Issues with primary key & subkeys on different smartcards

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Issues with primary key & subkeys on different smartcards

Pete Stephenson
Hi everyone,

I'm writing in regards to an issue I've run into using GnuPG 2.0.21 on
Windows (the same issue occurs with 2.0.19 in Debian 7 and Ubuntu
Linux 13.04, and I performed the same steps on all three systems to
verify that this wasn't an OS-specific issue). I apologize in advance
for the length of this message, but I thought it better to be more
detailed than less.

Brief background:
I have loaded a primary RSA signing key onto a smartcard ("smartcard
#1"). I have created two RSA subkeys, one for signing and the other
for encrypting, and loaded them onto a second smartcard ("smartcard
#2"). The primary key and its subkeys were generated on the computer
and were later loaded onto the card; they were not generated
internally on the card (I keep a secure, offline backup of the private
keys in case the cards are damaged or lost.).

I wish to have a single private key file in my GnuPG keyring that
includes stubs to the primary key on smartcard #1 and the subkeys on
smartcard #2. This way, if I need to certify a public key belonging to
someone else I will be prompted to insert smartcard #1. If I wish to
sign a message or decrypt an encrypted message sent to me I will be
prompted to insert smartcard #2.

==========

First attempt:

Initial conditions:
1. The public key that contains details about my primary and subkeys
is present in my GnuPG keyring. The private keys are not present in
the GnuPG keyring; they exist only in the offline backup and on the
smartcards.
2. Primary key is on smartcard #1, both subkeys (encryption and
signing) are on smartcard #2.

Expected behavior:
1. I insert smartcard #1, then run "gpg2 --card-status".
2. The details of smartcard #1 is displayed.
3. GnuPG adds a private key stub pointing to smartcard #1.
4. I remove smartcard #1 and insert smartcard #2, then run "gpg2 --card-status".
5. The details of smartcard #2 is displayed.
6. GnuPG adds private key stubs pointing to smartcard #2.
7. Certifying ("signing") someone else's public key requires that I
insert smartcard #1. Signing a message or decrypting an encrypted
message requires that I insert smartcard #2.

Observed behavior:
1. Same as above.
2. Same as above.
3. Same as above.
4. Same as above.
5. Same as above.
6. GnuPG does *not* add private key stubs pointing to smartcard #2.
7. Certifying someone else's public key requires that I insert
smartcard #1, as expected. Signing a message or decrypting an
encrypted message does not prompt for smartcard #2, but instead
results in the following error message:

gpg: secret key parts are not available
gpg: skipped "KEYID": Unusable secret key
gpg: [stdin]: clearsign failed: Unusable secret key

If I start over from the initial conditions and reverse the order of
the cards (i.e. insert smartcard #2 first and run "gpg2
--card-status"), then the stubs for the subkeys get generated but when
I later insert smartcard #1 and run "gpg2 --card-status" then the stub
for the primary key is not created.

==========

Second attempt:

Expected behavior:
1. Add the primary key stub (steps 1-3 from above). This successfully
adds the primary key stub.
2. Run "gpg2 --export-secret-keys KEYID > primary-stub.key"
3. Run "gpg2 --delete-secret-keys KEYID" to delete the private key
component (that is, the stub) from the keyring.
4. Add the subkey stubs (steps 4-6 as above). This successfully adds
the subkey stubs.
5. Run "gpg2 --import primary-stub.key".
6. GnuPG imports the primary key stub, resulting in a private key
containing stubs to the primary and subkeys on their respective cards.

Observed behavior.
1. Same as above.
2. Same as above.
3. Same as above.
4. Same as above.
5. Same as above.
6. GnuPG does *not* import the primary key stub. Rather it says:

gpg: key KEYID: already in secret keyring
gpg: Total number processed: 1
gpg:       secret keys read: 1
gpg:  secret keys unchanged: 1

Starting over and reversing the order (creating the subkey stubs,
exporting them to a file, deleting the subkey stubs from the keyring,
adding the primary key stub, and trying to import the subkey stubs)
produces the same, unsuccessful result.

==========

Is this intentional or a bug?

If it is intentional, how can one easily add stubs pointing to
different smartcards for different private key components?

==========

Addendum:

I was able to successfully create a private key with stubs pointing to
both cards as follows (since Gpg4Win does not include the gpgsplit
utility but Debian's gnupg2 package does, I performed these steps in
Debian. I presume they'd also work in Debian derivatives like
Ubuntu.):
1. Insert smartcard #1, run "gpg2 --card-status". This creates a stub
for the primary key.
2. Run "gpg2 --export-secret-keys KEYID > primary-stub.key" to export
a private key file containing the stub of the primary key.
3. Run "gpg2 --delete-secret-keys KEYID" to delete the private key
stub from the keyring. Only the public key remains in the keyring.
4. Insert smartcard #2, run "gpg2 --card-status". This creates a stub
for the subkeys.
5. Run "gpg2 --export-secret-keys KEYID > subkeys-stub.key" to export
a private key file containing the stubs of the subkey.
6. Run "gpg2 --delete-secret-keys KEYID" to delete the subkey stubs
from the keyring. Only the public key remains in the keyring.
7. Put each exported key file into a separate directory, then run "cat
primary-stub.key | gpgsplit" and "cat subkeys-stub.key | gpgsplit" in
the respective directories to separate the keys into packets.
8. Move the subkey stub packets from their directory into the primary
key directory, overwriting the subkey packets in the primary key
directory.
9. Run "cat * > complete.key" in the primary key directory to
reassemble the key file.
10. Run "gpg2 --import complete.key" to import the reassembled key file.
11. Success! Everything works as expected: running "gpg2 --edit-key
KEYID", then "toggle" shows that the primary key and the subkey stubs
exist and point at their respective cards. Certifying a key requires
smartcard #1 and signing/decrypting messages requires smartcard #2.

Although this was successful, I think that it's something that should
be doable within GnuPG itself rather than by splitting keys and
working manually on packets.

Cheers!
-Pete

--
Pete Stephenson

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with primary key & subkeys on different smartcards

Pete Stephenson
On Thu, Sep 5, 2013 at 8:35 PM, Pete Stephenson <[hidden email]> wrote:
[snip]
> I wish to have a single private key file in my GnuPG keyring that
> includes stubs to the primary key on smartcard #1 and the subkeys on
> smartcard #2. This way, if I need to certify a public key belonging to
> someone else I will be prompted to insert smartcard #1. If I wish to
> sign a message or decrypt an encrypted message sent to me I will be
> prompted to insert smartcard #2.
[snip]

Hi all,

Quick followup: I was also able to create the correct private key with
stubs pointing at both smartcards by loading the actual private keys
onto the smartcard using "keytocard", as expected.

However, I'm unable to re-create this file starting only with the
public key and running "gpg2 --card-status" for each card. It seems
like running "gpg2 --card-status" for each card should be able to
create the stubs, but if there's already a stub associated with a
particular smartcard, then running "gpg2 --card-status" doesn't seem
to have any effect other than to display the card info.

Put simply: running "gpg2 --card-status" will create one stub pointing
at the card, but running that command again with a different card only
displays the card info and doesn't add any additional stubs. This
seems inconsistent and not what I would expect.

Sorry again for the really long previous message.

Cheers!
-Pete

--
Pete Stephenson

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with primary key & subkeys on different smartcards

Paul R. Ramer
On 09/06/2013 03:08 PM, Pete Stephenson wrote:

> On Thu, Sep 5, 2013 at 8:35 PM, Pete Stephenson <[hidden email]> wrote:
> Quick followup: I was also able to create the correct private key with
> stubs pointing at both smartcards by loading the actual private keys
> onto the smartcard using "keytocard", as expected.
>
> However, I'm unable to re-create this file starting only with the
> public key and running "gpg2 --card-status" for each card. It seems
> like running "gpg2 --card-status" for each card should be able to
> create the stubs, but if there's already a stub associated with a
> particular smartcard, then running "gpg2 --card-status" doesn't seem
> to have any effect other than to display the card info.
>
> Put simply: running "gpg2 --card-status" will create one stub pointing
> at the card, but running that command again with a different card only
> displays the card info and doesn't add any additional stubs. This
> seems inconsistent and not what I would expect.

Hello Pete,

It seems that the keytocard command is the way to correctly load the
subkeys and primary key onto the smartcards.  I had not thought about
splitting the primary and subkeys across the two smartcards, but it
works quite easily by using the keytocard command.  I tested it to see
how it works, and I feel certain that the keytocard method that you used
is the correct way to do it.

For those who may be reading, I found loading one OpenPGP card with the
primary key and a second with the subkey to work as the following
example demonstrates:

$ gpg2 --edit-key Joe
gpg (GnuPG) 2.0.17; Copyright (C) 2011 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  2048R/123B9C22  created: 2013-09-07  expires: 2018-09-06  usage: SC
                     trust: ultimate      validity: ultimate
sub  2048R/972C7E79  created: 2013-09-07  expires: 2018-09-06  usage: E
[ultimate] (1). Joe <[hidden email]>

gpg> toggle

sec  2048R/123B9C22  created: 2013-09-07  expires: 2018-09-06
ssb  2048R/972C7E79  created: 2013-09-07  expires: never
(1)  Joe <[hidden email]>

gpg> keytocard
Really move the primary key? (y/N) y
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]

Please select where to store the key:
   (1) Signature key
   (3) Authentication key
Your selection? 1

You need a passphrase to unlock the secret key for
user: "Joe <[hidden email]>"
2048-bit RSA key, ID 123B9C22, created 2013-09-07


sec  2048R/123B9C22  created: 2013-09-07  expires: 2018-09-06
                     card-no: 0005 DECAFBAD
ssb  2048R/972C7E79  created: 2013-09-07  expires: never
(1)  Joe <[hidden email]>

gpg> key 1

sec  2048R/123B9C22  created: 2013-09-07  expires: 2018-09-06
                     card-no: 0005 DECAFBAD
ssb* 2048R/972C7E79  created: 2013-09-07  expires: never
(1)  Joe <[hidden email]>

gpg> keytocard
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]

Please select where to store the key:
   (2) Encryption key
Your selection? 2

You need a passphrase to unlock the secret key for
user: "Joe <[hidden email]>"
2048-bit RSA key, ID 972C7E79, created 2013-09-07


sec  2048R/123B9C22  created: 2013-09-07  expires: 2018-09-06
                     card-no: 0005 DECAFBAD
ssb* 2048R/972C7E79  created: 2013-09-07  expires: never
                     card-no: 0005 DEADBEEF
(1)  Joe <[hidden email]>

gpg> save

Now you are done, and the cards work great.  If you need either the
primary key or subkey, pinentry will prompt you to insert the
appropriate card.  The only thing is that if you need a backup of the
secret keys before moving them to the smartcards, you need to do that
before following the example above.

Anyway, Pete, thank you for bringing this subject up and experimenting
with it and helping make us all a little smarter.  I can't answer the
question as to whether it was designed to work that way, but I don't
feel there is any doubt.

Cheers,

--Paul

--
PGP: 0x3DB6D884
PGP Fingerprint: EBA7 88B3 6D98 2D4A E045  A9F7 C7C6 6ADF 3DB6 D884

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with primary key & subkeys on different smartcards

Pete Stephenson
On Sat, Sep 7, 2013 at 9:45 AM, Paul R. Ramer <[hidden email]> wrote:
[snip]
> It seems that the keytocard command is the way to correctly load the
> subkeys and primary key onto the smartcards.  I had not thought about
> splitting the primary and subkeys across the two smartcards, but it
> works quite easily by using the keytocard command.  I tested it to see
> how it works, and I feel certain that the keytocard method that you used
> is the correct way to do it.
[snip]

Hi Paul,

Indeed, the keytocard command is the correct way to load the keys onto
the cards and to generate the stubs initially. As you mention, that
works as expected and generates the correct stubs pointing at both
cards.

The issue I'm running into is not the initial loading of the private
keys onto the cards, but rather if I'm trying to use the cards on a
computer that does not already have the private keys.

If I start on that new computer with only my public key, insert one of
the two cards (e.g. the card containing my primary key) and run "gpg2
--card-status", GnuPG will generate a private key stub that points at
that card. That's fine and works as expected. However, if I try doing
the same thing with the second card (the one with my subkeys), the
stub is not added. Only the details of the second card are displayed,
but the stub pointing to that card is not added.

This is not what I expected: I expect that GnuPG will add a stub for
each of the cards after I run "--card-status" for each card, but this
doesn't happen and only the stub for the first card (i.e. whichever
one I use with "--card-status" first) is added.

