A30LDJHN2

NXP Semiconductors

Secure Authenticator Rev. 3.0 27 January 2025

Manufacturer: NXP Semiconductors

Document: 209 Pages / 2Mb

Request Quote Download Datasheet Read online HTML view

More from NXP Semiconductors Browse A parts

Online Datasheet

Read A30LDJHN2 online.

A30 NXP | Alldatasheet

Document overview

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

Technical content

Datasheet sections

1 General description
2 Features and use cases
2.1 Use cases
2.2 Key features
2.3 Configuration
2.4 Configuration as authenticator
2.5 Configuration to secure IoT applications
3 Ordering information
4 Block diagram
5 Pin description
6 Functional description
6.1 I2C support
6.1.1 I2C parameter values
6.1.1.1 Target address
6.1.1.2 Communication interface parameters
6.1.2 I2C Application Remarks
6.1.2.1 Power Management
6.1.2.2 Write after Write behavior
6.2 Command format and chaining
6.2.1 Native command format
6.2.2 ISO/IEC7816-4 communication frame
6.2.3 Command chaining
6.3 Authentication and Secure Messaging
6.3.1 Authentication overview
6.3.2 SIGMA-I authentication with
6.3.2.1 Session keys
6.3.2.2 Message types
6.3.2.3 Protocol exchange – Host as initiator
6.3.2.4 Protocol exchange – Host as responder
6.3.2.5 SIGMA-I session key generation
6.3.2.6 A30 Signature generation
6.3.2.7 SIGMA-I: Verification of the host
6.3.3 ECC-based card-unilateral authentication
6.3.3.1 Data structures and notations
6.3.3.2 Cryptographic primitives
6.3.3.3 ISOInternalAuthenticate
6.3.3.4 Authentication overview
6.3.4 AES-based Symmetric Authentication
6.3.4.1 Command AuthenticateEV2First
6.3.4.2 Command AuthenticateEV2NonFirst
6.3.4.3 Session Key Generation
6.3.5 AuthenticationCounter and Limit
6.3.6 EV2/AES secure messaging
6.3.6.1 Transaction Identifier
6.3.6.2 Command Counter
6.3.6.3 MAC Calculation
6.3.6.4 Encryption
6.3.6.5 Session Key Generation
6.3.6.6 Communication Modes
6.3.6.7 Plain Communication Mode
6.3.6.8 MAC Communication Mode
6.3.6.9 Full Communication Mode
6.3.7 Controller Session Key Usage
6.3.7.1 ProcessSM
6.3.7.2 ProcessSM_Apply
6.3.7.3 ProcessSM_Remove
6.3.8 Secure Dynamic Messaging
6.3.8.1 SDM Read Counter
6.3.8.2 SDM Read Counter Limit
6.3.8.3 PICCData
6.3.8.4 Encryption of PICCData
6.3.8.5 GPIOStatus
6.3.8.6 SDMENCFileData
6.3.8.7 Encryption of SDMENCFileData
6.3.8.8 SDMMAC
6.3.8.9 MAC Calculation
6.3.8.10 SDMSIG
6.3.8.11 Signature Calculation
6.3.8.12 SDM Session Key Generation
6.3.8.13 Output Mapping Examples
6.4 Access Rights Management
6.4.1 Access conditions
6.4.2 CARootKey access rights
6.4.3 Certificate access rights
6.5 Card Memory and Configuration
6.5.1 Card Version
6.5.1.1 Command GetVersion
6.5.2 Card configuration
6.5.2.1 Command SetConfiguration
6.5.2.2 Command GetConfiguration
6.5.2.3 Memory management
6.6 Symmetric Key Management
6.6.1 Key Types
6.6.2 Key Versioning
6.6.3 Symmetric Keys
6.6.3.1 AppMasterKey
6.6.3.2 AppKey
6.6.3.3 SDMMetaReadKey
6.6.3.4 SDMFileReadKey
6.6.3.5 AppPrivacyKey
6.6.3.6 CryptoRequestKey
6.6.4 Key Management Commands
6.6.4.1 Command ChangeKey
6.6.4.2 Command GetKeySettings
6.6.4.3 Command GetKeyVersion
6.7 Asymmetric Key Management
6.7.1 ECCPrivateKey Management
6.7.1.1 Command ManageKeyPair
6.7.1.2 ECCPrivateKey Key Usage Limit
6.7.1.3 ECCPrivateKey Information Retrieval
6.7.2 CARootKey Management
6.7.2.1 Command ManageCARootKey
6.7.2.2 CARootKey Information Retrieval
6.7.3 PICC/MF level
6.7.3.1 ECCPrivateKey entries
6.7.4 Application/DF level
6.7.4.1 ECCPrivateKey entries
6.7.4.2 CARootKey entries
6.7.5 Memory Consumption
6.7.6 Certificate Cache

Rev. 3.0 — 27 January 2025 Product data sheet 976730

1 General description

A30 is a secure authentication IC for IoT platforms, electronic accessories, and consumable devices such as home electronic devices, mobile accessories, and medical supplies. A30 contains ECC key pairs, which can be generated by the IC itself to make sure that private keys are never exposed outside the IC. Also it performs cryptographic operations for security critical communication and control functions. A30 has Common Criteria EAL 6+ security certification with AVA_VAN.5 on product level [1] and supports a generic Crypto API providing AES, ECDSA, ECDH, SHA, HMAC, and HKDF cryptographic functionality to users. Asymmetric cryptography features support 256-bit ECC over the NIST P-256 and brainpoolP256r1 curves. Symmetric cryptography features support both AES-128 and AES-256. Also it supports PKI-based mutual authentication including certificate handling. The CC security certification ensures that the IC security measures and protection mechanisms have been evaluated against sophisticated noninvasive and invasive attack scenarios. A30 supports an I2C contact interface with two GPIOs. A30 supports a low-power design, and consumes only 5 μA at Halt mode when an external VDD is supplied.

2 Features and use cases

2.1 Use cases

Secure key(s) and certificate(s) storage
PKI (public key infrastructure) based authentication and communication
Device only, device-to-device, device-to-cloud authentication
Secure connection for consumer devices, industrial machines, and medical devices
Battery passport and/or Digital product passport
Device to meet strengthening cybersecurity requirements

2.2 Key features

A30 is designed to support many IoT applications and solves the problems in IoT applications' full life cycle.

ECC key generation on the IC, and provisioning item level certificate(s) in NXP, or in the field.
The following crypto primitives are supported: AES-128/256 (ECB, CBC, CMAC, CCM, GCM), ECDSA, and ECDH over NIST P-256 and brainpoolP256r1, SHA-256/384, HMAC, and HKDF. This allows to support advanced crypto protocols such as SIGMA-I, TLS1.3 and Matter.
Nonreversible monotonic counter as the usage counter
Delivery of the list of UID and certificates at shipping from NXP
I2C target operates at 100 kHz (standard mode), 400 kHz (fast mode), or 1 MHz (Fast-mode Plus)
Two configurable GPIOs; 1 GPIO can be used for power downstream - up to 10 mW for batteryless

applications

1 V operation with 1.5 V battery
Small footprint on PCB with WLCSP16

2.3 Configuration

A30 can be used as an I2C target with Host MCU. aaa-052794 Plug and trust MW Host MCU/MPU Connectivity (WiFi/BLE) Sensor/ actuator Display TLS 1.3 SIGMA-I I2C Crypto APIs Keys Certs RNG I2C Authenticator Figure 1. A30 solution block diagram There are many configuration options to meet different types of applications. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

2.4 Configuration as authenticator

authentication via ECDH, ECDSA, or full SIGMA-I protocol (Section 6.3.2). Figure 2. A30 for the consumable authentication device has been powered up, or used with a nonreversible monotonic counter.

2.5 Configuration to secure IoT applications

A30 can be used for many other IoT applications. and certificates securely, provide one-way and/or mutual authentication, and sign data being transferred. Figure 3. A30 solution block diagram communications, for example, with Matter. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

3 Ordering information

4 Block diagram

5 Pin description

6 Functional description

A30 supports I2C interface with ISO/IEC 7816-4. terms are used to represent NFC inherited authentication architecture.

6.1 I2C support

A30 supports I2C target communication with 7-bit target address according to [15]. depending on the HW configuration.

100 kHz (Standard-mode)
400 kHz (Fast-mode)
1 MHz (Fast-mode Plus) At the data link layer, the T=1’ protocol as specified in [16] is supported. Only the default parameter values are specified here.

6.1.1 I2C parameter values

6.1.1.1 Target address

see Command SetConfiguration.

6.1.1.2 Communication interface parameters

The communication interface parameters (CIP) as defined by [16] are specified in Table 3. Table 3. I2C communication interface parameters A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 3. I2C communication interface parameters...continued SetConfiguration Option 0x14, see Command SetConfiguration.

6.1.2 I2C Application Remarks

6.1.2.1 Power Management

A30 contains an adaptive power management system reducing or stopping internal clocks. stopped. In this case the host will read 'FF' while the internal clock is stopped. This cases will be detected with high probability by the CRC check.

Read IFSC number of bytes to clear before continuing.
Send R-Block CRC Fail to Card

6.1.2.2 Write after Write behavior

6.2 Command format and chaining

6.2.1 Native command format

important to understand the basic format of native commands which consist of the following parts.

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) A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 8 / 209

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. Within this document, the ’0x’ prefix indicates hexadecimal integer notation, i.e. not reflecting the byte order representation on the command interface at all.

6.2.2 ISO/IEC7816-4 communication frame

as outlined in Section 6.2.1 and standard ISO/IEC 7816-4 commands. for the wrapped native commands, this needs to be taken into account. Figure 5. ISO/IEC 7816-4 command response pair Table 4. ISO/IEC 7816-4 command fields A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

supported input size is restricted as specified in the command definition. Table 5. ISO/IEC 7816-4 response fields

6.2.3 Command chaining

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, see Section 7. – Standard ISO/IEC 7816-4 commands: ISOReadBinary, ISOUpdateBinary i.e. every command where a larger frame size can occur.
the PICC 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 must 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 regard 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 and ISOUpdateBinary). In this case, command execution is started before the complete command is received. For single frame write operations or chained frames that fit within the supported FSC it is ensured that either the data is completely written or not at all.

6.3 Authentication and Secure Messaging

6.3.1 Authentication overview

symmetric mutual authentication: this authentication is initiated by AuthenticateEV2First or AuthenticateEV2NonFirst. The protocol is inherited and compatible with NTAG42x and MIFARE DESFire. It is based on AES-128 or AES-256.
asymmetric mutual authentication: this authentication is initiated by ISOGeneralAuthenticate. It is based on 256-bit ECC. Both mutual authentication methods initiate an EV2 secure messaging channel, see Section 6.3.6 based on AES-128 or AES-256 session keys. Each authentication option can be used with different keys and on different I/O interfaces. However, the A30 only supports a single authentication session. The authentication session applies to the I/O interface, which A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 10 / 209

opened it. The other I/O interface has no current authentication session. The current session shall be closed if any of the following occur:

a new mutual authentication is initiated (on either interface)
the NTAG application is selected (on either interface)
the key used to open the session is changed (for symmetric mutual authentication)
the device enters HALT state
the device is reset
the OS processes an erroneous command on the interface, which opened the authentication session The fundamental states as listed below are introduced in Figure 6.
VCState.NotAuthenticated: This is the default state where there is no active authentication. The AuthKey is invalidated in this state. This state is reached after POR and activation.
VCState.PartiallyAuthenticated: In this state, an authentication is ongoing. The A30 is expecting the second part. This means that any previous active authentication has already been lost.
VCState.AuthenticatedAES: there is an active authentication reached by successfully executing the symmetric authentication protocol initiated with AuthenticateEV2First or AuthenticateEV2NonFirst. EV2 Secure Messaging, as defined in Section 6.3.6, is active. The targeted key of the last authentication is remembered as an AuthKey. Depending on these key access rights to subsequent commands may be granted or not.
VCState.AuthenticatedECC: there is an active authentication reached by successfully executing the asymmetric mutual authentication protocol initiated with the ISOGeneralAuthenticate (CLA 0x00, INS 0x86, targeting a Sigma-I protocol). Also here, symmetric AES-based EV2 Secure Messaging, as defined in Section 6.3.6, is active. Access rights in this state depend on the targeted CARootKey and/or reader The transitions to and from those states are related to the secure messaging specification. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 11 / 209

Figure 6. Authentication State Diagram

Failure indicates any error: the A30 switches to the VCState.NotAuthenticated. In these cases the response is already sent with CommMode.Plain (as always in VCState.NotAuthenticated).
If enabled, AWDT2 expiration aborts an ongoing authentication attempt, moving the A30 back from VCState.PartiallyAuthenticated to VCState.NotAuthenticated.
If enabled, AWDT1 expiration aborts an active authentication session, moving the A30 back from VCState.AuthenticatedAES or VCState.AuthenticatedECC to VCState.NotAuthenticated.
The authentication process consists of two parts. If only the first part is received, then any command different from the expected second part results in a failure.
In both, VCState.AuthenticatedAES and VCState.AuthenticatedECC, the same AES-based secure messaging applies.
ChangeAuthKey indicates ChangeKey targeting the currently authenticated key. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 12 / 209

6.3.2 SIGMA-I authentication with ISOGeneralAuthenticate

protocol execution can commence. (or if caching is not supported) then certificate request and reply messages are exchanged. case, the host still needs to send the first command, initiating the message exchange.

6.3.2.1 Session keys

Table 6. SIGMA-I Session Keys

6.3.2.2 Message types

host upon successful authentication. Secure tunnel rules now apply. Table 7. SIGMA-I Message Types...continued [1] cert hash is a hash over the complete certificate including the Signature field.

Abort message is received from the host.
Host certificate chain is syntactically correct but CA root public key can't be located to verify it.
Session key size can't be mutually agreed.

6.3.2.3 Protocol exchange – Host as initiator

83 01 <key sizes supported> (see Table 11). 83 01 <key size selected> (see Table 11). Table 9. A30 as SIGMA-I responder A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 9. A30 as SIGMA-I responder...continued

6.3.2.4 Protocol exchange – Host as responder

Table 10. A30 as SIGMA-I initiator...continued

6.3.2.5 SIGMA-I session key generation

session signature. This is defined by the targeted certificate repository.

Validate the host’s public key
Compute shared secret using ECDH with the private key of the A30 and the public key of the Host.
Select AES session key size (AES-128 or AES-256). This shall be the largest key size mutually supported by both initiator and responder. If no mutually supported key size then the mutual authentication session is aborted with a protocol error. Key size definitions are outlined in Table 11.
Generate session keys and IV used for mutual authentication
Generate session keys used for the secure tunnel b7 b6 b5 b4 b3 b2 b1 b0 Description x x x x x x -- RFU

key. When AES-256 is selected, then the complete 32 bytes shall be used; for AES-128 the derived bytes shall be truncated to the first 16 bytes. i: two-byte iteration counter starting at 1. When AES128 is selected only 0x0001 is used; for AES 256 0x0001 and 0x0002 counter values are used and the output is concatenated. Label: each mutual authentication key to be generated shall have a unique label:

“K_e1”, see Section 6.3.2.1
“K_m1“, see Section 6.3.2.1
“IV_e1”, see Section 6.3.2.1
“K_e2“ for EV2 ENC, see Section 6.3.6
“K_m2“ for EV2 MAC, see Section 6.3.6 Context: “SIGMA-I” for mutual authentication keys, “IVs” for mutual authentication IV or “EV2” for EV2 tunnel session keys L: an integer specifying the output data length:
0x0100 AES-256 key
0x0080 for an AES-128 key
0x0068 for an IV_e1. Note: The CCM nonce N is composed of the 13 leftmost IV_e1 bytes.

6.3.2.6 A30 Signature generation

The A30 generates a unique signature every session, which is sent in an encrypted payload and also includes the leaf certificate hash of thwe A30. Signature generation and subsequent encryption depend on the role assumed by the A30. The private key and associated repository to use are either explicitly stated or the certificate repository with the lowest Id, which supports SIGMA-I shall be used. The signature generation and encryption methodology are as follows. ECDSA-Sign and ECDSA-Verify is ECDSA Digital Signature Generation and Verification as defined in [23]. The hash function to be applied is SHA-256, as specified in NIST FIPS 180-4 [17]. AES-CMAC is according to [7] and AES_CCM is according to [25]. The AES CCM parameters according to the formatting Appendix A from [25] are a 2-byte length field q, a 13-byte nonce n, and an 8-byte tag t. The following parameters are used:

sk_init and sk_resp are the targeted private keys.
keySize_init and keySize_resp are the initiator key sizes supported byte and responder key size selected byte, according to Table 11
xP and yP are respectively the host/initiator’s ephemeral public key and A30/responder’s ephemeral public key
leaf_cert_hash is SHA-256 of the end-leaf certificate of the A30 including the signature.
A (Associated Data from [25]) is optional additional authenticated data (which is not encrypted) and is not applicable for this SIGMA-I implementation.

6.3.2.6.1 A30 as initiator

Init_ECC_Sig = ECDSA-Sign(sk_init , 0x02 || keySize_init || keySize_resp || yP || xP || AES_CMAC(K_m1, 0x02’|| leaf_cert_hash))
Data = leaf_cert_hash || Init_ECC_Sig
C_k_i = AES_CCM_Enc(K=K_e1, N=IV_e1, A=NULL, P=Data) A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 18 / 209

6.3.2.6.2 A30 as responder

Resp_ECC_Sig = ECDSA-Sign(sk_resp, 0x01 || keySize_init || keySize_resp || xP || yP || AES-CMAC(K_m1, 0x01 || leaf_cert _hash))
Data = leaf_cert_hash || Resp_ECC_Sig
C_k_r = AES_CCM_Enc(K=K_e1, N=iv_e1, A=NULL, P=Data)

6.3.2.7 SIGMA-I: Verification of the host

The A30 receives the end-leaf certificate hash and a session ECC signature from the Host. To authenticate the Host, the A30 shall verify the session signature using a trusted public key. The trusted public key can either be a prevalidated key stored in the A30’s certificate cache or a key authenticated through validation of the associated public key certificate. If certificate caching is disabled or the public key isn’t present in the A30’s cache then the A30 shall request the host to provide public key certificates until the certificate chain of the leaf public key can be verified. The maximum depth of a certificate chain is 4, therefore, the A30 shall request up to a maximum of three certificates from the host (leaf, P1 and P2). If the leaf certificate public key of the Host cannot be validated then the authentication session is terminated. Once the public key of the Host is validated, the A30 verifies the signature from the Host as follows. ECDSA- Verify is ECDSA Digital Signature Generation as defined in [23]. The hash function to be applied is SHA-256, as specified in NIST FIPS 180-4 [17]. AES-CMAC is according to [7]. The following parameters are used:

pk_init and pk_resp are the targeted public keys, retrieved from the certificate chain.
sig_init and sig_resp are the received signatures
keySize_init and keySize_resp are the initiator key sizes supported byte and responder key size selected byte, according to Table 11
xP and yP are respectively the A30/initiator’s ephemeral public key and host/responder’s ephemeral public key
leaf_cert_hash is SHA-256 of the host’s end-leaf certificate including the signature. When the host’s session signature is validated, the host is granted the access rights (from ‘0’ to ‘D’) associated with the CA root public key used to validate the host’s certificate chain (or restricted subset as specified in x.509 certificate extension).

6.3.2.7.1 A30 as initiator

ECDSA-Verify(pk_resp, sig_resp, 0x01 || keySize_init || keySize_resp || xP || yP || AES-CMAC(K_m1, 0x01 || leaf_cert_hash))

6.3.2.7.2 A30 as responder

ECC_Verify(pk_init, sig_init, 0x02 || keySize_init || keySize_resp || yP || xP ( || AES-CMAC(K_m1, 0x02 || (leaf_cert_hash)))

6.3.3 ECC-based card-unilateral authentication

A30 supports an ECC-based card-unilateral authentication protocol as described in this section. This allows for authenticating the card without requiring an authentication from the reader side. This protocol can be applied protocol does not open a secure messaging session. The protocol can be executed with ISOInternalAuthenticate. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 19 / 209

As the protocol creates a trace that cannot be repudiated, the privacy implications of enabling the feature should be evaluated.

6.3.3.1 Data structures and notations

6.3.3.1.1 ECCKey pair

The card-unilateral authentication applies a static key pair (Priv.B, Pub.B) from which the private key Priv.B is stored on the card and used by the card during the protocol.

6.3.3.1.2 Certificate

For the protocol, the public key Pub.B to be used by the reader for validating the authenticity of the card, should be authenticated through a certificate or certificate chain. This certificate (chain) can be stored on the card in a FileType.StandardData file and retrieved via the related commands before executing the ISOInternalAuthenticate. For Originality Check purposes, the certificate is trust-provisioned during manufacturing, as described in Section 6.16.1. During the further description of the protocol, the certificate validation is kept out of scope.

6.3.3.2 Cryptographic primitives

6.3.3.2.1 Elliptic Curve Digital Signature Generation and Verification

The card-unilateral authentication is based on the ECDSA Digital Signature Generation and Verification as defined in [12]. The hash function to be applied is SHA-256, as specified in NIST FIPS 180-4[17]. The following notations are used: Sig.B = ECDSASign(Priv.B, M) [true, false] = ECDSAVerify(Pub.B, M, Sig.B) In the above example, B signs the message M with his private key Priv.B, resulting in the signature Sig.B. Sig.B curve, resulting in a 64-byte signature. With ECDSAVerify, the Sig.B is verified to be correct for the message M with the public key Pub.B, resulting in true or false.

6.3.3.3 ISOInternalAuthenticate

The authentication is initiated by ISOInternalAuthenticate. A detailed command definition can be found in Table 48. The protocol can only be executed in VCState.NotAuthenticated and does not change the authentication state. All parameters in the command and response data field are BER-TLV data objects (DOs) encoded according to ISO/IEC7816-4 [3] with DER length encoding. Authentication DOs are collected under the 0x7C tag according to ISO/IEC 7816-4, Table 100. Other parameters use a context-specific tag according to ISO/IEC 8825-1 [18]. All DOs must be sent in the order specified in the command tables. Upon reception of ISOInternalAuthenticate, the PICC checks the ECCPrivateKey addressed by P2 if the key does not exist or is not enabled for ECC-based unilateral authentication, the command is rejected. If the targeted ECCPrivateKey has an enabled KeyUsageCtrLimit that was already reached, see Section 6.7.1.2, the command is also rejected. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 20 / 209

whether the protocol is supported for a specific key. FileType.StandardData files. then also return an OptsB with Tag 0x80.

6.3.3.4 Authentication overview

Identities are not communicated or included in the protocol: – the identity of the card may be extracted from the corresponding certificate. – there is no requirement for knowledge and confirmation of the reader identity by the card. Note that reader’s random sufficiently ensures uniqueness and timeliness, and therefore prevents the returned token to be accepted by other parties.
The references A and B are exchanged to be more aligned with other protocols in this document. An overview of this asymmetric card-unilateral authentication is given in Table 12. The inclusion of a random number generated by the card prevents the reader from having full control on the data that gets “signed” by the card. This is different from a generic ECDSA signature generation as supported with CryptoRequest. PCD PICC Knows:Pub.B The PCD generates a random challenge RndA Knows:Priv.B OptsA || RndA The PICC generates a random RndB: The PICC computes its signature: Sig.B = ECDSASign(Priv.B,0xF0F0[||OptsA]||RndB||RndA) RndB || Sig.B The PCD validates the signature: ECDSAVerify(Pub.B, 0xF0F0[||OptsA]||RndB||RndA, Sig.B)

6.3.4 AES-based Symmetric Authentication

6.3.4.1 Command AuthenticateEV2First

and a command counter, see Section 6.3.6.2, even if multiple authentications are required. Allowed, recommended to use. Table 13. When to use which authentication command two PCDs at the same time and in that way compromise the security. The authentication consists of two parts: AuthenticateEV2First - Part1 and AuthenticateEV2First - Part2. execution of the first part, the PICC aborts the ongoing authentication. rejects answers from the PICC when they don’t have the proper length. crypto operations with CryptoRequest and result in an error. At PICC level, there are no symmetric keys. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

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). If AWDT1 is enabled, see SetConfiguration, the timer is started during AuthenticateEV2First execution. If the timer expires before AuthenticateEV2First - Part2 reception, the authentication attempt is reset and the AuthenticateEV2First - Part2 will be rejected. On successful execution of the authentication protocol, the session keys SesAuthMACKey and and the Secure Messaging is activated. On any failure during the protocol, the PICC ends up in VCState.NotAuthenticated. 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.

