Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?
Date: Thu, 25 Apr 2019 12:37:23
In Reply to: Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard? by Marek Szuba
1 On Thu, Apr 25, 2019 at 7:57 AM Marek Szuba <marecki@g.o> wrote:
2 >
3 > On 2019-04-24 20:34, Rich Freeman wrote:
4 >
5 > > The only reason to have a separate primary key is to have an offline
6 > > copy,
7 >
8 > Not quite. First and foremost, you don not want to have an offline copy
9 > of the primary private key - you want to have the primary ENTIRELY
10 > offline.
12 Agree, I could have said that better. Though, to be clear the primary
13 key needs to be on a PC anytime you use it, which includes time of
14 generation and renewal. Typically this PC will be online.
16 > > So, maintaining this requirement with a Nitrokey means that we in
17 > > reality have the primary key online most of the time,
18 >
19 > Seeing as separating the primary and the signing key has been part of
20 > OpenPGP best practices for a long, long time, I have got highly mixed
21 > feelings about this statement. On the one hand, it is not reasonable to
22 > expect someone with no or minimal prior knowledge of OpenPGP to master
23 > it overnight. On the other, we are not just some random people from Teh
24 > Intarwebz and we *have* been using OpenPGP signatures on commits for
25 > quite a while now.
27 IMO this has nothing to do with knowledge, and everything with risk
28 tolerance and incentives.
30 Generating a key on a smartcard is practically a one-liner and is
31 convenient. It is also VERY secure.
33 Now, if you're going to have a completely offline PC that never gets
34 connected to the internet, and use that for key generation, and treat
35 any media used to transfer keys as if you're working on a classified
36 software project, then sure, that would be more secure. It is also a
37 LOT less convenient. I'd argue that most devs who understand how to
38 use GPG fairly well would not bother with this. I've never kept a
39 primary key offline and I was using PGP back when you had to be
40 located in the US to download it from the original official source.
42 >
43 > > when if it were the same as the signing key then both would be
44 > > offline in the Nitrokey.
45 >
46 > Using a hardware security device is not the same as making the key
47 > offline - especially given that the Gentoo NitroKey workflow as
48 > currently posted on the Wiki suggests disabling forcesig, which could
49 > effectively leave the signing private key unlocked for extended periods
50 > of time.
52 I'm all for revising this, but it isn't part of the GLEP. Maybe it should be.
54 A smartcard is a practical compromise. It gives a great deal more
55 security than online keys, while being convenient. Sure, it might not
56 be the most secure approach possible, but it is far more secure than
57 approaches most are likely to actually use, even if they know better
58 options exist.
60 >
61 > > Also, by generating the key outside the Nitrokey it is exposed to a
62 > > far higher risk of compromise.
63 >
64 > As Kristian has already mentioned, in principle one could keep the
65 > primary private key on a separate token.
67 Sure, though this is definitely more cumbersome, and not a one-liner
68 in gpg for sure. And last time I checked we're only issuing one
69 Nitrokey per dev, so it is unlikely many would do this.
71 >
72 > > In any case, I think it is far more likely that somebody generating
73 > > keys using software has a rooted box than somebody is going to come
74 > > up with a way to extract keys from a Nitrokey.
75 >
76 > You do not have to extract keys from a smartcard in order to be able to
77 > use keys physically present on it. All you have to do observe the
78 > smartcard user's PIN - either physically or using said rooted box - then
79 > nick the smartcard off them, ehich given that we are talking about keys
80 > that are supposed to be used on a regular basis might be very simple.
82 Sure, but this requires physical theft, which is a HUGE escalation of
83 effort. IMO the most likely attack is some script kiddie on the other
84 side of the planet.
86 I mean, somebody could steal my ID and get into my work and go cause a
87 mess. However this is extremely unlikely in practice.
89 If we were defending against the CIA or whatever I'd consider this a
90 more serious concern, but this isn't realistic, and we would need far
91 better standards to do that.
93 > Hell, if said smartcard contains the primary key you might even return
94 > it to them once you're done compromising them (e.g. by generating your
95 > own set of subkeys) and chances are pretty good that as long as
96 > everything keeps on working fine for them, it will take a quite a while
97 > before anyone notices.
99 I don't see how it differs whether the primary vs signing key is
100 stolen, unless you regenerate new signing keys frequently. If you
101 keep just re-extending expiry on your signing key then that stolen key
102 will work forever.
104 And if you do generate signing keys often then the window of
105 compromise is the same either way.
107 --
108 Rich