-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-05-13 18:21, Peter Todd wrote: > On Sat, May 13, 2017 at 03:18:39PM -0500, Andrew David Wong wrote: >> There are many other methods you could use to attempt to verify the >> master key fingerprint aside from relying on the Qubes website. Here's >> a brief, non-exhaustive list: >> >> * Use different search engines to search for the fingerprint. >> * Use Tor to view and search for the fingerprint on various websites. >> * Use various VPNs and proxy servers. >> * Use different Wi-Fi networks (work, school, internet cafe, etc.). >> * Ask people to post the fingerprint in various forums and chat rooms. >> * Check against PDFs and photographs in which the fingerprint appears >> (e.g., slides from a talk or on a T-shirt). >> * Repeat all of the above from different computers and devices. > > Don't forget the PGP web-of-trust. >
Good point. Added. > For me personally this is a very short trust path with multiple connections. > For example: > > 1) my PGP key is 0x7FAB114267E4FA04 > 2) I've signed Nicolas Vigier (boklm)'s key, IIRC after a keysigning a few > years back at a Tor conference. > 3) Nicolas Vigier has signed the Qubes Master Signing Key. > > Which you can see here: > https://pgp.cs.uu.nl/paths/7fab114267e4fa04/to/2067001b1b678a63.html > > A few more paths: > > Me to Ola Bini: > https://pgp.cs.uu.nl/mk_path.cgi?FROM=7FAB114267E4FA04&TO=295c746984af7f0c&PATHS=trust+paths > Me to Holger Levsen: > https://pgp.cs.uu.nl/mk_path.cgi?FROM=7FAB114267E4FA04&TO=091AB856069AAA1C&PATHS=trust+paths > > Unfortunately the tools to actually find these paths all kinda suck, but they > do at least the paths exist. The one I used to find the above is > https://pgp.cs.uu.nl/, however it has the significant limitation that it only > works for keys in the "strong set" - the Qubes signing key is *not* in that > set > because it has never signed another key that is in that set. > > IMO the Qubes project should fix this. > It's unclear to me whether there's any practical way to perform such a signing without exposing the QMSK to unacceptable risk. Joanna wrote [1] that the QMSK was generated on an airgapped machine and that the private key has never left that machine (and hopefully never will). I infer from context that this refers to a physically (as opposed to virtually) airgapped machine. Since the QMSK was generated there (and, presumably, Release Signing Keys (RSKs) are also generated there), this entails that some GPG-like program (probably GPG itself) is installed in whatever OS is running on that machine. Let's refer to this as QMSK's "environment." Clearly, both the QMSK and RSK public keys get transferred off of the airgapped machine somehow, since we have copies of them. I assume that such transfers are only one-way and are tightly controlled. That is, only public keys are allowed to leave the QMSK's environment, and nothing is allowed to enter. In particular, it's safe to assume that there is no networking (or else it wouldn't be an air gap) and that no freely rewritable USB drives (i.e., drives without write-protect switches) are plugged into that machine. (This is inferred from the fact that Joanna was warning the world about the dangers of plugging USB devices into machines years before BadUSB.) This suggests that some kind of read-only medium is used to enforce the one-way transfers. If all this is correct, then the only way for the QMSK to sign another key is to: (1) Generate the key in the QMSK's environment; (2) Transfer the key to the QMSK's environment. (1) is the method used to create RSKs, but it's not clear whether this would help with getting the QMSK into the strong set. Would it be sufficient for the QMSK to generate a key that subsequently enters the strong set? Even so, this would introduce new complications to the Qubes PGP trust model. For example, should the strong set key generated by the QMSK be considered just as trustworthy as the QMSK itself? Should it be used to verify RSKs and Qubes ISOs? If not, can such accidental misuse be prevented, and if so, by what means should that be enforced? (2), meanwhile, requires transferring the key to the QMSK's environment via: (3) The network; (4) A storage medium; (5) Manual input. Let's assume that (5) would be too cumbersome and error-prone to qualify as "practical." (3) would, again, entail that the machine is no longer airgapped. (4) is inherently risky. The riskiest storage media are, presumably, those with rewritable firmware, such as many conventional USB drives. Even with less risky media (e.g., CD-ROMs or even floppy disks), however, we can't rule out the possibility that a malformed PGP public key block might try to exploit a hypothetical vulnerability in GPG. So, in general, (2) may not be worth the risk. [1] https://www.qubes-os.org/security/verifying-signatures/#importing-qubes-signing-keys - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZGKvVAAoJENtN07w5UDAwt4QP/3APMZl7IQ/39pP/Y8iAet4n azKYxQTfz6paoCTk7UqWcfsmlbP6hzPqoADmK5GDtDPgqhN8bRCH+6s0MKjsCDPP 9IVIAHZ8G36O8+c/zrbHHxm6zUoweYuciXJQYc3CdKPNnlNr/p7T89Zrea0SBJ2O kkMtPvXkr0OgGniz4ZCSpxjD+OlSM/jwMNSGiaNoSM7j9EdP4XaRIc4rNkoVifFx 9baA2xFYRlozQ+gDTeDtKx08h1TPGP3nVwvcpld3j21stBBonlyveu7TJ8Zi54i1 To5GzOFTbBy0IHbmoN8SB0zgWAPIGksNXLs4cBGms7PMC1yjTVLojq2B0O26rkWL PcQzIv7Cnnr9J9VIGnWLe1DkjjL1CA57EPL//F/M0mPA2OCQeNllOV1fXRbKqzc0 basdNd4Lsh13cw/iodcJDnlaUjRqup3b2RJjtD38ZpJuQAd6R2MDVtAbW/nQ0LiE AQBlHSPYds0uwel5fQC1Newj6oB0QUTwzJXx+7T/a+PP2LoQgadjvI3+YJLOUQ/O BfI4eFkhP+xKWfuCvTjXHFTpVpb5oB1wb7WnEDDnDXqnhWkh6W0ugIIkOVLhKfgM 92iZJnfPtvnOEimBUx5xiHv805pSWxps/4xJzLmfnKQ9//MoTbqp5/19crSyu8nO CLzc1iqx3+j7BuJOlEX6 =h+YB -----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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/f0311882-99cc-568c-16ea-ffa60c0c0acb%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.