TL;DR: I think you might be helped by [4]. Do an "scd killscd" from gpg-connect-agent, install and start pcscd, install the Python module pyscard and run the script from [4]. By the way, if you have an OpenPGP v.1 card, you're screwed, they self-destruct on 3 wrong Admin PINs.
On 21/01/14 02:37, Paul R. Ramer wrote: > I am having trouble reseting an OpenPGP card on which I locked the admin > PIN. Since you already locked the PIN, the 8 commands that represent VERIFY attempts with a wrong PIN should no longer be needed. They are these commands: >> scd apdu 00 20 00 81 08 40 40 40 40 40 40 40 40 For the normal PIN (to be overly exact, for doing a signature) >> scd apdu 00 20 00 83 08 40 40 40 40 40 40 40 40 For the admin PIN >> scd apdu 00 44 00 00 > ERR 100663405 Card reset required <SCD> This would normally be the first step of getting the card back to an unlocked, clean state. Note that an OpenPGP v1.1 card will self-destruct on 3 wrong admin PINs. If you have a v1.1 card, you're out of luck. However, a v2.0 card can be quite a bitch as well. I grabbed an unused v2.0 card to try to replicate your situation. I exhausted the Admin PINs, disconnected and reconnected the reader, and tried to re-initialise it. It wouldn't work. I accidentally lost the log of what I did, but it would respond to "TERMINATE DF" with the expected status 90 00, but "ACTIVATE FILE" would give an error in SW1-SW2. Then I also exhausted the regular PINs, thinking that maybe both need to be locked. No luck again. I interspersed all with the following APDU I constructed from the docs: scd apdu 00 ca 5f 52 00 Which gets the DO "Historical bytes" and looks like this for one of my v2.0 cards: D[0000] 00 31 C5 73 C0 01 40 05 90 00 90 00 The fourth-to-last byte, 05, indicates it is in "Operational state". At no point did the test card leave this state, even though after "TERMINATE DF" it should say 03 for "Initialisation state", IIUC. I changed the order of "TERMINATE DF" and "ACTIVATE FILE", and sometimes repeated one of those, but no matter what I tried, I could never get 90 00 for both commands, always only one of them. Then at some point, my card stopped working. I would get "Incorrect value" if I remember, euh... correctly. I got a bit worried at this point, and decided to kill scdaemon and gpg-agent to start with a clean slate. gpg-agent however is started by my X session, and killing it only made it <defunct>. At this point I logged out, and lost my log of what I had done. Oops! There goes an exact and detailed transcript of how it went wrong. Aaarrrggh! Why didn't I set screen to log all to a file?! So now, the OpenPGP card would not select the OpenPGP application. A log of all APDU's, generated by scdaemon (debug 2048) is: -----------------8<--------------------->8----------------- 2014-01-21 10:51:00 scdaemon[9568] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 00 0C 02 3F 00 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 04 00 06 D2 76 00 01 24 01 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6285 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=7 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 04 0C 07 D2 76 00 00 03 01 02 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=12 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 04 0C 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=08 p2=0C lc=2 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 08 0C 02 2F 00 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=01 p2=0C lc=2 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 01 0C 02 50 15 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=9 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 04 0C 09 D2 76 00 00 25 45 50 02 00 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] DBG: send apdu: c=00 i=A4 p1=04 p2=0C lc=6 le=-1 em=0 2014-01-21 10:51:00 scdaemon[9568] DBG: raw apdu: 00 A4 04 0C 06 D2 76 00 00 66 01 2014-01-21 10:51:00 scdaemon[9568] DBG: response: sw=6B00 datalen=0 2014-01-21 10:51:00 scdaemon[9568] no supported card application found: Invalid value -----------------8<--------------------->8----------------- I tried to decode this. ISO 7816-4 is annoyingly expensive to buy, but you can find parts of it online. The first apdu "SELECT FILE" seems to request file control information, but P2=0C is not defined by [1]. The error response by the card is given, as "Wrong parameter(s) P1-P2" [2]. Hah, the card also doesn't understand P2, I think. On to the OpenPGP application. The second APDU is a "SELECT FILE" for the OpenPGP application, but unfortunately, the card returns 62 85. Again, not mentioned by [1] or [2]! It is of the class "State of non-volatile memory unchanged", but SW2=85 is not defined. But it is obviously different from the rest of the "SELECT FILE"s that follow, which aren't all that interesting because I think they refer to different cards that are also supported by scdaemon. The fact that selecting OpenPGP is different, is relevant, though. Oh, by the way, the ATR is normal. Perhaps I could get further with the full, real ISO 7816. But alas, I don't have it, and it's expensive. So I wrote all this, and then tried to find more about "TERMINATE DF". The reasoning is: normally we select the DF for OpenPGP, and then do a "TERMINATE DF", right? Selection errors out, so if we could parameterise "TERMINATE DF" to directly specify the OpenPGP DF, maybe that will work. At this point I came across this mailing list conversation: [3] and from that [4]. The script in [4] did the trick to bring back my card, and it differs from the scdaemon approach in that it doesn't error out when "SELECT FILE" doesn't work. What it does for me, is "SELECT FILE" OpenPGP, it errors with 62 85 just as with the author of the script, but then it nonetheless sends an "ACTIVATE FILE". Yes, at this point it seems that I was wrongly informed earlier, and that it is actually as follows: >> scd apdu 00 44 00 00 This is "ACTICATE FILE" >> scd apdu 00 e6 00 00 This is "TERMINATE DF" If I now, with this experience, read the descriptions of those in the OpenPGP card v2.0 spec, some more things become clear. "TERMINATE DF", INS=E6, will indeed somewhat terminate the OpenPGP application, in that it will, documented there, return 62 85 on a "SELECT FILE". Perhaps 62 85 is defined in ISO 7816-9, where "TERMINATE DF" is defined, a specification which I don't have either. However, it gets slightly annoying when scdaemon from then on will not talk to the card anymore because it returns said 62 85. The Python script will do the trick. That is, if I first do an "scd killscd" from gpg-connect-agent, then start pcscd, and also make sure I have the pyscard package installed for Python. At this point my card works again. A little while earlier in writing this mail, I thought "well that's the last time I experiment with resetting an OpenPGP card to help someone", but I suppose I'm good to go again :). I don't have to throw out my unused card after all. In fact, I did another test. As documented in the OpenPGP card spec, indeed both PIN counters need to be down to 0, not just the Admin one. And it seems the following is required to reset it: - Expire both PINs - scd apdu 00 e6 00 00 "TERMINATE DF". If at this point you reset your card, scdaemon will become useless because it will error out on selection of the OpenPGP DF. - scd apdu 00 44 00 00 "ACTIVATE FILE". Works from scdaemon when issued after "TERMINATE DF", otherwise, use the script in [4]. HTH, Peter. [1] http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_6_basic_interindustry_commands.aspx#chap6_11 [2] http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx#chap5_4_5 [3] http://lists.gnupg.org/pipermail/gnupg-devel/2013-November/028058.html [4] http://lists.gnupg.org/pipermail/gnupg-devel/2013-March/027518.html -- 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 Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
