Page MenuHome GnuPG

Difficulties to generate key on OpenPGP Smart Card V3.3
Closed, ResolvedPublic


Generally I use OpenPGP V2.2 or OpenPGP V3.3 smart cards in different roles and one Yubikey. For best practice the key is always generated straight on the card. Five of my cards worked fine, but one card failed (OpenPGP V3.3). It took a while, until the message "Key generation failed: Card error" showed-up. I contacted the vendor, because I bleieved that the card was dead at arrival.

However, the vendor told me that it is a common problem. The time for key generation would be too long and therefore a time out would happen often. They recommended to generate the key on a computer and copy it to the OpenPGP card. Definitely no best practice. I have not yet tried this work around. I´ll check it out next weekend. However, I would like to bring the issue to your attention.

Event Timeline

I should may add, that on the card which failed, only the signature key was generated and written to the card. The authentication and encryption keys could not be generated..

gniibe added a subscriber: gniibe.

Please let us know what kind of key and how large, like RSA-4096 or ECC Brainpool.
For RSA 2048 or larger, yes, it takes too long.

All my keys are RSA 4096. It worked fine with OpenPGP smart cards and with two Yubikey 5. On all devices a set of RSA 4096 keys were geneated on the device itself. Only one card failed. But even the card which failed, generated at least the signature key in RSA 4096.

werner added a subscriber: werner.

Are you using pcscd (is that process running) or the internal driver.? Please try the latter if you are not already using it.

gniibe triaged this task as Normal priority.

I am trying to reproduce your problem with my 3.3 card using my TTXS card reader.

I put scdaemon.conf in GNUPGHOME for debugging.

pcsc-driver none
debug-level guru
log-file /tmp/scd-debug.log

So far, I can't reproduce the bug.

Please note that key generation is takes time unusually longer from a viewpoint of card reader.
It is possible for a card reader to give up the execution of key generation command as timeout.

I observed that OpenPGPcard V3.3 has BWI=100, and it periodically sends time extension to host (period is 42-43 seconds), during key generation. As long as this time extension is kept sending, a card reader should wait. But it is likely that some readers have a limit for total time for an execution.

I do not wonder, that you face difficulties to reproduce it. It happened only with one card from my six cards; so five cards working fine. Therefore, I thought that this particular card was may dead at arrival and I contacted the vendor. They refused to replace it with the comment, it would be a well known issue. Do you know a test where I can demonstrate that the card is dead at arrival?

This weekend I´ll generate a test key pair on my notebook and then I´ll transfer it to the troublesome card. If the transfer fails too, it is may an indicator that the card is dead.

Concerning your comment above with BWI=100 and time extension: Five cards worked, it took a while, but no trouble at all. One card needed much more longer as the others and then the error message occured. I used always the same card reader for every card (it is an integrated card reader). So I belive that the root cause will may point to the card.

I applied the following with gpg-connect-agent --hex:

scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40

so often until the reply was "D[000] 69 83"

Then termination and re-opening with:

scd apdu 00 e6 00 00
scd apdu 00 44 00 00

I removed the card and tested again. The single signature key which was written to the card, before a card error ist still existing, it was not deleted. I applied it once to another card where I entered the admin PIN three times wrong. It was possible to reset the card. With the card reset it was possible to to initialize the admin PIN counter, but all existing keys on the card where deleted. In this case not, therefore, I believe it is something wrong with the card itself.

FYI, we have "factory-reset" command in gpg --card-edit; It is not enough for a card to have admin locked state, but it requires normal user locked state, too.

The card was replaced by the vendor. It seems to be a problem with the specific card. All other cards so far worked well. The issue can be closed.