Search code examples
smartcardsmartcard-readercontactless-smartcard

Get card type from ATR

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 28enter image description here enter image description here 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

Solution

  • 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!