Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: Kristian Fiskerstrand <k_f@g.o>
Cc: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
Date: Wed, 24 Apr 2019 19:34:34
In Reply to: Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard? by Kristian Fiskerstrand
1 On Wed, Apr 24, 2019 at 11:57 AM Kristian Fiskerstrand <k_f@g.o> wrote:
2 >
3 > On 4/24/19 4:19 PM, Rich Freeman wrote:
4 > > If it is the case that Nitrokeys can't support a separate primary key,
5 > > I'd suggest modifying the GLEP to remove that requirement when a
6 > > smartcard is in use. Its main purpose is to keep a key component
7 > > offline, and if the key is generated on the card that is already
8 > > accomplished. Maybe somebody has a suggestion for how to make the two
9 > > work together, otherwise I'll go ahead and suggest a GLEP revision for
10 > > the next Council meeting.
11 >
12 >
13 > The GLEP should not be changed on the requirement for distinct signing
14 > subkey, this is one of the expected results of it to begin with.
16 So, I intend to propose this. Council is welcome to vote it down.
17 However, I'm really interested in what the concern is here.
19 The only reason to have a separate primary key is to have an offline
20 copy, but it is not a current requirement that it be kept offline, and
21 I suspect that 99% of devs won't keep it offline, and of course there
22 is no way to verify if this is being done anyway.
24 So, maintaining this requirement with a Nitrokey means that we in
25 reality have the primary key online most of the time, when if it were
26 the same as the signing key then both would be offline in the
27 Nitrokey. This requirement effectively makes the key less secure in
28 practice. It doesn't matter if the signing key is safely stored in
29 the Nitrokey if somebody can steal the primary key, since they can
30 just create a new signing key at will. Also, by generating the key
31 outside the Nitrokey it is exposed to a far higher risk of compromise.
33 At best for the 1% of devs who would actually keep the primary key
34 offline then this achieves the same level of security you have with
35 the Nitrokey anyway, which always keeps its keys offline
36 (effectively). The only exception to this would be an exploit in the
37 Nitrokey, which seems like a pretty low risk. And of course it is
38 only a risk when the Nitrokey is plugged in, and the intent would be
39 for devs to only plug it in when working on commits. In any case, I
40 think it is far more likely that somebody generating keys using
41 software has a rooted box than somebody is going to come up with a way
42 to extract keys from a Nitrokey.
44 Now, I think it is a great best practice which we should support for
45 anybody who wants to have their offline key-generation machine they
46 keep in a vault or whatever. And by all means require the additional
47 key when using keys not generated on a Nitrokey. As to how you can
48 tell which are which, I'd simply point out that you can't tell if keys
49 are being stored offline or not, so really your risk is unchanged in
50 taking devs at their word.
52 I think most companies issuing these sorts of tokens to users would
53 generate their keys on the tokens for these very reasons. The reason
54 they're using these hardware tokens is because they know that users in
55 practice will not take extraordinary care to protect keys, and the
56 token provides a similar level of security with very little
57 inconvenience. Really the only thing we're missing with the Nitrokey
58 is some form of attestation to ensure the keys are in fact generated
59 on the device.
61 --
62 Rich