[Pcsclite-muscle] pcsclite-muscle Digest, Vol 25, Issue 2

[Michael StJohns]

On 2/8/2022 1:23 PM, s.ferey wrote:
> Hello,
>
> Le 08/02/2022 à 17:59, pcsclite-muscle-request at lists.infradead.org a 
> écrit :
>> Recap + new info: Specifically under Windows with GemCCID driver 
>> (Gemalto
>> 4.1.4.0 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).
>
> When T=0 protocol is used a case-4 can NOT contain a Le.


Actually, I'm looking right at ISO7816-3 and Case 4 by definition 
contains an Le field in the APDU.

Let's say you have a command that sends 10 bytes of data and receives 5 
bytes back.  Your APDU is 0x00 0x93 0xaa 0xbb 0x0a <10 bytes of data> 0x05.

This encodes (case 4S) to a TPDU of:

0x00 0x93 0xaa 0xbb 0x0a <10 bytes of data>

Which should result in a response of: 0x90 0x00 OR  0x61 0x05

Which should then be followed by a second TPDU of: 0x00 0xC0 0x00 0x00 
0x05 -- that 0xC0 is "GET RESPONSE"

Which should result in a return of: <5 bytes of data> 0x90 0x00, and 
that result should be passed up to the caller.

The P3 value in the GET RESPONSE TPDU should be the minimum of the Le in 
the original APDU or the XX in the 0x61XX if you get one.  Note that 
0x00 for Le or P3 actually means 256 bytes so 0x00 is actually greater 
than 0xFF in this case.

If you do not include the Le, then this is a Case 3 command.


Looking at Microsoft SCardTransmit - 
https://docs.microsoft.com/en-us/windows/win32/api/winscard/nf-winscard-scardtransmit 
- it looks like this is designed to  send TPDUs rather than APDUs, but I 
don't find that stated explicitly.    That's not an issue for T=1 as the 
TPDU == APDU, but means that for T=0 you might have to do extra work.

In the related question, it looks like the working driver is looking at 
the length of the send buffer (pbSendBuffer/cbSendLength) and -  by 
checking bP3 against the total length of the data part of the field 
determining that someone is passing in an APDU rather than the 
appropriate TPDU. (E.g. for the T=0, bP3 should equal cbSendLength - 5 
for a Case 3 or 4 TPDU vs APDU).  If it sees the mismatch, it does 
something appropriate like trimming off the Le byte or doing the whole 
TPDU/APDU mapping itself.  The driver that's returning a mute response 
is probably sending the passed in APDU as a malformatted TPDU to the card.

For the javax.smartcardio code, I believe that the various functions do 
the appropriate thing for T=0 with respect to APDU to TPDU mapping.  It 
may be useful to look at whether the Python commands do the right thing.

Mike


>
> The (overall) result is so undefined, the card may choose to not 
> respond, or the firmware or diver may generate an error (or for some 
> maange itself the Get Response).
>
> AFAIK, your error is not related to a specific Gem+ driver but due to 
> an invalid use of the protocol.
>
> Rgds,
>
> Sylvain.
>
>
>
>
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle