[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:21:59
Message-ID: 357f5e92-5e60-ab8c-5426-38dc4b0e3b06 () qubes-os ! org
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2017-05-14 20:57, Jean-Philippe Ouellet wrote:
> 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>
>
Oh, wow! That raises some questions about the way the QMSK is handled.
> 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
>
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJZGRDFAAoJENtN07w5UDAwB6AQAJciK2nVcGtbRtqv6JGUK46V
42y3xfUtSk45lP/ABtUdmwXWuDVTOfq8qFoK5AuBScmZEeihzbxum1lsyPNwghGz
zEM7oleroio23a+Jbfhv0JGWMFfQBQQ5Z+F19X0aT2UPq6c5WMHdWyPU2N5OSlAM
rrCYjc+WEmiOhKJSiMmns1zlC1R/mUejR/xzdAMaG9WxLm/hKPxtVtFcuKfUfFVe
xgHUOBh++n7OVism4/g9kCaoecYtEFZoz/r3AE75T0UOl4fe4U+KCvmRnXZzz6v2
eQWgpNbCAVEy+cMq/bfEQKrC1jbDxVpP3llIj42JRuRjdxv1i3ZKP2YaBMH/tXHG
Nsxzzd6lXdx0ODbsroV+iZohKGZqRJvSy+L7NOCuTCgL/1xB/FcnLBynncw4CQlG
rTPgd1tankyHenhPmoQuZuqOjvZx4aWIHqRRrsPIJjPvIidgknBpahjedzx8spmN
PSW52INkuesSCZGd5T3Y2AZVTr5o82XfdIKLeKKhwnBf5rPW9TjyKhDVl15sPniJ
AwOVvWWpPwdxKthZfNT5P6zK5lgofuqC5BiZAmDbI6TO+Wh7Ja06/uhyNLg5p7Cr
o4rtDoBKDQfEBIEJCQbm/t9ZAmf25Gher3DLB4U56sIjZEgn3yow6BdhliTEgyzu
FRBnrHuxtYkHSr6pxSdt
=XrqU
-----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/357f5e92-5e60-ab8c-5426-38dc4b0e3b06%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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic