[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-14 19:11:30
Message-ID: f0311882-99cc-568c-16ea-ffa60c0c0acb () qubes-os ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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


- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZGKvVAAoJENtN07w5UDAwt4QP/3APMZl7IQ/39pP/Y8iAet4n
azKYxQTfz6paoCTk7UqWcfsmlbP6hzPqoADmK5GDtDPgqhN8bRCH+6s0MKjsCDPP
9IVIAHZ8G36O8+c/zrbHHxm6zUoweYuciXJQYc3CdKPNnlNr/p7T89Zrea0SBJ2O
kkMtPvXkr0OgGniz4ZCSpxjD+OlSM/jwMNSGiaNoSM7j9EdP4XaRIc4rNkoVifFx
9baA2xFYRlozQ+gDTeDtKx08h1TPGP3nVwvcpld3j21stBBonlyveu7TJ8Zi54i1
To5GzOFTbBy0IHbmoN8SB0zgWAPIGksNXLs4cBGms7PMC1yjTVLojq2B0O26rkWL
PcQzIv7Cnnr9J9VIGnWLe1DkjjL1CA57EPL//F/M0mPA2OCQeNllOV1fXRbKqzc0
basdNd4Lsh13cw/iodcJDnlaUjRqup3b2RJjtD38ZpJuQAd6R2MDVtAbW/nQ0LiE
AQBlHSPYds0uwel5fQC1Newj6oB0QUTwzJXx+7T/a+PP2LoQgadjvI3+YJLOUQ/O
BfI4eFkhP+xKWfuCvTjXHFTpVpb5oB1wb7WnEDDnDXqnhWkh6W0ugIIkOVLhKfgM
92iZJnfPtvnOEimBUx5xiHv805pSWxps/4xJzLmfnKQ9//MoTbqp5/19crSyu8nO
CLzc1iqx3+j7BuJOlEX6
=h+YB
-----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/f0311882-99cc-568c-16ea-ffa60c0c0acb%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]