Long Term Key Management With Hardware Tokens

[Brandon Anderson]

Hey everyone,

I have a question regarding using secure hardware such as 
Yubikey/Nitrokey, GPG smartcards, and the handling of encryption key 
rotation and replacement. I currently have a GPG key with a 4096 bit RSA 
key generated on a GPG smart card version 2.1. I have recently acquired 
two Yubikey 5's, both of which support curve25519. It is unclear if 
version 3.4 of the GPG smart card supports this curve, but if it does, I 
would be interested in using it as well. As I am looking to generate a 
new key that uses the curve25519, I was trying to plan out how I should 
handle key management and revocation. I was thinking that sub-signing 
keys could be generated on the secure hardware and a sub decryption key 
could be generated and imported onto each of these devices with an 
air-gapped system. Then the non-secure copy of the key is destroyed. 
Ideally, these subkeys would only ever exist on the secure hardware. 
When either a token is lost, a new one is added, or enough time has 
passed that I want to roll the keys, I would revoke the subkey in use, 
generate a new one via the same process and add it to the security 
tokens in use.

The problem, of course, comes when I need to decrypt old messages signed 
with the revoked key or if someone at a later point sends an encrypted 
message to the revoked key. Ideally, I would keep one security token 
that is assigned the encryption subkey simultaneously as the others 
before it is destroyed from the computer.This token's job would be to 
store historic encryption keys if I ever needed to decrypt messages with 
the older encryption keys. PIV smartcards, including the Yubikey 
implementation, support Slots 82-95: Retired Key Management which is 
specifically built for the purpose of key rotation while letting a user 
store many old encryption keys before they need to acquire new hardware. 
As neat as this is, the GPG smart card implementations seem to offer no 
such similar feature. The GPG keys on the smartcards seem specialized 
specifically for the type of key, be it signing or encryption; you cant 
even store 3~4 encryption keys per card. Is there a proper way to do 
this similar to the PIV retired key management scheme? Most people say 
to just backup offline the encryption keys. Still, I feel like security 
is lost if that key is ever recoverable in a form other than the secure 
hardware (e.g., it somehow leaks, resulting in old messages being able 
to be decrypted). Is there a reason the GPG smart card system does not 
have retired key slots as part of the design? How is one supposed to 
best go about this without getting new cards everytime you rotate 
encryption subkeys?

Sincerely,

Brandon Anderson

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x255837AEF812E87E.asc
Type: application/pgp-keys
Size: 9076 bytes
Desc: OpenPGP public key
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210620/bab37fdf/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210620/bab37fdf/attachment-0001.sig>