i.MX8 DXL SECO HSM

Certificate

Approved Algorithms (25)

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

flowchart LR
  %% Deterministic review-risk graph for i.MX8 DXL SECO HSM
  %% 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 SECO HSM
  %% 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 SECO HSM Document Version 1.2 March 27, 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 SECO HSM 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 SECO HSM 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 20-Mar-2020 ISO/IEC 24759 and ISO/IEC 19790 Annex B [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 [FIPS 140-3 NIST, Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program 7-Oct-2022 IG] [ISO 19790] ISO/IEC 19790:2012 Information technology -- Security techniques -- Security requirements for 1-Nov-2015 cryptographic modules NXP Semiconductors Public Material

• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL SECO HSM FIPS 140-3 Security Policy Ref. Full Specification Name Date [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 Aug-2008 (GCM) [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 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 [FIPS 140-3 IG] TLS Transport Layer Security (see [135]) IoT Internet of Things WDog Watchdog timer IV Initialization Vector NXP Semiconductors Public Material

• may be reproduced only in its original entirety (without revision)

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

This document defines the Security Policy for the NXP Semiconductors i.MX8 DXL SECO HSM hardware sub-chip cryptographic subsystem with a single-chip embodiment, hereafter denoted the SECO, SECO HSM or the Module. The Module has 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 Security 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]

NXP Semiconductors Public Material

• may be reproduced only in its original entirety (without revision)

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

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 or IoT applications. The Module is available in the configurations shown in Table 2. Table 2: Cryptographic Module Tested Configuration Model Hardware [Part Number and Version] Firmware Version Distinguishing Features i.MX 8SoloXLite MIMX8SL3AVNFZAB SECO ROM: The mem_I.MX8_s28roml_w24576x032 MIM8SL3AVNFZA i.MX 8SoloXLite PIMX8SL3AVNFZAB m32B2_1Tlms_m0_1.7 B and SECO FW 5.9.0 PIM8SL3AVNFZA i.MX 8DualXLite MIMX8DL3AVNFZAB B parts feature one applications processor The leading P designates engineering sample parts i.MX 8DualXLite PIMX8DL3AVNFZAB The MIM8DL3AVNFZ AB and SoC Part Number SOC_iMX8DualXL_28FDSOI_1.75 PIM8DL3AVNFZA B parts feature Module Subsystem DA_SSL_iMX8DXL_SCU_SUBSYS_LN28FDSOI_1.56 two applications Version processors

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/Method Description / Key Size(s) Use / Function Cert and Standard / Key Strength(s) 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 CKG [133r2] Section 4: Using the Output of a Random Bit Cryptographic key generation per [FIPS 140-3 IG] Affirmed Generator D.H, applicable to Module generated symmetric Section 5.1: Key Pairs for Digital Signature keys and seeds for generating asymmetric keys Schemes Section 5.2: Key Pairs for Key Establishment Section 6.1: Direct Generation of Symmetric Keys Section 6.2.1: Symmetric Keys Generated Using Key-Agreement Schemes Section 6.2.2: Symmetric Keys Derived from a Pre-existing Key NXP Semiconductors Public Material

• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL SECO HSM FIPS 140-3 Security Policy A2955 DRBG [90Ar1] Hash SHA2-256 Random number generation A2963 ECDSA [186] P-256, P-384 ECC key generation P-256 (SHA2-256); ECC signature generation P-384 (SHA2-384) P-256 (SHA2-256, SHA2-384, SHA2-512); ECC signature verification P-384 (SHA2-256, SHA2-384, SHA2-512); Note that P-521 is used only by the Authenticate P-521 (SHA2-256, SHA2-384, SHA2-512) 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, Keyed MAC used with TLS SHA2-384, SHA2-512 384, 5121 A2973 CVL [135r1r] TLS v1.2 KDF HMAC-SHA2-256; Key derivation for TLS (v1.2); TLS v1.2 KDF RFC7627 HMAC-SHA2-384 also supports [RFC7627] Extended Master Secret A2972 KAS-ECC-SSC KAS-ECC-SSC Key agreement used for TLS support and for [56Ar3] Schemes: Ephemeral Unified, One-Pass DH sensitive data communications Roles: Initiator, Responder ECC curves: P-256, P-384 A2966 KBKDF [1081] 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-1 [38F] Key wrapping in the context of Sensitive data AES GCM 256-bit SP 800-38D and SP storage 800-38F. KTS (key wrapping) per IG D.G. 256- bit keys providing

strength A2967 RSA [186] n=2048 (SHA2-256, SHA2-384, SHA2-512); PKCS 1.5 signature verification n=3072 (SHA2-256, SHA2-384, SHA2-512); 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, KAS-1 Schemes: Ephemeral SP 800-56Arev3. KAS- Key agreement to establish an SDS-KEK A2965 Unified, One-Pass DH ECC per IG D.F Scenario Roles: Initiator, 2 path (2) option 2 Responder KAS-ECC-SSC curves: P- P-256 and P-384 curves 256, P-384 providing 128 or 192 KDA One-Step Hash bits of encryption KDF strength A2972, KAS-2 Schemes: Ephemeral SP 800-56Arev3. KAS- Key agreement to establish TLSv1.2 session keys and A2973 Unified, One-Pass DH ECC per IG D.F Scenario the corresponding intermediate values for preRoles: Initiator, 2 path (2) option 2 master secret TLS-PMS and master secret TLS-MS Responder KAS-ECC-SSC curves: P- P-256 and P-384 curves 256, P-384 providing 128 or 192 TLS v1.2 KDF bits of encryption TLS v1.2 KDF RFC7627 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 SECO HSM FIPS 140-3 Security Policy AES GCM is used by the Sensitive Data Storage service. In accordance with [FIPS 140-3 IG] 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 [FIPS 140-3 IG] D.K for conformance to [90B]. AES GCM is also used to support TLS primitives and adheres to the [FIPS 140-3 IG] 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 [FIPS 140-3 IG] D.F Scenario 2 Path 2, option 2 (KAS-ECC-SSC using curve P-256 or BrainpoolP256R1 and One-Step Hash KDF)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 [FIPS 140-3 IG] D.F Scenario 2 Path 2, option 2 (KAS-ECC-SSC using curve P-256, P-384, BrainpoolP256R1 or BrainpoolP384R1 and TLS v1.2 KDF or TLS v1.2 KDF RFC7627)3. KAS (KAS-SSC Cert. #A2972, KDA Cert. #A2965); 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 SECO HSM 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 SECO HSM 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

The Module is a dedicated security controller subsystem of the i.MX8 DXL SoC, compliant to [FIPS 140-3 IG] 2.3.B Sub-Chip Cryptographic Subsystems:

• The physical boundary is the single-chip physical boundary.
• The set of components depicted in Figure 2 within the dashed red line, represents the defined sub-chip cryptographic subsystem.
• The Module boots from an 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 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 Channel (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. NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL SECO HSM FIPS 140-3 Security Policy 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 physical 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 SECO HSM 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 boundary are simplified. Figure 2: Module Block Diagram

The Module as defined above will always be in an Approved mode of operation by default. No configuration is necessary for the Module to operate and remain in the Approved mode. The Module does not support a non-Approved mode or a degraded mode of operation. The Management service Get Info message response includes the information shown next; chip lifecycle and Approved mode constitute the indicator of 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. • 8-bit chip lifecycle state: 0x80. • 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 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 SSPs.
7. Data output is inhibited during self-tests, zeroisation, and error states. NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

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

8. The Module clears previous authentications on power cycle.
9. The Module does not support manual key entry.
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. The Module’s TLS support corresponds to [FIPS 140-3 IG] D.C case 2 (providing a CAVP validated TLS v1.2 KDF and TLS v1.2 KDF RFC7627), 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 SECO HSM 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. DC in the Table 6 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 6, 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 boundary has write-only access to the M0+ RAM only during boot to load the SECO firmware (dashed line in Figure 2); 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 Control input DMA controlled access to external data or CAAM DC: No Control output 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 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 external circuits NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL SECO HSM FIPS 140-3 Security Policy Tamper input: accept 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). NXP Semiconductors Public Material

• may be reproduced only in its original entirety (without revision)

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

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. 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; SECO is 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. NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL SECO HSM FIPS 140-3 Security Policy 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).

Table 9 below 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 is cryptographic operation. output). G = Generate: The module generates or derives the SSP. Z = Zeroise: The module zeroises the SSP. W = Write: The SSP is updated, imported, or written to the -- = No access. The service does not access the SSP. 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 (#A2963) CO SRK-NXP W,E OK / (self-test) operational self-tests SHS (#A2956) SRKH- E error KBKDF (#A2966) NXP E MASTER- G NXP G SDS-BEK OTP-KEK Management Subsystem control and status. Get mode, status and (No crypto function) CO None N/A OK / (status) version information; configure or manage the error subsystem. Self-test Perform conditional CASTs as needed, on demand or See Section 10 N/A None N/A OK / periodically. error Authenticate Authenticate (verify a digital signature) command ECDSA Sig Ver (#A2963) N/A SRK-NXP W,E OK / content or firmware images (for SoC cores on behalf of RSA Sig Ver (#A2967) SRK- W,E error the SCU). OEM W,E SRKH- E NXP E SRKHOEM Generic Data Management of generic (non-sensitive) data, media Non-approved AES CCM N/A SDRBG- E OK / Storage parameter storage. uses DRBG Generate State error (#A2955) SDRBGSeed Hash Generate or verify message digest. SHS (#A2956) N/A None N/A OK / error Management SECO device control and status. Get mode, status and (No crypto function) N/A None N/A OK / (Approved version information; configure or manage the SECO error mode status) device. NXP Semiconductors Public Material

• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL SECO HSM FIPS 140-3 Security Policy Service Description Approved Security Roles Keys Access Indicator Functions and/or rights to SSPs Keys and/or SSPs Random DRBG generation of random bits. DRBG Generate N/A SDRBG- E,Z OK / (#A2955) EI E error SDRBGState SDRBGSeed Session Initialize session communications. (No crypto function) N/A None N/A OK / error Generate Generate a digital signature. ECDSA Sig Gen (#A2963) User SDRBG- E OK / Signature CKG State W,E error SDRBG- E Seed DSPrivate SDS-BEK Key Perform the KAS-ECC-SSC and One-Step Hash KDF in an KAS-ECC-SSC (#A2972) User SDRBG- E OK / Agreement: atomic command to establish an SDS-KEK instance. ECDSA Key Gen State G,E error KEK use case (#A2963) SDRBG- G,E,Z DRBG Generate Seed G,R (#A2955) KEK-SS W,E KDA Derivation KEK- G (#A2965) Local- E CKG Private KEKLocalPublic KMHostPublic SDS-KEK SDS-BEK Key Perform the KAS-ECC-SSC and TLS KDF in an atomic KAS-ECC-SSC (#A2972) User SDRBG- E OK / Agreement: command to establish TLS session keys (instances of ECDSA Key Gen State G,E error TLS use case SC-EDK, MAC-AK). (#A2963) SDRBG- G,E,Z DRBG Generate Seed G,R (#A2955) SC-EDK W,E TLS v1.2 KDF (#A2973) MAC-AK G TLS v1.2 KDF RFC7627 SDS-BEK G (#A2973) TLS- E CKG Local- G,E,Z Private G,R TLS- W,E LocalG,E,Z Public G,E,Z TLSPeer- G,E,Z Public TLS-MS TLS-PS NXP Semiconductors Public Material

• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL SECO HSM FIPS 140-3 Security Policy Service Description Approved Security Roles Keys Access Indicator Functions and/or rights to SSPs Keys and/or SSPs TLS-KB Key Generate key or key pair; manage (invalidate, import, ECDSA Key Gen User SDRBG- E OK / Management update) key or key group. Invalidate refers to marking (#A2963) State G, W, R error keys invalid

• automatic zeroisation on invalidation is a DRBG Generate SDRBG- G, R programmable option. (#A2955) Seed G, W, R AES GCM Enc, Dec DS- G, W, E (#A2964) Private E CKG DS- E Public G, W, R The AES GCM (KTS) is MAC-AK applicable to the import SDS-KEK use case. SDS-BEK OEMRKEK SC-EDK Key Store Manage key storage context and access to key AES GCM Dec (#A2964) User SDS-BEK E OK / information. error MAC HMAC or CMAC generate and verify. CMAC Gen, Ver User MAC-AK W,E OK / (#A2954) SDS-BEK E error HMAC Gen, Ver (#A2961) PK Recover Recover public key from private key. ECDSA Key Gen User DS- E OK / (#A2963) Private G,R error DS- E Public SDS-BEK Sensitive Management of sensitive data storage using AES GCM ECDSA Key Gen User DS- G,W, R OK / Data Storage authenticated cipher. (#A2963) Private G,R error DRBG Generate DS- G,E,W, R (#A2955) Public G,W, R ECDSA Key Gen MAC-AK G,W,E (#A2963) SC-EDK E AES GCM Enc, Dec SDS-KEK (#A2964) SDS-BEK NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL SECO HSM FIPS 140-3 Security Policy Service Description Approved Security Roles Keys Access Indicator Functions and/or rights to SSPs Keys and/or SSPs The list of SSPs at right includes SSPs that may be saved in persistent secure storage. Symmetric Encrypt or decrypt data (including authenticated AES Enc, Dec (#A2953, User SC-EDK W,E OK / Cipher encrypt/decrypt). A2962, A2964) SDS-BEK E error Zeroise Destroy Master-NXP; renders other CSPs unusable. (No crypto function) User SDRBG- Z OK / EI Z error SDRBG- Z State Z SDRBG- Z Seed Z DS- Z Private Z MAC-AK Z SC-EDK Z SDS-BEK Z SDS-KEK Z SRK-NXP Z OTP-KEK Z OEM- Z RKEK Z KEK-SS Z KEKZ LocalZ Private Z KEKLocalPublic KMHostPublic TLSLocalPrivate TLSLocalPublic TLSPeerPublic TLS-MS TLS-PS TLS-KB The Module does not provide any Non-Approved Services. NXP Semiconductors Public Material

• may be reproduced only in its original entirety (without revision)

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

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 of firmware from an external source (partial update), the ROM code is immutable and thus unaffected by the loading. 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. NXP Semiconductors Public Material

• may be reproduced only in its original entirety (without revision)

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

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 SECO HSM FIPS 140-3 Security Policy

The Module has 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. The module is coated with a hard tamper evident coating. 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 a or EFT shutdown or zeroisation Low Temperature -40C EFP Shutdown High Temperature +105C EFP Shutdown Low Voltage 0.95 V EFP Shutdown High Voltage 1.1 V EFP Shutdown Table 12: Hardness testing temperature ranges Hardness tested temperature measurement Low Temperature -40C High Temperature +105C NXP Semiconductors Public Material

• may be reproduced only in its original entirety (without revision)

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

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 SECO HSM 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: SSPs Generation Import/Export Establishment Zeroisation Security Key/SSP Function Storage Name/Type Strength and Cert. Number Use & related keys SDRBG-EI 256 ENT G1 -- -- S1 Z1 Hash_DRBG entropy input

• see detail below. CSP SDRBG-State 256 DRBG G2 -- -- S1 Z1 Hash_DRBG internal state (V and C). CSP #A2955 SDRBG-Seed 512 DRBG G2 -- -- S1 Z1 Seed derived using the NIST SP 800-90Ar1 Hash_DRBG and SDRBG-EI. CSP #A2955 DS-Private 128 or 192 ECDSA G3 O1 I1 S2 Z1 ECDSA private key (P-256, P-384; BrainpoolP256R1, BrainpoolP384R1) for digital CSP #A2963 AD/EE Z2 signature generation. CKG DS-Public 128 or 192 ECDSA # G3 O2 I2 S2 Z1 ECDSA public key (P-256, P-384; BrainpoolP256R1, BrainpoolP384R1) for digital PSP A2963 G7 AD/EE S3 Z3 signature verification. CKG KEK-SS 128/256 KDA # A2965 G9 -- -- S2 Z4 Key agreement shared secret, KEK use case. CSP CKG KEK-Local- 128 KAS-ECC-SSC G3 -- N/A S2 Z4 Key agreement ephemeral EC private key (P-256; BrainpoolP256R1), KEK use case. Private # A2972 CSP CKG KEK-Local- 128 KAS-ECC-SSC G3 O2 -- S5 Z4 Key agreement ephemeral EC public key (P-256; BrainpoolP256R1), KEK use case. Public # A2972 AD/EE PSP CKG KEK-Host- 128 KAS-ECC-SSC NA -- I2 S5 Z4 Key agreement ephemeral EC public key (P-256; BrainpoolP256R1), KEK use case. Public # A2972 PSP MAC-AK AES: 128, AES # A2954 G4 O1 I1 S2 Z1 AES key (128, 192 or 256-bit) used for AES CMAC generation and verification; CSP 192 or 256 HMAC # G10 AD/EE Z2 HMAC key (224, 256, 384 or 512-bit) used for HMAC generation and verification. HMAC: 192 A2961 or 256 CKG MASTER-NXP 256 KBKDF # G6 -- -- S4 Z5 Master key used to derive SDS-BEK. CSP A2966 CKG OEM-RKEK 256 AES # A2964 G11 -- 13 S5 Z5 OEM key encryption key, used to unwrap imported keys. CSP OTP-KEK 256 AES # A2964 G5 -- -- S3 Z1 Key used to decrypt sensitive OTP content. CSP CKG SC-EDK 128, 192 AES # A2953 G4 O1 I1 S2 Z1 AES key (128, 192 or 256-bit) used for AES encrypt and decrypt. CSP or 256 CKG G10 AD/EE Z2 SDS-BEK 256 AES # A2964 G5 -- -- S2 Z1 Blob encryption key (256-bit AES) used for secure off-chip storage, derived from CSP CKG S3 MASTER-NXP using KBKDF. SDS-KEK 256 AES # A2964 G8 O1 I1 S2 Z1 Key encryption key, used to unwrap imported keys. CSP CKG AD/EE S3 TLS-Local- 128 or 192 KAS-ECC-SSC G3 -- -- S2 Z4 EC local private key (P-256, P-384; BrainpoolP256R1, BrainpoolP384R1) for key Private # A2972 agreement. CSP CKG TLS-Local- 128 or 192 KAS-ECC-SSC G3 O2 -- S3 Z4 EC local public key (P-256, P-384; BrainpoolP256R1, BrainpoolP384R1) for key Public # A2972 AD/EE agreement. PSP CKG TLS-Peer- 128 or 192 KAS-ECC-SSC G3 -- I2 S6 Z4 EC peer public key (P-256, P-384; BrainpoolP256R1, BrainpoolP384R1) for key Public # A2972 agreement. PSP CKG TLS-MS 128 or 192 KAS #A2972 G10 -- -- S2 Z4 TLS master_secret (48-byte value): TLS KDF intermediate value (used to derive TLSCSP TLS v1.2 KDF KB). #A2973 NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL SECO HSM FIPS 140-3 Security Policy TLS v1.2 KDF RFC7627 (#A2973) CKG TLS-PS 128 or 192 KAS-ECC-SSC G9 -- -- S2 Z4 TLS pre_master_secret: TLS KDF intermediate value (used to derive TLS-MS). CSP #A2972 CKG TLS-KB 128 or 192 KAS #A2972 G10 -- -- S2 Z4 TLS key_block: TLS KDF intermediate value used to form a TLS SC-EDK instance; CSP TLS v1.2 KDF depending on key exchange call flags, will derive either TLS MAC-AK instance or GCM #A2973 or CCM IVs. TLS v1.2 KDF RFC7627 #A2973 CKG -- = 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. Z5 Destroyed by Zeroise OTP overwrite, module or operator initiated. Additional notes or explanations for keys listed above NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL SECO HSM FIPS 140-3 Security Policy MASTER-NXP: 256-bit Master key used to derive (KBKDF) SDS-BEK. Generated during factory configuration by DRBG seeded by on-chip TRNG and written to SECO-only OTP in plaintext. 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: 256 bits used to derive Module Secure Data Storage service Root Key Encryption Key, the latter is used for AES GCM authenticated decrypt (import) of externally generated keys. Injected during the process of configuring the Module. SDS-KEK: The 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-512 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 is 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 an SDS-KEK instance. SDS-BEK 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-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 two 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 and 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 [56Cr2r] 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:
• Optional, based on a call parameter (to support TLS in the client role): TLS-Local-Private and TLS-Local-Public are generated, compliant with [56A3] §5.6.2.1 owner key pair assurances;
• 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); NXP Semiconductors Public Material
• may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL SECO HSM FIPS 140-3 Security Policy 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 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. NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)

NXP Semiconductors i.MX8 DXL SECO HSM 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 (error code 0x471EED29). 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 (i.e. a quiescent state) 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 SECO HSM FIPS 140-3 Security Policy 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 [140 IG] 10.3.A, covers CCM; per [140 IG] 10.3.A, covers AES forward cipher. #A2964, #A2962, #A2953
• Decrypt KAT using an AES-128 key in GCM mode; per [140 IG] 10.3.A, covers CCM; per [140 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 [140 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 [140 IG] D.F. #A2972.
• KBKDF CAST (AES CMAC): KAT using 256-bit AES key; per [140 IG] 10.3.B, covers AES CMAC KAT. #A2966, #A2954.
• KDA CAST: KAT of One-Step SHA2-256 KDF; complies with [140 IG] D.F. #A2965.
• RSA CAST (SHA2-256): RSA signature verification KAT using n=2048, SHA2-256; per [140 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 [140 IG] 10.3.B, covers SHA2-256 and SHA2-224 KATs. #A2967, #A2956.
• SHA2-512 CAST (SHA2-384): SHA2-512 KAT; per [140 IG] 10.3.A, covers SHA2-384. #A2956.
• TLS v1.2 KDF CAST (HMAC-SHA2-256): KAT using 384-bit Z; complies with [140 IG] D.F; per [140 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 SECO HSM 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 SECO HSM FIPS 140-3 CO and User Guidance. The Module can be securely sanitized by zeroising it. NXP Semiconductors Public Material

• may be reproduced only in its original entirety (without revision)

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

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)