On Sun, May 14, 2017 at 4:20 PM, Andrew David Wong <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 2017-05-14 03:51, Holger Levsen wrote: >> On Sat, May 13, 2017 at 02:55:12PM -0500, Andrew David Wong wrote: >>>> you really dont protect your gpg key with a passphrase?? >>> See: https://www.qubes-os.org/doc/split-gpg/ >> >> oh wow :( >> >>> Why is that a problem? It's only visible in dom0. If an attacker is in >>> dom0, it's already game over. >> >> no, the world is not black and white. >> >> If an attacker steals your computer while it's unlocked, all your gpg >> encrypted stuff is wide open. >> >> If an attacker steals my computer while it's unlocked, my gpg encrypted >> stuff is still locked. Surely the attacker can now install as many backdoors >> as >> they want, but as long as I don't type my gpg passphrase into that computer >> anymore, it should be pretty safe. >> > > You're conflating two distinct problems: > > (1) Passphrases I've typed in dom0 are available in cleartext in > dom0. > (2) Data-at-rest is not encrypted while Qubes is booted and the screen > is unlocked. > > We could solve (1) without solving (2). If we did that, it would solve > the `ps` + qvm-backup problem (the first problem you mentioned), since > my backup would be encrypted, and the thief wouldn't have access to the > backup decryption passphrase. > > (2) is the second problem you mentioned. Solving (2) is distinct from > solving (1), but in order for the solution to (2) to be satisfactory, we > also have to solve (1) (or make sure no similar problem arises for > per-VM encryption), since otherwise my data-at-rest passphrase could be > obtained via (1). > > I think the right approach to (2) in Qubes is per-VM encryption [1] > (probably with LUKS instead of GPG, and certainly not relying on public > key crypto, though hopefully we're all already in agreement on the > latter point). If I'm in an untrusted physical environment, I should be > able to work with less sensitive VMs without decrypting sensitive VMs, > and if someone steals my unlocked laptop, they shouldn't be able to gain > access to the encrypted sensitive VMs. That's the goal, anyway. > > > [1] https://github.com/QubesOS/qubes-issues/issues/1293
Solving 1 is not a simple matter of patching some things to pass passwords on stdin instead of argv or env vars, it would still be a mostly trivial matter for an attacker to just make a core dump and run strings on it. Rather, I believe a proper solution to 1 would require that dom0 to some degree distrust whoever is physically at the keyboard. A "kiosking" of Qubes, if you will. Also, I do not agree on your assessment about symmetric crypto being obviously the way to go. I think there is value in being able to initiate a backup from inside a hostile environment (think: someplace with cameras everywhere watching any passphrase you would enter), which would make sense to implement by encrypting to an asymmetric keypair for which the private half is only in a separate physical environment. (Sure, yes, use a symmetric algo for the bulk encryption and just encrypt that with the asymetric algo... not my point.) You would not be able to decrypt your own backups until you had regained access to the private half, but you would be able to start backups without needing to divulge your backup secret at the same time. In this scheme you would also have another keypair with the secret part on your laptop in order to sign the backup (authenticating it with an asymmetric signature without requiring a passphrase at backup-creation time). I've made this argument before, but perhaps never presented it well enough. Expect a PoC in the hopefully not-too-distant future. Regards, Jean-Philippe -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABQWM_CKyJYdocFbpz_O2YQhO%3DXbNweaDrm6oCsV_4tKvsyVag%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
