MF0AES20

NXP Semiconductors

MIFARE Ultralight AES contactless limited-use IC Rev. 3.1-29 April 2022

Manufacturer: NXP Semiconductors

Document: 73 Pages / 680Kb

Request Quote Download Datasheet Read online HTML view

More from NXP Semiconductors Browse M parts

Online Datasheet

Read MF0AES20 online.

MF0AES20 NXP | Alldatasheet

Document overview

Manufacturer or author: Provided By www.digicamel.com(FREE DATASHEET DOWNLOAD SITE)
PDF pages: 73

Technical content

Datasheet sections

1 General description
1.1 Contactless energy and data transfer
1.2 Anti-collision
1.3 Simple integration and user convenience
1.4 NFC Forum Tag 2 Type compliance
1.5 Security and privacy
1.6 Naming conventions
2 Features and benefits
2.1 Memory
3 Applications
4 Quick reference data
5 Ordering information
6 Block diagram
7 Pinning information
7.1 Wafer delivery
7.2 Smart card contactless module
8 Functional description
8.1 Block description
8.2 RF interface
8.3 Data integrity
8.4 Communication principle
8.4.1 IDLE and HALT
8.4.2 READY1
8.4.3 READY2
8.4.4 ACTIVE
8.4.5 TRACEABLE
8.4.6 AUTHENTICATED
8.5 Memory organization
8.5.1 UID/serial number
8.5.2 Random ID
8.5.3 Lock byte 0 and
8.5.4 Lock byte 2, 3 and
8.5.5 OTP bytes
8.5.6 Data pages
8.5.7 Configuration pages - 144 byte user
8.5.8 Configuration for memory access via AES
8.5.9 Counter 3x 24-bit one way
8.6 AES authentication protection
8.6.1 AES authentication
8.6.2 AES authentication example
8.6.3 Programming of the AES key to memory
8.6.4 Protection of configuration pages
8.6.5 Limiting failed authentication attempts
8.7 Plain communication
8.8 CMAC protected message integrity
8.8.1 Session Key Generation
8.8.2 CMAC Calculation for data integrity
8.8.3 CMAC Communication Mode
8.9 Product originality
8.9.1 Originality Signature
8.9.2 Originality Signature at Delivery
8.10 Virtual Card Architecture Support
9 Command overview
9.1 MIFARE Ultralight AES Command
9.2 Timings
9.3 ACK and NAK
9.4 ATQA and SAK responses
9.5 Summary of device identification data
10 MIFARE Ultralight AES - Commands
10.1 GET_VERSION
10.2 READ
10.3 FAST_READ
10.4 WRITE
10.5 READ_CNT
10.6 INCR_CNT
10.7 READ_SIG
10.8 WRITE_SIG
10.9 LOCK_SIG
10.10 AUTHENTICATE
10.11 VCSL
11 Limiting values
12 Characteristics
12.1 Electrical characteristics
13 Wafer specification
14 Delivery
14.1 Delivery as a wafer
14.2 Delivery as a module
14.3 Delivery method one: The customer
14.4 Delivery method two: The product is sent
15 Package outline
15.1 Bare die outline
16 Abbreviations
17 References
18 Revision history
19 Legal information

MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC Rev. 3.1 — 29 April 2022 Product data sheet COMPANY PUBLIC

1 General description

MIFARE Ultralight AES is a smart IC serving the requirements of limited use applications for contactless tickets and RFID key cards managed by one single entity. MIFARE Ultralight AES is offering a powerful mix between performance, security, privacy and flexibility. It addresses the needs of limited use applications such as public transport, hospitality, access, event ticketing and loyalty applications, by expanding the MIFARE Ultralight ticketing IC portfolio and adds Advanced Encryption Standards (AES) into it. MIFARE Ultralight AES comes with AES-128 cryptography and enables product protection mechanisms in terms of product authenticity and integrity. Its enhanced feature and command set enables efficient implementations and offers flexibility in system designs and is a perfect contactless ticketing expansion to the smart card contactless IC families such as MIFARE DESFire or MIFARE Plus. Based on these parameters the MIFARE Ultralight AES is a trusted platform targeting the secure authentication of people with an intuitive convenient user experience. MIFARE Ultralight AES is fully compliant with the contactless proximity smart card protocol according to ISO/IEC 14443-3 making it compatible with the majority of existing contactless infrastructure devices. Its contactless performance supports advanced user convenience and reading distances up to 10 cm (depending on various parameters as e.g. field strength and antenna geometry). MIFARE Ultralight AES has a 4 byte per one page memory structure with a total user memory of 144-byte. To protect sensitive data against unauthorized access, MIFARE Ultralight AES offers a 3-pass mutual authentication based on AES with a 128-bit key. For data integrity protection an optional CMAC calculation for commands and response can be enabled, following NIST Special Publication 800-38B, see [15]. Besides the data protection MIFARE Ultralight AES serves the option to protect one out of the three independent 24-bit one-way counters by an AES authentication. To prevent undefined counters values due to tear-off in the field or originating from interrupted programming cycles an advanced anti-tearing support is implemented. MIFARE Ultralight AES is also ready to support contactless applications addressing privacy sensitive use-cases. With its optional support of Random ID, it enables compliance with latest user data protection regulations. MIFARE Ultralight AES enables check of the manufacturing origin of a ticket by verification of an asymmetric signature retrieved from the IC using the UID and an ECC-based originality signature. The default NXP signature can be overwritten with a customer-specific signature during personalization. The purpose of originality check is to identify mass penetration of none-genuine MIFARE Ultralight AES ICs into an infrastructure. MIFARE Ultralight AES is designed to support smart ticket antenna designs with a 17 pF input capacitance as well as smaller form factors for key fobs, tags or wristbands by providing 50 pF input capacitance. This is offered by FFC deliveries and MOA8 modules to ensure high user convenience throughout different form factors.

1.1 Contactless energy and data transfer

1.2 Anti-collision

An anti-collision function allows to operate more than one card in the field simultaneously. Figure 1. Contactless System

1.3 Simple integration and user convenience

The data access protection with AES authentication based on a key length of 128-bit
Optional CMAC protection for message integrity
The fast read capability allows reading the complete user memory with only one FAST_READ command, therefore reducing the overhead in high throughput production environments
The improved RF performance allows for more flexibility in the choice of shape, dimension and materials
The Random ID support for enhanced user privacy compliant with latest user data protection regulations The MIFARE Ultralight AES is designed for simple integration and advanced user convenience with superior ticketing transactions times. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 2 / 73

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC

1.4 NFC Forum Tag 2 Type compliance

MIFARE Ultralight AES can be configured to comply to the NFC Forum Tag 2 Type technical specification, see [20] and allows to enable NDEF data structure configurations as specified in [21].

1.5 Security and privacy

Common Criteria certification: EAL3+ (AVA_VAN.2)
3-pass mutual AES authentication based on a key length of 128-bit
Configurable secure messaging communication mode - CMAC for message integrity protection according to NIST Special Publication 800-38B, see [15].
Three independent 24-bit one-way counters with optional AES authentication protection of one counter
Unique 7-byte IDentifier for each device
Random ID (optional) for enhanced privacy. Compliant to ISO14443-3
32-bit user programmable OTP area
Field programmable read-only locking function per page for the first 512 bit
Read-only locking per block of 2 pages for the memory above 512 bit
Pre-programmed ECC-based originality signature, offering the possibility for customizing and permanently locking
AES-based originality key leveraging the AES authentication to check the NXP origin of the IC via NXP tools Note: MF0AES(H)20 comes with an external CC EAL3+ certification targeting basic attack potential (AVA_VAN.2). Hence, the contactless IC does not claim to be completely resistant. In case of broader protection is required, products with a higher security certification should be considered. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 3 / 73

