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 References Ref. Full Specification Name Date Algorithm-Related References [107r1] NIST, SP 800-107 Rev. 1, Recommendation for Applications Using Approved Hash Algorithms 24-Aug-2012 [108r1] NIST, SP 800-108 Rev. 1, Recommendation for Key Derivation Using Pseudorandom Functions 17-Aug-2022 [131Ar2] NIST, SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths 21-Mar-2019 [133r2] NIST, SP 800-133 Rev. 2, Recommendation for Cryptographic Key Generation 4-Jun-2020 [135r1] NIST, SP 800-135 Rev. 1, Recommendation for Existing Application-Specific Key Derivation Functions 23-Dec-2011 [180] NIST, FIPS 180-4, Secure Hash Standard (SHS) 4-Aug-2015 [186] NIST, FIPS 186-4, Digital Signature Standard (DSS) 19-Jul-2013 [197] NIST, FIPS 197, Advanced Encryption Standard (AES) 26-Nov-2001 [198] NIST, FIPS 198-1, The Keyed-Hash Message Authentication Code (HMAC) 16-Jul-2008 [38A] NIST, SP 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques 1-Dec-2001 [38B] NIST, SP 800-38B, Recommendation for Block Cipher Modes of Operation: the CMAC Mode for 6-Oct-2016 Authentication [38C] NIST, SP 800-38C, Recommendation for Block Cipher Modes of Operation: the CCM Mode for 20-Jul-2007 Authentication and Confidentiality [38D] NIST, SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode 28-Nov-2007 (GCM) and GMAC [38F] NIST, SP 800-38F, Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping 13-Dec-2012 [56Ar3] NIST, SP 800-56A Rev. 3, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete 16-Apr-2018 Logarithm Cryptography [56Cr2] NIST, SP 800-56C Rev. 2, Recommendation for Key-Derivation Methods in Key-Establishment Schemes 18-Aug-2020 [57P1r5] NIST, SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1 - General 4-May-2020 [90Ar1] NIST, SP 800-90A Rev. 1, Recommendation for Random Number Generation Using Deterministic 24-Jun-2015 Random Bit Generators [90B] NIST, SP 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation 10-Jan-2018 Other References [140] NIST, FIPS 140-3, Security Requirements for Cryptographic Modules 22-Mar-2019 [140DTR] NIST, SP 800-140, FIPS 140-3 Derived Test Requirements (DTR): CMVP Validation Authority Updates to 20-Mar-2020 ISO/IEC 24759 [140A] NIST, SP 800-140A, CMVP Documentation Requirements: CMVP Validation Authority Updates to 20-Mar-2020 ISO/IEC 24759 [140B] NIST, SP 800-140B, CMVP Security Policy Requirements: CMVP Validation Authority Updates to ISO/IEC 20-Mar-2020