In short, I expect to be able to get the same result using
"--card-status" and both cards as I do when I use "keytocard" to
initially move the keys to the cards, but this does not occur.

> Now you are done, and the cards work great.  If you need either the
> primary key or subkey, pinentry will prompt you to insert the
> appropriate card.  The only thing is that if you need a backup of the
> secret keys before moving them to the smartcards, you need to do that
> before following the example above.

Right, I definitely have backups, but it's always a good thing to
remind people. :)

> Anyway, Pete, thank you for bringing this subject up and experimenting
> with it and helping make us all a little smarter.  I can't answer the
> question as to whether it was designed to work that way, but I don't
> feel there is any doubt.

You're welcome.

If it is designed to work that way, I respectfully ask that the
developers consider changing how it works so that "keytocard" and
"--card-status" both produce the same key with stubs pointing to each
respective card. The way it currently works, where --card-status will
only add one stub to a key, is not what I would expect to happen.

As my programming abilities are not sufficient to make a patch to
change this behavior, I'd be happy to offer a financial contribution
if someone with more skill were to give it a shot.

Cheers!
-Pete

--
Pete Stephenson

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Reply | Threaded
Open this post in threaded view
|

Re: Issues with primary key & subkeys on different smartcards

Peter Lebbing
(from the first mail)
> I was able to successfully create a private key with stubs pointing to
> both cards as follows

