-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-05-14 21:36, Peter Todd wrote: > On Sun, May 14, 2017 at 02:11:30PM -0500, Andrew David Wong wrote: >>> 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." > > Ah, that's quite a restrictive set of security concerns. Good point! > >> 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. > > Note that other mechanisms exist to get data out of such an environment > safely, > assuming that the environment itself is uncompromised(i): > > 1) CD/DVD writers > 2) Serial ports w/ RX pins removed (also possible with ethernet) > 3) Taking a photo of the screen (hopefully with OCR rather than by hand!) > > > i) Note how this assumption is less stringent than the requirements for the > Zcash trusted setup that I participated in, as in that case we wanted to be > able to create an audit log of all data that left the trusted setup computer; > we may have failed at that goal as DVD-R's are not strictly read-only once > written. > >> 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. > > While Jean-Philippe Ouellet noticed that the QMSK *has* signed other keys, > even > if it hadn't you've nearly hit on the solution. Basically do: > > 1) Generate binding key pair in QMSK's environment > 2) Sign QMSK with binding key > 3) Sign binding key with QMSK > 4) Transfer binding *keypair* out of QMSK's environemnt to secondary > environment > 5) Transfer strong-set pubkey into secondary environment > 6) Sign that key with binding key > 7) Transfer binding pubkey and signature on strong-set key to keyservers > 8) Sign binding pubkey with a strong-set key > >> (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? > > It doesn't have to be as trustworthy as the QMSK: can and should verify > multiple web-of-trust paths. GnuPG's default settings are to expect to see > three separate paths, and you can easily tell it to consider the binding key > as > non-trustworthy when calculating those paths (with the command `gpg > --update-trustdb`) > > Remember that the binding key idea I outline above - which again I think we've > nearly accomplished anyway with Marek's Qubes OS signing key - is just a hack > to get PGP web-of-trust path finders to see the QMSK as part of the PGP strong > set. Once that's done it'll be much easier to find paths to the QMSK with > tools > like https://pgp.cs.uu.nl, but you'd still be verifying paths distinct from > this binding key hack. Equally, the alternatives people use right now are > probably often much more risky in practice than the above. :/ > > Finally, we also might manage to get the maintainers of https://pgp.cs.uu.nl > and similar tools to manually add the QMSK (and similar keys) to their > pathfinder databases! > >> (2), meanwhile, requires transferring the key to the QMSK's environment >> via: > > <snip> > > We're in agreement that's a less-than-wise idea. :) >
Great points. Thanks! I think your setup would have been preferable, since I'm pretty sure Marek's key was generated on a different machine (in which case some kind of riskier transfer must have occurred, but perhaps special precautions were taken). - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZGRY2AAoJENtN07w5UDAw70cQAMe+9BoYiaWe6c0V2QIIvPZf tbKP4jIKpDvJf5uO01QKSSH+FwMmuvZNYeRin0zJg8u9GS1sg6p5Rosj7zgXO86P XwuxZ1PvqdStWEgk9AfsAPeU/4SXraCNloE0KPUDoWtapnrn7PDD7NyWop3/vxvY VqoGa2x0LQ4Ue8DCc18ttEgrLxMWkeNZ8h2iB4nf7sCg40RZUgArzYOEUtztokJg //GT3hlZjjx8GgHPOXgNkfR95TYaVwrP/ZqMYxsui8pZ8BxwBkh6DSm449KCYCkz l262Scw6iKUXuFHRxELNj84/c2d5CyUGnN7BAt0AXJYm+k8rGl1/KH9FNpGxVDEf EP6aBSyLFfK25iMZ8jICwOFK3++xfD1I+7w1+fkepTvZScchmAg0wMjg0cHVEMiB NJaAkXxjalur1oexBG2NcTZoLVzO9yoFcVQX6rEmmv2Y+DZVj6opX/RMDabTUcgz 1545UHYL8h8kmOut4BJml1ZVbJbFRc6S98gwY2kmaoru6K4t4U/LSZVKh80+/atW XiIngh0t5zwHN6G1I142mXFuUM6Qta4PmrBxn0oFXlg5EbzRnVfdvVjzKNtt1rvf AeMeAszY56mDtLt8seXChh8qn8avDqIDm55bYGDPk5+QKBG4rIyhG204Xuv15AgW +KrtRrHxUY0XTpGixElu =TJWs -----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/d09c864b-b334-09c4-4021-c994e57e9fe0%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
