-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-05-22 23:49, Jean-Philippe Ouellet wrote: > On Sun, May 14, 2017 at 4:20 PM, Andrew David Wong <[email protected]> wrote: >> 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. >
Encrypting a backup to a public key, where the private key is not and never has been accessible to the machine creating the backup? You have to admit that's a pretty remote edge case for Qubes, which is supposed to be a trusted single-user system. I'm not denying such edge cases exist, but it should be obvious that statements like, "You should use symmetric crypto for your backups" are not meant to apply in such remote edge cases. Rather, they're meant to apply in the vast majority of cases in which they make sense. If we tried to qualify every statement to make it perfectly accurate across all domains of possibility, we'd never be able to say anything. (By the way, just because a camera's watching everything you type doesn't necessarily mean you have to use asymmetric crypto. You could use, e.g., a preshared keyfile instead.) - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZI8aTAAoJENtN07w5UDAwwgoQALjoWMYgAMey/q1vrEwKnYse xJ1hpSTiq1VpmQJ3AcPZTwUEXQ80JQs2jKn+8r/LyayxvyUoo5v83mJZ/3/R7UV3 jwC2fC4+ITdDUZUbDEIHHDTmi6/EClZ6XZVisZvnNPHMDozFxYsyeY1nqXFonnjq KwIKUR7On6M5hHuvzoyftnA8Ek+jUTp3xO6vKqzD8IqynGERZAu/4DOzmwoVKyr2 7QUJN2zpwM63CRdG1VNCkmuUuN8DflZHUp1EOTbW/fF2AjBucZPI51vVkelpD++7 g9k27sSwV606CiCtCar2B8Vopdt0DM1i/89Rqfj3vCg4G6FaNXA8nB5hg6B3rxfC kRnlv/IgVStE+VQAY6f+l+X1IzlODQ3mYccwavm3bvkeWl3fzawGA2P/PUkqoztE +ig2FGkMcrtItnqKRPmwsdKUMLmTpP1djBR6ToeO0wr6cY9bKSm0tYGYqa0ab5Pi xSSwiE337ynRJ1eZrsXN0noICsBND0Olc+pqCmxJODEx7hAXEjzTRGW/k53Z/bMf +mKsjimCtrkqrzFfXZHcrIVbEpx7Yf/kw/0BlVBMVdtgbvOReVwNjWhDwRUZ+RJe 1hAnUmpDQwDfMgG5SxoX40UDhllI+T4ToIX4HlsjYalgas4p091mYwkqeOpZxpda 9KwKFXjo+FTGt4O6a3fW =ZITB -----END PGP SIGNATURE----- -- 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/2167da4a-88f7-e4e4-85c5-c0bbca5cb992%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
