MIFARE type identification procedure - NXP

1 AN10833 MIFARE type identification procedureRev. 10 August 2021 Application noteCOMPANY PUBLICD ocument informationInformationContentKeywordsMIF ARE, NTAG, ISO/IEC 14443 AbstractThis document describes how to differentiate between the members of theMIFARE card IC family. ISO/IEC 14443-3 describes the initialization and anti-collision procedure , and ISO/IEC 14443-4 describes the protocol activationprocedure. This document shows how to use these procedures to deliver thechip type information for all MIFARE ICs and SemiconductorsAN10833 MIFARE type identification procedureRevision Addition of newest generation General restructuring with focus on the GetVersion for MIFARE Plus for multi- MIFARE implementation and implementation in for MIFARE Implementation in a for for the new MIFARE Classic with 7 byte UID of Table 12320090518 Third release(supersedes AN MIFARE Interface Platform, Type identification procedure , Rev.)

2 , )Revision historyAN10833 All information provided in this document is subject to legal disclaimers. NXP 2021. All rights noteRev. 10 August 2021 COMPANY PUBLIC2 / 17 NXP SemiconductorsAN10833 MIFARE type identification procedure1 and abbreviationsTable 1 shows the terms and abbreviation used in this document. All the Type A relateddefinitions are used and described in the ISO/IEC 14443 To Request acc. to ISO/IEC 14443-4 ATSA nswer To Select acc. to ISO/IEC 14443-4 DIFDual Interface (cards)COSCard Operating SystemCLCascade Level acc. to ISO/IEC 14443-3 CTCascade Tag, Type applicableNFCNear Field CommunicationPCDP roximity Coupling Device ( Contactless Reader )PICCP roximity Integrated Circuit ( Contactless Card )PKEP ublic Key Encryption (like RSA or ECC)REQAR equest Command, Type ASAKS elect Acknowledge, Type ASelectSelect Command, Type ARIDR andom ID, typically dynamically generated at Power-on Reset(UID0 = 0x08 , Random number in UID3)RFUR eserved for future useUIDU nique Identifier, Type ANUIDNon-Unique IdentifierTable 1.

3 AbbreviationsIn this document the term MIFARE card refers to a contactless card using an IC outof the MIFARE Classic, MIFARE Plus; MIFARE desfire or MIFARE Ultralight document describes how to differentiate between the members of the MIFARE interface card IC family. The ISO/IEC 14443-3 describes the initialization and anti-collision procedure for type A, which delivers the card type information for all MIFARE cards are ISO/IEC 14443-3 compatible. Therefore already existingapplications can easily be extended to operate with newer MIFARE chips respectively allother ISO/IEC 14443-3 compatible information provided in this document is subject to legal disclaimers. NXP 2021.

4 All rights noteRev. 10 August 2021 COMPANY PUBLIC3 / 17 NXP SemiconductorsAN10833 MIFARE type identification procedureThis document provides an easy guideline how the ISO/IEC 14443 compatible PCDshould handle the MIFARE cards and how it can distinguish between the differentavailable types of MIFARE and ISO/IEC MIFARE ICs are compliant to the ISO/IEC 14443 part 2 and part 3. The T=CL protocolas defined in the ISO/IEC 14443-4 is supported by MIFARE desfire product family,the MIFARE Plus product family, and the NXP Dual or Triple Interface Card ICs (likeSmartMX).The MIFARE Classic with 1K memory, the MIFARE Classic with 4K memory, the MIFAREU ltralight EV1, the MIFARE Ultralight C, the MIFARE Plus, the MIFARE Plus EV1 and theMIFARE Plus EV2 (in security level 1 or 2) use the MIFARE Protocol (native commandset) based on ISO/IEC 14443-3 MIFARE Classic with 1K memory, and the MIFARE Classic with 4K memory use theproprietary 14443 The ISO/IEC 14443 consists of 4 1: Physical characteristicsThe ISO/IEC 14443-1 defines the physical size of the ISO/IEC 14443 PICC and 2: RF signal and power interfaceThe ISO/IEC 14443-2 defines the carrier frequency of MHz, the modulationand coding, and the minimum and maximum field-strength.

5 It is split up into type A (= MIFARE ) and type 3: Initialization and anti-collisionThe ISO/IEC 14443-3 defines the start of communication and how to select the this is called Card Activation Sequence . It is split up into type A (= MIFARE )and type 4: Transmission protocolThe ISO/IEC 14443-4 defines the protocol for a data exchange between PCD and protocol often is called T=CL refer to the ISO/IEC 14443 documents for information provided in this document is subject to legal disclaimers. NXP 2021. All rights noteRev. 10 August 2021 COMPANY PUBLIC4 / 17 NXP SemiconductorsAN10833 MIFARE type identification procedure2 Chip type identification GetVersion command to exactly identify the ICsThe MIFARE Ultralight EV1, MIFARE Plus EV1, MIFARE Plus EV2, MIFARE DESFireEV2, MIFARE desfire EV3 and MIFARE desfire Light support the command GetVersion to exactly identify the is recommended to use only the GetVersion command to identify which IC Typecurrently is present on a GetVersion command specification, as well as the GetVersion response can befound in the respective datasheets of the MIFARE products.