1.6 Naming conventions

Table 1. Naming conventions

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC

2 Features and benefits

Contactless transmission of data and supply energy compliant to ISO/IEC 14443 -2/ -3 A, see [1]and [2]
Operating frequency of 13.56 MHz
Data transfer of 106 kbit/s
Data integrity of 16-bit CRC, parity, bit coding, bit counting
Anti-collision function allows to operate more than one card in the field simultaneously
Low power consumption enabling operating distances of up to 10 cm (depending on various parameters as e.g. field strength and antenna geometry)
Fast start-up time for reliable and robust detection
Support of double size (7-byte) Unique IDentifiers (UID) and optionally Random ID (RID) according to ISO/IEC 14443-3 A, [2]
Optional CMAC calculation for data integrity protection
3-pass mutual authentication with AES based on a 128-bit key
ECC-based originality signature, offering the possibility for customizing and permanently locking
Fast read command
17 pF and 50 pF input capacitance to support high user convenience throughout different form factors
Fast counter transaction

2.1 Memory

144 bytes freely available Read/Write user memory, organized in 36 pages with 4 bytes per page
4 bytes One Time Programmable (OTP) access bits
Anti-tearing support for counters, Lock bits, OTP bits
Field programmable read-only locking function per page for the first 16 pages
Field programmable read-only locking function above the first 16 pages per 2 pages
Configurable AES authentication for data access protection with optional limit of unsuccessful attempts
Configurable data protection access rights for available user memory
Pre-programmed ECC-based originality signature, offering the possibility for customizing and permanently locking
Compatibility to allow NFC Type 2 Tag compliant configurations
Data retention time of 10 years
Write endurance of 100.000 cycles Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 5 / 73

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC

3 Applications

The target applications of the MIFARE Ultralight AES are primarily designed for single or limited use applications such as:

Public transport for limited use ticketing
Hospitality RFID basic guest card
Event ticketing
Electronic voucher
Loyalty tickets Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 6 / 73

4 Quick reference data

Table 2. Characteristics of MIFARE Ultralight AES

5 Ordering information

Table 3. Ordering information MF0AES(H)xy

6 Block diagram

Figure 2. Block diagram

7 Pinning information

7.1 Wafer delivery

Table 4. Pin allocation table

7.2 Smart card contactless module

Figure 3. Contact assignments for SOT500-4 (MOA8) Table 5. Pin allocation table

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC

8 Functional description

8.1 Block description

The MIFARE Ultralight AES IC consists of a 240 byte EEPROM, RF-Interface and the Digital Control Unit. Energy and data are contactless transferred between the contactless reader resp. Proximity Coupled Device (PCD) and Proximity Integrated Circuit Card (PICC). PICC antenna which consists of a coil with a few turns directly connects to the MIFARE Ultralight AES contactless IC. No further external components are necessary. For details on antenna design please refer to the document, see [7].

RF-Interface: – Modulator/Demodulator – Rectifier – Clock Regenerator – Power On Reset – Voltage Regulator
Anti-collision support: multiple cards may be selected and managed in sequence
True Random Number Generator (TRNG)
Crypto coprocessor: Advanced Encryption Standard (AES)
Crypto control unit: controls Crypto coprocessor operations
Command Interpreter: processes memory access commands that the MIFARE Ultralight AES supports
EEPROM-Interface
MIFARE Ultralight AES EEPROM: 240 byte, organized in 60 pages of 4 bytes per page. - First 16 byte are for manufacturer data, Lock byte 0 and 1, One-Time-Programmable (OTP) page - 144 byte are user programmable read/write memory - 80 byte configuration pages and RFU

8.2 RF interface

The RF interface is based on the ISO/IEC 14443 Type A standard, see [1] and [2]. During operation, the contactless reader (PCD) generates an RF field. This RF field must always be present with short pauses for data communication. It is used for both communication and as power supply for the tag. For both directions of data communication, there is one start bit at the beginning of each frame. Each byte is transmitted with an odd parity bit at the end, except for REQA and WUPA command. The LSB of the byte with the lowest address of the selected block is transmitted first. The maximum length of a PCD to PICC frame for AUTH_Part 2 is 280 bits excluding parity bits. The maximum length for a fixed size PICC to PCD frame is 208 bits for READ command with CMAC without parity bits. The FAST_READ response has a variable frame length depending on the start and end address parameters. When issuing this command, take the maximum frame length of the PCD into account. For a multi-byte parameter, the least significant byte is always transmitted first. As an example, take reading from the memory using the READ command, byte 0 from the Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 11 / 73

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC addressed block is transmitted first. It is then followed by bytes 1 to byte 3 out of this block. The same sequence continues for the next block and all subsequent blocks.

8.3 Data integrity

Following mechanisms are implemented in the contactless communication link between contactless reader and smart ticket contactless IC to ensure very reliable data transmission:

User commands and responses
16-bit Cyclic Redundancy Check (CRC) according to ISO/IEC 14443-3, see [2], calculated over all preceding bytes in the same communication frame
Parity bit for each byte
Bit count checking and bit coding to distinguish between "1", "0", and no information
Channel monitoring (protocol sequence and bit stream analysis)
Configurable secure messaging communication mode to apply CMAC for message integrity protection

8.4 Communication principle

The contactless reader initiates the commands and the Command Interpreter of the MIFARE Ultralight AES processes them. The command response is depending on the state of the IC and for memory operations also on the access conditions valid for the corresponding page. For a correct implementation of an anti-collision procedure, see [2]. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 12 / 73

unexpected command. If the IC was previously in the HALT state, it returns in that state. Remark: The VCSL command is only allowed in the ACTIVE state. Remark: In ACTIVE state, all operations are allowed which are not requiring authentication. privacy sensitive operations reading UID bytes and originality signature are allowed. Figure 4. State diagram

8.4.1 IDLE and HALT

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC reader. Any other data received while in this state is interpreted as an error and MIFARE Ultralight AES remains in the IDLE state. After a correctly executed HLTA command i.e. out of the ACTIVE, TRACEABLE or AUTHENTICATED state, the default waiting state changes from the IDLE state to the HALT state. This state can then be exited with a WUPA command only. Please refer to [2] for implementation hints for a card polling algorithm that respects relevant timing specifications from ISO/IEC 14443 Type A.

8.4.2 READY1

In this state, the contactless reader resolves the first part of the UID (3 bytes) or complete Random ID using the ANTICOLLISION or SELECT commands in cascade level 1. This state is exited correctly after execution of either of the following commands:

