[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    Re: [qubes-devel] Re: GitLab
From:       Andrew David Wong <adw () qubes-os ! org>
Date:       2017-05-15 2:45:13
Message-ID: d09c864b-b334-09c4-4021-c994e57e9fe0 () qubes-os ! org
[Download RAW message or body]

-----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+unsubscribe@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.


[prev in list] [next in list] [prev in thread] [next in thread]