6.3.4.2 Command AuthenticateEV2NonFirst

This section defines the Non-First authentication, which is recommended to be used if Secure Messaging is already active, see Table 13. 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 KeyType.AES128 or KeyType.AES256 keys. The authentication consists of two parts: AuthenticateEV2NonFirst - Part1 and AuthenticateEV2NonFirst - Part2. A detailed command definition can be found in Section 7.3.4. This command is rejected if there is no active symmetric authentication. For the rest, the behavior is exactly the same as for AuthenticateEV2First, except for the following differences:

No PCDcap2 and PDcap2 are exchanged and validated.
Transaction Identifier TI is not reset and not exchanged.
Command Counter CmdCtr is not reset.
If the authentication Counter is enabled for authentication counting, it shall not be incremented on Section 7.3.4. After successful authentication, the PICC remains in VCState.AuthenticatedAES. On any failure during the protocol, the PICC ends up in VCState.NotAuthenticated.

6.3.4.3 Session Key Generation

At the end of a valid authentication with AuthenticateEV2First or AuthenticateEV2NonFirst, both the PICC and the PCD generate two session keys for secure messaging, as shown in Figure 7:

SesAuthMACKey for MACing of messages
SesAuthENCKey for encryption and decryption of messages A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 23 / 209

Figure 7. Session key generation for Secure Messaging The session key generation is according to NIST SP 800-108 [9] in counter mode. different order than proposed by the standard as long as it is unambiguously defined.

a 2-byte label, distinguishing the purpose of the key: 0x5AA5 for MACing and 0xA55A for encryption
a 2-byte counter – KeyType.AES128: fixed to 0x0001. – KeyType.AES256: counting from 0x0001 to 0x0002.
a 2-byte length, – KeyType.AES128: fixed to 0x0080. – KeyType.AES256: fixed to 0x0100.
a 26-byte context, constructed using the two random numbers exchanged, RndA and RndB KeyType.AES128 First, the 32-byte input session vectors SVx are derived as follows 1 : with ⊕ being the XOR-operator. Then, the 16-byte session keys are constructed as follows: SesAuthENCKey = PRF(Kx, SV1) 1 Bytes are numbered from rightmost to leftmost i.e. index 0 for the rightmost byte. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 24 / 209

SesAuthMACKey = PRF(Kx, SV2) KeyType.AES256 First, the 32-byte input session vectors SV x are derived as follows: A[7..0] A[7..0] A[7..0] A[7..0] with ⊕ being the XOR-operator. Then, the 32-byte session keys are constructed as follows: SesAuthENCKey = PRF(Kx, SV1a)||PRF(Kx, SV 1b) SesAuthMACKey = PRF(Kx, SV2a)||PRF(Kx, SV 2b)

6.3.5 AuthenticationCounter and Limit

To allow mitigating potential future attack scenarios, symmetric mutual authentications can be configured with a counter and usage limitation. This allows limiting the amount of key computations, and therefore related trace collection for side-channel attacks. Next to attack mitigation, this feature can also be used to limit the usage of a card/device. Potentially, the limit can be increased in the field, e.g. if the end user pays for additional service. The authentication counter and usage limitation are configured through SetConfiguration Option 0x16, by assigning one of the FileType.Counters to this purpose. Once enabled, A30 shall maintain a AuthCtr through the assigned file, for counting the authentications, and if configured also an AuthCtrLimit. This means that the AuthCtr shall be incremented by the following operations, if enabled:

AuthenticateEV2First for AES-based authentication, before the response of the Part 1. If the configured AuthCtrLimit has been reached, the related authentication is disabled. This means that the relevant keys cannot be used anymore, though the key entry can still be updated (and potentially reenabled) if the required authentication to do so can still be gained, e.g. through an asymmetric authentication if symmetric authentication is disabled. If the AuthCtrLimit is disabled, authentications may still be counted. When further updating SetConfiguration Option 0x16, it is possible to disable or change the AuthCtrLimit without affecting the current AuthCtr value. This ensures the monotonic property of the FileType.Counter. When configuring a different file, the authentication counting for the original file is disabled. Putting the limit to a value equal or lower than the current value will immediately disable the authentication. As any other SetConfiguration option, the current authentication counter configuration and AuthCtrLimit can be retrieved with GetConfiguration. For this Option 0x16, also the current AuthCtr value will be returned by GetConfiguration. Enabling the feature may create a denial-of-service risk. It must be assessed from a system-level perspective if this can be accepted. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 25 / 209

6.3.6 EV2/AES secure messaging

The EV2 secure messaging is an AES-based secure messaging, which was introduced in MIFARE DESFire EV2, explaining the naming. The EV2 secure messaging can both be initiated by an ECC-based mutual authentication as defined in

6.3.6.1 Transaction Identifier

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 7.3.3. 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. In the case of ECC-based authentication it is expected that a transaction only consists of a single authentication. As a CARootKey and/or reader certificate can cover multiple access rights, see Section 6.4, there should not be a need to authenticate multiple times. Therefore, in VCState.AuthenticatedECC, the TI is set to all zero bytes.

6.3.6.2 Command Counter

A command counter is included in the MAC calculation for commands and responses 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 0x0000 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 0x0000. In the case of ECC-based authentication, the CmdCtr is also set to 0x0000 after successful authentication, i.e. a ISOGeneralAuthenticate exchange successfully completing SIGMA-I mutual authentication. The CmdCtr is increased between the command and response, for all communication modes. For CommMode.Plain, this is not reflected in the actual command exchange as the CmdCtr is not used. When a MAC on a command is calculated at PCD side that includes the CmdCtr, it uses the current CmdCtr. The CmdCtr is afterward incremented by 1. At PICC side, a MAC appended to 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 nonincreased value is used for the command calculations while the increased value is used for the response calculations. If the CmdCtr holds the value 0xFFFF 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 6.2.3, does not affect the counter. The chained command is considered as a single command, just as for the other aspects of secure messaging, and therefore the related counter is increased only once. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 26 / 209

6.3.6.3 MAC Calculation

MACs are calculated using the underlying block cipher according to the CMAC standard described in [7]. Padding is applied according to the standard. The MAC used in A30 is truncated by using only the 8 even-numbered bytes out of the 16-bytes output as described [7] 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 [7].

6.3.6.4 Encryption

Encryption and decryption are calculated using AES according to the CBC mode of NIST SP800-38a [6]. Padding is applied according to Padding Method 2 of ISO/IEC 9797-1 [8], i.e. by always adding 0x80 followed. If required, by zero bytes until a string with a length of a multiple of 16 byte is obtained. 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 [6] the concatenation of:

a 2-byte label, distinguishing the purpose of the IV: 0xA55A for commands and 0x5AA5 for responses
Transaction Identifier TI
Command Counter CmdCtr (LSB first)
Padding of zeros acc. to NIST SP800-38b [7] This results in the following IVs: IV for CmdData = E(SesAuthENCKey; 0xA5 || 0x5A || TI || CmdCtr || 0x0000000000000000) IV for RespData = E(SesAuthENCKey;5Ah || 0xA5 || TI || CmdCtr || 0x0000000000000000) When an encryption or decryption is calculated, the CmdCtr to be used in the IV are the current values. 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 is 128 bits of 0.

6.3.6.5 Session Key Generation

As an output of a successful authentication, both the PICC and the PCD have generated two session keys for secure messaging:

SesAuthMACKey or KSesAuthMAC for MACing of messages
SesAuthENCKey or KSesAuthENC for encryption and decryption of messages These session keys are generated differently, depending on the authentication:
For ECC-based authentication, this is defined in Section 6.3.2.
For AES-based authentication, this is defined in Section 6.3.4. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 27 / 209

6.3.6.6 Communication Modes

Table 14. Supported communication modes

6.3.6.7 Plain Communication Mode

command specification tables, see Section 7. Figure 8. Plain Communication Mode on any subsequent command that is sent in CommMode.MAC or CommMode.Full.

6.3.6.8 MAC Communication Mode

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

Cmd
Command Counter CmdCtr
Transaction Identifier TI
Command header - CmdHeader (if present)
Command data - CmdData (if present) A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 28 / 209

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 6.3.6.2. 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 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 7). The authentication state is immediately lost and the error return code is sent without a MAC appended. Any other error during the command execution has the same consequences. PICC to PCD aaa-032192 TI TC CmdCtr Cmd C = value of CmdCtr at start of this sequence T = Value of TI (will stay constant) [c] RespData [c] RespData TI TC+1 CmdCtr MACt(SesAuthMACKey, RC || CmdCtr || TI [|| RespData]) MAC(SesAuthMACKey, RC || CmdCtr || TI [|| RespData]) PCD to PICC MAC(SesAuthMACKey, CMD || CmdCtr || TI [|| CmdHeader] [|| CmdData]) Command counter (CmdCtr) incremented after validating the command before sending the response and related MAC calculation MAC Truncation from 16 to 8 byte by use of the even-numbered bytes 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 are 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

6.3.6.9 Full Communication Mode

command execution has the same consequences. Figure 10. Secure Messaging: CommMode.Full

6.3.7 Controller Session Key Usage

I2C ) and prover device (target in I2C ). For example, this can be a host device and consumable parts. messaging, and response processing, i.e. validating the MAC and eventually decrypting. typical use case requires this only over the I2C interface.

6.3.7.1 ProcessSM

ProcessSM_Apply: applying secure messaging to a command.
ProcessSM_Remove: removing secure messaging from a response. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 30 / 209

The overall command format is outlined in Section 7.3.5 while the two variants are further detailed in the following subsections. While the ProcessSM is issued in VCState.AuthenticatedECC, the command itself is not protected by the regular secure messaging. This means both the command and response are issued in plain, just applying the secure messaging to the command and response data to support controller device processing. Once enabled, there is no additional access control to the ProcessSM command. Therefore, it must be assessed at system level if the access to the command can be abused.

6.3.7.2 ProcessSM_Apply

The ProcessSM_Apply is used for applying secure messaging to a command before sending it to the target device. The command format is outlined in Section 7.3.6. If targeting CommMode.Plain, there is no command data exchanged.A30 increments the CmdCtr by the amount given in CmdCtrIncr. If CmdCtr would reach 0xFFFF or overflow, the command is rejected. If targeting CommMode.MAC or CommMode.Full, Plaintext provides the data to be protected. ProcessSM_Apply only supports one-shot operations fitting in a single short-length ISO/IEC 7816-4 APDU. Bigger lengths are rejected. The data provided and returned by A30 does not hold the ISO/IEC 7816-4 APDU wrapping overhead. This means the native command fields, as described in Section 6.2.1 consisting of Cmd (i.e. the ISO/IEC 7816-4 INS field) followed by eventually CmdHeader and CmdData fields (i.e.the full ISO/IEC 7816-4 Command Data field). If targeting CommMode.Full, an additional parameter Offset indicates where the encryption shall start, i.e.the first byte of CmdData. If targeting CommMode.MAC, only the computed MAC is returned. If targeting CommMode.Full, the encrypted data is returned together with the computed MAC. Other plain data like the Cmd and CmdHeader are not echoed.

6.3.7.3 ProcessSM_Remove

The ProcessSM_Remove is used for removing and validating secure messaging from a response received from a target device. The command format is outlined in Section 7.3.7. If targeting CommMode.Plain, the command must not be called as the only relevant processing (CmdCtr), is triggered with ProcessSM_Apply. If targeting CommMode.MAC or CommMode.Full, Ciphertext provides the data to be processed. Note that ProcessSM_Remove only supports one-shot operations fitting in a single short-length ISO/IEC 7816-4 APDU. Bigger lengths are rejected. The data provided and returned by A30 does not hold the ISO/IEC 7816-4 APDU the ISO/IEC 7816-4 SW2 field) followed by eventually RespData and the MAC (i.e. the full received ISO/IEC 7816-4 Response Data field). In CommMode.Full, RespData is the encrypted response data. If targeting CommMode.MAC, no data is returned. If targeting CommMode.Full, the decrypted data is returned. The RC is not echoed.

6.3.8 Secure Dynamic Messaging

The Secure Dynamic Messaging (SDM) allows for confidential and integrity-protected data exchange, without requiring a preceding authentication. A30 supports SDM for reading from one of the StandardData files on the PICC. Secure Dynamic Messaging allows adding security to the data read, while still being able to access it with standard NDEF readers. The typical use case is an NDEF holding a URI and some metadata, where SDM allows this metadata to be communicated confidentiality and integrity protected toward a back end server. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 31 / 209

When using SDM, residual risks coming with the Secure Dynamic Messaging for Reading have to be taken into account. As SDM allows free reading of the secured message, i.e. without any up-front reader authentication, anybody can read out the message. This means that also a potential attacker is able to read out and store one ore multiple messages, and play them at a later point in time to the verifier. If this residual risk is not acceptable for the system’s use case, one of the authentication protocols (using challenge response protocol) and subsequent secure messaging should be applied. This would require using an own application and operating outside a standard NDEF read operation. Other risk mitigation may be applied for SDM to limit the residual risk, without completely removing it:

Track SDMReadCtr per tag at the verifying side. Reject SDMReadCtr values that have been seen before or that are played out-of-order. This is a minimum requirement that any verifier should implement.
Limit the time window of an attacker by requiring tags to be presented regularly (e.g. at least once a day) in combination with the previous mitigation.
Read out the SDM-protected file more than once. This does not protect against attackers that have read out the valid tag also multiple times and play the received responses in the same sequence. A30 supports two modes for integrity protection and authentication of the data: A30 supports two modes for integrity protection and authentication of the data:
symmetric SDMMAC, where the data is protected by a Message Authentication Code, which is generated by
asymmetric SDMSIG, where the data is protected by a Signature, which is generated with the private key of management towards e.g. reader infrastructure as no secret key is required for the signature validation. Encryption is always based on symmetric cryptography, as specified in Section 6.3.8.4 for PICCData like the UID and Section 6.3.8.7 for generic file data (SDMENCFileData). The session key derivation for symmetric keys (be it for encryption or MACing) is outlined in Section 6.3.8.12. SDM is enabled and configured with ChangeFileSettings, see Section 6.10.2.3. Access right related aspects are defined in Section 6.10.2.1.

6.3.8.1 SDM Read Counter

To allow replay detection by the party validating the data read, a read counter is associated with the file for which Secure Dynamic Messaging is enabled. SDMReadCtr is a 24-bit unsigned integer. The SDMReadCtr is reset to 0x000000 when enabling SDM with ChangeFileSettings. In cryptographic calculations and represented with binary encoding on the external interface, the SDMReadCtr is represented LSB first. When represented with ASCII encoding on the contactless interface, it is represented MSB first. This is in line with the NFC counter representation in [13]. In not Authenticated state, the SDMReadCtr is incremented by 1 before calculating the response of the first read command, ReadData or ISOReadBinary, if successful. On subsequent read commands targeting the same file, the SDMReadCtr is not increased, and the current value is used. As soon as a different command has been received, the counter is incremented again on a subsequent read command. Also when varying between ReadData and ISOReadBinary, the counter is incremented on each first instance of the read command type. The SDMReadCtr is not incremented when authenticated. If the SDMReadCtr reaches the SDMReadCtrLimit (see Section 6.3.8.2) or the value 0xFFFFFF (if SDMReadCtrLimit is not enabled) and a first read command arrives at the PICC, an error is being returned. Command chaining, see Section 6.2.3, does not additionally affect the counter increase. The chained command is considered as a single command. SDMReadCtr can be retrieved via the mirroring as part of the PICCData, see Section 6.3.8.3, or it can be retrieved via GetFileCounters. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 32 / 209

6.3.8.2 SDM Read Counter Limit

Limit the number of usages from the card side. Typically this can also be controlled from the back end verifying the SDM for Read protected message.
Limit the number of traces that can be collected on the symmetric crypto processing. This way the attack potential via side-channel attacks can be further reduced. The number of reads that can be executed for an SDM configured file can be limited by setting an SDM Read Counter Limit (SDMReadCtrLimit). This is an unsigned integer of 3 bytes, related with SDMReadCtr. On the interface, the SDMReadCtrLimit is represented LSB first. The SDMReadCtrLimit can be enabled by setting a customized value with ChangeFileSettings. It can be retrieved with GetFileSettings. Once the SDMReadCtr equals the SDMReadCtrLimit, no reading of the file with ReadData or ISOReadBinary in not authenticated state can be executed. If authenticated, reading is always possible even if SDMReadCtrLimit is reached, applying the regular secure messaging. If the SDMReadCtrLimit is disabled with ChangeFileSettings, this is also equivalent to putting it to the maximum value: 0xFFFFFF.

6.3.8.3 PICCData

The PICCData holds metadata of the targeted PICC and file, consisting of the UID and/or the SDMReadCtr. PICCData is plain and is defined according to Table 15. Table 15. PICCData: plain encoding and lengths ciphertext will be ASCII encoded. The PICCData is mirrored within the file. This is configured with ChangeFileSettings via the related offsets.

UIDOffset configures the UID mirroring position. It is only given if UID mirroring is enabled.
SDMReadCtrOffset configures the SDMReadCtr mirroring position. It is only given if SDMReadCtr mirroring is enabled. It is possible to enable the SDMReadCtr but without mirroring by putting SDMReadCtrOffset to 0xFFFFFF. In this case, it can be retrieved with the GetFileCounters command. If UID and SDMReadCtr are mirrored within the file, they shall not overlap:
UIDOffset ≥ SDMReadCtrOffset + SDMReadCtrLength OR SDMReadCtrOffset ≥ UIDOffset + UIDLength. In the case of encrypted mirroring (i.e. SDMMetaRead = 0x0..0x4), PICCDataOffset configures the PICCData A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 33 / 209

regular secure messaging is always applied on the static file data. With A30, PICCData is always ASCII encoded. and writing “x” (0x78) in the static file data.

6.3.8.4 Encryption of PICCData

mirrored, together with the length of the UID if mirrored, as defined in Table 16. Table 16. PICCDataTag The format of the plain text is: PICCDataTag [ || UID] [|| SDMReadCtr]. the actual plain text input. The random padding is generated for the response of the first read command, ReadData or ISOReadBinary. command. Also when varying between ReadData and ISOReadBinary, fresh random padding is generated.

6.3.8.4.1 AES mode encryption

PICCData = E(SDMMetaReadKey; PICCDataTag [ || UID ] [ || SDMReadCtr ] || RandomPadding) with PICCDataTag as defined in Section 6.3.8.3, and RandomPadding being a random byte string generated by the PICC to make the input 16 bytes long. Because of the ASCII encoding, the required placeholder length doubles.

6.3.8.5 GPIOStatus

When one of the GPIO pins is configured for input, see Section 6.13, or tag tamper detection, see Tag Tamper Protection, with SetConfiguration 0x11, see Section 6.3.8.5, it is possible to mirror the statuses within the NDEF file. The GPIO statuses are encoded on a 3-byte string, identical as the ReadGPIO response, see Section 6.10.2.3 and especially Table 254. They can be mirrored in plain or encrypted. For the latter, GPIOStatus needs to be positioned within the place- holder for the plain data that serves as input for SDMENCFileData, see Section 6.3.8.6. In this case, the static file data is replaced by the dynamic statuses before applying the encryption. Note however, that either all status bytes are plain, or all are encrypted. As the status bytes are already ASCII encoded, no ASCII encoding must be applied on top, and only a 3-byte placeholder is required. Where the status is mirrored within the file, is configured with ChangeFileSettings, see Section 6.10.2.3 via GPIOStatus. The restrictions on this offset shall be that it may not be overlapped with any PICCData mirrored or with the SDMMAC. If the GPIOStatus is mirrored within the file, the mirroring shall always be applied in VCState.NotAuthenticated, independently of whether Secure Dynamic Messaging applies. This means it will also be applied if VCState.AuthenticatedAES or VCState.AuthenticatedECC, no mirroring is done, i.e. the regular secure messaging is always applied on the static file data.

6.3.8.6 SDMENCFileData

SDM for Reading supports mirroring (part of the) file data encrypted. This part is called the SDMENCFileData. If the SDMFileRead access right is configured for an application key, part of the file data can optionally be encrypted as defined in Section 6.3.8.7 when being read out in not authenticated state. In this case, the input plaintext for the encryption is always in binary encoding, while the output ciphertext is ASCII encoded. If authenticated, no Secure Dynamic Messaging is applied, i.e. the regular secure messaging is always applied on the static file data. The SDMENCFileData (if any) is always mirrored within the file. This is configured with ChangeFileSettings, see Section 7.8.7 via SDMENCOffset and SDMENCLength. If the SDMFileRead access right is disabling Secure Dynamic Messaging for reading (i.e. set to 0xF), SDMENCOffset and SDMENCLength are not present in ChangeFileSettings. If PICCData is mirrored within the file, SDMENCFileData shall not overlap with it. Depending on what is exactly mirrored, the following holds:

SDMENCOffset ≥ PICCDataOffset + PICCDataLength OR PICCDataOffset ≥ SDMENCOffset + SDMENCLength.
SDMENCOffset ≥ UIDOffset + UIDLength OR UIDOffset ≥ SDMENCOffset + SDMENCLength.
SDMENCOffset ≥ SDMReadCtrOffset + SDMReadCtrLength OR SDMReadCtrOffset ≥ SDMENCOffset + SDMENCLength. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 35 / 209

It is ensured that SDMENCOffset + SDMENCLength is smaller than or equal to the file size. As the SDMMAC is as well mirrored into the file, additional conditions apply, see Section 6.3.8.8. The SDMENCLength is a multiple of 32 bytes for the ASCII encoding. With A30, only ASCII encoding is supported.

6.3.8.7 Encryption of SDMENCFileData

The key applied for the encryption is a session key SesSDMFileReadENCKey derived from the application key defined by the SDMFileRead access right as specified in Section 6.3.8.12. From the user point of view, the SDMENCOffset and SDMENCLength define a placeholder within the file where the plain data is to be stored when writing the file. For ASCII encoding, only the first half of the placeholder is used for storing the plain data. The second half is ignored for constructing the returned data when reading with SDM. For example, if targeting to encrypt 2 AES blocks, i.e. 32 bytes, a placeholder of 64 bytes is reserved via SDMENCOffset and SDMENCLength. The first 32 bytes hold the plaintext, and the next 32 bytes are ignored when reading with Secure Dynamic Messaging.

6.3.8.7.1 AES mode encryption

Encryption and decryption of the SDMENCFileData are calculated using the underlying block cipher according to the CBC mode of NIST SP800-38a [6]. A30 supports AES-128 and AES-256 as the underlying block cipher depending on the key type of the SDMFileReadKey. The following IV is applied: IV = E(SesSDMFileReadENCKey; SDMReadCtr||0x00000000000000000000000000) with SDMReadCtr LSB first. For applying SDM with ASCII encoding, the SDMENCFileData is defined as follows: SDMENCFileData = E(SesSDMFileReadENCKey; StaticFileData[SDMENCOffset:: SDMENCOffset + SDMENCLength=2 - 1]) with StaticFileData being the current file data as written in the placeholder. The file configuration ensures via SDMENCLength that the input is a multiple of 16 bytes, so no padding is applied. It is possible via the read command parameters to read-only part of the file. If the SDMENCFileData is partially read as per the issued offset and length, a truncated part of the ciphertext is returned. As truncation might happen in the middle of an AES block. This means subsequent read commands to fetch the remainder of the file might be required to be able to decrypt.

6.3.8.8 SDMMAC

SDM for Reading supports calculating a MAC over the response data. This message authentication code is called the SDMMAC. If FileAR.SDMFileRead is configured for an application key, and FileAR.SDMFileRead2 is set to 0xF, a MAC is calculated as defined in Section 6.3.8.9 when being read out in no authenticated state. The SDMMAC is to be mirrored within the file via SDMMACOffset. This is configured with ChangeFileSettings, see Section 7.8.7. If SDMMAC is mirrored within the file, it is limited to start only after SDMENCFileData, i.e. SDMMACOffset ≥ SDMENCOffset + SDMENCLength. The SDMMACInputOffset must ensure that the complete SDMENCFileData is included in the MAC calculation. As the mirrored SDMMAC is ASCII encoded, the output size doubles to 16 bytes. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 36 / 209

It is ensured that SDMMACOffset + SDMMACLength is smaller or equal than the file size. If authenticated, no Secure Dynamic Messaging is applied and the placeholder data at SDMMACOffset is not replaced, i.e. the regular secure messaging is always applied on the static file data. The SDMMACInputOffset defines from which position in the file the MAC calculation starts. If SDMMAC is mirrored within the file, SDMMACInputOffset must be smaller than or equal to SDMMACOffset. MACing is mandatory if the SDMFileRead access right is configured for an application key. If the SDMFileRead access right is disabling Secure Dynamic Messaging for reading (i.e. set to 0xF), SDMMACOffset and SDMMACInputOffset are not present in ChangeFileSettings. With A30, only ASCII encoding is supported. SDMMAC is always mirrored within the file.

6.3.8.9 MAC Calculation

The key applied for the MAC calculation is a session key SesSDMFileReadMACKey derived from the application key defined by the SDMFileRead access right, as specified in Section 6.3.8.12.

6.3.8.9.1 AES mode MAC calculation

The 8-byte SDMMAC is calculated using AES according to the CMAC standard described in NIST Special Publication 800-38b [7] applying the same truncation as the AES mode secure messaging, see Section 6.3.6.3. A30 supports AES-128 and AES-256 as the underlying block cipher depending on the key type of the SDMFileReadKey. The SDMMAC is defined as follows: SDMMAC = MACt (SesSDMFileReadMACKey; DynamicFileData[SDMMACInputOffset ... SDMMACOffset - 1]) with DynamicFileData being the file data as how it is put on the contactless interface, i.e. replacing any placeholders by the dynamic data.

6.3.8.10 SDMSIG

If FileAR.SDMFileRead2 is configured for an application ECCPrivateKey, a signature, called SDMSIG, is ECCPrivateKey does not exist or is not enabled for ECC-based Secure Dynamic Messaging (via its key policy or if KeyUsageCtrLimit was already reached, see Section 6.7.1.2), the read command is rejected. The offsets for signature input and signature mirroring are configured with ChangeFileSettings, see Section 6.10.2.3. As to a large extent the same rules apply, parameters SDMMACOffset and SDMMACInputOffset are reused. This means that the SDMSIG is to be mirrored within the file via SDMMACOffset. It shall be limited to start only after SDMENCFileData, i.e. SDMMACOffset ≥SDMENCOffset +SDMENCLength. The SDMMACInputOffset must ensure that the complete SDMENCFileData is included in the signature calculation. The SDMSIGLength is128 bytes, as only ASCII encoding is supported. It shall be ensured that SDMMACOffset + SDMSIGLength is smaller or equal than the file size. Also here, if authenticated, no Secure Dynamic Messaging is applied and the placeholder data at SDMMACOffset is not replaced, i.e. the regular secure messaging is always applied on the static file data. The SDMMACInputOffset defines from which position in the file the input for the signature calculation starts. With A30, only ASCII encoding is supported. SDMSIG shall always be mirrored within the file. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 37 / 209

6.3.8.11 Signature Calculation

The key applied for the signature calculation is the ECCPrivateKey defined by FileAR.SDMFileRead2. The SDMSIG is calculated using ECDSA Digital Signature Generation as defined in [12]. The hash function to be applied is SHA-256, as specified in NIST FIPS 180-4[17]. SDMSIG is defined as follows: SDMSIG= ECDSASign(Priv.x, DynamicFileData[SDMMACInputOffset..SDMMACOffset− 1]) with DynamicFileData being the file data as how it is put on the external interface, i.e. replacing any placeholders by the dynamic data.

6.3.8.12 SDM Session Key Generation

For Secure Dynamic Messaging for reading, the following session keys are calculated:

SesSDMFileReadMACKey for MACing of file data.
SesSDMFileReadENCKey for encryption of file data The session key generation is according to NIST SP 800-108 [9] in counter mode. The pseudo-random function applied during the key generation is the CMAC algorithm described in NIST Special Publication 800-38b [7]. The key derivation key is the SDMFileReadKey as configured with the SDMFileRead access right.

6.3.8.12.1 AES mode session key generation for SDM

The input data is constructed using the following fields as defined by [9]. NIST SP 800-108 allows defining a different order than proposed by the standard as long as it is unambiguously defined.

A 2-byte label, distinguishing the purpose of the key: 0x3CC3 for MACing and 0xC33C for encryption.
A 2-byte counter – KeyType.AES128: fixed to 0x0001. – KeyType.AES256: counting from 0x0001 to 0x0002.
A 2-byte length, – KeyType.AES128: fixed to 0x0080. – KeyType.AES256: fixed to 0x0100.
A context, constructed using the UID and/or SDMReadCtr, followed by zero-byte padding if needed. Whether or not the UID and/or SDMReadCtr are included in session vector SV2, depends on whether they are Therefore, they are always included in SVx. KeyType.AES128 First, the input session vectors SVx are derived as follows: SV1 = 0xC3 || 0x3C || 0x00 || 0x01 || 0x00 || 0x80 || UID || SDMReadCtr SV2 = 0x3C || 0xC3 || 0x00 || 0x01 || 0x00 || 0x80 [ || UID] [ || SDMReadCtr] [ || ZeroPadding] Padding with zeros is done up to a multiple of 16 bytes. So, in case of 7-byte UID and both elements are mirrored, no padding is added. Then, the 16-byte session keys are constructed as follows: SesSDMFileReadENCKey = MAC(SDMFileReadKey; SV1) SesSDMFileReadMACKey = MAC(SDMFileReadKey; SV2) A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 38 / 209

6.3.8.13 Output Mapping Examples

The following figure shows an example with the static file content and how it will be read. Figure 11. Secure Dynamic Messaging for Reading example

6.4 Access Rights Management

can be granted through certificates presented during asymmetric authentication is explained in Section 6.4.3.

6.4.1 Access conditions

Section 6.10.2. For other commands, the access conditions are either fixed or configurable via other means. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

The authentication access conditions where a valid authentication is required. The access condition is satisfied by one of the following means: – an active symmetric authentication with the AuthKey addressed by the key number encoded by the access condition. – an active asymmetric authentication granting the access condition via the current CertAccessRights. This means the CARootKey addressed during the authentication must have been associated with access rights encoded by the access condition. How a CARootKey is configured with its access rights is defined in Section 6.4.2. Optionally the reader certificate (or certificate chain) presented during the authentication can further restrict the granted access rights from the CARootKey. This is specified in Section 6.4.3.
The free access over I2C condition meaning the related commands can be accessed without an active authentication over the I2C interface.
The free access condition meaning the related commands can be accessed without an active authentication over any interface.
The no access condition meaning no access to the related commands. Note: In other parts of the document, when it is stated that an active authentication with AppKey is required, this means either a symmetric authentication with that particular key, or an asymmetric authentication granting equivalent access rights (even if the latter is not explicitly mentioned). The access conditions are specified on 4 bits as defined in Table 17. Condition value Description 0x0..0xB authentication required 0xC authentication required over I2C 0xD free access over I2C 0xE free access 0xF no access or RFU

Table 17. Access condition values coded on 4 bits from an ECC-based authentication. independently of the interface. CARootKey.1, only grants access right 0x5, and therefore in that case not the AppMasterKey access rights. symmetric key 0x0 until 0xD. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

access right is not configured for CARootKey.1. Figure 12. Access conditions example

6.4.2 CARootKey access rights

Bit 13-0 AC bitmap. If bit 0 is set, AC 0x0 access rights are granted. If bit1 is set, AC 0x1 access are rights granted. And so on. Table 18. ACMap encoding there does not exist an equivalent symmetric key within the application. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

defined in Section 6.4.3. There the same encoding is used.

6.4.3 Certificate access rights

are inherited from the parent certificate, or in the case of no parent, the targeted CARootKey. maintained as long as in VCState.AuthenticatedECC.

1 Tag specifying the type of ARG

Table 19. Application access rights, specified via DFName that application, as further defined in Table 18. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

DFNameLen 1 0x01.. 0x10 Length of the subsequent DFName of the application. This shall be set to 0x07 for A30. Table 20. Application access rights, specified via DFName

6.5 Card Memory and Configuration Management

6.5.1 Card Version

HW type 1 Hardware platform type. HW subtype 1 Hardware platform subtype. HW major version number 1 Hardware platform major version number. HW minor version number 1 Hardware platform minor version number. HW storage size 1 Hardware platform storage size. See Table 93 for actual values. HW protocol 1 Hardware communication protocol type. Vendor ID 1 Card vendor identification. SW type 1 Card software type. SW subtype 1 Card software subtype. SW storage size 1 Card Software storage size. See Table 97 for actual values. SW protocol 1 Card Software communication protocol type. Table 21. Manufacturer characteristics used as card version A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Batch number 3 Fabkey server batch number. Fab ID [1] Fab Identifier, only present if requested via Option byte. Table 21. Manufacturer characteristics used as card version...continued independent of the Random ID configuration, and of whether there is an active authentication.

6.5.1.1 Command GetVersion

No parameters are passed with this command. command can be found in Section 6.3.

6.5.2 Card configuration

6.5.2.1 Command SetConfiguration

command consists of an option byte and a data field with a size depending on the option. associated configuration is left as it is already in the card and its value is not changed. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Description

0x00 .. 0x03 Reserved Total: 2 SecureMessaging Configuration

1 Secure messaging configuration (Byte A)

EV2 secure messaging configuration for FileType.StandardDataBit 2 0:No change 1: In VCState.AuthenticatedAES and VCState.AuthenticatedECC, disable chained writing with WriteData in CommMode.MAC and CommMode.Full. SMConfigA Bit1-0 Reserved

1 Secure messaging configuration (Byte B)

0x05 .. 0x0F Reserved Total: 4 I2C Management

1 I2C Support

0: I2C disabled I2CSupport Bit 0 1: I2C enabled (default) 0x10 I2CAddress 1 The address used for the I2C target (default 0x20) ProtocolOptions 2 The crypto protocols supported over I2C. See Table 23. The default value is that all protocols supported in the manufacturing features selection map are enabled and Protocol Negotiations disabled. Total: 28 GPIO Management GPIO1 Mode 0x00: disabled (default) 0x01: input 0x02: output 0x03: input tag tamper GPIO1Mode 1 0x04: down-stream power out GPIO1Config 1 GPIO1 Configuration, see Table 24. GPIO1PadCtrl 4 GPIO1 Pad Control, see Table 25. GPIO2 Configuration 0x00: disabled (default) 0x11 0x01: input GPIO2Mode 1 0x02: output Table 22. SetConfiguration options list A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

GPIO2Config 1 GPIO2 Configuration, see Table 24. GPIO2PadCtrl 4 GPIO2 Pad Control, see Table 25. Note: Notification is only allowed if GPIO1Mode is 0x02. GPIO notification on authentication. Note: Notification is only allowed if GPIO2Mode is 0x02.

1 ManageGPIO access condition

Bit 5-4 CommMode, see Table 14. Bit 3-0 AccessCondition Value, see Table 17. Default 0xF.

1 ReadGPIO access condition

Bit 5-4 CommMode, see Table 14. Bit 3-0 AccessCondition Value, see Table 17. Default 0xF. 0x00: disable in rush current limit. Table 22. SetConfiguration options list...continued A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

of current when charging an external capacitor. 0x00: disable in rush current limit. 0x0000.. 0xFFFF: targeted duration in ms. when supplying power harvesting.

1 ManageKeyPair access condition

Bit 5-4 CommMode, see Table 14. Default ’11’. Bit 3-0 AccessCondition Value, see Table 17. Default 0x0.

1 ManageCARootKey access condition

Bit 5-4 CommMode, see Table 14. Default ’11’. Bit 3-0 AccessCondition Value, see Table 17. Default 0x0.

1 Feature Selection

1 ManageCertRepoCreate Option (’00’) Access Condition

Bit 5-4 CommMode, see Table 14. Default ’10’. certificate repository access conditions are set during repository creation. exits the Halt state. It is reset by command reception on I2C. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

1 CryptoAPI Support

1 Access condition for CryptoRequest

Bit 5-4 CommMode, see Table 14. Default CommMode.MAC. Bit 3-0 AccessCondition Value, see Table 17. Default 0x0. 1 Access condition for ChangeKey targeting CryptoRequestKey. Bit 3-0 AccessCondition Value, see Table 17. Default 0x0.

1 Authentication counter options

1 Wake-up options (Byte A)

GPIOwake-up: GPIO2 pulldown triggers wake-up.

1 Wake-up options (Byte B)

to wake up when SDA is pulled down. wake-up address, wake-up is triggered. cycles, wake-up are triggered. theRF field, while the device is in HALT state.

1 HALT options

’0’: disabled ’1’: enabled (default) 0x18 .. 0xFD RFU Total: 1+N*2 Defer Configurations DeferralCount (N)DeferralCount 1 0x01..0x03 0xFE DeferralList N*2 List of Deferrals. See Table 1. Total: 3 Lock Configurations

3 Bitmap where each bit encodes for the related configuration option if it is

locked. LSB first, i.e. first byte encodes Option 0x07-0x00. Lock bit ’0’: No Change 0xFF LockMap Bit 23-0 ’1’: Lock configuration

1 ProtocolOptions (Byte A)

Controller session key usage, see Section 6.3.7 ’0’: Disabled (default) Bit 7 ’1’: Enabled Bit 6-4 RFU Bit 3 Reserved ECC-based Card-Unilateral authentication (ISOInternalAuthenticate) ’0’: Disabled Bit 2 ’1’: Enabled (default) Bit 1 Reserved AES-based Symmetric authentication (AuthenticateEV2First, AuthenticateEV2Non First) ’0’: Disabled ProtocolOptionsA Bit 0 ’1’: Enabled (default) Table 23. ProtocolOptions A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

1 ProtocolOptions (Byte B)

Enable SIGMA-I Verifier for host(ISOGeneralAuthenticate with P1=0x01where host acts as initiator, i.e. starts with 0xA0 message) ’0’: Disabled Bit 4 ’1’: Enabled (default) Enable SIGMA-I Prover for host (ISOGeneralAuthenticate with P1=0x01where host acts as responder, i.e. starts with 0xB0 message) ’0’: Disabled Bit 3 ’1’: Enabled (default) Secure Tunnel variant after SIGMA-I authentication (ISOGeneralAuthenticate with P1=0x01) Bit 2 ’0’: NTAG EV2 secure messaging Secure Tunnel strength for SIGMA-I authentication (ISOGeneralAuthenticate with P1=0x01) ’0’: AES-256 not supported Bit 1 ’1’: AES-256 supported (default) Secure Tunnel strength for SIGMA-I authentication (ISOGeneralAuthenticate with P1=0x01) ’0’: AES-128 not supported ProtocolOptionsB Bit 0 ’1’: AES-128 supported (default) Table 23. ProtocolOptions...continued

1 GPIOx Configuration

[ifGPIOxMode is output (0x02 or 0x05)] Bit 7-1 RFU Initial state after power-off cycle 0:Low (i.e. equivalent to after CLEAR operation with ManageGPIO) Bit 0 1:High (i.e. equivalent to after SET operation with ManageGPIO) - [elseif GPIOxMode is down-stream power out (0x04)] Bit 7-2 RFU I2C Support 0: disabled Bit 1 1: enabled - [else] GPIOxConfig Bit 7-0 RFU

1 GPIOx Pad Control (Byte A)

Bit1-0 DebounceFilter value: the 2 MS bits of the 10 bit debounce filter value.

1 GPIOx Pad Control (Byte B)GPIOxPadCtrlB

Bit7-0 Debounce Filter value (Resolution = 0.1 μs): the LS 8 bits of the 10 bit debounce filter value. Bit 0 is the LSB. Writing a value of 1 filters out glitches less than 0.1 μs. Writing a value of 1000 (over the10 bits) filters out glitches less than 100us

1 GPIOx Pad Control (Byte C)

0:Disable debounce filter Bit 2 1:Enable debounce filter of min.5us/max.60us Input filter selection 00: unfiltered input selected, (filter of 50 ns selected but has no effect) 01: unfiltered input selected, (filter of 10 ns selected but has no effect) 10: ZIF filtered input selected, filter of 50 ns selected GPIOxPadCtrlC Bit1-0 11: ZIF filtered input selected, filter of 10 ns selected Table 25. GPIOxPadCtrl A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

1 GPIOx Pad Control (Byte D)

Table 25. GPIOxPadCtrl...continued messaging-dependent structure of the command can be found in Section 6.3.

required authentication is not active. Options 0x0F and 0x10 configure the communication interfaces of the product, and what cryptographic protocols are available over each interface. Extreme care must be taken when configuring these options as e.g.disabling both interfaces makes the product unusable. Also, option 0x10 does not check the provided I2CAddress against reserved addresses as specified in [15]. Option 0x11 allows for configuring the GPIO pins and related access conditions for further managing and/or reading them, see also Section 6.13. Values related to specific modes are not checked for consistency. This means it is the user responsibility to provide a meaningful configuration. Even if not applicable for the configured mode, the provided values are stored and returned by GetConfiguration. A change in the GPIO configuration is guaranteed after the next power-off reset. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 54 / 209

Option 0xFF allows deferring some configurations, see Deferred Configuration Options. bit to 0 does not change the current state.

6.5.2.2 Command GetConfiguration

returned. If a policy has not been configured explicitly, the default value of 0xFFFF is returned. The GetConfiguration is rejected at the PICC level. CommMode.Full, requiring AppMasterKey access rights.

6.5.2.3 Memory management

The nonvolatile memory available for user data is allocated in blocks of 32 bytes. Table 26. Supported memory configurations completed a successful execution. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

6.5.2.3.1 Free Memory with Command FreeMem

The available free user memory on the card is returned with FreeMem as defined in Section 7.4.1. No parameters are passed with this command. The memory size in bytes available is returned as an unsigned integer. command can be found in Section 6.3.

6.6 Symmetric Key Management

6.6.1 Key Types

A30 supports symmetric key types as defined in Table 27. As shown in the table, the different key types are represented by two bits. Table 27. Supported key types This representation is used at several places in the document.

6.6.2 Key Versioning

version of any addressable symmetric key can be read using GetKeyVersion.

6.6.3 Symmetric Keys

These roles and other key related configurations are defined via the key settings, see Section 6.6.3.2. Table 28. Keys at application level A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 28. Keys at application level...continued

6.6.3.1 AppMasterKey

The AppMasterKey always has the key number 0x00. ChangeKey. When changing the key type of the AppMasterKey, the key type of all AppKeys change. AppMasterKey itself with the ChangeKey command.

6.6.3.2 AppKey

The application of the A30 includes 5 application keys with key numbers 0, 1, 2, 3, 4. KeyType.AES128, or they can be set via trust provisioning, see Section 6.16.3. The AppKeys are changeable with ChangeKey with an active authentication with AppMasterKey. personalization, even if not all keys are used in the application.

6.6.3.3 SDMMetaReadKey

As the SDMMetaReadKey refers to an AppKey, it is available for authentication.

6.6.3.4 SDMFileReadKey

6.6.3.5 AppPrivacyKey

The AppPrivacyKey is the AppKey identified by the key number specified with SetConfiguration Option 0x0E if this feature is enabled. Once enabled, authentication with this AppPrivacyKey is required for GetCardUID.

6.6.3.6 CryptoRequestKey

The CryptoRequestKeys can be used for generic cryptographic operations. An CryptoRequestKey is a KeyType.AES128 or KeyType.AES256 key. The CryptoRequestKeys are changeable with ChangeKey according to the ChangeAC configuration of SetConfiguration Option 0x15. By default, an active authentication with AppMasterKey is required. When changing the key, the key type is defined, i.e. KeyType.AES128 or KeyType.AES256, and potential restrictions on the usage are specified through the given KeyPolicy. At delivery, by default, this KeyPolicy is set to 0x0000, i.e. disabling the key for any functionality. The CryptoRequestKeys are not available for authentication.

6.6.4 Key Management Commands

This section gives the overall description of the key management commands as most of them apply to both PICC and application level.

6.6.4.1 Command ChangeKey

Changing keys is possible with the command ChangeKey as defined in Section 7.5.1. The command is also rejected if there is no active authentication with the relevant change key. For the application level, all AppKeys, including AppMasterKey, require authentication with AppMasterKey. CryptoRequestKeys require authentication granting SetConfiguration Option 0x15 ChangeAC access rights. By default this is also AppMasterKey authentication. The required access rights can also be achieved through asymmetric authentication, see Section 6.4. Under EV2 Secure Messaging, i.e. if in VCState.AuthenticatedAES or in VCState.AuthenticatedECC, the secure distinguished when targeting AppKeys, i.e. KeyNo 0x00 until 0x04: Targeted key equal to authenticated key If the targeted key is equal to the authenticated key (i.e. KeyNo==getKeyNo(AuthKey), the plaintext is constructed as follows:

KeyType.AES128: KeyData = NewKey||KeyVer(16 + 1 byte)
KeyType.AES256: KeyData = NewKey||KeyVer(32 + 1 byte) NewKeyisthe new key. KeyVer is the related key version. The normal EV2 secure messaging for CommMode.Full is applied on the command. The response is sent in plain, as the authentication is lost (see below). In VCState.AuthenticatedECC, this case cannot occur. In VCState.AuthenticatedAES, this case applies only if targeting AppMasterKey. Targeted key different from authenticated key If the targeted key is not equal to the authenticated key (i.e. KeyNo!= getKeyNo(AuthKey)),the plaintext is constructed as follows:
KeyType.AES128:KeyData = (NewKey⊕OldKey)||KeyVer||CRC32NK(16+ 1 + 4 byte)
KeyType.AES256:KeyData = (NewKey⊕OldKey)||KeyVer||CRC32NK(32+ 1 + 4 byte) A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 58 / 209

key type size. KeyV er is the new version. The normal EV2 secure messaging for CommMode.Full is applied on both the command and the response. always if not targeting AppMasterKey. the targeted use case, if this configuration creates a security risk. the length does not match with the targeted key type, the command is rejected. zero bytes if changing from KeyType.AES128 to KeyType.AES256. both HMAC-based (bit 8-7) and AES-based (bit 6-0) algorithms. PICC moves into VCState.NotAuthenticated.

6.6.4.2 Command GetKeySettings

Retrieving key settings is possible with the command GetKeySettings as defined in Section 7.5.2. is supported, no authentication is required.

KeySetting is set to 0x03, i.e. compatible to the AppKeySettings on a MIFARE DESFire product.
Bit 7-6 of MaxNoOfKeys represents the key type of the application, encoded as defined in Table 27. This key type can be changed through updating the AppMasterKey. Bit5-0 is set to the number of application keys, i.e. 0x05. If an Option is given, the metadata of a specific key group is returned. Option KeyGroup 0x00 CryptoRequestKeys 0x01 ECCPrivateKeys 0x02 CARootKeys

Under active authentication, the command GetKeySettings requires CommMode.MAC. Information on the authentication and the secure messaging-dependent structure of the command can be found in Section 6.3.

6.6.4.3 Command GetKeyVersion

Getting the key version of an addressable key is possible with the command GetKeyVersion as defined in Section 7.5.3. KeyNo indicate which information is requested. If the key does not exist, the command is rejected. When retrieving a key version, a single byte KeyVer is returned holding the key version. This command can be issued without an active authentication, but if there is an active authentication the command GetKeyVersion requires CommMode.MAC. Information on the authentication and the secure messaging-dependent structure of the command can be found in Section 6.3.

6.7 Asymmetric Key Management

A30 distinguishes private and public keys and the way that they are managed:

ECCPrivateKey: This is the private key of an asymmetric ECC key pair, which is used to authenticate the A30 toward external parties. The management of these keys is detailed in Section 6.7.1.
CARootKey: This is the public key of an asymmetric ECC key pair, which is used to authenticate an external party toward the A30. This key is written to the A30 with ManageCARootKey. This is further detailed in Section 6.7.2.

6.7.1 ECCPrivateKey Management

6.7.1.1 Command ManageKeyPair

The generation of ECCPrivateKeys is possible with the command ManageCARootKey. A30 supports up to five ECC Key Pairs. The key pairs are associated with a specific curve via CurveID. Each ECC key pair is assigned to a specific application area and potentially to a specific protocol via KeyPolicy. Typically, best security practice is to use each key for a single purpose. Therefore, if allowing multiple usages for the same key, the implication from security perspective must be assessed. Generation of a new key pair requires the access condition and communication mode as defined in the configuration parameters (see SetConfiguration Option 0x12). By default, CommMode.Full is applied, requiring authentication granting AppMasterKey access rights. Key pair replacement requires write-access as specified with ECCPrivateKey was created. During key pair generation, the private key is securely stored on-card and the public key is returned to the caller. In case of import, the private key is to provided via PrivateKey. In this case, the public key is not returned. It is also possible to only update the metadata, i.e. KeyPolicy and access rights, of an existing key entry. This will not affect the current key value. For metadata update, also WriteAccess as configured for the targeted key entry is required. In this case, the command is rejected if the CurveID is not set to the curve associated with the current key.

6.7.1.2 ECCPrivateKey Key Usage Limit

To allow mitigating potential future attack scenarios, ECCPrivateKeys can be configured with a key usage limitation. This allows limiting the amount of private key computations, and therefore related trace collection for side-channel attacks. Next to attack mitigation, this feature can also be used to limit the usage of a card/device. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 60 / 209

Potentially, the limit can be increased in the field, e.g. if the end user pays for additional service. The key usage limitation (KeyUsageCtrLimit) is configured through KUCLimit. Once enabled for a particular ECCPrivateKey, any private key usage is counted through a KeyUsageCtr associated with that ECCPrivateKey. This means that the KeyUsageCtr shall be incremented by one before the private key operation of the following operations:

ISOInternalAuthenticate for Card-Unilateral Authentication, see Section 6.3.3.
ReadData or ISOReadBinary when applying Secure Dynamic Messaging with ECDSa SDMSIG, i.e.only when SDMSIG is targeted to be read out, see Section 6.3.8.10.
CryptoRequest with action 0x03 for ECC signature generation, see Section 7.10.3. Note that in case of Initialize/Update/Finalize flow, the counter is incremented on the Finalize-step.
CryptoRequest with action 0x05 for ECC Diffie-Hellman, see Section 7.10.5. Note that here the counter is only incremented in the Single-step flow, as the Tow-step flow does not support ECCPrivateKey.
ISOGeneralAuthenticate for SIGMA-I, see Section 6.3.2: – A30 acting as Responder: before B1 response – A30 acting as Initiator: before A1 response Note: Any updates to the KeyUsageCtr are written with anti-tearing protection, guaranteeing that the counter will in case of tearing either hold the previous or the targeted value. If the configured KeyUsageCtrLimit has been reached, the related ECCPrivateKey will be disabled. This means that the key cannot be used for private key computations, though the key entry can still be updated (and potentially reenabled) if the required authentication to do so can still be gained. If the KeyUsageCtrLimit is disabled, private key operations are not counted. When only updating metadata with ManageKeyPair, it is possible to disable or change the KeyUsageCtrLimit without affecting the current KeyUsageCtr value. Note that putting the limit to a value equal or lower than the current value, will immediately disable the key entry. When changing the current key value through an import or generate key pair action, the current KeyUsageCtr value shall be reset to zero. It is also possible to freeze the current KeyUsageCtrLimit. This can be done through KeyPolicy Bit 15. Once the KeyUsageCtrLimit has been frozen, it cannot be updated anymore. This means that a ManageKeyPair updating metadata will be rejected if KUCLimit has a value different from the currently configured KeyUsageCtrLimit or if KeyPolicy Bit 15 is not set. Note that it is still possible to change the limit configuration by generating or importing a new key pair. Enabling the key usage limit feature may create a denial-of-service risk. For typical use cases, the risk should be limited if e.g. configuring a limit of one million, or if preceding authentication of the external party is required before the A30 private key operation. Note: It is essential to properly protect the ECCPrivateKey write access, as the right to update the key entry also allows to update and/or disable the KeyUsageCtrLimit.

6.7.1.3 ECCPrivateKey Information Retrieval

A30 supports information retrieval with regard to ECCPrivateKey by GetKeySettings as defined in Section 7.5.2. A30 does not support exporting private keys or the related public keys. Note that the related public key is typically stored via a certificate in a FileType.StandardData file. If the certificate is not created at the time of ECCPrivateKey generation or import, the public key may be temporarily stored in the file and later overwritten with the certificate. Note that this means one needs to be careful when generating a key pair ManageKeyPair and putting the WriteAccess condition to 0xF. If the public key in the response gets lost, one is not able to regenerate the key entry. Therefore, it is not recommended to put WriteAccess to 0xF before the public key has been received. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 61 / 209

6.7.2 CARootKey Management

6.7.2.1 Command ManageCARootKey

The writing of CARootKeys is possible with the command ManageCARootKey as defined in Section 7.6.2. A30 supports up to five CARootKeys. The public keys are associated with a specific curve via CurveID. Note that A30 does not validate the provided public key. Each CARootKey has an associated set of access rights via AccessRights which can be granted to the host after successful authentication depending on the presented certificates. Note that AccessRights is encoded LSB first. All CARootKeys can optionally be associated with a trusted issuer name via IssuerLen and Issuer. The full Issuer byte string, including SEQUENCE tag and length must be provided. If a trusted issuer name is set, this is compared against the Issuer field of the public key certificate provided during the authentication. In case of chaining, the (grand-)parent certificate Issuer must match. Note that the implementation stores a hash of the provided Issuer to allow for fixed memory consumption. Creation of CARootKeys requires the access condition and communication mode as defined in the configuration parameters (see SetConfiguration Option 0x12). By default, CommMode.Full is applied, requiring authentication granting AppMasterKey access rights. Updating an existing CARootKey requires write-access as specified with WriteAccess when the entry was created. If a certificate cache is enabled, see SetConfiguration Option 0x13, the cache will be flushed on updating a CARootKey.

6.7.2.2 CARootKey Information Retrieval

A30 supports information retrieval with regards to CARootKey by GetKeySettings as defined in Section 7.5.2.

6.7.3 PICC/MF level

6.7.3.1 ECCPrivateKey entries

At PICC or MF level, in the default configuration, the A30 is trust-provisioned during manufacturing with one key pair from which the private keys are stored on the A30 as ECCPrivateKeys for the purpose of originality

6.7.4 Application/DF level

6.7.4.1 ECCPrivateKey entries

A30 supports up to five ECCPrivateKey entries.

6.7.4.2 CARootKey entries

A30 supports up to five CARootKey entries. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 62 / 209

6.7.5 Memory Consumption

Memory allocation is done in 32-byte blocks, see Section 6.5.2.3.

ECCPrivateKey: three blocks.
CARootKey: four blocks.

6.7.6 Certificate Cache

associated issuer information. keys i.e. public keys belonging to intermediate certificates. Each cache entry shall be stored with its expiry date. the most recently used entries are retained. However, all expired certificates shall be flushed from the cache. command. The cache can only be created once and cannot be resized. Table 30. Certificate Cache Example A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Figure 13. Conceptual View of Host Verification Public Keys

6.8 Certificate Management

6.8.1 ECC Certificate Repository Management

Create certificate repository. Note the maximum memory specified for the repository is allocated on creation. This size may be defined as larger than initially required to allow increasing data items after resetting a repository.
Load one or more public key certificate
Load one or more certificate mapping table (optional)
Activate the certificate repository A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 64 / 209

Figure 14. Conceptual View of a Certificate Repository apply. The command does not return any response data.

6.8.1.1 Create Certificate Repository

the identity of the on-card private key to be associated with the repository
a repository identifier used to personalize the repository and to access the repository during algorithm execution The format of the create certificate repository command data is defined in Table 129.

6.8.1.2 Load Public Key Certificate Chain

Figure 15. Certificate Chain Example execution). The command format is outlined in Table 130. The A30 shall not verify the certificate chain or certificate hash values during loading.

6.8.1.3 Certificate Mapping Table

Table 31. X.509 Certificate Wrap Encoding

6.8.1.3.2 Mapping Table Command Data Format

6.8.1.4 Activate Certificate Repository

6.8.2 Read Certificate Repository

It is possible to read a certificate from a repository or to read a repository’s metadata using the ReadCertRepo command. Reading metadata does not require any authentication; if reading metadata in a secure tunnel then CommMode.MAC is applied. Reading a certificate directly from the repository requires access as defined in the Read access condition set during repository creation/reset. If reading using a standard APDU then the maximum response data length is 239 bytes. The format of the ReadCertRepo command is defined in Section 7.7.2.

6.9 Application Management

A30 groups user data into an application. Within an application data is further grouped into files, as described in Section 6.10. A30 only holds one application, which is pre-configured at delivery, as defined in Section 6.9.2. In Section 6.9.1, it is detailed how applications can be selected.

6.9.1 Application Selection

An application can only be selected with ISOSelectFile, see Section 6.15.1.4.

6.9.2 Application Definition

A30 comes pre-configured with one application. It shall have the following properties for application selection:

DFName: 0xD2760000850101
ISOFile Identifier: 0xE110

6.10 File Management

A30 maintains user data into files of specific types listed in Section 6.10.1. Files are managed through creation, information retrieval and update functions respectively specified in Section 6.10.4, Section 6.10.3 and

6.10.1 File Types

A30 supports the following types of data storage:

raw data as specified in Section 6.10.1.1
monotonic counters as specified in Section 6.10.1.2 All A30 files are defined with a file number and the communication mode that has to be used when accessing the file data. The file number is coded over 1 byte. It is unique per file in an application. The communication mode is defined in Section 6.3.6.6. 6.10.1.1 FileType.StandardData FileType.StandardData stores the data as raw data byte per byte. Data is accessed by chunk of byte at a certain offset in the data file and with a certain length in byte. Section 6.10.6, A30 holds three FileType.StandardData files at delivery. Next to this, the user can create additional files. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 68 / 209

WriteData and ISOUpdateBinary. create, is limited to maximum of 1024 bytes. case, if secure messaging applies, incomplete cryptographic blocks within a frame cannot be fully processed. Such a block will then be considered as part of the next frame. Section 6.10.6, A30 does not hold any FileType.Counter files in the default configuration at delivery. counters using WriteData or ISOUpdateBinary.

6.10.2 File Access Rights Management

encoding of access conditions. of these access rights are permitting the use of a subset of commands defined in Section 6.10.2.2. to be set to 0xF (for future extensibility). 15..12 FileAR.Read access condition as in Table 17. 11..8 FileAR.Write access condition as in Table 17. 7..4 FileAR.ReadWrite access condition as in Table 17. 3..0 FileAR.Change access condition as in Table 17. Table 32. Set of Access condition coded on 2 bytes A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

6.10.2.1 Secure Dynamic Messaging Related Access Rights

access rights:FileAR.SDMMetaRead, FileAR.SDMFileRead, and FileAR.SDMCtrRet. access to GetFileCounters. The others have a different interpretation. Table 33. FileAR.SDMMetaRead values free access to ReadData and ISOReadBinary. The FileAR.SDMFileRead2, as defined in Table 34, allows configuring an asymmetric ECCPrivateKey. encryption if enabled. Table 35 gives an overview of the possible combinations. Table 34. FileAR.SDMFileRead values Table 35. FileAR.SDMFileRead2 values A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 36. FileAR.SDMFileRead and FileAR.SDMFileRead2 combinations

6.10.2.2 Access right association with commands

In Table 37, it is listed to which commands the access rights are granting access to. Table 37. Command list associated with access rights A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 37. Command list associated with access rights...continued CommMode.Plain is to be applied. FileAR.SDMFileRead2 are not affecting the regular secure messaging, i.e. if authenticated. dedicated Secure Dynamic Messaging FileAR.SDMCtrRet.

Resp.PERMISSION_DENIED if all access conditions associated with all access rights granting access to the command are denying any access.
Resp.AUTHENTICATION_ERROR if at least one access condition associated with one of the access rights granting access to the command requires a valid authentication, while being in VCState.NotAuthenticated, or in VCState.AuthenticatedAES but authenticated with the wrong key.
Resp.CERT_ERROR if at least one access condition associated with one of the access rights granting access to the command requires a valid authentication, while being in VCState.AuthenticatedECC but not having obtained the required access rights from the targeted CARootKey or reader certificate presented during the authentication.

6.10.2.3 Command ChangeFileSettings

in Table 14 and the access rights of a file by mean of all its sets of access conditions as specified in Table 32. configuration, see Deferred Configuration Options. previous file, i.e. only one FileType.Counter can act as Authentication Counter at a time. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

The command is rejected if:

one of the access conditions is targeting a key that does not exist within the application.
the PICC level is selected.
the FileNo parameter does not refer to an existing file in the selected application.
the FileAR.Change is not granted because it is a no access 0xF.
the FileAR.Change is not granted because it requires an authentication with a AppKey which is currently not active.
trying to enable Secure Dynamic Messaging on a file where it is not supported.
the provided configuration for Secure Dynamic Messaging and mirroring is inconsistent according to the Under active authentication, the command ChangeFileSettings requires CommMode.Full. There is one exception: if FileAR.Change of the targeted file is configured to 0xE allowing free access, also under active authentication CommMode.Plain is to be applied. Information on authentication and secure messaging- dependent structure of the command can be found in Section 6.3.

6.10.3 File Information Retrieval

6.10.3.1 Command GetFileSettings

GetFileSettings as defined in Section 7.8.5 allows to get information on the properties of a specific file. The information provided by this command depends on the type of the file which is queried. The file from which the settings have to be retrieved is defined by FileNo specified over 5 bits. The first part of the returned message is the same for all file types:

the actual file type, see Section 6.10.1
the communication mode as specified in Table 14
the access rights of a file by mean of all its sets of access conditions as specified in Table 32. All subsequent bytes in the response have a special meaning depending on the file type:
FileType.StandardData: file size over 3 bytes. If Secure Dynamic Messaging, with eventually Deferred Configuration, applies for the targeted file, this is also indicated, and the related parameters are returned.
FileType.Counter file: if the authentication Counter is enabled. The command is rejected if:
the targeted file does not exist The command is rejected if:
the targeted file does not exist Under active authentication, the command GetFileSettings requires CommMode.MAC. Information on authentication and secure messaging-dependent structure of the command can be found in Section 6.3.

6.10.3.2 Command GetFileCounters

GetFileCounters as defined in Section 7.8.6 supports retrieving of the following counter values:

current values associated with the 24-bit SDMReadCtr related with a FileType.StandardData file after en-
current values associated with the FileType.Counter files holding a 32-bit counter. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 73 / 209

The command is rejected if

The PICC level is selected
the targeted file does not exist
the targeted file is not a FileType.StandardData file with Secure Dynamic Messaging enabled, or a FileType.Counter file.
if targeting FileType.StandardData file, depending on FileAR.SDMCtrRet, permission is always denied or requires authentication.
if targeting FileType.Counter file, depending on FileAR.Read or FileAR.ReadWrite, permission is always denied or requires authentication. Under active authentication, the command GetFileCounters requires CommMode.Full for SDMReadCtr retrieval. If retrieving the value of a FileType.Counter, the communication mode depends on the configuration of the file. Information on authentication and secure messaging-dependent structure of the command can be found in Section 6.3.

6.10.3.3 Command GetFileIDs

GetFileIDs as defined in Section 7.8.3 returns the complete list of file IDs of all active files of the selected application. The command takes no parameters. Each File ID is coded in one byte. Duplicate values are not possible as each file must have an unambiguous identifier. The response includes all identifiers of all FileType.StandardData or FileType.Counter files. For FileType.StandardData, independently of whether they were pre-allocated or created by the user. The command is rejected if:

the PICC level is selected. Under active authentication, the command GetFileIDs requires CommMode.MAC. Information on authentication and secure messaging-dependent structure of the command can be found in Section 6.3.

6.10.3.4 Command GetISOFileIDs

GetISOFileIDs as defined in Section 7.8.4 returns the complete list of the 2 byte ISO/IEC 7816-4 File IDentifiers of all active files within the currently selected application. The command takes no parameters. Each File ID is coded in 2 bytes. Duplicate values are not possible as each file must have an unambiguous identifier. The response includes all identifiers of all FileType.StandardData files, independently of whether they were pre- allocated or created by the user. The command is rejected if:

the PICC level is selected. Under active authentication, the command GetISOFileIDs requires CommMode.MAC. Information on authentication and secure messaging-dependent structure of the command can be found in Section 6.3. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 74 / 209

6.10.4 File Creation

A30 supports file creation for FileType.StandardData and FileType.Counter files. The file creation commands all share the following parameters: FileNo, FileOption and AccessRights. The FileNo encodes the file number in the range of 0x00 to 0x1F which the new created file should get within the currently selected application. If the file number is already occupied, the file creation fails. FileOption defines the communication mode of the targeted file, see Section 6.3.6.6. The AccessRights define the mandatory access right set of the newly created file. Note that the meaning of these access rights depends on the targeted file type, see Section 6.10.2.2. The command is rejected if one of the access rights targets a key that is not available in the targeted application. The file creation command is rejected if no application has been selected, i.e. the PICC level is currently selected. An active authentication with the AppMasterKey is required. Under active authentication file creation commands require CommMode.MAC.

6.10.4.1 Command CreateStdDataFile

General aspects of file creation, shared by all file creation commands, are described at the start of specifies the size of the file in bytes. FileSize is defined as a 3 byte integer. The file will be initialized with all zero bytes. Every FileType.StandardData file within the application, must be created with a 2 byte File Identifier ISOFileID to enable ISO/IEC 7816-4 selection with ISOSelectFile. A30 does not limit the amount of files that can be created, other than by the available memory and FileNo range. The size of a created file must not exceed 1024 byte.

6.10.4.2 Command CreateCounterFile

General aspects of file creation, shared by all file creation commands, are described at the start of specifies the initial value of the counter. Value is defined as a 4 byte unsigned integer. If targeting a FileType.Counter, the counter can be enabled as Authentication Counter by setting FileOption Bit 6. If another file is currently already enabled as Authentication Counter, the feature will be disabled for the previous file, i.e. only one FileType.Counter can act as Authentication Counter at a time. A30 does not limit the amount of counters that can be created, other than by the available memory and FileNo range.

6.10.5 Memory Consumption

Memory allocation is done in 32-byte blocks, see Section 6.5.2.3. The memory for files is allocated at file creation and can be computed as follows:

General overhead: 1 block per 2 files within an application.
FileType.StandardData: (FileSize +31)/32
FileType.Counter: 1 block. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 75 / 209

6.10.6 File Definition

The A30 application as defined in Section 6.9.2 shall hold the following files: FileType.StandardData files

