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

Reply via email to