-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-05-14 20:57, Jean-Philippe Ouellet wrote: > On Sun, May 14, 2017 at 3:11 PM, Andrew David Wong <a...@qubes-os.org> wrote: >> 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 > > Uhh... except it *has* signed other keys, for example: > > $ gpg2 --list-sigs marmarek > pub rsa4096 2014-03-05 [SC] > 0064428F455451B3EBE78A7F063938BA42CFA724 > uid [ unknown] Marek Marczykowski-Górecki (Qubes OS signing > key) <marma...@invisiblethingslab.com> > sig 3 063938BA42CFA724 2014-03-05 Marek Marczykowski-Górecki > (Qubes OS signing key) <marma...@invisiblethingslab.com> > sig EE570349A603BCB6 2014-03-05 Marek Marczykowski (Qubes OS > signing key) <marma...@invisiblethingslab.com> > sig DDFA1A3E36879494 2014-04-30 Qubes Master Signing Key > sig 3 063938BA42CFA724 2014-04-30 Marek Marczykowski-Górecki > (Qubes OS signing key) <marma...@invisiblethingslab.com> >
Oh, wow! That raises some questions about the way the QMSK is handled. > This is the reason we can initially import only the master signing > key, trust it, and have all other valid Qubes signing keys trusted > transitively. This is done for example here [1]. > > [1]: > https://github.com/QubesOS/qubes-builder/blob/3352cd4363a25debd77ced0a1fa752944ac1ef2f/scripts/verify-git-tag#L25 > - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZGRDFAAoJENtN07w5UDAwB6AQAJciK2nVcGtbRtqv6JGUK46V 42y3xfUtSk45lP/ABtUdmwXWuDVTOfq8qFoK5AuBScmZEeihzbxum1lsyPNwghGz zEM7oleroio23a+Jbfhv0JGWMFfQBQQ5Z+F19X0aT2UPq6c5WMHdWyPU2N5OSlAM rrCYjc+WEmiOhKJSiMmns1zlC1R/mUejR/xzdAMaG9WxLm/hKPxtVtFcuKfUfFVe xgHUOBh++n7OVism4/g9kCaoecYtEFZoz/r3AE75T0UOl4fe4U+KCvmRnXZzz6v2 eQWgpNbCAVEy+cMq/bfEQKrC1jbDxVpP3llIj42JRuRjdxv1i3ZKP2YaBMH/tXHG Nsxzzd6lXdx0ODbsroV+iZohKGZqRJvSy+L7NOCuTCgL/1xB/FcnLBynncw4CQlG rTPgd1tankyHenhPmoQuZuqOjvZx4aWIHqRRrsPIJjPvIidgknBpahjedzx8spmN PSW52INkuesSCZGd5T3Y2AZVTr5o82XfdIKLeKKhwnBf5rPW9TjyKhDVl15sPniJ AwOVvWWpPwdxKthZfNT5P6zK5lgofuqC5BiZAmDbI6TO+Wh7Ja06/uhyNLg5p7Cr o4rtDoBKDQfEBIEJCQbm/t9ZAmf25Gher3DLB4U56sIjZEgn3yow6BdhliTEgyzu FRBnrHuxtYkHSr6pxSdt =XrqU -----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/357f5e92-5e60-ab8c-5426-38dc4b0e3b06%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
