Smart Card Reader T0 T1 communication on APDU level

Question

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

Answer 1

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.