Gentoo Archives: gentoo-dev

From: Marek Szuba <marecki@g.o>
To: 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 11:58:04
In Reply to: Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard? by Rich Freeman
1 On 2019-04-24 20:34, Rich Freeman wrote:
3 > The only reason to have a separate primary key is to have an offline
4 > copy,
6 Not quite. First and foremost, you don not want to have an offline copy
7 of the primary private key - you want to have the primary ENTIRELY
8 offline. Secondly, the reason for that is not (just) to have a backup
9 but that the primary private key gives you virtually unlimited control.
10 Create pretty much any number of additional subkeys? Check. Assign
11 additional user IDs? Check. Change expiration dates? Check. And so on...
12 In short, having the primary private key compromised means A LOT of
13 trouble - and not just for the key owner either, the primary is also
14 used to sign other people's public keys so it could mess up other users'
15 trust databases.
17 > So, maintaining this requirement with a Nitrokey means that we in
18 > reality have the primary key online most of the time,
20 Seeing as separating the primary and the signing key has been part of
21 OpenPGP best practices for a long, long time, I have got highly mixed
22 feelings about this statement. On the one hand, it is not reasonable to
23 expect someone with no or minimal prior knowledge of OpenPGP to master
24 it overnight. On the other, we are not just some random people from Teh
25 Intarwebz and we *have* been using OpenPGP signatures on commits for
26 quite a while now.
28 > when if it were the same as the signing key then both would be
29 > offline in the Nitrokey.
31 Using a hardware security device is not the same as making the key
32 offline - especially given that the Gentoo NitroKey workflow as
33 currently posted on the Wiki suggests disabling forcesig, which could
34 effectively leave the signing private key unlocked for extended periods
35 of time.
37 > Also, by generating the key outside the Nitrokey it is exposed to a
38 > far higher risk of compromise.
40 As Kristian has already mentioned, in principle one could keep the
41 primary private key on a separate token.
43 > In any case, I think it is far more likely that somebody generating
44 > keys using software has a rooted box than somebody is going to come
45 > up with a way to extract keys from a Nitrokey.
47 You do not have to extract keys from a smartcard in order to be able to
48 use keys physically present on it. All you have to do observe the
49 smartcard user's PIN - either physically or using said rooted box - then
50 nick the smartcard off them, ehich given that we are talking about keys
51 that are supposed to be used on a regular basis might be very simple.
52 Hell, if said smartcard contains the primary key you might even return
53 it to them once you're done compromising them (e.g. by generating your
54 own set of subkeys) and chances are pretty good that as long as
55 everything keeps on working fine for them, it will take a quite a while
56 before anyone notices.
58 Conversely, even a software-generated primary key stored on a
59 software-encrypted USB stick might be more secure simply because with it
60 being only occasionally required, it can be stored somewhere hard to
61 access. You don't even need a vault (which, incidentally, is something I
62 have found people trying to make fun of crypto nerds mention a lot)
63 either - my personal experience has taught me that giving to a trusted
64 family member or friend who doesn't live with you is not a bad solution
65 either.
67 > Really the only thing we're missing with the Nitrokey is some form of
68 > attestation to ensure the keys are in fact generated on the device.
70 That would indeed be nice to have, unfortunately I do not think the
71 current hardware supports this. I know recent YubiKeys do but only in
72 PIV mode (i.e. for X.509).
74 On the other hand, vulnerabilities such as ROCA show clearly that
75 generating the private key on a smartcard does NOT necessarily make it
76 more secure than generating it in software, importing it into the
77 smartcard and wiping the original.
79 --
80 MS