Standards for smartcard communication

Question

What is the difference between ISO 14443-3 and ISO 7816-4 APDUs? I'm asking this because seems some cards use former to communicate with reader, some latter. I'm confused with this, would like to get a good understanding about this. For example, I think Mifare Classic uses ISO 14443-3. But what confused me here is that when I wrote application to communicate with Mifare classic, I was sending APDUs to it.

Scolecite

Answer 1

The ISO 14443 standard defines the physical RF transport protocol for communication between the card and the reader (see e.g. http://www.openpcd.org/ISO14443 for a quick overview). It standardizes things like the use of parity bits, CRC algorithms, frame size, acknowledgement mechanism, etc. There are essentially 2 different types of communication defined: Type A and Type B. The reason for this is largely historical: there were different kinds of products on the market before the standard was defined, which more or less correspond to Type A and and Type B in Part 3 of ISO 14443.

Part 4 of the standard essentially defines a communication layer on top of which a common type of communication becomes possible. This is usually ISO 7816-4, although there are contactless cards (e.g. MIFARE DESFire and MIFARE Plus) that (also) use their own native command structure instead of this.

ISO 7816 is a collection of contact smart card standards. Part 4 standardizes a command-response format and a number of commands: the APDU. This creates the situation that from a software point of view, there is no real difference between communicating with a contact smart card reader and a contactless one. In both cases the software can use APDUs to communicate with the smart card. So many software libraries implementing smart card reader support use APDUs as the basic communication unit with the card.

That is very convenient, except for the fact that some popular contactless cards such as MIFARE Classic do not understand APDUs (as they do not even support ISO 14443-4). So contactless card reader manufacturers have created a kind of "virtual" APDU format (using a proprietary Class byte in the APDU) to address this. The card reader firmware (or the driver on the PC) intercepts the C-APDUs and translates them into the proper MIFARE Classic command and translates the card response into a R-APDU. In this way software developers can use their preferred smart card communication library and still communicate with MIFARE Classic cards.

MIFARE DESFire cards offer a similar mechanism, but there it is actually the card itself that manages the translation of APDUs from and to its native command set. This possible because the card uses ISO 14443-4 communication.

A nice infographic showing many contactless smart card and NFC standards and specification in relation to each other can be found at http://open-nfc.org/documents/PRE_NFC_0804-250%20NFC%20Standards.pdf

For an overview of more smart card standards, see e.g. http://www.smartcardbasics.com/smart-card-standards.html. This question may also provide relevant information.

Redon

Thank you NFC guy. I more or less understand these things now. 1. So it is true each reader translates APDU to Mifare commands right? But how is this reflected on interoperability? If I use specific set of APDU to talk to Mifare classic, will I be able to talk to Mifare Classic using same APDUs but a different reader? – Scolecite

This APDU translation is not standardized, AFAIK, so it may fail on another reader. – Redon

I will use an opportunity to ask you one more question: which is easier to implement, Mifare Plus? or Desfire EV? – Scolecite

If you are migrating from an existing MIFARE Classic system, I would propose MIFARE Plus. In all other cases, I would recommend DESFire EV1. – Redon

what about Ultralight C? In any case now that I look at it, I think first I should look at the reader which I have (isn't it?) see what kind of support (e.g., SDK etc) it has (good or bad) for some specific Mifare card. And then see how to implement it, isn't this the general guideline? (ps. this is new system, not migration) – Scolecite

Answer 2

Actually 14443-3 corresponds to 7816-3 because we are talking over protocol issues here. Mifare cards (as simple memory cards) do not understand APDUs. To have them addressed via PCSC at all, the reader drivers offer APDUs (which are not standardized and so possibly different for different reader brands). These are not passed to the card but are chosen for and interpreted by the reader or its driver. There is also a family of smart cards understanding real APDUs on 14443-basis using the protocol T-CL, like ICAO-compliant travel documents.

Carn

hm... ok I used a manual for ACR122U reader to assemble APDU commands to send to the reader for communicating with Mifare Classic. But then I used these APDUs to communicate with Mifare Classic using a Omnikey reader - and it still worked, so it seems these two readers happen to use common APDU format right? – Scolecite

You were lucky this time, which is why I wrote "possibly different". (Manufacturers may be smart enough to converge.) But from the technical point of view they could be totally different, because they do not depend on the card. – Carn