a FileType.StandardData file of 32 bytes with following properties: – FileNo = 0x01; ISO File ID = 0xE103 – FileAR.Read = 0xE;FileAR.Write =0x0;FileAR.ReadWrite =0x0;FileAR.Change =0x0 – Secure Dynamic Messaging and mirroring are not supported for this file. – CommMode.Plain This file will hold the CC-file according to [14]. At delivery it will hold following content:
CCLEN = 0x0017, i.e. 23 bytes
T4T_VNo = 0x20, i.e. Mapping Version 2.0
MLe = 0x0100, i.e. 256 bytes
MLc = 0x00FF, i.e. 255 bytes
NDEF-File_Ctrl_TLV – T = 0x04, indicates the NDEF-File_Ctrl_TLV – L = 0x06, i.e. 6 bytes – NDEF-File File Identifier = 0xE104 – NDEF-File File Size = 0x0100, i.e. 256 bytes – NDEF-File READ Access Condition = 0x00, i.e. READ access granted without any security – NDEF-File WRITE Access Condition = 0x00, i.e. WRITE access granted without any security
Proprietary-File_Ctrl_TLV – T= 0x05, indicates the Proprietary-File_Ctrl_TLV – L= 0x06, i.e. 6 bytes – Proprietary-File File Identifier = 0xE105 – Proprietary-File File Size = 0x0080, i.e. 128 bytes – Proprietary-File READ Access Condition = 0x82, i.e. Limited READ access, granted based on proprietary methods, after authentication with key 0x2. – Proprietary-File WRITE Access Condition = 0x83, i.e. Limited READWRITE access, granted based on proprietary methods, after authentication with key 0x3. The remainder of the file is set to all 0x00 bytes.
a FileType.StandardData file of 256 bytes with following properties: – FileNo= 0x02; ISO File ID = 0xE104 – FileAR.Read =0xE;FileAR.Write =0xE;FileAR.ReadWrite =0xE;FileAR.Change =0x0 – SecureDynamic Messaging and mirroring is supported for this file, but disabled at delivery. – CommMode.Plain – By default, this file is set to all 0x00 bytes at delivery. This file will hold the NDEF-file according to [14].
a FileType.StandardData file of 128 bytes with following properties: – FileNo= 0x03; ISO File ID = 0xE105 – FileAR.Read =0x2;FileAR.Write =0x3;FileAR.ReadWrite =0x3;FileAR.Change =0x0 – SecureDynamic Messaging and mirroring is not supported for this file. – CommMode.Full – By default, this file is set to 0x00 0x7E, followed by all 0x00 bytes at delivery. This file proprietary file according to [14] that can hold additional confidential information. According to [14], the PLEN field is set to 126 (0x007E) by default at delivery. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 76 / 209

All files can on request get customer-specific configurations and contents through commercial customization options, instead of the default values listed here. After personalization the write access to the FileType.StandardData files, can be adapted to no access (0xF). The following access rights for Secure Dynamic Messaging can be configured by the customer, e.g. as follows:FileAR.SDMMetaRead = 0x4;FileAR.SDMFileRead = 0x1;FileAR.SDMCtrRet = 0x2. This is only a recommended setting, other configurations are also possible. In this setting KeyNo 0x4 is used as non- diversified key (e.g. in this case configuring for encrypted UID-retrieval via PICCData). KeyNo 0x1 is used as read key protecting the file communication and KeyNo 0x2 is used for counter retrieval after mutual authentication.

6.11 Data Management

A30 maintains user data into files of specific types as described in Section 6.10. The user can access and manage the data through functions specific to file type. Data can be read, written, or updated. Depending on the file type, data are defined as:

raw data in FileType.StandardData For a user, the access to data is limited by the access rights set at file level as defined in Section 6.10.2 and listed in Table 37.

6.11.1 Standard Data Files

6.11.1.1 Command ReadData

Reading data from FileType.StandardData files is possible with the command as defined in Section 7.9.1. The data to be read is defined by the file number of the targeted file, the offset in the data file where to start the reading and its size in bytes. The file number specifying the file where to read the data from is given by FileNo specified over 5 bits as defined in Section 6.10. The position byte-wise in the data file where to start to read data is given by Offset. Its valid range is from 0x000000 to FileSize −1. The data size to be read is given by Length specifying the number of bytes. If Length is equal to 0x000000 then the entire data file has to be read starting from the position specified by the Offset value. Length valid range is 0x000000 to FileSize − Offset. Note: Due to the ISO/IEC 7816-4 wrapping, only supporting short Le, see Section 6.2.2, the amount of data read is limited by Le as well. The data is returned in Data. If the number of bytes to send to the PCD does not fit into one single frame, chaining is applied, see Section 6.2.3. As listed in Table 37, ReadData is allowed only if at least one of FileAR.Read and FileAR.ReadWrite access rights associated with the targeted file is granted. Additionally, if not authenticated, ReadData may be granted if Secure Dynamic Messaging for reading is enabled via FileAR.SDMFileRead. If authenticated, the communication mode depends on the one from the file being accessed as specified in Section 6.3.6.6. Information on authentication and secure messaging-dependent structure of the command can be found in Section 6.3. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 77 / 209

6.11.1.2 Command WriteData

Writing data to FileType.StandardData files is possible with the command as defined in Section 7.9.2. The location of data to be written is defined by the file number of the targeted file, the offset in the data file where to start the writing and its size in bytes. The file number specifying the file where to write to is given by FileNo specified over 5 bits as defined in Section 6.10. The position byte-wise in the data file where to start to write data is given by Offset define on 3 bytes. Its valid range is from 0x000000 to FileSize −1. The data size to be written is given by Length specifying the number of bytes defined on 3 bytes. Length valid range is 0x000001 to FileSize −Offset. The data is passed in Data and is, if needed, split in multiple frames depending on the command variant as defined above. For FileType.StandardData, data written in a file can be directly returned with ReadData, as FileType.StandardData does not implements any backup mechanism. Note especially that in case of chaining, data is already written before the integrity has been checked (CommMode.MAC or CommMode.Full). Therefore, in case of Resp.INTEGRITY_ERROR, the content of the file can be corrupted. For this reason, chained writing to FileType.StandardData in CommMode.MAC or CommMode.Full can be disabled with SetConfiguration, option 0x04. Note however, that also here an implementation may buffer multiple chained frames and write them at once. As long as the implementation can guarantee that the MAC is validated before the writing and all targeted data or none are updated, this does not violate the disabled chained writing configuration. As listed in Table 37, WriteData is allowed only if at least one of FileAR.Write and FileAR.ReadWrite access rights associated with the targeted file is granted. The communication mode depends on the one from the file being accessed as specified in Section 6.3.6.6. Information on authentication and secure messaging-dependent structure of the command can be found in Section 6.3. At PICC level, the command is rejected.

6.11.2 Counter Files

6.11.2.1 Command IncrementCounterFile

Increment the value of a FileType.Counter file is possible with the command IncrementCounterFile as defined in Section 7.9.3. The increment is defined by the file number of the targeted FileType.Counter file and the amount to add up. The file number specifying the file where to credit the amount is given by FileNo specified over 5 bits as defined in Section 6.10. The increment amount is given in IncrValue over 4 bytes defined as an unsigned integer. As listed in Table 37, IncrementCounterFile is allowed only if at least one of FileAR.Write or FileAR.ReadWrite access rights associated with the targeted file is granted. The communication mode depends on the one from the file being accessed as specified in Section 6.3.6.6. Information on authentication and secure messaging-dependent structure of the command can be found in Section 6.3. At PICC level, the command is rejected. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 78 / 209

6.12 Crypto API

Random Number Generation [21][22]
SHA-256/SHA-384[17]
ECC Sign/Verify [23]
ECC Diffie-Hellman [27]
AES CMAC (128-bit and 256-bit key size) [7]
AES CBC (128-bit and 256-bit key size) [5][6]
AES ECB (128-bit and 256-bit key size) [5][6]
AES CCM (128-bit and 256-bit key size) [25]
AES GCM (128-bit and 256-bit key size) [26]
Write to Internal Buffer storage
HMAC [24]
HKDF [28]
Echo The crypto API provides two internal buffers, which can be used as workspace for RNG data, keys, ECDH output, signature generation/verification and AES encrypt/decrypt. The buffers may be used as 1 or more 16- byte buffers as outlined in Figure 16 and Figure 17. One buffer provides data only retained for the current crypto API session (the transient buffer); the other buffer stores data persistently in NVM (the static buffer). aaa-053124 Slot 0 - 16 bytes Slot 1 - 16 bytes Slot 2 - 16 bytes Slot 3 - 16 bytes Slot 4 - 16 bytes Slot 5 - 16 bytes Slot 6 - 16 bytes Slot 7 - 16 bytes

Figure 16. Crypto API Transient Buffer Format buffer is reinitialized under the following circumstances.

ISO GeneralAuthenticate command
AuthenticateEV2First/NonFirst commands
Following an update to the Crypto API configuration (option 0x15).

SHA operation to slot 0 will cause data to be written to both slots 0 and 1. Table 38. Crypto API Data Source/Destination Selection permitted. If a command uses multiple slots, then the policy checks for each slot must be fulfilled. Table 39. Crypto API Slot Usage Policy Options Table 40. Crypto API Policy Supported Algorithms and then a request is received to execute an AES operation then the SHA operation shall be aborted. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

If an internal buffer is referenced as input or output, then multiple slots are used for values of more than 16 bytes.

6.13 GPIO Management

A30 supports two GPIOs:

GPIO1 may be configured for input detection of a binary-state input signal (e.g. to detect if button is pressed or not), binary-state output signal or down-stream power-out.
GPIO2 may be configured as a binary-state input or output signal. GPIO configuration is done with SetConfiguration 0x11, see Command SetConfiguration, and especially Table 1. For each of the modes, dedicated HW aspects as outlined in Table 3 can be set. When configured for down- stream power-out, a targeted voltage/current level needs to be set. It is however possible to overwrite this at runtime via ManageGPIO, if e.g. not sufficient power can be harvested from the actual field strength. When configured as output, the GPIO can also be configured to notify on authentication. This is further detailed in Section 6.13.4. The ReadGPIO command, as defined in Section 7.11.2, may be used to read the current status of the GPIOs. The ManageGPIO, as defined in ManageGPIO, is used for controlling the output on GPIO1.

6.13.1 Command ManageGPIO

The ManageGPIO command format is outlined in Section 6.13. The command is only accepted at application level, and will be rejected at PICC level. Depending on the ManageGPIOAccessCondition, as configured with SetConfiguration Option 0x11 , the command may require an authentication and the configured secure messaging communication mode. By default, the command is disabled. When a GPIO is configured for output, after a power-on reset, the GPIO will be initialized with the state as configured by the GPIOXConfig from SetConfiguration Option 0x11 on the first command after activation, i.e. I2C activation. This is independently of the state from a previous activation. Immediately after the PoR, output GPIOs will be in high-impedance (High-Z) state.

6.13.2 Command ReadGPIO

The ReadGPIO, as defined in Section 7.8.2, returns the status of GPIO1 and/or GPIO2 for both input and output use cases, as configured with SetConfiguration Option 0x11, see Command SetConfiguration. For GPIO input configurations (GPIOXMode = 0x01), only the current status for GPIO1 and GPIO2 are returned:GPIO1CurrStatus and GPIO1CurrStatus. This is the value as measured during the execution of the ReadGPIO command. For GPIO output (GPIOXMode = 0x02 or GPIO2Mode = 0x05) and down-stream power out (GPIO1Mode = 0x04) operations, the current status can be retrieved, i.e. whether or not the output or down-stream power out has been set or not. This allows an external host to keep track. For both input and output cases, GPIO1CurrStatus and GPIO1CurrStatus can take the following values: of output, the output is not driven, or down-stream power out is not enabled (e.g. after CLEAR operation with ManageGPIO). case of output, the output is driven or down-stream power out is enabled (e.g. after SET operation with ManageGPIO). A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 81 / 209

Invalid: 0x49,i.e. ASCII encoding of ‘I’. This is the value when the feature has not been enabled. The complete GPIO status is returned on 3 bytes:
Byte[0]:TTPermStatus or N/A
Byte[1]:TTCurrStatus, GPIO1CurrStatus or N/A
Byte[2]:GPIO1CurrStatus or N/A This results in the following possible outputs, depending on the GPIO configuration: Configuration Response data GPIO1Conf GPIO2Conf GPIOByte0 GPIOByte1 GPIOByte2 N/A =(‘I’) GPIO1CurrStatus =(‘H’/‘L’) GPIO1CurrStatus =(‘H’/‘L’) N/A =(‘I’) GPIO1CurrStatus =(‘H’/‘L’) GPIO1CurrStatus =(‘H’/‘L’) Input Input Output Other N/A =(‘I’) GPIO1CurrStatus =(‘H’/‘L’) N/A =(‘I’) TTPermStatus =(‘C’/‘O’) TTCurrStatus =(‘C’/‘O’) GPIO1CurrStatus =(‘H’/‘L’) TTPermStatus =(‘C’/‘O’) TTCurrStatus =(‘C’/‘O’) GPIO1CurrStatus =(‘H’/‘L’) TT Input Output Other TTPermStatus =(‘C’/‘O’) TTCurrStatus =(‘C’/‘O’) N/A =(‘I’) N/A =(‘I’) GPIO1CurrStatus =(‘H’/‘L’) GPIO1CurrStatus =(‘H’/‘L’) N/A =(‘I’) GPIO1CurrStatus =(‘H’/‘L’) GPIO1CurrStatus =(‘H’/‘L’) Output Input Output Other N/A =(‘I’) GPIO1CurrStatus =(‘H’/‘L’) N/A =(‘I’) N/A =(‘I’) N/A =(‘I’) GPIO1CurrStatus =(‘H’/‘L’) N/A =(‘I’) N/A =(‘I’) GPIO1CurrStatus =(‘H’/‘L’) Other Input Output Other N/A =(‘I’) N/A =(‘I’) N/A =(‘I’)

Table 41. ReadGPIO response authentication and specific secure messaging communication mode. By default, the command is disabled. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

6.13.3 Mirroring in the NDEF message

The GPIO Input and Tag Tamper statuses can be mirrored together within the NDEF messaging. In this way, the status can be protected by the Secure Dynamic Messaging, as defined in Section 6.3.8 and more specifically Section 6.3.8.5. If mirroring is enabled, the encoding within the NDEF file will be identical to the 3-byte ReadGPIO response, see Table 255. Note that only Input and Tag Tamper configurations are mirrored. Output configurations are interpreted as ‘Other’ for NDEF mirroring, i.e. returning ‘I’ for Invalid. To enable this mirroring, the configuration must be done with ChangeFileSettings, see Section 7.8.7.

6.13.4 Authentication notification

When configured as output, the GPIO can be configured to notify on authentication. This configuration is also done via SetConfiguration 0x11using the GPIO1NotifandGPIO2Notifparameter. When configured, the targeted GPIO is enabled (i.e. set to HIGH representing logical ’1’) once the authenticated state is reached. This means:

On successful execution of SIGMA-I mutual authentication; see Section 6.3.2, i.e ISOGeneralAuthenticate replying with message type 0xB4 when acting as responder or 0xA1 when acting as initiator.
On successful execution of symmetric mutual authentication with AuthenticateEV2NonFirstPart2. Note that it is still possible to manually toggle the GPIO with ManageGPIO if authentication notification is enabled. Most likely, this kind of double usage of a GPIO pin should be avoided for a use case, as can e.g. be done by configuring the ManageGPIOAccessCondition to 0xF. When losing the authentication state, the GPIO will be disabled (i.e.set to LOW representing logical ’0’). See

6.14 Timer Support

The A30 supports three timers:

Authority Watchdog Timer 1 (AWDT1)
Authority Watchdog Timer 2 (AWDT2)
Halt Watchdog Timer (HWDT) The timer values are configured using SetConfiguration Option 0x14 as defined in Command SetConfiguration.

6.14.1 Authority Watchdog Timers

The AWDT1 timer is used to limit the time the host has to execute mutual authentication. If configured it is used when performing AES-based symmetric mutual authentication or SIGMA-I asymmetric mutual authentication. When performing SIGMA-I as the Initiator the AWDT1 timer is started when the A30 sends its ephemeral public key to the host. It is stopped when the host provides its ephemeral public key and session signature or the session is explicitly aborted e.g. a new mutual auth session is started. When performing AES-based mutual authentication the AWDT1 timer is started when the A30 receives the first AuthenticateEV2First command. It is stopped when the hosts sends the final AuthenticateEV2First command or the session is explicitly aborted e.g. a new mutual auth session is started. If the AWDT1 timer expires then the A30 closes the current mutual authentication session, and reject the next command received. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 83 / 209

The AWDT2 timer is used to limit the period of the secure tunnel opened by a successful mutual authentication. The AWDT2 timer is started when the A30 authenticates the host and completes mutual authentication. When the AWDT2 timer expires the A30 closes the current secure tunnel session.

6.14.2 Halt Watchdog Timer

The HWDT is used to move the A30 to the HALT state to save power when there is no I/O activity. The HWDT timer is only enabled when the device is Vcc powered. The timer is reset (not stopped) when a command is received on the I2C. resulting in termination of any ongoing activity e.g. an open authentication session. The HALT state is exited when one of the following events occurs:

I2C activity (SDA pulled low).

6.15 ISO/IEC 7816-4 Support

A30 supports ISO/IEC 7816-4 commands [4] by wrapping into ISO/IEC 7816-4 APDUs of the native command set, as explained in Section 6.2.2. On top, the following standard ISO/IEC 7816-4 commands are supported as well:

ISOSelectFile with INS code 0xA4
ISOReadBinary with INS code 0xB0
ISOUpdateBinary with INS code 0xD6

6.15.1 Standard ISO/IEC 7816-4 commands

A30 supports a selection of standard ISO/IEC 7816-4 commands, i.e. commands from the interindustry class [4]. These commands are defined in this section. First the authentication and secure messaging aspects are of these commands are described.

6.15.1.1 Byte order

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 on the native command interface, this needs to be especially taken into account.

6.15.1.2 Security concepts of standard ISO/IEC 7816-4 commands

These commands do not support secure messaging, and therefore can only be issued under following conditions:

ISOReadBinary: if targeted file is configured with at least one of FileAR.Read, FileAR.ReadWrite, Depending on the configuration Secure Dynamic Messaging, see Section 6.3.8, is applied.
ISOUpdateBinary: if targeted file is configured with at least one of FileAR.Write and FileAR.ReadWrite to 0xE, i.e. free access, and issuing the command in VCState.NotAuthenticated. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 84 / 209

6.15.1.3 Error Handling

In case of unsuccessful command execution, A30 sends a return code different from Resp.ISO9000. The full list of ISO/IEC 7816-4 errors is given in Section 7.1. In case of unsuccessful command execution, A30 executes the same abort actions as for native commands, see Section 6.15.1.3. The following generic error cases can occur:

Resp.ISO6985: An ongoing wrapped chained command or multiple pass command is aborted, see Section 6.2.3.
Resp.ISO6700: Wrong or inconsistent APDU length according to [4].
Resp.ISO6E00: Unsupported CLA byte.
Resp.ISO6D00: The received instruction code INS is not supported.
Resp.ISO6A86: Incorrect parameters P1 orP2.

6.15.1.4 ISOSelectFile

ISOSelectFile as defined in compliance with ISO/IEC7816-4 in Table 257 selects either the PICC level, an application, or a file within the application. P1 defines the selection method. IfP1 is set to 0x00, 0x01, or 0x02, selection is done by a 2-byte ISO file identifier. P1 set to 0x00 is used to select the MF (i.e. the PICC level), a DF (i.e. an application if currently the PICC level is selected) or an EF (i.e. a file within the currently selected application). P1 set to 0x01 is used to select a DF, if the MF is currently selected.P1 set to 0x02 can be used to select an EF, if an application is currently selected. For MF selection, 0x3F00 or empty data is to be used. For DF and EF selection, Data shall hold the 2-byte ISO/IEC 7816-4 file identifier. Note: The different byte order for the file identifiers when written with native commands and when used here for ISO/IEC 7816-4 selection. If P1 is set to 0x03, the MF level is selected. This option can only be issued if currently an application (DF) is selected. In this case, Data must be empty. If P1 is set to 0x04, selection is done by DF name which can be up to 16 bytes. The registered ISO DF name is 0xD2760000850100. When selecting this DF name, the PICC level (or MF) is selected. For selecting the application immediately, the ISO/IEC 7816-4 DF name 0xD2760000850101 is to be used. P2 indicates whether or not File Control Information (FCI) is to be returned in case of application selection. If this is to be returned, P2 is set to 0x00. In this case, FCI is returned as response data, if the following conditions are satisfied:

the targeted application hold as file with native file number 0x1F.
this file is of FileType.StandardData.
this file is freely accessible, i.e. FileAR.Read or FileAR.ReadWrite holds the free access condition, see Section 6.10.2.
Le is present. The number of bytes requested by Le up to the complete file data will be returned in plain. There is no specific FCI template format checked, i.e. the data stored in the file will be sent back as is. In case of PICC level or file selection, FCI data is never returned. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 85 / 209

In case of failure, the current selection status both at application (MF/DF) and file (EF) level is not affected. The currently selected application and file, if any, remains selected.

6.15.1.5 ISOReadBinary

ISOReadBinary as defined in compliance with ISO/IEC7816-4 in Table 261 can be used to read data from FileType.StandardData files. P1 and P2 define the targeted file and the offset. If Bit 7 of P1 is set, then P1 Bit4-0 encodes a short ISO/IEC 7816-4 file identifier, i.e. referencing the five least significant bits of the 2-byte ISO/IEC 7816-4 file identifiers. All zero bits is reserved for referencing the currently selected file. All one bits is reserved [4] and will be rejected. The referenced file will be selected for this and subsequent operations. Note that if intending to use short file identifiers, the user must take care of avoiding collisions amongst each other and with the reserved values in the definition of the file system, as there is no checking on file creation. P2 encodes the offset from 0 byte to 255 byte. If Bit 7 of P1 is not set, then P1 Bit6-0 concatenated with P2 encode the offset from 0 to 32767 byte. The file currently selected is targeted. If no file was selected, the command is rejected. At PICC level, the command is rejected. Le encodes the number of bytes to be returned. If the encoded value is 0x00 or if it is larger than the number of bytes in the file (starting from the offset), all remaining bytes of the file will be returned. As listed in Table 37, ISOReadBinary is allowed only if at least one of FileAR.Read, FileAR.ReadWrite and FileAR.SDMFileRead access rights associated with the targeted file is granted. It must be set to 0xE, i.e.free access, as the command is only accepted in VCState.NotAuthenticated, i.e.not supporting EV2 secure messaging. Only Secure Dynamic Messaging is supported (which does not require a preceding authentication), depending on the targeted file’s configuration, see Section 6.3.8.

6.15.1.6 ISOUpdateBinary

ISOUpdateBinary as defined in compliance with ISO/IEC7816-4 in Table 265 can be used to write data to FileType.StandardData files. P1 and P2 define the targeted file and the offset. The interpretation is identical as for ISOReadBinary, see Section 7.12.3. At PICC level, the command is rejected. Lc encodes the number of bytes to be written. The command is rejected if one attempts to write across the file boundary. As listed in Table 37, ISOUpdateBinary is allowed only if at least one of FileAR.Write and FileAR.ReadWrite access rights associated with the targeted file is granted. It must be set to 0xE, i.e. free access, as the command is only accepted in VCState.NotAuthenticated, i.e. not supporting EV2 secure messaging. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 86 / 209

