i.MX8 DXL V2X

Certificate

Approved Algorithms (47)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for i.MX8 DXL V2X
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>firmware load<br/>load firmware<br/>update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>unauthenticated<br/>Status output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for i.MX8 DXL V2X
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>firmware load<br/>load firmware<br/>update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>unauthenticated<br/>Status output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

i.MX8 DXL V2X Document Version 1.3 October 08, 2024 Prepared for: Prepared by: NXP Semiconductors KeyPair Consulting Inc. MIKRONWEG 1 987 Osos Street

Austria USA NXP.com keypair.us

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy Table of Contents List of Tables List of Figures NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy Acronyms and Definitions NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

Model i.MX 8SoloXLite i.MX 8SoloXLite i.MX 8DualXLite

Hardware [Part Number and Version] MIMX8SL2AVNFZAB PIMX8SL2AVNFZAB MIMX8DL2AVNFZAB

Firmware Version

Distinguishing Features The MIM8SL2AVNFZA B and PIM8SL2AVNFZA B parts feature

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy This document defines the Security Policy for the NXP Semiconductors i.MX8 DXL V2X hardware sub-chip cryptographic subsystem with a single-chip embodiment, hereafter denoted the V2X or the Module. The Module is a limited operational environment under the [FIPS 140-3] definitions. The Module includes a firmware load function. New firmware versions within the scope of this validation must be validated through the CMVP; any other firmware loaded into the Module is out of the scope of this validation and requires a separate [FIPS 140-3] validation. The Module is validated to FIPS 140-3 overall Level 3 requirements with security levels as follows: Table 1: Security Levels The hardware Module is a sub-chip subsystem of a single-chip embodiment that provides cryptographic engine and secure storage functions, intended for use in automotive applications. The Module includes the SECO sub-chip subsystem that is used in other devices; the V2X provides additional acceleration capability to the SECO HSM functionality. As there are several redundant security function implementations, the corresponding tables are separated into V2X and SECO blocks as a convenience to the reviewer. In circumstances where the information is applicable to the complete Module, a single table is provided. The Module is available in the configurations shown in Table 2: Cryptographic Module Tested Configuration . Table 2: Cryptographic Module Tested Configuration NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy

The Module implements the Approved and allowed cryptographic functions listed below. [57P1r5] notation is used throughout this document to describe key sizes and security strength. All references to the algorithm standards cited below can be found in the References section of this document. Table 3: Approved Algorithms NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy The Module facilitates the use of truncated MACing but enforces a minimum of 32 bits

• see [107]. NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

A2972, A2973

KAS-3

Schemes: Ephemeral Unified, One-Pass DH Roles: Initiator, Responder KAS-ECC-SSC curves: P-256, P-384 TLS v1.2 KDF TLS v1.2 KDF RFC7627

SP 800-56Arev3. KAS-ECC per IG D.F Scenario 2 path (2) option 2 P-256 and P-384 curves providing 128 or 192 bits of encryption strength

