Page MenuHome GnuPG

Problems with same encryption and signing key on smartcard
Closed, ResolvedPublic


Hi there!

At work I got an X509 certificate with a 2048 bit RSA key which
I can use for encryption and signing (of emails typically).

I want to store my private key on a OpenPGP smart card. As far
as I understood, the smart card can only sign with with its
key in slot 1 and only decrypt for the key in slot 2.

Therefore, I simply stored my private key on both the signing
and encryption slot on the smartcard:

> gpg --card-status
gpg: Warning: using insecure memory!
Application ID ...: D27600012401020000050001234D1234
Version ..........: 2.0
Manufacturer .....: ZeitControl
Serial number ....: 0000280D
Name of cardholder: [not set]
Language prefs ...: de
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [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 ....: 265C 3401 7EAB 92EF 7878  B4FD C183 1F64 C157 75A3
      created ....: 2013-12-12 14:34:12
Encryption key....: 265C 3401 7EAB 92EF 7878  B4FD C183 1F64 C157 75A3
      created ....: 2013-12-12 14:34:12
Authentication key: [none]
General key info..: [none]

My problem is now that I can only sign OR decrypt, depending
on the OPENPGP.[12] entry in the private key file in

gnupg looks up the location of the private key from this file and
then ask the smartcard to sign with this key, which the card can
only do if it is slot OPENPGP.1. For a decryption it only works
if the entry is OPENPGP.2.

My wish would therefore be to extend the file-format to record
multiple locations of a key on the card, so that the proper
location can be returned for a signing or decrypt operation.

Event Timeline

marcus added a subscriber: marcus.

It's not really a good idea to use the same RSA key for encryption and signing. (Although when I wrote scute, I couldn't generate a CSR for the encryption key, because the CSR had to be self-signed, meh).

That is the way I get my certificate signed, there is nothing I can do about it ;-)

I have to say it is quite common for SMIME certificates to be used like this, i.e. just one RSA key for both digital signatures and encryption. It might not be ideal but that is the way they are used.

Back then I even created two CSRs asking for only a signature key and another with only an encryption key, but the CA refused to deviate from their usual profile, and certified both for both signing and encryption. I contacted them ( but they said that is just they way it is. I have to say that I can understand them, as it really would be unusual for SMIME certificates.

(As you also discovered, it is not so easy to create a CSR for the encryption key. One just has to create the key and the CSR somewhere safe and then copy the key to the smartcard encryption slot.)

While it's not recommended, current master has a support of sharing same raw key materials. I think that it now works (I don't try, though).