6.16 Trust Provisioning

6.16.1 Originality Check Key Pair and Certificate

During manufacturing, A30 is trust-provisioned with an ECC-based key pair and related certificate to allow verification of the genuineness of the IC. The originality check is done by executing a card-unilateral authentication through a challenge-response protocol. As the protocol creates a trace that potentially cannot be repudiated, the key pair is shared by all ICs in one production batch to reduce the privacy implications. On top, the feature can be disabled through SetConfiguration Option 0x0E.

6.16.1.1 Originality Key Pair

The Originality Check key pair (Priv.Orig, Pub.Orig) is trust-provisioned with the following properties. For KeyPolicy and Read/WriteAccess encoding, refer to ManageKeyPair API definition.

Shared key pair per batch.
Priv.Orig is stored as ECCPrivateKey KeyNo 0x01 at the PICC level, with following default configuration: – NIST P-256 – KeyPolicy: 0x0100, only allowing ECC-based Unilateral Authentication. – WriteAccess: 0x30. For A30, this access right is irrelevant as A30 does not support reader authentication at the PICC level. – KUCLimit: disabled

6.16.1.2 Originality Certificate

The Originality Check certificate is stored in a FileType.StandardData file, as introduced in Section 6.10.1.1, at the PICC level. It can be freely read upfront the authentication using the supported data management (see Section 6.11.1) and standard ISO/IEC 7816-4 commands (see Section 6.15.1) for data file access. Access to the file can be disabled by enabling the enhanced privacy feature, see SetConfiguration. The file holding the certificate is a FileType.StandardData file of 384 bytes with the following properties:

FileNo = 0x01; ISO File ID = 0xEF01 FileAR.Read is relevant, as one cannot authenticate at the PICC -level. This file holds the NXP Originality Certificate Cert.Orig. If needed, the file content is further padded with all zero bytes. The NXP Originality Certificate is signed by NXP Trust Provisioning using a dedicated CA key pair for this product. The CA key pair can be retrieved from https://www.gp-ca.nxp.com/CA/getCA?caid=63709320110003 filling in the CAID with the serialNumber encoded in the issuer name. The NXP Originality Certificate certificate is a public-key certificate according to X.509 v3 format [29]. Optional fields from [29] have been omitted, that is, the certificate will not contain additional issuerUniqueID, subjectUniqueID, and extensions. The signature algorithm used is ECDSA with SHA-256. The issuer is set to the following content:
Organizational name (O, OID 2.5.4.10): “NXP”
Common name (CN, OID 2.5.4.3): “NXP Orig RootCAvE2xx” with xx varying per product variant
SerialNumber (OID 2.5.4.5): 14 digits encoding CAID A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 87 / 209

The subject contains a subset of GetVersion: VendorID || HWMajorVersion || HWMinorVersion || SWType || SWSubType || SWMajorVersion || SWMinorVersion. This is encoded in a description (OID 2.5.4.13)[29], using hexadecimal ASCII encoding.

6.16.1.3 Card-unilateral authentication

The authentication supported by Priv.Orig is outlined in Section 6.3.3.

6.16.2 Application Key Pair and Certificate

At application-level, in the default configuration, A30 is trust-provisioned during manufacturing with an App- level key pair (Priv.App, Pub.App) and related certificate Cert.App. This can be used to authenticate individual devices for executing App-level functionality.

6.16.2.1 Application Key Pair

The application key pair (Priv.App, Pub.App) is a unique key pair per die from which the Priv.App is stored as ECCPrivateKey KeyNo 0x00 within the application, holding with following default configuration:

NIST P-256
KeyPolicy: 0x0004, only allowing SIGMA-I Mutual Authentication. Note that by default both Prover and Verifier mode are enabled. For privacy (non-traceability), only Prover may be preferred, with requires configuration per interface (I2C) via SetConfiguration Option 0x0F/0x10.
WriteAccess: 0x30, allowing replacement with ManageKeyPair after an authentication granting AppMasterKey access rights in CommMode.Full.
KUCLimit: disabled. For KeyPolicy and WriteAccess encoding, refer also to ManageKeyPair API definition. Pub.App is trusted via the certificate Cert.App, as specified in the next subsection.

6.16.2.2 Application Certificate

The Cert.App is stored as an uncompressed end-leaf certificate without parent certificates within a certificate repository, seeSection 6.8.1, with id 0x00, with following default configuration:

Associated with the ECCPrivateKey with KeyNo 0x00.
Repository size: [TBD]
WriteAccess: 0x30, allowing ManageCertRepo after an authentication granting AppMasterKey access rights in CommMode.Full.
ReadAccess: 0x30, allowing ReadCertRepo after an authentication granting AppMasterKey access rights in CommMode.Full. Note that typically the certificate is only to be retrieved via the SIGMA-I authentication itself. Though if needed this configuration can be changed, requiring the certificate to be re-loaded.
No mapping table, this means the certificate is stored as a plain X.509 certificate without any PKCS#7 wrapping. The certificate repository is already activated and thus ready for use with the SIGMA-I authentication. The Cert.App is signed by NXP Trust Provisioning using a dedicated key pair. The CA key pair can be retrieved from https://www.gp-ca.nxp.com/CA/getCA?caid=63709320101003 filling in the CAID with the serialNumber encoded in the issuer name. The Cert.App is a public-key certificate according to X.509 v3 format [11]. It has the same structure as the Cert.Orig defined in subsection 17.1.2 with the following content. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 88 / 209

The issuer is set to:

Organizational name (O, OID 2.5.4.10): “NXP”
Common name (CN, OID 2.5.4.3): “NXP Auth RootCAvE2xx” with xx varying per product variant
SerialNumber (OID 2.5.4.5): 14 digits encoding CAID The subject is set to:
Description (OID 2.5.4.13), containing a subset of GetVersion: VendorID || HWMajorVersion || HWMinorVersion || SWType || SWSubType || SWMajorVersion || SWMinorVersion, using hexadecimal ASCII encoding.
UniqueIdentifier (OID 2.5.4.45) with 7-byte UID as a BIT STRING

6.16.3 Commercial customization options

NXP provides commercial customization options for trust-provisioning. This allows for a customer-dedicated delivery configuration. This may include the provisioning of a customer-specific CARootKey. This allows to do the initial personalizaiton with the ECC-based SIGMA-I authentication. By this, the need for a secure environment can be removed, compared to when doing the initial personalization based on the default AES keys. Additionally, also customer-specific AES keys, certificates and/or a customized file system and configuration can be provisioned. Reach out to your local sales representative for more information.

6.17 Security

6.17.1 Introduction

NXP Semiconductors has gained comprehensive security experience from developing more than six generations of certified secure microcontrollers and other security certified products. The large number of approved features and the significant enhancements over the different generations of certified secure products and secure microcontrollers are the foundation of the security concept that is implemented in the A30 product. These mentioned design features related to security ensure to protect the integrity and confidentiality of user data and applications. The unique security design is built on over one hundred dedicated security mechanisms which create a dense protection shield with redundancy and multiple layers. The security mechanisms provide a comprehensive response to the wide variety of known and expected security attacks. As attacks evolve over time, the distributed approach of the implemented security architecture allows for more proactive and continuous enhancements of the security mechanisms compared to alternative and less versatile approaches. This makes the underlying security architecture of A30 a future-proof concept that´s built into the product, that effectively counters side channel and fault attacks as well as reverse engineering efforts. The following sections describe a subset of the security features that are implemented on A30. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 89 / 209

6.17.2 Reset

The following types of resets and reset sources can be distinguished:

normal application power-on reset, triggered by the on-chip power-on reset circuit
internal reset, triggerable by – Dedicated software reset – On-chip security sensors – Electrical operating condition category – Internal physical attack category – Data integrity protection category Two different reset severities can be distinguished in the A30 hardware. The"normal" chip resets and the "security" resets.

6.17.3 Sensor Architecture

The following sensors are implemented on A30:

Electrical operation condition category – Low Frequency Sensor – High Frequency Sensor – Low Voltage Sensor – High Voltage Sensor
Internal physical attack category – Low Temperature Sensor – High Temperature Sensor – Light Sensors – Glitch Sensors – Active Shielding – ISO/IEC 14443 Frequency Sensor
Data integrity protection category – RAM Integrity Error – ROM Integrity Error – FLASH Integrity Error – internal Bus and Register Integrity Error

6.17.4 Scalable Security

A30 implements an error counter. The error counter uses a dedicated memory area in the FLASH within a dedicated, protected memory area. The error counter is decremented for security critical errors. The Scalable Security feature enables additional security countermeasures during operation based on the error counter values to avoid exploitation of repeated attacks. This results in a significant performance degradation in case of repeated security resets, if A30 detects that it is under security attacks. From system design perspective this behavior has to be considered to avoid a non functional system due to timeouts by the host in case of activated Scalable Security features. Therefore timeouts should be defined with significant margins in case of additional security countermeasures are activated. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 90 / 209

7 Command set

7.1 Introduction

show the wrapped format as supported by A30. For further explanation, see Section 6.2.2.

7.2 Supported commands and APDUs

IncrementCounterFile 90 F8 00 00 5 Data 00 Data 9100 CommMode of targeted file. ReadData 90 AD 00 00 07 Data 00 Data 9100 CommMode of targeted file. WriteData 90 8D 00 00 XX Data 00 - 9100 CommMode of targeted file. Table 42. APDUs...continued A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.3 Authentication and Secure Messaging

7.3.1 ISOGeneralAuthenticate

The detailed description of this command can be found in Section 6.3.2. Figure 18. ISOGeneralAuthenticate command protocol Table 43. Command summary - ISOGeneralAuthenticate Table 44. Command description - ISOGeneralAuthenticate Table 45. Response description - ISOGeneralAuthenticate Table 46. Error code description - ISOGeneralAuthenticate A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

ISO6700 0x6700 Wrong or inconsistent APDU length. ISO6985 0x6985 Wrapped chained command or multiple pass command ongoing. ISO6985 0x6985 Not supported at PICC level. Table 46. Error code description - ISOGeneralAuthenticate ...continued

7.3.2 ISOInternalAuthenticate

The detailed description of this command can be found in Section 6.3.3.3. Figure 19. ISOInternalAuthenticate command protocol Description: Asymmetric card-unilateral authentication. Table 47. Command summary - ISOInternalAuthenticate At application level, up to five keys are supported. Table 48. Command Description - ISOInternalAuthenticate A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

L: 0x00..0xE9 Length of Value field. Card will accept other lengths and ignore the Value field. 0x00/0x0000 Any expected length up to resp. 256/65536 bytes. 0x56..0xFFFF Max expected length must be at least 86 bytes. Table 48. Command Description - ISOInternalAuthenticate ...continued Table 49. Response description - ISOInternalAuthenticate Resp.ISO6700 0x6700 Wrong or inconsistent APDU length. Table 50. Error code description - ISOInternalAuthenticate A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Resp.ISO6985 0x6985 ECC-based Card-Unilateral Authentication disabled over I2C interface. Resp.ISO6985 0x6985 KeyUsageCtrLimit enabled for targeted key has been reached. Resp.ISO6987 0x6987 Expected DO missing. Resp.ISO6987 0x6987 Unexpected DO recieved. Resp.ISO6A86 0x6A86 Wrong parameter P1: different from 0x00. Resp.ISO6A86 0x6A86 Wrong parameter P2: RFU bits set. Resp.ISO6A88 0x6A88 Wrong parameter P2: Key targeted by PrivKeyNo does not exist. Resp.ISO6C00 0x6C00 Wrong Le: expected length insufficient for response data. Table 50. Error code description - ISOInternalAuthenticate ...continued

7.3.3 AuthenticateEV2First

The detailed description of this command can be found in Section 6.3.4.1. Figure 20. AuthenticateEV2First command protocol Description: Symmetric mutual authentication. This authentication is intended to be the first in a transaction. Table 51. Command summary - AuthenticateEV2First A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

1 Targeted authentication key

LenCap 1 0x00 to 0x06 Length of the PCD Capabilities. [This value should be set to 0x00]. [1] - Capability vector of the PCD. PCDcap2.2-6 [1..5] Full range Capability vector of the PCD. Table 52. Command description - AuthenticateEV2First - Part1 Table 53. Response description - AuthenticateEV2First - Part1 COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. Targeted key not available for authentication. AES-based Symmetric Authentication disabled over I2C interface. AuthCtrLimit enabled for AES-based authentication has been reached. Table 54. Error code description - AuthenticateEV2First - Part1 A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

32 Full range

RndA: 16 byte random from PCD.

Table 55. Command description - AuthenticateEV2First - Part2

32 Full range Encrypted PICC response

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

Table 56. Response description - AuthenticateEV2First - Part2 LENGTH_ERROR 0x7E Command size not allowed. Table 57. Error code description - AuthenticateEV2First - Part2 A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.3.4 AuthenticateEV2NonFirst

The detailed description of this command can be found in Section 6.3.4.2. Figure 21. AuthenticateEV2NonFirst command protocol after AuthenticateEV2First in a transaction. Table 58. Command summary - AuthenticateEV2NonFirst Table 59. Command description - AuthenticateEV2NonFirst - Part1

RndB (16 byte): Random number from the PICC.

COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. Not in VCState.AuthenticatedAES. Targeted key not available for authentication. AES-based Symmetric Authentication disabled over I2C interface. Table 61. Error code description - AuthenticateEV2NonFirst - Part1

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

Table 62. Command description - AuthenticateEV2NonFirst - Part2

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

Table 63. Response description - AuthenticateEV2NonFirst - Part2 LENGTH_ERROR 0x7E Command size not allowed. Table 64. Error code description - AuthenticateEV2NonFirst - Part2 A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.3.5 ProcessSM

color coding of the different fields does not apply to distinguish CmdHeader and CmdData parameters. Figure 22. ProcessSM command protocol codes. Specific operations are further defined by dedicated subcommands. Table 65. Command summary - ProcessSM Table 66. Command Description - ProcessSM Table 67. Response Description - ProcessSM COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. PARAMETER_ERROR 0x9E Invalid action. PERMISSION_DENIED 0x9D ProcessSM disabled for the targeted interface. PERMISSION_DENIED 0x9D Not supported at PICC level. Table 68. Error code description - ProcessSM A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 68. Error code description - ProcessSM ...continued

7.3.6 ProcessSM_Apply

Figure 23. Protocol ProcessSM_Apply Description: Applies secure messaging for the given command. Table 69. Command summary - ProcessSM_Apply 0x01 Apply secure messaging. Table 70. Command Description - ProcessSM_Apply A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

0x01..0xEF Index of the first byte of CmdData in Data field. Table 70. Command Description - ProcessSM_Apply...continued Table 71. Response Description - ProcessSM_Apply LENGTH_ERROR 0x7E If CommMode.MAC, Data length bigger than 240 is not supported. LENGTH_ERROR 0x7E If CommMode.Full, Data length bigger than 239 is not supported. INTEGRITY_ERROR 0x1E If CommMode.Plain,CmdCtr reaches 0xFFFF or overflows. INTEGRITY_ERROR 0x1E If CommMode.MAC or CommMode.Full, CmdCtr reached 0xFFFF already. Table 72. Error code description - ProcessSM_Apply

7.3.7 ProcessSM_Remove

Figure 24. Protocol ProcessSM_Remove Description: Applies secure messaging for the given command. Table 73. Command summary - ProcessSM_Remove A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 74. Command Description - ProcessSM_Remove Table 75. Response Description - ProcessSM_Remove LENGTH_ERROR 0x7E If CommMode.MAC, Data length bigger than 252 is not supported. LENGTH_ERROR 0x7E If CommMode.Full, Data length bigger than 249 is not supported. Table 76. Error code description - ProcessSM_Remove A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.4 Memory and Configuration Management

7.4.1 FreeMem

Figure 25. FreeMem command protocol Description: Returns the free memory available on the card. Table 77. Command summary - FreeMem Table 78. Command description - FreeMem Table 79. Response description - FreeMem - OPERATION_OK COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. INTEGRITY_ERROR 0x1E Invalid secure messaging MAC. LENGTH_ERROR 0x7E Command size not allowed. MEMORY_ERROR 0xEE Failure when reading or writing to non-volatile memory. Table 80. Error code description - FreeMem A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.4.2 SetConfiguration

The detailed description of this command can found in Command SetConfiguration. Figure 26. SetConfiguration command protocol Description: Configures several aspects of the application. Table 81. Command Description - SetConfiguration whereas the Data is always transmitted in CommMode.Full. 0x04 Secure Messaging Configuration. Table 82. Command description - SetConfiguration A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 82. Command description - SetConfiguration ...continued Table 83. Response description - SetConfiguration COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. INTEGRITY_ERROR 0x1E Invalid cryptogram (padding or CRC). Invalid secure messaging MAC. LENGTH_ERROR 0x7E Command size not allowed. Table 84. Error code description - SetConfiguration A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

PARAMETER_ERROR 0x9E Parameter value not allowed. Option 0x00: Data bit 7-2 or bit 0 not set to 0b. Option 0x02: TL inconsistent with length of received ATS string. Option 0x02: Data bit 7-2 or bit 0 not set to 0b. Option 0x0D: given REQS equals given WUPS. Option 0x0F: unsupported protocol set. Option 0x10: unsupported protocol set. Option 0x13: unsupported cache size set. Option 0x13: unsupported feature selected. Option 0x14: unsupported timer value. Option 0x16: unsupported AuthCtrOption. Option 0x17: unsupported configuration. Option 0xFE: unsupported Option or Method values. Unsupported option (i.e. Reserved). FILE_NOT_FOUND 0xF0 Option 0x16: invalid AuthCtrFileID: file does not exist. AUTHENTICATION_ERROR 0xAE No active authentication with AppMasterKey. Table 84. Error code description - SetConfiguration...continued

7.4.3 GetConfiguration

The detailed description of this command can be found in Section 6.5.2.2. Figure 27. GetConfiguration command protocol Description: Retrieves configuration aspects of the card or the application. Table 85. Command summary - GetConfiguration A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Limited range For supported options, see SetConfiguration. Table 86. Command Description - GetConfiguration option value as defined in Table 1. Table 87. Response description - GetConfiguration COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. INTEGRITY_ERROR 0x1E Invalid secure messaging MAC. LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Unsupported Option. PERMISSION_DENIED 0x9D Option not supported at PICC level. PERMISSION_DENIED 0x9D Option disabled by product configuration, see SetConfiguration. issued Option, see SetConfiguration. access rights if issued without Option. Table 88. Error code description - GetConfiguration A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.4.4 ActivateConfiguration

The detailed description of this command can be found in Section 7.4.4. Figure 28. ActivateConfiguration command protocol Description: Activates a deferred configuration. Table 89. Command summary - ActivateConfiguration ConfCount 1 0x01 .. 0x04 Number of configurations to be activated (N). must hold one or more of following values. Table 90. Command Description - ActivateConfiguration on option value as defined in Table 1. Table 91. Response description - ActivateConfiguration A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. INTEGRITY_ERROR 0x1E Invalid secure messaging MAC. LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. Table 92. Error code description - ActivateConfiguration

7.4.5 GetVersion

The detailed description of this command can be found in Section 6.5.1.1. Figure 29. GetVersion command protocol Description: Returns manufacturing related data. Table 93. Command summary - GetVersion Table 94. Command parameters description - GetVersion - Part1 A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 94. Command parameters description - GetVersion - Part1 ...continued Table 95. Response description - GetVersion - Part1 CMD 1 0xAF Additional frame request. Table 96. Command parameters description - GetVersion - Part2 Table 97. Response description - GetVersion - Part2 A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 97. Response description - GetVersion - Part2 ...continued CMD 1 0xAF Additional frame request. Table 98. Command parameters description - GetVersion - Part3 Table 99. Response description - GetVersion - Part3 A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 99. Response description - GetVersion - Part3 ...continued COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. INTEGRITY_ERROR 0x1E Invalid secure messaging MAC (only). LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. Table 100. Error code description - GetVersion

7.4.6 GetCardUID

The detailed description of this command can be found in Command. Figure 30. GetCardUID command protocol Description: Returns manufacturing related data. Table 101. Command summary - GetCardUID Table 102. Command parameters description - GetCardUID Table 103. Response description - GetCardUID A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 103. Response description - GetCardUID ...continued COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. INTEGRITY_ERROR 0x1E Invalid secure messaging MAC (only). LENGTH_ERROR 0x7E Command size not allowed. PERMISSION_DENIED 0x9D Not supported at PICC level. AUTHENTICATION_ERROR 0xAE No active authentication with AppPrivacyKey while enabled. Table 104. Error code description - GetCardUID

7.5 Symmetric Key management

7.5.1 ChangeKey

The detailed description of this command can be found in Section 6.6.4.1. Figure 31. ChangeKey command protocol Description: This command updates a symmetric key. Table 105. Command summary - ChangeKey Table 106. Command description - ChangeKey A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

1 - Key number of the key to be changed. Table 106. Command description - ChangeKey ...continued A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 107. Response description - ChangeKey COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. PERMISSION_DENIED 0x9D Not allowed at PICC level. Table 108. Error code description - ChangeKey A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.5.2 GetKeySettings

The detailed description of this command can found in Section 6.6.4.2. Figure 32. GetKeySettings command protocol Description: This command retrieves the meta-data of certain key types. Table 109. Command Description - GetKeySettings Table 110. Command description - GetKeySettings A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

selected application. Additionally the key type is returned. 0x05 Number of application keys. Table 111. Response description - GetKeySettings - [No Option byte provided] EntryCount 1 0x08 Number of key information entries (n) that will follow. Entry[1] KeyType: KeyType.AES128 or KeyType.AES256. Entry[2..3] KeyPolicy, see ChangeKey. Table 112. Response description - GetKeySettings - [Option = 0x00] CryptoRequestKey's meta-data EntryCount 1 0x00..0x05 Number of key information entries (n) that will follow.

List with meta-data, see ManageKeyPair.

Table 113. Response description - GetKeySettings - [Option = 0x01] ECCPrivateKey's meta-data A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

EntryCount 1 0x00..0x05 Number of key information entries (n) that will follow.

List with meta-data, see ManageCARootKey.

Table 114. Response description - GetKeySettings - [Option = 0x02] CARootKey's meta-data COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. PERMISSION_DENIED 0x9D Option different from 0x01 not supported at PICC level. AUTHENTICATION_ERROR 0xAE No active authentication with AppMasterKey. Table 115. Error code description - GetKeySettings A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.5.3 GetKeyVersion

