Page MenuHome GnuPG

Smartcard interaction improvement (was: Shadowed private key design (for smartcard))
Closed, ResolvedPublic

Assigned To
Authored By
gniibe
Mar 23 2016, 2:12 AM
Tokens
"Love" token, awarded by GPF."100" token, awarded by lopter."Love" token, awarded by jheeb."Love" token, awarded by Esai.

Description

Shadowed key includes serial number of the smartcard, so that GnuPG can ask a
user about the specific card when signature/decryption will be asked (but not
yet the card is ready).

This is better to improve. (1) some people have a practice to put same private
key on multiple smartcards (say, for backup). (2) a user wants to migrate to
new card/token. (3) Most users don't care/know about serial number of smartcard
which is recorded in the shadowed key.

Event Timeline

I have two ideas on how to imrpove this:

  1. If an appropriate card is plugged in we could try to use it. This is similar to what we do in command-ssh.c
  1. Rework the private key file format to allow adding several serial numbers for one card. This rework needs to be done anyway for another features (OpenSSH certifcactes)

Yes, there are two things to implement; How gpg frontend use gpg-agent (1 in Werner's comment), and new shadowed key format support (2 in Werner's comment).

Considering again, I think that (2) is not that important. So, I am changing the title of this ticket. For this, it can be also done not using new private key format, but just only extend the shadowed information format. Now, it's "t1-v1". We can also support another format, say, "t1-v2".

The real part is (1), which requires changes in gpg. I think that this is somehow also needed in case of better support of encrypted data to anonymous.

In case of SSH, SSH asks gpg-agent for available card(s), and then, asks signing with a specific key on the card.

On the other hand, currently, gpg asks gpg-agent for signing/encryption with no information if the corresponding card is available now or not. It is gpg-agent which asks a user to insert matching card if not available.

This interaction should be changed; gpg should know current cards available, by asking gpg-agent, beforehand. And then, gpg should ask signing/decryption using the card. (It is still gpg-agent which asks a user to authenticate the card.)

It will be gpg for inserting card.

That's my thought, now. How about implementing this in GnupG 2.1?

gniibe renamed this task from Shadowed private key design (for smartcard) to Smartcard interaction improvement (was: Shadowed private key design (for smartcard)).Apr 14 2017, 3:54 AM
gniibe updated the task description. (Show Details)

litmus test will be :

  1. if "openpgp applet" were able to encrypt/sign using main token first then do the same with backup token containing same subkeys.
  2. on a new computer how to teach gpg that all these tokens with different serial numbers are the same? do we need to teach first before we use a backup key? or gpg will learn this on first encountering of backup key?
werner added a parent task: Restricted Maniphest Task.Dec 23 2019, 11:03 AM
gniibe changed the task status from Open to Testing.Jan 16 2020, 5:29 AM

In master, it has been implemented.

BTW, I just pushed some new features to maste for the gpg-card tool. You can now do

learn --cards --apps

and you get a list or S/Ns along with their active applications. The first application is the curently active one. To select another application you can for example do this on a Yubikey

learn - piv

and it switches to the PIV application and list info about it. The '-' can be replaced by the card number (first column in the list you get with the --cards) and you can immediately switch to an application on another card. I tried this with tqo Yubikeys and a Gnuk token; seems to work well.

Is there a blogpost or similar where the use of several smartcards following this improvement is explained to n00bs like me? :) For now all I find is this thread and some SE answers saying it does not work yet (https://security.stackexchange.com/questions/154702/gpg-encryption-subkey-on-multiple-smart-cards-issue) . If somebody could post a new answer on SE / write a small blog post or similar that would be great. Useful would be to have 1) from which versions and over is that available 2) how this works / how to use.

Hello,

Thank you for all the work! Does it mean that, if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

I believe so (the actual work was done until last year, and I've been using, some details are out of my brain).
Please try if possible.

Report on some testing using master:

  1. This feel unrelated to this issue but keytocard failed with You may only store a 1024 bit RSA key on the card for 4096 RSA keys to Yubikeys 4/5;
  2. I have been able to copy the same encryption/auth/signature private subkeys to multiple smartcards and swap freely between any of the smartcards to use those keys from the same GNUPGHOME where I imported the corresponding public keys.

Not sure about 1, but otherwise this issue is now solved as far as I am concerned!

This really simplifies key management for me, thank you very much for the work.

Note: xdotool(1) was a life saver to re-encrypt my pass repository and click through those prompts asking me for the correct smartcard.

Thank you for testing.
For the issue #1, I think it is the probelm of rG1cd615afe301: gpg,card: Allow no version information of Yubikey., which is fixed already. This was introduced by the support of PIV feature of Yubikey.

Thank you for testing.
For the issue #1, I think it is the probelm of rG1cd615afe301: gpg,card: Allow no version information of Yubikey.. This was introduced by the support of PIV feature of Yubikey.

Ok, not sure what to do about that, but I am happy to help testing and I am curious about the process/conditions to merge the fixes related to this issue into the stable branch?