Re: “Hardware problem” with OpenPGP smart card
On Mon, 7 Dec 2020 23:37, Nicolas Boullis said: > Hence, I think my card is really dead. yeah :-( > I see that the card includes a signature counter (which reads 89), hence > I understand the card has to write the EEPROM (to update the counter) Yes, this one reason to write to the EEPROM. However, this is a way too low number for a failure. A few years ago we had a similar report and the Zeitcontrol folks did some testing. A 10 operations were not a problem at all. From my understanding the EEPROM of the chip used by Zeitcontrol allows for much more r/w cycles than what you usually get from an average Atmel or so microcontroller. Anyway, my STM32 based Gnuk token did about 8000 signing operaion with the first key. > between 1,000 and 10,000 authentications with that card. I think it > might be sufficient to wear an EEPROM. Nope. > Also, the card reports 2 tries left for the PIN code, which means that > my last try to unlock the unlock the pin was a failure. Did the card > somehow fail updating the retry counter? (Either when I typed the wrong It failed. Smartcards handle verification by first decrementing the retry counter, running the verify, and on success incrementing the retry counter. This is so that a power glitch can't be used to trick out the retry counter. This method explains why you see 2. > If there’s anything I can do to investigate that failure, please tell > me. The card should not allow you to investigate things even after a failure. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: “Hardware problem” with OpenPGP smart card
Hi, On Mon, Dec 07, 2020 at 12:08:23PM +0100, Werner Koch via Gnupg-users wrote: > > The show error code is indeed either a hardware error (EEPROM failure) > or due to a card reader which filters certyain commands send to the card > and return a bogus error code. However, I doubt that the latter is the > case. > > In any case, it is best to try a different reader and if possible a > different machine. Thanks to all for your answers. I had already tried on a different computer, with no success. I have a second OpenPGP card (with different keys) installed in a second reader, which still works fine on both computers. I tried the first card in the second reader; it still fails. I tried the second card in the firest reader; it works. Hence, I think my card is really dead. Anyhow, even if it’s dead, I’d love to understand how/why it happened. I see that the card includes a signature counter (which reads 89), hence I understand the card has to write the EEPROM (to update the counter) each time I perform a signature. But I think 89 is a much too low a number to wear en EEPROM. I have used my card much more for file decryption and for SSH authentication. Does the card write the EEPROM each time such an operation is performed? A rough guess is that I might have performed between 1,000 and 10,000 authentications with that card. I think it might be sufficient to wear an EEPROM. Also, the card reports 2 tries left for the PIN code, which means that my last try to unlock the unlock the pin was a failure. Did the card somehow fail updating the retry counter? (Either when I typed the wrong pin, or now when I type the right one and it tries to reset the counter to 3…) If there’s anything I can do to investigate that failure, please tell me. Cheers, -- Nicolas Boullis ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: “Hardware problem” with OpenPGP smart card
On Sun, 6 Dec 2020 13:43, John Scott said: >> PIN retry counter : 2 0 3 > It looks like you're trying to decrypt a file and your encryption PIN counter > is zero. I wonder why it was giving you the strange error message. No, it is not at zero. Since OpenPGP card specification version 2 we only have two PINs and not a separate one for the encryption key. Thus the the secund number is always zero. Well, not always: If you set a reset code the second retry counter is set to 3. Such a reset code is an alternative to the Admin PIN. If an organization does not want to hand out the Admin PIN a reset code is instead set and the user can use that reset code to unblock they PIN. The show error code is indeed either a hardware error (EEPROM failure) or due to a card reader which filters certyain commands send to the card and return a bogus error code. However, I doubt that the latter is the case. In any case, it is best to try a different reader and if possible a different machine. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: “Hardware problem” with OpenPGP smart card
On Saturday, December 5, 2020 9:20:33 AM EST Nicolas Boullis wrote: > PIN retry counter : 2 0 3 It looks like you're trying to decrypt a file and your encryption PIN counter is zero. I wonder why it was giving you the strange error message. Does signing work? signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: “Hardware problem” with OpenPGP smart card
On Sun, 6 Dec 2020 16:34:40 +0100, Nicolas Boullis wrote: > Hi, > > On Sun, Dec 06, 2020 at 12:37:19PM +0100, Werner Koch wrote: >> >> To make sure that this is really the card (or reader), I'd like to ask >> you to put >> >> --8<---cut here---start->8--- >> log-file /some/path/scd.log >> verbose >> debug cardio >> --8<---cut here---end--->8--- >> >> into scdaemon.conf. Kill scdaemon.conf and retry. You should see a line >> with status code 0x6581 (EEPROM FAILURE) in response to a VERIFY (00 20 >> ... PIN) APDU or a PSO (00 2A ) APDU. If that is the case you are >> probably out of luck. It is a rare thing; iirc, I recall one other >> report about a hardware failure. > > Thanks for your suggestion. > I just tried it, and found, in the scd.log file: > > 2020-12-06 16:26:24 scdaemon[4732] DBG: send apdu: c=00 i=20 > p1=00 p2=82 lc=8 le=-1 em=0 > 2020-12-06 16:26:24 scdaemon[4732] DBG: raw apdu: 00 20 00 82 08 ***PIN*** > 2020-12-06 16:26:24 scdaemon[4732] DBG: response: sw=6581 datalen=0 > 2020-12-06 16:26:24 scdaemon[4732] verify CHV2 failed: Hardware problem > 2020-12-06 16:26:24 scdaemon[4732] operation decipher result: > Hardware problem > 2020-12-06 16:26:24 scdaemon[4732] app_decipher failed: Hardware problem > > Do you think there is still a chance that the reader is at fault rather > than the smartcard? > Any hope besides replacing the smartcard *and the subkeys*? > > Testing a new reader dongle is the best option. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: “Hardware problem” with OpenPGP smart card
Hi, On Sun, Dec 06, 2020 at 12:37:19PM +0100, Werner Koch wrote: > > To make sure that this is really the card (or reader), I'd like to ask > you to put > > --8<---cut here---start->8--- > log-file /some/path/scd.log > verbose > debug cardio > --8<---cut here---end--->8--- > > into scdaemon.conf. Kill scdaemon.conf and retry. You should see a line > with status code 0x6581 (EEPROM FAILURE) in response to a VERIFY (00 20 > ... PIN) APDU or a PSO (00 2A ) APDU. If that is the case you are > probably out of luck. It is a rare thing; iirc, I recall one other > report about a hardware failure. Thanks for your suggestion. I just tried it, and found, in the scd.log file: 2020-12-06 16:26:24 scdaemon[4732] DBG: send apdu: c=00 i=20 p1=00 p2=82 lc=8 le=-1 em=0 2020-12-06 16:26:24 scdaemon[4732] DBG: raw apdu: 00 20 00 82 08 ***PIN*** 2020-12-06 16:26:24 scdaemon[4732] DBG: response: sw=6581 datalen=0 2020-12-06 16:26:24 scdaemon[4732] verify CHV2 failed: Hardware problem 2020-12-06 16:26:24 scdaemon[4732] operation decipher result: Hardware problem 2020-12-06 16:26:24 scdaemon[4732] app_decipher failed: Hardware problem Do you think there is still a chance that the reader is at fault rather than the smartcard? Any hope besides replacing the smartcard *and the subkeys*? Thanks for your help, -- Nicolas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: “Hardware problem” with OpenPGP smart card
On Sat, 5 Dec 2020 15:20, Nicolas Boullis said: > gpg: public key decryption failed: Hardware problem > gpg: decryption failed: No secret key To make sure that this is really the card (or reader), I'd like to ask you to put --8<---cut here---start->8--- log-file /some/path/scd.log verbose debug cardio --8<---cut here---end--->8--- into scdaemon.conf. Kill scdaemon.conf and retry. You should see a line with status code 0x6581 (EEPROM FAILURE) in response to a VERIFY (00 20 ... PIN) APDU or a PSO (00 2A ) APDU. If that is the case you are probably out of luck. It is a rare thing; iirc, I recall one other report about a hardware failure. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
“Hardware problem” with OpenPGP smart card
Hi, I’ve been using GnuPG with my private keys stored in an OpenPGP smartcard since year 2014. Suddenly, it stopped working yesterday. The smartcard is an ID000-cut version 2 OpenPGP smartcard, that I put in a Gemalto Shell Token v2 card reader. Whenever I try to decrypt a file with gnupg, it asks me for the pin code, and then fails with: gpg: public key decryption failed: Hardware problem gpg: decryption failed: No secret key But gpg2 --card-status looks fine: Reader ...: 08E6:3438:EB846942:0 Application ID ...: D27600012401020528AC Version ..: 2.0 Manufacturer .: ZeitControl Serial number : 28AC Name of cardholder: Nicolas Boullis Language prefs ...: fren Sex ..: male URL of public key : https://people.debian.org/~nboullis/882D4468.asc Login data ...: nboullis Signature PIN : not forced Key attributes ...: rsa4096 rsa4096 rsa4096 Max. PIN lengths .: 32 32 32 PIN retry counter : 2 0 3 Signature counter : 89 Signature key : E255 CB42 FC16 B17E 20CD 18D9 79F1 8F90 CC2B 8435 created : 2014-12-14 00:17:04 Encryption key: 7D9E A605 E167 A29C 4C0F 8AEA 5BEC 68E0 0D97 34FB created : 2014-12-14 00:12:11 Authentication key: F2DF B54A 3623 7414 53DD 9461 F203 2B12 D9E8 23FD created : 2014-12-14 00:19:47 General key info..: sub rsa4096/79F18F90CC2B8435 2014-12-14 Nicolas Boullis sec# rsa4096/D0E94F8D882D4468 created: 2014-12-13 expires: 2021-01-01 ssb> rsa4096/5BEC68E00D9734FB created: 2014-12-14 expires: never card-no: 0005 28AC ssb> rsa4096/79F18F90CC2B8435 created: 2014-12-14 expires: never card-no: 0005 28AC ssb> rsa4096/F2032B12D9E823FD created: 2014-12-14 expires: never card-no: 0005 28AC Has anyone experienced such a problem? Any suggestion how I can sort this out? Cheers, -- Nicolas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users