On 12/30/2016 06:58 AM, Andrew David Wong wrote: > 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 >
I think the assumption was that PGP makes too much parsing during decryption/decoding of an encrypted blob. In fact it can do decryption, decompression which means more string/data manipulation routines and more potential bugs or vulnerabilities. On this assumption, PGP has been used first to check the signature of encrypted blobs (using a HMAC algorithm based on a user provided passphrase), then and only then any program could be selected to decrypt/decompress the data. In this case this can also be PGP. In most linux distribution PGP is used to verify packages before reading package data or extracting packages, but the reason is essentially validating package integrity and chain of trust. Not protecting against parsing=bugs=vulnerabilities. The question may be whether one should choose PGP or another tool, but in fact the important thing is how Encryption / Signature / Trust mechanisms are used whatever the selected or combined tool, and PGP can sign then encrypt or encrypt then sign. One interesting example is the history of package signature in Archlinux: Archlinux only choose recently - considering its history - to sign packages and it was during years considered as unnecessary by Archlinux developpers. Now it verify packages (trust), and *optionnally* the package database that contains metadata of all packages (Actually, I think that there is no signature available for the core package database). This means that this database that involve a lot of parsing is not verified, but packages are. I don't checked how fedora package update exactly works, especially package database files, however I remember that packages are downloaded in an AppVM (usually the default firewall vm). The package signatures could then be verified against PGP fedora PGP keys before being imported in dom0, and are definitively verified in dom0 before generating a package database file only for dom0 [1]. [1] /usr/libexec/qubes/qubes-receive-updates -- 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/9a88c1fa-3133-a250-c718-9590353f8871%40yahoo.fr. For more options, visit https://groups.google.com/d/optout.
