Gentoo Archives: gentoo-dev

From: Marek Szuba <marecki@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards
Date: Thu, 25 Apr 2019 12:26:41
Message-Id: 7fd02b4b-b819-02f9-1fb1-9656b7663965@gentoo.org
In Reply to: [gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards by Rich Freeman
1 On 2019-04-25 12:32, Rich Freeman wrote:
2
3 > The OpenPGP smartcard standard, and the Nitrokey Pro smartcards that
4 > are being distributed to Gentoo developers, do not support having a
5 > separate primary/signing key for keys that are generated on the cards.
6 > As a result they can only be used in accordance with our current
7 > requirements if the keys are generated in software, which places them
8 > at a higher risk of compromise.
9 >
10 > The intent of the separate primary key is to reduce the risk of it
11 > being compromised by keeping it offline. However, if it were
12 > generated on a smartcard it would be exclusively be maintained
13 > offline, so it is counterproductive to require that it be generated
14 > online and then recommend that it be kept offline after this.
15 > Additionally this key needs to be brought back online anytime the key
16 > expiration is updated, which is at least annually.
17 >
18 > I believe this is creating a false sense of security, and that
19 > developers should be encouraged to generate new keys using their
20 > smartcards, so that these keys are never stored outside the protected
21 > hardware. By default gpg creates revocation certificates at this time
22 > as well. If a key is lost it can still be revoked, and of course the
23 > gpg fingerprint associated with the developer can be changed in any
24 > case and is the de-facto root of our trust system. These failure
25 > modes really are no different from an offline primary key that is
26 > separate from the signing keys.
27 >
28 > The revision adds an exception for keys generated on a smartcard.
29
30 I very much oppose this change, see my comments in the "Best way to
31 create a GLEP 63 compliant GPG key on Nitrocard?" thread for details.
32
33 Regarding the very accurate comment that requiring a separate primary
34 key does not guarantee said primary key is handled securely - I know it
35 might be overly optimistic of me but I kind of expect developers of a
36 mainstream Linux distribution to be able to grasp and follow OpenPGP
37 best practices.
38
39 Incidentally, having been using smartcards of various sort in my
40 workflows for 5+ years now I find their most obvious benefit is not that
41 they store crypto keys securely but that they make the use of keys *more
42 convenient*. Worried about persistence of the private key on your drive,
43 especially on a shared system? Remove the card and the key is
44 inaccessible, and since it was never handled by the system itself there
45 should be no traces of it even in RAM. Fed up with resetting user
46 passwords being a significant part of your sysadmin duties due to some
47 people seemingly being unable to retain "at least 16 characters long and
48 a minimum 3 character classes" in their wetware? Smartcard PINs can be
49 much shorter because smartcards can lock up after a fairly small number
50 of having entered the PIN wrong. In fact, although the official Gentoo
51 rationale for the use of Nitrokeys as stated on the relevant Wiki page
52 is that it makes the signing keys more secure, the recommendation to
53 disable forcesig does hint at the ease-of-use factor as well.
54
55
56 --
57 MS