MF2DL1000DA4/02

MF2DLHX0 NXP | Alldatasheet

Document overview

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

Technical content

MF2DL(H)x0 MIFARE DESFire Light contactless application IC Rev. 3.3 — 5 April 2019 Product data sheet

430733 COMPANY PUBLIC

1 General description

1.1 Introduction

MIFARE DESFire Light (MF2DL(H)x0) is a versatile contactless smart card platform serving the requirements of applications managed by one single entity. Offering a powerful mix between performance, security, privacy and flexibility. It addresses the needs of limited use and simple extended use applications. Based on these parameters MIFARE DESFire Light is a trusted platform targeting the secure authentication of people with an intuitive convenient user experience. MIFARE DESFire Light is fully compliant with the contactless proximity smart card protocol according to ISO/IEC 14443-4 and ISO/IEC 7816-4 communication frames making it compatible with the majority of existing contactless infrastructure devices and with NFC devices, such as NFC enabled mobile handsets. Its contactless performance supports superior user convenience and reading distances up to 10 cm. MIFARE DESFire Light has a file-based memory structure compliant to ISO/IEC 7816-4 with a fixed, pre-defined configuration of six individual files (EF). The pre-defined configuration enables various use cases and allows the management of data according to best practice. Organized in one single directory (DF) and configurable access rights per file it enables different use cases of one issuing instance. MIFARE DESFire Light offers three individual standard data files with totally 544 bytes of memory for storage of application-specific data. The value file with a stored signed integer value and an upper and lower limit enables fast, flexible and secure implementation of monetary transactions, e.g. for micropayment applications. The cyclic record file with 4 entries of 16 bytes each enables an on-card logging of transactions. As a contactless platform, MIFARE DESFire Light includes a powerful transaction management. This transaction management ensures data and transaction consistency supporting applications with the avoidance of disrupted or incomplete transactions. The optional Transaction Message Authentication (TMAC) further enables operators of, e.g., payment applications with a cryptographic checksum over the complete transaction enabling the verification of a transaction by a clearing entity. MIFARE DESFire Light offers AES-based security features for authentication and data transfer over the contactless interface. The required level of security is defined by the needs of the application and can be done on a file basis. With 5 customer defined keys, MIFARE DESFire Light supports a key management addressing the organizational and security needs of the issuing entity. Beside the standard AES implementation, MIFARE DESFire Light offers an alternative AES-based protocol for authentication and secure messaging using a Leakage Resilient Primitive, LRP. The LRP works as a wrapper around the AES cryptography and enhances side-channel and fault resistance.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 2 / 132 MIFARE DESFire Light contains features like the fully encrypted communication mode enabling contactless applications to address privacy sensitive applications. With its optional support of Random ID, it enables compliance with latest user data protection regulations. Users of MIFARE DESFire Light can change the application identifier (AID) and the file identifiers (FID) according to their needs enabling compatibility with existing data models. This further enables users to complement their use cases with an NFC forum-compliant Type 4 Tag in order to enable additional, end-user centric services, such as business card sharing or pairing with a network. MIFARE DESFire Light is compatible with MIFARE DESFire EV2, a secure multi- application platform. Through this compatibility single application running on MIFARE DESFire Light can become part of a multi-application solution, combining applications from different entities, with minimal system impact. MIFARE DESFire Light is designed to support standards Class 1 smart cards antenna designs with a 17 pF input capacitance as well as smaller form factors, i.e. key fobs, wristbands, by providing 50 pF input capacitance delivery forms. This ensures high user convenience throughout different form factors.

2 Features and benefits

2.1 RF Interface & Communication Protocol

• Contactless interface compliant to ISO/IEC 14443A-2/ -3/ -4, see [1] , [2], [3]
• Support of ISO/IEC 7816-4 communication frames for highest interoperability with mobile and wearables
• Low power consumption (Hmin) enabling operating distances of up to 10 cm
• Support of fast data rates: 106 kbit/s, 212 kbit/s, 424 kbit/s, and 848 kbit/s
• Support of double size (7-byte) Unique Identifiers (UID) and optionally Random ID (RID) according to ISO 14443-3 [2]
• Configurable communication frame size to support up to 128 bytes
• Fast start-up time for reliable and robust detection of MIFARE DESFire Light in legacy terminals
• Support of ISO 7816-4 wrapped commands compliant to a subset of MIFARE DESFire EV2 commands

2.2 Memory Organization

• 640 bytes user memory, equivalent to available user memory on legacy MIFARE Classic 1 kB product
• Data retention of 10 years and write endurance of minimum 200.000 cycles
• File system compliant to ISO/IEC 7816-4 with one predefined Directory File (DF) and a set of Elementary Files (EF) – Three standard data files, one with 32 bytes and two with 256 bytes – One cyclic record file of 4 records of each 16-byte record size – One value file for value operations including upper and lower limits – Optional Transaction Message Authentication Code (TMAC) file for transaction protection
• File system compliant with MIFARE DESFire EV2 file system

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 3 / 132

• User configurable file naming enabling compatibility to legacy systems and NFC Type 4 Tag compliant configurations

2.3 Security and Privacy

• Common Criteria certification: EAL4 for both Hardware and Software
• Secure messaging compliant to standard AES according to NIST Special Publication 800-38A and 800-38B [5] [6] – Optional enhanced side channel attack protection using LRP wrapped AES operation according to [10] – Secure messaging compatible with a subset of MIFARE DESFire EV2 secure messaging
• Five customer defined AES 128-bit keys including key versions
• Optional Random ID for enhanced privacy
• Individual AES 128-bit TMAC key for enhanced transaction protection
• Transaction counter limit to limit the number of transactions with the application
• 3-pass mutual authentication
• Flexible access control configurable per file (EF) – Individual key configuration for Read (R) / Write (W) / ReadWrite (RW) / Configuration
• Configurable secure messaging communication mode – Plain communication – CMAC protected for message integrity protection – Full Enciphered plus CMAC for full encryption of complete data transferred through contactless interface
• ECC-based NXP originality signature
• AES-based originality keys leveraging the LRP wrapped AES authentication

2.4 Specific Features

• Transaction-oriented automatic anti-tearing mechanism
• Configurable ATS information for card personalization
• Functional compatibility with MIFARE DESFire EV2 for easy integration of applications designed on MF2DL(H)x0 into flexible multi-application solutions
• High input capacitance (50 pF) for small form factor design available

3 Applications

MIFARE DESFire Light can be used in various contactless applications, some target applications are mentioned below.

• Access management
• Event ticketing
• Transport ticketing
• Account based services
• Electronic voucher
• Gaming
• Loyalty cards

4 Ordering information

Table 1. Ordering information [1] Delivered on film frame carrier with electronic fail die marking according to SECSII format.

5 Quick reference data

Table 2. Quick reference data

6 Block diagram

Figure 1. MIFARE DESFire Light IC blocks

7 Pinning information

7.1 Pinning

The pinning for the MF2DL(H)x0 is shown in Figure 2 for a contactless MOA8 module. Figure 2. Pin configuration for SOT500-4 (MOA8) The pinning for the MF2DL(H)x0 is shown in Figure 3 for a contactless MOA4 module. Figure 3. Pin configuration for SOT500-2 (MOA4) Table 3. Pin allocation table

8 Functional description

8.1 Interface initialization and protocol

uses transmission protocol as specified in ISO/IEC 14443-4 [3] of PICC Type A.

8.1.1 Default ISO/IEC 14443 parameter values

This section describes the default values for ISO/IEC 14443 activation and selection. requires a power cycle to make those changes effective. ATQA bytes are transmitted as LSB first. the value of SAK is 20h, indicating UID complete and supporting ISO/IEC 14443-4. first byte of the double size UID is fixed to 04h, indicating NXP as manufacturer. Table 4. Default ATS value

8.1.2 Setting of higher communication speed

communication speed up to 848 kbit/s according to ISO/IEC 14443-4 [3].

8.1.3 Half-duplex block transmission protocol

extension, protocol operation, and all rules or handling as in [3].

8.2 User memory

Figure 4. In the DF (application), there are 6 EFs (files) and 5 keys.

4 Records

1 TMAC Key

5 Application

Figure 4. MIFARE DESFire Light application

8.2.1 Application and file selection

the Read_Sig command, see Section 11.11.1.

8.2.2 Default Application Name and ID

• DF Name: A00000039656434103F015400000000Bh
• File Identifier: DF01h DF Name and File ID can be changed using SetConfiguration command.

8.2.3 Files

ChangeFileSettings command can be used to change the access rights configuration. duplication of a file number or a file ID is not allowed. configuration or disable the TMAC feature. File access rights can be restricted with the keys of the application. Table 5. File management 00h [1] EF00h 256 bytes Storage of raw data e.g. 04h EF04h 256 bytes Storage of raw data e.g. Limit of application selection. reserved in the scope of implicit selection. The File no. can be changed in order to leverage implicit selection.

8.2.3.1 StandardData file

at a certain offset in the StandardData file and with a certain byte length. FCI information in case it is renamed to 1Fh. A StandardData file can be read with the ReadData and ISOReadBinary commands. The data can be written with the WriteData and ISOUpdateBinary commands.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 11 / 132 A StandardData file is not covered by the transaction mechanism and therefore does not implement a transaction-based backup mechanism. Thus data are available to read as soon as they are written in the file. The writing operations of single frames up to 128 bytes with a WriteData or ISOUpdateBinary command are also tearing protected.

8.2.3.2 Value file

The Value file stores the data as a 4 byte signed integer. The Value file can be read with the GetValue command. The value can be manipulated with Credit, Debit and LimitedCredit commands, respectively. The value is restricted by an upper and lower limit that the current value of the file cannot exceed. The Value file can support a LimitedCredit feature as defined in Section 11.8.6. The free GetValue allows a user to get freely the value of a value file bypassing an authentication if necessary as long as there is one access condition associated with GetValue command that is different from "no access" condition, see Section 11.5.1 The Value file implements a backup mechanism. All operations executed on a value file within the current transaction will be effective only when a successful CommitTransaction will be executed. Meanwhile or if the transaction is aborted or not successfully committed, the previous value remains effective and is returned by a GetValue.

8.2.3.3 Record file

The record file is a CyclicRecord file which allows storing latest 4 records of 16-byte (each record) size. The record file adds up new records when a successful WriteRecord command is executed. When the maximum number of records of the file is reached, the next new record overwrites the oldest record as defined Section 11.8.8. The record file implements a backup mechanism. All operations executed on a record file within the current transaction are effective only when a successful CommitTransaction command is executed. If the transaction is aborted or not successfully committed the previous file image is effective and returned by a ReadRecords command. Within a record file, records are numbered starting with the latest record written. Meaning that the latest record written has the number 0, the second latest record written has the number 1 and so on. Its valid range is from 0 to the number of existing records ExistingRecCount- 1 in the record file. This indexing is used in the data management commands to address records within the Record file. Note that when reading out records, the records are returned in the chronological order that they have been written, i.e. the oldest record is returned first.

8.2.3.4 TransactionMAC file

A TransactionMAC file is used to store Transaction MAC-related information. It consists of the following items:

• Transaction MAC Counter (TMC) 4 byte unsigned integer. The TMC is initialized to 00000000h on file creation. This value means that no Transaction MAC has

• Transaction MAC Value (TMV) 8 bytes. The TMV is initialized to all zero bytes on file creation. A TransactionMAC file is created with the CreateTransactionMACFile command, see Section 11.7.6. A TransactionMAC file can be read with a ReadData command, protected by the Read access right, see below. The behavior is identical as reading a StandardData file of 12 bytes. A TransactionMAC file cannot be written directly. The TMC and TMV are related with the latest successful transaction and are updated automatically on successful CommitTransaction command. In addition, the last calculated TransactionMAC values can be read out from the TransactionMAC file, in case the response to the CommitTransaction command has not been received correctly by the PCD. Therefore, the implementation of this file type supports the integrated backup mechanism for anti- tearing protected atomic update of these values together with the rest of the transaction updates. In addition, the following content is stored in the TransactionMAC file:
• optionally the TransactionMAC ReaderID (TMRIPrev), see Section 11.9.3, as a committed value becomes valid together with the updated TMC and TMV on CommitTransaction.
• the AppTransactionMACKey, as it is specified when creating the TransactionMAC file. However, these values are never immediately accessible on the command interface via the file (e.g. using ReadData).

8.2.3.5 File access rights management

File data is accessed with 3 different access rights Read, Write and ReadWrite. ChangeFileSettings to change the file access rights.

• The access condition where a valid authentication with a given AppKey of the targeted application is needed to access related commands listed in Table 9. The access condition is satisfied if the current valid authentication has been performed with the given AppKey and not satisfied in all other cases. The AppKey is specified with its number.
• The free access condition meaning the related commands listed in Table 9 can be accessed without an active authentication.
• The no access condition meaning no access to related commands listed in Table 9. The access conditions are specified on 4 bits as defined in the following table.

Table 6. Access condition

access conditions are expected to be set to Fh (for future extensibility). Table 7. Set of Access condition The default access conditions for the files in MF2DL(H)x0 is shown below in . Table 8. Default file access rights The mapping of access rights to applicable commands is shown in Table 9. Table 9. Command list associated with access rights

8.2.3.6 TransactionMAC file access rights

Note that Write is RFU and should to be set to Fh. Table 10. TransactionMAC access rights

8.2.3.7 Communication modes

representation is used at several places in the document. Table 11. Supported communication modes this authentication is required by the command or not. command is rejected in the case an authentication is required). The default communication mode per file is shown in below. Table 12. Default communication modes per file

8.2.4 Keys

respectively. They are used to manage the security of the application.

Table 13. Keys at application level

8.2.4.1 AppMasterKey

itself with the ChangeKey command.

8.2.4.2 AppKey

can be assigned for access rights management. authentication with key number 0 in transport configuration. keys are used in the application.

8.2.4.3 AppCommitReaderIDKey

Section 8.2.3.6 and is assigned at creation time of the TransactionMAC file.

