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

[Ludovic Rousseau]

Hello François,

Le lun. 7 févr. 2022 à 17:01, Francois Grieu <fgrieu at gmail.com> a écrit :
>
> 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 4.1.4.0 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
> section 12.1.1).
>
> 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.

What happens on GNU/Linux with pcsc-lite and my CCID driver?

Bye

-- 
 Dr. Ludovic Rousseau