6 In general, the lower nibbleof the second byte of the GetVersion response gives the MIFARE product family, whichis in many cases the most important information needed. The upper nibble defines if thedevice is a native MIFARE IC (0x0), an implementation (0x8), an applet on a Java Card(0x9) or MIFARE 2GO (0xA).Second Byte of GetVersion ResponseProduct0xX1 MIFARE DESFire0xX2 MIFARE Plus0xX3 MIFARE Ultralight0xX4 NTAG0xX5 RFU0xX6 RFU0xX7 NTAG I2C0xX8 MIFARE desfire LightTable 2. GetVersion response byte 2 (HW/Product Type) meaningBelow Figure 1 shows a flow diagram that can be used to distinguish all current MIFAREand NTAG products currently available using the GetVersion command, and for oldergenerations the ATQA/SAK information provided in this document is subject to legal disclaimers.

7 NXP 2021. All rights noteRev. 10 August 2021 COMPANY PUBLIC5 / 17 NXP SemiconductorsAN10833 MIFARE type identification procedureaaa-041598 Check Cardb8b7b6b5b4b3b2b1 SAK b2=1?RFUYesYesYesNoNoBit 2 Bit 4 Bit 5 Bit 1 Bit 6 Yes0x190x38 SAK b4=1?SAK b5=1?SAK b6=1?RATSGetVersionin L4 HistoricalGetVersionin L4 SAK b1=1?MIFAREC lassic 2 KYesYes0x110x200x100x00 SAK b5=1?SAK b1=1?YesSmartMX withMIFAREC lassic 4 KMIFAREC lassic 4 KYesNoNoNoErrorATSGetVersionin L4 ATSATSYesYesNoNoNoNoYes0x090x280x180x08 SAK b6=1?SAK b1=1?MIFAREMiniYesSAK b6=1?GetVersionHW Type0x03(Ultralight)In L3 AuthSmartMX withMIFAREC lassic 1 KMIFAREU ltraLightNanoByte 6 (Size)0x16: 2 K0x18: 4 KMIFAREU ltraLightEV1 NTAG2xxISO 14443-3 ISO 14443-4 UltraLight EV1 and Nanosupport Layer 3 GetVersionMIFAREC lassic 1 KMIFAREU ltraLightMIFAREU ltraLight CMIFAREH ospitalityMIFAREPlus4 K in SL2 YesSAK b1=1?

8 NoNoNoNoReadPage 2/3 YesYesErrorNoMIFAREPlus2 K in SL2 TagNPlayHW Type0x02 or 0x82( MIFARE Plus)HW Type0x02 or 0x82( MIFARE Plus)*HW Type0x8x isMIFARE on MCUHW Type0x01 or 0x81( MIFARE DF)HW Type0x08( MIFARE DFL)HW Type0x04(NTAG)HW Type0x04(NTAG)RATSRATSE rrorBytes?HistoricalBytes?HistoricalByte s?SAK: 0x18 SAK: 0x08 MIFARE Plus SL0 isPre-Personalizationstatus, and not classified here. C105213000F6D1or 10F6D1 SAK: 0x20C1052F2F0035C7C1052F2F01 BCD6 MIFAREPlus EV12 K/4 k in SL3 MIFAREPlus EV22 K/4 k in SL3 MIFAREDESFire EV1256 B/2/4/8 KMIFAREDESFire EV22/4/8/16/32 KMIFAREDESFire EV32/4/8 MIFAREDESFireLightByte 6 (Size)0x13: ~512 BByte 4 (HWversion)0x11: EV10x22: EV2 Byte 4 (HWversion)0x11: EV10x22: EV20x33: EV3 Byte 6 (Size)0x10: 256 B0x16: 2 K0x18: 4 K0x1A: 8 K0x1C: 16 K0x1E: 32 K*Storage Size Calculation:7-MSbits (=n) code the size based on LSbit is set to `0' if the size is exactly : 0x1A = 8192 bytes storage sizeByte 6 (Size)0x16: 2 K0x18: 4 K00F6D1: 17 pF10F6D1: 70 pFATQA2 K: 0x00 x44 K: 0X00 x200F6D1: 17 pF10F6D1.

9 70 pFMIFAREPlus S2 K in SL1 MIFAREPlus X2 K in SL1 MIFAREPlus SE1 KC105213000F6D1or 10F6D1C1052F2F0035C7C1052F2F01 BCD6 MIFAREPlus S2/4 K in SL3 MIFAREPlus X2/4 K in SL3 MIFAREPlus SE1 KC1052F2F0035C7C1052F2F01 BCD6 MIFAREPlus S4 K in SL1 MIFAREPlus X4 K in SL1 MIFAREPlus EV12 K/4 k in SL1 NTAG4xx1. This Card Activation requires a proper REQA/ATQA before the anti-collision The bit numbering of the ISO/IEC 14443 starts with LSB = bit1!3. The MIFARE Plus in Security Level 3 fully supports the ISO/IEC SAK bit 2 is reserved for future use, bit 2 = 1 might give a different meaning to all otherSAK 1. MIFARE Card Activation examples** Product-specific details can be found in the data sheet of the specific : It is not recommended to use the ATQA to determine card parameters due topossible : The whole MIFARE Ultralight family uses the same ATQA and information provided in this document is subject to legal disclaimers.

10 NXP 2021. All rights noteRev. 10 August 2021 COMPANY PUBLIC6 / 17 NXP SemiconductorsAN10833 MIFARE type identification procedureNote: The MIFARE Plus in the SL3 uses the ATS or the card capabilities to distinguishbetween different card : Only for older product generations, the following sections should be used for typeidentification. For MIFARE desfire EV3 and MIFARE Plus EV2, the ATQA and SAK isconfigurable, so any ISO-conformal values are possible, therefore this cannot be used fortype identification the ISO activation parameters - not recommended!Note: It is not recommended to use the ISO activation parameters for PCD typically polls for PICCs in the field. This is done with the REQA.