IAS-ECC/Pinpad couple does not support variable lenght pin #424
Comments
|
The only PINPAD that I have is 'Gemalto GemPC PinPad' and apparently it has a bug and do not accept different values for min/max length in P10 data. In 95ad11a this reader is separated in a special case, |
|
Have you looked at: I remember problems with the endian of integers with PCSC part 10. The wPinMaxExtraDigit is two bytes. reader-pcsc.c handles the min max using this: 1368 tmp16 = (data->pin1.min_length << 8 ) + data->pin1.max_length; I see card-iasecc.c has: if (pin_cmd->pin1.min_length != pin_cmd->pin1.max_length) I have used the Omnikey 3821 pin pad, with pin.min_length = 4 and pin.max_length = 8 A opensc debug of the verify command sent to the reader to use the pinpad Some things to look at: On 4/4/2015 2:50 PM, viktorTarasov wrote:
Douglas E. Engert [email protected] |
|
Note the debug line for the Omnikey 3821 pin pad, with pin.min_length = 4 and pin.max_length = 8, the max is before the min, 0804. The GemALto pdf above has in the example table: reader-pcsc.c:1667:pcsc_pin_cmd: PC/SC v2 pinpad block: 1E1E020800080402FF0000000000000D 0000000020008008FFFFFFFFFFFFFFFF PCSC shows this: |
|
The real source of the problem this line in iasecc_chv_verify_pinpad: pin_cmd->pin1.len = pin_cmd->pin1.min_length; Should it have been: The template for a verify command needsto be long enough to hold the largest pin. |
|
In reality it has to be not the pin1.min_length but pin1.stored_length. Template of PIN VERIFY command in P10 data has to be exactly of length of expected PIN.
I your example the real PIN length for the card is always 8 bytes, but PIN pad allows to enter 4 of them, the rest will be filled with PAD character. |
|
I have no problem with the Gemalto pinpad and min != max. I think that https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/reader-pcsc.c#L1370 is wrong. The application shall not change the byte order.
I propose to remove the use HOST_TO_CCID_16() in reader-pcsc.c Yes, I agree it is a mess. |
|
internal-winscard.h has: |
|
@viktorTarasov I disagree with the statement: I say the card will accept between 4 and 8 byte PIN, padded if needed. If the iasecc card does not accept a fixed length padded pin, PCSC revision 1.1 (I would expect this in v2.0) appears to allow the length of the pin typed on the pad to be inserted into the APDU. See reader-pcsc.c, looks like it tries to set bmPINBlockString bits 7-4 arount line 1325. Can you use data->pin1.length_offset so it will be set? card-sc-hsm.c and card-mcrd.c set data->pin1.length_offset = 4; |
|
If the ADPU Lc is just the length of the PIN, I have not tried this, as I don't have a card that requires just the pin or the pinpad reader Douglas E. Engert [email protected] |
"Padded PIN" has no meaning at the card level.
"Padded if needed" means that card receives always 8 bytes.
Iasecc card can accept fixed length, as a particular case of possibility to accept any (reasonable) length. There is no general convention for the length of PIN, neither no convention to use the PIN padding. In one case 4 bytes are used, in another 6 bytes.
Tried.
Do not see the attached diff. |
After inspection it appears that in my case pin-pad do not accept max_length more then 8. |
|
GemPC pinpad (depending on the firmware, probably) had limitations with min/max pin length and alos no support for the variable length PIN block, at least the (older?) versions I have. |
|
@LudovicRousseau while pro-cleanup, I'm afraid it would mean that for usable software "compatibility" mode for some readers on Windows is necessary, based on reader name (much like the HP keyboard). |
|
On 4/6/2015 5:12 AM, viktorTarasov wrote:
They way I read it, the offset = 4 effect tells the reader to use the size of the PIN the user types
Yes there is but requires hardware debug device between the reader and the card. I have seen a
Github did not print attachment, this was it: diff --git a/src/libopensc/card-iasecc.c b/src/libopensc/card-iasecc.c
- }
memset(buffer, 0xFF, sizeof(buffer)); data->pin1.encoding = SC_PIN_ENCODING_ASCII;
sc_log(ctx, "PIN policy: size max/min %i/%i, tries max/left %i/%i",
Douglas E. Engert [email protected] |
|
So it sounds like the pinpad support in isaecc was developed trying to use a non standard or defective pin-pad reader Does anyone have all the pieces (or some of the pieces )to address the original post? i.e. isaecc card, were they could try different size pins and a a different pin pad reader that does support variable length PIN block. Does any one have a sc-hsm or mcrd card and a GemAlto pin pad reader? @viktorTarasov if you try the patch, can you send the opensc-debug output of the On 4/6/2015 6:03 AM, Martin Paljak wrote:
Douglas E. Engert [email protected] |
|
In my above comments Lc should have said Le. |
|
Disregard that, Its Lc, the size of the data sent to the card. |
|
A way to debug a pinpad verify PIN is to use my test JavaCard applet https://anonscm.debian.org/viewvc/pcsclite/trunk/HandlerTest/JavaCard/ The applet implements a VERIFY command (INS=0x20) and also a DUMP command (INS=0x40) to get the PIN value sent to the card. |
|
@dengert With Gemalto IAS/ECC it works, as it works without patch, With Morpho's IAS/ECC card, that has stored pin length 4, min_length 4, max_length 16:
|
|
The more I look at this, I don't see if the IAS/ECC specifications say anything about I did see one note from 4 years ago. Both Viktor and I replied :) http:https://opensc-devel.narkive.com/vOv8KYOK/iasecc-problem-with-oberthur-compliant-card The interesting lines where in the VERIFY sent to the card has padding,the users says it was padded 00004576 APDU: 00 20 00 01 40 39 39 39 39 FF FF FF FF FF FF FF FF FF FF FF FF This could be a difference in how the card handles VERIFY or stores the PIN, could it have stored padding If the IAS/ECC allows padding then there is no need for the variable length substitution. I find it hard to believe that the big name card vendors who write the specs, make the card and pin-pad readers would On 4/6/2015 10:04 AM, viktorTarasov wrote:
Douglas E. Engert [email protected] |
|
@dengert Other IAS/ECC manufacturers do not use PIN padding: Gemalto, Morpho, ... To use PIN pad one has to know the stored length .
In IAS/ECC there are no obstacles to use padded PIN.
Do you think that the PIN-pad itself can overwrite Lc ?
Big name card vendors use their own middle-ware and have no obligation to be inter-compatible. |
|
On 4/6/2015 2:30 PM, viktorTarasov wrote:
Unfortunately.
The IAS/ECC does mention ISO7816-15, does OpenSC need to support this too?
I would have designed it that way, but it looks like it may not.
No, still looking. If you have a card which claims to not support padding, say min=4 max=8 and the the pin is actually length=6, for example 123456
So much for standards. So sounds like you are stuck with a fixed size pin if you want to use a pinpad reader.
Douglas E. Engert [email protected] |
Why? For example, everyone knows that PIN length (padded) for PIV card is 8 bytes. Make it less secure? There is always possibility to use longer PINs.
Many times you were saying "card support padding". As for your example: As anecdote: |
|
Just a few feedback :
I saw in http:https://www.acsiel.fr/iso_album/ias_ecc_v1_0_1_fr.pdf that, in paragraph 9.4.2, the applet change PIN is described and mention that the lenght of the PIN in stored in the PIN SDO. This is described in 3.4.5. Is this value used as "stored_length" shown by pkcs15-tool --list-pin ? Because it seems that this value is "public" If we have no choice other than having a fixed-size pin length, maybe I could be possible to parameterize this in opensc.conf. Users may be warn that changing the default pin size (4) may break compatibility under other OS... |
|
Just for information, I gave a try to http:https://git.gniibe.org/gitweb/?p=gnuk/gnuk.git;a=blob;f=tool/pinpadtest.py with my pinpad reader. I was able to check a PIN with a length of 6 successfully. (for 5 I needed to pass the -pinmin 4 option) I just commented out openpgp verification in main() (l.238) |
|
Main point: "SO WHY DID THIS PRACTICE CHANGE? See below. On 4/7/2015 3:28 AM, viktorTarasov wrote:
Minor concern, save for some other discussion.
It could, depends on what the card does with pad characters. Let's say card receive 31:32:33:34:34:35:36:FF:FF NIST 800-73-e Part 2 Section 2.4.3 Authentication of an Individual Says: It goes on with some examples, and talks about any Global Pin. This NIST wording works with a card that understands 'FF' as padding or just another character. And I think it was added Is there any IAS-ECC statement like this on the PIN values and padding in any official documents? (NIST is part of the US Department of Commerce. NIST 800-73-2 Part 3 enforces interoperability at the card edge.
Pin pad can supply padding, With this sent to the reader, (spaces added) 1E 1E 02 08 00 0804 02 FF 0000000000000 D000000 00200080 08 FFFFFFFFFFFFFFFF
The padding could be any character like zero padding. Sounds like you saying the Gemalto, Morpho, ... store the length based on the length of the data.
SO WHY DID THIS PRACTICE CHANGE? If a 6 byte PIN was padded when created and padded to N bytes each time it is used, either by the middle ware, How are the pins created on officially issued cards? If officially issued cards are now created with unpadded pins, it sounds the change broke the use of pinpad readers with some cards
Are you saying users entered 1234 and padding is 56? i.e. 31323334 and 3536 or did you mean "first 6 characters"? The iso7816.c pin commands, understand how to extend padding with FF (or I think any other single character like 00)
Douglas E. Engert [email protected] |
|
If the SDO can be read, then it could be used as the Lc value in the pinpad template. On 4/7/2015 8:00 AM, estieux-tehtri-security wrote:
Douglas E. Engert [email protected] |
|
Sounds like that is there way to get around the same problem if pinpad reader can not change the Lc value. Is the SDO created by the card during a pin change operation, or is it updated If it can be read and the middleware needs to update it, is there code missing in OpenSC to update it? On 4/7/2015 9:01 AM, estieux-tehtri-security wrote:
Douglas E. Engert [email protected] |
|
I think I misexplained : the tool mentioned does not need to know the Le 07/04/2015 16:46, Doug Engert a écrit :
|
|
Great find... http:https://git.gniibe.org/gitweb/?p=gnuk/gnuk.git;a=blob;f=tool/pinpadtest.py This has a lot of useful information, including pinpad readers that work with variable length, This line looks interesting: Douglas E. Engert [email protected] |
|
Even with your that explanation, I think the python script is doing something Can you: Then run the script with -pinmin 4 and other options as needed. Before entering the PIN, recode what it is. Then enter the 5 digit PIN on the pinpad. Recode the status PCSC returns from the card, If it worked, it will be 9000. What this should show is what working middleware send to the reader, Can you also send Thanks. On 4/7/2015 10:00 AM, estieux-tehtri-security wrote:
Douglas E. Engert [email protected] |
|
I have not seen cards that can strip the PIN and return OK on validating of only the part of received PIN.
Here APDU template in P10 verify data is composed by MW, including the padding.
No, its two different PINS.
In Oberthur's case there is convention to use padded PIN (64 bytes), adopted by Oberthur's MW for all their cards, not only IAS/ECC. The same was implemented in OpenSC to be compatible with native MW. No such convention was adopted by the others.
I mean PIN "313233343536".
In IAS/ECC PIN SDO meta data there is no 'stored-length' parameter. Only 'min' and 'max'. |
|
OK, here is my debugging output when launching python pinpadtest.py My testing environment is ubuntu 14.04 LTS x64 in a virtualbox Pinpad reader is a Gemalto CT-710 (Bus 002 Device 021: ID 08e6:34c2 tail -f log-pcsc.log |grep -v "CMD_GET_READERS_STATE" |grep -v -- Here I type my PIN on pinpad Le 07/04/2015 18:21, Doug Engert a écrit :
|
|
Much of this discussion is also covered in: The Verification Data Structure is: bTimeOut = 0 I suspect the actual APDU used is: The main difference I see with this vs what OpenSC does is the bmFormatString For some readers the script has a --add_byte which sounds like #309 Vikyor said: "The only PINPAD that I have is 'Gemalto GemPC PinPad' and apparently it has Not clear type of card you have. So to do this correctly, the bmFormatString which have bit7 = 1, for bytes. Some readers may never work with the variable length pin. On 4/7/2015 5:04 PM, estieux-tehtri-security wrote:
Douglas E. Engert [email protected] |
|
With "recent" Gemplus/Gemalto readers you can use FEATURE_CCID_ESC_COMMAND_Gemalto_features.py [1] to know the min and max PIN length supported by the reader. You can see the results with some readers at [2]. If available, the information is reported by the CCID driver using PCSCv2_PART10_PROPERTY_bMinPINSize and PCSCv2_PART10_PROPERTY_bMaxPINSize [1] https://anonscm.debian.org/viewvc/pcsclite/trunk/PCSC/UnitaryTests/FEATURE_CCID_ESC_COMMAND_Gemalto_features.py?view=markup |
|
I've done the same debuging using opensc-explorer with a fixed 5 digits pin (hardcoding it in opensc) and here is the debug output : Excepted an error from me, I see another difference (excepted timeout). The bTeoPrologue is 00 00 00 in pinpadtest.py. Don't know if it is important. |
|
Original problem is card-iasecc.c only supports a fixed size pin when using a pinpad reader. IAS/ECC cards will not accept a verify APDU with a fixed Lc and a padded pin. card-sc-hsm.c and card-mrcd.c appear to require the same format of Lc is length of pin Both of the above issue discuss this and code was added to reader-pcsc.c to send the 4 Both issues point out that PART10 does not appear to cover this situation yet most I would propose that the card-iasecc.c do what the card-sc-hsm.c and card-mrcd.c To make sure SC_CCID_PIN_UNITS_BYTES is set, I would also propose that reader-pcsc.c line 1331 If there are readers that are known not to work or require 5 byte APDU with the Lc set to zero @LudovicRousseau can your list of supported readers be extended to list if they In the long run, PART10 should be updated to standardize how setting the Lc value from the pin length. Douglas E. Engert [email protected] |
|
I would expect that to work, as you sent the length of your pin in the abData (APDU template) This should be the same APDU that would be sent to the card, if you did not use a pinpad reader. I believe the reader-pcsc.c fills in the bTeoPrologue if T=1 is being used. On 4/8/2015 8:33 AM, estieux-tehtri-security wrote:
Douglas E. Engert [email protected] |
|
Feel free to ask me if I can help debugging. If necessary, I can even lend the reader. |
|
They should be under $50. The problem is I don't have a card that uses the variable length pin format, like the IAS/ECC cards. If not a IAS/ECC card, what other card could I use? On 4/9/2015 7:41 AM, estieux-tehtri-security wrote:
Douglas E. Engert [email protected] |
|
I tried CardMan 3821 but it do not works without full VERIFY PIN template: @estieux-tehtri-security |
|
Currently my PIN is 5 bytes and the result of the command is : PIN [Puk pour Pin User] |
|
Current PIN is 5 bytes, but stored-len is 4. |
|
Card was delivered with default 4 bytes length PIN (1234). I changed the PIN through pkcs15-tool --change-pin. The applet on the card is not the latest, it is the 1.4.5 version (and not 1.6). |
|
The python script on previous issues with pinpad readers point out that different readers The APDU may need to be 5 bytes, i.e. add a Lc=0 byte. The Omnikey 3821 (which may be the same as CardMan 3821 but newer) may need may need the lc = 0 byte. I am attaching the lastest patch I have. It adds the Lc=0 byte, sets the system units are bytes, On 4/9/2015 11:20 AM, viktorTarasov wrote:
Douglas E. Engert [email protected] |
|
@dengert |
|
@viktorTarasov |
|
If forgot to say that when I changed the initial pin code to a 5 byte length (or another size) PIN, I used a non-pinpad smartcard reader. |
|
The MODIFY is harder. The reader would have to add the length of the two pins Next we need a way in reader-pcsc.c to look up reader variable length pin info, It would be nice if pcscd could return this, but when run on Windows, the Windows The comments in the python script, and maybe other places, is a start for the @LudovicRousseau could you add something like this to: I see you have bPINSupport, Features and Limitations Any suggestions on how to collect this information? Any other developers of cards that use the variable length PIN info should also be interested in this. On 4/10/2015 2:24 AM, viktorTarasov wrote:
Douglas E. Engert [email protected] |
|
I use the same script (pinpadtest.py) successfully to modify my pin on pinpad with various scenario like old and new PIN 4 bytes length or old and new PIN with different length. |
|
@estieux-tehtri-security |
|
|
@estieux-tehtri-security |
|
my fault, I switched back to a 4 bytes PIN. Here's the output for a five-byte PIN (PUK is still 4-bytes) |
|
@estieux-tehtri-security |
|
Functionnaly,it works. I saw that you implemented a way to catch the size of the PIN SDO and send an appropriate APDU with this size. The minor side effect is that if the card is waiting of a n bytes PIN and you type a wrong m (>n) bytes PIN, the error counter will not be incremented. Personally, I can live with that. What I'm wondering is what can be the behavior of the pinpad reader if it implements a "firewall feature" ? Will it accept your APDU ? Mine (CT-710) is supposed to have a "firewall" feature but I saw that it does not work in reality (I was able to send PIN through command line). And is there any problem reusing the APDU seen in pinpadtest.py with a LC=0. I think I missed this point. |
|
Commit 5757d82 breaks binary compatibility. You need to bump the soname to libopensc.so.4, don't you? |
I'm using a Morpho ypsid S3 card IAS-ECC card. With a basic card-reader, opensc tools are working correctly (key creation, PKCS11 interface, ...).
If I want to use the card with a pinpad reader (Gemalto CT710) I'm facing a problem. Every action requiring to type the PIN will fail and it seems that OpenSC is the culprit as the pin on the card may have variable length :
Length : min_len:4, max_len:16, stored_len:4So for example, if I use opensc-explorer to verify the PIN (verify CHVx), I always get the message "Different values for PIN min and max lengths is not actually compatible with PinPAD."
But if I comment out https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-iasecc.c lign 1804 to 1809, and keep a 4 digits pin, opensc is able to deal with the pinpad reader. If I use, let's say, a 6 digits pin, I just need to fix lign 1810.
So could it be possible to improve pinpad support for ias-ecc ? Is there a real technical limitation that prevent to deal with variable pin size ?
The text was updated successfully, but these errors were encountered: