How do I distinguish different ISO 14443-4 cards?

Question

There are different smart cards supporting ISO 14443-4. For example, Mifare Plus with its native command set. Or other cards with different command sets (i.e. 7816-4 APDUs).

I develop some software for a card reader and I need to identify which commands the card supports (for example, if it supports commands in ISO 7816-4 structure or not).

What is the recommended way to distinguish between them? Should I just try some commands from Mifare Plus command set and check if I get correct replies? Or is there any smarter way to do it?

Post

Answer 1

During the connection protocol some parameters are exchanged that you can use to determine the card's capabilities. For example, the SAK byte will inform the reader whether the card is ISO 14443-4, and even if it is MIFARE Plus (there is an NXP document explaining which bits you have to read). Then you have ATS (Answer To Select), which contains a lot of useful information about the card. Have a look at ISO 14443-4 and at ISO 7816-4.

Schutt

Yes, I know that, but ATS can be changed in Mifare Plus cards, so it's not 100% reliable. And I suspect there can exist other cards (not Mifare family) which have the same SAK. NXP recommends to evaluate only bit 6 of SAK to see if the card supports ISO 14443-4 and to ignore other bits. – Post

Probably the best course of action will be to implement a "pragmatic" approach: first use SAK and ATS (so you'll cover most cards) plus some test commands for the corner cases. Will your reader software have to support all generic Mifare Plus cards, or just the ones personalized for a specific application or service? – Schutt

I think it'll be enough to handle the personalized ones, plus new blank cards for personalization. – Post

Okay, I've come with my own answer. I think that the whole purpose of ISO 14443-4 is to provide a generic way to exchange information with different cards. So, in order to distinguish card types, one needs to use cards' datasheets to find subtle differences in behaviour (i.e. different command sets). There is no smarter way. – Post

That's correct - ISO 14443-4 defines a transmission protocol, but then it is up to the card/application implementer what commands to design. But still, the ATS has some useful information. For example, if you have an NFC-enabled Android phone around, you can install an app to quickly see that kind of information. I usually use TagInfo by NXP. – Schutt

Answer 2

Never use ATQ! Use SAK only for non 14443-4 cards(e.g. Mifare Classic)! ATS is also bad practice as different card vendor can set it differently.

Now how to do it:

Only way how to think about card and don't get crazy is imagine it like it is full communication stack(see OSI model).

Keep in mind that your goal is to connect two applications, one in the card and one in your computer. 14443-4 provides mechanism for sending messages and don't care about its content.

On top of it there are implemented interfaces of different cards and if both sides: card - carddriver are compatible they will communicate. If not, there will be errors on that level. So you know you will need to use different card driver.

Complete communication stack will look like this:

  Your Application 
  |  CardProtocol/7816-4 
  |  |  14443-4 
  |  |  |  14443 
  |  |  |  |  radio waves 
  |  |  |  14443 (in card) 
  |  |  14443-4 (in card) 
  |  CardProtocol/7816-4 (in card) 
  Application/Appdata (in card)

Of course between every layer has to be some interface.

If you have two applications which wants to communicate try one and then try second.

error on application level => there is no compatible application on card

error on CardProtocol level => there is not compatible card

Point is your communication has to succed on all levels so don't worry to try to communicate with card by not compatible protocol - if you (by some miracle) will not get error on CardProtocol level you will definitely get one on your application level and result will be same. Good Luck!

P.S. There are some more complex situations like "one app over two protocols/types of cards" but they can be handled easily too.

Anthelion