From: Jean-Luc Giraud (giraudbtinternet.com)
Date: Tue Aug 05 2003 - 19:29:51 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Thursday, July 24, 2003, at 08:18 PM, Michael Bender wrote:
>
> I have run into this same situation writing T=0 firmware for a reader.
> I have asked around to other smartcard groups, experts, reader firmware
> writers and even my guru :-) and there is absolutely no consensus on
> whether or not the reader or the application (or somebody in the middle
> somehwere) must handle GetResponse.
>
> In my case, I handle it in the reader, but I have complaints from
> some smartcard application developers that tell me that their apps
> break because they *expect* to handle the GetResponse processing
> after a specific APDU - to me, that's just bogus programming, but
> what can you do?

One way to do it (it is the way it is done in the GemPC410/430 driver)
is to check the length of the command buffer given in the SCardTransmit
(works only for T=0 TPDU):

Case 1:
Cmd = CLA INS P1 P2
L(Cmd) = 4
-> Treat as APDU

Case 1:
Cmd = CLA INS P1 P2 P3 (=0)
L(Cmd) = 5
-> Treat as TPDU

Case 2:
Cmd = CLA INS P1 P2 Le
L(Cmd) = 5
-> No difference between TPDU and APDU (T=0)

Case 3:
Cmd = CLA INS P1 P2 Lc Data
L(Cmd) = 5 + Lc
-> No difference between TPDU and APDU (T=0)

Case 4:
Cmd = CLA INS P1 P2 Lc Data Le
L(Cmd) = 5 + Lc +1
-> APDU, perform chaining

Case 4:
Cmd = CLA INS P1 P2 Lc Data
L(Cmd) = 5 + Lc
-> TPDU, treat as Case 3 and return 61 xx.

Any comments?

Cheers,
JLuc.

_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.musclecard.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]