8.2.4.4 AppTransactionMACKey

Transaction MAC feature is described in Section 10.3. re-creation which requires an active authentication with the AppMasterKey. The AppTransactionMACKey is not available for authentication.

8.2.4.5 OriginalityKey

• AuthenticateLRPFirst, see Section 9.2.5
• AuthenticateLRPNonFirst, see Section 9.2.6

Table 14. Keys at PICC level

8.2.4.6 Key version

retrieved using the GetVersion command.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 18 / 132

8.3 Native Command Format

MF2DL(H)x0 always communicates in ISO/IEC 7816-4 wrapped mode as described in Section 8.4. Nevertheless it is important to understand the basic format of native commands as it is used in MIFARE DESFire EV2 which consist of the following parts. A command as sent by the PCD consists of the concatenation of:

• the command code (Cmd)
• zero, one or more header fields (CmdHeader)
• zero, one or more data fields (CmdData) The response as sent by the PICC consists of the concatenation of:
• the return code (RC)
• zero, one or more data fields (RespData) MF2DL(H)x0 supports the APDU message structure according to ISO/IEC 7816-4 [4] for:
• wrapping of the native command format into a proprietary ISO/IEC 7816-4 APDU
• a subset of the standard ISO/IEC 7816-4 commands (ISOSelectFile, ISOReadBinary, ISOUpdateBinary) Remark: Communication via native ISO/IEC7816-4 commands without wrapping is not supported. On the native command interface, plain command parameters consisting of multiple bytes are represented least significant byte (LSB) first, similar as for ISO/IEC 14443 parameters during the activation, see [2]. For cryptographical parameters and keys (including the random numbers exchanged during authentication, the TI and the computed MACs), this does not hold. For these, the representation on the interface maps one-to-one to the most significant byte (MSB) first notation used in this specification. Note that within this document, the ’Xh’ prefix indicates hexadecimal integer notation, i.e. not reflecting the byte order representation on the command interface at all.

8.4 ISO/IEC7816-4 Communication frame

MF2DL(H)x0 uses ISO/IEC 7816-4 [4] type APDUs for command-response pair for both, wrapping of native commands as outlined in Section 8.3 and standard ISO/IEC 7816-4 commands. Note that for all parameters of standard ISO/IEC 7816-4 commands, the representation on the interface is most significant byte (MSB) first notation. As data like the 2-byte ISO/ IEC 7816-4 file identifiers, are in different order for the wrapped native commands, this needs to be taken into account.

Figure 5. ISO/IEC 7816-4 command response pair Table 15. ISO/IEC 7816-4 command fields data is sent back for ISO/IEC 7816-4 standard commands. For wrapped commands, Le must always be set to 00h. see [4]. This includes overhead for secure messaging. exceed 256 bytes since only short length (1 byte) is supported in MF2DL(H)x0, see [4]. This includes overhead for secure messaging. Table 16. ISO/IEC 7816-4 response fields command description in Section 11.

8.5 Command Chaining

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 20 / 132

• the PICC supports ISO/IEC 14443-4 chaining to allow larger command or response frames than the supported buffer size for variants of the following commands: – Native commands wrapped into ISO/IEC 7816-4 APDU: ReadData, WriteData, ReadRecords, WriteRecord, and UpdateRecord, see Section 11. – Standard ISO/IEC 7816-4 commands: ISOReadBinary, ISOUpdateBinary i.e. every command where larger frame size can occur.
• the PICC will automatically split a response in several frames to fit with the FSD frame size supported by the PCD and communicated in the RATS. When a PCD applies ISO/IEC 14443-4 chaining, see [3], it needs to assure the reassembled INF field containing the command header (i.e. ISO/IEC 7816-4 header bytes and/or (Cmd || CmdHeader)) fits within the PICC’s buffer (FSC) communicated in the ATS. If not, the PICC may respond with LENGTH_ERROR. The ISO/IEC 14443-4 chaining does not influence the secure messaging. This means that the secure messaging mechanisms are applied as if the command or response would have been sent in a single large frame. With regards to command execution, commands are handled as if they were received in one large frame, except for write commands where the total frame size can be larger than the supported FSC (WriteData, WriteRecord, UpdateRecord and ISOUpdateBinary). In this case, command execution is started before the complete command is received. Note that this is important for StandardData files, where the file may end up in an undefined state if the command is not completed successfully, see Section 8.6.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 21 / 132

8.6 Backup management

MF2DL(H)x0 supports the implementation of transactions with tearing protection by its backup file management. The following file types are backup file types:

• Value
• CyclicRecord
• TMC and TMV inside the TransactionMAC file All updates to these file types will be done only if CommitTransaction is executed successfully. If the transaction is teared, or an error occurs, before issuing CommitTransaction, none of the changes issued during the transaction so far will be applied. If the card is teared during the CommitTransaction execution itself, the implementation will still ensure that either all, or none of the changes are applied. Note that it is possible that the reader will not receive the response to CommitTransaction despite a successful execution, i.e. when tearing on the response transmission. The chance for this to occur is limited by a short execution time of the CommitTransaction command. However, still some system level measures should be considered for this event. Note that files of StandardData do not offer this backup mechanism. However, still a limited tearing protection is offered by ensuring that on single frame write operations the updated data is either completely written or not changed at all.

8.7 Product originality

MF2DL(H)x0 supports two types of originality check: one based on an LRP authentication with AES originality keys and another one with a static signature verification with an ECC public key. For detail of the ECC originality check, refer to originality check commands. The AES-based originality verification using AuthenticateLRPFirst or AuthenticateLRPNonFirst is done with one of the OriginalityKey described in Section 8.2.4.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 22 / 132

9 Secure Messaging

Prior to data transmission a mutual three-pass authentication can be done between PICC and PCD which results in the generation of session keys used in the secure messaging. There are two secure messaging types available in the MF2DL(H)x0. One is using AES-128 and is referred to as AES mode in this data sheet. The other one is using AES-128 with a Leakage Resilient Primitive (LRP) wrapper, also referred to as LRP mode. The LRP mode can be permanently enabled using the SetConfiguration command. After this switch, it is not possible to revert back to AES mode. Compared to AES mode, the LRP mode has the advantage that it provides strong resistance against side-channel and fault attacks. It serves as a replacement for AES as it only uses standard cryptographic constructions based on AES without any proprietary cryptography. Thus, LRP can be seen as an alternative for AES which is itself based on AES, and is provably as secure as AES, but comes with better properties w.r.t. implementation security, see also [10]. The PCD requires the same LRP mode implementation. To improve the resistance against side-channel attacks and especially card only attacks for the AES mode, MF2DL(H)x0 provides a limit for unsuccessful authentication attempts. Every unsuccessful authentication is counted in the TotFailCtr. The parameters TotFailCtrLimit TotFailCtrDecr can be configured as described in Section 11.5.1 using the "Failed authentication counter configuration". Each unsuccessful authentication is counted internally in the total failed authentication counter TotFailCtr. After reaching the TotFailCtrLimit, see Section 11.5.1, the related key cannot be used for authentication anymore. In addition, after reaching a limit of consecutive unsuccessful authentication attempts, the MF2DL(H)x0 starts to slow down the authentication processing in order to hamper attacks. This is done by rejecting any authentication command with a AUTHENTICATION_DELAY response. The response time of a single AUTHENTICATION_DELAY response is depending on the FWT, see Section 8.1.1, and is about 65% of the maximum response time specified by FWT. The error response is sent until the total authentication delay time is reached which is equal to the sum of the frame delay times. The total authentication delay time increases with each unsuccessful authentication attempt up to a maximum value, only a successful authentication restores the full operational speed. Changing a blocked AES key by authenticating with the AppMasterKey and using the ChangeKey command makes the referenced key accessible again. If the AppMasterKey itself is blocked, no recovery is possible. Each successful AES authentication decrements the TotFailCtr by a value of TotFailCtrDecr. The AES and LRP authentications are initiated by commands sharing the same command code (First Authentication and Non-First Authentication variants). These authentication protocols are both AES-based, but differ with regards to the actual protocol applied and the subsequent secure messaging mode they initiate. An overview of the different modes is given in Figure 6.

Figure 6. MIFARE DESFire Light secure messaging setup state after a successful First or Non-First Authentication. counter, see Section 9.1.2, even if multiple authentications are required. use Non-First Authentication. Table 17. When to use which authentication command the Leakage Resilient Primitive (LRP), see Section 9.2.

defined with SetConfiguration, see Section 11.5.1. authentication request is rejected. If the PCD chooses for LRP secure messaging, it sends PCDCap2.1 equaling 02h. standard AES authentication as well. only AuthenticateLRPNonFirst is supported. Below table provides possible negotiation outcomes on FirstAuthentication. Table 18. Secure messaging mode negotiation

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 25 / 132

9.1 AES Secure Messaging

The AES Secure Messaging is managed by AuthenticateEV2First and AuthenticateEV2NonFirst. Note that AuthenticateEV2First and AuthenticateEV2NonFirst can also be used to start LRP Secure Messaging, as defined in Section 9.2. This is done with the PCDCap2 sent in First Authentication and the return code, see Section 9 and Section 9.2.5 for details.

9.1.1 Transaction Identifier

In order to avoid interleaving of transactions from multiple PCDs toward one PICC, the Transaction Identifier (TI) is included in each MAC that is calculated over commands or responses. The TI is generated by the PICC and communicated to the PCD with a successful execution of an AuthenticateEV2First command, see Section 11.4.1. The size is 4 bytes and these 4 bytes can hold any value. The TI is treated as a byte array, so there is no notion of MSB and LSB.

9.1.2 Command Counter

A command counter is included in the MAC calculation for commands and responses in order to prevent e.g. replay attacks. It is also used to construct the Initialization Vector (IV) for encryption and decryption. Each command, besides few exceptions, see below, is counted by the command counter CmdCtr which is a 16-bit unsigned integer. Both sides count commands, so the actual value of the CmdCtr is never transmitted. The CmdCtr is reset to 0000h at PCD and PICC after a successful AuthenticateEV2First authentication and it is maintained as long as the PICC remains authenticated. In cryptographic calculations, the CmdCtr is represented LSB first. Subsequent authentications using AuthenticateEV2NonFirst do not affect the CmdCtr. Subsequent authentications using the AuthenticateEV2First will reset the CmdCtr to 0000h. The CmdCtr is increased between the command and response, for all communication modes. When a MAC on a command is calculated at PCD side that includes the CmdCtr, it uses the current CmdCtr. The CmdCtr is afterwards incremented by 1. At PICC side, a MAC appended at received commands is checked using the current value of CmdCtr. If the MAC matches, CmdCtr is incremented by 1 after successful reception of the command, and before sending a response. For CommMode.Full, the same holds for both the MAC and encryption IV calculation, i.e. the non-increased value is used for the command calculations while the increased value is used for the response calculations. If the CmdCtr holds the value FFFFh and a command maintaining the active authentication arrives at the PICC, this leads to an error response and the command is handled like the MAC was wrong. Command chaining, see Section 8.5, does not affect the counter. The chained command is considered as a single command, just as for the other aspects of secure messaging, and thus the related counter is increased only once.

9.1.3 MAC Calculation

MACs are calculated using the underlying block cipher according to the CMAC standard described in [6]. Padding is applied according to the standard.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 26 / 132 The MAC used in MF2DL(H)x0 is truncated by using only the 8 even-numbered bytes out of the 16 bytes output as described [6] when represented in most-to-least-significant order. Initialization Vector for MACing The initialization vector used for the CMAC computation is the zero byte IV as prescribed [6].

9.1.4 Encryption

Encryption and decryption are calculated using AES-128 according to the CBC mode of NIST SP800-38A [5]. Padding is applied according to Padding Method 2 of ISO/IEC 9797-1 [7], i.e. by adding always 80h followed, if required, by zero bytes until a string with a length of a multiple of 16 byte is obtained. Note that if the plain data is a multiple of 16 bytes already, an additional padding block is added. The only exception is during the authentication itself (AuthenticateEV2First and AuthenticateEV2NonFirst), where no padding is applied at all. The notation E(key, message) is used to denote the encryption and D(key, message) for decryption. Initialization Vector for Encryption When encryption is applied to the data sent between the PCD and the PICC, the Initialization Vector (IV) is constructed by encrypting with SesAuthENCKey according to the ECB mode of NIST SP800-38A [5] the concatenation of:

• a 2-byte label, distinguishing the purpose of the IV: A55Ah for commands and 5AA5h for responses
• Transaction Identifier TI
• Command Counter CmdCtr (LSB first)
• Padding of zeros acc. to NIST SP800-38B [6] This results in the following IVs: IV for CmdData = E(SesAuthENCKey; A5h || 5Ah || TI || CmdCtr || 0000000000000000h) IV for RespData = E(SesAuthENCKey;5Ah || A5h || TI || CmdCtr || 0000000000000000h) When an encryption or decryption is calculated, the CmdCtr to be used in the IV are the current values. Note that this means that if CmdCtr = n before the reception of a command, after the validation of the command CmdCtr = n + 1 and that value will be used in the IV for the encryption of the response. For the encryption during authentication (both AuthenticateEV2First and AuthenticateEV2NonFirst), the IV will be 128 bits of 0.

9.1.5 AuthenticateEV2First Command