SELECT command from cascade level 1: once double side UID is configured the PCD switches the MIFARE Ultralight AES into READY2 state where the second part of the UID is resolved. The response of the MIFARE Ultralight AES to the cascade level 1 SELECT command is the SAK byte with value 04h. It indicates that the UID has not been completely received by the contactless reader and another anti-collision level is required. Once Random ID is configured the PCD switches the MIFARE Ultralight AES into ACTIVE state. In this case SAK answer will indicate completion of the anti-collision process.
READ command (from address 0): all anti-collision mechanisms are bypassed and the MIFARE Ultralight AES switches directly to the ACTIVE state. Remark: If more than one MIFARE Ultralight AES is in the field of the contactless reader, a read from address 0 will cause a collision because of the different serial numbers, but all MIFARE Ultralight AES devices will be selected. Any other data received in state READY1 state is interpreted as an error and the MIFARE Ultralight AES falls back to its waiting state (IDLE or HALT, depending on its previous state).

8.4.3 READY2

In this state, the MIFARE Ultralight AES supports the contactless reader in resolving the second part of its UID (4 bytes) with the cascade level 2 ANTICOLLISION command. This state is usually exited using the cascade level 2 SELECT command. Alternatively, READY2 state can be skipped using a READ command (from block address 00h) as described in state READY1. The response of the MIFARE Ultralight AES to the cascade level 2 SELECT command is the select acknowledge (SAK) byte. In accordance with ISO/IEC 14443, this byte indicates if the anti-collision cascade procedure has finished. The MIFARE Ultralight AES is now uniquely selected and only this device communicates with the contactless reader even when other contactless devices are present in the reader field. If more than one MIFARE Ultralight AES is in the reader field, a READ command from address 0 selects all MIFARE Ultralight AES devices. In this case, a collision occurs. Any other data received when the device is in this state is interpreted as an error and, depending on its previous state, the MIFARE Ultralight AES returns to either the IDLE state or HALT state. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 14 / 73

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC

8.4.4 ACTIVE

Allowed memory operations are operated in the ACTIVE state. Operations with a required authentication will be rejected. The ACTIVE state is exited with either HLTA or AUTHENTICATE command. Upon reception of HLTA command, MIFARE Ultralight AES transits to the HALT state. Similarly MIFARE Ultralight AES transits to the AUTHENTICATED/TRACEABLE state after successful 3-pass mutual authentication using the AUTHENTICATE command with [DataProtKey] or [UIDRetrKey] respectively. Any other unsupported data received when the device is in ACTIVE state is interpreted as an error. Depending on its previous state, the MIFARE Ultralight AES returns to either the IDLE state or HALT state.

8.4.5 TRACEABLE

In TRACEABLE state following operations are allowed depending on activated UID type: Once standard 7 byte UID is activated, there is not difference to ACTIVE state except that VCSL command is not supported in TRACEABLE state. Once RID is activated, then on top of all operations allowed in ACTIVE state in TRACEABLE state also all privacy sensitive operations reading UID bytes and originality signature are allowed. Secure messaging is supported in TRACEABLE state. The TRACEABLE state is exited with either HLTA or AUTHENTICATE command. Upon reception of HLTA command, MIFARE Ultralight AES transits to the HALT state. Similarly MIFARE Ultralight AES transits to the AUTHENTICATED/ACTIVE state after successful 3-pass mutual authentication using the AUTHENTICATE command with [DataProtKey] or [OriginalityKey] respectively. Any other unsupported data received when the device is in this state is interpreted as an error. Depending on its previous state returns to either the IDLE state or HALT state.

8.4.6 AUTHENTICATED

In the AUTHENTICATED state, all operations on memory pages, which are configured as authentication protected, can be accessed. Also all operations that are allowed in TRACEABLE state are also allowed in AUTHENTICATION state. Non-protected memory pages that do not require AUTHENTICATED state can still be accessed in AUTHENTICATED state. AUTHENTICATED state is exited with either HLTA or AUTHENTICATE command. Upon reception of HLTA command, MIFARE Ultralight AES transits to the HALT state. Similarly MIFARE Ultralight AES transits to the TRACEABLE/ ACTIVE state after successful 3-pass mutual authentication using the AUTHENTICATE command with [UIDRetrKey] or [OriginalityKey] respectively. Any other unsupported data received when the device is in this state is interpreted as an error. Depending on its previous state MIFARE Ultralight AES returns to either the IDLE state or HALT state. Authentication sequence is described in section Section 8.6.1. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 15 / 73

8.5 Memory organization

organization is shown in Table 6 . Table 6. Memory organization [144-byte user memory] are compatible to the existing MIFARE Ultralight portfolio.

8.5.1 UID/serial number

internal data bytes are programmed and write protected in the production test.

Figure 5. 7B UID/serial number According to ISO/IEC14443-3, BCC0 is defined as CT ⊕ SN0 ⊕ SN1 ⊕ SN2. accordance with ISO/ IEC 14443-3.

8.5.2 Random ID

AUTHENTICATED (DataProtKey) state to retrieve the real 7-byte UID. POWER-OFF state to IDLE state is required. TRACEABLE or AUTHENTICATED state.

8.5.3 Lock byte 0 and 1

locking, the corresponding page becomes read-only memory. and 1 are shown in Figure 6.

Remark: Page numbers in the figure are represented in decimal. Figure 6. Lock bytes 0 and 1 The default value of the lock bytes is 00 00h. Any write operation to the lock bytes is anti-tearing supported. Remark: Setting a lock bit to 1 immediately prevents write access to the respective page.

8.5.4 Lock byte 2, 3 and 4

inside the lock bytes 2, 3 and 4 is shown in Figure 7.

Remark: Page numbers in the figure are represented in decimal. Figure 7. Lock bytes 2, 3 and 4 The default value of the lock bytes is 00 00 00h. The value of MSB from page 28h is always 00h when read. Any write operation to the lock bytes is anti-tearing supported.

8.5.5 OTP bytes

modified using the WRITE command. Figure 8. OTP bytes

cannot be any longer erased. The default value of the OTP bytes is 00 00 00 00h. Any write operation to the OTP bytes features anti-tearing support.

8.5.6 Data pages

referring to 144 bytes of data memory. authentication with a key length of 128-bit, see Section 8.6.1 for further details. Remark: The default content of the data blocks at delivery is not defined.

8.5.7 Configuration pages - 144 byte user memory

the configuration pages is defined in Table 7. Table 7. Configuration Pages

Table 7. Configuration Pages...continued Table 8. Random ID RID_ACT and Secure Messaging SEC_MSG_ACT - configuration byte Table 9. User memory protection AUTH0 - configuration byte Table 10. Counter CNT - configuration byte Table 11. Virtual Card Type IDentifier VCTID - configuration byte Table 12. Negative authentication limit AUTH_LIM0 - configuration byte

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC Bit number 7 6 5 4 3 2 1 0 - - - - - - AUTH_ LIM [9] AUTH_ LIM [8] Table 13. Negative authentication limit AUTH_LIM1 - configuration byte Table 14. Lock keys LOCK_Keys configuration byte

Description