The detailed description of this command can found in Section 6.6.4.3. Figure 33. GetKeyVersion command protocol Description: This command retrieves the key version of the key targeted. Table 116. Command Description - GetKeyVersion Table 117. Command parameters description - GetKeyVersion Table 118. Response description - GetKeyVersion COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. INTEGRITY_ERROR 0x1E Invalid secure messaging MAC (only). LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. Table 119. Error code description - GetKeyVersion A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

NO_SUCH_KEY 0x40 Targeted key does not exist. Table 119. Error code description - GetKeyVersion ...continued

7.6 Asymmetric Key Management

7.6.1 ManageKeyPair

The detailed description of this command can be found in Section 6.7.1.1. Figure 34. ManageKeyPair command protocol Description: Creates or updates a private key entry by generating a key pair or importing a private key. command as defined by SetConfiguration 0x12. Table 120. ManageKeyPair 1 - Key number of the key to be managed. Table 121. Command Description - ManageKeyPair A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

2 - Defines the allowed crypto operations with the targeted key. 4 - Defines the key usage limit of the targeted key. KeyUsageCtrLimit enabled with the given value (LSB first). Table 121. Command Description - ManageKeyPair ...continued A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 122. Response description - ManageKeyPair COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. NO_SUCH_KEY 0x40 Targeting nonexisting key while trying to update metadata. PERMISSION_DENIED 0x9D Not allowed at PICC level. PERMISSION_DENIED 0x9D Targeting existing key with its WriteAccess condition set to 0xF. associated with the targeted key. currently configured KeyUsageCtrLimit. PERMISSION_DENIED 0x9D Trying to import key while disabled by product configuration. PERMISSION_DENIED 0x9D Trying to update metadata while disabled by product configuration. different from 0xF not being granted. ManageKeyPair access condition is not granted while different to 0xF. Table 123. Error code description - ManageKeyPair A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

0x0E Insufficient free user memory available for creating new key. Table 123. Error code description - ManageKeyPair ...continued

7.6.2 ManageCARootKey

The detailed description of this command can be found in Section 6.7.2.1. Figure 35. ManageCARootKey command protocol Description: Creates or updates a public key entry. command as defined by SetConfiguration 0x12. Table 124. ManageCARootKey 1 - Key number of the key to be managed. AccessRights 2 Limited range Access rights associated with the CARootKey, see Table 18.

Write CommMode (see Table 14).

Full range Access condition (see Table 17). 0x00 No trusted issuer name check required. 0x01..0xFF Length of Issuer. Trusted issuer name of IssuerLen bytes. Table 125. Command Description - ManageCARootKey ...continued Table 126. Response description - ManageCARootKey Resp.COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. Resp.LENGTH_ERROR 0x7E Command size not allowed. Resp.PARAMETER_ERROR 0x9E Parameter value not allowed. Resp.PERMISSION_DENIED 0x9D Not allowed at PICC level. Resp.PERMISSION_DENIED 0x9D Targeting existing key with its WriteAccess condition set to 0xF. is not granted while different from 0xF. key different from 0xF not being granted. Table 127. Error code description - ManageKeyPair A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Resp.OUT_OF_MEMORY_ERROR 0x0E Insufficient free user memory available for creating this file. Table 127. Error code description - ManageKeyPair ...continued

7.6.3 GetKeySettings

7.7 Certificate Management

7.7.1 ManageCertRepo

The detailed description of this command's usage can be found in Section 6.8.1. Figure 36. ManageCertRepo command protocol CommMode: CommMode of ManageCertRepo as defined by SetConfiguration 0x13. execution and repository modification. Table 128. Command Description - ManageCertRepo A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

5 Table 129 [if option is create certificate repository]

2 Table 132 [if option is reset certificate repository]

Table 128. Command Description - ManageCertRepo ...continued Bit 5-4 CommMode, see Table 14. Bit 3-0 AccessCondition Value, see Table 17. Bit 5-4 CommMode, see Table 14. Bit 3-0 AccessCondition Value, see Table 17. Table 129. ManageCertRepo - Create Certificate Repository Table 130. ManageCertRepo - Load Certificate A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 131. ManageCertRepo - Load Certificate Mapping info Bit 5-4 CommMode, see Table 14. Bit 3-0 AccessCondition Value, see Table 17. Bit 5-4 CommMode, see Table 14. Bit 3-0 AccessCondition Value, see Table 17. Table 132. ManageCertRepo - Reset Certificate Repository Resp.COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. Resp.INTEGRITY_ERROR 0x1E MAC does not match data. Resp.PARAMETER_ERROR 0x9E Parameter value not allowed. Resp.PERMISSION_DENIED 0x9D Not supported at PICC level. Table 133. ManageCertRepo - Error Conditions A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 133. ManageCertRepo - Error Conditions...continued

7.7.2 ReadCertRepo

The detailed description of this command's usage can be found in Section 6.8.1. Figure 37. ReadCertRepo command protocol Table 134. Command Description - ReadCertRepo must have been created using ManageKeyPair). Table 135. ReadCertRepo - Response Data Format for Metadata A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Bit 5-4 CommMode, see Table 14. Bit 5-4 CommMode, see Table 14. Bit 3-0 AccessCondition Value, see Table 17. Table 135. ReadCertRepo - Response Data Format for Metadata ...continued Table 136. ReadCertRepo - Response Data Format for Certificate Resp.COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. Resp.INTEGRITY_ERROR 0x1E MAC does not match data. Resp.PARAMETER_ERROR 0x9E Parameter value not allowed. Resp.PERMISSION_DENIED 0x9D Not supported at PICC level. Table 137. Error Code Description - ReadCertRepo A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.8 File Management

7.8.1 CreateStdDataFile

The detailed description of this command can be found in Section 6.10.4.1. Figure 38. CreateStdDataFile command protocol Description: Creates files for the storage of plain unformatted user data. Table 138. Command Description - CreateStdDataFile 1 - File number of the file to be created. 1 - Options for the targeted file. Table 139. Command description - CreateStdDataFile A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 139. Command description - CreateStdDataFile...continued Table 140. Response description - CreateStdDataFile COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. INTEGRITY_ERROR 0x1E Invalid secure messaging MAC. application but not present in the received command. DataFile.AccessRights does not exist. Not supported at PICC level. SAI given but no 2nd application selected. Trying to pre-enable SDM on File 0x1F. StdDataFile.ISOFileID already exists. Table 141. Error code description - CreateStdDataFile A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

available for creating this file. application exceeded if creating this file. MEMORY_ERROR 0xEE Failure when reading or writing to nonvolatile memory. Table 141. Error code description - CreateStdDataFile...continued

7.8.2 CreateCounterFile

The detailed description of this command can be found in Section 6.10.4.2. Figure 39. CreateCounterFile command protocol Description: Creates a Counter File. Table 142. CreateCounterFile 1 - File number of the file to be created. AccessRights 2 Limited range Set of access conditions (see Table 17). Table 143. Command Description - CreateCounterFile A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 144. Response description - CreateCounterFile Resp.COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. Resp.INTEGRITY_ERROR 0x1E Invalid secure messaging MAC. Resp.LENGTH_ERROR 0x7E Command size not allowed. Resp.PARAMETER_ERROR 0x9E Parameter value not allowed. Resp.AUTHENTICATION_ERROR 0xAE No active authentication with AppMasterKey. Resp.DUPLICATE_ERROR 0xDE File with the targeted FileNo already exists. Resp.OUT_OF_MEMORY_ERROR 0x0E Insufficient free user memory available for creating this file. Table 145. Error code description - CreateCounterFile

7.8.3 GetFileIDs

The detailed description of this command can be found in Section 6.10.3.3. Figure 40. GetFileIDs command protocol Description: Returns the File IDentifiers of all active files within the currently selected application. Table 146. Command Description - GetFileIDs Table 147. Command description - GetFileIDs A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 147. Command description - GetFileIDs...continued Table 148. Response description - GetFileIDs COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. INTEGRITY_ERROR 0x1E Invalid secure messaging MAC. LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. PERMISSION_DENIED 0x9D Not supported at PICC level. MEMORY_ERROR 0xEE Failure when reading or writing to nonvolatile memory. Table 149. Error code description - GetFileIDs A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.8.4 GetISOFileIDs

The detailed description of this command can be found in Section 6.10.3.4. Figure 41. GetISOFileIDs command protocol Description: Get back the ISO File IDs. Table 150. Command Description - GetISOFileIDs Table 151. Command description - GetISOFileIDs FIDList n*2 with n in [0..27] - List of n ISO File IDs. ISO File IDs, i.e. never a partial ISO File ID is sent. Table 152. Response description - GetISOFileIDs A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. INTEGRITY_ERROR 0x1E Invalid secure messaging MAC. LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. PERMISSION_DENIED 0x9D Not supported at PICC level. MEMORY_ERROR 0xEE Failure when reading or writing to nonvolatile memory. Table 153. Error code description - GetISOFileIDs

7.8.5 GetFileSettings

The detailed description of this command can be found in Section 6.10.3.1. Figure 42. GetFileSettings command protocol Description: Get information on the properties of a specific file. Table 154. Command Description - GetFileSettings 1 - File number of the targeted file. Table 155. Command description - GetFileSettings A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

File Type of the targeted file.

1 - Options for the targeted file. FileSize 3 - File size of the targeted file. Table 156. Response description - GetFileSettings - Targeting FileType.StandardData A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

File Type of the targeted file.

1 - Options for the targeted file. Table 157. Response description - GetFileSettings - Targeting FileType.Counter COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. INTEGRITY_ERROR 0x1E Invalid secure messaging MAC (only). LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. FILE_NOT_FOUND 0xF0 File with targeted FileNo does not exist for the targeted application. Table 158. Error code description - GetFileSettings A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.8.6 GetFileCounters

The detailed description of this command can be found in Section 6.10.3.2. Figure 43. GetFileCounters command protocol Table 159. Command Description - GetFileCounters FileNo 1 - File number of the targeted file. Table 160. Command description - GetFileCounters SDMReadCtr 3 Full Range Current SDMReadCtr of the targeted file (LSB first). Table 161. Response description - - Targeting FileType.StandardData with SDM enabled. FileCtr 4 Full Range The current 32-bit value (LSB first). Table 162. Response description - - Targeting FileType.Counter. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

PICC level (MF) is selected. Targeted FileType.StandardData file has SDMCtrRet access right set to 0xF. authentication with the wrong key. FILE_NOT_FOUND 0xF0 File with targeted FileNo does not exist for the targeted application. Table 163. Error code description - GetFileCounters

7.8.7 ChangeFileSettings

The detailed description of this command can be found in Section 6.10.2.3. Figure 44. ChangeFileSettings command protocol Description: Changes the access parameters and other configurations of an existing file. Table 164. Command summary - ChangeFileSettings Table 165. Command description - ChangeFileSettings A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

1 - File number of the targeted file. 1 - Options for the targeted file. Bit 1-0 CommMode (see Table 14). the file (see Section 6.10.2). Table 165. Command description - ChangeFileSettings ...continued A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 166. Response description - ChangeFileSettings COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. INTEGRITY_ERROR 0x1E Integrity error in cryptogram. Invalid Secure Messaging MAC (only). LENGTH_ERROR 0x7E Command size not allowed. Parameter value not allowed. and SDMReadCtr mirroring are disabled. Trying to set FileAR.SDMMetaRead to 0xF, while enabling UID mirroring. Table 167. Error code description - ChangeFileSettings A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

possible if FileAR.SDMFileRead = 0xF. Trying to set a SDMReadCtrLimit while not enabling SDMReadCtr. PICC level (MF) is selected. access right Change of targeted file has access conditions set to 0xF. Enabling Deferred Configuration is only allowed for FileNo 0x02. FILE_NOT_FOUND 0xF0 File with targeted FileNo does not exist for the targeted application. Table 167. Error code description - ChangeFileSettings ...continued A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

CERT_ERROR 0xCE Active ECC-based authentication not granting FileAR.Change access rights.

7.9 Data Management

7.9.1 ReadData

The detailed description of this command can be found in Section 6.11.1.1. Figure 45. ReadData command protocol Description: Reads data from FileType.StandardData files. CommMode: CommMode of targeted file. Table 168. Command summary - ReadData 1 - File number of the targeted file. Starting position for the read operation.

Number of bytes to be read.

specified in the offset value. Table 169. Command parameters description - ReadData A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 170. Response description - ReadData Targeted file is not of FileType.StandardData. targeted StandardData file only have access conditions set to 0xF. SDMReadCtr is equal or bigger than its SDMReadCtrLimit. Targeted FileNo 0x01 at PICC level, while Originality Check is disabled. entry is enabled and reached. CERT_ERROR 0xCE Active ECC-based authentication not granting the required access rights. Table 171. Error code description - ReadData A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.9.2 WriteData

The detailed description of this command can be found in Section 6.11.1.2. Figure 46. WriteData command protocol Description: Writes data to FileType.StandardData files. CommMode: CommMode of targeted file. Table 172. Command summary - WriteData 1 - File number of the targeted file. Starting position for the write operation. Number of bytes to be written. Data X Full range Data to be written. Table 173. Command parameters description - WriteData Table 174. Response description - WriteData COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. Table 175. Error code description - WriteData A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

INTEGRITY_ERROR 0x1E Invalid secure messaging MAC or encryption padding. LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. PICC level (MF) is selected. Targeted file is not of FileType.StandardData. Write and ReadWrite of targeted file only have access conditions set to 0xF. FILE_NOT_FOUND 0xF0 Targeted file does not exist in the targeted application. conditions is different from 0xF. CERT_ERROR 0xCE Active ECC-based authentication not granting the required access rights. BOUNDARY_ERROR 0xBE Attempt to write beyond the file boundary as set during creation. Table 175. Error code description - WriteData ...continued

7.9.3 IncrementCounterFile

The detailed description of this command can be found in Section 6.11.2.1. Figure 47. IncrementCounterFile command protocol Description: Increments a Counter File. CommMode: CommMode of targeted file. Table 176. IncrementCounterFile 1 - File number of the file to be incremented. Table 177. Command Description - IncrementCounterFile A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

IncrValue 4 Full Range Value to be incremented. LSB first. Table 177. Command Description - IncrementCounterFile ...continued Table 178. Response description - IncrementCounterFile Resp.COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. Resp.INTEGRITY_ERROR 0x1E Invalid secure messaging MAC. Resp.LENGTH_ERROR 0x7E Command size not allowed. Resp.PARAMETER_ERROR 0x9E Parameter value not allowed. Resp.PERMISSION_DENIED 0x9D Not supported at PICC level. Resp.PERMISSION_DENIED 0x9D Targeted file is not of FileType.Counter. Resp.FILE_NOT_FOUND 0xF0 Targeted file does not exist. at least one of the access conditions is different from 0xF. granting the required access rights. Resp.BOUNDARY_ERROR 0xBE File with the targeted FileNo already exists. Table 179. Error code description - IncrementCounterFile A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.10 Crypto API

data fields may be further restricted if secure messaging must be applied. Figure 48. CryptoRequestcommand protocol CommMode: CommMode of CryptoRequest as defined by SetConfiguration 0x15. Table 180. Command Description - CryptoRequest A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Resp.COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. Resp.INTEGRITY_ERROR 0x1E MAC does not match data. Resp.PERMISSION_DENIED 0x9D Not supported at PICC level. Table 181. Error Code Description - CryptoRequest

7.10.1 CryptoRequest SHA

multiple steps allows the input data to be taken from different sources. Table 182. CryptoRequest SHA - SHA Init Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 183. CryptoRequest SHA - SHA Update Operation Table 184. CryptoRequest SHA - SHA Finalize Operation Table 185. CryptoRequest SHA - SHA One-Shot Operation Table 186. Response description - SHA Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.10.2 CryptoRequest RNG

Maximum number of generated bytes is 128. Table 187. CryptoRequest RNG - RNG Operation Table 188. Response description - RNG Operation Table 189. Error Code Description - RNG Operation

7.10.3 CryptoRequest ECC_Sign

command buffer (64 bytes of raw signature data). Private Key Id 1 0x00 - 0x04 Id of the ECC key pair containing the private key to use. Table 190. CryptoRequest ECC_Sign - ECC Sign Init Operation Table 191. CryptoRequest ECC_Sign - ECC Sign Update Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 191. CryptoRequest ECC_Sign - ECC Sign Update Operation...continued Table 192. CryptoRequest ECC_Sign - ECC Sign Finalize Operation Private Key Id 1 0x00 - 0x04 Id of the ECC key pair containing the private key to use. Table 193. CryptoRequest ECC_Sign - ECC Sign One-Shot Operation Private Key Id 1 0x00 - 0x04 Id of the ECC key pair containing the private key to use. Table 194. CryptoRequest ECC_Sign - ECC Sign One-Shot Pre-computed Hash Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 195. Response description - ECC Sign Operation Table 196. Error Code Description - ECC Sign Operation

7.10.4 CryptoRequest ECC_Verify

Table 197. CryptoRequest ECC_Verify - ECC Sign Init Operation Table 198. CryptoRequest ECC_Verify - ECC Verify Update Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 198. CryptoRequest ECC_Verify - ECC Verify Update Operation...continued Table 199. CryptoRequest ECC_Verify - ECC Verify Finalize Operation Table 200. CryptoRequest ECC_Verify - ECC Verify One-Shot Operation Table 201. CryptoRequest ECC_Verify - ECC Verify One-Shot Pre-computed Hash Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 201. CryptoRequest ECC_Verify - ECC Verify One-Shot Pre-computed Hash Operation...continued Table 202. Response description - ECC Verify Operation Table 203. Error Code Description - ECC Verify Operation

7.10.5 CryptoRequest ECC DH

shall be either the command buffer or an internal buffer. output in the command buffer. The shared secret shall be output to the destination specified.. Table 204. CryptoRequest ECC_DH - ECC DH Single-step Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 205. CryptoRequest ECC_DH - ECC DH Two-step Step 1 Table 206. CryptoRequest ECC_DH - ECC DH Two-step Step 2 Table 207. Response description - ECC DH Operation Table 208. Error Code Description - ECC DH Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.10.6 CryptoRequest AES

supported by a static key are defined by the KeyPolicy set via the ChangeKey command. Table 209. Crypto API AES Key Selection one-shot operation, the result destination can be an internal buffer. ICV Source [1] Table 38 Only present for CBC operations. Table 210. Crypto API AES Key Selection - AES Enc/Dec Init Operation Table 211. Crypto API AES Key Selection - AES Enc/Dec Update Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 212. Crypto API AES Key Selection - AES Enc/Dec Finalize Operation Table 213. Crypto API AES Key Selection - Format of crypto API AES Enc/Dec multi-part operation response ICV Source [1] Table 38 Only present for CBC operations. Table 214. Crypto API AES Key Selection - AES Enc/Dec One-Shot Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 215. Crypto API AES Key Selection - Format of crypto API AES Enc/Dec One-shot operation response Table 216. Error Code Description - AES Operation

7.10.7 CryptoRequest AES CMAC

supported by a static key are defined by the KeyPolicy set via the ChangeKey command. The CMAC Signature shall be output to the command buffer (16 bytes of raw signature data). Table 217. CryptoRequest AES CMAC - AES CMAC Sign Init Operation Table 218. CryptoRequest AES CMAC - AES CMAC Sign Update Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 219. CryptoRequest AES CMAC - AES CMAC Sign Finalize Operation Table 220. CryptoRequest AES CMAC - AES CMAC Sign One-shot Operation Table 221. CryptoRequest AES CMAC - Format of crypto API AES CMAC Sign response data shall be 0x5A5A upon successful verification or 0xA5A5 if verification fails. Table 222. CryptoRequest AES CMAC - AES CMAC Verify Init Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 222. CryptoRequest AES CMAC - AES CMAC Verify Init Operation...continued Table 223. CryptoRequest AES CMAC - AES CMAC Verify Update Operation Table 224. CryptoRequest AES CMAC - AES CMAC Verify Finalize Operation Table 225. CryptoRequest AES CMAC - AES CMAC Verify One-shot Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 226. CryptoRequest AES CMAC - Format of crypto API AES CMAC Verify response data does not match the Total Input data length field. Table 227. Error Code Description - AES Operation

7.10.8 CryptoRequest AES AEAD

supported by a static key are defined by the KeyPolicy set via the ChangeKey command. result destination can be an internal static or transient buffer. AAD Length 1 0xXX Number of AAD bytes. Table 228. CryptoRequest AES AEAD - AES AEAD Initialize Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

input data can be processed. Result Destination [1] Table 38 Only present when Action is 0x0C Decrypt/Verify. Table 228. CryptoRequest AES AEAD - AES AEAD Initialize Operation...continued Table 229. CryptoRequest AES AEAD - Format of crypto API AES AEAD Initialize operation response data AAD Length 1 0xXX Number of AAD bytes. any input data can be processed. Result Destination 1 Table 38 Only present when Action is 0x0C Decrypt/Verify. Table 230. CryptoRequest AES AEAD - AES AEAD Update Operation Table 231. CryptoRequest AES AEAD - Format of crypto API AES AEAD Update operation response data A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

AAD Length 1 0xXX Number of AAD bytes. Tag Data [XX] - Only present when Action is 0x0C Decrypt/Verify. Result Destination 1 Table 38 Only present when Action is 0x0C Decrypt/Verify. Table 232. CryptoRequest AES AEAD - AES AEAD Finalize Operation Verification Result [2] - 0x5A5A for successful verification, 0xA5A5 for failed verification. Only present when Action is 0x0C Decrypt/Verify. Table 233. CryptoRequest AES AEAD - Format of crypto API AES AEAD finalize operation response data Table 234. CryptoRequest AES AEAD - AES AEAD One-Shot Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

AAD Length 1 0xXX Number of AAD bytes. Tag Data [XX] - Only present when Action is 0x0C Decrypt/Verify. Result Destination 1 Table 38 Only present when Action is 0x0C Decrypt/Verify. Table 234. CryptoRequest AES AEAD - AES AEAD One-Shot Operation...continued verification. Only present when Action is 0x0C Decrypt/Verify. Table 235. CryptoRequest AES AEAD - Format of crypto API AES AEAD One-shot operation response data Table 236. Error Code Description - AES Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

not match the Total Input data length field. Table 236. Error Code Description - AES Operation...continued

7.10.9 CryptoRequest Write Internal Buffer

loaded for use within other crypto API operations. Table 237. CryptoRequest - Write Internal Buffer Operation Table 238. Response description - Write Internal Buffer

7.10.10 CryptoRequest HMAC

It is possible to execute an HMAC calculation using a single command or as a series of commands. signature verification result shall give response data 0xA5A5. Table 239. CryptoRequest HMAC - HMAC Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 239. CryptoRequest HMAC - HMAC Operation...continued Table 240. Response description - HMAC Verify Operation Table 241. Response description - HMAC Sign Operation Table 242. Error Code Description - HMAC Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.10.11 CryptoRequest HKDF

