MIFARE Application Directory #
The memory data mapping NDEF methods of the MIFARE Classic and MIFARE Plus IC use the MIFARE application directory structure (MAD).
The MIFARE application directory (MAD) identifies to which application the information stored inside each memory sector belongs.
Two MIFARE application directories have been specified:
-
-
- MIFARE application directory 1 (MAD1): MAD1 MAY be used in any MIFARE Classic compliant product. The MAD1 is located in the MAD sector (sector 00h), In case the MAD1 is used on products with a memory size bigger than 1Kbytes, only 1Kbytes memory can be used and addressed by the MAD1. The remaining memory is therefore not used for NDEF storage and stays free.
- MIFARE application directory 2 (MAD2): MAD1 MAY be used in any MIFARE Classic compliant product with a memory size bigger than 1Kbytes. MAD2 is not applicable for products with a memory size smaller or equal to 1Kbytes. The MAD2 is located in the MAD sectors (sector 00h and 10h)
-
To each application, the MAD associates a unique application identifier (AID). The application identifiers (AIDs) are stored inside the MAD sector(s) 00h.
The AID is two-byte long, and it is divided into 2 fields of one byte each:
- the function cluster code (1 byte) that identifies the cluster to which the application belongs, and
- the application code (1 byte) that identifies the application inside the cluster. For more information about MAD1 and MAD2.
The General Purpose Byte (GPB) of the MAD sector SHALL be set with a DA bit equal to 1b (DA bit is the MAD available bit of the GPB).
All currently unused sectors SHOULD be write-protected with secret keys defined by the tag issuer in order to prevent the unintended redefinition of access conditions and keys. It is RECOMMENDED to use different keys for all free sectors. This enables the future release of some sectors to new service providers without the need of releasing all free sectors.
MAD Sector Access #
The memory sectors where the MAD1 and MAD2 are stored (see [MAD]), are protected using the key A and key B. According to [MAD] the memory sectors are:
-
-
-
- MAD1: the MAD sector is 00h (sector 0), and
- MAD2: the MAD sectors are 00h and 10h (sector 0 and sector 16).
-
-
Anybody SHALL be allowed to read the MAD sectors. This is achieved by using a public key A described in Table 1 (see also [MAD]).
Table 1. Public Key A value of MAD sector(s)
-
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 A0h A1h A2h A3h A4h A5h
The access bits for the MAD sector(s) are set to either:
-
-
-
- as described in Table 2 if the MAD sector has read and write access granted, or
- as described in Table 3 if the MAD sector has read-only access granted (see also [MF1K, MF4K, MFPLUS]).
-
-
In this context, the term read and write access granted means that for MAD sectors that have been previously authenticated with the secret key B, it is possible to read and write all sector blocks apart from the sector trailer block (see Table 2 for more details).
Instead, the term read-only access granted means that for MAD sectors that have been previously authenticated with the public key A of Table 1 or secret key B, it is possible to only read all sector blocks apart from the sector trailer block (see Table 5 for more details).
Using key A it is always only possible to read the blocks of the MAD sector. Sector trailers have a particular access configuration when read/write access or read-only access is granted (see Table 2 and Table 3).
The MAD sectors SHOULD be write-protected by means of the secret key B (e.g. defined by the tag issuer) or setting the MIFARE Classic and MIFARE Plus tag as read-only using the access bits.
Table 2. Access bits setting for the MAD sector with the read and write access granted
-
Access bits setting for sector 0 of MAD1 or MAD2 and for sector 16 of MAD2 Access Bits Values Remarks C10 C20 C30 100bi Block 0 is read with key A or key B and written with key B C11 C21 C31 100b Block 1 is read with key A or key B and written with key B C12 C22 C32 100b Block 2 is read with key A or key B and written with key B C13 C23 C33 011b The sector trailer block: - Key A is written with key B and never read,
- Access bits is read with key A or key B and written with key B,
- Key B is written with key B and never read.
i. Recommended value for the access bits C10 C20 C30 of sector 0 (manufacturer block).
Table 3. Access bits setting for the MAD sector with read-only access granted
-
Access bits setting for sector 0 of MAD1 or MAD2 and for sector 16 of MAD2 Access Bits Values Remarks C10 C20 C30 010b Block 0 is read with key A or key B C11 C21 C31 010b Block 1 is read with key A or key B C12 C22 C32 010b Block 2 is read with key A or key B C13 C23 C33 110b The sector trailer block: - Key A is never written and read,
- Access bits is read with key A or key B and never written,
- Key B is never written and read.
i. Recommended value for the access bits C10 C20 C30 of sector 0 (manufacturer block).
TLV blocks #
A TLV block consists of one to three fields:
T (tag field, or T field) SHALL identifies the type of the TLV block (see Table 9), and SHALL consist of a single byte encoding a number from 00h to FFh. The tag values 01h, 02h, 04h to FCh and FFh are reserved for future use.
L (length field, or L field) SHALL provide the size in bytes of the value field. It has two different formats composed of one, or three bytes. The Reader device SHALL understands all two-length field formats. Fig 5 shows the two different length field structures. However, depending on the tag field value, the length field MAY not be present.
- One byte format: The one-byte format SHALL code the length of the value field between 00h and FEh bytes. This byte SHALL be interpreted as a cardinal if the value is between 00h and FEh. If it contains FFh the value SHALL be interpreted as a flag that specifies that the length field is composed of more than one byte.
- Three consecutive bytes format: This format SHALL code the length of the value field between 00FFh and FFFEh bytes. The first byte is assumed to be a flag equal to FFh indicating that two more bytes length SHALL be interpreted as a word. This word SHALL be interpreted as a cardinal if the value is between 00FFh and FFFEh. The value FFFFh is reserved for future use (RFU).
V (value field, or V field) If the length field is equal to 00h or there is no length field, there SHALL NOT be the value field, i.e. the TLV block is empty. If there is the length field and indicates a length of the value field N bigger than zero (N>0), the value field SHALL consist of N consecutive bytes.
Table 4 lists the TLV blocks specified by this document that are described in the following sections.
Table 4. Defined TLV blocks
-
TLV Block Name Tag Field Value Short Description NULL TLV 00h It might be used for padding of memory areas and the Reader device SHALL ignore this NDEF Message TLV 03h It contains the NDEF Message Proprietary TLV FDh Tag proprietary information Terminator TLV FEh Last TLV block in the data area
The Reader device SHALL write the TLV blocks in a specific order inside the data area following the rules below:
- The TLV blocks SHALL be written in order starting from byte 0 of block 0 of the NFC Sector (sector containing NDEF data) with the smallest address.
- A TLB block MAY be memorized across two or more NFC Sectors.
- If present the Terminator TLV is the last TLV block on the MIFARE Classic and MIFARE Plus tag.
NULL TLV and Terminator TLV are the only TLV blocks that are 1 byte long (e.g. composed of only the Tag field, see below).
Reader devices SHALL ignore and jump over those TLV blocks that make use of reserved tag field values (see above). To jump over a TLV block with reserved tag field values, the Reader device SHALL read the length field to understand the length of the value field.
Future definitions of TLV blocks composed of only the tag field are not backward compatible with this application note.
NDEF Message TLV #
At least one NDEF Message TLV SHALL be always present inside the MIFARE Classic and MIFARE Plus tag. The NDEF Message TLV stores the NDEF Message inside the Value field. The Reader device SHALL be able to read and process the NDEF Message TLV found by the NDEF Detection Procedure (also called mandatory NDEF Message TLV or first NDEF Message TLV); anyhow further NDEF Message TLV blocks MAY be present. Below the encoding of the 3 TLV fields of NDEF Message TLV is shown:
T SHALL be equal to 03h (see Table 4).
L SHALL be equal to the size in bytes of the stored NDEF Message.
V SHALL store the NDEF Message.
An empty NDEF Message TLV SHALL be defined as an NDEF Message TLV with L field equal to 00h, and no V field (i.e. no NDEF Message is present in the V field, see [NDEF]).
A non-empty NDEF Message TLV MAY contain either empty or non-empty NDEF Messages.
Proprietary TLV #
The Proprietary TLV contains proprietary information. A MIFARE Classic and MIFARE Plus tag SHALL contain zero, one or more Proprietary TLV. The Reader device might ignore the data contained in this TLV block. Below the encoding of the 3 TLV fields of Proprietary TLV is shown:
T SHALL be equal to FDh (see Table 4).
L SHALL be equal to the size in bytes of the proprietary data in the Vale field.
V SHALL contain any proprietary data.
NULL TLV #
The NULL TLV MAY be used for padding of the data area. A MIFARE Classic and MIFARE Plus tag MAY contain zero, one, or more NULL TLV. The Reader device SHALL ignore this TLV block. NULL TLV SHALL be composed of a 1-byte tag field. Below the encoding of the tag field of the NULL TLV is shown:
T SHALL be equal to 00h (see Table 4).
L SHALL NOT be present.
V SHALL NOT be present.
Terminator TLV #
The Terminator TLV MAY be present inside the MIFARE Classic and MIFARE Plus tag, and a Reader device SHALL be able to read/process it. The Terminator TLV is the last TLV block in the data memory area. Terminator TLV SHALL be composed of a 1-byte tag field. Below the encoding of the tag field of the Terminator TLV is shown:
T SHALL be equal to FEh (see Table 4).
L SHALL NOT be present.
V SHALL NOT be present.