[140Cr1] NIST, SP 800-140C Rev. 1, CMVP Approved Security Functions: CMVP Validation Authority Updates to 20-May-2022 ISO/IEC 24759 [140Dr1] NIST, SP 800-140D Rev. 1, CMVP Approved Sensitive Parameter Generation and Establishment 20-May-2022 Methods: CMVP Validation Authority Updates to ISO/IEC 24759 [140E] NIST, SP 800-140E, CMVP Approved Authentication Mechanisms: CMVP Validation Authority 20-Mar-2020 Requirements for ISO/IEC 19790 Annex E and ISO/IEC 24579 Section 6.17 [140F] NIST, SP 800-140F, CMVP Approved Non-Invasive Attack Mitigation Test Metrics: CMVP Validation 20-Mar-2020 Authority Updates to ISO/IEC 24759 [140IG] NIST, Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program 7-Oct-2022 [ISO 19790] ISO/IEC 19790:2012 Information technology -- Security techniques -- Security requirements for 1-Nov-2015 cryptographic modules [ISO 24759] ISO/IEC 24759:2017 Information technology -- Security techniques -- Test requirements for 1-Mar-2017 cryptographic modules [RFC5246] IETF RFC5246: The Transport Layer Security (TLS) Protocol Version 1.2 Aug-2008 [RFC5289] IETF RFC5289: TLS Elliptic Curve Cipher Suites with SHA2-256/384 and AES Galois Counter Mode (GCM) Aug-2008 [RFC5639] IETF RFC5639: Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation Mar-2010 [RFC7627] IETF RFC7627: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension Sept-2015 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 Term Meaning Term Meaning A35 ARM Cortex A35 array (on-chip, external to SECO) KAS Key Agreement Scheme AEAD Authenticated Encryption with Associated Data KAT Known Answer Test AES Advanced Encryption Standard KBKDF Key Based Key Derivation Function CAAM Cryptographic Acceleration and Assurance Module KDA Key Derivation Algorithm CAVP Cryptographic Algorithm Validation Program KDF Key Derivation Function CBC Cipher-Block Chaining KEK Key Encryption Key (generalization of SDS-KEK) CCM Counter with CBC-MAC KTS Key Transport Scheme CKG Cryptographic Key Generation M0+ ARM Cortex-M0+ core CMAC Cipher-based Message Authentication Code MAC Message Authentication Code CMVP Cryptographic Module Validation Program MU Messaging Unit CO Cryptographic Officer NIST National Institute of Standards and Technology CRNGT Continuous Random Number Generator Test OTP One Time Programmable CSP Critical Security Parameter PCT Pairwise Consistency Test CVL Component Validation List PRF Pseudorandom Function DRBG Deterministic Random Bit Generator PSP Public Security Parameter DTCP Digital Transport Content Protection RSA Rivest, Shamir, and Adleman Algorithm ECB Electronic Code Book SCU System Control Unit (on-chip CPU, external to SECO) ECC Elliptic Curve Cryptography SECO Security Controller ECDSA Elliptic Curve Digital Signature Algorithm SHA/SHS Secure Hash Algorithm / Standard ENT Entropy source compliant with [90B] SHE Secure Hardware Extension (automotive standard) FIPS Federal Information Processing Standard SNVS Secure Non-Volatile Storage GCM Galois/Counter Mode SoC System on Chip HMAC Keyed-Hash Message Authentication Code SP NIST Special Publication HSM Hardware Security Module SSC Shared Secret Computation IEE Inline Encryption Engine (external to SECO) SSP Sensitive Security Parameter IG Implementation Guidance; see [140IG] TLS Transport Layer Security (see [135]) IoT Internet of Things V2X Vehicle to anything (“X”) interaction IV Initialization Vector WDog Watchdog timer 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

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 ISO/IEC 24759 FIPS 140-3 Section Title Security Level Section 6. [Number Below]

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 Model Hardware [Part Number and Version] Firmware Version Distinguishing Features i.MX 8SoloXLite MIMX8SL2AVNFZAB The MIM8SL2AVNFZA i.MX 8SoloXLite PIMX8SL2AVNFZAB B and PIM8SL2AVNFZA i.MX 8DualXLite MIMX8DL2AVNFZAB B parts feature 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 ROM : one applications mem_I.MX8_s28roml_w24576x032 processor. m32B2_1Tlms_m0_1.7 The leading P V2XP ROM : designates mem_I.MX8_s28roml_w32768x032 engineering m32B2_1Tlm_cm0_rom_1.18 sample parts. i.MX 8DualXLite PIMX8DL2AVNFZAB V2XS ROM: The mem_I.MX8_s28roml_w45056x032 MIM8DL2AVNFZ m32B4_1Tlm_empty_1.10 AB and SoC Part Number SOC_iMX8DualXL_28FDSOI_1.75 SECO FW 5.9.0 PIM8DL2AVNFZA V2X FW 1.2.1 B parts feature Module Subsystem SECO Block: two applications Version DA_SSL_iMX8DXL_SCU_SUBSYS_LN28FDSOI_1.56 processors. V2X Block: DA_SSL_iMX8DXL_DB_SUBSYS_CMOS28FDSOI_1.77

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 CAVP Algorithm Mode / Description / Key Use / Function Cert [Standard] Method Size(s) / Key Strength(s) A2957 AES [197], [38A] ECB, CBC 128, 192, 256 bits Encrypt, decrypt. A2968 AES [38C] AES CCM 128, 192, 256 bits Authenticated encrypt, decrypt. A2958 AES [38B] AES CMAC 128, 192, 256 bits Generate, verify. A2975 AES [38D] AES GCM 128, 192, 256 bits Authenticated encrypt, decrypt. Vendor Affirmed CKG [133r2] Section 4: Using the Output of a Random Bit Generator Cryptographic key Section 5.1: Key Pairs for Digital Signature Schemes generation per [140IG] Section 5.2: Key Pairs for Key Establishment D.H, applicable to Section 6.1: Direct Generation of Symmetric Keys Module generated Section 6.2.1: Symmetric Keys Generated Using Key-Agreement symmetric keys and Schemes seeds for generating Section 6.2.2: Symmetric Keys Derived from a Pre-existing Key asymmetric keys. A2969 DRBG [90Ar1] CTR, with DF AES-256 Random number generation (V2X primary) A2970 DRBG [90Ar1] CTR, with DF AES-256 Random number generation (V2X secondary) A2974 ECDSA [186] P-256; P-384; P-521 ECC key generation. P-256 (SHA2-256); ECC signature P-384 (SHA2-384); generation, verification. P-521 (SHA2-512) 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 CAVP Algorithm Mode / Description / Key Use / Function Cert [Standard] Method Size(s) / Key Strength(s) N/A ENT (P) [90B] Provide entropy input to the DRBG. Two instances (primary and secondary). Used only to seed the approved V2X primary and secondary DRBGs. A2977 KAS-ECC-SSC KAS-ECC-SSC Key agreement used for [56Ar3] Schemes: One-Pass DH sensitive data Role: Responder communications. ECC curves: P-256 A2976 KDA [56Cr2] One-Step Hash KDF SHA2-256 Key derivation for sensitive data communications. A2975 KTS-1 [38F] AES GCM 256-bit SP 800-38D and SP 800- Key wrapping in the 38F. KTS (key wrapping) context of Sensitive data per IG D.G. storage. 256- bit keys providing

