Get card type from ATR

Question

When I scan my card with springcard reader I need to get if this card is one of those types: CTS or CD_97 or ISO_A or ISO_B or FRD How can I get those types from ATR?

Those are some ATR examples, I am getting:

Navigo: 3B 88 80 01 00 00 00 00 00 71 81 00 F9

Técély: 3B 8F 80 01 80 5A 0A 01 01 20 03 11 10 1D 86 BC 82 90 00 C9

Oura: 3B 8F 80 01 80 5A 0A 01 02 20 03 11 03 53 52 A2 82 90 00 5D

Citycard: 3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 00 02 00 00 00 00 69

Is there any detailed explanation of how we can get those types from ATR?

I am using SpringCard to read cards: http://files.springcard.com/pub/pmd841p-fa.pdf

I was able to find a part of the solution in page 27 and 28 http://files.springcard.com/pub/%5bpma13205-bd%5d_Smart_Readers_and_RFID_Scanners_Template_System.pdf

I still need to finc the command to get OPT REGISTER

Fallow

As far as I know there is no global ATR registry, or a registry of the ATR historical bytes. Looking at the historical bytes within an ATR is probably the best way of distinguishing cards though (at a low level anyway). – Iila

The ATR tool from pcsc-tools is a good starting point. I guess you mean ISO 14443 type A and B. Not only, that this information is not visible from the ATR, you wont get the but an ATQB or ATS respectively depending on the used protocol. – Iceberg

So you think this is no possible to find those types CTS or CD_97 or ISO_A or ISO_B or FRD using ATR? We will never be sure about the type? – Fallow

Answer 1

Regarding the "OPT register" -- as far as I understand you set this register to control the way how SpringCard's Template System (optionally) encodes card family into its output. My bet is you do not want to use their Template System at all...

---

To get information about generic card technology/family use the following GET DATA command to get PIX.SS and PIX.NN (see chapter 2.2.1):

FF CA F1 00 00

First byte in response is PIX.SS (see chapter 5.1.4):

0x00 -> No information given
0x01 -> ISO 14443 A, level 1
0x02 -> ISO 14443 A, level 2
0x03 -> ISO 14443 A, level 3 or 4 (and Mifare)
0x05 -> ISO 14443 B, level 1
0x06 -> ISO 14443 B, level 2
0x07 -> ISO 14443 B, level 3 or 4
0x09 -> ICODE 1
0x0B -> ISO 15693

The following two bytes contain PIX.NN (see chapter 5.1.5):

0x0001 -> NXP Mifare Standard 1k
0x0002 -> NXP Mifare Standard 4k
0x0003 -> NXP Mifare UltraLight + Other Type 2 NFC Tags with a capacity <= 64 bytes
0x0006 -> ST MicroElectronics SR176
0x0007 -> ST MicroElectronics SRI4K, SRIX4K, SRIX512, SRI512, SRT512
0x000A -> Atmel AT88SC0808CRF
0x000B -> Atmel AT88SC1616CRF
0x000C -> Atmel AT88SC3216CRF
0x000D -> Atmel AT88SC6416CRF
0x0012 -> Texas Intruments TAG IT
0x0013 -> ST MicroElectronics LRI512
0x0014 -> NXP ICODE SLI
0x0016 -> NXP ICODE1
0x0021 -> ST MicroElectronics LRI64
0x0024 -> ST MicroElectronics LR12
0x0025 -> ST MicroElectronics LRI128
0x0026 -> NXP Mifare Mini
0x002F -> Innovision Jewel
0x0030 -> Innovision Topaz (NFC Forum type 1 tag)
0x0034 -> Atmel AT88RF04C
0x0035 -> NXP ICODE SL2
0x003A -> NXP Mifare UltraLight C + Other Type 2 NFC Tags with a capacity > 64 bytes
0xFFA0 -> Generic/unknown 14443-A card
0xFFA1 -> Kovio RF barcode
0xFFB0 -> Generic/unknown 14443-B card
0xFFB1 -> ASK CTS 256B
0xFFB2 -> ASK CTS 512B
0xFFB3 -> Pre-standard ST MicroElectronics SRI 4K
0xFFB4 -> Pre-standard ST MicroElectronics SRI X512
0xFFB5 -> Pre-standard ST MicroElectronics SRI 512
0xFFB6 -> Pre-standard ST MicroElectronics SRT 512
0xFFB7 -> Inside Contactless PICOTAG/PICOPASS
0xFFB8 -> Generic Atmel AT88SC / AT88RF card
0xFFC0 -> Calypso card using the Innovatron protocol
0xFFD0 -> Generic ISO 15693 from unknown manufacturer
0xFFD1 -> Generic ISO 15693 from EMMarin (or Legic)
0xFFD2 -> Generic ISO 15693 from ST MicroElectronics, block number on 8 bits
0xFFD3 -> Generic ISO 15693 from ST MicroElectronics, block number on 16 bits
0xFFFF -> Virtual card (test only)

Please pay attention to the following note regarding PIX.NN values starting with 0xFF (SpringCard proprietary codes):

The cards in this list are not referenced by PC/SC specification at the date of writing. In case they are added to the specification, the future firmware versions will have to use the new value. It is therefore advised not to check those values in the applications, as they are likely to be removed in the future.

And a note about PIX.NN availability:

Note: PIX.NN is specified for memory cards only. Even if the GET DATA instruction allows to retrieve PIX.NN even for micro-processor based cards (smartcards), the returned value is unspecified and shall not be used to identify the card.

Disclaimer: I no longer have access to SpringCard reader so I can't test it with my cards, but given the documentation it should work this way.

---

I was dealing with a very similar problem (processing different cards, somewhat mentioned here) in the past and the most effective approach was (given my "mix" of cards):

• Use ATR value to create "candidate list" (in many cases ATR value led to a single card scheme candidate)

• If there are more candidates consider the following ways to confirm one of them:

  • technology-specific "directory service" (e.g. MAD, Get Application IDs, PSE/PPSE, PTSE...)

  • trial-and-error application selection (which might be faster than using a directory service if candidate list is very short)

  • (as a least resort) proprietary card scheme detection

This approach assumes that you know all possible ATR values for used cards -- if not you would have to replace/combine it with card technology/family detection described above.

---

Note: pcsc-tools ATR list mentioned in comments is available here and here (I am not sure which one is canonical)

Good luck!

Habitue

I will test it , thank you for the detailed answer ;) – Fallow

@haythemsouissi CTS should give PIX.NN of 0xFFB1 and 0xFFB2. – Habitue

thanks @Habitue one last thing please , any idea for Calypso card? :) – Fallow

@haythemsouissi Linked manual gives some hints in a note inside section 5.1.1.c. (page 60) -- you should get PIX.NN of 0xFFC0 (Innovatron) or a generic T=CL card (probably one of 14443-B variants). If given generic T=CL card you should attempt to "Select Application" to verify it's presence (which is in line with my answer)...I can't help with Calypso specific details as they are not publicly available...Good luck! – Habitue

0xFFC0 -> Calypso card using the Innovatron protocol do we have only Calypso that use Innovatron? we don't have other Calypso that use other protocols? Sorry I am not an expert :) – Fallow

@haythemsouissi (Sorry I missed it was a question) -- As far as I understand Innovatron protocol was used before ISO 14443 was standardized and ISO14443B was heavily inspired by it (but is different because of some patents held by Innovatron) -- please verify those thoughts...But I would definitely be very cautious as SpringCard's documents do warn about cards that talk both protocols and randomly pick one to be used (a viable solution to this might be to disable Innovatron protocol at all -- see section 3.5.1). It all depends on your use-case -- that you did not specify (but I assume that... – Habitue

...you want to 'do-something-more' with the card after you detected which card it is -- so you will probably need to select some card application as a first step and realize that this step might be used as a part of card detection routine...and don't worry -- neither am I an expert...PS: It is very difficult (almost impossible) to achieve anything with smartcards without proper documentation...Good luck! – Habitue

Let us continue this discussion in chat. – Habitue

Answer 2

you can find here spring card answer, sorry but they answered me in Frensh langage, so if there is anything not clear , put it in your comment:

ATR

1- Envoyer d'abord FF CA FA 00 : - Avez-vous au moins 14 octets, et les octets 7-11 sont-ils : A0 00 00 03 06 ? -> Si oui, alors vous êtes sur une carte à logique câblée, Il faut récupérer le PIX.SS et le PIX.NN (octets 12-13-14 de la réponse) et retrouver la techno de la carte selon les paragraphes 4.1.4 et 4.1.5. La détection de la technologie s'arrête là. Vous pouvez envoyer la commande décrite dans NUM_PROTOCOL pour connaître le numéro protocolaire de la carte. -> Si non, alors vous êtes sur une "vraie" carte à puce. Envoyer la commande décrite dans NUM_PROTOCOL

NUM_PROTOCOL

2- Envoyer FF CA 00 00, et analyser le nombre d'octets dans la réponse : - réponse sur 7 ou 11 octets: la carte est forcément en ISO A, la réponse est l'UID de la carte. L'algo peut s'arrêter là si vous n'avez pas besoin de plus de détail - réponse sur 4 octets : c'est le numéro protocolaire. 2 options : * si vous avez détecté que c'est une carte à logique câblée à l'étape précédente, alors l'algo peut s'arrêter là si vous n'avez pas besoin de plus de détail * Si vous êtes sur une carte à puce, alors il faut envoyer la commande COMPLETE_ID - réponse sur un nombre d'octet différent : on est forcément sur de la logique câblée (ou carte à mémoire), dont la techno est déja identifiée. La réponse correspond au numéro protocolaire. L'algo peut s'arrêter là si vous n'avez pas besoin de plus de détail

COMPLETE_ID

3- On n'arrive ici que quand la carte est une carte avec une "vraie" puce (DONC : pas une carte à mémoire, ni une carte à logique câblée) Envoyer FF CA F0 00 et analyser le nombre d'octets dans la réponse: -11 ou 12 octets: c'est forcément de l'ISO B - la valeur obtenue est l'ATQB - le numéro protocolaire a été obtenu à l'étape suivante / la carte est identifiée - résultat sur un nombre d'octets différent : vérifier si cela correspond à 3 octets suivi du numéro protocolaire obtenu à la commande précédente a) si oui, c'est de l'ISO A - les deux premiers octets sont l'ATQA, et le troisième est le SAK (le reste forme l'UID) b) si non alors on a reçu le REPGEN, la carte répond sur le protocole INNOVATRON (le PUPI a été obtenu à l'étape précédente).

Avec cela, normalement, vous devriez être en mesure de reconnaître toutes vos cartes.

Fallow