This section defines the Authentication, which is mandatory to be used first in a transaction when using Secure Messaging, see Table 17. In this procedure both, the PICC as well as the PCD show in an encrypted way that they possess the same secret, i.e. the same key. This authentication is supported with AES keys. The authentication consists of two parts: AuthenticateEV2First - Part1 and Section 9.1.6 - Part2. Detailed command definition can be found in Section 11.4.1. The protocol cannot

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 27 / 132 be interrupted by other commands. On any command different from AuthenticateEV2First - Part2 received after the successful execution of the first part, the PICC aborts the ongoing authentication. During this authentication phase, the PICC accepts messages from the PCD that are longer than the lengths derived from this specification as long as LenCap is correct. This feature is to support the upgradability to following generations of MF2DL(H)x0. The PCD rejects answers from the PICC when they don’t have the proper length. Note that if present, PCDcap2:1:Bit1 must not be set, otherwise LRP authentication is targeted, see Section 9.2.5. Upon reception of AuthenticateEV2First, the PICC validates the targeted key. If the key does not exist, AuthenticateEV2First is rejected. The PICC generates a random 16-byte challenge RndB and send this encrypted to the PCD, according to Section 9.1.4. Additionally, the PICC resets CmdCtr to zero and generate a random Transaction Identifier (TI). Upon reception of the AuthenticateEV2First response from the PICC, the PCD also generates a random 16-byte challenge RndA. The PCD encrypts, on his turn, the concatenation of RndA with RndB', which is the received challenge after decryption and rotating it left by one byte. Within AuthenticateEV2First - Part2, this is sent to the PICC. Upon reception of AuthenticateEV2First - Part2, the PICC decrypts the second message and validates the received RndB'. If not as expected, the command is rejected. Else it generates RndA' by rotating left the received RndA by one byte. This is returned together with the generated TI. Also, the PICC sends 12 bytes of capabilities to the PCD: 6 bytes of PICC capabilities PDcap2 and 6 bytes of PCD capabilities PCDcap2 that were received on the command (sent back for verification). The use of those capabilities, and the negotiation process is described in Section 9. Note that part of PDCap will be configurable with SetConfiguration. PCDcap2 is used to refer both to the value sent from the PCD to the PICC and to the value used in the encrypted response message from the PICC to the PCD where in this case the PCDcap2 is the adjusted version of the originally sent PCDcap2: i.e. truncated or padded with zero bytes to a length of 6 bytes if needed. On successful execution of the authentication protocol, the session keys SesAuthMACKey and SesAuthENCKey are generated according to Section 9.1.7. The PICC is in EV2 authenticated state and the Secure Messaging is activated. On any failure during the protocol or if one of the OriginalityKey were targeted, the PICC ends up in not authenticated state. If there is a mismatch between the capabilities expected by the PCD and the capabilities presented by the PICC to the PCD (both the PDcap2 and the echoed/adjusted PCDcap2), it is the responsibility of the PCD to take the proper actions based on the application the PCD is running. This decision is outside the scope of this specification.

9.1.6 AuthenticateEV2NonFirst Command

This section defines the Non-First Authentication, which is recommended to be used if Secure Messaging is already active, see Table 17. In this procedure both, the PICC as well as the PCD show in an encrypted way that they possess the same secret, i.e. the same key. This authentication is supported with AES keys. The authentication consists of two parts: AuthenticateEV2NonFirst - Part1 and AuthenticateEV2NonFirst - Part2. Detailed command definition can be found in Section 11.4.2. This command is rejected if there is no active authentication, except if the

• No PCDcap2 and PDcap2 are exchanged and validated.
• Transaction Identifier TI is not reset and not exchanged.
• Command Counter CmdCtr is not reset. After successful authentication, the PICC remains in EV2 authenticated state. On any failure during the protocol, the PICC ends up in not authenticated state.

9.1.7 Session Key Generation

• SesAuthMACKey for MACing of messages
• SesAuthENCKey for encryption and decryption of messages Note that these identifiers are also used in context of the LRP protocol, though the actual calculation of the session keys is different, see Section 9.2.7. aaa-032191 SesAuthENCKey = AES Session Key for encryption SesAuthMACKey = AES Session Key for MAC RndA MIFARE DESFire Light Authentication RndB KDF SesAuthENCKey = AES Session Key for encryption SesAuthMACKey = AES Session Key for MAC RndA AES Key KxAES Key Kx PICCPCD RndB KDF

Figure 7. Session key generation for Secure Messaging The session key generation is according to NIST SP 800-108 [8] in counter mode.

• a 2-byte label, distinguishing the purpose of the key: 5AA5h for MACing and A55Ah for encryption
• 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 First, the 32-byte input session vectors SVx are derived as follows: with ⊕ being the XOR-operator. Then, the 16-byte session keys are constructed as follows: SesAuthENCKey = PRF(Kx, SV1) SesAuthMACKey = PRF(Kx, SV2)

9.1.8 Plain Communication Mode

i.e. as defined in the command specification tables, see Section 11. Figure 8. Plain Communication Mode in CommMode.Plain on any subsequent command that is sent in CommMode.MAC (e.g. CommitTransaction) or CommMode.Full.

9.1.9 MAC Communication Mode

The Secure Messaging applies MAC to all commands listed as such in Section 11.2.

• Command, Cmd

• Command Counter CmdCtr
• Transaction Identifier TI
• Command header - CmdHeader (if present)
• Command data - CmdData (if present) For responses, the MAC is calculated over the following data in this order:
• Return code - RC
• Command Counter - CmdCtr (The already increased value)
• Transaction Identifier - TI
• Response data - RespData (if present) CmdCtr is the Command Counter as defined in Section 9.1.2. Note that the CmdCtr is increased between the computation of the MAC on the command and the MAC on the response. TI is the Transaction Identifier, as defined in Section 9.1.1. The other input parameters are as defined in Section 8.3. The calculation is illustrated in Figure 9. In case of command chaining, the MAC calculation is not interrupted. The MAC is calculated over the data including the complete data field (i.e. either CmdData or RespData of all frames) at once. The MAC is always transmitted by appending to the unpadded plain command. If necessary, an additional frame is sent. If a MAC over the command is received, the PICC verifies the MAC and rejects commands that do not contain a valid MAC by returning INTEGRITY_ERROR. In this case, the ongoing command and transaction are aborted (see also Section 11). The authentication state is immediately lost and the error return code is sent without a MAC appended. Note that any other error during the command execution has the same consequences. PICCto PCD aaa-032192 TI TC CmdCtr Cmd C= valueof CmdCtr at start of this sequence T = Value of TI (will stayconstant) [c] RespData [c] RespData TI TC+1 CmdCtr MACt(SesAuthMACKey, RC|| CmdCtr || TI [|| RespData]) MAC(SesAuthMACKey, RC|| CmdCtr || TI [|| RespData]) PCDtoPICC MAC(SesAuthMACKey, CMD|| CmdCtr || TI [|| CmdHeader] [|| CmdData]) Command counter (CmdCtr) incremented after validatingthe command before sendingthe response and relatedMACcalculation MACTruncationfrom16 to8 byte byuseof the even-numberedbytes CLA 90h Cmd P1 00h 00h 1 1 1 1 Le 00h 1[a] [b] ISO 7816 Data Field CmdData [a] [b] ISO 7816 Data Field CmdData status SW2 SW1 status SW2 CmdHeader CmdHeaderLc MACt(SesAuthMACKey, CMD|| CmdCtr|| TI [|| CmdHeader] [|| CmdData]) CLA, P1, P2, LC, Le and SW1 not included in secure messaging calculation. SW2 is the return code (RC) and appended in the beginning for secure messaging calculation

Figure 9. Secure Messaging: MAC Communication mode

9.1.10 Full Communication Mode

as such in Section 11.2. In case CommMode.Full is to be applied, the following holds. The encryption/decryption is calculated using the current session key SesAuthENCKey.

in both the command and the response frame. After the encryption, the command and response frames are handled as with MAC. In this case, the ongoing command and transaction are aborted (see also Section 11). Figure 10. Secure Messaging: CommMode.Full

9.2 LRP Secure Messaging

The LRP Secure Messaging is using AES-128 to construct a Leakage Resilient Primitive. This way, it allows side-channel resistant implementation. with the same command code as AuthenticateEV2First and AuthenticateEV2NonFirst. on when to use one or the other command also apply for LRP secure messaging.

9.2.1 Transaction identifier

messaging as defined for AES secure messaging, see Section 9.1.1.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 32 / 132

9.2.2 Command counter

The Command counter (CmdCtr) is treated exactly in the same way by LRP secure messaging as defined for AES secure messaging, see Section 9.1.2.

9.2.3 MAC calculation

MACs are computed by using a CMAC construction on top of the LRP primitive. This is specified in [10]. This document uses the following notation where the right hand refers to the notation of [10]. MACLRP(key,message) = CMAC_LRP(4,key, Len(message),message) Note that in the LRP context a key is not purely a single value, but rather consists of the associated set of plain texts, an updated key and in context of CMAC also the subkeys K1 and K2. Therefore K1 and K2 are not shown (contrary to [10]) as they can be calculated inside. MACtLRP(key, message) denotes the CMAC after truncation to 8 bytes which is identical to the truncation of the AES secure messaging i.e. the even-numbered bytes are retained in most-to-least-significant order, see Section 9.1.3. The initialization vector used for the CMAC computation is the zero byte IV as prescribed [10].

9.2.4 Encryption

Encryption and decryption are calculated using a Leakage Resilient Indexed CodeBook (LRICB) construction on top of the LRP primitive: LRICBof [10]. For this purpose an Encryption Counter is maintained: EncCtr is a 32-bit unsigned integer as Input Vector (IV) for encryption/decryption. The EncCtr is reset to 000000000h at PCD and PICC when starting an authentication with AuthenticateLRPFirst or AuthenticateLRPNonFirst targeting LRP. The counter is incremented during each encryption/decryption of each 16-byte block. i.e. for 64-byte encryption/decryption the EncCtr is increased by 5 due to 4 blocks of 16-byte of data plus one block of padding. Note that for AuthenticateLRPFirst the value 00000000h is already used for the response of part 2, so the actual secure messaging starts from 00000001h. For AuthenticateLRPNonFirst, secure messaging starts from 00000000h as the counter is not used during the authentication. EncCtr is further maintained as long as the PICC remains in LRP authenticated state. Note that for the key stream calculation [10], the counter is represented MSB first. Padding is applied according to Padding Method 2 of ISO/IEC 9797-1 [7], i.e. by adding always 80h followed, if required, by zero bytes until a string with a length of a multiple of 16 bytes is obtained. Note that if the plain data is a multiple of 16 bytes already, an additional padding block is added. The only exception is during the authentication itself (AuthenticateLRPFirst and AuthenticateLRPNonFirst), where no padding is applied at all. The notation ELRP(key, plaintext) is used to denote the encryption, i.e. LRICBEnc of [10] and DLRP(key, ciphertext) for the complementary decryption operation. Note that in the LRP context a key is not purely a single value, but rather consists of the associated set of plain texts and updated key. Also, as specified in [10], the EncCtr is updated as part of the operation. Note that the EncCtr cannot overflow. Due to the supported file sizes, the CmdCtr will always expire before.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 33 / 132 Note that the MSB representation of EncCtr is different from other counter representations in this specification, but allows saving some AES calculations in the key stream generation.

9.2.5 AuthenticateLRPFirst command

The AuthenticateLRPFirst command reuses the same command code as AuthenticateEV2First. The distinction is made via the PCDCap2.1 parameter, as explained in Section 9. The AuthenticateLRPFirst command is fully compliant with the mutual three-pass authentication of ISO/IEC 9798-4 [7]. The authentication consists of two parts: AuthenticateLRPFirst - Part1 and AuthenticateLRPFirst Part2. Detailed command definition can be found in Section 11.4.3. The protocol cannot be interrupted by other commands. On any command different from AuthenticateLRPFirst - Part2 received after the successful execution of the first part, the PICC aborts the ongoing authentication. During this authentication phase, the PICC accepts messages from the PCD that are longer than the lengths derived from this specification as long as LenCap is correct. This feature is to support the upgradability to following generations of MIFARE DESFire Light. Apart from bit 1 of PCDCap2.1, which need to be set to 1 for AuthenticateLRPFirst resulting into 020000000000h, the content of PCDCap2 is not interpreted by the PICC. The PCD rejects answers from the PICC when they don’t have the proper length. Upon reception of AuthenticateLRPFirst, the PICC validates the targeted key. If the key does not exist, AuthenticateLRPFirst is rejected. At PICC level, the only available key is the OriginalityKey. The PICC generates a random 16-byte challenge RndB and send this in plain to the PCD. Additionally, the PICC and PCD reset both CmdCtr and EncCtr to zero and generate a random TI. Upon reception of the AuthenticateLRPFirst response from the PICC, the PCD also generates a random 16-byte challenge RndA. Now the PCD calculates the session keys SesAuthMACKey and SesAuthENCKey, as specified in Section 9.2.7. As explained there for LRP, a session key consists of a set of plain texts and an updated key. Then the PCDResponse computes a MAC over the concatenation of RndA with RndB, applying the SesAuthMACKey with the algorithm defined in Section 9.2.3. Note that MACs are not truncated during the authentication. Within AuthenticateLRPFirst - Part2, the concatenation of RndA and this MAC is sent to the PICC. Upon reception of AuthenticateLRPFirst - Part2, the PICC validates the received MAC. If not as expected, the command is rejected. Else it encrypts the generated TI concatenated with 12 bytes of capabilities to the PCD: 6 bytes of PICC capabilities PDCap2 and 6 bytes of PCD capabilities PCDCap2 that were received on the command (sent back for verification). Encryption is done according to Section 9.2.4, applying SesAuthENCKey. Note that part of PDCap is configurable with SetConfiguration. PCDCap2 is used to refer both to the value sent from the PCD to the PICC and to the value used in the encrypted response message from the PICC to the PCD where in this case the PCDCap2 is the adjusted version of the originally sent PCDCap2: i.e. truncated or padded with zero bytes to a length of 6 bytes if needed. After that encryption, the PICCResponse will also compute a MAC over the concatenation of RndB, RndA and the encrypted data.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 34 / 132

9.2.6 AuthenticateLRPNonFirst command

This section defines the LRP Non-First Authentication, which is recommended to be used if LRP Secure Messaging is already active, see Table 17. The authentication consists of two parts: AuthenticateLRPNonFirst - Part1 and AuthenticateLRPNonFirst Part2. Detailed command definition can be found in Section 11.4.4. This command is rejected if there is no active LRP authentication, except if the targeted key is the OriginalityKey. For the rest, the behavior is exactly the same as for AuthenticateLRPFirst, except for the following differences:

• PCDCap2 and PDCap2 are not exchanged and validated
• TI is not reset and not exchanged
• CmdCtr is not reset Note that EncCtr is reset to zero also on AuthenticateLRPNonFirst. After successful authentication, the PICC remains in LRP authenticated state, except if the OriginalityKey was targeted. In that case, the PICC is in not authenticated state. On any failure during the protocol, the PICC ends up in not authenticated state.

9.2.7 Session key generation

Next to the algorithms for MAC calculation and encryption, one of the major differences between the LRP secure messaging and the AES secure messaging is that the session keys are generated and already applied during the authentication with AuthenticateLRPFirst or AuthenticateLRPNonFirst. Also for the LRP protocol, two keys are generated:

• SesAuthMACKey for MACing of messages
• SesAuthENCKey for encryption and decryption of messages During the authentication, the SesAuthMACKey is used for both AuthenticateLRPFirst and AuthenticateLRPNonFirst. SesAuthENCKey is only used for AuthenticateLRPFirst. Being LRP keys, this section shows how both the plain texts and the updated key [10] related to these session keys are computed. In the remainder of the document, when the session key is applied in the LRP context the combination of those plain texts and updated key is meant. The session key generation is according to NIST SP 800-108 [8] in counter mode. The Pseudo Random Function PRF(key; message) applied during the key generation is the CMAC algorithm on top of the LRP primitive. This is specified in [10], see also Section 9.2.3. The key derivation key is the key Kx that was applied during authentication. Note that from this key a set of plaintexts and updated key is computed, so the static key is only used in this derivation. The generated session keys are AES keys. The input data is constructed using the following fields as defined by [8]. Note that NIST SP 800-108 allows defining a different order than proposed by the standard as long as it is unambiguously defined.
• 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
• a 2-byte label: 9669h Firstly, the 32-byte input session vector SV is derived as follows: (RndA[13::8] ⊕ RndB[15::10]) || RndB[9::0] || RndA[7::0] || 96h || 69h with ⊕ being the XOR-operator. Then, the session key material is constructed as follows: AuthSPT = generatePlaintexts(4; Kx) {AuthUpdateKey} = generateUpdatedKeys(1; Kx) SesAuthMasterKey = MACLRP (Kx; SV ) SesAuthSPT = generatePlaintexts(4; SesAuthMasterKey) {SesAuthMACUpdateKey; SesAuthENCUpdateKey} = generateUpdatedKeys(2; SesAuthMasterKey) with generatePlaintexts and generateUpdatedKeys the functions from [10]. Note that the output of generateUpdatedKeys is shown in the order that the keys are generated. The actual SesAuthMACKey then consists for LRP of the set of plaintexts SesAuthSPT (consisting of 16 16-byte values) and SesAuthMACUpdateKey. The SesAuthENCKey consists of the same set of plaintexts SesAuthSPT and SesAuthENCUpdateKey.

9.2.8 Plain communication mode

AES secure messaging in EV2 authenticated state, see Section 9.1.8.

9.2.9 MAC communication mode

EV2 authenticated state, see Section 9.1.9. The calculation is illustrated in Figure 11. Figure 11. LRP Secure Messaging: MAC Protection Mode

9.2.10 Full communication mode

is as well illustrated in Figure 12.

8 Commandcounter(CmdCtr)

Figure 12. LRP Secure Messaging: CommMode.Full

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 37 / 132

10 Transaction Management

MIFARE DESFire Light supports the grouping of data management operations into transactions. This allows for committing or aborting all previous write access to files with integrated backup mechanisms within the selected application via a single atomic operation. How a transaction can be initiated and concluded, is detailed in Section 10.1 and Section 10.2. On top of this, MF2DL(H)x0 supports a Transaction MAC feature which allows proofing transaction execution toward a third party. This feature can be used if, for example, a merchant needs to be reimbursed by a backend for the transaction he executed. This way the backend is protected against the fraudulent merchant scenario. The Transaction MAC feature is specified in Section 10.3.

10.1 Transaction Initiation

MF2DL(H)x0 does not provide a separate command for initiating a transaction. Instead, a transaction is started by selecting the application with a ISOSelectFile command. Next to this, a new transaction is also automatically initiated after conclusion of a previous transaction, see Section 10.2. Note that a transaction is not affected by the execution of an authentication. One can have several authentications during the course of a single transaction.

10.2 Transaction Conclusion

A transaction can be concluded by successfully committing all write operations on backup files, as detailed in Section 10.2.1, or by abortion which will cancel all changes, as detailed in Section 10.2.2. For both operations, MF2DL(H)x0 supports a specific command, but transaction abortion can also be triggered by other commands. Note that some of the parameters and actions triggered by these commands are related with the Transaction MAC feature, explained in Section 10.3. For a full understanding, the description in that section should be referred to.

10.2.1 CommitTransaction

Validating all previous write access to back up files within the currently selected application is possible with the command CommitTransaction as defined in Section 11.9.1. The CommitTransaction takes an optional parameter option, which indicates if the Transaction MAC Counter (TMC) and Transaction MAC Value (TMV) of the calculated Transaction MAC, see Section 10.3, are to be sent with the response. If this is requested while the selected application does not support Transaction MAC calculation, i.e. no TransactionMAC file is present, the command is rejected. The CommitTransaction validates all preceding write access of the ongoing transaction to files with integrated backup mechanisms:

• Value file
• CyclicRecord file If the Transaction MAC feature is enabled, the TransactionMAC file is updated if the Transaction MAC Input (TMI) is different from the empty string. The updated file holds the

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 38 / 132 calculated TMV, as defined in Section 10.3.2.4 and the increased TMC which was used for the calculation of SesTMACKey. In case the application is configured for LRP, this means the used actTMC and sesTMC, see Section 10.3.2.1, are written into the file. On successful CommitTransaction, the sesTMC is also reset to zero and written to the non-user-accessible NVM for future session key generation. If TMC reached the TMCLimit, see Section 10.3.2.2, the application remains selected, but with limited functionality: no data management commands, see Section 11.8 can be executed anymore, except ReadData targeting the TransactionMAC file. Also CommitReaderID will be rejected. All these file updates are processed as a single atomic operation. In case of tearing, either all or none of the changes are applied to the memory. After execution of this command a new transaction is started. The command is rejected if no application has been selected. An error code is also returned if no write access has been done to any of the backup file types and, in case the application is protected by the Transaction MAC feature (see Section 10.3), no Transaction MAC calculation update has been done. This means no command that is included in the Transaction MAC calculation has been executed, i.e. the TMI is still the empty string. So note that if Transaction MAC is enabled, successful execution of CommitTransaction updating the TransactionMAC is possible without any write operation, as read operations are also included in the Transaction MAC calculation. If CommitReaderID is required according to access right configuration of the TransactionMAC, this command will be rejected if no ReaderID has been committed during the ongoing transaction, i.e. if TMRICur is still the empty string. If a ReaderID was committed in an authenticated state (EV2 authenticated state or LRP authenticated state), this value TMRICur is stored in non-volatile memory as TMRIPrev as part of the atomic operation. If the ReaderID was committed when not authenticated, TMRIPrev is not updated. The CommitTransaction requires MAC if there is an active authentication. Information on authentication and secure messaging-dependent structure of the command can be found in Section 9. The CommitTransaction is typically the last command of a transaction before deselecting the card with the ISO/IEC 14443-4 deselect command [3]. Note that TMC and TMV can also be read out encrypted, if preferred. In this case, the TransactionMAC file should be configured for CommMode.Full. One can then use ReadData to retrieve this information, instead of requesting it within the response of CommitTransaction.

10.2.2 AbortTransaction

A transaction can be aborted by explicitly issuing a AbortTransaction command. Next to this any ongoing transaction is also automatically aborted after:

• unsuccessful execution of a command
• selecting an application with the ISOSelectFile command, even if the same application is reselected.
• creating/deleting the TransactionMAC file with CreateTransactionMACFile or DeleteTransactionMACFile
• enabling LRP with SetConfiguration
• renaming files with SetConfiguration

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 39 / 132

• configuring Value file with SetConfiguration
• enabling TMCLimit with ChangeFileSettings
• enabling exclusion of unauthenticated operations from Transaction MAC calculation with ChangeFileSettings This has the same effects as successful execution of AbortTransaction detailed below. A new transaction is started. Invalidating all previous write access to back up files within the currently selected application is possible with the AbortTransaction command as defined in Section 11.9.2. This command takes no parameter. The AbortTransaction invalidates all preceding write access of the ongoing transaction to files with integrated backup mechanisms:
• Value file
• CyclicRecord file If a Transaction MAC is calculated, see Section 10.3, the ongoing calculation is also aborted and a new calculation is initiated. The AbortTransaction does not affect the authentication status. After execution of this command a new transaction is started. The command is rejected if no application has been selected, i.e. the PICC or MF level is currently selected. An error code is also returned if no write access has been done to any of the backup file types and, in case the application is protected by the Transaction MAC feature, no Transaction MAC calculation update has been done. This means no command that is included in the Transaction MAC calculation has been executed, i.e. the TMI is still the empty string. This is similar as for CommitTransaction. The AbortTransaction requires CommMode.MAC if there is an active authentication. It can be useful to cancel a transaction with the AbortTransaction command because there is no need for re-authentication to the PICC or no need for a reset of the RF field and a complete new ISO/IEC 14443 activation, which would have the same effect.

10.3 Transaction MAC

The Transaction MAC feature helps preventing e.g. fraudulent merchant attacks. It allows a merchant operating a point-of-sale terminal to prove that the transactions he executed with customers are genuine toward the card issuer’s or application provider’s backend. This is done by letting the card generate a Transaction MAC over the transaction with a key shared only by the card and the card issuer’s (or application provider’s) backend. This key is called the AppTransactionMACKey. As this key will not be present in the merchant’s terminal, it is not possible for the merchant to forge MACs toward the backend. Note that this implies that (pre-)personalization of the card is done by the card issuer and not at the merchant’s location. MAC generation will also involve a Transaction MAC Counter maintained by the card, which allows the backend to detect replay by the merchant. In addition this counter allows the backend to detect missing transactions, which allows detecting fraud where the merchant has increased the balance without reporting the transaction. Note that a counter also allows for easier detection mechanisms of replay than keeping logs with fingerprints of every transaction. Fraud detection alone might not be sufficient if one cannot point to the fraudulent merchant. Therefore, an additional configuration option requires that the merchant’s terminal commits its identity during the transaction. This requires support of a SAM

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 40 / 132 (Secure Access Module) which allows a secure commit of an ID that is then linked with the merchant. The goal of this is that the merchant cannot forge the committed ID. This ID is called ReaderID. For this feature, a key is assigned which is known by both the card and the SAM: AppCommitReaderIDKey. At the merchant’s site, this key should not leave the SAM. The card supports linking ReaderIDs of merchants by storing the committed ReaderID and returning the ReaderID of the previous transaction. This way the backend can detect which merchant did not report missing transactions.

10.3.1 General Overview

The Transaction MAC can be activated by creating a TransactionMAC file. When creating this file, one also specifies the AppTransactionMACKey, see Section 11.7.6. Additionally, one can optionally also require the commitment of a ReaderID, by assigning a AppCommitReaderIDKey for this, see Section 8.2.3.6. Once the Transaction MAC feature is activated, the Transaction MAC computation consists of the following steps: 1. Initialization: before performing the first command that needs a Transaction MAC computation update, the Transaction MAC Session Keys (SesTMMACKey and SesTMENCKey) are derived from the AppTransactionMACKey using the next Transaction MAC Counter value, see also Section 10.3.2.1. 2. Computation updates: during the transaction, the Transaction MAC is computed using SesTMMACKey over the following commands:

• ReadData, GetValue and ReadRecords
• WriteData, Credit, Debit, LimitedCredit, WriteRecord, UpdateRecord and ClearRecordFile
• CommitReaderID: the committed ReaderID is stored on the card and the ReaderID of the previous transaction is returned encrypted with the SesTMENCKey. This is also included in the ongoing Transaction MAC computation. Note that for simplicity operations all file types are included. Note that StandardData can be written without transaction finalization with CommitTransaction. Therefore, the protection of StandardData files by the TransactionMAC is limited. MF2DL(H)x0 does support an option that excludes unauthenticated data management operations from the Transaction MAC calculation. This can be enabled with ChangeFileSettings. 3. Finalization: on CommitTransaction, the Transaction MAC is finalized. The update of the manipulated backup files and the computed Transaction MAC, the related counter and (optionally) the committed ReaderID, are one atomic operation. The computed Transaction MAC and the related counter are either provided with the response of CommitTransaction or can be read afterwards using ReadData on the TransactionMAC file.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 41 / 132

10.3.2 Cryptographic and Other Concepts

10.3.2.1 Transaction MAC Counter

Each Transaction MAC calculation is associated with a Transaction MAC Counter (TMC) which is a 4 byte unsigned integer. On the interface or in cryptographic calculations, the TMC is represented LSB first. The TMC is stored in the TransactionMAC file. How the TMC is exactly processed depends on whether the application is using standard AES or LRP, as configured with PDCap2.1 via SetConfiguration, see Section 11.5.1. Standard AES The TMC is processed as a 4-byte integer. The TMC added by 1 serves as input for the Transaction MAC Session Key generation, see Section 10.3.2.3. LRP The TMC is composed by two 2-byte unsigned integer subparts: actTMC: the actual Transaction MAC Counter subpart serves the actual role of TMC toward the backend. This means the PICC will only output a single TMV for an actTMC value, and therefore the backend can use this part for replay or missing transaction detection. At any point in time the current actTMC can be read from the TransactionMAC file and actTMC added by 1 serves as input for the Transaction MAC Session Key generation sesTMC: the session Transaction MAC Counter subpart ensures that each session key generation results in different keys. sesTMC added by 1 serves as input for the Transaction MAC Session Key generation. On successful CommitTransaction, the current sesTMC is written to the TransactionMAC file as part of the stored TMC. On CommitTransaction, this non-user-accessible sesTMC is reset to zero. If sesTMC reached its maximum value (FFFFh), no Transaction MAC Session Key generation can be executed, as the counter would overflow. As a consequence, no data management commands, see Section 11.8 can be executed, except ReadData targeting the TransactionMAC file. Also CommitReaderID will be rejected. This means the application can still be selected, but with limited functionality. ISOSelectFile will be responded with error code 6283h, indicating that the selected file or application is deactivated. The counter can only be reset by recreating the TransactionMAC file. For composing TMC the two subparts are concatenated as follows: actTMC || sesTMC. Both subparts are represented LSB first. If configuring from Standard AES to LRP, see Section 11.5.1, the actTMC is set to the minimum of FFFFh and the current value of TMC. sesTMC is set to 0000h.