strength A2959 SHS [180] SHA2-224, SHA2-256, SHA2-384, SHA2-512 Secure hash function (primary) A2960 SHS [180] SHA2-224, SHA2-256, SHA2-384, SHA2-512 Secure hash function (secondary) A2976, A2977 KAS-1 Schemes: Ephemeral Unified, SP 800-56Arev3. KAS-ECC per IG Key agreement to One-Pass DH D.F Scenario 2 path (2) option 2 establish an SDS-KEK Roles: Initiator, Responder KAS-ECC-SSC curves: P-256, P- P-256 and P-384 curves

KDA One-Step Hash KDF encryption strength SECO HSM Algorithms A2953 AES [197], [38A] ECB, CBC 128, 192, 256 bits Encrypt, decrypt A2953 AES [197], [38A] ECB, CBC 128, 192, 256 bits Encrypt, decrypt. A2962 AES [38C] AES CCM 128, 192, 256 bits Authenticated encrypt, decrypt A2954 AES [38B] AES CMAC 128, 192, 256 bits Generate, verify A2964 AES [38D] AES GCM 128, 192, 256 bits Authenticated encrypt, decrypt Vendor Affirmed CKG [133r2] Section 4: Using the Output of a Random Bit Generator Cryptographic key Section 5.1: Key Pairs for Digital Signature Schemes generation per [FIPS Section 5.2: Key Pairs for Key Establishment 140-3 IG] D.H, Section 6.1: Direct Generation of Symmetric Keys applicable to Module Section 6.2.1: Symmetric Keys Generated Using Key-Agreement generated Schemes symmetric keys and Section 6.2.2: Symmetric Keys Derived from a Pre-existing Key seeds for generating asymmetric keys A2955 DRBG [90Ar1] Hash SHA2-256 Random number generation A2963 ECDSA [186] P-256, P-384 ECC key generation 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 P-256 (SHA2-256); ECC signature P-384 (SHA2-384) generation P-256 (SHA2-256, SHA2-384, SHA2-512); ECC signature P-384 (SHA2-256, SHA2-384, SHA2-512); verification P-521 (SHA2-256, SHA2-384, SHA2-512) Note that P-521 is used only by the Authenticate service, hence no P-521 key or signature generation N/A ENT (P) [90B] Provide entropy input to the DRBG Used only to seed the approved DRBG A2961 HMAC [198] SHA2-224, SHA2-256, Key lengths 224, 256, 384, Keyed MAC used SHA2-384, SHA2-512 5121 with TLS A2973 CVL [135r1] TLS v1.2 KDF HMAC-SHA2-256; Key derivation for TLS v1.2 KDF RFC7627 HMAC-SHA2-384 TLS (v1.2); also supports [RFC7627] Extended Master Secret A2972 KAS-ECC-SSC KAS-ECC-SSC Key agreement used [56Ar3] Schemes: Ephemeral Unified, One-Pass DH for TLS support and Roles: Initiator, Responder for sensitive data ECC curves: P-256, P-384 communications A2966 KBKDF [108r1] CTR KBKDF AES CMAC 256-bit Key derivation used for SDS-BEK A2965 KDA [56Cr2] One-Step Hash KDF SHA2-256 Key derivation for sensitive data communications A2964 KTS-2 [38F] AES GCM 256-bit SP 800-38D and SP 800- Key wrapping in the 38F. KTS (key wrapping) context of Sensitive per IG D.G. data storage 256- bit keys providing 256 bits of encryption strength A2967 RSA [186] n=2048 (SHA2-256, SHA2-384, SHA2-512); PKCS 1.5 signature n=3072 (SHA2-256, SHA2-384, SHA2-512); verification n=4096 (SHA2-256, SHA2-384, SHA2-512) A2955 SHS [180] SHA2-256 Message digest used exclusively by the DRBG A2956 SHS [180] SHA2-224, SHA2-256, SHA2-384, SHA2-512 Message digest for all purposes other than DRBG A2972, A2965 KAS-2 Schemes: Ephemeral Unified, SP 800-56Arev3. KAS-ECC per IG Key agreement to One-Pass DH D.F Scenario 2 path (2) option 2 establish an SDSRoles: Initiator, Responder KEK KAS-ECC-SSC curves: P-256, P-256 and P-384 curves providing P-384 128 or 192 bits of encryption KDA One-Step Hash KDF strength 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)

