[prev in list] [next in list] [prev in thread] [next in thread]
List: qubes-devel
Subject: Re: [qubes-devel] Re: GitLab
From: Jean-Philippe Ouellet <jpo () vt ! edu>
Date: 2017-05-15 1:57:45
Message-ID: CABQWM_B8GttM5b9yi747FK0QpvOTqN9-p+UKH-PP6WbquuS5MQ () mail ! gmail ! com
[Download RAW message or body]
On Sun, May 14, 2017 at 3:11 PM, Andrew David Wong <adw@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) <marmarek@invisiblethingslab.com>
sig 3 063938BA42CFA724 2014-03-05 Marek Marczykowski-Górecki
(Qubes OS signing key) <marmarek@invisiblethingslab.com>
sig EE570349A603BCB6 2014-03-05 Marek Marczykowski (Qubes OS
signing key) <marmarek@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) <marmarek@invisiblethingslab.com>
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
--
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/CABQWM_B8GttM5b9yi747FK0QpvOTqN9-p%2BUKH-PP6WbquuS5MQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic