Search code examples
pcsc

Can Le be part of the data passed to PCSC SCardTransmit for a Case 4 command regardless of protocol?

ISO/IEC 7816-3:2006 (12.1.2) defines the bytestring for a command to a Smart Card that sends data and is expected to produce some beyond a status word:

A command APDU of case 4 consists of a header, a LC field, a data field and a LE field.

ISO/IEC 7816-4:2020 (5.2) is similar. I restrict to the short case (4S) where

  • LC is a byte in 01H…FFH directly coding integer NC (the number of bytes in the data field, thus discounting the 4-byte header)
  • LE is a byte in 01H…FFH directly coding integer NE (the number of bytes expected from the card in response when no error occurs, discounting status words), or 00H meaning maximum (or equivalently NE=256).

In such case 4S, can LE be part of the data passed to PCSC SCardTransmit regardless of the protocol?

In other words, when passing such command to PCSC SCardTransmit, can we set cbSendLength to NC+6 regardless of the protocol?

I ask because I have a reproducible issue where including LE in a command (e.g. 00 A4 09 00 02 20 03 42 with cbSendLength = 8 in a context where the card will actually return a status word 6A 82 and no data) causes SCardTransmit to fail. The value of the LE byte is immaterial. That's with T=0 cards from different manufacturers and applications, several readers of different models but all with the same manufacturer-recommended Windows driver (GemPcCCID 4.1.4.0 of 2016-08-08 signed 2018-07-26, there). The problem vanishes with Microsoft's default CCID WUDF driver, or if I set cbSendLength to one less (thus removing LE). I have so far found no other reader/driver configuration triggering that issue, so I'm tented to say that's a driver issue (or at least an issue of the combination of that driver and the PCSC service it's supposed to work with).

I'd like some specification that tells if it's legit to include the LE byte to SCardTransmit, and I'd prefer something not Windows-specific.

I understand that if somewhat the application knows that the protocol T=0 is used, it's easy to omit the LE byte from the initial SCardTransmit, and I see how LE can be handled subsequently when the card sends a 61xx status word. However some contactless Smart Card readers pretend to be T=0 when they really use the ISO/IEC 14443-4 protocol, and then the LE byte is useful in some cases, thus I don't want to use that option.

Addition: the spec of ScardTransmit has:

For T=0, in the special case where no data is sent to the card and no data expected in return, this length (of the data passed to ScardTransmit) must reflect that the bP3 member is not being sent; the length should be sizeof(CmdBytes) - sizeof(BYTE)(that is 4, the length of the C-APDU).

Therefore, under in T=0, in cases 1, 2S, 3S, what's passed to ScardTransmit is the C-APDU, and in case 1 that differs from the C-TPDU. I'm asking if there is a reference settling about the imperative, in case 4S under T=0 specifically, to strip LE from a C-APDU (making it the C-TPDU) before passing it to ScardTransmit, similar to the above prescription to not make such conversion from C-APDU to C-TPDU in case 1 under T=0 (which ScardTransmit, the driver, or the reader will perform).

Solution

  • According to ISO/IEC 7816-3:2006(E) command for T=0 protocol consists of CLA-INS-P1-P2-P3-Data, i.e. there is no any field behind data.

    Clause 12.2.5 Case 4S is related to command-response pair transmission by T=0. It says: The command APDU is mapped onto the command TPDU by cutting off the Le field.

    So, no Le byte is allowed at the end of command int the case 4S.