Question about redundant smartcard setup

[Andrew Gallagher]

On 19 Aug 2022, at 13:48, kho via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> 5. What is at the end the best way to setup 2 smartcards that can be
> used in encryption, signing and decryption? And additionally both
> smartscard should work, I have 2 smartcards for redundancy.

If you want the two smartcards to be redundant copies of each other, then they MUST contain exactly the same key material. It is possible to generate multiple signing/authentication subkeys that will be treated the same for practical purposes, since most software will try each valid sig/auth-capable (sub)key in turn during verification. There is no equivalent ability for encryption subkeys, as clients will encrypt to only the most recent valid encryption subkey. If you lose/break the smartcard with the only copy of an encryption subkey then there is no way to recover.

You can save the same key material to multiple smartcards using the gnupg command line interface:

1. Run gnupg and follow the usual process for generating (sub)keys, but “save” to save and exit before transferring subkeys to the smartcard. This ensures that you have a copy on disk before continuing.

2. Run gnupg again and copy the subkey(s) to the card, but afterwards you should say “quit” to exit *without* saving (not “save”). That way the subkeys will not be deleted from disk and you can use them again.

3. Repeat step 2 for the second (third, fourth,…) smartcard. Only choose “save” to save-and-exit after copying to the last smartcard, however be aware that “last” in this context really means “last”. No take-backs.

If you have to generate a new subkey for whatever reason (say you had to revoke the previous one) you must follow a similar save/quit sequence, remembering the order “run, generate, save, run, copy, quit, run, copy, quit, … run, copy, save"

To keep open the possibility of provisioning extra cards in the future, you could back up your entire .gnupg directory to a secure offline storage medium (such as an encrypted thumb drive) after generating the keys but before transferring to smartcard(s). Or you could perform the whole process of generating and managing your keys using a secure live system such as Tails with an encrypted persistent partition (remembering to “quit” after copying even the last time so that there is always a copy on disk). If you do either of these you only need one smartcard, so long as you don’t mind waiting for a replacement smartcard to arrive in the post if your original breaks.

On any given machine, gnupg will only ask for one smartcard. You should therefore consider one smartcard your working copy and one your emergency backup (if you have multiple machines, you could assign different primary cards to each machine). To force gnupg to ask for the other smartcard, you can delete the stub `.key` files under ~/.gnupg/private-keys-v1.d (on Linux/Mac, I forget the Windows equivalent). To work out which files to delete, incant `gpg -K --with-keygrip` and note the “Keygrip” lines under the three subkeys. Delete the corresponding `.key` files only, then plug in the replacement smartcard and incant `killall gpg-agent; gpg --card-status` (again Linux/Mac only). gnupg should now recognise the replacement card as the primary, and will ask consistently for that one until you repeat the process.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20220819/7076009b/attachment.sig>