[gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards

[gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards

[Rich Freeman]

The OpenPGP smartcard standard, and the Nitrokey Pro smartcards that
are being distributed to Gentoo developers, do not support having a
separate primary/signing key for keys that are generated on the cards.
As a result they can only be used in accordance with our current
requirements if the keys are generated in software, which places them
at a higher risk of compromise.

The intent of the separate primary key is to reduce the risk of it
being compromised by keeping it offline.  However, if it were
generated on a smartcard it would be exclusively be maintained
offline, so it is counterproductive to require that it be generated
online and then recommend that it be kept offline after this.
Additionally this key needs to be brought back online anytime the key
expiration is updated, which is at least annually.

I believe this is creating a false sense of security, and that
developers should be encouraged to generate new keys using their
smartcards, so that these keys are never stored outside the protected
hardware.  By default gpg creates revocation certificates at this time
as well.  If a key is lost it can still be revoked, and of course the
gpg fingerprint associated with the developer can be changed in any
case and is the de-facto root of our trust system.  These failure
modes really are no different from an offline primary key that is
separate from the signing keys.

The revision adds an exception for keys generated on a smartcard.  It
does not prohibit those who wish to have separate keys from doing so,
though doing this with card-generated keys requires having two
smartcards.

An obvious objection I can see is that nobody will be able to tell
whether any particular key was generated on a smartcard or not.  While
this is true, it is also the case that there is no way to verify that
a primary key is being stored offline, or used on a non-compromised
PC, or that it even has a passphrase set.  Unless we want to use some
kind of hardware key that supports remote attestation we're going to
have to trust developers to be security conscious, and IMO making it
easy to generate keys on smartcards actually will facilitate security.
This change actually makes the more secure mode of operation simpler
than the less secure one (unless the primary key is kept online, in
which case it provides no benefit).

Full version online at:
https://gist.github.com/rich0/7d11e2297d8b8a5586997baec2a99e30

Patch follows:


diff --git a/glep-0063-v3.rst b/glep-0063-v3.rst
index 5895873..86e5fd9 100644
--- a/glep-0063-v3.rst
+++ b/glep-0063-v3.rst
@@ -12,6 +12,12 @@ OpenPGP key management policies for the Gentoo
Linux distribution.
 Changes
 =======

+v3
+  The requirement to have a separate signing and primary key was removed
+  in the case of keys generated/stored on smartcards, to encourage the use
+  of these keys, and acknowledging that the main use case for a separate
+  primary key is largely fulfilled by having all the keys stay offline.
+
 v2
   The distinct minimal and recommended expirations have been replaced
   by a single requirement. The rules have been simplified to use
@@ -69,7 +75,8 @@ not be used to commit.
    at least 256-bit.  All subkey self-signatures must use this digest.

 2. Signing subkey that is different from the primary key, and does not
-   have any other capabilities enabled.
+   have any other capabilities enabled.  This requirement does not apply
+   if the primary key was generated on a smartcard.

 3. Primary key and the signing subkey are both of type EITHER:


-- 
Rich

Re: [gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards

[Marek Szuba]

On 2019-04-25 12:32, Rich Freeman wrote:

> The OpenPGP smartcard standard, and the Nitrokey Pro smartcards that
> are being distributed to Gentoo developers, do not support having a
> separate primary/signing key for keys that are generated on the cards.
> As a result they can only be used in accordance with our current
> requirements if the keys are generated in software, which places them
> at a higher risk of compromise.
> 
> The intent of the separate primary key is to reduce the risk of it
> being compromised by keeping it offline.  However, if it were
> generated on a smartcard it would be exclusively be maintained
> offline, so it is counterproductive to require that it be generated
> online and then recommend that it be kept offline after this.
> Additionally this key needs to be brought back online anytime the key
> expiration is updated, which is at least annually.
> 
> I believe this is creating a false sense of security, and that
> developers should be encouraged to generate new keys using their
> smartcards, so that these keys are never stored outside the protected
> hardware.  By default gpg creates revocation certificates at this time
> as well.  If a key is lost it can still be revoked, and of course the
> gpg fingerprint associated with the developer can be changed in any
> case and is the de-facto root of our trust system.  These failure
> modes really are no different from an offline primary key that is
> separate from the signing keys.
> 
> The revision adds an exception for keys generated on a smartcard.

I very much oppose this change, see my comments in the "Best way to
create a GLEP 63 compliant GPG key on Nitrocard?" thread for details.

Regarding the very accurate comment that requiring a separate primary
key does not guarantee said primary key is handled securely - I know it
might be overly optimistic of me but I kind of expect developers of a
mainstream Linux distribution to be able to grasp and follow OpenPGP
best practices.

Incidentally, having been using smartcards of various sort in my
workflows for 5+ years now I find their most obvious benefit is not that
they store crypto keys securely but that they make the use of keys *more
convenient*. Worried about persistence of the private key on your drive,
especially on a shared system? Remove the card and the key is
inaccessible, and since it was never handled by the system itself there
should be no traces of it even in RAM. Fed up with resetting user
passwords being a significant part of your sysadmin duties due to some
people seemingly being unable to retain "at least 16 characters long and
a minimum 3 character classes" in their wetware? Smartcard PINs can be
much shorter because smartcards can lock up after a fairly small number
of having entered the PIN wrong. In fact, although the official Gentoo
rationale for the use of Nitrokeys as stated on the relevant Wiki page
is that it makes the signing keys more secure, the recommendation to
disable forcesig does hint at the ease-of-use factor as well.


-- 
MS

Re: [gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards

[Mikle Kolyada]

[-- Attachment #1.1: Type: text/plain, Size: 1579 bytes --]



On 25.04.2019 14:32, Rich Freeman wrote:
> [snip]

> Patch follows:
>
>
> diff --git a/glep-0063-v3.rst b/glep-0063-v3.rst
> index 5895873..86e5fd9 100644
> --- a/glep-0063-v3.rst
> +++ b/glep-0063-v3.rst
> @@ -12,6 +12,12 @@ OpenPGP key management policies for the Gentoo
> Linux distribution.
>  Changes
>  =======
>
> +v3
> +  The requirement to have a separate signing and primary key was removed
> +  in the case of keys generated/stored on smartcards, to encourage the use
> +  of these keys, and acknowledging that the main use case for a separate
> +  primary key is largely fulfilled by having all the keys stay offline.
> +
>  v2
>    The distinct minimal and recommended expirations have been replaced
>    by a single requirement. The rules have been simplified to use
> @@ -69,7 +75,8 @@ not be used to commit.
>     at least 256-bit.  All subkey self-signatures must use this digest.
>
>  2. Signing subkey that is different from the primary key, and does not
> -   have any other capabilities enabled.
> +   have any other capabilities enabled.  This requirement does not apply
> +   if the primary key was generated on a smartcard.
>
>  3. Primary key and the signing subkey are both of type EITHER:
>
>
>
I strongly disagree with this change. If you generated your keys
straight on the device you are not able to make a backup later.
The best practice here is to have a separate USB stick that is never
used for purposes other than private keys storing.
Also paperkey backups should serve as the last resort.





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [PATCH] glep-0063: Allow a single primary/signing key for smartcards

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

On Thu, 2019-04-25 at 07:32 -0400, Rich Freeman wrote:
> The intent of the separate primary key is to reduce the risk of it
> being compromised by keeping it offline.  However, if it were
> generated on a smartcard it would be exclusively be maintained
> offline, so it is counterproductive to require that it be generated
> online and then recommend that it be kept offline after this.
> Additionally this key needs to be brought back online anytime the key
> expiration is updated, which is at least annually.

You seem to be using 'offline' in two different meanings here.  Yes,
smartcard technically prevents the PC from *reading* the secret key
material.  However, it isn't really 'offline' as the PC can *use*
the secret key material.

In the scenario of Gentoo development, the primary use of the 'signing
slot' key is to sign commits, pushes and messages, a lot.  This means
that for practical reasons you need to disable 'forcesig', or you'll
have to repeatedly enter PIN for every commit made, for every message
sent and twice for every push.  If you include the extra delay due to
that, and the necessity of rebasing, you may end up being unable to
commit otherwise.

Now, the smartcard can't (or doesn't -- I haven't looked into
the details) distinguish the signing usage vs certification usage.
In other words, once you unlock the key e.g. to sign a commit, any
program can freely use the card to sign any key or subkey, without even
raising your suspicion.

To summarize, there is still a major benefit to keeping the primary key
offline -- as in, not normally accessible to the system.  Whether you do
it via keeping the key on an offline system, on a dedicated smartcard
that is normally disconnected or in a dedicated smartcard slot that
requires PIN for *every* certification made, doesn't matter that much. 
However, when you open it to direct abuse when using it to sign commits,
it is not 'offline'.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]