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

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!