Mailing List Archive

Hi, Recently I have been working with GPG and 2 smartcards (Yubikey). Despite some information here an there on internet, some things are still not clear to me. My setup has 1 master key with 6 subkeys, twice 3 keys for different purposes(A,E,S). So each smartcard will receive 3 keys. It works fine with Thunderbird and also with other tools: passwordstore (unix pass). Here some questions about particular situations: 1. In the passwordstore, I encrypted a few passwords, which are in fact just GPG files that store the passwords. When I want to decrypt them with the Yubikey, I receive the message: Please insert card with serial number. But what if I don't have that smartcard2 at hand? And how do I know that smartcard1 then really works , if it is never asked to insert smartcard1? I found a way to encrypt with smartcard1 via the option: -r <putkeyidofsmartcard1here>! . Smartcard1 seems to work fine. But then the question remains, suppose GPG asks for smartcard2 and smartcard2 is stolen. I can only provide smartcard1 and GPG asks for smartcard2. What to do? 2. Then some people suggest to use a different master key, but the goal was that both smartcards back each other up, in case one is broke. So that idea is not going to work, correct? 3. Also with different master keys, if I have sent a bunch of e-mails with smartcard1 and smartcard2. When one of the smartcards is broke , I will not be able to open those e-mails with the working smartcard? 4. Another approach is that I could for example have created just 3 subkeys (not 6) and copied all 3 to smartcard1 and again to smartcard2. I thought that having those subkeys separately is ideal, specially in a occasion were smartcard2 is stolen. Then I revoke the smartcard2 subkeys and keep on using the smartcard1 until I have ordered a new backup smartcard. Because some e-mails are sent encrypted (not so many), am I sure then when I revoke the subkey of smartcard2 that all e-mail will open with smartcard1? 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. On internet there are many blogs etc, but they never deal with the complete picture. Thanks in advance for your help. All the best!

On Fri, 19 Aug 2022 14:48, kho said:

> 4. Another approach is that I could for example have created just 3
> subkeys (not 6) and copied all 3 to smartcard1 and again to smartcard2.
> I thought that having those subkeys separately is ideal, specially in a
> occasion were smartcard2 is stolen. Then I revoke the smartcard2 subkeys

No need to. Save a paper copy of the keys before you remove them from
the disk. If both cards are broken you can still type the keys in and
create a new smartcard. Exact procedures depend on your threat model.


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

On 19 Aug 2022, at 13:48, kho via Gnupg-users <gnupg-users@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

Of course, you are right. I could store it digitally on a encrypted disk
and even on paper. And like you say they are not really gone. Thanks for
the tip.

On 8/19/22 15:21, Werner Koch wrote:
> On Fri, 19 Aug 2022 14:48, kho said:
>
>> 4. Another approach is that I could for example have created just 3
>> subkeys (not 6) and copied all 3 to smartcard1 and again to smartcard2.
>> I thought that having those subkeys separately is ideal, specially in a
>> occasion were smartcard2 is stolen. Then I revoke the smartcard2 subkeys
> No need to. Save a paper copy of the keys before you remove them from
> the disk. If both cards are broken you can still type the keys in and
> create a new smartcard. Exact procedures depend on your threat model.
>
>
> Salam-Shalom,
>
> Werner
>

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Thanks for this fast, complete and clear answer.

I am going to see if I can still pick up somewhere or just remove all I
did and start all over by following your steps.

This is the confirmation I needed! Thanks!

On 8/19/22 15:25, Andrew Gallagher wrote:
> On 19 Aug 2022, at 13:48, kho via Gnupg-users <gnupg-users@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
>

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On 19 Aug 2022, at 17:17, kho <skaainet@skynet.be> wrote:
>
> Thanks for this fast, complete and clear answer.
>
> I am going to see if I can still pick up somewhere or just remove all I
> did and start all over by following your steps.

Just a note of caution: since it is quite an involved process I would recommend keeping it as simple as possible at first, and trying it out with a test key before doing it in production. So long as you have a (tested!) offline backup you should be safe.

A

Yes, will do that. And the full chain from start to finish with a test
key. Deal.

On 8/19/22 16:25, Andrew Gallagher wrote:
> On 19 Aug 2022, at 17:17, kho <skaainet@skynet.be> wrote:
>>
>> Thanks for this fast, complete and clear answer.
>>
>> I am going to see if I can still pick up somewhere or just remove all I
>> did and start all over by following your steps.
>
> Just a note of caution: since it is quite an involved process I would
> recommend keeping it as simple as possible at first, and trying it out
> with a test key before doing it in production. So long as you have a
> (tested!) offline backup you should be safe.
>
> A
>

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users