Best practice to use several smartcards for a single key?

Ingo Klöcker kloecker at kde.org
Sat Dec 12 18:45:46 CET 2020


On Samstag, 12. Dezember 2020 16:29:55 CET Nicolas Boullis wrote:
> Since the smartcard that held all my subkeys died, I have to replace my
> subkeys, and I’m willing to store them on several smartcards, just in
> case I am unlucky again…
> 
> I wonder whether I should the same subkey or different subkeys on
> different smartcards.

I see little reason for setting up a second smartcard for subkeys as disaster 
recovery backup for the first smartcard. Reasoning below:

> As far as I understand it, for encryption, if I have several encryption
> subkeys, people who send me encrypted messages will encrypt for single
> subkey.

Yes, unless they explicitly specify multiple subkeys gpg will use the most 
recently created valid encryption subkey.

> Hence, if I want to be able to decrypt the message with any
> smartcard, then I have to use a single subkey that is held by all
> smartcards.

Yes, but why a second smartcard? The reason for making a backup of the 
encryption (sub)key is that this will allow you to decrypt messages even if 
the smartcard dies. But if your second smartcard also dies, then all is lost 
... unless you have an off-card backup of the private encryption key. But this 
off-card backup would allow you to create a new smartcard _after_ the first 
smartcard dies. So, instead of setting up two smartcards with identical 
encryption keys I suggest to save the money for the second smartcard and 
instead create an off-card backup of the private encryption key that you store 
somewhere safe (see Erich's mail).

> As for signature subkeys, as I understand it, there is no problem with
> using several distinct subkeys, so I can sign with the one that is
> available, and people who verify the signature will accept any subkey.
> Moreover, if a smartcard is lost/stolen, I can revoke its signature
> subkey.

Yes, but what purpose serves the second smartcard? Again, you can easily setup 
a replacement smartcard _after_ the first smartcard dies. Typically, you would 
create the signature (sub)key on-card to avoid any risk of compromise of the 
private key.

> As for the authentication subkeys (that I use for SSH connection), it
> behaves like the signature subkeys, except that I have to explicitly
> allow each subkey on all machine that I want to connect to.

Yes, for the authentication use case setting up a second smartcard does make 
sense because otherwise you'd lose access to the machines if the first 
smartcard dies. But you could as well keep an off-card backup of the 
authentication key. Or you could create a second "master" authentication key 
off-card and store it somewhere safe. One argument for using a second 
smartcard instead is to avoid any risk of compromise of the private 
authentication keys.

> As a bonus question: given that my “master” private key is also stored
> on a smartcard, is there a way to ask GnuPG to generate a signature
> subkey on a second smartcard, while signing it with the first smartcard?

Yes, but only with the unreleased development version of GnuPG. With 2.2.25 
trying to add a subkey from an existing key from card failed here. There have 
been quite some fixes with regard to smartcard support in the development 
version in the last few weeks.

What I did:
Remove the first smartcard. Insert the second smartcard. Then
$ gpg --edit-key master at example.net
gpg (GnuPG) 2.3.0-beta1490; Copyright (C) 2020 Free Software Foundation, Inc.
[...]
sec  ed25519/B16F599516474ABA
     created: 2020-08-03  expires: 2022-08-03  usage: SC  
     card-no: [s/n of first card]
     trust: ultimate      validity: ultimate
sub  cv25519/2BBE9540CAF56DC9
     created: 2020-08-03  expires: never       usage: E   
[ultimate] (1). master at example.net

gpg> addkey
Secret parts of primary key are stored on-card.
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
  (10) ECC (sign only)
  (12) ECC (encrypt only)
  (14) Existing key from card
Your selection? 14
Serial number of the card: D2760001240100000006090745820000
Available keys:
   (1) 930509C5F5BD42B2ABCB4C7BDC2FD64BE59086CE OPENPGP.1 rsa2048 (cert,sign*)
   (2) AEA62514505EBDDB4C2FF8AF27B02F221ECAFBCE OPENPGP.2 rsa2048 (encr*)
   (3) 56EBCBEEA72DBF1BFAFE583F7FF36CBCB895C265 OPENPGP.3 rsa2048 (sign,auth*)
Your selection? 1
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 
Key does not expire at all
Is this correct? (y/N) y
Really create? (y/N) y
-> "Please insert the card with serial number: [s/n of first card]"
-> "Please unlock the card" [s/n of first card]
-> "Please unlock the card" [s/n of second card]

sec  ed25519/B16F599516474ABA
     created: 2020-08-03  expires: 2022-08-03  usage: SC  
     card-no: [s/n of first card]
     trust: ultimate      validity: ultimate
sub  cv25519/2BBE9540CAF56DC9
     created: 2020-08-03  expires: never       usage: E   
ssb  rsa2048/06B697821DAABF4B
     created: 2020-12-04  expires: never       usage: S   
     card-no: [s/n of first [sic] card] <-- This is a bug.
[ultimate] (1). master at example.net

gpg> save

Now let's try to sign (and immediately verify) something.
$ gpg --clearsign | gpg --verify
bla
^D
-> "Please insert the card with serial number: [s/n of first [sic] card]"
-> I insert the second (!) card
-> "Please unlock the card" [s/n of second card]
gpg: Signature made Sa 12 Dez 2020 18:35:47 CET
gpg:                using RSA key AF440A8368A6C258DB22AC2C06B697821DAABF4B
gpg: Good signature from "master at example.net" [ultimate]

-> Success!

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20201212/c393a049/attachment.sig>


More information about the Gnupg-users mailing list