NXP Semiconductors i.MX8 DXL V2X FIPS 140-3 Security Policy A2972, KAS-3 Schemes: Ephemeral Unified, SP 800-56Arev3. KAS-ECC per IG Key agreement to A2973 One-Pass DH D.F Scenario 2 path (2) option 2 establish TLSv1.2 Roles: Initiator, Responder session keys and KAS-ECC-SSC curves: P-256, P-256 and P-384 curves providing the corresponding P-384 128 or 192 bits of encryption intermediate TLS v1.2 KDF strength values for preTLS v1.2 KDF RFC7627 master secret TLSPMS and master secret TLS-MS 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;
2. TLS KAS: To establish TLSv1.2 session keys and the corresponding intermediate values for pre-master secret TLS-PMS and master secret TLS-MS, compliant to [140IG] D.F Scenario 2 Path 2, option 2 (KAS-ECC-SSC using curve P-256, P384, BrainpoolP256R1 or BrainpoolP384R1 and TLS v1.2 KDF or TLS v1.2 KDF RFC7627)3. KAS (KAS-SSC Cert. # A2972 or A2977, KDA Cert. # A2965 or A2976); provides 128 bits of strength KAS (KAS-SSC Cert. # A2972, CVL Cert. # A2973); provides 128 or 192 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 Algorithm Caveat Use / Function ECDSA Provides 128 or 192 bits of Use of Brainpool curves, allowed for use per [FIPS 140-3 with non-NIST recommended encryption strength); Per IG C.A IG] C.A: curves - BrainpoolP256R1 (128-bit security strength) - BrainpoolP384R1 (192-bit security strength) EC Diffie-Hellman with non-NIST Provides 128 or 192 bits of Use of Brainpool curves in KAS, allowed for use per [FIPS recommended curves encryption strength); Per IGs D.F and 140-3 IG] C.A and [FIPS 140-3 IG] D.F Scenario 3: C.A - BrainpoolP256R1 (available for both KEK and TLS use cases; 128-bit security strength) - BrainpoolP384R1 (available only for TLS use case; 192-bit security strength) Table 5: Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed Algorithm Caveat Use / Function AES CCM no security Hardware implementation of AES CCM (no security claimed - [FIPS 140-3 IG] 2.4.A), used by Generic claimed Data Storage service 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 Physical port Logical interface Data that passes over port/interface System Bus: MU Control input DC: No Control output SECO command messages and responses Description: Status output Interface between Data input Messaging Units and Data output external subsystems System Bus: CAAM V2X Control input DMA controlled access to external data or CAAM DC: No Control output results or V2X results (mediated by SECO) Description: Status output Interface between CAAM Data input and external subsystems Data output System Bus: SCU Control input Firmware image DC: No Data input Description: Status output SCU write-only access to M0+ RAM (firmware image load) Private Bus Control input Stored parameters, used by other SoC subsystems DC: No Data output Description: Data output (no CSPs) to media (e.g., video) controllers 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 Tamper I/O Control input Tamper input: accept external tamper detection DC: Yes Control output signals Description: Status output Tamper output: indicate tamper condition to Tamper input: accept external circuits external tamper detection signals Tamper output: indicate tamper condition to external circuits Osc out Control output Oscillator output DC: Yes Description: SNVS oscillator output VSNVS-LP Power input Power input DC: Yes Description: SNVS Low Power section power supply connection, also called LP Battery VSS, VDD Power input Power input DC: Yes Description: Supply voltage 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 Role Service Input Output CO Initialize (self-test) N/A. Status CO Management (status) Context(session); flags Status N/A Self-test (on demand CASTs) Context(session); flags Status N/A Authenticate: verify signature Context(session); data Context(service); verification result; status N/A Generic (non-sensitive) data storage Context(session); flags; data Context(service); status N/A Hash: perform a SHA Context(session); flags; data Context(service); status N/A Management (Approved mode status) Context(session); flags Status N/A Random (generate a random value) Context(session); flags Context(service); random value; status N/A Session: initiate a session context Flags Context(session); status User Generate Signature Context(session, keystore); data Context(service); signature; status User Key Agreement Context(session, keystore); data Context(service); key handle User Key Management Context(session, keystore); flags Context(service); status User Key Store Context(session) Context(keystore); status User MAC (CMAC or HMAC) Context(session); data Context(service); status User PK Recover Context(session, keystore) Context(service); status User Sensitive Data Storage Context(session); data pointer Context(service); status User Symmetric Cipher Context(session); data pointer Context(service); data pointer; status User Zeroise Context(session); data pointer Status Table 8: Roles and Authentication Role Authentication Method Authentication Strength CO ECDSA P-384 signature False authentication probability, single attempt: 1/(2^192) = 1.6E-58 verification, 192-bit strength False authentication probability, over a one-minute interval: (60*1000)/(2^192) = 9.6E-54 User AES-GCM, 32-bit AAD token False authentication probability, single attempt: 1/(2^32) = 2.3E-10 False authentication probability, over a one-minute interval: (60*500)/(2^32) = 7.0E-06 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 Service Description Approved Security Roles Keys Access Indicator Functions and/or rights to SSPs Keys and/or SSPs Initialize Authenticate and load firmware; perform pre- ECDSA Sig Ver CO SRK-NXP4 W,E OK / (self-test) operational self-tests. (#A2963) SRKH-NXP E error SHS (#A2956) MASTER- E KBKDF (#A2966). NXP G SDS-BEK G OTP-KEK Management Subsystem control and status. Get mode, (No crypto function) CO None N/A OK / (status) status and version information; configure or error manage the subsystem. Self-test Perform conditional CASTs as needed, on See Section 10 N/A None N/A OK / demand or periodically. error Authenticate Authenticate (verify a digital signature) ECDSA Sig Ver N/A SRK-NXP W,E OK / command content or firmware images (for (#A2963) SRK-OEM W,E error SoC cores on behalf of the SCU). RSA Sig Ver (#A2967) SRKH-NXP W,E SRKH- E OEM E Generic Data Management of generic (non-sensitive) data, Non-approved AES N/A SDRBG- E OK / Storage media parameter storage. CCM uses DRBG State error Generate (#A2955) SDRBGSeed Hash Generate or verify message digest. SHS (#A2956, A2959, N/A None N/A OK / A2960) error Management SECO device control and status. Get mode, (No crypto function) N/A None N/A OK / (Approved mode status and version information; configure or error status) manage the SECO device. Random DRBG generation of random bits. DRBG Generate N/A SDRBG-EI G,E,Z OK / (#A2955, A2969, SDRBG- E error A2970) State G,E,Z SDRBG- E Seed VDRBG-EI VDRBGState VDRBGSeed Session Initialize session communications. (No crypto function) N/A None N/A OK / error SRK-NXP and SRKH-NXP include SECO and V2X instances. 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 Service Description Approved Security Roles Keys Access Indicator Functions and/or rights to SSPs Keys and/or SSPs Generate Signature Generate a digital signature. ECDSA Sig Gen User SDRBG- E OK / (#A2963, A2974) State W,E error CKG SDRBG- E Seed E DS-Private SDS-BEK SDS-V2XBEK Key Agreement: Perform the KAS-ECC-SSC and One-Step Hash KAS-ECC-SSC User SDRBG- E OK / KEK use case KDF in an atomic command to establish an (#A2972, #A2977) State G,E error SDS-KEK instance. ECDSA Key Gen SDRBG- G,E,Z (#A2963) Seed G,O DRBG Generate KEK-SS W,E (#A2955) KEK-Local- G KDA Derivation Private E (#A2965, #A2976) KEK-LocalCKG Public KM-HostPublic SDS-KEK SDS-V2XBEK Key Agreement: Perform the KAS-ECC-SSC and TLS KDF in an KAS-ECC-SSC User SDRBG- E OK / TLS use case atomic command to establish TLS session (#A2972) State G,E error keys (instances of SC-EDK, MAC-AK). ECDSA Key Gen SDRBG- G,E,Z (#A2963) Seed G,O DRBG Generate SC-EDK W,E (#A2955) MAC-AK G TLS KDF Derivation SDS-BEK G (##A2973)TLS v1.2 TLS-Local- E KDF RFC7627 Private G,E,Z (#A2973) TLS-Local- G,R CKG Public W,E TLS-PeerG,E,Z Public G,E,Z TLS-MS G,E,Z TLS-PS TLS-KB Key Management Generate key or key pair; manage (invalidate, ECDSA Key Gen User SDRBG- E OK / import, update) key or key group. Invalidate (#A2963) State G, W, R error refers to marking keys invalid

• automatic DRBG Generate SDRBG- G, R zeroisation on invalidation is a programmable (#A2955) Seed G, W, R option. AES GCM Enc, Dec DS-Private G, W, E (#A2964) DS-Public E CKG MAC-AK E SDS-KEK G, W, R SDS-V2XThe AES GCM (KTS) is BEK applicable to the import use case. OEMRKEK SC-EDK 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 Service Description Approved Security Roles Keys Access Indicator Functions and/or rights to SSPs Keys and/or SSPs Key Store Manage key storage context and access to AES GCM Dec User SDS-BEK E OK / key information (#A2964) error MAC HMAC or CMAC generate and verify. AES CMAC Gen, Ver User MAC-AK W, E OK / (#A2954, #A2958) SDS-BEK E error HMAC Gen, Ver SDS-V2X- E (#A2961) BEK PK Recover Recover public key from private key. ECDSA Key Gen User DS-Private E OK / (#A2963) DS-Public G, R error SDS-BEK E Sensitive Data Management of sensitive data storage using ECDSA Key Gen User DS-Private G,W,R OK / Storage AES GCM authenticated cipher. (#A2963) DS-Public G,R error DRBG Generate MAC-AK G,E,W,R (#A2955) SC-EDK G,W,R ECDSA Key Gen SDS-KEK G,W,E (#A2963) SDS-V2X- G,W,E AES GCM Enc, Dec BEK (#A2964) The list of SSPs at right includes SSPs that may be saved in persistent secure storage. Symmetric Cipher Encrypt or decrypt data (including AES Enc, Dec (#A2953, User SC-EDK W,E OK / authenticated encrypt/decrypt). A2962, A2964, A2957, SDS-BEK E error A2968, A2975) SRK-NXP W,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 Service Description Approved Security Roles Keys Access Indicator Functions and/or rights to SSPs Keys and/or SSPs Zeroise Destroy NXP Master Key; renders other CSPs (No crypto function) User SDRBG-EI Z OK / unusable. SDRBG- Z error State Z SDRBG- Z Seed Z VDRBG-EI Z VDRBG- Z State Z VDRBG- Z Seed Z DS-Private Z MAC-AK Z SC-EDK Z SDS-BEK Z SDS-KEK Z SDS-RKEK Z SRK-NXP Z OTP-KEK Z KEK-SS Z KEK-Local- Z Private Z KEK-Local- Z Public Z KM-Host- Z Public TLS-LocalPrivate TLS-LocalPublic TLS-PeerPublic TLS-MS TLS-PS TLS-KB 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 Physical Security Mechanism Recommended Frequency of Inspection/Test Inspection/Test Guidance Details Single-chip packaging The Module is intended to be mounted in additional packaging; N/A physical inspection of the die is typically not practical after packaging. 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 Temperature or Voltage Measurement Specify EFP Specify if this condition results in or EFT a shutdown or zeroisation Low Temperature -40C EFP Shutdown High Temperature +105C EFP Shutdown SECO Low Voltage 0.95 V EFP Shutdown SECO High Voltage 1.1 V EFP Shutdown Low frequency High frequency V2X Low Voltage 0.95 V 1.05 V EFP Shutdown V2X High Voltage 1.1 V 1.15 V EFP Shutdown Table 12: Hardness Testing Temperature Ranges Hardness Tested Temperature Measurement Low Temperature -40C High Temperature +105C

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 parameters, e.g., public keys). Table 13: Sensitive Security Parameters (SSPs) [-- = not applicable] Generation Import/Export Establishment Zeroisation Key/SSP Storage Name/Type Strength Security Function and Cert. Number Use & Related Keys SDRBG-EI

256 ENT G1 -- -- S1 Z1 Hash_DRBG entropy input

• see detail below.

256 DRBG # A2955 G2 -- -- S1 Z1 Hash_DRBG internal state (V and C).

CSP SDRBG-Seed 512 DRBG #A2955 G2 -- -- S1 Z1 Seed derived using the NIST SP 800-90Ar1 Hash_DRBG CSP and SDRBG-EI. ECDSA #A2963, O1 DS-Private Z1 ECDSA private key (P-256, P-384; BrainpoolP256R1,

128 or 192 A2974 G3 AD I1 S2

CSP Z2 BrainpoolP384R1) for digital signature generation. CKG /EE ECDSA # A2963, O2 DS-Public G3 Z1 ECDSA public key (P-256, P-384; BrainpoolP256R1,

