Re: [opensc-devel] Implicit PIN change with pinpad reader.
Thanks for the pointer Martin. I've attached a small patch that uses your suggestion. I've successfully tested it with both versions of the Portuguese eID card, with a SPR532 pinpad reader: one version uses an implicit change pin operation and the other uses the (normal) explicit pin change operation. João implicit_pin_change.patch Description: Binary data On Sep 24, 2009, at 19:12, Martin Paljak wrote: On 24.09.2009, at 15:59, João Poupino wrote: On the document, there are other options explained. One looks promising: bConfirmPin: 0x01 bNumberMessage: 0x02 Messages seen on Pinpad display: New Pin*, Confirm Pin* *In these two cases, old PIN is not asked by the Pinpad but do not forget to put the old PIN value in the APDU command. And now it works as expected :) Of course, by doing this I'm breaking all other cards and it's not very nice. Is there any way (through a flag in structure or something) that we can signal part10_build_modify_pin_block() to adapt its behavior depending on the type of card? Sure, there are flags SC_PIN_CMD*. You can add a new flag and related code. It might be useful to add a similar flag to PKCS#15 layer, even if not defined in PKCS#15. When you have a similar application on multiple cards and a single emulation driver then the emulation layer information can be translated to lower flags. Check SC_PIN_CMD_NEED_PADDING and SC_PKCS15_PIN_FLAG_NEEDS_PADDING for inspiration. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new openct release?
Hello, In trunk revision 1168 and 1167 I corrected openct/etc/Info.plist according to openct.conf. Hope it won't entail any side effects, please check it. Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Implicit PIN change with pinpad reader.
On 24.09.2009, at 15:59, João Poupino wrote: > On the document, there are other options explained. One looks > promising: > > bConfirmPin: 0x01 > bNumberMessage: 0x02 > Messages seen on Pinpad display: New Pin*, Confirm Pin* > > *In these two cases, old PIN is not asked by the Pinpad but do not > forget to put the old > PIN value in the APDU command. > And now it works as expected :) > > Of course, by doing this I'm breaking all other cards and it's not > very nice. Is there any way (through a flag in structure or > something) that we can signal part10_build_modify_pin_block() to > adapt its behavior depending on the type of card? Sure, there are flags SC_PIN_CMD*. You can add a new flag and related code. It might be useful to add a similar flag to PKCS#15 layer, even if not defined in PKCS#15. When you have a similar application on multiple cards and a single emulation driver then the emulation layer information can be translated to lower flags. Check SC_PIN_CMD_NEED_PADDING and SC_PKCS15_PIN_FLAG_NEEDS_PADDING for inspiration. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Implicit PIN change with pinpad reader.
On Sep 24, 2009, at 14:14, François Leblanc wrote: > > >> On the document, there are other options explained. One looks >> promising: >> >> bConfirmPin: 0x01 >> bNumberMessage: 0x02 >> Messages seen on Pinpad display: New Pin*, Confirm Pin* >> >> *In these two cases, old PIN is not asked by the Pinpad but do not >> forget to put the old >> PIN value in the APDU command. > > How do you do this, since you have pinpad reader the pin code should > be never see by opensc > > so it can be put on apdu? The old pin isn't needed in change pin > command? Exactly, with the Portuguese eID card, the old pin isn't needed in the change pin command. First, we send a normal verify pin apdu (the reader asks the user for the pin and fills in the pin value as expected) and next we send a change pin apdu with only the new pin. João > > > > François. > > > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Implicit PIN change with pinpad reader.
>On the document, there are other options explained. One looks promising: > >bConfirmPin: 0x01 >bNumberMessage: 0x02 >Messages seen on Pinpad display: New Pin*, Confirm Pin* > >*In these two cases, old PIN is not asked by the Pinpad but do not forget to >put the old >PIN value in the APDU command. How do you do this, since you have pinpad reader the pin code should be never see by opensc so it can be put on apdu? The old pin isn't needed in change pin command? François. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Implicit PIN change with pinpad reader.
Hi François, Thank you for replying! On Sep 24, 2009, at 13:36, François Leblanc wrote: I don't think that the matter is in reader-pcsc.c, I think you should have a look on Portuguese eID in command " pin_cmd " the SC_PIN_CMD_CHANGE is probably slip in two parts SC_PIN_CMD_VERIFY + the SC_PIN_CMD_CHANGE just disable the SC_PIN_CMD_VERIFY when reader is pinpad capability... If I disable it, then OpenSC will try to build an SC_PIN_CMD_CHANGE apdu with "old pin, new pin, new pin" - but the card specification does not allow it. Meanwhile, I was trying to understand the PC/SC V2 spec part 10, but it's not very detailed. I was able to find a document by Gemalto [1] that says this, on page 13: bConfirmPin: 0x03 bNumberMessage: 0x03 Messages seen on Pinpad display: Enter Pin, New Pin, Confirm Pin This is the case is reader-pcsc.c as it can be seen on the code: pin_modify->bConfirmPIN = 0x03; /* bConfirmPIN, all */ pin_modify->bEntryValidationCondition = 0x02; /* bEntryValidationCondition, keypress only */ if (slot->capabilities & SC_SLOT_CAP_DISPLAY) pin_modify->bNumberMessage = 0x03; /* 3 messages (because bConfirmPIN = 3), all default. Could be 0xFF too */ else pin_modify->bNumberMessage = 0x00; /* No messages */ On the document, there are other options explained. One looks promising: bConfirmPin: 0x01 bNumberMessage: 0x02 Messages seen on Pinpad display: New Pin*, Confirm Pin* *In these two cases, old PIN is not asked by the Pinpad but do not forget to put the old PIN value in the APDU command. So, I changed the code in reader-pcsc.c: pin_modify->bConfirmPIN = 0x01; pin_modify->bEntryValidationCondition = 0x02; /* bEntryValidationCondition, keypress only */ if (slot->capabilities & SC_SLOT_CAP_DISPLAY) pin_modify->bNumberMessage = 0x02; else pin_modify->bNumberMessage = 0x00; /* No messages */ And now it works as expected :) Of course, by doing this I'm breaking all other cards and it's not very nice. Is there any way (through a flag in structure or something) that we can signal part10_build_modify_pin_block() to adapt its behavior depending on the type of card? João [1] - http://support.gemalto.com/fileadmin/user_upload/user_guide/Pinpad/PCPinpad_PC-SC_UserGuide.pdf Can anyone help? Thank you. João Hope this can help you, Regards. François. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Implicit PIN change with pinpad reader.
Hi, Don't anything about Portuguese eID but: > ... > >This works perfectly when using a regular reader. When using a pinpad >reader it works also, but a "minor annoyance" occurs: the reader asks >for 4 PINs (instead of the regular 3) and I think this can cause >confusion to the users. >If I'm not mistaken, 1 PIN is asked for the SC_PIN_CMD_VERIFY apdu >and the 3 other PINs are asked for the SC_PIN_CMD_CHANGE apdu. With your description it seems true. >I've been trying to understand part10_modify_pin_block() in reader- >pcsc.c, but I still don't know exactly what is needed to change its >behavior to support correctly this card. I don't think that the matter is in reader-pcsc.c, I think you should have a look on Portuguese eID in command " pin_cmd " the SC_PIN_CMD_CHANGE is probably slip in two parts SC_PIN_CMD_VERIFY + the SC_PIN_CMD_CHANGE just disable the SC_PIN_CMD_VERIFY when reader is pinpad capability... >Can anyone help? >Thank you. >João Hope this can help you, Regards. François. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Implicit PIN change with pinpad reader.
Hi all, I've come across an issue with the way a "Change PIN" operation is processed in OpenSC, when using a pinpad reader and the Portuguese eID card. Basically, the problem is that one of the versions of the Portuguese eID card (IAS spec) only supports changing the PIN if a previously "Verify PIN" apdu was sent. So the driver, when receiving a "change pin" request, breaks it in two different APDUs: SC_PIN_CMD_VERIFY and, after that, SC_PIN_CMD_CHANGE. Normally, this is what happens (old pin = 1234, new pin = 1234). APDU 00:20:00:01:08:31:32:33:34:2F:2F:2F:2F SW: 90 00 APDU 00:24:01:01:08:31:32:33:34:2F:2F:2F:2F SW: 90 00 This works perfectly when using a regular reader. When using a pinpad reader it works also, but a "minor annoyance" occurs: the reader asks for 4 PINs (instead of the regular 3) and I think this can cause confusion to the users. If I'm not mistaken, 1 PIN is asked for the SC_PIN_CMD_VERIFY apdu and the 3 other PINs are asked for the SC_PIN_CMD_CHANGE apdu. I've been trying to understand part10_modify_pin_block() in reader- pcsc.c, but I still don't know exactly what is needed to change its behavior to support correctly this card. Can anyone help? Thank you. João ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