RID_ACT 1 0b Enables or disables the RandomID functionality. 0b ... RandomID disabled (default) 1b ... RandomID enabled To activate RID new power-on cycle is needed. AUTH0 7 3Ch AUTH0 defines the page address from which the AES authentication is required. Valid address range for byte AUTH0 is from 00h to 3Bh. If AUTH0 is set to a page address outside of the valid address range, the AES authentication protection is effectively disabled. PROT 1 1b Configures the data access restrictions without authentication 0b … write access restricted, but read access allowed 1b … read and write access restricted CNT_INC_EN 1 1b Configuration option to allow a counter increment of counter "0x02" in ACTIVE or TRACEABLE state 0b … Counter increment allowed only in AUTHENTICATE state 1b … Counter increment allowed on top of AUTHENTICATE also in ACTIVE or TRACEABLE state CNT_RD_EN 1 1b Configuration option to read of counter "0x02" in ACTIVE or TRACEABLE state 0b ... Counter read allowed only in AUTHENTICATE state 1b ... Counter read allowed on top of AUTHENTICATE also in ACTIVE or TRACEABLE state VCTID 8 00000101b Supports the virtual card architecture by replying to a Virtual Card Select Last (VCSL) command with defined Virtual Card Type IDentifier (VCTID) answer. 00000101b ... 05h (default) AUTH_LIM 10 000h Limitation of failed AES authentications 000h ... limit of failed AES authentication attempts disabled (default) 001h - 3FEh ... up to 1022 negative AES authentication attempts allowed Table 15. Configuration parameter descriptions

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC Field Bit(s) Default value LOCK_AES_ KEY0 1 0b LOCK_AES_KEY0 permanently locks the AES_KEY0 in pages 30h-33h. 0b … AES_KEY0 is not locked 1b … AES_KEY0 is locked Remark: Bit can only be set once. There is no command to set it back to unlocked. LOCK_AES_ KEY1 1 0b LOCK_AES_KEY1 permanently locks the AES_KEY1 in blocks 34h-37h. 0b ... AES_KEY1 is not locked 1b ... AES_KEY1 is locked Remark: Bit can only be set once. There is no command to set it back to unlocked. BLOCK_LOCK_ KEY 1 0b BLOCK_LOCK_KEY permanently locks the LOCK_AES_KEY0 and LOCK_AES_ KEY1. 0b ... not locked 1b ... locked Remark: Bit can only be set once. There is no command to set it back to unlocked. LOCK_USR_ CFG 1 0b LOCK_USR_CFG permanently locks the modification of user configuration elements. 0b … not locked 1b … locked Remark: Bit can only be set once. There is no command to set it back to unlocked. SEC_MSG_ACT 1 0b SEC_MSG_ACT allows the user to activate Secure Messaging. 0b … Secure messaging not activated (default) 1b … Secure messaging activated RFU - not defined Reserved for Future Use - implemented. The recommendation is to write bits and bytes denoted as RFU as 0b. Table 15. Configuration parameter descriptions...continued locked memory elements immediately to a NAK response.

8.5.8 Configuration for memory access via AES authentication

configuration byte AUTH0, located in page 29h within byte 3, see Section 8.5.7 .

AUTH0 defines the page address from which the authentication is required. Valid address values for byte AUTH0 are from 00h to 3Bh.
Setting AUTH0 to a value higher than 3Bh effectively disables memory protection.
PROT configuration bit only determines in ACTIVE or TRACEABLE state if write access is restricted or both read and write access are restricted.
To activate new AUTH0 and PROT setting, the state transition from POWER-OFF state to IDLE state is required. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 23 / 73

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC

8.5.9 Counter 3x 24-bit one way

The MIFARE Ultralight AES features three independent 24-bit one-way counters with two of them accessible without restrictions in ACTIVE and TRACEABLE states and third one with optional increment and read control in those states. Settings of the counter with the optional AES protection are configurable within the user memory protection configuration. These counters are located in a separate part of the EEPROM which is not directly addressable using READ, FAST_READ or WRITE commands. The actual value can be retrieved by using the READ_CNT command, the counters can be incremented with the INCR_CNT command. The INCR_CNT command features anti-tearing support. In the initial state, counter values are set to 000000h. The maximum value of each counter is FFFFFFh. The counters can be incremented by an arbitrary 3-byte value. The incremented value is valid immediately without necessity of an RF reset or re-activation. Once counter value reaches FFFFFFh and an increment is performed via a valid INCR_CNT command, the MIFARE Ultralight AES replies a NAK. If the sum of the addressed counter value and the increment value in the INCR_CNT command is higher than FFFFFFh, the MIFARE Ultralight AES replies a NAK and does not update the respective counter. An increment by zero (000000h) is always possible, but does not have any impact on the counter value. Remark: With the user memory protection configuration (see Section 8.5.7 ) the read and increment functionality of the counter "0x02" can be restricted.

8.6 AES authentication protection

The memory access to a configurable part of the memory can be constrained by a 3- pass mutual authentication. The 128-bit secret AES key is typically programmed into the configuration pages at the tag personalization in a secure environment. In the initial state of MIFARE Ultralight AES, the authentication protection is disabled. The AES key is freely writable in this state. Access to the configuration pages and any part of the user memory can be restricted by setting AUTH0 to a page address within the available memory space. From this page address onwards the memory is protected, see Section 8.5.8. Once AES authentication protection is activated, following items must be handled appropriately:

AUTH0 defines the page address from which the authentication is required. Valid address values for byte AUTH0 are from 00h to 3Bh. Value higher than 3Bh effectively disables memory protection, but still keeping AES authentication procedure working.
AUTH_LIM to limit failed AES authentication attempts during lifetime
PROT determines if write access is restricted or both read and write accesses are restricted
CNT_RD_EN to limit read of counter "0x02" in ACTIVE and TRACEABLE state. If set, Read allowed in AUTHENTICATED state only.
CNT_INC_EN to limit increment of counter "0x02" in ACTIVE and TRACEABLE state. If set, Increment allowed in AUTHENTICATED state only. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 24 / 73

8.6.1 AES authentication

Vector (IV) for encryption of the response uses a byte value of all zeroes. Table 16. AES authentication

is enciphered again by the PICC. message and retrieves RndA’. proceeds further accordingly. Table 16. AES authentication...continued according to NIST Special Publication 800-38A. The used key is a 128-bit AES Key. authentication limit (AUTH_LIM) can be set.

8.6.2 AES authentication example

default 128-bit AES key used has a value of all zeros. Table 17. Numerical AES authentication example

Table 17. Numerical AES authentication example...continued

8.6.3 Programming of the AES key to memory

AUTHENTICATED state to allow to write AES keys. Table 18. DataProtKey memory configuration

A2 30 0F 0E 0D 0C CRC
A2 31 0B 0A 09 08 CRC
A2 32 07 06 05 04 CRC
A2 33 03 02 01 00 CRC Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 27 / 73

Table 19. DataProtKey memory configuration based on example configuration Remark: A re-programmed AES authentication key has immediate effect.

8.6.4 Protection of configuration pages

8.6.5 Limiting failed authentication attempts

AUTH_LIM to a value of 000h, which is also the default state of MIFARE Ultralight AES. authentication is valid or not.

8.7 Plain communication

8.8 CMAC protected message integrity protection

8.8.1 Session Key Generation

be valid only for the given session, see Figure 9. Figure 9. Session key generation for Secure Messaging authentication. The generated key is also an AES 128-bit key.

a 2-byte label, distinguishing the purpose of the key: 5AA5h for MACing
a 2-byte counter, fixed to 0001h as only 128-bit keys are generated.
a 2-byte length, fixed to 0080h as only 128-bit keys are generated.
a 26-byte context, constructed using the two random numbers exchanged, RndA and RndB With that input data specification, the 32-byte input session vector SV2 is derived as follows: RndB[9..0]||RndA[7..0] with || indicating concatenation operator. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 29 / 73

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC Then, the 16-byte session key is constructed as follows: SesAuthMACKey = PRF(Kx; SV2)

