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

[Rich Freeman]

On Thu, Apr 25, 2019 at 7:57 AM Marek Szuba <marecki@g.o> wrote:
>
> 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.

Agree, I could have said that better.  Though, to be clear the primary
key needs to be on a PC anytime you use it, which includes time of
generation and renewal.  Typically this PC will be online.

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

IMO this has nothing to do with knowledge, and everything with risk
tolerance and incentives.

Generating a key on a smartcard is practically a one-liner and is
convenient.  It is also VERY secure.

Now, if you're going to have a completely offline PC that never gets
connected to the internet, and use that for key generation, and treat
any media used to transfer keys as if you're working on a classified
software project, then sure, that would be more secure.  It is also a
LOT less convenient.  I'd argue that most devs who understand how to
use GPG fairly well would not bother with this.  I've never kept a
primary key offline and I was using PGP back when you had to be
located in the US to download it from the original official source.

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

I'm all for revising this, but it isn't part of the GLEP.  Maybe it should be.

A smartcard is a practical compromise.  It gives a great deal more
security than online keys, while being convenient.  Sure, it might not
be the most secure approach possible, but it is far more secure than
approaches most are likely to actually use, even if they know better
options exist.

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

Sure, though this is definitely more cumbersome, and not a one-liner
in gpg for sure.  And last time I checked we're only issuing one
Nitrokey per dev, so it is unlikely many would do this.

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

Sure, but this requires physical theft, which is a HUGE escalation of
effort.  IMO the most likely attack is some script kiddie on the other
side of the planet.

I mean, somebody could steal my ID and get into my work and go cause a
mess.  However this is extremely unlikely in practice.

If we were defending against the CIA or whatever I'd consider this a
more serious concern, but this isn't realistic, and we would need far
better standards to do that.

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

I don't see how it differs whether the primary vs signing key is
stolen, unless you regenerate new signing keys frequently.  If you
keep just re-extending expiry on your signing key then that stolen key
will work forever.

And if you do generate signing keys often then the window of
compromise is the same either way.

-- 
Rich