2011/10/21 Stef Hoeben <[email protected]>: > 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...
UNBLOCK PIN is defined in TS 102 221. The UNBLOCK PIN command uses as parameters: the UNBLOCK PIN and the new PIN. So 2 PIN needs to be sent. Does a user enters the 2 PINs on the pinpad? or the unblock PIN is sent by the application and this is just another example of PIN merge? > Do you abuse the FEATURE_VERIFY_PIN_DIRECT command for a PIN unblock? > > Yes! (See e.g. the above examples.) The examples where for a PIN merge. Unblock PIN also use the (possible) PIN merge feature of FEATURE_VERIFY_PIN_DIRECT? > Do you know of another way? I'm only aware of the FEATURE_VERIFY_PIN_XXX > and FEATURE_CHANGE_PIN_XXX commands.. No. So your requests are: - allow PIN merge for FEATURE_VERIFY_PIN_DIRECT (do not pad) - allow INS = 0x2C for FEATURE_VERIFY_PIN_DIRECT (and not just 0x20) Exact? Bye -- Dr. Ludovic Rousseau _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