8.8.2 CMAC Calculation for data integrity

The Cipher-based Message Authentication Codes (CMAC) are calculated using the underlying block cipher according to the CMAC standard described in NIST Special. Publication 800-38B, see [15]. Padding is applied according to the standard.

8.8.3 CMAC Communication Mode

PCD communicating with MIFARE Ultralight AES in MAC communication mode shall calculate MAC over:

2-bytes of Command Counter - CmdCtr
1- byte of Command Code
Argument bytes For responses, the MIFARE Ultralight AES calculates CMAC over:
2-bytes of Command Counter - CmdCtr
Response data bytes CRC bytes appended in both directions at the end of the communication message are excluded from the MAC calculation. CmdCtr is included in the CMAC calculation for commands and responses in order to prevent replay attacks. The CmdCtr is reset to 0000h at PCD and PICC after a subsequent authentication using AUTHENTICATE command. CmdCtr value is maintained as long as MIFARE Ultralight AES remains in AUTHENTICATED/TRACEABLE state. Subsequent authentications using the AUTHENTICATE command will reset CmdCtr to 0000h. The command counter is incremented between each command and response. In cryptographic calculations, the CmdCtr is represented with LSB first. If the CmdCtr holds the value FFFFh and a command maintaining the active authentication arrives at the PICC, it leads to an error response and the command is handled like the CMAC was wrong. If a CMAC over the command is received, the PICC verifies the CMAC and rejects commands that do not contain a valid CMAC. In this case, the ongoing command and transaction are aborted, the authentication state is lost and the NAK is sent without a CMAC appended. Note that any other error during the command execution has the same consequences. In MAC communication mode ACK responses are replaced by standalone MAC calculated over CmdCtr. In this case also CRC is added.

8.9 Product originality

The MIFARE Ultralight AES offers two ways to verify the originality of the IC manufactured by NXP Semiconductors:

For NXP tools AES-based originality key leveraging the AES authentication with an NXP die specific 128-bit AES key stored in the hidden part of the memory to check the origin of the IC
For customer application ECC (Elliptic Curve Cryptography) based originality signature according to ECDSA (Elliptic Curve Digital Signature Algorithm) with a public key for verification Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 30 / 73

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC The purpose of the ECC originality check during (pre-)personalization is to protect customer investments by identifying mass penetration of non-NXP originated MIFARE Ultralight AES ICs into an infrastructure. As individual signatures can still be copied, it does not completely prevent hardware copy or emulation of individual MIFARE Ultralight AES ICs. As such, a valid signature is not a full guarantee. Therefore, this signature validation should be complemented with a check to detect if multiple ICs with the same UID are being introduced in the system. The 48-bytes asymmetric originality signature is based on standard Elliptic Curve Cryptography (ECC curve secp192r1, see [19]), according to the ECDSA algorithm and only requires a public key for the verification. The originality signature can be read with the READ_SIG command. The MIFARE Ultralight AES provides the possibility to customize the originality signature to personalize the IC individually for specific application. If the PICC is not configured for Random ID, the READ_SIG command is available even in ACTIVE state. If the PICC is configured for Random ID, an authentication with either DataProdKey or UIDRetrKey is required, see Section 8.5.

8.9.1 Originality Signature

At delivery, the MIFARE Ultralight AES is pre-programmed with the NXP originality signature. This signature is locked in the hidden part of the memory. If needed, the signature can be re-programmed with a custom-specific signature using the WRITE_SIG command during the personalization process by the customer. The signature can be permanently locked afterward with the LOCK_SIG command to avoid further modifications. Remark: If no customized originality signature is required, it is recommended to permanently lock the NXP signature during the initialization process with the LOCK_SIG command.

8.9.2 Originality Signature at Delivery

To verify the signature (for example with the use of the public domain crypto library OpenSSL) the tool domain parameters shall be set to secp192r1, defined within the standards for elliptic curve cryptography SEC, see [19]. As input data for signature validation the 7-byte UID without Hash is in use. For details on how to check the NXP signature values are provided in following application note see [5].

8.10 Virtual Card Architecture Support

The MIFARE Ultralight AES supports in ACTIVE state the Virtual Card Architecture by replying to a Virtual Card Select Last (VCSL) command with a Virtual Card Type IDentifier (VCTID), see Section 10.11. The VCTID that is replied can be programmed in the configuration pages. It enables infrastructure support of this feature to process MIFARE product-based cards across different MIFARE families in a common way. For example, a contactless system is enabled to select a specific virtual MIFARE product-based card inside a cell phone. It can use the same card identification principle to detect that the MIFARE Ultralight AES belongs to the system, see Section 10.11. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 31 / 73

9 Command overview

9.1 MIFARE Ultralight AES Command Overview

Table 20. All memory access commands are transmitted in either plain or CMAC protected compliant to the CMAC mode of NIST Special Publication 800-38B, see [15]. Table 20. Command overview

9.2 Timings

The timing shown in this document is not to scale and values are rounded to 1 μs.

bit") and the end of communication (1 bit length of no subcarrier). specified as a timeout value. Figure 10. Frame Delay Time (from PCD to PICC)

9.3 ACK and NAK

Table 21. ACK and NAK values

9.4 ATQA and SAK responses

Table 22. It replies to final Select command with the SAK value shown in Table 22. The 2- byte ATQA value is transmitted with the least significant byte first. 14443 independent from the settings of the UID usage. LSB = bit 0. So 1 byte counts bit 1 to bit 8 instead of bit 0 to 7.

9.5 Summary of device identification data

For more details on the values below, please refer to [2], [3] and [4]. Table 22. Summary of relevant data for device identification

10 MIFARE Ultralight AES - Commands

SEC_MSG_ACT is disabled, then the CMAC bytes are not present.

10.1 GET_VERSION

identifying products across platforms and evolution steps. and Table 23 the response description is shown in Table 24. Table 26 shows the required timing. Figure 11. GET_VERSION command Table 23. GET_VERSION command Table 24. GET_VERSION response

Table 24. GET_VERSION response...continued Table 25. GET_VERSION data response for MIFARE Ultralight AES These times exclude the end of communication of the PCD. Table 26. GET_VERSION timing

10.2 READ

the command structure, refer to Figure 12. Table 39 shows the required timing. Figure 12. READ Table 27. READ command Table 28. READ response

These times exclude the end of communication of the PCD. Table 29. READ timing 3Bh are allowed as Addr parameter to the READ command. accessible memory is reached if at least first addressed page is within allowed limit.

if MIFARE Ultralight AES is in the ACTIVE or TRACEABLE state - addressing a page which is equal to or higher than AUTH0 results in a NAK response - addressing a page lower than AUTH0 results in data being returned with the roll-over mechanism occurring just before the AUTH0 defined page - in TRACEABLE state if secure messaging enabled, a CMAC on the READ command is required
if MIFARE Ultralight AES is in the AUTHENTICATED state - the READ command behaves like on a MIFARE Ultralight AES without access protection - if secure messaging enabled, a CMAC on the READ command is required Remark: AES key values can never be directly read out of the memory. When reading from the pages holding key values, all 00h bytes are replied to the PCD instead. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 38 / 73

10.3 FAST_READ

