Hi,
- A 'pin merge' feature: part of the PIN is provided by the app
and
the other part is entered on the pinpad reader. (Some readers
already
allow this: you just put part of the PIN in the APDU -- but some
readers seem to overwrite the APDU's PIN buffer with padding
bytes..)
How do you do that?
What SCardControl() do you send?
Please provide a real example.
For eID cards, it happens that a PUK is split between the citizen and the
govmnt.
The examples below come from an eID card with ASCII encoded PINs:
E.g. of a 'PIN unblock without PIN change', in this case you can
do an SCardControl(ctrl-for-FEATURE_VERIFY_PIN_DIRECT , data) with
data = 1E 1E 02 00 00 00 00 08 04 00 02 01 16 08 00 00 00 00 00 00 0D 00 00 00
00 2C 01 81 08 FF FF FF FF 31 32 33 34 (37 bytes)
So the app provides the last part of the PUK (= "1234" in this case) and the
pinpad reader should ask the first part of the PUK to the user and fill it
in at the location of the FF FF FF FF.
So for ASCII and BCD encoded PINs, this trick works on readers that don't
write padding bytes to the PIN buffer (i.e. they should not change the
31 32 33 34 into FF FF FF FF in the above example).
For Global Platform PINs (the ones whos PIN buffer starts with
byte '2X' where X = the number of PIN digits), this means that the pinpad
reader shouldn't overwrite the the '2X' byte. In principle, this should be
possible
by specifying that the padding is BCD and the offset for the PIN/PUK starts
at byte 1 i.s.o. 0 (but I think this trick didn't work on my reader, long time
ago..)
Another example, of a 'PIN unblock with PIN change', in this case you can
do an SCardControl(ctrl-for-FEATURE_CHANGE_PIN_DIRECT , data) with
data = 1E 1E 02 00 00 00 08 08 04 03 02 03 16 08 00 00 00 00 00 00 15 00 00 00
00 2C 00 81 10 FF FF FF FF 31 32 33 34 FF FF FF FF FF FF FF FF (45
bytes)
Here again, the first FF FF FF FF are for the user's part of the PUK, and the
last 8 FF bytes are for the new PIN. Same remarks as above apply.
- Currently, only Verify and Change pin commands exist. On most
readers,
you can (ab)use them to do an Unblock without resp. with pin
change;
but some readers check the INS byte during a Verify command ->
so it's
not possible to do an Unblock without pin change.
What INS code do you use to unblock?
I can find 5 unbock commands in [1].
The best candidate I found is:
UNBLOCK CHV, Reset a PIN retry counter that has reached its maximum
value.
INS: '2C’
Standard: TS 51.011 EN
Yes, indeed a '2C'.
But it could be something else, as long as the card understands it and
the reader would ignore it. But the latter isn't always the case, some
readers want a '20' INS byte...
Do you abuse the FEATURE_VERIFY_PIN_DIRECT command for a PIN unblock?
Yes! (See e.g. the above examples.)
Do you know of another way? I'm only aware of the FEATURE_VERIFY_PIN_XXX
and FEATURE_CHANGE_PIN_XXX commands..
Br,
Stef
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
