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

Philomel

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. – Shew

Taking a look at this question and answer+comments is useful : #28856430 – Shew

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!? – Philomel

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. – Shew

I know this guy and I saw his blog. I was trying to find an answer there as well. I even ended up emailing him and asking this question but I was surprised what he replayed. Probably his arrogance doesn't allow him to help people. :) – Philomel

Oh no! he replay to emails very friendly :) maybe he is busy. – Shew

@Alex : Read the section 6.3.1 Selection of transmission parameters and protocol of specification ISO/IEC 7816-3, there you find the logic which determine what protocol to be used.If any doubts then please ask. – Sammy

@AnkitPandey thanks man. I red that part of the spec more carefully and still I have problems to grasp the logic ATR(TD1) = 1 i.e. T1 is a default protocol ATR(TA2) = 0 i.e. no card special mode (card is in negotiable mode) Reader Feature Descriptor reports no AutoPpsCur and no AutoPpsPar that means we have to PPS to the card to negotiate the communication. When I do PPS I got error that it is not supported. Then according to the spec I have to use default protocol with the default parameters which is T1 protocol in this case. But the Reader fails to communicate in T1 but it does fine in T0 – Philomel

That's the point I don't understand how I can figure that out!? Because all others readers I have work fine and all of them use T1. – Philomel

Another weird thing I do not understand is that PPS is Protocol and parameters selection between host and card or is it between reader and the card? Why it actually depends on the reader? I mean PPS fails on that buggy Cherry xx44 reader but it works on others. Even though Cherry reports that it supports both protocols T0 and T1. – Philomel

@Alex : As per the ISO/IEC 7816-3 (under section 6.3.1) : 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. That means in your case ATR(TA2) = 0 i.e. Card is in negotiable mode but PPS exchange fails i.e. your card need not support PPS exchange. That means Card offers only one transmission protocol (which is T0 in you case, I think). – Sammy

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. – Sammy

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.

Philomel

Answer 2

In general, the ATR tells you what the card supports (and what not). The ISO 7816-3 specification is the correct place to look for the correct behaviour, i.e. programming.

The ATR consists of the octets TS|T0|TA1|TB1|TC1|TD1|...|historical bytes|TCK. Not all of the mentioned values have to be part of the ATR, though. You have to parse the ATR checking for all TDi (i=1..n). Please check the PC/SC-lite sources, an ATR parser is provided there.

The least significant four bits of TDi bytes tell you, which protocols are supported (the four LSBs encode from 0 to 15, 0 is T=0, 1 is T=1). The protocols 0..15 shall be sorted in ascending order in the ATR.

Special case: if TD1 is absent, then T=0 is the only supported option. If any of the TDi bytes state T=1 support, then use it. ELSE: T=0

Urticaria