Key agreement to establish TLSv1.2 session keys and the corresponding intermediate values for pre- master secret TLS- PMS and master secret TLS-MS

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy AES GCM is used by the Sensitive Data Storage service. In accordance with [140IG] C.H Scenario 2, the 96-bit IV is generated randomly in its entirety using the Approved DRBG within the Module boundary and maintained within the Module boundary by the Symmetric Cipher service. Due to the excessive length of time taken for the counter to wrap, the counter cannot practically wrap within the lifetime of the module. The DRBG seed is generated inside the Module boundary, and the Module’s entropy source has been assessed in accordance with [140IG] D.K for conformance to [90B]. AES GCM is also used to support TLS primitives and adheres to the [140IG] C.H Resolution 1a TLS 1.2 protocol IV generation requirements. The Module uses the KAS-ECC-SSC function as follows (without support for key confirmation): 1. KEK KAS: To establish an SDS-KEK compliant to [140IG] D.F Scenario 2 Path 2, option 2 (KAS-ECC-SSC using curve P-256 or BrainpoolP256R1 and One-Step Hash KDF)2; KAS (KAS-SSC Cert. # A2972 or A2977, KDA Cert. # A2965 or A2976); provides 128 bits of strength NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy The Module supports the following ciphersuites used in TLS primitives:

1. Hex Enum: 0xC0,0x2B IETF Cipher Suite Enumeration: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 RFC: 5289 TLS: v1.2 Kex: ECDHE Sig: ECDSA PRF: HMAC-SHA2-256 Cipher: AES-128 Auth: GCM
2. Hex Enum: 0xC0,0x2C IETF Cipher Suite Enumeration: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 RFC: 5289 TLS: v1.2 Kex: ECDHE Sig: ECDSA PRF: HMAC-SHA2-384 Cipher: AES-256 Auth: GCM
3. Hex Enum: 0xC0,0xAD IETF Cipher Suite Enumeration: TLS_ECDHE_ECDSA_WITH_AES_256_CCM RFC: 7251 TLS: v1.2 Kex: ECDHE Sig: ECDSA PRF: HMAC-SHA2-256 Cipher: AES-256 Auth: CCM
4. Hex Enum: 0xC0,0x23 IETF Cipher Suite Enumeration: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 RFC: 5289 TLS: v1.2 Kex: ECDHE Sig: ECDSA PRF: HMAC-SHA2-256 Cipher: AES-128 Auth: HMAC
5. Hex Enum: 0xC0,0x24 IETF Cipher Suite Enumeration: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 RFC: 5289 TLS: v1.2 Kex: ECDHE Sig: ECDSA PRF: HMAC-SHA2-384 Cipher: AES-256 Auth: HMAC NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy Table 4: Non-Approved Algorithms Allowed in the Approved Mode of Operation Table 5: Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed The Module does not implement the following:

• Non-Approved Algorithms Not Allowed in the Approved Mode of Operation NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy

The Module is a subsystem of the i.MX8 DXL SoC, incorporating a SECO (security controller) block which has been separately validated for use in other scenarios with additional acceleration implemented in the V2X block. The Module is compliant to [140IG] 2.3.B Sub-Chip Cryptographic Subsystems:

• The physical boundary is the single-chip physical boundary as described above.
• The sub-chip cryptographic subsystem boundary is the set of components depicted in Figure 2 within the dashed red line, with corresponding V2X and SECO HSM firmware.
• The Module boots from internal masked ROM but requires a firmware container to be loaded into RAM: during the initialization period, the loaded firmware is verified with an approved authentication method in accordance with [FIPS 140-3 DTR] firmware load test requirements.
• The ports and interfaces are defined at the sub-chip cryptographic subsystem boundary, as depicted in Figure 2.
• Private and secret keys cross the sub-chip and physical boundaries only in the form of AES-GCM authenticated ciphertext blobs, meeting [FIPS 140-3 IG] 9.5.A and D.G requirements. An authentication token is provided in plaintext over a Trusted Path from a source within the physical boundary of the Module.
• The function of the Tamper I/O signals is to (optionally) support one or more tamper mesh mechanisms external to the device. The physical form of the Module (i.e. the Tested Operational Environment’s Physical Perimeter (TOEPP) of CM) is depicted in Figure 1 (represents all models and P/Ns listed in Table 2). The cryptographic boundary is the surface, edges, and solder bump connections of the chip package. Figure 1: Module Physical Form NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy Figure 2 depicts the Module sub-chip functions, with the sub-chip cryptographic boundary depicted as the dashed red line, and the chip physical boundary depicted as the outer solid black line. SoC functions outside the sub-chip cryptographic subsystem boundary are simplified. The hardware PRNG is depicted for completeness but not used. Figure 2: Module Block Diagram

The Module as defined above will always be in an Approved mode of operation. No configuration is necessary for the Module to operate and remain in the Approved mode. The Management service Get Info message responses (SECO and V2X variants) includes the information shown next; chip lifecycle and Approved mode constitute the indicator of the Approved mode. For the part numbers in this validation, the SECO and V2X are configured in the factory for the Approved mode. • 32-bit SECO FW version: 0x50090 (corresponding to SECO FW 5.9.0); • 32-bit Extended version, SECO FW commit ID: 0x80649c52; • 32-bit V2X FW version: 0x10021 (corresponding to V2X FW 1.2.1); • 32-bit Extended version, V2X FW commit ID: 0x75e63de241c; • 8-bit chip lifecycle state: 0x80; • SECO Approved mode: 8-bit field, only the last two bits are used; 0x3 indicates a validated part in the Approved mode. • V2X Approved mode: 8-bit field, only the last two bits are used; 0x3 indicates a validated part in the Approved mode. The Module implementation enforces the following security rules:

1. The Module supports two types of operator roles: Cryptographic Officer and User.
2. The Module does not support a maintenance interface or role.
3. The Module provides identity-based authentication.
4. An operator does not have access to any cryptographic services prior to assuming an authorized role, with the exception of the services listed as unauthenticated services. These services do not require use of secret or private keys and conform to [FIPS 140-3 IG] 4.1.A.
5. Pre-operational self-tests do not require any operator action.
6. No additional interface or service is implemented by the Module which would provide access to CSPs.
7. Data output is inhibited during self-tests, zeroisation, and error states.
8. The Module clears previous authentications on power cycle.
9. The Module does not support manual key entry. NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy

10. The Module does not output plaintext CSPs or intermediate key values.
11. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the Module.
12. The Module’s TLS support corresponds to [FIPS 140-3 IG] D.C case 2 (providing a CAVP validated TLS v1.2 KDF), which requires the following statement: No parts of the TLS protocol, other than the approved cryptographic algorithms and the KDF, have been tested by the CAVP or CMVP. The Module design corresponds to the Module security rules. The Module is validated to FIPS 140-3 overall Security Level

3 requirements with security levels as listed in Table 1 above in this document. No initialization requirements apply to the

Module. NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy

The Module’s ports and interfaces are listed in Table 6 below, including the designation of [FIPS 140-3] logical interface types. Note that the Module’s ports and interfaces are identical to the SECO HSM in isolation, with the exception of MU connections to the primary V2X block. The NXP provided SECO HSM API provides a driver level interface to external callers which hides the details of V2X accelerators, requiring only simple flags to use the V2X accelerator features. DC in the Table Physical port column refers to Device Connection:

• Yes means the port is available at the physical boundary (solder ball).
• No means the port is completely internal to the physical boundary. In Figure 2 and Table , System Bus refers to the address/data bus with hardware enforced access control that connects major i.MX8 DXL SoC subsystems. In Table 6, the System Bus: CAAM interface includes the logical interface used to store AES GCM encapsulated keys (Key Management and Sensitive Data Storage services) or data (Generic Data Storage service) in external NVM. The system control CPU outside the sub-chip cryptographic subsystem boundary has write-only access to the M0+ RAM only during boot to load the SECO firmware (dashed line); following boot, the M0+ RAM is accessible only by the M0+ Core. The Module uses the Private Bus to provide parameters required by media controllers, for example, for a video processing unit. These parameters are used by algorithms that execute outside the Module boundary; they are not used by the Module and unrelated to Module security. Table 6: Ports and Interfaces NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy VSS, VDD Power input Power input The 32-bit Authentication Token used for the User role authentication enters in plaintext over the Trusted Channel (i.e. over the corresponding port). This restriction/port separation from other ports/interfaces is implemented in the Module design as bus transactions are restricted to the specific domain (User) and the SECO HSM processor. No physical tools are required (the path is within the integrated circuit) and no operator instructions are required (the access control mechanism is built into the bus control hardware).

The Module supports two distinct operator roles and identity-based authentication is required for each role as follows:

• Cryptographic Officer (CO): The System Control Unit (SCU) as a proxy for NXP via the MU0 interface.
• User: User processes running in User CPUs, uniquely identified by Domain Identifier, TrustZone and MU. The Module supports concurrent operators, enforcing separation of roles (and as such, access to sensitive data and keys) by an access hierarchy that requires unique identification and authentication. Most services require corresponding open and close operations, where flags to the open operation set various properties of the service. The Module does not output any CSPs; the calling application refers to keys by an identifier (handle). Cryptographic service invocations require a sequence of contextual calls to open a session (returning a session handle), open a service (returning a service handle) and, if access to a CSP is required, open a key store (requiring authentication of the operator and returning a key store handle). The term context below refers to the aggregated set of handles, e.g., session, service, and key store. Data refers to any input to be MAC’ed, signed, or verified. Flags refers to parameters used to control service characteristics. NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy Table 7: Roles, Service Commands, Input and Output Table 8: Roles and Authentication In the i.MX8 DXL architecture, the SCU coordinates the boot sequence, including copying the SECO firmware to the M0+ RAM. Both the SCU and the SECO firmware are provided by NXP, authenticated using the SRK-NXP public key. The SCU is effectively a proxy for NXP development, which holds the private key corresponding to SRK-NXP. During the initialization sequence, the Module authenticates the SECO firmware image using SRK-NXP (ECDSA P-384). Authentication failure causes the Module to enter the Locked error state, with reboot (requiring at least 1 millisecond) to clear the error state. The V2X authentication is part of the SoC boot sequence and is triggered by the SCU through SECO. SECO copies the V2X container in the V2X RAM and then forwards the V2X authenticate request to V2X. V2X locks the access to its RAM and authenticates its own FW images using the OEM-SRK. Operators in the User role are authenticated by use of a 32-bit token (SDS-AT) as AES GCM Additional Authenticated Data (AAD) when opening the sensitive data store corresponding to the service for the designated operator. The attempt to open a Sensitive Data Storage service key store fails if the SDS-AT does not match the registered value, and the Module enters the Locked error state, requiring a reboot to clear (at least 2 milliseconds to reach the Sensitive Data Storage service for another attempt).

The Module adheres to [FIPS 140-3 IG] 2.4.C, similar to example 2, as it offers only approved services with a corresponding global indication of Approved services an API call status response (OK or a context-dependent error; see Section 0). NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy Table 9 describes all Module services and service access to SSPs. The modes of access shown in the table are defined as:

• E = Execute: The module uses the SSP in performing a
• R = Read: The SSP is read from the module (e.g. the SSP cryptographic operation. is output).
• G = Generate: The module generates or derives the
• Z = Zeroise: The module zeroises the SSP. SSP.
• -- = No access. The service does not access the SSP.
• W = Write: The SSP is updated, imported, or written to the module. Table 9: Approved Services E NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy G,E,Z G,E,Z G,E,Z NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy The Module does not provide any Non-Approved Services.

The Module uses ECDSA signature verification (P-384, SHA2-384) as the firmware integrity technique. The operator can initiate the integrity test on demand by invoking the Self-test service. In addition, each time the CAST retest timer expires the Module automatically performs one of the CASTs listed in Section 10 of this document (with the exception of the firmware integrity test), cycling through all CASTs periodically. The Module has a sleep mode (i.e. a quiescent state) that will halt the CAST retest timer; prior to entering the sleep mode, the next CAST in the sequence is executed. The module supports loading firmware from an external source (partial update), the ROM code is immutable and thus unaffected by the loading. The module firmware is in the form of an image (pre-compiled), stored in a container loaded onto the sub-chip cryptographic subsystem, in addition to the firmware in the ROM (non-modifiable). NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy ROM endurance has been proven to be more than 10 years after manufactured date. Therefore, per FIPS 140-3 IG 5.A, no pre-operational ROM integrity self-test has been implemented. The module’s end-of-life procedures must be applied prior to the degradation of the ROM.

The Module is classified in [FIPS 140-3] terms as a limited operational environment. The tested platforms have been specified in Table 2 above in this document. The Module meets Physical Security Level 3 requirements and thus the requirements per this section do not apply to the Module. No security rules, settings or restrictions to the configuration of the operational environment apply in addition to those specified in Section 2.3 Modes of Operation, Overall security design and the rules of operation in this document. NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy The Module is a single-chip embodiment that meets commercial-grade specifications for power, temperature, reliability, and shock/vibration. The Module is packaged in standard integrated circuit packaging that provides protection from probing and direct visual observation of circuit detail in the visible spectrum, as well as passivation. Table 10: Physical Security Inspection Guidelines The Module also includes Environmental Failure Protection (EFP) features. Table 11 specifies the temperature and voltage parameters and corresponding module behavior. Table 11: EFP/EFT Table 12: Hardness Testing Temperature Ranges

The non-invasive security measures supported by the module are specified in Section 12 “Mitigation of Other Attacks”, per FIPS 140-3 IG 12.A. NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy

Table 13 specifies the Module’s SSPs, which include CSPs (critical security parameters) and PSPs (public security Table 13: Sensitive Security Parameters (SSPs) [-- = not applicable] Generation Import/Export Establishment Zeroisation NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy -- = not applicable. The following Module parameters are non-SSPs: ECDSA (P-384) public key used for SECO firmware authentication.

• SRKH-NXP; SHA2-256, s=256 bits; SHS #A2956; Input during manufacturing; Stored in OTP; Not zeroised; Reference used to verify SRK-NXP.
• SRK-OEM; P-256, P-384, P-521 or mod 2048, 3072, 4096 bits, s= 128, 192, 256 bits or s=112, 128, 152 bits; ECDSA non-SECO firmware authentication.
• SRKH-OEM; SRKH-NXP; SHA2-256, s=256 bits; SHS #A2956; Input during manufacturing; Stored in OTP; Not zeroised; Reference used to verify SRK-OEM. NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

Z5

Destroyed by Zeroise OTP overwrite, module or operator initiated.

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy Additional notes or explanations for keys listed above MASTER-NXP: 256-bit Master key used to derive (KBKDF) KEK and BEK keys. Generated during factory configuration by DRBG seeded by on-chip TRNG and written to SECO-only OTP in plaintext. Used only to derive BEK and KEK keys with KBKDF. OTP-KEK: 256-bit key used for AES GCM authenticated encryption and decryption of sensitive data stored in OTP. Derived each time the module is restarted (following power on or reset) from MASTER-NXP using KBKDF. OEM-RKEK: SECO module Secure Data Storage service Root Key Encryption Key. Used for AES GCM authenticated decrypt (import) of externally generated keys. Injected during the process of configuring the Module. This key is used to derive two keys for use by the SECO (SECO OEM RKEK) and V2 (V2X OEM RKEK) blocks. SDS-KEK: SECO module Secure Data Storage service Key Encryption Key. Used for AES GCM authenticated decrypt (import) of externally generated keys. Established in either of two ways:

1 – imported encrypted with OEM-RKEK or another SECO-SDS-KEK;

2 – agreed on using EC DH key agreement (ephemeral unified model) via KAS-ECC-SSC + [56Cr2] One Step Hash KDA.

Stored in Secure RAM and persisted to external secure storage encrypted by SECO-SDS-BEK. Secure RAM copy is destroyed by overwriting with 0x00 values on Module termination; external secure storage is unreadable following destruction of MASTER-NXP, since SECO-SDS-BEK can no longer be derived. SRK-NXP and SRK-OEM are public keys from key pairs generated by systems external to the chip, managed by NXP and the OEM (module integrator). The corresponding private keys are used by these external provisioning systems to sign firmware, certificates, or commands by NXP or the OEM. SRKH-NXP and SRKH-OEM are SHA2-384 hashes of the corresponding public key used as a root of trust, established onto the Module in a factory setting prior to deployment. SDS-BEK and SDS-RKEK are derived from MASTER-NXP on the Module on every restart. SDS-KEK are key encryption keys generated external to the Module, or via the Key Agreement: KEK use case service. SDS-KEK must be imported into the Module encrypted by SDS-RKEK or another SDS-KEK instance. SDS-BEK, SDS-RKEK and SDS-KEK are used by the Sensitive Data Storage and Key Management services to import or export AES GCM encrypted blobs for storage in external NVM:

• Keys imported into the Module are decrypted using SDS-RKEK or SDS-KEK.
• Keys managed by the Module (once generated or imported) utilize the Sensitive Data Storage service: o encrypted with SDS-BEK and provided to NVM controller to store in external NVM; o retrieved from external NVM and decrypted with SDS-BEK to store in Secure RAM.
• Services that require a CSP are authenticated via a Sensitive Data Storage service command;
• Keys may be locked to remain in Secure RAM, or if unlocked, may be swapped in and out as required. Key agreement is provided for the following use cases:
• The KEK use case, to establish an SDS-KEK instance for key import. In this use case, KEK-Local-Private and KEK-LocalPublic are an ephemeral EC key pair generated by the Module and KEK-Host-Public is the other party’s public key. The complete key agreement scheme, including generation of the ephemeral keys, is performed in a single command:
• KEK-Local-Private / KEK-Local-Public are generated, compliant with [56Ar3] §5.6.2.1 owner key pair assurances;
• KEK-Local-Private and KEK-Host-Public are used in KAS-ECC-SSC to calculate a shared secret (KEK-SS);
• KEK-SS is used with the [56Cr2] One-Step KDF to derive SDS-KEK, which is retained within the Module;
• KEK-Local-Private and KEK-SS are destroyed; KEK-Local-Public and call status are returned to the caller.
• The TLS use case, to establish instances of SC-EDK and optionally, instances of MAC-AK. In this use case, TLS-LocalPrivate and TLS-Local-Public are an ephemeral EC key pair generated by the Module and TLS-Peer-Public is the other party’s public key. The Module provides all cryptographic primitives for a calling application within the i.MX8 DXL SoC but outside the Module boundary that performs the TLS protocol. The Key Agreement service in the TLS use case performs the following functions in a single command: NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy o Optional, based on a call parameter (to support TLS in the client role): TLS-Local-Private and TLS-Local-Public are generated, compliant with [56Ar3] §5.6.2.1 owner key pair assurances; o TLS-Local-Private and TLS-Host-Public are used in KAS-ECC-SSC to calculate a shared secret, identified in [RFC5246] as the pre_master_secret (TLS-PS); o TLS-PS is used within the [135r1] TLS v1.2 KDF to derive the [RFC5246] TLS master_secret or the [RFC7627] TLS extended_master_secret. The master secret variants are considered variations on the same CSP (TLS-MS), as they are the same size and purpose, and differ only in the input provided to the TLS PRF. o TLS-MS is used within the [135r1] TLS v1.2 KDF to derive the TLS key_block (TLS-KB); o The TLS-KB is partitioned into the session keying material dependent on the key agreement call parameters (corresponding to ciphersuites): this will include SC-EDK and may include MAC-AK. These resulting key instances are retained within the Module – only key identifiers (handles) are returned to the caller. o TLS-Local-Private, TLS-PS, and TLS-KB are destroyed prior to return of the call to the KDF; TLS-MS and the cipher and MAC keys are retained within the Module; TLS-Local-Public and the call status are returned to the caller. The TLS-MS is retained to support the TLS Finish operation which uses the master secret; TLS Finish destroys TLS-MS. o Note

1. TLS-PS and TLS-KB are intermediate calculations established during the execution of the command, are destroyed prior to the call return, and never cross the Module boundary. These values are included in Security Policy tables and descriptions to conform with typical representations of TLS CSPs and more easily demonstrate guidance compliance. o Note
2. To support TLS in the server role, the TLS-Local-Private / TLS-Local-Public key pair must be generated in a separate step prior to the key agreement call to provide the public key to the other party in the correct sequence. The Key Agreement service (for either the KEK or the TLS use cases) always deletes the local EC private key (TLSLocal-Private or KEK-Local-Private), whether or not it was generated in advance of the call or within the call execution. o Note
3. The Module addresses all [56Ar3] §5.6.2.1 Assurances Required by the Key Pair Owner by means of approved generation of the ephemeral EC key pair as well as public key validation. [56Ar3] §5.6.2.1 and §5.6.2.2 Assurances Required by a Public Key Recipient are met by public key validation. As the Module provides only primitives and not the entire TLS protocol, it cannot determine if the public key it receives is static or ephemeral, nor make assurances regarding approved generation of the key pair by the other party, or possession of the private key by the other party. The Module integrator shall assure that these [56Ar3] assurance requirements are met. o Note
4. The module does not support any non-approved random bit generators. Only an approved Hash DRBG and CTR_DRBG is supported by the module and used to generate SSPs as shown per ‘G4’ in Table 13 above. Table 14: Non-Deterministic Random Number Generation Specification NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy

The on-chip System Control Unit (SCU; outside the SECO boundary) copies the SECO firmware container into the SECO M0+ RAM, raising an interrupt when firmware is available. The Module initializes, performing the self-tests listed in this section. As allowed by [FIPS 140-3 IG] 5.A, the masked ROM is not integrity tested. The Module verifies the hash of the SECO firmware image within the container and verifies the signature of the container inclusive of the SECO firmware hash. The NXP public key used for SECO FW image verification (SRK-NXP) is provided in the firmware container; the Module assures the correctness of the public key values by comparing the SHA2-512 hash of SRKs to the OTP reference value SRKH. In case of a failure in the pre-operational firmware integrity test, the module enters the Locked error state (error code 0x0000FF29). All cryptographic algorithm self-tests (CASTs) must complete successfully prior to any other use of cryptography by the Module. If one of the CASTs fails, the Module enters the ABORT state. The error state is persistent, and only Status services are available. All attempts to use the Module’s services result in the return of an error code (HSM_SELF_TEST_FAILURE). To recover from an error state, the Module must be power-cycled or reset. The Module maintains a CAST retest timer: each time the CAST retest timer expires the Module automatically performs one of the CASTs listed in this section, cycling through all CASTs periodically. The Module has a sleep mode that will halt the CAST retest timer; prior to entering sleep mode, the next CAST in the sequence is executed. The operator can also initiate the firmware integrity on demand by invoking the Self-test service and the CASTs by rebooting the module. NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy V2X Self-tests: Pre-Operational Self-tests: Firmware integrity: ECDSA signature verification using P-384, SHA2-384; CAVP Certs. #A2974, #A2959, #A2960. Conditional Self-tests:

• Conditional Cryptographic Algorithm Self-tests:
• AES CAST: Inverse cipher (decrypt) KAT using an AES-128 key in ECB mode; CAVP Cert. # A2957.
• AES CMAC CAST: KAT using AES-256; covers AES forward cipher. CAVP Cert. # A2958.
• AES GCM CAST (Covers AES CCM, CBC, ECB);
• Encrypt KAT using an AES-128 key in GCM mode; per [FIPS 140-3 IG] 10.3.A, covers CCM; per [FIPS 140-3 IG] 10.3.A, covers AES forward cipher. #A2968, #A2957.
• Decrypt KAT using an AES-128 key in GCM mode; per [FIPS 140-3 IG] 10.3.A, covers CCM; per [FIPS 140-3 IG] 10.3.A, covers AES forward cipher. #A2968, #A2957.
• DRBG CAST (AES ECB) : Instantiate, generate and reseed KATs using the DRBG and associated SHA2-256; per [FIPS 140-3 IG] 10.3.A, covers AES forward cipher (encrypt). #A2969, #A2957.
• DRBG CAST (AES ECB): Instantiate, generate and reseed KATs using the DRBG and associated SHA2-256; per [FIPS 140-3 IG] 10.3.A, covers AES forward cipher (encrypt). #A2970, #A2957.
• ECDSA CAST (SHA2-512, SHA2-384): ECDSA signature generation and verification KATs using P-521, SHA2-512; per [FIPS 140-3 IG] 10.3.A, covers SHA2-512 and SHA2-384 KATs. #A2974, #A2960.
• ENT (V2X Primary) : Entropy source health testing in accordance with [90B].
• ENT (V2X Secondary): Entropy source health testing in accordance with [90B].
• KAS-ECC-SSC CAST: KAT using P-256; complies with [FIPS 140-3 IG] D.F. #A2977.
• KDA CAST: KAT of One-Step SHA2-256 KDF; complies with [FIPS 140-3 IG] D.F. #A2976.
• SHA2-512 CAST (SHA2-384): SHA2-512 KAT; per [FIPS 140-3 IG] 10.3.A, covers SHA2-384. #A2959.
• Pairwise consistency tests:
• ECDSA PCT: Pairwise consistency test performed for each key pair generated (conforms to IG 10.3.A Additional Comment 1). #A2974.
• Firmware Load Test: ECDSA signature verification using P-384, SHA2-384; CAVP Certs. # A2963, #A2956. NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy SECO Self-tests: Pre-Operational Self-tests:

• Firmware integrity: ECDSA signature verification using P-384, SHA2-384; CAVP Certs. # A2963, #A2956. Conditional Self-tests:
• Conditional Cryptographic Algorithm Self-tests:
• AES CAST: Inverse (decrypt) KAT using an AES-128 key in ECB mode; CAVP Cert. # A2953.
• AES GCM CAST (Covers AES CCM, CBC, ECB);
• Encrypt KAT using an AES-128 key in GCM mode; per [FIPS 140-3 IG] 10.3.A, covers CCM; per [FIPS 140-3 IG] 10.3.A, covers AES forward cipher. #A2964, #A2962, #A2953
• Decrypt KAT using an AES-128 key in GCM mode; per [FIPS 140-3 IG] 10.3.A, covers CCM; per [FIPS 140-3 IG] 10.3.A, covers AES forward cipher. #A2964, #A2962, #A2953
• DRBG CAST (SHA2-256): Instantiate, generate and reseed KATs using the DRBG and associated SHA2-256; per [FIPS 140-3 IG] 10.3.A, covers SHA2-256. #A2955.
• ECDSA CAST: ECDSA signature verification KAT using P-384, SHA2-512; per [140 IG] 10.3.B, covers SHA2-

• ECDSA CAST (SHA2-256): ECDSA signature generation KAT using P-384, SHA2-512; per [140 IG] 10.3.B, covers SHA2-512 and SHA2-384 KATs. #A2963, #A2956.
• ENT (P): Entropy source health testing in accordance with [90B].
• KAS-ECC-SSC CAST: KAT using P-256; complies with [FIPS 140-3 IG] D.F. #A2972.
• KBKDF CAST (AES CMAC): KAT using 256-bit AES key; per [FIPS 140-3 IG] 10.3.B, covers AES CMAC KAT. #A2966, #A2954.
• KDA CAST: KAT of One-Step SHA2-256 KDF; complies with [FIPS 140-3 IG] D.F. #A2965.
• RSA CAST (SHA2-256): RSA signature verification KAT using n=2048, SHA2-256; per [FIPS 140-3 IG] 10.3.B, covers SHA2-256 KAT. #A2967, #A2956.
• RSA CAST (SHA2-256, SHA2-224): RSA signature verification KAT using n=2048, SHA2-256; per [FIPS 140-3 IG] 10.3.B, covers SHA2-256 and SHA2-224 KATs. #A2967, #A2956.
• SHA2-512 CAST (SHA2-384): SHA2-512 KAT; per [FIPS 140-3 IG] 10.3.A, covers SHA2-384. #A2956.
• TLS v1.2 KDF CAST (HMAC-SHA2-256): KAT using 384-bit Z; complies with [FIPS 140-3 IG] D.F; per [FIPS 140-3 IG] 10.3.B, covers HMAC-SHA2-256. #A2973, #A2961
• Pairwise consistency tests:
• ECDSA PCT: Pairwise consistency test performed for each key pair generated (conforms to IG 10.3.A Additional Comment 1). #A2963
• Firmware Load Test: ECDSA signature verification using P-384, SHA2-384; CAVP Certs. # A2963, #A2956. NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy

The Module is configured in the factory for the Approved mode of operation only. No procedures for secure installation, initialization, startup and operation of the Module are required. No maintenance requirements apply to the Module. Administrator and non-Administrator guidance is provided as a separate document, i.MX8 DXL V2X FIPS 140-3 CO and User Guidance.

The Module incorporates a clock frequency sensor that generates an out-of-range signal. This condition results in CO authentication reset, preventing use of Module security functions, and blocking access to sensitive information. The module also includes side channel resistance and fault injection countermeasures. Until the requirements of SP 800140F are defined, non-invasive mechanisms fall under ISO/IEC 19790:2012 Section 7.12 Mitigation of other attacks, thus the non-invasive security measures supported by the module are as follows: The side channel mitigations include random data moving, blinding techniques, and continuously generating noise on the power line. Fault injection mitigations include double calculations, parameter integrity protections, parameter checking and clearing memory areas after usage. Confidence in the effectiveness of each of these mitigations was achieved through a combination of fault attack simulations and internal vulnerability assessment testing. The countermeasures were shown to be effective against common fault injection and side channel attacks. NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)