10.3.2.2 Transaction MAC Counter Limit

The number of transactions that can be executed within an application can be limited by setting a Transaction MAC Counter Limit (TMCLimit). This is an unsigned integer of 4 bytes (if configured for Standard AES, related with TMC) or 2 byte (if LRP, related with actTMC). On the interface or in cryptographic calculations, the TMC is represented LSB first. At delivery, the TMCLimit is disabled. This is equivalent to holding the maximum value (FFFFFFFFh, as configured for Standard AES at that time). The TMCLimit can be

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 42 / 132 enabled by setting a customized value with ChangeFileSettings. It can be retrieved with GetFileSettings. Once the TMC (actTMC in case of LRP) equals the TMCLimit, no data management commands, see Section 11.8 can be executed, except ReadData targeting the TransactionMAC file. Also CommitReaderID will be rejected. This means the application can still be selected, but with limited functionality. ISOSelectFile will be responded with error response 6283h indicating that the selected file or application has been deactivated and provides limited functionality. If configuring from standard AES to LRP, see Section 11.5.1, the TMCLimit is set to the minimum of FFFFh and its current value. This means it is possible that suddenly the maximum value is reached, i.e. if TMC at that point in time hold a value of FFFFh or larger. If the TMCLimit gets disabled with ChangeFileSettings, this is also equivalent to putting it to the maximum value: FFFFFFFFh if standard AES, or FFFFh if LRP. Also when the TransactionMAC file gets re-created with CreateTransactionMACFile, the feature is disabled and TMCLimit is set to the maximum value.

10.3.2.3 Transaction MAC Session Keys

Out of the AppTransactionMACKey, two session keys are generated:

• SesTMMACKey for computing the Transaction MAC Value
• SesTMENCKey for encrypting the committed ReaderID (if used) The Transaction MAC Session Keys are derived using the following algorithms. AES mode The session key generation is according to NIST SP 800-108 [10] in counter mode. The Pseudo Random Function PRF(key; message) applied during the key generation is the CMAC algorithm described in NIST Special Publication 800-38B [6]. The key derivation key is the AppTransactionMACKey, see Section 8.2.4. The input data is constructed using the following fields as defined by [10]. Note that NIST SP 800-108 allows defining a different order than proposed by the standard as long as it is unambiguously defined.
• a 1-byte label, distinguishing the purpose of the key: 31h for MACing and 32h for encryption
• 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 11-byte context, constructed using the 4-byte TMC+1 and the UID Two session vectors SVx are derived as follows: Then, the 16-byte session keys SesTMMACKey and SesTMENCKey are constructed as follows: SesTMMACKey = PRF(AppTransactionMACKey, SV1) SesTMENCKey = PRF(AppTransactionMACKey, SV2) LRP mode The session key generation is according to NIST SP 800-108 [10] in counter mode.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 43 / 132 The Pseudo Random Function PRF(key; message) applied during the key generation is the CMAC algorithm on top of the LRP primitive. This is specified in [10], see also Section 9.2.3. The key derivation key is the AppTransactionMACKey. The input data is constructed using the following fields as defined by [10]. Note that NIST SP 800-108 allows defining a different order than proposed by the standard as long as it is unambiguously defined.

• 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 11-byte context, constructed using the 2-byte actTMC+1, 2-byte sesTMC+1 and the UID, followed by zero byte padding if needed
• a 1-byte label, distinguishing the purpose of the key: 5Ah for MACing and A5h for encryption Two session vectors SV x are derived as follows: No padding is done because the input using the 7 Byte UID is equal to 16 byte. Then, the 16-byte session keys SesTMMACKey and SesTMENCKey are constructed as follows: SesTMMACKey = MACLRP (AppTransactionMACKey; SV1) SesTMENCKey = MACLRP (AppTransactionMACKey; SV2) After the session key calculation, but before the first data operation, the non-user- accessible sesTMC is updated with the incremented value, such that a subsequent session key generation will use a new value.

10.3.2.4 Transaction MAC Value and Input

The 8-byte Transaction MAC Value (TMV) is computed over the Transaction MAC Input (TMI). This input depends on the commands executed during the transaction, see A different notation than the one for Secure Messaging MACs is used: MACtTM(key; message) is used to denote the CMAC operation including truncation. MACTM(key; message) denotes the CMAC result before truncation. Note that, though similar algorithm as for Secure Messaging are used, this MAC calculation is unrelated with the secure messaging itself as a different key is applied. The TMV is calculated as follows: TMV = MACtTM(SesTMMACKey, TMI) using the MAC algorithm of the Secure Messaging with zero byte IV, see Section 9.1.3. Note that even if the application is configured for LRP, standard AES CMAC is used for the TMV calculation. LRP is only used for the session key generation.

10.3.2.5 Transaction MAC Reader ID and its encryption

A Transaction MAC ReaderID is 16 bytes. If ReaderID commitment is enabled, see Section 10.3.4.3, two ReaderIDs are maintained by the card.

• TMRICur: the current ReaderID of the ongoing transaction. It is set with CommitReaderID

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 44 / 132

• TMRIPrev: the ReaderID of the latest successful transaction. On successful execution of CommitTransaction, TMRICur is stored on the PICC as TMRIPrev During the next transaction, the TMRIPrev is returned encrypted using SesTMENCKey. This is done via the EncTMRI parameter in the response of the CommitReaderID: EncTMRI = ETM(SesTMENCKey, TMRIPrev) using the AES block cipher according to the CBC mode of NIST SP800-38A [5] without adding any padding. The zero byte IV is applied, i.e. 128 bits of 0. The initial TMRIPrev, as configured during creation of the TransactionMAC, is set to all zero bytes, see Section 11.7.6. Note that even if the application is configured for LRP, standard AES encryption is used for the EncTMRI calculation. LRP is only used for the session key generation. The exact specification of the TMRI is out of scope for this document, but an example can be the 7- byte SAM UID with padding.

10.3.3 Transaction MAC Enabling

For MF2DL(H)x0, the Transaction MAC feature is enabled by default due to the existence of the TransactionMAC file. The Transaction MAC feature can be disabled for an application by deleting the TransactionMAC file with DeleteTransactionMACFile. The Transaction MAC feature can be re-enabled by creating the TransactionMAC file again with CreateTransactionMACFile, see Section 11.7.6. As soon as the Transaction MAC feature is enabled for a selected application, the Transaction MAC will be calculated, as specified in the next section, for every transaction within the currently selected application, starting with the next transaction. MF2DL(H)x0 supports additional Transaction MAC-related configuration options which can be set via ChangeFileSettings:

• enabling a Transaction MAC counter limit TMCLimit.
• excluding unauthenticated operations from Transaction MAC calculation. The AppTransactionMACKey is not an application key. Instead it is fully specified and set by the CreateTransactionMACFile. Therefore, if this key needs to be changed, the TransactionMAC file needs to be deleted and re-created. Notice that by doing this, the TMC is also reset to zero. Note that for MF2DL(H)x0 it is highly recommended to delete the initial TransactionMAC file and re-create a new TransactionMAC file using a confidential AppTransactionMACKey.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 45 / 132

10.3.4 Transaction MAC Calculation

10.3.4.1 Transaction MAC Initiation

A Transaction MAC calculation is initiated on transaction start, if the TransactionMAC file is present. Next to this, a new Transaction MAC calculation is initiated each time a transaction with ongoing Transaction MAC calculation is committed successfully with CommitTransaction, or aborted, as described in Section 10.2. Initiating a Transaction MAC calculation consists of the following steps:

• Set TMI to the empty byte string.
• Set TMRICur to the empty byte string. Note that AbortTransaction can be used to exclude data read (ReadData, ReadRecords or GetValue) from the Transaction MAC calculation if this data does not need to be authenticated via the Transaction MAC toward the backend.

10.3.4.2 Transaction MAC Update

If the Transaction MAC Input TMI is still empty, the Transaction MAC Session Keys (SesTMMACKey and SesTMENCKey), as defined in Section 10.3.2.3, are calculated. Note that the calculation of SesTMENCKey may be delayed until CommitReaderID. Once a Transaction MAC calculation is ongoing, the Transaction MAC Input TMI gets updated on each following data manipulation command targeting a file of any file type within the application, except TransactionMAC file itself. The affected commands are listed below including the exact TMI updates. The following holds for all commands: ZeroPadding is the minimal number of zero bytes added such that the length of the TMI up to and including the ZeroPadding is a multiple of 16 bytes. Note that this padding is also added if this TMI update is not the last one before CommitTransaction. Note that if executed while in not authenticated state (in case the access rights allow), the command can be excluded from Transaction MAC processing, according to the TransactionMAC configuration as can be done with ChangeFileSettings. In that case, TMI is not updated at all. Note that for each of these commands always the plain data are added, independently from the actual communication settings and secure messaging (i.e. plain data without any MAC, CRC, padding,. . . ). In case of command chaining, the chaining overhead is ignored for the Transaction MAC computation. Data is the complete response data of all frames with a total byte length of Length. Except otherwise noted in the commands, all parameters are exactly as they appear on the command interface. If TMCLimit was reached, see Section 10.3.2.2, the command is rejected. ReadData command TMI update TMI = TMI || Cmd || FileNo || Offset || Length || ZeroPadding || Data || ZeroPadding If Length is set to 000000h in the command, meaning that the whole file is read, the actual length value is filled in with the number of bytes read for the Transaction MAC calculation.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 46 / 132 The Transaction MAC is not updated when the TransactionMAC file is targeted with the ReadData command. WriteData command TMI update TMI = TMI || Cmd || FileNo || Offset || Length || ZeroPadding || Data || ZeroPadding Note that the first ZeroPadding for the WriteData command is actually adding 8 zero bytes after the command parameter fields so that those and the padding add up to 16 bytes. GetValue command TMI update TMI = TMI || Cmd || FileNo || Value || ZeroPadding Credit command TMI update TMI = TMI || Cmd || FileNo || Value || ZeroPadding Debit command TMI update TMI = TMI || Cmd || FileNo || Value || ZeroPadding LimitedCredit command TMI update TMI = TMI || Cmd || FileNo || Value || ZeroPadding ReadRecords command TMI update TMI = TMI || Cmd || FileNo || RecNo || RecCount || ZeroPadding || Data If RecCount is set to 000000h in the command, meaning that all records are read (starting from the RecNo), the actual length value is filled in with the number of records read for the TM computation. Note that ZeroPadding for the ReadRecords command is actually adding 8 zero bytes after the command parameter fields so that those and the padding add up to 16 bytes. As the data is always a multiple of 16 bytes, no padding is needed at the end of the TMI. WriteRecord command TMI update TMI = TMI || Cmd || FileNo || Offset || Length || ZeroPadding || Data Note that ZeroPadding for the WriteRecord command is actually adding 8 zero bytes after the command parameter fields so that those and the padding add up to 16 bytes. As the data is always a multiple of 16 bytes, no padding is needed at the end of the TMI. UpdateRecord command TMI update TMI = TMI || Cmd || FileNo || RecNo || Offset || Length || ZeroPadding || Data Note that ZeroPadding for the UpdateRecord command is actually adding 5 zero bytes after the command parameter fields so that those and the padding add up to 16 bytes. As the data is always a multiple of 16 bytes, no padding is needed at the end of the TMI. ClearRecordFile command TMI update TMI = TMI || Cmd || FileNo || ZeroPadding

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 47 / 132

10.3.4.3 CommitReaderID Command

The application can be configured to require a reader to securely commit to a ReaderID during transaction. Typically this requires the support of a SAM inside the reader such that the ReaderID cannot be forged by a fraudulent attacker (and also the key required to commit the ReaderID cannot be known). For example, the ReaderID can be the SAM UID. The SAM command API will need to ensure that the ReaderID value itself cannot be manipulated by an attacker. In this case ReadWrite of the TransactionMAC file will be configured to require authentication with a specific key. As specified in Section 8.2.3.6, ReadWrite of the TransactionMAC file can also be configured to allow free CommitReaderID access. This allows for use cases where this command can be used to add reader data (ID, time, GPS location, etc.) to the Transaction MAC calculation. However, it should not be used for the use case where this command is used to be able to track unreported and missing transactions. Committing a ReaderID is possible with the command CommitReaderID as defined in Section 11.9.3. Note that CommitTransaction will be rejected if CommitReaderID is required and has not been executed during the ongoing transaction. This is even the case if ReadWrite of the TransactionMAC file is configured for free access. Depending on the configuration of ReadWrite of the TransactionMAC file, an authentication is required with AppCommitReaderIDKey, see Section 8.2.3.6. If the selected application does not hold such a file or committing the ReaderID is disabled according to this access right, the command is rejected. The command is also rejected if a ReaderID has already been committed during the ongoing transaction. The parameter TMRI is the committed ReaderID and is assigned to TMRICur. If authenticated, this value is stored as TMRIPrev on a successful CommitTransaction. If not authenticated, the value is only used for the Transaction MAC computation. The Transaction MAC Input (TMI) is updated as follows including the received ReaderID, i.e. TMRICur, and if authenticated, the encrypted ReaderID of the latest successful transaction, i.e. EncTMRI: if authenticated: TMI = TMI || Cmd || TMRICur || EncTMRI || ZeroPadding if not authenticated: TMI = TMI || Cmd || TMRICur || ZeroPadding ZeroPadding is the minimal number of zero bytes added such that the length of the TMI up to and including the ZeroPadding is a multiple of 16 byte. Note that this padding is also added if this TMI update is not the last one before CommitTransaction. If authenticated, CommitReaderID will provide in its response the encrypted ReaderID of the previous transaction, as defined in Section 10.3.2.5. Note that this encryption is independent of the secure messaging as it is with a key derived from AppTransactionMACKey. If not authenticated, no data is returned and the given TMRICur is discarded. Note that even if ReadWrite is configured for free access, it is possible to execute the command authenticated, which will trigger the TMRIPrev processing, i.e. updating the value and replying the encrypted ReaderID. The CommitReaderID requires CommMode.MAC if there is an active authentication. If TMCLimit was reached, see Section 10.3.2.2, the command is rejected.