details on command structure, refer to Figure 13. Table 32 shows the required timing. Figure 13. FAST_READ command Table 30. FAST_READ command Table 31. FAST_READ response

These times exclude the end of communication of the PCD. Table 32. FAST_READ timing 00h to 3Bh are allowed as StartAddr parameter to the FAST_READ command. Addressing a memory page above the limits results in a NAK response.

if the MIFARE Ultralight AES is in the ACTIVE or TRACEABLE state - if EndAddr is equal to or higher than AUTH0 a NAK is replied - in TRACEABLE state if secure messaging enabled, a CMAC on the FAST_READ command is required
if the MIFARE Ultralight AES is in the AUTHENTICATED state - the FAST_READ command behaves like on a MIFARE Ultralight AES without access protection - if secure messaging enabled, a CMAC on the FAST_READ command is required Remark: Key values can never directly be read out of the memory. When reading from the pages holding those two values, all 00h bytes are replied to the PCD instead. Remark: The FAST_READ command is able to read out the whole accessible memory in one shot. Nevertheless, receive buffer of the PCD must be able to handle the requested amount of data as there is no chaining possibility. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 40 / 73

10.4 WRITE

addressed MIFARE Ultralight AES page. The WRITE command is shown in Figure 14. Table 35 shows the required timing. Figure 14. WRITE Table 33. WRITE command enabled by set of SEC_MSG_ACT. Table 34. WRITE response

These times exclude the end of communication of the PCD. Table 35. WRITE timing Addr parameters to the WRITE command. Addressing a memory page above the limits results in a NAK response.

if MIFARE Ultralight AES is in the ACTIVE or TRACEABLE state - writing to a page which address is equal or higher than AUTH0 results in a NAK response - in TRACEABLE state if secure messaging enabled, a CMAC on the WRITE command is required
if MIFARE Ultralight AES is in the AUTHENTICATED state - the WRITE command behaves like on a MIFARE Ultralight AES without access protection MIFARE Ultralight AES features tearing support write operations to specific memory content. The following pages are protected against tearing events during a WRITE operation:
page 02h containing lock bytes 0 and 1
page 03h containing OTP bits
page 28h containing the lock bytes 2, 3 and 4 for the MIFARE Ultralight AES Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 42 / 73

10.5 READ_CNT

the counter number and returns the 24-bit counter value of the corresponding counter. the AUTHENTICATE state. The command structure is shown in Figure 15. Table 38 shows the required timing. Figure 15. READ_CNT command Table 36. READ_CNT command Table 37. READ_CNT response

These times exclude the end of communication of the PCD. Table 38. READ_CNT timing If secure messaging enabled, a CMAC on the READ_CNT command is required.

10.6 INCR_CNT

Table 41 shows the required timing. Figure 16. INCR_CNT command Table 39. INCR_CNT command enabled by set of SEC_MSG_ACT. Table 40. INCR_CNT response

These times exclude the end of communication of the PCD. Table 41. INCR_CNT timing significant byte is ignored. of the counter 00h by 01h, is formulated as INCR CNT 00 01 00 00 00. If secure messaging enabled, a CMAC on the INCR_CNT command is required.

10.7 READ_SIG

Section 8.9.1) if it has been unlocked with the LOCK_SIG command (see, Section 10.9 ). Table 44 shows the required timing. Figure 17. READ_SIG command Table 42. READ_SIG command Table 43. READ_SIG response

Table 43. READ_SIG response...continued These times exclude the end of communication of the PCD. Table 44. READ_SIG timing If secure messaging enabled, a CMAC on the READ_SIG command is required.

10.8 WRITE_SIG

the dedicated originality signature memory. Table 47 shows the required timing. Figure 18. WRITE_SIG command Table 45. WRITE_SIG command enabled by set of SEC_MSG_ACT. Table 46. WRITE_SIG response

These times exclude the end of communication of the PCD. Table 47. WRITE_SIG timing block beyond the limits above results in a NAK response from MIFARE Ultralight AES. Table 48. Blocks for the WRITE_SIG command results in a NAK response from the MIFARE Ultralight AES. If secure messaging enabled, a CMAC on the WRITE_SIG command is required.

10.9 LOCK_SIG

command is shown in Figure 19. Table 51 shows the required timing. Figure 19. LOCK_SIG command Table 49. LOCK_SIG command enabled by set of SEC_MSG_ACT. Table 50. LOCK_SIG response

Table 50. LOCK_SIG response...continued These times exclude the end of communication of the PCD. Table 51. LOCK_SIG timing If secure messaging enabled, a CMAC on the LOCK_SIG command is required.

10.10 AUTHENTICATE

16 Byte ek(RndB)PICC ,,ACK''

Figure 20. AUTHENTICATE Part 1 Table 52. AUTHENTICATE Part 1 command Table 53. AUTHENTICATE Part 1 response

Table 53. AUTHENTICATE Part 1 response...continued These times exclude the end of communication of the PCD. Table 54. AUTHENTICATE Part 1 timing Table 55. AUTHENTICATE Part 2

