> On 15. May 2017, at 04:21, Andrew David Wong adw-at-qubes-os.org > |qubes-mailing-list/Example Allow| <a4dhg0e...@sneakemail.com> wrote: > > -----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.
Not if those keys were generated and signed in the QMSK-Environment before they were transferred to their owners, right? > >> 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. -- 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/20727-1495267329-64823%40sneakemail.com. For more options, visit https://groups.google.com/d/optout.