10.3.4.4 Transaction MAC Finalization

The Transaction MAC computation is successfully finalized on CommitTransaction as described in Section 10.2.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 48 / 132 The Transaction MAC is computed as defined in Section 10.3.2.4. If a transaction is aborted, either with AbortTransaction or implicitly by some other event, the ongoing Transaction MAC calculation is also aborted. This is described in Section 10.2.2.

11 Command set

11.1 Introduction

This section contains the full command set of MIFARE DESFire Light. SetConfiguration command may seem to have arbitrary values assigned. CMAC). Communication mode and condition are mentioned in the command description.

11.2 Supported commands and APDUs

Table 19. APDUs

90 AF 00 00 20 Data 00 Data 9100

11.3 Status word

Table 20. SW1 SW2 for CLA byte 0x90 0x9100 OPERATION_OK Successful operation. 0x911C ILLEGAL_COMMAND_CODE Command code not supported. 0x9140 NO_SUCH_KEY Invalid key number specified. 0x917E LENGTH_ERROR Length of command string invalid. 0x919E PARAMETER_ERROR Value of the parameter(s) invalid. trying until full delay is spent. 0x91AF ADDITIONAL_FRAME Additionaldata frame is expected to be sent.

0x91CA COMMAND_ABORTED Previous Command was not fully completed. application with same number already exists. 0x91F0 FILE_NOT_FOUND Specified file number does not exist. Table 21. SW1 SW2 for CLA byte 0x00 0x6CXX Wrong Le field; SW2 encodes the exact number of avail- able data bytes.

11.4 Authentication commands

used for secure messaging between the terminal and MF2DL(H)x0. messaging without LRP are set according to GSMA specification v2.0 to the value 7h. be applied by changing the configurable ATS within the Configuration Settings.

11.4.1 AuthenticateEV2First

Figure 13. AuthenticateEV2First command protocol Table 22. Command parameters description - AuthenticateEV2First - Part1

1 Targeted authentication key

LenCap 1 00h to 06h Length of the PCD Capabilities. [This value should be set to 00h]. [1] - Capability vector of the PCD.

PCDcap2.2-6 [1..5] Full range Capability vector of the PCD. Table 23. Response data parameters description - AuthenticateEV2First - Part1 Table 24. Return code description - AuthenticateEV2First - Part1 COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. Targeted key not available for authentication. Table 25. Command parameters description - AuthenticateEV2First - Part2

32 Full range

• RndA: 16 byte random from PCD.

Table 26. Response data parameters description - AuthenticateEV2First - Part2

32 Full range Encrypted PICC response

• RndA’: 16 byte RndA rotated left by 1 byte.

Table 27. Return code description - AuthenticateEV2First - Part2 LENGTH_ERROR 7Eh Command size not allowed. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.4.2 AuthenticateEV2NonFirst

Figure 14. AuthenticateEV2NonFirst command protocol Table 28. Command parameters description - AuthenticateEV2NonFirst - Part1 Table 29. Response data parameters description - AuthenticateEV2NonFirst - Part1

Table 30. Return code description - AuthenticateEV2NonFirst - Part1 COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. Targeted key not available for authentication. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory. Table 31. Command parameters description - AuthenticateEV2NonFirst - Part2

• RndA: 16 byte random from PCD.
• RndB': 16 byte RndB rotated left over 1 byte.

Table 32. Response data parameters description - AuthenticateEV2NonFirst - Part2

• RndA: 16 byte random from PCD.
• RndB’: 16 byte RndB rotated left over 1 byte.

Table 33. Return code description - AuthenticateEV2NonFirst - Part2 LENGTH_ERROR 7Eh Command size not allowed. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.4.3 AuthenticateLRPFirst

Figure 15. AuthenticateLRPFirst command protocol Table 34. Command parameters description - AuthenticateLRPFirst - Part1 LenCap 1 1h..6h Length of the PCD Capabilities. 1 - Capability vector of the PCD. PCDcap2.2-6 [1..5] Full range Capability vector of the PCD. Table 35. Response data parameters description - AuthenticateLRPFirst - Part1

Table 36. Return code description - AuthenticateLRPFirst - Part1 COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. NO_SUCH_KEY 40h Targeted key does not exist. or bigger than the TotFailCtrLimit. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory. Table 37. Command parameters description - AuthenticateLRPFirst - Part2 Table 38. Response data parameters description - AuthenticateLRPFirst - Part2

16 Full range PICC response to the challenge

Table 39. Return code description - AuthenticateLRPFirstPart2 LENGTH_ERROR 7Eh Command size not allowed. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.4.4 AuthenticateLRPNonFirst

authentication in a transaction. Figure 16. AuthenticationLRPNonFirst command protocol Table 40. Command parameters description - AuthenticateLRPNonFirst - Part1 Table 41. Response data parameters description - AuthenticateLRPNonFirst - Part1 Table 42. Return code description - AuthenticateLRPNonFirst - Part1 COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed.

Targeted key not available for authentication. AUTHENTICATION_DELAY ADh Currently not allowed to authenticate. Keep trying until full delay is spent. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory. Table 43. Command parameters description - AuthenticateLRPNonFirst - Part2 Table 44. Response data parameters description - AuthenticateLRPNonFirst - Part2 Table 45. Return code description - AuthenticateLRPNonFirst - Part2 LENGTH_ERROR 7Eh Command size not allowed. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.5 Memory and configuration commands

11.5.1 SetConfiguration

requires an authentication with the AppMasterKey and CommMode.Full. option. The option byte specifies the nature of the data field content. and its value is not changed. once and are locked afterwards. Figure 17. SetConfiguration command protocol Table 46. Command parameters description - SetConfiguration always transmitted in CommMode.Full. 04h Secure Messaging Configuration. Data Up to 20 bytes - Data content depends on option values.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 62 / 132 Name Length Value Description Full range Data content depends on option value as defined in setConfigOptionsList Table. Table 47. SetConfigOptionList

Description

Bit 5 UID0 configuration for Random ID. If bit 1 is set to 0b, this bit should be 0b. 0b: [if Bit1 = 1b] Enable ISO- compliant random ID (UID0 = 08h). 1b: [if Bit1 = 1b] Enable legacy random ID compatible with MIFARE DESFire EV1 (UID0 = 80h). Bit 4 -2 RFU Bit 1 UseRID configuration for Random. Random ID is disabled at delivery time. 1b: Enable Random ID 0b: No change 00h 1 byte PICCConfig Bit 0 RFU 02h 5 to 20 bytes User ATS 5 to 20 bytes User-defined ATS. TL byte of the ATS should be as 0 < TL< 20. Please refer to ISO/IEC 14443-4 for ATS definition. TL: Length byte: 5 <TL <20 T0: Supported values: 75h or 77h. This means interface bytes always present. FSC of 64 byte or 128 byte. TA(1): Any value TB(1): 71h, 81h. FWI is set by default to 7h. In use of LRP, FWI value shall be changed to 8h. SFGI should be 1h. TC(1): 02h. CID supported, NAD not supported. Tk: Historical bytes: can hold any value 03h 2 bytes User SAK 2 bytes User-defined SAK1 and SAK2 each of one byte long formatted as SAK1 and SAK2. Refer to ISO/ IEC 14443-3 for SAK1 and SAK2 definition.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 63 / 132 Option Data Length Field Length/bitin dex Secure Messaging Configuration Bit 15 to 3 RFUSMConfig Bit 2 Secure messaging configuration for StandardData file 0b: No Change 1b: disable chained writing with WriteData command in CommMod e.MAC and CommMode.Full 04h 2 bytes Bit 1-0 RFU Capability data, consisting of PDCap2 4 bytes RFU 1 byte User configured PDCap2.1 Bit 7 to 2: RFU Bit 1: 1b means enable LRP mode. This change is permanent, LRP mode cannot be disabled afterwards. Bit 1: 0b means no change 3 bytes RFU 1 byte User configured PDCap2.5 05h 10 bytes 1 byte User configured PDCap2.6 Application ID renaming (one-time configuration) AppNameOptions 1 byte Bit 7 must be set to 1b and means update of the 2-byte ISOFile ID Bit 6 to 5: RFU Bit 4 to 0: Length of DF Name, must be in the range of 1 to 16 DF Name 16 bytes DF Name - up to 16 byte, padded with 00h bytes if needed 06h 17,19 bytes ISO FileID 2 bytes ISO File ID, LSB first Excluding the following values reserved by ISO: 0000h, 3F00h, 3FFFh, FFFFh File renaming (one-time configuration) File Name Option 1 byte Bit 7 to 2: RFU Bit 1: Set to 1b means update 2 files Bit 1: Set to 0b means update 1 file Bit 0: Set to 1b means update ISO File ID Bit 0: Set to 0b means no update of ISO File ID OldFileNo 1 byte Current FileNo of the first file 08h 3,5,9 bytes NewFileNo 1 byte New FileNo for the first file

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 64 / 132 Option Data Length Field Length/bitin dex NewFileID 2 bytes [Optional, present if FileNameOptions Bit 0 = 1b] New ISOFileID for the first file. LSB first. Excluding the following values reserved by ISO: 0000h, 3F00h, 3FFFh, FFFFh OldFileNo2 1 byte [Optional, present if FileNameOptions Bit 1 = 1b] Current FileNo of the second file NewFileNo2 1 byte [Optional, present if FileNameOptions Bit 1 = 1b] New FileNo for the second file NewFileID2 2 bytes [Optional, present if FileNameOptions Bit 1 = 1b AND File- NameOptions Bit 0 = 1b] New ISOFileID for the second file. LSB first. Excluding the following values reserved by ISO: 0000h, 3F00h, 3FFFh, FFFFh Value file configuration (one-time configuration) File Nr 1 byte FileNo of the targeted file Lower Limit 4 bytes Lower Limit of the file encoded as a 4 byte signed integer, with LowerLimit less than or equal to UpperLimit UpperLimit 4 bytes Upper Limit of the file encoded as a 4 byte signed integer, with LowerLimit less than or equal to UpperLimit. Value 4 bytes Current Value with Value greater than or equal to Lower- Limit and less than or equal to UpperLimit. 09h 14 bytes ValueOption 1byte Bit 7 to 2: RFU Bit1: 0b means No free access to GetValue Bit1: 1b means free access to GetValue Bit 0: 0b means LimitedCredit command disabled Bit 0: 1b means LimitedCredit command enabled Failed authentication counter configuration0Ah 5 bytes FailedCtrOption 1 byte Bit 7 to 1: RFU Bit 0: Set to 0b for disabling Bit 0: Set to 1b for enabling [default]

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 65 / 132 Option Data Length Field Length/bitin dex TotFailCtrLimit 2 bytes configurable limit, encoded as 2-byte unsigned integer (LSB first), must be bigger than 0000h. Default value: 1000. When disabling, this value is ignored TotFailCtrDecr 2 bytes configurable decrement value, encoded as 2-byte unsigned integer (LSB first). Default value: 10. When disabling, this value is ignored. HW configuration0Bh 1 byte HW Option 1 byte Bit 7 to 1: RFU Bit 0: Set to 0b for Standard back modulation Bit 0: Set to 1b for Strong back modulation (default) Table 48. Response data parameters description - SetConfiguration Table 49. Return code description - SetConfiguration COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. LENGTH_ERROR 7Eh Command size not allowed. Option 02h: Data length is not in the range [5..20].

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 66 / 132 Status Value Description PARAMETER_ERROR 9Eh Parameter value not allowed. Option 00h: Data bit 7-6 or bit 4-2 or bit 0 not set to 0b. Option 02h: TL inconsistent with length of received ATS string or unsupported T0, TB(1) or TC(1) value Unsupported option (i.e. Reserved). PERMISSION_DENIED 9Dh Option 00h, 02h, 03h, 04h, 05h, 06h, 08h, 09h, 0Ah, 0Bh: not supported / allowed at PICC level Option 06h: application renaming not allowed anymore as already done once Option 08h: file renaming not allowed anymore as (for both files if updating two) it was already done once. Option 08h: trying to update ISOFileID while the targeted file does not have an ISOFileID. Option 09h: file configuration not allowed anymore as already done once or targeted file is not a Value file FILE_NOT_FOUND F0h Option 08h: File with targeted OldFileNo1 or OldFileNo2 does not exist within the targeted application. Option 09h: File with targeted FileNo does not exist within the targeted application. AUTHENTICATION_ERROR AEh Option 00h, 02h, 03h, 04h, 05h, 06h, 08h, 09h, 0Ah, 0Bh: No active authentication with AppMasterKey. DUPLICATE_ERROR DEh Option 06h: executing application renaming would result in duplicate DFNames. Option 08h: executing file renaming would result in duplicate FileNos or ISOFileIDs. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.5.2 GetVersion

(MF2DL(H)x0). No parameters are required for this command. Remark: This command is only available after ISO/IEC 14443-4 activation. secure messaging as soon as the PD is selected and there is no active authentication. Figure 18. GetVersion command protocol Table 50. Command parameters description - GetVersion - Part1 Table 51. Response data parameters description - GetVersion - Part1

