Store files encrypted in sd-app AppVM

[redshiftzero]

Currently we decrypt files and store them decrypted in the sd-app AppVM. However, there is not a strong reason to store decrypted versions of these files as we can decrypt them only as needed (whether for the message/reply view described in #89's conversation view).

Another approach might be to decrypt the files upon first download, store only some metadata in the sd-app AppVM (for the UI), and from then on out decrypt only on demand.

The metadata we'd want to store about each file is:

• The journalist designation of the source
• The datetime of the submission
• The extension of the file
• The name of the file

2020-09-11: Edited to reflect current VM name - @eloquence

[redshiftzero]

I'm thinking about this more now in the context of considering how to implement the conversation view in this client mockup and I'm now on the fence about this issue. If we store all documents and messages encrypted, it means that it will be difficult to create a responsive conversation view in the UI. We'd have to start the application and then start decrypting all the submissions/replies on disk (or do it on demand), making a user experience that would range from sluggish at best to incredibly annoying at worst.

So taking a step back and considering what threats this is actually mitigating (to evaluate whether the hit to usability is worthwhile), we have:

• Attacker compromises sd-svs AppVM, in which case they can also request files to be decrypted or establish persistence and monitor activity regardless of whether we store the docs encrypted or not.
• Attacker steals workstation while it is on, in which case they can also just decrypt documents/messages using the submission key, which they would also have access to.
• Anything else?

[emkll]

I agree, I can't think of anything else, assuming the GPG private key is stored on sd-gpg and does not have a passphrase. It might also be worth mentioning that in my experience with split-gpg vms, each key operation produces a notification (this doesn't address the sd-svs compromise scenario, but perhaps could offer auditability). Should we keep a log of decryptions?

The situation is a bit different if the key is protected with a passphrase, it would offer an extra layer of encryption for the GPG private key, and the documents would require an extra passphrase to decrypt. This mitigates the theft scenario.

In the context of #100 (using hardware tokens to store GPG keys), I think the difference is even greater: it would require the token to be plugged into the workstation, as well as the token PIN.

In the last two scenarios, decrypting the files as the client starts and caching those files in their decrypted form for the duration of the journalist's session might be a way to balance the user experience.

[eloquence]

We discussed this on 8/23. As a next step, we identified that more research is needed to document the user experience of passphrase-protected gpg keys in Qubes OS. @emkll will also update the threat model to score the potential additional value that a passphrase-protected key would provide, so we can ultimately measure it against whichever potential user experience trade-offs we identify.

[kushaldas]

I tested the Qubes split GPG on my box today along with a password protected key. The good thing is that the GPG valut is prompting for the password using the gtk-pinentry, means the user will have to provide the passphrase if not given before.

[eloquence]

Per discussion with @redshiftzero, we're removing this from the must-do alpha requirements. Without additional security mitigation the benefits here don't outweigh the immediate significant increase in complexity. We can reconsider post-alpha.

[eloquence]

Discussed at backlog review on 10/23, still something we may want to consider for defense in depth.

[zenmonkeykstop]

Definitely needs further discussion and potential reexamination of the SDW threat model.