Trouble reseting OpenPGP card after admin PIN lockout

Tue Jan 21 12:23:40 CET 2014

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>