Table 52. Command parameters description - GetVersion - Part2 CMD 1 AFh Additional frame request. Table 53. Response data parameters description - GetVersion - Part2 Table 54. Command parameters description - GetVersion - Part3 CMD 1 AFh Additional frame request.

Table 55. Response data parameters description - GetVersion - Part3 Table 56. Return code description - GetVersion COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC (only). LENGTH_ERROR 7Eh Command size not allowed. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.5.3 GetCardUID

retrieve the UID, even if the Random ID is used. Figure 19. GetCardUID command protocol Table 57. Command parameters description - GetCardUID Table 58. Response data parameters description - GetCardUID Table 59. Return code description - GetCardUID COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC (only). LENGTH_ERROR 7Eh Command size not allowed. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.6 Key management commands

MF2DL(H)x0 provides the following command set for Key Management.

11.6.1 ChangeKey

Figure 20. ChangeKey command protocol Table 60. Command parameters description - ChangeKey 1 - Key number of the key to be changed. Table 61. Response data parameters description - ChangeKey

Table 62. Return code description - ChangeKey COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. messaging MAC ( Secure Messaging). LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. AppMasterKey while targeting any AppKey. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.6.2 GetKeyVersion

can be changed with the ChangeKey command together with the key. Figure 21. GetKeyVersion command protocol Table 63. Command parameters description - GetKeyVersion Table 64. Response data parameters description - GetKeyVersion Table 65. Return code description - GetKeyVersion COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC (only). LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. NO_SUCH_KEY 40h Targeted key does not exist. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.7 File management commands

The MF2DL(H)x0 provides the following command set for File Management functions.

11.7.1 ChangeFileSettings

The ChangeFileSettings command changes the access parameters of an existing file. current access right of the file. Figure 22. ChangeFileSettings command protocol Table 66. Command parameters description - ChangeFileSettings 1 - File number of the targeted file. 1 - Options for the targeted file.

Table 67. Response data parameters description - ChangeFileSettings Table 68. Return code description - ChangeFileSettings COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. LENGTH_ERROR 7Eh Command size not allowed. Parameter value not allowed. AccessRights does not exist. i.e. enabling free CommitReaderID. while the access conditions is different from Fh. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.7.2 GetFileSettings

Figure 23. GetFileSettings command protocol Table 69. Command parameters description - GetFileSettings 1 - File number of the targeted file. Table 70. Response data parameters description - GetFileSettings - Targeting Data File

• File Type of the targeted file.

1 - Options for the targeted file. FileSize 3 - File size of the targeted file. Table 71. Response data parameters description - GetFileSettings - Targeting Value File. FileType 1 02h File Type of the targeted file.

1 - Options for the targeted file. the file (see Section 8.2.3.5). GetValue is allowed for this file. Table 72. Response data parameters description - GetFileSettings - Targeting CyclicRecord 1 - Options for the targeted file. CurrNoOfRecs 3 - Current number of records within the file.

Table 73. Response data parameters description - GetFileSettings - Targeting FileType 1 05h File Type of the targeted file. 1 - Options for the targeted file. Table 74. Return code description - GetFileSettings COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC (only).

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 79 / 132 Status Value Description LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. PERMISSION_DENIED 9Dh PICC level (MF) is selected. FILE_NOT_FOUND F0h File with targeted FileNo does not exist for the targeted application. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.7.3 GetFileIDs

MIFARE DESFire Light application. Communication mode is CommMode.MAC. Figure 24. GetFileIDs command protocol Table 75. Command parameters description - GetFileIDs Table 76. Response data parameters description - GetFileIDs - OPERATION_OK Table 77. Return code description - GetFileIDs COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC (only). LENGTH_ERROR 7Eh Command size not allowed. PERMISSION_DENIED 9Dh PICC level (MF) is selected. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.7.4 GetISOFileIDs

active files within the currently selected application. Figure 25. GetISOFileIDs command protocol Table 78. Command parameters description - GetISOFileIDs Table 79. Response data parameters description - GetISOFileIDs and the CyclicRecord file, 2 bytes per file. Table 80. Return code description - GetISOFileIDs COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC (only). LENGTH_ERROR 7Eh Command size not allowed. PERMISSION_DENIED 9Dh PICC level (MF) is selected. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.7.5 DeleteTransactionMACFile

The TransactionMAC file can be deleted using the DeleteTransactionMACFile command. Figure 26. DeleteTransactionMACFile command protocol Table 81. Command parameters description - DeleteTransactionMACFile 1 - File number of the file to be deleted. Table 82. Response data parameters description - DeleteTransactionMACFile

8 CMAC 8-byte CMAC

Table 83. Return code description - DeleteTransactionMACFile COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC (only). LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. Targeted file is not TransactionMAC file. FILE_NOT_FOUND F0h Targeted file does not exist in the targeted application. AUTHENTICATION_ERROR AEh No active authentication with AppMasterKey.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 83 / 132 Status Value Description MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.7.6 CreateTransactionMACFile

executed only in a secure environment. Figure 27. CreateTransactionMACFile command protocol Table 84. Command parameters description - CreateTransactionMACFile 1 - File number of the file to be created. 1 - Options for the targeted file.

Table 85. Response data parameters description - CreateTransactionMACFile Table 86. Return code description - CreateTransactionMACFile COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC (only). LENGTH_ERROR 7Eh Command size not allowed. AccessRights does not exist. AUTHENTICATION_ERROR AEh No active authentication with AppMasterKey. DUPLICATE_ERROR DEh File with the targeted FileNo already exists. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.8 Data management commands

The MF2DL(H)x0 provides the following command set for Data Management functions.

11.8.1 ReadData

Figure 28. ReadData command protocol Table 87. Command parameters description - ReadData 1 - File number of the targeted file. Starting position for the read operation.

• Number of bytes to be read.

from the position specified in the offset value.

Table 88. Response data parameters description - ReadData Table 89. Return code description - ReadData PICC level (MF) is selected. only have access conditions set to Fh. access conditions set to Fh.

11.8.2 WriteData

better control of the overall write process. interrupted WriteData using chained communication. Figure 29. WriteData command protocol Table 90. Command parameters description - WriteData 1 - File number of the targeted file. Starting position for the write operation. Number of bytes to be written. Full range Data to be written.

Table 91. Response data parameters description - WriteData Table 92. Return code description - WriteData COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC or encryption padding. LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. PICC level (MF) is selected. Targeted file is not of StandardData. in MAC or Full while this is not allowed. sesTMC reached its maximal value. FILE_NOT_FOUND F0h Targeted file does not exist in the targeted application. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.8.3 GetValue

The GetValue command allows reading the currently stored value from the Value file. retrieve the old, unchanged value which is still the valid one. Figure 30. GetValue command protocol Table 93. Command parameters description - GetValue 1 FileNr File number of the targeted file. Table 94. Response data parameters description - GetValue Table 95. Return code description - GetValue COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC (only). LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. PERMISSION_DENIED 9Dh PICC level (MF) is selected.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 91 / 132 Status Value Description Targeted file is not of Value. Read, Write and ReadWrite of targeted file only have access conditions set to Fh. sesTMC reached its maximal value. TMCLimit was reached. FILE_NOT_FOUND F0h Targeted file does not exist in the targeted application. AUTHENTICATION_ERROR AEh Read, Write and ReadWrite of targeted file not granted while at least one of the access conditions is different from Fh and no free access was granted at file creation. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.8.4 Credit

Limited Credit Value needs to be set to 0, a LimitedCredit with value 0 can be used. Figure 31. Credit command protocol Table 96. Command parameters description - Credit 1 - File number of the targeted file. Table 97. Response data parameters description - Credit Table 98. Return code description - Credit COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC or encryption padding. LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 93 / 132 Status Value Description PICC level (MF) is selected. Targeted file is not of Value. ReadWrite of targeted file only have access conditions set to Fh sesTMC reached its maximal value. PERMISSION_DENIED 9Dh TMCLimit was reached. FILE_NOT_FOUND F0h Targeted file does not exist in the targeted application. AUTHENTICATION_ERROR AEh ReadWrite of targeted file not granted while at least one of the access conditions is different from Fh. BOUNDARY_ERROR BEh Data added to the current value of the value file is bigger than the value file UpperLimit or create an integer arithmetic overflow. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.8.5 Debit

rebook more values than a debiting transaction deducted before. Figure 32. Debit command protocol Table 99. Command parameters description - Debit 1 - File number of the targeted file. Table 100. Response data parameters description - Debit Table 101. Return code description - Debit COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC or encryption padding. LENGTH_ERROR 7Eh Command size not allowed.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 95 / 132 Status Value Description PARAMETER_ERROR 9Eh Parameter value not allowed. PICC level (MF) is selected. Targeted file is not of Value. Read, Write and ReadWrite of targeted file only have access conditions set to Fh sesTMC reached its maximal value. PERMISSION_DENIED 9Dh TMCLimit was reached. FILE_NOT_FOUND F0h Targeted file does not exist in the targeted application. AUTHENTICATION_ERROR AEh Read, Write and ReadWrite of targeted file not granted while at least one of the access conditions is different from Fh. BOUNDARY_ERROR BEh Data subtracted to the current value of the value file is smaller than the value file LowerLimit or create an integer arithmetic underflow. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.8.6 LimitedCredit

a CommitTransaction command. An AbortTransaction command invalidates all changes. preceding authentication with the AppKey specified for “Write” or "Read&Write" access. Figure 33. LimitedCredit command protocol Table 102. Command parameters description - LimitedCredit 1 - File number of the targeted file. Table 103. Response data parameters description - LimitedCredit Table 104. Return code description - LimitedCredit COMMAND_ABORTED CAh Chained command or multiple pass command ongoing.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 97 / 132 Status Value Description INTEGRITY_ERROR 1Eh Invalid secure messaging MAC or encryption padding. LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. PICC level (MF) is selected. Targeted file is not of Value. Write and ReadWrite of targeted file only have access conditions set to Fh Limited credit not enabled for file with FileNo. sesTMC reached its maximal value. PERMISSION_DENIED 9Dh TMCLimit was reached. FILE_NOT_FOUND F0h Targeted file does not exist in the targeted application. AUTHENTICATION_ERROR AEh Write and ReadWrite of targeted file not granted while at least one of the access conditions is different from Fh. Data is exceeding the limited credit limit. Already successfully executed a LimitedCredit command during the current ongoing transaction. BOUNDARY_ERROR BEh Already successfully executed and committed a L imitedCredit command since the latest successful transaction containing at least one Debit MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.8.7 ReadRecords

Figure 34. ReadRecords command protocol Table 105. Command parameters description - ReadRecords 1 - File number of the targeted file. starting with the latest record written.

Table 106. Response data parameters description - ReadRecords Table 107. Return code description - ReadRecords COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC (only). LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. PICC level (MF) is selected. Targeted file is not of CyclicRecord. sesTMC reached its maximal value. FILE_NOT_FOUND F0h Targeted file does not exist in the targeted application. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.8.8 WriteRecord

create a new record in the record file. CommMode.Plain, CommMode.MAC or CommMode.Full. Figure 35. WriteRecord command protocol Table 108. Command parameters description - WriteRecord 1 - File number of the targeted file. Number of bytes to be written. Data up to 64 Full range Data to be written. Table 109. Response data parameters description - WriteRecord

Table 110. Return code description - WriteRecord COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC or encryption padding. LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. PICC level (MF) is selected. Targeted file is not of CyclicRecord. sesTMC reached its maximal value. FILE_NOT_FOUND F0h Targeted file does not exist in the targeted application. Offset + Length + 1 is bigger than 16 bytes. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.8.9 UpdateRecord

Figure 36. UpdateRecord command protocol Table 111. Command parameters description - UpdateRecord 1 - File number of the targeted file. starting with the latest record written. 000000h meaning the latest record written. existing records (ExistingRecCount). Number of bytes to be updated. Table 112. Response data parameters description - UpdateRecord Table 113. Return code description - UpdateRecord COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC or encryption padding. LENGTH_ERROR 7Eh Command size not allowed.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 103 / 132 Status Value Description PARAMETER_ERROR 9Eh Parameter value not allowed. PICC level (MF) is selected. Targeted file is not of CyclicRecord. ReadWrite of targeted file only have access conditions set to Fh A ClearRecordFile targeting the currently targeted file has already been performed within the current transaction. A WriteRecord targeting the currently targeted file has already been performed within the current transaction. An UpdateRecord targeting a record different from the currently targeted record has already been performed within the current transaction. sesTMC reached its maximal value. PERMISSION_DENIED 9Dh TMCLimit was reached. FILE_NOT_FOUND F0h Targeted file does not exist in the targeted application. AUTHENTICATION_ERROR AEh ReadWrite of targeted file not granted while at least one of the access conditions is different from Fh. RecNo is strictly bigger than the number of existing record in the file. Offset + 1 is bigger than 16 bytes. BOUNDARY_ERROR BEh Offset + Length + 1 is bigger than 16 bytes. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.8.10 ClearRecordFile

commands will fail. The ReadRecords command returns the old still valid records. CommitTransaction) invalidates the clearance. Figure 37. ClearRecordFile command protocol Table 114. Command parameters description - ClearRecordFile 1 - File number of the targeted file. Table 115. Response data parameters description - ClearRecordFile Table 116. Return code description - ClearRecordFile INTEGRITY_ERROR 1Eh Invalid secure messaging MAC. LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. Targeted file is not of CyclicRecord.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 105 / 132 Status Value Description ReadWrite of targeted file only have access conditions set to Fh sesTMC reached its maximal value. TMCLimit was reached. FILE_NOT_FOUND F0h Targeted file does not exist in the targeted application. AUTHENTICATION_ERROR AEh ReadWrite of targeted file not granted while at least one of the access conditions is different from Fh. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.9 Transaction management commands

11.9.1 CommitTransaction