128 or 192 A2974 AD I2 S2 S3

PSP G7 Z3 BrainpoolP384R1) for digital signature verification. CKG /EE KDA #< A2965, KEK-SS 128/256 A2976 G9 -- -- S2 Z4 Key agreement shared secret, KEK use case. CSP CKG KEK-Local-Private KAS-ECC-SSC # Key agreement ephemeral EC private key (P-256;

128 G3 -- N/A S2 Z4

CSP A2972, A2977 BrainpoolP256R1), KEK use case. KAS-ECC-SSC # O2 KEK-Local-Public Key agreement ephemeral EC public key (P-256;

128 A2972, A2977 G3 AD -- S5 Z4

PSP BrainpoolP256R1), KEK use case. CKG /EE KEK-Host-Public KAS-ECC-SSC # Key agreement ephemeral EC public key (P-256;

128 NA -- I2 5 Z4

PSP A2972, A2977 BrainpoolP256R1), KEK use case. AES CMAC # A2954, AES key (128, 192 or 256-bit) used for AES CMAC O1 MAC-AK AES: 128, 192 or 256 A2958 G4 Z1 generation and verification; AD I1 S2 CSP HMAC: 192 or 256 HMAC # A2961 G10 Z2 HMAC key (224, 256, 384 or 512-bit) used for HMAC /EE CKG generation and verification. MASTER-NXP 256 KBKDF # A2966 G6 -- -- S4 Z5 Master key used to derive system keys. CSP CKG OEM-RKEK AES # A2964, A2975 OEM key encryption key, used to unwrap imported

256 G11 -- 13 S5 Z5

CSP keys, derived from MASTER-NXP using KBKDF. OTP-KEK 256 AES # A2964, A2975 G5 -- -- S3 Z1 Key used to decrypt sensitive OTP content. CSP CKG AES # A2953, A2962, A2964, G4 O1 SC-EDK Z1 AES key (128, 192 or 256-bit) used for AES encrypt and 128, 192 or 256 A2957, A2968, G10 AD I1 S2 CSP Z2 decrypt. A2975 /EE CKG SDS-BEK AES # A2964, A2975 Blob encryption key (256-bit AES) used for secure off-

256 G5 -- -- S2 S3 Z1

CSP CKG chip storage, derived from MASTER-NXP using KBKDF. O1 SDS-KEK AES # A2964, A2975

256 G8 AD I1 S2 S3 Z1 Key encryption key, used to unwrap imported keys.

CSP CKG /EE TLS-Local-Private KAS-SSC # A2972 EC local private key (P-256, P-384; BrainpoolP256R1,

128 or 192 G3 -- -- S2 Z4

CSP CKG BrainpoolP384R1) for key agreement. KAS-ECC-SSC # O2 TLS-Local-Public EC local public key (P-256, P-384; BrainpoolP256R1,

128 or 192 A2972 G3 AD -- S3 Z4

