Handling multiple subkeys on two SmartCards
Testing, LowPublic


One primary pgp key with two pgp subkeys - more exact, two distinct auth&signing (let's call them A1, S1 and A2, S2) keys, and one common encryption key (let's call em E) - using gpg2.

Hence the end-state of this setup shall be:

SC1 contains A1,S1,E
SC2 contains A2,S2,E

Writing the keys to the cards works fine:

Stage 1: Insert SC1, keytocard A1&S1, backup keystore, keytocard E
Stage 2: Insert SC2, restore keystore, keytocard A2&S2, keytocard E

The KeyGrips are different, so I'd expect gpg to ask for the correct card, but: After SC2 is written, the pgp db seems screwed up: it shows that ALL 5 subkeys are on SC2.

Thanks in advance,

Versions (on Fedora 29):
gpg (GnuPG) 2.2.11
libgcrypt 1.8.4

kaspro created this task.Dec 23 2018, 5:01 AM
gniibe claimed this task.Dec 27 2018, 4:30 AM
gniibe triaged this task as Normal priority.

Is it an issue when you share an decryption key E among two smartcards?
I think that when there are six distinct keys (three subkeys for one smartcard each), it works fine.
I'll try to make reproducible test case.

For my test, six distinct keys (three subkeys for each smartcard) works fine.
IIUC, you try to use same decryption key by two smartcards. Currently, it is not supported.

Please show us your output of gpg --card-status for each card, and tell us the reason why you think "the pgp db seems screwed up".

That's exactly the point: I do want one common encryption key between the two cards: So I can distinguish between the two, but en-/decrypt with both.
One is on the GnuPG SmartCard, the other on a YubiKey - output --card-status (some things xxx'ed out) :

SC1 (GnuPG SC):

Application ID ...: D276000xxx
Version ..........: 2.1
Manufacturer .....: ZeitControl
Serial number ....: 00005xxx
Name of cardholder: My Name
Language prefs ...: de
Sex ..............: male
URL of public key : [not set]
Login data .......: myLogin
Private DO 1 .....: [not set]
Private DO 2 .....: [not set]
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: xxxx FA81
      created ....: 2018-09-20 08:01:32
Encryption key....: xxxx B3BD
      created ....: 2018-09-20 08:02:52
Authentication key: xxxx A2AB
      created ....: 2018-09-20 08:02:06
General key info..: [none]

SC2 (YubiKey SC):

Application ID ...: D276000xxx
Version ..........: 2.0
Manufacturer .....: unknown
Serial number ....: 07326xxx
Name of cardholder: My Name
Language prefs ...: de
Sex ..............: male
URL of public key : [not set]
Login data .......: myLogin
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: xxxx F7A7
      created ....: 2018-09-20 08:03:16
Encryption key....: xxxx B3BD
      created ....: 2018-09-20 08:02:52
Authentication key: xxxx 7203
      created ....: 2018-09-20 08:03:45
General key info..: [none]

Why I think it's screwed up: because, as mentioned in the post above, it shows that all subkeys are on SC2 - instead of them being divided between the two of them.
Hence, to be able to use SC1 as "default", I need to restore the .gnupg directory to the state before writing to SC2.

If anything fails: is there any way to manually adjust the database (to adjust which keys are on which card)?

Thanks in advance, Chris

I would have thought this is a logical usage for gpg cards - seems this is harder to achieve as I thought.

It would be really helpful to at least have a way to manually adjust the database (or some other configuration file) - to adjust which keys are on which card / used for what.

Any hints on this front? Thanks!

Hello again - can I ask about the status? Or should I consider this as a no-fix? Anything I can assist with?

Thanks in advance,

It's complicated to have a good solution, because we need to change assumption (serial number identifies keys).

Today, I push a change to master, which relaxes the requirement. It does not fully fix your case, but it allows use of another card for different serial number.

gniibe changed the task status from Open to Testing.Thu, May 16, 1:58 AM
gniibe edited projects, added scd, gnupg; removed Info Needed.Thu, May 16, 9:22 AM

Helo and forgive me for the ignorance, Iam a new.
I subscribed to this topic because I need a fix like that, I have 2 yubikeys with same subkeys...
Now how is possible to install from master; It's about a debian based distro. Also, when this will be pushed for updates via apt-get;
Thank you.

gniibe lowered the priority of this task from Normal to Low.Fri, May 17, 2:00 AM

@blades: This feature will be available in GnuPG 2.3, which is planed to be released this year.
For Debian, Buster will come with GnuPG 2.2.12. After release of GnuPG 2.3, backport might be available (like GnuPG 2.2.x is available as backport for Stretch).

While the patch set is not that large, it is a kind of fundamental change to relax early implementation/design decision.

In long-standing smartcard practice, one raw private key material should be only on a single physical device, no where other than that. This practice is still valid, I suppose. In other words, this even makes sense these days, because the purpose of having a private key on a dedicated device is to control it better, securely. You know, having more places means (in many cases) increasing attack surface despite the purpose.

I implemented and pushed this change, because I think that when a user deliberately do that (say, after careful decision), it would not be a responsibility of a tool refusing such a usage, and it is true that supporting convenience for a corner case is also important for a tool. Still I, for myself, never recommend the usage which requires this feature.

I'm sad to see the methodology of having backup token getting popular in some community, I wonder if they really evaluate the security consequence.

I should have put "Low" priority for this task for GnuPG development. Well, after the change, I do it now.

Thanks Gniibe San for explanation.

Yes, ok as long as it gets to masses one day. For most business and
household usecases disaster recovery in case the token got damaged etc or
atleast for the peace of mind and considering threat model its ok with risk
of painful initial cloning step using throwaway raspberry pi etc.. Fun

ageis added a subscriber: ageis.EditedMon, May 20, 1:03 AM

Thanks for this @gniibe. I have long been frustrated by trying to save the correct "stubs" to have my keyring point at two different smartcards. It was common and even advocated in my former community to place one's master key on a separate smartcard (certify capability), with a different one designated for daily usage.

When having a backup media, I'd recommend completely different one (for example, on paper using paperkey to be stored in a locker in basement), which requires different method for recovering. Brains may be easily confused when same private key material exists in multiple similar devices.

I understand that it's convenient, and there are situations convenience matters (for easy recovering). Well, when using same media, I'd suggest to customize the backup device, by having different weight, different color, etc., so that it can be easily recognized.