-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2013-08-18 10:18, Joanna Rutkowska wrote: > On 08/17/13 16:48, Marek Marczykowski-Górecki wrote: >>> IIRC, gpg did waaay to much parsing (related decyrpting) before >>> veryfing >>>> the signature, which we agreed was wrong. Openssl seemed >>>> better in this respect. >> [...] >> >> By "gpg did waaay to much parsing (related decyrpting) before >> veryfing the signature" you basically mean that gpg isn't usable >> to encrypt the backup in our case, right? IIUC ideal solution >> would be to first verify all the data intergiry, then decrypt it >> and pass to restore core. But the "verify all the data integrity" >> part needs access to the whole backup blob (so store it >> somewhere), which isn't doable as I said earlier... Perhaps some >> block-based data integrity check (so can be done on the fly), >> but I'm not aware of any existing solution like this. As said >> earlier I'd prefer to keep our backup format as simple as >> possible - IOW to be extractable also with simple tools (without >> QubesOS). >> >> IMHO the best compromise here is to encrypt/decrypt the data with >> gpg (symmetric) then use tar for archive and each file keep with >> attached hmac (additional file right after). This means that >> untrusted data is processed by gpg (decryption), then by tar and >> then by openssl for hmac verification. Note that if you don't >> trust gpg in regard of parsing untrusted data (decryption here), >> probably much more components must be also reimplemented (like >> dom0 updates - rpm signatures, installation ISO signatures, >> enigmail for thunderbird etc). So IMO we don't have really the >> choice about the trust in gpg. >> > > We ain't need no stinkin' gpg to trust! > > [...]
After meditating on this thread for a little over three years, I'd like to revive it, because I think Marek made an important point here, and I don't quite understand Joanna's response. If we don't trust GPG in our backup system because it does too much parsing of untrusted data before verification (which I believe is correct), then why do we trust it in our dom0 update system? As a reminder, take a look at what we say about the security of the dom0 update system.[1] We tout the "separation of duties" between dom0 and the UpdateVM as a security feature (which it certainly is), but we also note that we're implicitly trusting GPG in dom0 not to be exploitable by a malicious package when it attempts to verify that package. The only asymmetry between the two cases that I can see is that in the case of dom0 updates, the packages are not encrypted, only signed, whereas we have to assume that the backup blob may be encrypted. Therefore, our position (viz., distrusting GPG with respect to backups while trusting it with respect to dom0 updates) is consistent only if it is the case that too much pre-parsing is done when handling a signed-and-encrypted blob, whereas an acceptable amount of pre-parsing is done on an only-signed blob. This condition, in turn, is likely to hold only if GPG handles signed-and-encrypted blobs by *first* attempting to decrypt the blob, *then* attempting to verify the integrity of the plaintext.[2] Otherwise, there should be no significant difference between the two cases in the amount of pre-parsing performed when verifying a blob. If the first step is always verification, then the amount of parsing done before the first step should be basically the same whether the thing being verified happens to be plaintext or ciphertext. [1] https://www.qubes-os.org/doc/software-update-dom0/#how-is-software-updated-securely-in-dom0 By the way, the last sentence in this section sounds false to me: "While we could, in theory, write a custom solution, it would only be effective if Qubes repos included all of the regular TemplateVM distro's updates, and this would be far too costly for us to maintain." This doesn't follow, since TemplateVMs are less trusted than dom0. A more secure custom solution for dom0 updates would not have to be applied to TemplateVMs in order to make Qubes as a whole more secure (by making dom0 less vulnerable to attacks via malicious update packages). Perhaps we meant something slightly different here: All the normal distro packages *for dom0* (e.g., Fedora 23 packages, in the case of R3.2) would have to be included in the Qubes repos in order for such a solution to be effective. Even this would be true only if the custom solution were repo- or package-dependent, and only if we wanted to guarantee secure updates using the new method for all of those packages. (There's a lot to be said for making dom0 smaller, and minimizing the number of packages installed there accords with that notion.) [2] This would seem to be a significant design flaw (perhaps a flaw in the OpenPGP spec).[3] It means that GPG does either mac-then-encrypt or mac-and-encrypt rather than the superior encrypt-then-mac.[4] [3] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html [4] http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYZfdrAAoJENtN07w5UDAwjt4QAM0U67EaippB0pYpBirxg6ER qzwsHFEF7vSyqi7942jrZ5SUGSLMNU4j9IK6MmqD2XAp1qzSG0KGc6R7T1azFvSc YxeFLdSnD0Y4k1UTJNmSTqMe+L8Bmud0U84aATswI0E7u8whnElPfoXrk2GJYkNJ B8CzFWgcPSxxloqJbbXU7ueaeNL766QtPnMYNmgDBzR5zuZ8hYzgfMOoGXQKq69T G5/rTRjqKeipkpunEmsJzqLLV3DdnnF4x81zPVsKrrNPOzmtMTQ4ihdhwFDGZiGf PMxJdbHW7v1YmcC0T6BDmry7K3Nb3YKewIo2fv1eF8EIKMhWV0DcwhBqJzUkxtGZ D+owcoDCitcYMRAT3DPuwLSZ1LPW6hvN98wtib/4Yw5PjYReJEieScbhg4dD5mE/ 2SvidPXGaYhuQm9AZjYeSlbD5VWWBaE5XGoSkigNXdXwr1lsyUpp8o6q77MBb47M 3D4BqW0rmNJ9KMmfMmHl048YgP+dlblkeU/O9wnjdUSe6dayy37xMb7rIQMjUXv0 mA2IGWmXHHh0HAD4qN2gnpbDZ6jmwed1xPiq3koCgI2aYG0rcfHHiJzRklI1Bp0D 2asnGu7XA/vHfe5xPMEsCGpo35xLPesjrwDldzf1cup7KmyyqMiCeKxB9hgSd3+t FcdLc+/lNrcxJ+nafOJu =uFbd -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" 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-devel/cc51fe68-9491-ccea-d880-edea74e4f958%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