PSP BrainpoolP384R1) for key agreement. CKG /EE KAS-ECC-SSC # TLS-Peer-Public EC peer public key (P-256, P-384; BrainpoolP256R1,

128 or 192 A2972 G3 -- I2 S6 Z4

PSP BrainpoolP384R1) for key agreement. CKG KAS # A2972 TLS-MS TLS KDF # A2973 TLS master_secret (48-byte value): TLS KDF

128 or 192 G10 -- -- S2 Z4

CSP TLS v1.2 KDF intermediate value (used to derive TLS-KB). RFC7627 (#A2973) 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 Generation Import/Export Establishment Zeroisation Key/SSP Storage Name/Type Strength Security Function and Cert. Number Use & Related Keys CKG KAS-ECC-SSC # TLS-PS TLS pre_master_secret: TLS KDF intermediate value

128 or 192 A2972 G9 -- -- S2 Z4

CSP (used to derive TLS-MS). CKG TLS key_block: TLS KDF intermediate value used to KAS # A2972 TLS-KB form a TLS SC-EDK instance; depending on key

128 or 192 TLS KDF # A2973 G10 -- -- S2 Z4

CSP exchange call flags, will derive either TLS MAC-AK CKG instance or GCM or CCM IVs. VDRBG-EI

256 ENT G1 -- -- S1 Z1 CTR_DRBG entropy input

• see detail below.

CSP VDRBG-State DRBG # A2969,

256 G2 -- -- S1 Z1 CTR_DRBG internal state (V and Key).

CSP A2970 VDRBG-Seed 512 DRBG # A2969, G2 -- -- S1 Z1 Seed derived using the NIST SP 800-90Ar1 CTR_DRBG CSP A2970 and VDRBG-EI. -- = not applicable. The following Module parameters are non-SSPs:

• SRK-NXP; P-384, s= 192 bits; ECDSA #A2963; Input in plaintext; Stored in Secure RAM; Destroyed by loss of power; 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 #A2963, RSA #A2967; Input in plaintext; Stored in Secure RAM; Destroyed by loss of power; Public key used for 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. CSP / Public Key Generation Methods CSP / Public Key Input Methods Key to entity association G1 Generated by the hardware entropy source (ENT). I1 Input using AES GCM with SDS-BEK (blob storage) Key store handle (unique identifier). G2 Generated by DRBG Instantiate; updated by DRBG Reseed or AES GCM with SDS-KEK (import). or DRBG Generate. I2 Input in plaintext (used with PSPs only). Call stack position (API parameter). G3 Generated by FIPS 186-4 compliant ECDSA key generation, I3 Input during manufacturing. Call stack position (API parameter). with input from the internal DRBG. G4 Direct output of the internal DRBG. CSP / Public Key Storage Methods Key to entity association G5 Generated by the AES Counter KBKDF. S1 Stored in CAAM DRBG hardware register. Unique SECO memory map location. G6 Direct output of the internal DRBG during manufacturing. S2 Stored in Secure RAM. Key store handle (unique identifier). G7 Computed from the ECC Private key. S3 Stored in SECO local (M0+) RAM. Unique variable location (pointer). G8 Derived using [56C] One Step Hash KDF. S4 Stored in OTP (plaintext). Unique fuse map location. G9 Calculated using KAS-ECC-SSC. S5 Stored in OTP encrypted by OTP-KEK. Unique fuse map location. G10 Calculated as an element of TLS v1.2 KDF. S6 Held temporarily in CAAM hardware. Key generation output to caller. G11 Input during manufacturing (customer provisioned). CSP / Public Key Zeroisation Methods CSP / Public Key Output Methods Key to entity association Z1 Destroyed due to power-cycling or resetting the module, O1 Output using AES GCM with SDS-BEK (blob storage). Key store handle (unique identifier). operator initiated. O2 Output in plaintext (public key only). Call stack position (API parameter). Z2 Can also be destroyed by Key Management service Delete, operator initiated. Z3 Destroyed by tamper event or Zeroise, module initiated. Z4 Destroyed after use during hsm_key_exchange, module initiated. 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 Z5 Destroyed by Zeroise OTP overwrite, module or operator initiated. 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:

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 Entropy Minimum number Details sources of bits of entropy Local TRNG [90Ar1] min_length: 256 bits The SECO DRBG is seeded via the [90Ar1] hash_df using 256 bits of entropy input and ENT (P) [90Ar1] seedlen: 512 bits a 256-bit nonce, both obtained from the Approved [90B] ENT (P). The entropy source provides at least 0.994 of min_entropy per bit of entropy input, hence the DRBG is seeded with 509 bits of effective entropy, sufficient to support the strength of the largest key generated by the Module. Local TRNG [90Ar1] min_length: 256 bits The V2X DRBGs are implemented in firmware, seeded via the [90Ar1] block_cipher_df ENT (P) [90Ar1] seedlen: 512 bits using 256 bits of entropy input and a 256-bit nonce, both obtained from the Approved [90B] ENT (P). The entropy source provides at least 0.993 of min_entropy per bit of entropy input, hence the DRBG is seeded with 508 bits of effective entropy, sufficient to support the strength of the largest key generated by 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 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)