On Wed, Apr 24, 2019 at 11:57 AM Kristian Fiskerstrand <k...@gentoo.org> wrote: > > On 4/24/19 4:19 PM, Rich Freeman wrote: > > If it is the case that Nitrokeys can't support a separate primary key, > > I'd suggest modifying the GLEP to remove that requirement when a > > smartcard is in use. Its main purpose is to keep a key component > > offline, and if the key is generated on the card that is already > > accomplished. Maybe somebody has a suggestion for how to make the two > > work together, otherwise I'll go ahead and suggest a GLEP revision for > > the next Council meeting. > > > The GLEP should not be changed on the requirement for distinct signing > subkey, this is one of the expected results of it to begin with.
So, I intend to propose this. Council is welcome to vote it down. However, I'm really interested in what the concern is here. The only reason to have a separate primary key is to have an offline copy, but it is not a current requirement that it be kept offline, and I suspect that 99% of devs won't keep it offline, and of course there is no way to verify if this is being done anyway. So, maintaining this requirement with a Nitrokey means that we in reality have the primary key online most of the time, when if it were the same as the signing key then both would be offline in the Nitrokey. This requirement effectively makes the key less secure in practice. It doesn't matter if the signing key is safely stored in the Nitrokey if somebody can steal the primary key, since they can just create a new signing key at will. Also, by generating the key outside the Nitrokey it is exposed to a far higher risk of compromise. At best for the 1% of devs who would actually keep the primary key offline then this achieves the same level of security you have with the Nitrokey anyway, which always keeps its keys offline (effectively). The only exception to this would be an exploit in the Nitrokey, which seems like a pretty low risk. And of course it is only a risk when the Nitrokey is plugged in, and the intent would be for devs to only plug it in when working on commits. In any case, I think it is far more likely that somebody generating keys using software has a rooted box than somebody is going to come up with a way to extract keys from a Nitrokey. Now, I think it is a great best practice which we should support for anybody who wants to have their offline key-generation machine they keep in a vault or whatever. And by all means require the additional key when using keys not generated on a Nitrokey. As to how you can tell which are which, I'd simply point out that you can't tell if keys are being stored offline or not, so really your risk is unchanged in taking devs at their word. I think most companies issuing these sorts of tokens to users would generate their keys on the tokens for these very reasons. The reason they're using these hardware tokens is because they know that users in practice will not take extraordinary care to protect keys, and the token provides a similar level of security with very little inconvenience. Really the only thing we're missing with the Nitrokey is some form of attestation to ensure the keys are in fact generated on the device. -- Rich
