[Pcsclite-muscle] What's responsible to filter out Le in Case 4 C-APDUs under T=0?
fgrieu at gmail.com
Mon Feb 7 07:28:44 PST 2022
I have a confirmed case where passing to SCardTransmit a valid "Case 4(S)"
Command-APDU, with incoming data followed by Le, leads to a "mute card" error.
That's under Windows 10, with an IdBridge K30 (SIM-format) reader, specifically
it's manufacturer-supplied GemCCID 126.96.36.199 driver as obtained thru Windows
Update, and several T=0 card types.
00xx xxxx 06 xxxxxxxxxxxx 08
\ \ \ \ \_ Le
\ \ \ \_ data in
\ \ \_ Lc
\ \_ P1P2
\_ CLA INS
The problem vanishes, with the card answering SW=6108 (then a Get Response
getting the 8 bytes of data and final SW as expected) when I either
- remove Le = 08 from the C-APDU
- change the driver to Microsoft's WUDF driver
I understand why the problem occurs and can depend on the driver: the T=0
protocol is such that the card should not receive the 08, and something has to
filter it out from the C-APDU (which includes it, see ISO/IEC 7816-3:2006
My question is: in the PC/SC stack, who should do this filtering ?
1. the application, when it senses that T=0 is used (and then, how)
2. winscard / pcsclite's SCardTransmit function
3. the driver
4. the reader (perhaps per CCID)
References appreciated since in options 2/3/4 I'd want to file a bug report to
whoever is responsible.
More information about the pcsclite-muscle