last command of a transaction before the ISO/IEC 14443-4 deselect command. Figure 38. CommitTransaction command protocol Table 117. Command parameters description - CommitTransaction Table 118. Response data parameters description - CommitTransaction

Table 119. Return code description - CommitTransaction COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC (only). LENGTH_ERROR 7Eh Command size not allowed. PARAMETER_ERROR 9Eh Parameter value not allowed. PERMISSION_DENIED 9Dh PICC level (MF) is selected. i.e. TMRICur is the empty string. (if Transaction MAC active) TMI is the empty string. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.9.2 AbortTransaction

Figure 39. AbortTransaction command protocol Table 120. Command parameters description - AbortTransaction Table 121. Response data parameters description - AbortTransaction Table 122. Return code description - AbortTransaction COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC (only). LENGTH_ERROR 7Eh Command size not allowed. PERMISSION_DENIED 9Dh PICC level (MF) is selected. (if Transaction MAC active) TMI is the empty string. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.9.3 CommitReaderID

allow a backend to identify any inconsistency in use of the card. Figure 40. CommitReaderID command protocol Table 123. Command parameters description - CommitReaderID Table 124. Response data parameters description - CommitReaderID EncTMRI [16] Full Range Optional, present if authenticated. latest successful transaction. Table 125. Return code description - CommitReaderID COMMAND_ABORTED CAh Chained command or multiple pass command ongoing. INTEGRITY_ERROR 1Eh Invalid secure messaging MAC. LENGTH_ERROR 7Eh Command size not allowed. PICC level (MF) is selected. The application does not hold a TransactionMAC file. sesTMC reached its maximal value.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 110 / 132 Status Value Description TMCLimit was reached. AUTHENTICATION_ERROR AEh No active authentication with AppCommitReaderIDKey. MEMORY_ERROR EEh Failure when reading or writing to non-volatile memory.

11.10 Inter-industry standard commands

MF2DL(H)x0 provides the following ISO/IEC 7816-4 wrapped commands.

11.10.1 ISOSelectFile

PICC level, an application or a file within the application. D2760000850100h. When selecting this DF name, the PICC level (or MF) is selected. SetConfiguration can be used. Figure 41. ISOSelectFile command protocol Table 126. Command parameters description - ISOSelectFile

Table 127. Response data parameters description - ISOSelectFile FCI stored in file ID 1Fh of the DF. Table 128. Return code description - ISOSelectFile TMCLimit reached, see Section 10.3.2.2. sesTMC reached maximal value. application selected with limited functionality. ISO6700 6700h Wrong or inconsistent APDU length. ISO6985 6985h Wrapped chained command or multiple pass command ongoing.

11.10.2 ISOReadBinary

access right must be set to free access rights. Figure 42. ISOReadBinary command protocol Table 129. Command parameters description - ISOReadBinary

1 ShortFile ID/Offset

P1[Bit 4..0] encode a short ISO FileID. P2[Bit 7..0] encode an offset from zero to 255. 00h Targeting currently selected file. should be included in this value. from the offset position is returned.

Table 130. Response data parameters description - ISOReadBinary Table 131. Return code description - ISOReadBinary ISO6700 6700h Wrong or inconsistent APDU length. ReadWrite equal to Eh is allowed. Security status not satisfied: AuthenticatedEV2 not allowed. Security status not satisfied: AuthenticatedLRP not allowed. ISO6985 6985h Wrapped chained command or multiple pass command ongoing. Targeted file is not of StandardData. Application of targeted file holds a TransactionMAC file.

11.10.3 ISOUpdateBinary

chaining can enable better control of the overall write process. Figure 43. ISOUpdateBinary command protocol Table 132. Command parameters description - ISOUpdateBinary P1[Bit 4..0] encode a short ISO FileID. P2[Bit 7..0] encode an offset from zero to 255. 00h Targeting currently selected file. Table 133. Response data parameters description - ISOUpdateBinary

Table 134. Return code description - ISOUpdateBinary ISO6700 6700h Wrong or inconsistent APDU length. ReadWrite equal to Eh is allowed. Security status not satisfied: AuthenticatedEV2 not allowed. Security status not satisfied: AuthenticatedLRP not allowed. ISO6985 6985h Wrapped chained command or multiple pass command ongoing. Targeted file is not of StandardData. Attempt to write beyond the file boundary as set during creation. Application of targeted file holds a TransactionMAC file.

11.11 Originality check commands

asymmetric signature retrieved from the card.

• AuthenticateLRPFirst, see Section 9.2.5
• AuthenticateLRPNonFirst, see Section 9.2.6 The asymmetric originality signature is based on ECC and only requires a public key for the verification, which is done outside the card. The Read_Sig command can be used in both ISO/IEC 14443-3 and ISO/IEC 14443-4 protocols to retrieve the signature. If the PICC is not configured for Random ID, the command is freely available. There is no authentication required. If the PICC is configured for Random ID, an authentication is required.

11.11.1 Read_Sig

prevent HW copy or emulation of individual ICs. NXPOriginalitySignature is computed over the UID and written during manufacturing. requires encrypted secure messaging. Figure 44. Read_Sig command protocol Table 135. Command parameters description - Read_Sig

Table 136. Response data parameters description - Read_Sig Table 137. Return code description - Read_Sig Missing or incorrect MAC when authenticated. Frames were requested or provided by the PCD. together with example is explained in MF2DL(H)x0 - Feature and Hints application note.

12 Limiting values

the device. Exposure to limiting values for extended periods can affect device reliability. Table 138. Limiting values In accordance with the Absolute Maximum Rating System (IEC 60134). precautions for handling electrostatic sensitive devices. JESD625-A or equivalent standards.

13 Characteristics

Table 139. Characteristics

1. Total package thickness, exclusive punching burr.

For unspecified dimensions see PLLMC-drawing given in the subpackage code. Figure 45. Package outline SOT500-4 (MOA8)

For unspecified dimensions see PLLMC-drawing given in the subpackage code.

1. Total package thickness, exclusive punching burr.

Figure 46. Package outline SOT500-2 (MOA4) For details on the contactless modules MOA4 and MOA8 refer to [11] and [12].

15 Abbreviations

Table 140. Abbreviations

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 123 / 132 Acronym Description PCDCap Proximity Coupling Device Capabilities PD Proximity Device, used as synonym for the PICC PDCap Proximity Device Capabilities PICC Proximity IC Card PPS Protocol Parameter Select RC Return Code R-APDU Response APDU RFU Reserved for future use RID Random ID SAK Select Acknowledge SAM Secure Access Module SesAuthENCKey Session key for encryption SesAuthMACKey Session key for MACing SesTMENCKey Transaction MAC Session Key for Encryption SesTMMACKey Transaction MAC Session Key for MACing SM Secure Messaging SV Session Vector, input for session key calculation SW Status Word TI Transaction Identifier TMAC Transaction MAC TMC Transaction MAC Counter TMCLimit Transaction MAC Counter Limit TMI Transaction MAC Input TMRICur Current Transaction MAC Reader ID TMRIPrev Previous Transaction MAC Reader ID TMV Transaction MAC Value TotFailCtr Total Failed Authentication Counter TotFailCtrDecr Total Failed Authentication Counter Decrement TotFailCtrLimit Total Failed Authentication Counter Limit UID Unique IDentifier

16 References

[1] ISO/IEC 14443-2:2016 Identification cards -- Contactless integrated circuit cards -- Proximity cards -- Part 2: Radio frequency power and signal interface [2] ISO/IEC 14443-3:2016

BlockCipher Modes of Operation. Cipher Modes of Operation: The CMAC Mode for Authentication. (MACs) – Part 1: Mechanisms using a block cipher. derivation using pseudorandom functions. CD) Access Method and Physical Layer Specifications. Elliptic curve cryptography. Version 2.0, May 2009. Table 141. Revision history

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 125 / 132 Document ID Release date Data sheet status Change notice Supersedes MF2DL_H_x0 v. 3.1 20190207 Product data sheet - MF2DL_H_x0 v. 3.0 Modifications: • Editorial update MF2DL_H_x0 v. 3.0 20190131 Product data sheet - 430712 Modifications: • Data sheet status changed into Product data sheet

• Security status changed into "Company public" 430712 20181105 Objective data sheet 430711 Modifications: • added response codes in Section 11.3
• clarified generation of SDMMetaReadUpdateKey in LRP mode encryption 430711 20180321 Objective data sheet - 430710 Modifications: • added TMCLimit to ChangeFileSettings and GetFileSettings
• added note about the limit of data within a single ISO/IEC 7816-4 frame in Section 8.4
• added clarification about the authentication delay after unsuccessful AES mode authentications in Section 9
• added default file parameters to the individual sections in chapter Section 8.2.3
• added details for PCDcap2 in authentication commands, see Section 11.4.1 and Section 11.4.3
• corrected GetVersion response
• clarified Application ID renaming option in Section 11.5.1
• clarifications added across the data sheet
• editorial changes 430710 20180111 Objective data sheet - -

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 126 / 132

18 Legal information

18.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.

18.2 Definitions

Draft — The document is a draft version only. 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 herein 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.

18.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.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 127 / 132 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. 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. 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 is for reference only. The English version shall prevail in case of any discrepancy between the translated and English versions.

18.4 Licenses

ICs with DPA Countermeasures functionality NXP ICs containing functionality implementing countermeasures to Differential Power Analysis and Simple Power Analysis are produced and sold under applicable license from Cryptography Research, Inc.

18.5 Trademarks

Notice: All referenced brands, product names, service names and trademarks are the property of their respective owners. MIFARE — is a trademark of NXP B.V. DESFire — is a trademark of NXP B.V.

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 128 / 132 Tables Tab. 22. Command parameters description - Tab. 23. Response data parameters description - Tab. 24. Return code description - Tab. 25. Command parameters description - Tab. 26. Response data parameters description - Tab. 27. Return code description - Tab. 28. Command parameters description - Tab. 29. Response data parameters description - Tab. 30. Return code description - Tab. 31. Command parameters description - Tab. 32. Response data parameters description - Tab. 33. Return code description - Tab. 34. Command parameters description - Tab. 35. Response data parameters description - Tab. 36. Return code description - Tab. 37. Command parameters description - Tab. 38. Response data parameters description - Tab. 39. Return code description - Tab. 40. Command parameters description - Tab. 41. Response data parameters description - Tab. 42. Return code description - Tab. 43. Command parameters description - Tab. 44. Response data parameters description - Tab. 45. Return code description - Tab. 46. Command parameters description - Tab. 48. Response data parameters description - Tab. 50. Command parameters description - Tab. 51. Response data parameters description - Tab. 52. Command parameters description - Tab. 53. Response data parameters description - Tab. 54. Command parameters description - Tab. 55. Response data parameters description - Tab. 57. Command parameters description - Tab. 58. Response data parameters description - Tab. 60. Command parameters description - Tab. 61. Response data parameters description - Tab. 63. Command parameters description - Tab. 64. Response data parameters description - Tab. 66. Command parameters description - Tab. 67. Response data parameters description - Tab. 68. Return code description - Tab. 69. Command parameters description -

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 129 / 132 Tab. 70. Response data parameters description - Tab. 71. Response data parameters description - Tab. 72. Response data parameters description - GetFileSettings - Targeting CyclicRecord Tab. 73. Response data parameters description - GetFileSettings - Targeting Tab. 75. Command parameters description - Tab. 76. Response data parameters description - Tab. 78. Command parameters description - Tab. 79. Response data parameters description - Tab. 81. Command parameters description - Tab. 82. Response data parameters description - Tab. 83. Return code description - Tab. 84. Command parameters description - Tab. 85. Response data parameters description - Tab. 86. Return code description - Tab. 87. Command parameters description - Tab. 88. Response data parameters description - Tab. 90. Command parameters description - Tab. 91. Response data parameters description - Tab. 93. Command parameters description - Tab. 94. Response data parameters description - Tab. 97. Response data parameters description - Tab. 100. Response data parameters description - Tab. 102. Command parameters description - Tab. 103. Response data parameters description - Tab. 105. Command parameters description - Tab. 106. Response data parameters description - Tab. 108. Command parameters description - Tab. 109. Response data parameters description - Tab. 111. Command parameters description - Tab. 112. Response data parameters description - Tab. 114. Command parameters description - Tab. 115. Response data parameters description - Tab. 117. Command parameters description - Tab. 118. Response data parameters description - Tab. 119. Return code description - Tab. 120. Command parameters description - Tab. 121. Response data parameters description - Tab. 123. Command parameters description - Tab. 124. Response data parameters description - Tab. 125. Return code description - CommitReaderID .. 109 Tab. 126. Command parameters description - Tab. 127. Response data parameters description - Tab. 129. Command parameters description - Tab. 130. Response data parameters description - Tab. 132. Command parameters description - Tab. 133. Response data parameters description - Tab. 134. Return code description - ISOUpdateBinary .. 116 Tab. 135. Command parameters description - Read_ Tab. 136. Response data parameters description -

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 130 / 132 Figures Fig. 6. MIFARE DESFire Light secure messaging Fig. 7. Session key generation for Secure Fig. 9. Secure Messaging: MAC Communication Fig. 11. LRP Secure Messaging: MAC Protection Fig. 14. AuthenticateEV2NonFirst command Fig. 16. AuthenticationLRPNonFirst command Fig. 26. DeleteTransactionMACFile command Fig. 27. CreateTransactionMACFile command

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Product data sheet Rev. 3.3 — 5 April 2019 COMPANY PUBLIC 430733 131 / 132

Contents

10.3.2.5 Transaction MAC Reader ID and its

NXP Semiconductors MF2DL(H)x0 MIFARE DESFire Light contactless application IC Please be aware that important notices concerning this document and the product(s) described herein, have been included in section 'Legal information'. © NXP B.V. 2019. All rights reserved. For more information, please visit: http://www.nxp.com For sales office addresses, please send an email to: salesaddresses@nxp.com Date of release: 5 April 2019 Document identifier: MF2DL_H_x0 Document number: 430733