Mailing List Archive

Best practice to use several smartcards for a single key?
Hi,

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.

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

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.

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.

Any opinion on this?


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?
Or do I have to first generate it in software and sign it with the first
smartcard, and then export it to the second smartcard?


Best regards,

--
Nicolas

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice to use several smartcards for a single key? [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, 12 Dec 2020, Nicolas Boullis wrote:

> Hi,

Hi Nicolas,

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

[ ... snip ... ]

> Any opinion on this?

Sry to not answer your question(s), but: I believe, the common way is to
use *one* smart card and backup the keys on paper (or any other offline
storage, like a usb thumb drive lying in some shoe box).

[ ... snip ... ]

> Best regards,
>
> --
> Nicolas

regards,
Erich

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl/U6e4ACgkQCu7JB1Xa
e1r4qQ//Ykkk7x83Hkq+AJuxtTVkh1HWtSR9DrgDboKSz693uJvkpL4ISIG/xnsn
oSqePGtQ0ZcspnF0+vLTjCku8RyJUKf1XCUcq+n/iMqfJBp3hpzMhQm77/IRe/rj
O5AtINfq2cYPcVHjTh3/MvUJoW6nkwW4LCCjg/7rxvQhKtqOX+SkD/x9XvCm4cMP
PPU/Awb6Kpj8rwaXQJCFyLTYHdWGjIBIZFrevi9yhjCoFDHxMVwtlRHEX0r/GK5A
b8CdV1wQE1mMX0tLYrEjPhwwIjQ/EEYQytaNEkIZ5I8Sbt+RgwSfHrjRealHQpwr
aedwHyklpRpX4glQqzEiV5AYmadLQ+1V+KDUUO7texKoVmRyn8xOqAMbC659mYiw
p5v8uE+mCu7V8WRBiDF0c0yk88Tplrkz3tRxRRToXAByqqQf7wAYBhTdP9wnMW++
nnzmpnhY7TZ0Vh43/fc1CjULYb0tOrMSxuCq9jHKwrGI0fg3ED9zpq+ZZR/ZzkF2
24phqnA8PuSLEQ0yK11ZRjpQcH64a9Fb5KTm7dwgVQFU3dnsacYdHGw4qVVYD+CI
GYsaLCuioUar9jTgBp+4sfDPb79rBbnMJFDPUKeXZT+r/M8cmM+HP3nYPNi54Viv
KPQXTeHpihWFRLjlIpPLLdIj0Cto2l+ZwkoXDja7uKQhyxQZtxk=
=kZaw
-----END PGP SIGNATURE-----
Re: Best practice to use several smartcards for a single key? [ In reply to ]
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@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@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@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@example.net" [ultimate]

-> Success!

Regards,
Ingo
Re: Best practice to use several smartcards for a single key? [ In reply to ]
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@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@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@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@example.net" [ultimate]
>
> -> Success!

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


Cheers,

--
Nicolas

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice to use several smartcards for a single key? [ In reply to ]
On Sonntag, 13. Dezember 2020 12:06:21 CET Nicolas Boullis wrote:
> > > 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@example.net
[...]
> > -> "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?

Both cards were inserted after I was asked to insert the first card. I have
not tried the above with both cards inserted from the start. Even if it works,
I think it's easier if at first you only insert the second card (i.e. the card
with the key you want to add as signing subkey) because it will make the
selection of the key from the list of available keys easier.

> > -> "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?

The request to enter a certain card is merely a hint (in this case a bogus
hint) for the user. gpg will look for the key on any inserted card regardless
of what card it asked for. The key is uniquely identified by its keygrip (use
--with-keygrip to see it on --list[-secret]-keys), the s/n of the card doesn't
matter.

> Can’t you then fix this by deleting the stub and then learning the
> second card?

Maybe, but I'd rather make sure that the bug is fixed. ;-)

Regards,
Ingo
Re: Best practice to use several smartcards for a single key? [ In reply to ]
> On 13 Dec 2020, at 11:08, Nicolas Boullis <nicolas.boullis@ecp.fr> wrote:
>
> 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.

How are you going to decrypt the old files if your old smartcard is already dead? If you don’t want to lose all access to your encrypted files, you *must* keep a backup of your encryption key material at the very least. There is no recovering from a deleted encryption private key.

I keep my key material on a Tails encrypted partition in a safe place. Alternatively you could keep a paper backup in a safe place. But there’s no getting around having some form of backup. What amounts to a “safe place” depends on your threat model of course...

A
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practice to use several smartcards for a single key? [ In reply to ]
>
> Date: Sun, 13 Dec 2020 21:22:44 +0000
> From: Andrew Gallagher <andrewg@andrewg.com>
> Message-ID: <9AE37DA2-0E50-46CD-8F16-05C4D55B3BDF@andrewg.com>
>
>
> > On 13 Dec 2020, at 11:08, Nicolas Boullis <nicolas.boullis@ecp.fr>
> wrote:
> >
> > 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.
>
> How are you going to decrypt the old files if your old smartcard is
> already dead? If you don?t want to lose all access to your encrypted files,
> you *must* keep a backup of your encryption key material at the very least.
> There is no recovering from a deleted encryption private key.
>
> I keep my key material on a Tails encrypted partition in a safe place.
> Alternatively you could keep a paper backup in a safe place. But there?s no
> getting around having some form of backup. What amounts to a ?safe place?
> depends on your threat model of course...
>
> A
>
>
Don't know whether you've considered USB security tokens, but you might
find them less likely to 'die' than smartcards. Once you put your private
key in one of the Nitrokey security-token products, it's supposed to be
impossible to extract the key (not sure whether the same is *as much* true
with the smartcards you are considering).

I agree with Nicolas Boullis, that using duplicate smartcards (or USB
security tokens) might be preferred for back-up purposes. If on the other
hand, you want to back-up your private key in the more conventional way
suggested by Andrew Gallagher, and you are worried about adversaries
gaining access to your backup, you might want to do something like
splitting the key into several parts, and then backing-up each of the parts
with a different friend/colleague, perhaps each of whom is located very far
away from the others: see Shamir's Secret Sharing
<https://en.wikibooks.org/wiki/End-user_Computer_Security/Main_content/Passwords_and_digital_keys#Shamir's_Secret_Sharing>
.


Kind regards,


Mark Fernandes