32 Byte ek(RndA || RndB')

Figure 21. AUTHENTICATE Part 2 Table 56. AUTHENTICATE Part 2 command

Table 57. AUTHENTICATE Part 2 response These times exclude the end of communication of the PCD. Table 58. AUTHENTICATE Part 2 timing

10.11 VCSL

shown in Figure 22 and Table 59. Table 61 shows the required timing. Figure 22. VCSL command Table 59. VCSL command Table 60. VCSL command

These times exclude the end of communication of the PCD. Table 61. VCSL timing

11 Limiting values

the device. Exposure to limiting values for extended periods can affect device reliability. In accordance with the Absolute Maximum Rating System (IEC 60134). Table 62. Limiting values This device has limited built-in ElectroStatic Discharge (ESD) protection. during storage or handling to prevent electrostatic damage to the gates.

12 Characteristics

12.1 Electrical characteristics

Table 63. Characteristics of MIFARE Ultralight AES

13 Wafer specification

Table 64. Wafer specifications MIFARE Ultralight AES [2] Pads VSS and TESTIO are disconnected at wafer treatment.

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC

14 Delivery

The customer purchasing a product of the MIFARE Ultralight AES family has to make sure that they receive the evaluated version. This section describes the measures that are needed to ensure delivery of the evaluated version. The evaluated version of the MIFARE Ultralight AES can be ordered from NXP by referencing the respective commercial type name as listed in Section 5. NXP offers two ways of delivery of the product: 1. The customer collects the product themselves at the NXP site. 2. The product is sent by NXP to the customer and protected by special measures. These methods are described in the Section 14.1 and Section 14.2 respectively.

14.1 Delivery as a wafer

When the product is delivered as wafer, there reside functional and non-functional ICs on the wafer. The non-functional ICs cannot be used but have to be handled securely, too. These ICs must be destroyed to such an extent that no analysis or misuse is possible after destruction. The non-functional ICs (scrap) shall be handled secure until the destruction. Information about non-functional items is accessible via the eMAP-Portal (http:// wmt.nxp.com). The Access sheet with the Login data is enclosed with the delivery to allow the download of the electronic wafer map file. In this case, the information about non-functional ICs is stored in a so-called wafer map file. The electronic wafer map file covers the electrical test results and additionally the results of mechanical/visual inspection.

14.2 Delivery as a module

When the product is delivered as module, there reside functional and non-functional modules on the reel. The non-functional modules cannot be used but have to be handled securely, too. These modules must be destroyed to such an extent that no analysis or misuse is possible after destruction. The non-functional modules (scrap) shall be handled secure until the destruction. Information about non-functional items is accessible via the eMAP-Portal (http:// wmt.nxp.com). The Access sheet with the Login data is enclosed with the delivery to allow the download of the file. In this case, the information about non-functional modules is stored in a so-called SNR file.

14.3 Delivery method one: The customer collects the product themselves

The customer fetches the product from the following location: NXP Semiconductors (Thailand) 303 Chaengwattana Rd.Laksi Bangkok

10210 Thailand

This method guarantees that the customer gets authentic products. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 61 / 73

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC

14.4 Delivery method two: The product is sent by NXP and protected by

To guarantee that the product is not manipulated during the delivery, NXP has defined three security measures: 1. The product is delivered in parcels sealed with special tapes. The customer can examine these tapes in order to make sure that they have not been manipulated. 2. The customer shall identify the product as described in Section 10.1. 3. The customer should check the originality by verification of the Originality Signature Section 8.9.2. These measures shall be applied to ensure that a genuine chip is in use. The product is delivered directly to the customer or via the Global Distribution Center: NXP Semiconductors Netherlands B.V. (Global Distribution Centre) c/o CEVA Logistics (Malaysia) Sdn Bhd Lot 9A Jalan Tiang U8/92, Bukit Jelutong Industrial Park, 40150 Shah Alam, Selangor Darul Ehsan, MALAYSIA Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 62 / 73

For more details on the MOA8 contactless modules, please refer to [12].

Total package thickness, exclusive punching burr.

For unspecified dimensions see PLLMC-drawing given in the subpackage code. Figure 23. Package outline SOT500-4

15.1 Bare die outline

For more details on the wafer delivery forms, see [13]. Figure 24. Bare die outline

16 Abbreviations

Table 65. Abbreviations

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC

17 References

[1] ISO/IEC 14443-2: July 2016 Identification cards -- Contactless integrated circuit cards -- Proximity cards -- Part 2: Radio frequency power and signal interface [2] ISO/IEC 14443-3: July 2018 Identification cards -- Contactless integrated circuit cards -- Proximity cards -- Part 3: Initialization and anti-collision [3] AN10833 MIFARE Interface Platform Type Identification Procedure [4] AN10834 MIFARE ISO/IEC 14443 PICC Selection [5] AN13452 MIFARE Ultralight AES - features and hints [6] AN1303 MIFARE Ultralight as Type 2 Tag [7] AN13453 MIFARE Ultralight AES - coil design guide [8] AN13454 MIFARE Ultralight AES - quick start guide [9] FIPS PUB 197. Advanced Encryption Standard (AES) November 2001. [10] ISO/IEC 10116: Information technology - Security techniques - Modes of operation for an n-bit block cipher International Organization for Standardization, 2017, [12] Contactless smart card module specification MOA8 Delivery Type Description, BU-ID Document number 1636 [13] General specification for 8" wafer on UV-tape Delivery Type Description, BU-ID Document number 1005 [14] NIST Special Publication 800-38A National Institute of Standards and Technology (NIST). Recommendation for BlockCipher Modes of Operation. [15] NIST Special Publication 800-38B National Institute of Standards and Technology (NIST). Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication. https://csrc.nist.gov/publications/detail/sp/800-38b/final Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 66 / 73

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC [16] NIST Special Publication 800-90B Recommendation for the Entropy Sources Used for Random Bit Generation, January 2018. [17] NIST Special Publication 800-108 National Institute of Standards and Technology (NIST). Recommendation for key derivation using pseudorandom functions. [18] Certicom Research. Sec 1 Elliptic curve cryptography. Version 2.0, May 2009. [19] Certicom Research. Sec 2 Recommended Elliptic Curve Domain Parameters. Version 2.0, January 2010. [20] NFC Forum Tag 2 Type Operation, Technical Specification NFC Forum, 31.05.2011, Version 1.0 [21] NFC Data Exchange Format (NDEF), Technical Specification NFC Forum, 24.07.2006, Version 1.0 Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 67 / 73

Section 17 "References": updated MF0AES(H)x0 v.3.0 20220222 Product data sheet MF0AES(H)x0 v.2.0 Modifications: • Data sheet status changed into "Product data sheet" MF0AES(H)x0 v.2.0 20220204 Preliminary data sheet MF0AES(H)x0 v.1.2 Modifications: • CMAC inclusion in the commands MF0AES(H)x0 v.1.2 20220117 Objective data sheet MF0AES(H)x0 v.1.1 Modifications: • PROT bit in Configuration parameter description updated MF0AES(H)x0 v.1.1 20211220 Objective data sheet MF0AES(H)x0 v.1.0 Modifications: • General description
Table15
Wafer specification MF0AES(H)x0 v.1.0 20211006 Objective data sheet MF0AES(H)x0 v.0.3 Modifications: • General update MF0AES(H)x0 v.0.3 20210716 Objective data sheet MF0AES(H)x0 v.0.2 Modifications: • General update MF0AES(H)x0 v.0.2 20200423 Objective data sheet MF0AES(H)x0 v.0.1 Modifications: • General update MF0AES(H)x0 v.0.1 20200221 Objective data sheet -

Table 66. Revision history

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC

19 Legal information

19.1 Data sheet status

Document status[1][2] Product status[3] Definition Objective [short] data sheet Development This document contains data from the objective specification for product development. Preliminary [short] data sheet Qualification This document contains data from the preliminary specification. Product [short] data sheet Production This document contains the product specification. [1] Please consult the most recently issued document before initiating or completing a design. [2] The term 'short data sheet' is explained in section "Definitions". [3] The product status of device(s) described in this document may have changed since this document was published and may differ in case of multiple devices. The latest product status information is available on the Internet at URL http://www.nxp.com.

19.2 Definitions

Draft — A draft status on a document indicates that the content is still under internal review and subject to formal approval, which may result in modifications or additions. NXP Semiconductors does not give any representations or warranties as to the accuracy or completeness of information included in a draft version of a document and shall have no liability for the consequences of use of such information. Short data sheet — A short data sheet is an extract from a full data sheet with the same product type number(s) and title. A short data sheet is intended for quick reference only and should not be relied upon to contain detailed and full information. For detailed and full information see the relevant full data sheet, which is available on request via the local NXP Semiconductors sales office. In case of any inconsistency or conflict with the short data sheet, the full data sheet shall prevail. Product specification — The information and data provided in a Product data sheet shall define the specification of the product as agreed between NXP Semiconductors and its customer, unless NXP Semiconductors and customer have explicitly agreed otherwise in writing. In no event however, shall an agreement be valid in which the NXP Semiconductors product is deemed to offer functions and qualities beyond those described in the Product data sheet.

19.3 Disclaimers

Limited warranty and liability — Information in this document is believed to be accurate and reliable. However, NXP Semiconductors does not give any representations or warranties, expressed or implied, as to the accuracy or completeness of such information and shall have no liability for the consequences of use of such information. NXP Semiconductors takes no responsibility for the content in this document if provided by an information source outside of NXP Semiconductors. In no event shall NXP Semiconductors be liable for any indirect, incidental, punitive, special or consequential damages (including - without limitation - lost profits, lost savings, business interruption, costs related to the removal or replacement of any products or rework charges) whether or not such damages are based on tort (including negligence), warranty, breach of contract or any other legal theory. Notwithstanding any damages that customer might incur for any reason whatsoever, NXP Semiconductors’ aggregate and cumulative liability towards customer for the products described herein shall be limited in accordance with the Terms and conditions of commercial sale of NXP Semiconductors. Right to make changes — NXP Semiconductors reserves the right to make changes to information published in this document, including without limitation specifications and product descriptions, at any time and without notice. This document supersedes and replaces all information supplied prior to the publication hereof. Suitability for use — NXP Semiconductors products are not designed, authorized or warranted to be suitable for use in life support, life-critical or safety-critical systems or equipment, nor in applications where failure or malfunction of an NXP Semiconductors product can reasonably be expected to result in personal injury, death or severe property or environmental damage. NXP Semiconductors and its suppliers accept no liability for inclusion and/or use of NXP Semiconductors products in such equipment or applications and therefore such inclusion and/or use is at the customer’s own risk. Applications — Applications that are described herein for any of these products are for illustrative purposes only. NXP Semiconductors makes no representation or warranty that such applications will be suitable for the specified use without further testing or modification. Customers are responsible for the design and operation of their applications and products using NXP Semiconductors products, and NXP Semiconductors accepts no liability for any assistance with applications or customer product design. It is customer’s sole responsibility to determine whether the NXP Semiconductors product is suitable and fit for the customer’s applications and products planned, as well as for the planned application and use of customer’s third party customer(s). Customers should provide appropriate design and operating safeguards to minimize the risks associated with their applications and products. NXP Semiconductors does not accept any liability related to any default, damage, costs or problem which is based on any weakness or default in the customer’s applications or products, or the application or use by customer’s third party customer(s). Customer is responsible for doing all necessary testing for the customer’s applications and products using NXP Semiconductors products in order to avoid a default of the applications and the products or of the application or use by customer’s third party customer(s). NXP does not accept any liability in this respect. Limiting values — Stress above one or more limiting values (as defined in the Absolute Maximum Ratings System of IEC 60134) will cause permanent damage to the device. Limiting values are stress ratings only and (proper) operation of the device at these or any other conditions above those given in the Recommended operating conditions section (if present) or the Characteristics sections of this document is not warranted. Constant or repeated exposure to limiting values will permanently and irreversibly affect the quality and reliability of the device. Terms and conditions of commercial sale — NXP Semiconductors products are sold subject to the general terms and conditions of commercial sale, as published at http://www.nxp.com/profile/terms, unless otherwise agreed in a valid written individual agreement. In case an individual agreement is concluded only the terms and conditions of the respective agreement shall apply. NXP Semiconductors hereby expressly objects to applying the customer’s general terms and conditions with regard to the purchase of NXP Semiconductors products by customer. No offer to sell or license — Nothing in this document may be interpreted or construed as an offer to sell products that is open for acceptance or the grant, conveyance or implication of any license under any copyrights, patents or other industrial or intellectual property rights. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 69 / 73

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC Quick reference data — The Quick reference data is an extract of the product data given in the Limiting values and Characteristics sections of this document, and as such is not complete, exhaustive or legally binding. Export control — This document as well as the item(s) described herein may be subject to export control regulations. Export might require a prior authorization from competent authorities. Suitability for use in non-automotive qualified products — Unless this data sheet expressly states that this specific NXP Semiconductors product is automotive qualified, the product is not suitable for automotive use. It is neither qualified nor tested in accordance with automotive testing or application requirements. NXP Semiconductors accepts no liability for inclusion and/or use of non-automotive qualified products in automotive equipment or applications. In the event that customer uses the product for design-in and use in automotive applications to automotive specifications and standards, customer (a) shall use the product without NXP Semiconductors’ warranty of the product for such automotive applications, use and specifications, and (b) whenever customer uses the product for automotive applications beyond NXP Semiconductors’ specifications such use shall be solely at customer’s own risk, and (c) customer fully indemnifies NXP Semiconductors for any liability, damages or failed product claims resulting from customer design and use of the product for automotive applications beyond NXP Semiconductors’ standard warranty and NXP Semiconductors’ product specifications. Translations — A non-English (translated) version of a document, including the legal information in that document, is for reference only. The English version shall prevail in case of any discrepancy between the translated and English versions. Security — Customer understands that all NXP products may be subject to unidentified vulnerabilities or may support established security standards or specifications with known limitations. Customer is responsible for the design and operation of its applications and products throughout their lifecycles to reduce the effect of these vulnerabilities on customer’s applications and products. Customer’s responsibility also extends to other open and/or proprietary technologies supported by NXP products for use in customer’s applications. NXP accepts no liability for any vulnerability. Customer should regularly check security updates from NXP and follow up appropriately. Customer shall select products with security features that best meet rules, regulations, and standards of the intended application and make the ultimate design decisions regarding its products and is solely responsible for compliance with all legal, regulatory, and security related requirements concerning its products, regardless of any information or support that may be provided by NXP. NXP has a Product Security Incident Response Team (PSIRT) (reachable at PSIRT@nxp.com) that manages the investigation, reporting, and solution release to security vulnerabilities of NXP products.

19.4 Licenses

Purchase of NXP ICs with NFC technology — Purchase of an NXP Semiconductors IC that complies with one of the Near Field Communication (NFC) standards ISO/IEC 18092 and ISO/IEC 21481 does not convey an implied license under any patent right infringed by implementation of any of those standards. Purchase of NXP Semiconductors IC does not include a license to any NXP patent (or other IP right) covering combinations of those products with other products, whether hardware or software.

19.5 Trademarks

Notice: All referenced brands, product names, service names, and trademarks are the property of their respective owners. NXP — wordmark and logo are trademarks of NXP B.V. DESFire — is a trademark of NXP B.V. MIFARE — is a trademark of NXP B.V. MIFARE Plus — is a trademark of NXP B.V. MIFARE Ultralight — is a trademark of NXP B.V. Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 70 / 73

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC Tables Tab. 6. Memory organization [144-byte user Tab. 8. Random ID RID_ACT and Secure Messaging SEC_MSG_ACT - configuration Tab. 9. User memory protection AUTH0 - Tab. 11. Virtual Card Type IDentifier VCTID - Tab. 12. Negative authentication limit AUTH_LIM0 - Tab. 13. Negative authentication limit AUTH_LIM1 - Tab. 19. DataProtKey memory configuration based Tab. 22. Summary of relevant data for device Tab. 25. GET_VERSION data response for MIFARE Tab. 64. Wafer specifications MIFARE Ultralight Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 71 / 73

NXP Semiconductors MF0AES(H)20 MIFARE Ultralight AES contactless limited-use IC Figures Fig. 3. Contact assignments for SOT500-4 Fig. 9. Session key generation for Secure Product data sheet Rev. 3.1 — 29 April 2022 COMPANY PUBLIC 72 / 73

Product Information

MF0AES20 specifications and overview.

Summary

MIFARE Ultralight AES contactless limited-use IC Rev. 3.1-29 April 2022

Description

MIFARE Ultralight AES contactless limited-use IC Rev. 3.1-29 April 2022

Source title MF0AES20 Datasheet(PDF) - NXP Semiconductors

Related Parts

More parts from the same family.

Browse manufacturer