[prev in list] [next in list] [prev in thread] [next in thread]
List: qubes-devel
Subject: Re: [qubes-devel] Re: GitLab
From: "Frank" <q5wrm4nkwz () snkmail ! com>
Date: 2017-05-20 8:02:06
Message-ID: 20727-1495267329-64823 () sneakemail ! com
[Download RAW message or body]
> On 15. May 2017, at 04:21, Andrew David Wong adw-at-qubes-os.org \
> |qubes-mailing-list/Example Allow| <a4dhg0euot@sneakemail.com> wrote:
> -----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.
Not if those keys were generated and signed in the QMSK-Environment before they were \
transferred to their owners, right?
>
> > 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.
--
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/20727-1495267329-64823%40sneakemail.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