Fix Lc byte in VERIFY PIN block for PC/SC PIN PAD reader #317
Conversation
|
Last time I checked (a long time ago, I must admit) PIN change worked without problems. Has anything changed in the past few years for SPR532 firmware ? |
sc-hsm: Fix Lc byte in VERIFY PIN block for PC/SC PIN PAD reader
|
This is similar to Micardo. What is still left to be fixed ? |
|
Reading CCID revision 1.1 2005, in all the examples in section 8, the abPINApdu includes In the discussion, it looks no Preliminary data is sent, leaving it up to the CCID, In the examples, when the pin length it to be modified, the Lc is not modified, but the first byte after the Lc is None of the examples modify the Lc. Are you sure that the readers can handle modifying the Lc? You say the card is expecting variable length pin, but is that as the first length byte of the pin data, or the Lc? With the last example, 8.2.2, a pin modification with PIN length management the Preliminary data Note the FF padding bytes will still be the command, and Lc is not changed. There is no way to change the Lc to work with a PIN modification command with truncated pins. IMHO, Expecting the reader to change the Lc, is not what the standards define or the reader expecting. To looks like sending the Preliminary data is what should be done, and either use padding, with no On 11/3/2014 9:20 AM, CardContact Software & System Consulting wrote:
Douglas E. Engert [email protected] |
|
As I said, the specification as it happened (starting with "teletrust spec") did not cover this (variable length PIN) use case but this is what seems to work with most of the pinpad readers that are otherwise credible, testing has shown. |
|
I agree with Martin, it's what we observe with the readers we are testing with. And btw. an ASCII encoded PIN with length in Lc or a PIN with F2B are the only two formats I've seen in the wild. I have no idea where all this stuff with shifting, converting, padding is good for. Same for modify PIN, you either have 00 24 00 P2 10 F2B_PIN_OLD F2B_PIN_NEW or 00 24 00 P2 Lc OLD_PIN NEW_PIN as the card knows the length of the old PIN. I guess what's really missing is a common test standard for PIN PAD readers. I'm in the process of adding some functionality to our APDU test applet, so that it records incoming APDUs. This way we can build a test framework to check the different encodings. |
|
It would be nice if we could rather somehow initiate a CCID spec amendment? Not a short trip but eventually something that would be needed. |
|
On 11/3/2014 2:14 PM, CardContact Software & System Consulting wrote:
Well padding is used, so the Lc in the verify (or other pin commands) isset to the max pin length, and the card only uses the non padding bytes for the pin. For example, using an Omnikey 3821, and a NIST PIV demo card with max pin = 8 with pin 123456 OpenSC sends: 0x7fe8d8181740 16:53:11.516 [opensc-pkcs11] ../../../src/src/libopensc/pkcs15-pin.c:293:sc_pkcs15_verify_pin: called The above appears to match 8.1.5 Pin uses ASCII format conversion with padding. pcscd: 00000010 Control TxBuffer: 1E 1E 02 08 00 08 04 02 FF 00 00 00 00 00 00 0D 00 00 00 00 20 00 80 08 FF FF FF FF FF FF FF FF When not using a pin pad reader, OpenSC would send Using a HSM without a pin pad, (I see where you are setting Lc=pinlen) pcscd: 00000008 APDU: 00 20 00 81 06 31 32 33 34 35 36 If I try doing a verify using the padding using opensc-tool opensc-tool -s 00:20:00:81:08:31:32:33:34:35:36:FF:FF APDU: 00 20 00 81 08 31 32 33 34 35 36 FF FF So as you say the HSM does not understand padding. If it the HSM did understand the padding, the Lc could stay constant...
Douglas E. Engert [email protected] |
|
I assume F2B is Format 2 PIN block and is also used in ISO 9564 :according to In the format they refer to the fill nibbles, of 15 The point I am trying to make, is PIN PAD readers are more likely to support the CCID standards, The CCID standard I have is 1.1 from April 2005, Is there a newer version? where bmPINLengthFormat is clarified, or an example of changing Lc? It appears that Lc in the CCID 1.1 is not defined as a single byte, thus opening up the ability to On 11/3/2014 2:14 PM, CardContact Software & System Consulting wrote:
Douglas E. Engert [email protected] |
|
CCID 1.1 is the current version. The whole PIN verification mechanism goes back to the MKT specifications written in 1990s for the German e-Health card. Verify with Lc denoting the PIN length was pretty much the standard at that time. It changed to F2B format, because several manufacturer introduced a self-encrypted PIN format, where the 8 byte F2B block was encrypted using the same data as key in a single DES operation. Later the MKT specs and their French equivalent (was it called SCP ?) were the basis for CCID, which then was the basis for PC/SC part 10. It's been the same people from various card [reader] manufacturer involved in writing those specs. So it's not a surprise, that their reader (in particular Reiner-SCT, Identiv / SCM and Omnikey / HID) support this format. The examples in the CCID specs are probably showing just the more complex constructions. Anyway, we should probably go for better specifications and a proper comformance test. |
The SmartCard-HSM uses a variable-length PIN, whose length is indicated in Lc.
This patch changes the PC/SC PIN Block used for PIN PAD reader and removes the Lc byte, which is automatically added by the reader.
This patch partially fixes #309, however while PIN verification now works on Windows, PIN modify fails with this reader on Linux. The issue is related to a firmware bug confirmed by Identiv.