Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

[Rich Freeman]

On Wed, Apr 24, 2019 at 11:57 AM Kristian Fiskerstrand <k_f@g.o> 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