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

[Marek Szuba]

On 2019-04-24 20:34, Rich Freeman wrote:

> The only reason to have a separate primary key is to have an offline
>  copy,

Not quite. First and foremost, you don not want to have an offline copy
of the primary private key - you want to have the primary ENTIRELY
offline. Secondly, the reason for that is not (just) to have a backup
but that the primary private key gives you virtually unlimited control.
Create pretty much any number of additional subkeys? Check. Assign
additional user IDs? Check. Change expiration dates? Check. And so on...
In short, having the primary private key compromised means A LOT of
trouble - and not just for the key owner either, the primary is also
used to sign other people's public keys so it could mess up other users'
trust databases.

> So, maintaining this requirement with a Nitrokey means that we in
> reality have the primary key online most of the time,

Seeing as separating the primary and the signing key has been part of
OpenPGP best practices for a long, long time, I have got highly mixed
feelings about this statement. On the one hand, it is not reasonable to
expect someone with no or minimal prior knowledge of OpenPGP to master
it overnight. On the other, we are not just some random people from Teh
Intarwebz and we *have* been using OpenPGP signatures on commits for
quite a while now.

> when if it were the same as the signing key then both would be
> offline in the Nitrokey.

Using a hardware security device is not the same as making the key
offline - especially given that the Gentoo NitroKey workflow as
currently posted on the Wiki suggests disabling forcesig, which could
effectively leave the signing private key unlocked for extended periods
of time.

> Also, by generating the key outside the Nitrokey it is exposed to a
> far higher risk of compromise.

As Kristian has already mentioned, in principle one could keep the
primary private key on a separate token.

> 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.

You do not have to extract keys from a smartcard in order to be able to
use keys physically present on it. All you have to do observe the
smartcard user's PIN - either physically or using said rooted box - then
nick the smartcard off them, ehich given that we are talking about keys
that are supposed to be used on a regular basis might be very simple.
Hell, if said smartcard contains the primary key you might even return
it to them once you're done compromising them (e.g. by generating your
own set of subkeys) and chances are pretty good that as long as
everything keeps on working fine for them, it will take a quite a while
before anyone notices.

Conversely, even a software-generated primary key stored on a
software-encrypted USB stick might be more secure simply because with it
being only occasionally required, it can be stored somewhere hard to
access. You don't even need a vault (which, incidentally, is something I
have found people trying to make fun of crypto nerds mention a lot)
either - my personal experience has taught me that giving to a trusted
family member or friend who doesn't live with you is not a bad solution
either.

> 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.

That would indeed be nice to have, unfortunately I do not think the
current hardware supports this. I know recent YubiKeys do but only in
PIV mode (i.e. for X.509).

On the other hand, vulnerabilities such as ROCA show clearly that
generating the private key on a smartcard does NOT necessarily make it
more secure than generating it in software, importing it into the
smartcard and wiping the original.

-- 
MS