Best practice to use several smartcards for a single key?

Sun Dec 13 12:06:21 CET 2020

Hi,

Thanks to you and Erich for your answers.

On Sat, Dec 12, 2020 at 06:45:46PM +0100, Ingo Klöcker wrote:
> 
> > 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.

I guess I hould better not expect others to do so. ;-)

> 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).

To be honnest, I don’t feel comfortable with storing an off-card backup 
of my private encryption card. My inner feeling is that it defeats the 
point of using a smartcard: if someone finds it, it can easily be copied 
(without me knowing it was copied) and it is protected with a passphrase 
with limited entropy (because I can’t remember a random 128-bit number).

My idea was that there was little chance that a smartcard fails (Werner 
Koch told me that the failure I experienced was exceptionnal) and if it 
does I can set up a new encryption key and, using the second smartcard, 
decrypt all the files that were encrypted for the old key and re-encrypt 
them for the new key.

Another idea would be to encrypt the off-card backup of the encryption 
key with the encryption key. I think it would be safer than having it 
protected with a passphrase. Then, if a smartcard fails, I get a new 
one, and then use the second smartcard to decrypt the off-card backup 
and then send it to the new card.

> 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.

I agree that there is no problem with creating a replacement signature 
subkey after the previous one failed. But if I use two smartcards to 
store the encryption subkey, I think I should better use both (so I can 
detect if one fails), and then it seems to me it would be more 
comfortable to also have a sigature subkey on each.

> > 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]

Do these step work if I have both cards inserted (in 2 readers) or would 
I have to remove one card to insert the other one?

> 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

Hmmm… That’s a funny bug…
You mean gnupg asks for the first card, but it needs and accepts the 
second one?
Just curious, do you know how this is possible?
I might understand that it could store the wrong s/n is the subkey stub, 
but why does it accept the card whose s/n does not match?

Can’t you then fix this by deleting the stub and then learning 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!

Thanks for the explanation about that incoming feature. It looks great! 
:-)

Cheers,

-- 
Nicolas