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

List:       qubes-devel
Subject:    Re: [qubes-devel] Re: GitLab
From:       Peter Todd <pete () petertodd ! org>
Date:       2017-05-15 2:36:30
Message-ID: 20170515023630.GB17281 () fedora-23-dvm
[Download RAW message or body]


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. :)

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
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/20170515023630.GB17281%40fedora-23-dvm. \
For more options, visit https://groups.google.com/d/optout.


["signature.asc" (application/pgp-signature)]

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