HKDF, as defined in RFC5869, requires execution of the extract operation followed by the expand operation. The API uses a secure SHA implementation. Table 243. CryptoRequest HKDF - HKDF Extract and Expand Operation buffer. Length must be equal to the Hash byte length. Info Length 1 0x01 to 0x50 Length of context and info data. Note: Zero length is not supported. Table 244. CryptoRequest HKDF - HKDF Expand Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 245. Response description - HKDF Operation Table 246. Error Code Description - HKDF Operation HKDF expand operation fails with error message 910E if Info Length is zero.

7.10.12 CryptoRequest Echo

Table 247. CryptoRequest Echo - Echo Operation Table 248. Response description - Echo Operation A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.11 GPIO Management

7.11.1 ManageGPIO

The detailed description of this command can be found in Section 6.13.1. Figure 49. ManageGPIO command protocol Description: Manages the GPIO output. CommMode: CommMode of ManageGPIO as defined by SetConfiguration 0x11. Table 249. ManageGPIO ’00’ CLEAR: clear the GPIO state to LOW (not driven). ’01’ SET: set the GPIO State to HIGH (driven). Table 250. Command Description - ManageGPIO A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

’10’ TOGGLE: toggle the GPIO State. Table 250. Command Description - ManageGPIO ...continued Table 251. Response description - ManageGPIO [else] Resp.COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. Resp.LENGTH_ERROR 0x7E Command size not allowed. Resp.PARAMETER_ERROR 0x9E Parameter value not allowed. Resp.PERMISSION_DENIED 0x9D Not supported at PICC level. Table 252. Error code description - ManageGPIO

7.11.2 ReadGPIO

The detailed description of this command can be found in Section 6.13.2. Figure 50. ReadGPIO command protocol Description: Returns the GPIO statuses. Table 253. ReadGPIO A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

CommMode: CommMode of ReadGPIO as defined by SetConfiguration 0x11. Table 253. ReadGPIO...continued Table 254. Command Description - ReadGPIO

GPIOStatus bytes as defined in Table 41.
GPIOStatus bytes as defined in Table 41.
GPIOStatus bytes as defined in Table 41.

COMMAND_ABORTED 0xCA Chained command or multiple pass command ongoing. LENGTH_ERROR 0x7E Command size not allowed. PARAMETER_ERROR 0x9E Parameter value not allowed. PERMISSION_DENIED 0x9D Not supported at PICC level. PERMISSION_DENIED 0x9D ReadGPIOAccessCondition is configured for no access (0x0F). Table 256. Error code description - ReadGPIO

7.12 ISO7816-4 Support

7.12.1 ISOSelectFile

The detailed description of this command can be found in Section 6.15.1.4. Figure 51. ISOSelectFile command protocol Table 257. Command summary - ISOSelectFile Table 258. Command description - ISOSelectFile A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 258. Command description - ISOSelectFile ...continued Table 259. Response description - ISOSelectFile ISO6700 0x6700 Wrong or inconsistent APDU length. ISO6985 0x6985 Wrapped chained command or multiple pass command ongoing. ISO6A82 0x6A82 Application or file not found, currently selected application remains selected. Table 260. Error code description - ISOSelectFile A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.12.2 ISOReadBinary

The detailed description of this command can be found in Section 6.15.1.5. Figure 52. ISOReadBinary command protocol Table 261. Command summary - 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. 0b P1 - P2 (15 bits) encode an offset from zero to 32767. 0x00 Targeting currently selected file.

The number of bytes to be read from the file.

starting from the offset position is returned. Table 262. Command description - ISOReadBinary A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 263. Response description - ISOReadBinary ISO6700 0x6700 Wrong or inconsistent APDU length. Security status not satisfied: SDMReadCtr overflow. Security status not satisfied: AuthenticatedAES not allowed. Security status not satisfied: AuthenticatedECC not allowed. ISO6985 0x6985 Wrapped chained command or multiple pass command ongoing. Attempt to read outside file boundaries. Table 264. Error code description - ISOReadBinary A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

7.12.3 ISOUpdateBinary

The detailed description of this command can be found in Section 6.15.1.6. Figure 53. ISOUpdateBinary command protocol Table 265. Command summary - ISOUpdateBinary P1[Bit 4..0] encode a short ISO FileID. P2[Bit 7..0] encode an offset from zero to 255. 0b P1 - P2 (15 bits) encode an offset from zero to 32767. 0x00 Targeting currently selected file. Table 266. Command description - ISOUpdateBinary A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

Table 267. Response description - ISOUpdateBinary ISO6700 0x6700 Wrong or inconsistent APDU length. Security status not satisfied: AuthenticatedAES not allowed. Security status not satisfied: AuthenticatedECC not allowed. ISO6985 0x6985 Wrapped chained command or multiple pass command ongoing. Attempt to write beyond the file boundary as set during creation. Table 268. Error code description - ISOUpdateBinary A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

8 Limiting values

In accordance with the Absolute Maximum Rating System (IEC 60134). Voltages are referenced to VSS (ground = 0 V). Table 269. Limiting values [3] Depending on the appropriate thermal resistance of the package. electrostatic sensitive devices. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

9 Recommended operating conditions

A30 is characterized by its specified operating supply voltage range of 1 V to 2 V. Table 270. Recommended operating conditions [1] The supply voltage operating range of 1 V to 2 V requires internal supply elevation for the supply voltage range of 1 V to 1.62 V. The supply voltage mode is automatically selected during boot-up based on internal supply voltage measurement. the application to reopen the session. the device boots in voltage elevation mode. For VCC supply voltages >1.62 V the supply voltage ramp shall therefore >600 μs. [2] All product properties and values specified within this data sheet are only valid within the operating ambient temperature range. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

10 Characteristics

10.1 DC characteristics

respect to the ground contact pad VSS. All currents flowing into the device are considered positive.

10.1.1 General-purpose I/O interface

External pullup resistor 20 kΩ to VCC assumed. The worst case test condition for parameter VOH is present at minimum VCC.

0.7 VCC ≤ VI ≤ VCC

0 V ≤ VI ≤ VCC;

0 V VILmax

Figure 54. Input characteristics of GPIO1/2

10.1.2 I2C interface

10.1.3 Power Consumption

Table 273. Electrical characteristics of IC supply voltage VCC

10.2 AC characteristics

Table 274. Authentication application timing Table 275. Nonvolitile memory timing characteristics [1] Typical values are only referenced for information. They are subject to change without notice. [2] The given value specifies physical access times of FLASH memory only. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

SCL, SDA pads in open-drain mode. Table 276. Electrical AC characteristics of SDA, SCL [1] All appropriately marked values are typical values and only referenced for information. They are subject to change without notice. [3] tr is defined as rise time between 30 % and 70 % of the signal amplitude. [4] tf is defined as fall time between 70 % and 30 % of the signal amplitude.

10.3 I2C Bus Timings

The A30 I2C bus timing parameters are in accordance to the NXP I2C bus specification, see Section 13.

10.4 EMC/EMI

A30 is either offered as Wafer Level Chip-Scale Package (WLCSP), or HVQFN.

11.1 WLCSP 16

Figure 55. Package outline WLCSP (Top view) Figure 56. Package outline WLCSP (Bottom view) A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved.

11.2 HVQFN 20

HVQFN thickness is 0.85 mm with a pitch is 0.5 mm. A detailed description can be found in "Delivery Specification [11]" A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 192 / 209

12 Abbreviations

13 References

[1] User Guidance Manual A30 Information on Guidance and Operation, Doc. No. UM9763[1] [2] ISO/IEC 14443-3:2018 Identification cards -- Contactless integrated circuit cards -- Proximity cards -- Part 3: Initialization and anti- collision [3] ISO/IEC 14443-4:2018 Identification cards -- Contactless integrated circuit cards -- Proximity cards -- Part 4: Transmission protocol [4] ISO/IEC 7816-4:2020 Identification cards – Integrated circuit cards – Part 4: Organization, security and commands for interchange [5] FIPS PUB 197 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, ADVANCED ENCRYPTION STANDARD (AES), National Institute of Standards and Technology, 2001 November 26 [6] NIST Special Publication 800-38A National Institute of Standards and Technology (NIST). Recommendation for BlockCipher Modes of Operation. http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf [7] NIST Special Publication 800-38B National Institute of Standards and Technology (NIST). Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication. http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf [8] ISO/IEC 9797-1:1999 Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher. [9] NIST Special Publication 800-108 National Institute of Standards and Technology (NIST). Recommendation for key derivation using pseudorandom functions. [10] IEEE Std 802.3-2008 IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 3: Carrier sense multiple access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. [11] Data sheet addendum A30 - Delivery specification, Document number AD9772[1] [12] Certicom Research. Sec 1 Elliptic curve cryptography. Version 2.0, May 2009. [13] Product data sheet NXP Semiconductors, NTAG213/215/216: NFC Forum Type 2 Tag compliant IC with 144/504/888 bytes user memory, Document number 2653[1] [14] NFC Forum: Type 4 Tag - Technical Specification NFC Forum: Type 4 Tag - Technical Specification - Version 1.0 - [T4T] - 2016.07.26, 07 2016. [15] User manual UM10204 I2C-bus specification and user manual, Rev. 7, 10 2021. [16] GlobalPlatform Globalplatform technology - apdu transport over spi / i2c - version 1.0. Version 1.0, January 2020 [17] National Institute of Standards and Technology (NIST) [1] … document version number A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 196 / 209

Federal Information Processing Standard (FIPS) 180- 4: Secure Hash Standard (SHS). NIST FIPS PUB 180-4, August 2015. [18] ISO/IEC 8825-1:2015 ISO JTC 1/SC 6. Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). ISO/IEC 8825-1:2015, November 2015. [19] ISO/IEC 9798-3:2019 ISO JTC 1/SC 27. Information technology – Security techniques – Entity authentication – Part 3: Mechanisms using digital signature techniques. ISO/IEC 9798-3:2019, 2019. [20] IEEE Std 802.3-2008 IEEE Computer Society. IEEE Standard for Information Technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements Part 3: Carrier sense multiple access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. IEEE Std 802.3-2008, December 2008. [21] Proposal for: Functionality classes for random number generators A proposal for: Functionality classes for random number generators, Wolfgang Killmann, T-Systems GEI GmbH, Werner Schindler, Bundesamt für Sicherheit in der Informationstechnik (BSI), Version 2.0, 18 September 2011 [22] BSI-CC-PP-0084-2014 Security IC Platform Protection Profile with Augmentation Packages, Registered and Certified by Bundesamt für Sicherheit in der Informationstechnik (BSI) under the reference BSI-CC-PP-0084-2014, Version 1.0, 13 January 2014. [23] FIPS PUB 186-5 FIPS PUB 186-5 (Draft): Digital Signature Standard (DSS), Federal Information Processing Standards Publication, US Department of Commerce/National Institute of Standards and Technology, October 2019. [24] FIPS PUB 198-1 FIPS PUB 198-1: The Keyed-Hash Message Authentication Code (HMAC), Federal Information Processing Standards Publication 198-1, US Department of Commerce/ National Institute of Standards and Technology, July 2008 [25] NIST SP 800-38C NIST SP 800-38C: Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality, Morris Dworkin, National Institute of Standards and Technology, May 2004. [26] NIST SP 800-38D NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/ Counter Mode (GCM) and GMAC, Morris Dworkin, National Institute of Standards and Technology, November 2007. [27] NIST SP 800-56A Logarithm Cryptography, National Institute of Standards and Technology, April 2018. [28] RFC 5869 RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF), Internet Engineering Task Force (IETF), Request For Comments, May 2010. [29] ISO/IEC 9594-8 ISO/IEC 9594-8:2020 Information technology - Open systems interconnection - Part 8: The Directory: Public key and attribute certificate frameworks - Ninth edition, 11 2020. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 197 / 209

14 Note about the source code in the document

Example code shown in this document has the following copyright and BSD-3-Clause license: Copyright 2023-2025 NXP Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials must be provided with the distribution. 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 198 / 209

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 https://www.nxp.com. Definitions Draft — A draft status on a document indicates that the content is still under internal review and subject to formal approval, which may result in modifications or additions. NXP Semiconductors does not give any representations or warranties as to the accuracy or completeness of information included in a draft version of a document and shall have no liability for the consequences of use of such information. Short data sheet — A short data sheet is an extract from a full data sheet with the same product type number(s) and title. A short data sheet is intended for quick reference only and should not be relied upon to contain detailed and full information. For detailed and full information see the relevant full data sheet, which is available on request via the local NXP Semiconductors sales office. In case of any inconsistency or conflict with the short data sheet, the full data sheet shall prevail. Product specification — The information and data provided in a Product data sheet shall define the specification of the product as agreed between NXP Semiconductors and its customer, unless NXP Semiconductors and customer have explicitly agreed otherwise in writing. In no event however, shall an agreement be valid in which the NXP Semiconductors product is deemed to offer functions and qualities beyond those described in the Product data sheet. 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 https://www.nxp.com/profile/terms, unless otherwise agreed in a valid written individual agreement. In case an individual agreement is concluded only the terms and conditions of the respective agreement shall apply. NXP Semiconductors hereby expressly objects to applying the customer’s general terms and conditions with regard to the purchase of NXP Semiconductors products by customer. No offer to sell or license — Nothing in this document may be interpreted or construed as an offer to sell products that is open for acceptance or the grant, conveyance or implication of any license under any copyrights, patents or other industrial or intellectual property rights. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 200 / 209

Quick reference data — The Quick reference data is an extract of the product data given in the Limiting values and Characteristics sections of this document, and as such is not complete, exhaustive or legally binding. Export control — This document as well as the item(s) described herein may be subject to export control regulations. Export might require a prior authorization from competent authorities. Suitability for use in non-automotive qualified products — Unless this document 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. HTML publications — An HTML version, if available, of this document is provided as a courtesy. Definitive information is contained in the applicable document in PDF format. If there is a discrepancy between the HTML document and the PDF document, the PDF document has priority. Translations — A non-English (translated) version of a document, including the legal information in that document, is for reference only. The English version shall prevail in case of any discrepancy between the translated and English versions. Security — Customer understands that all NXP products may be subject to unidentified vulnerabilities or may support established security standards or specifications with known limitations. Customer is responsible for the design and operation of its applications and products throughout their lifecycles to reduce the effect of these vulnerabilities on customer’s applications and products. Customer’s responsibility also extends to other open and/or proprietary technologies supported by NXP products for use in customer’s applications. NXP accepts no liability for any vulnerability. Customer should regularly check security updates from NXP and follow up appropriately. Customer shall select products with security features that best meet rules, regulations, and standards of the intended application and make the ultimate design decisions regarding its products and is solely responsible for compliance with all legal, regulatory, and security related requirements concerning its products, regardless of any information or support that may be provided by NXP. NXP has a Product Security Incident Response Team (PSIRT) (reachable at PSIRT@nxp.com) that manages the investigation, reporting, and solution release to security vulnerabilities of NXP products. NXP B.V. — NXP B.V. is not an operating company and it does not distribute or sell products. Trademarks Notice: All referenced brands, product names, service names, and trademarks are the property of their respective owners. NXP — wordmark and logo are trademarks of NXP B.V. Bluetooth — the Bluetooth wordmark and logos are registered trademarks owned by Bluetooth SIG, Inc. and any use of such marks by NXP Semiconductors is under license. DESFire — is a trademark of NXP B.V. I2C-bus — logo is a trademark of NXP B.V. Matter, Zigbee — are developed by the Connectivity Standards Alliance. The Alliance's Brands and all goodwill associated therewith, are the exclusive property of the Alliance. MIFARE — is a trademark of NXP B.V. NTAG — is a trademark of NXP B.V. SmartMX — is a trademark of NXP B.V. A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 201 / 209

Tab. 8. Asymmetric authentication Protocols Tab. 13. When to use which authentication Tab. 19. Application access rights, specified via Tab. 20. Application access rights, specified via Tab. 21. Manufacturer characteristics used as card Tab. 36. FileAR.SDMFileRead and Tab. 37. Command list associated with access Tab. 38. Crypto API Data Source/Destination Tab. 43. Command summary - Tab. 44. Command description - Tab. 45. Response description - Tab. 46. Error code description - Tab. 47. Command summary - Tab. 48. Command Description - Tab. 49. Response description - Tab. 50. Error code description - Tab. 52. Command description - Tab. 53. Response description - Tab. 54. Error code description - Tab. 55. Command description - Tab. 56. Response description - Tab. 57. Error code description - Tab. 58. Command summary - Tab. 59. Command description - Tab. 60. Response description - Tab. 61. Error code description - Tab. 62. Command description - Tab. 63. Response description - Tab. 64. Error code description - Tab. 73. Command summary - ProcessSM_Remove . 103 Tab. 74. Command Description - ProcessSM_ Tab. 75. Response Description - ProcessSM_ Tab. 76. Error code description - ProcessSM_ Tab. 79. Response description - FreeMem - A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 202 / 209

Tab. 89. Command summary - Tab. 90. Command Description - Tab. 91. Response description - Tab. 92. Error code description - Tab. 94. Command parameters description - Tab. 96. Command parameters description - Tab. 98. Command parameters description - Tab. 102. Command parameters description - Tab. 111. Response description - GetKeySettings - Tab. 112. Response description - GetKeySettings - [Option = 0x00] CryptoRequestKey's meta- Tab. 113. Response description - GetKeySettings - [Option = 0x01] ECCPrivateKey's meta- Tab. 114. Response description - GetKeySettings - Tab. 117. Command parameters description - Tab. 125. Command Description - Tab. 126. Response description - Tab. 129. ManageCertRepo - Create Certificate Tab. 131. ManageCertRepo - Load Certificate Tab. 132. ManageCertRepo - Reset Certificate Tab. 135. ReadCertRepo - Response Data Format Tab. 136. ReadCertRepo - Response Data Format Tab. 138. Command Description - CreateStdDataFile .. 132 Tab. 156. Response description - GetFileSettings - Tab. 157. Response description - GetFileSettings - Tab. 161. Response description - - Targeting Tab. 162. Response description - - Targeting Tab. 165. Command description - Tab. 166. Response description - ChangeFileSettings ..146 Tab. 167. Error code description - A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 203 / 209

Tab. 169. Command parameters description - Tab. 173. Command parameters description - Tab. 177. Command Description - Tab. 178. Response description - Tab. 179. Error code description - Tab. 183. CryptoRequest SHA - SHA Update Tab. 184. CryptoRequest SHA - SHA Finalize Tab. 185. CryptoRequest SHA - SHA One-Shot Tab. 190. CryptoRequest ECC_Sign - ECC Sign Init Tab. 191. CryptoRequest ECC_Sign - ECC Sign Tab. 192. CryptoRequest ECC_Sign - ECC Sign Tab. 193. CryptoRequest ECC_Sign - ECC Sign Tab. 194. CryptoRequest ECC_Sign - ECC Sign Tab. 195. Response description - ECC Sign Tab. 196. Error Code Description - ECC Sign Tab. 197. CryptoRequest ECC_Verify - ECC Sign Init Tab. 198. CryptoRequest ECC_Verify - ECC Verify Tab. 199. CryptoRequest ECC_Verify - ECC Verify Tab. 200. CryptoRequest ECC_Verify - ECC Verify Tab. 201. CryptoRequest ECC_Verify - ECC Verify Tab. 202. Response description - ECC Verify Tab. 203. Error Code Description - ECC Verify Tab. 204. CryptoRequest ECC_DH - ECC DH Single- Tab. 205. CryptoRequest ECC_DH - ECC DH Two- Tab. 206. CryptoRequest ECC_DH - ECC DH Two- Tab. 207. Response description - ECC DH Operation .. 161 Tab. 208. Error Code Description - ECC DH Tab. 210. Crypto API AES Key Selection - AES Enc/ Tab. 211. Crypto API AES Key Selection - AES Enc/ Tab. 212. Crypto API AES Key Selection - AES Enc/ Tab. 213. Crypto API AES Key Selection - Format of crypto API AES Enc/Dec multi-part Tab. 214. Crypto API AES Key Selection - AES Enc/ Tab. 215. Crypto API AES Key Selection - Format of crypto API AES Enc/Dec One-shot Tab. 217. CryptoRequest AES CMAC - AES CMAC Tab. 218. CryptoRequest AES CMAC - AES CMAC Tab. 219. CryptoRequest AES CMAC - AES CMAC Tab. 220. CryptoRequest AES CMAC - AES CMAC Tab. 221. CryptoRequest AES CMAC - Format of crypto API AES CMAC Sign response data .. 165 Tab. 222. CryptoRequest AES CMAC - AES CMAC Tab. 223. CryptoRequest AES CMAC - AES CMAC Tab. 224. CryptoRequest AES CMAC - AES CMAC Tab. 225. CryptoRequest AES CMAC - AES CMAC Tab. 226. CryptoRequest AES CMAC - Format of crypto API AES CMAC Verify response Tab. 228. CryptoRequest AES AEAD - AES AEAD Tab. 229. CryptoRequest AES AEAD - Format of crypto API AES AEAD Initialize operation Tab. 230. CryptoRequest AES AEAD - AES AEAD Tab. 231. CryptoRequest AES AEAD - Format of crypto API AES AEAD Update operation Tab. 232. CryptoRequest AES AEAD - AES AEAD A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 204 / 209

Tab. 233. CryptoRequest AES AEAD - Format of crypto API AES AEAD finalize operation Tab. 234. CryptoRequest AES AEAD - AES AEAD Tab. 235. CryptoRequest AES AEAD - Format of crypto API AES AEAD One-shot operation Tab. 237. CryptoRequest - Write Internal Buffer Tab. 238. Response description - Write Internal Tab. 240. Response description - HMAC Verify Tab. 241. Response description - HMAC Sign Tab. 243. CryptoRequest HKDF - HKDF Extract and Tab. 244. CryptoRequest HKDF - HKDF Expand Tab. 251. Response description - ManageGPIO [else] . 176 Tab. 273. Electrical characteristics of IC supply A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 205 / 209

Fig. 7. Session key generation for Secure Fig. 9. Secure Messaging: MAC Communication Fig. 11. Secure Dynamic Messaging for Reading Fig. 13. Conceptual View of Host Verification Public Fig. 18. ISOGeneralAuthenticate command Fig. 21. AuthenticateEV2NonFirst command A30 All information provided in this document is subject to legal disclaimers. © 2025 NXP B.V. All rights reserved. Product data sheet Rev. 3.0 — 27 January 2025 Document feedback 976730 206 / 209

6.10.2.1 Secure Dynamic Messaging Related

6.15.1.2 Security concepts of standard ISO/IEC

14 Note about the source code in the

Please be aware that important notices concerning this document and the product(s) described herein, have been included in section 'Legal information'. © 2025 NXP B.V. All rights reserved. For more information, please visit: https://www.nxp.com Document feedback Date of release: 27 January 2025 Document identifier: A30 Document number: 976730

Product Information

A30LDJHN2 specifications and overview.

Summary

Secure Authenticator Rev. 3.0 27 January 2025

Description

Secure Authenticator Rev. 3.0 27 January 2025

Source title A30LDJHN2 Datasheet(PDF) - NXP Semiconductors

Related Parts

More parts from the same family.

Browse manufacturer