Smart Card Reader T0 T1 communication on APDU level

8
votes

I am struggle to understand what protocol I have to use to communicate with the card T0 or T1? So, correct me if I am wrong, but the reader actually decides by itself what protocol to use to communicate with the card if the card supports both.

So my logic right now is:

// if ATR(T1) -> set_params(T1 structure) -> T1 APDU communication
// if ATR(T0) -> set_params(T0 structure) -> T0 APDU communication

But it turned out that the logic is wrong and it accidentally worked for majority of readers. I have just discovered the reader that expects T0 communication even if the card ATR returns T1.

Q: What is the logic must be to determine what protocol to use? And if there is a spec behind it, can you please point me out to it.

Edited: I forgot to mention that my code is at pre-boot environment (UEFI) before the OS. So I don't have (use) any APIs whatsoever. My code is at byte-stream APDU level and talks directly to hardware using UEFI UsbIo communication.

Thanks to all!

All the best,

Alex

1
smartcardapdusmartcard-reader
The related specification is ISO/IEC 7816 part 3. To have a T=0 or T=1 communication, both the card and the reader must support it. Most of nowaday cards support only T=1 and most of readers support both protocol. – Ebrahim Ghasemi
Taking a look at this question and answer+comments is useful : stackoverflow.com/questions/28855930/… – Ebrahim Ghasemi
Thanks man. That post explains some of the issues. So my guess is that's exactly why the muscle code is so huge and junky and it has a hardcoded list of supported readers!? – Alex
Your welcome. Unfortunately no idea about what is muscle code. I saw a great list of T=0/T=1 compatible smart card readers in on of "ludovic rousseau" web sites. If you think it is useful do a google search for his name. :) I eagerly waited for an answer below this question. – Ebrahim Ghasemi
Let me correct one point : if ATR(TD1) is present (i.e. set to 1) which means T=0 is the default protocol (not T=1). Please refer section 8.2.3 of same specification (ISO/IEC 7816-3) i.e. If TD1, TD2 and so on are present, the encoded types T (type of protocol) shall be in ascending numerical order. If present, T=0 shall be first, T=15 shall be last. That means in your case as TD1 is present (i.e. set to 1) so T=0 is the 'first offered transmission protocol' and as your Card do not support PPS handshaking (and TA2 =0), so it is supporting only one protocol which is T=0 in this case. – Bhanu

1 Answers

4
votes

Ok, I re-read the spec (7816-3) again and again, maybe 5 times or more. These are my findings:

According to the Spec there are no such things as "automatic" and "default" protocols whatsoever.

8.2.3 Interface bytes TA TB TC TD

The “first offered transmission protocol” is defined as follows. If TD1 is present, then it encodes the first offered protocol T. If TD1 is absent, then the only offer is T=0.

Ok going further...

6.3.1 Selection of transmission parameters and protocol

... until completion of a successful PPS exchange (see 9.3), after what the interface device shall start the negotiated transmission protocol using the negotiated values of the transmission parameters.

Next one is more interesting in this case:

Otherwise, the interface device shall have started the “first offered transmission protocol” (see TD1 in 8.2.3). The interface device shall do so when the card offers only one transmission protocol and only the default values of the transmission parameters. Such a card need not support PPS exchange.

With Card A it is not entirely true because it does support PPS exchange! It is simply doesn't work with Cherry reader.

Ok, the next key point is in 6.3.1:

NOTE 3 An interface device facing a card in negotiable mode and supporting neither PPS exchange nor the “first offered transmission protocol” can perform either a warm reset or a deactivation.

Thus in case of Cherry reader it doesn't follow the standard! it shell support communication in first offered protocol, which is T1.

I found a really interesting stuff in SmartCard Handbook, 4th Edition 8.2 PROTOCOL PARAMETER SELECTION (PPS) chapter:

The PPS process described above is not suitable for changing protocols with a terminal that has its own specific protocol but cannot execute a PPS.

Figure 8.11 A possible sequence for switching between two transmission protocols supported by a smart card without using a PPS. With the sequence outlined here, the terminal does not have to perform an explicit PPS, but can nevertheless switch between the two protocols by initiating a reset...

...This solution is not ideal from a technical perspective, since a device should always behave the same after each reset, but it is certainly a pragmatic solution for a heterogeneous terminal world.

It doesn't apply to my card though because card doesn't switch the protocol by performing warm reset. But it might be an answer to the weird behavior of the reader.