[Pcsclite-muscle] What's responsible to filter out Le in Case 4 C-APDUs under T=0?

Francois Grieu fgrieu at gmail.com
Tue Feb 8 01:58:38 PST 2022

Recap + new info: Specifically under Windows with GemCCID driver (Gemalto dated 2016-08-08 from Windows Update), several Gemalto/Thales readers 
pairing with this driver (including GemPC USB-SL, and IdBridge K30 SIM-format 
reader), with T=0 Smart Cards, SCardTransmit reports a Mute Card error when a 
Case 4(S) command-APDU includes Le after the data.
The issue disappears if Le is removed from the C-APDU, or with the Microsoft 
USBCCID WUDF driver (10.0.19041.1 dated 2006-06-2).

Example with my bank card. First try is without Le, and works. Next two attempts 
are with Le set to the number of data bytes expected from the card, then Le set 
to 00 meaning all available data.
     > Reset
     < 3B 65 00 00 20 63 CB BD 80
     > 00A4 0400 06 315041592E53
     < 61 1E
     > 00C0 0000 1E
     < 6F 1C 84 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 0A 88 01 01 5F 
2D 04 66 72 65 6E 90 00
     > Reset
     < 3B 65 00 00 20 63 CB BD 80
     > 00A4 0400 06 315041592E53 1E
     #   Error, mute card
     > Reset
     < 3B 65 00 00 20 63 CB BD 80
     > 00A4 0400 06 315041592E53 00
     #   Error, mute card

I also tried a minimal PyScard code:
     from smartcard.System import readers
     c = readers()[0].createConnection()
     dta,sw1,sw2 = c.transmit([0x00,0xA4, 0x04,0x00, 0x06, 
0x31,0x50,0x41,0x59,0x2E,0x53, 0x00])
which reports "smartcard.Exceptions.CardConnectionException: Failed to transmit 
with protocol T0. Paramètre incorrect."
Again that code works without Le, or with the Microsoft USBCCID WUDF driver.

I captured the USB traffic with WireShark and usbccid filter. When Le is 
omitted, I see the 11-byte C-APDU sent to the reader at the end of a 48-byte 
packet, then the 2-byte SW at the end of a 39-byte packet from the reader. But 
when Le is included, nothing is shown by WireShark.

I conclude the GemCCID/Gemalto driver somewhat blocks C-APDUs with Le under the 
T=0 protocol.
It's installed by Windows as an (optional) driver update, and recommended by the 
As such, normal users are likely to use it.

I think it's a driver bug. But is there an authoritative reference that it's 
valid for an application to send complete C-APDU (thus including Le in case 4S) 
to SCardTransmit? And perhaps one that it's not SCardTransmit's job to remove Le 
under T=0?

   Francois Grieu

More information about the pcsclite-muscle mailing list