Yes, that is how I ended up doing it back when I started using the same setup
years ago (two smartcards, certifying key on one, signing on another).

Only shortly ago, I got the impression from someone's mail to gnupg-users that
GnuPG these days did it as we both expected it would do: upon inserting the
second smartcard, replace the dummy S2K stubs with divert-to-card S2K's for the
second card.

Apparently it does not...

Once GnuPG has a secret key, I think it won't update it with new data. It didn't
use to AFAIK, and apparently still doesn't. Somebody else recently tried
exporting and importing a new subkey, and the import didn't work either. I just
thought of that thread and replied to it as well.

> As my programming abilities are not sufficient to make a patch to
> change this behavior, I'd be happy to offer a financial contribution
> if someone with more skill were to give it a shot.

I commend your spirit. Werner Koch does paid feature development for GnuPG as
well, although I am in no position to judge whether your financial contribution
can pay for the whole feature. I'm also willing to contribute, but don't hold
your breath over the amount of money ;). I've offered payment for a feature
before, can't exactly remember what right now, but it was worth to me more than
this particular one.

Come to think of it, I've never seen any mention of people paying for features
and/or features made possible by paying users. Perhaps an interesting subthread
to spawn, if Werner is comfortable discussing it?

Anyway, back to the topic: maybe there are situations where you don't want to
update a secret key with new subkeys or new "key material" (let's consider a
divert-to-card S2K as key material, and a dummy S2K as absence of it). But an
option "--import-options update-secret-key" or something seems like a useful
thing, and gives people the choice without resorting to gpgsplitting.

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users