Copyright 2022 NXP Semiconductors - may be reproduced only in its original entirety (without revision)
i.MX 8X SECO HSMv2
FIPS 140-2 Non-Proprietary Security Policy
Document Version 2.0
February 07, 2022
Prepared for: Prepared by:
NXP Semiconductors
MIKRONWEG 1
8101 GRATKORN
Austria
NXP.com
KeyPair Consulting Inc.
987 Osos Street
San Luis Obispo, CA 93401
USA
keypair.us
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 2 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
Table of Contents
References ..............................................................................................................................................................................3
Acronyms and Definitions.......................................................................................................................................................4
1 Overview...........................................................................................................................................................................5
2 Cryptographic Functionality .............................................................................................................................................8
2.1 Critical Security Parameters (CSPs) and Public Security Parameters (PSPs)........................................................10
3 Roles, Authentication and Services ................................................................................................................................12
3.1 CO Authentication................................................................................................................................................12
3.2 User Authentication.............................................................................................................................................12
3.3 Approved Mode Services .....................................................................................................................................13
4 Initialization and Self-Test ..............................................................................................................................................15
5 Physical Security.............................................................................................................................................................16
6 Mitigation of Other Attacks............................................................................................................................................16
7 Security Rules and Guidance ..........................................................................................................................................16
Table of Tables
Table 1: Security Level of Security Requirements...................................................................................................................5
Table 2: Part Numbers ............................................................................................................................................................5
Table 3: Ports and Interfaces ..................................................................................................................................................7
Table 4: Approved Algorithms ................................................................................................................................................8
Table 5: Ciphersuites Supported for Use with Module TLS Primitives ...................................................................................9
Table 6: Non-Approved but Allowed Cryptographic Functions ..............................................................................................9
Table 7: Non-Approved Mode Security Functions..................................................................................................................9
Table 8: Critical Security Parameters and Public Keys..........................................................................................................10
Table 9: Module Roles...........................................................................................................................................................12
Table 10: Service Descriptions ..............................................................................................................................................13
Table 11: Service Access to CSPs and PSPs ...........................................................................................................................14
Table 12: FIPS Boot Mode Self-Tests ....................................................................................................................................15
Table 13: FIPS HSM Mode Self-Tests ....................................................................................................................................15
Table 14: Module Conditional Self-Tests ..............................................................................................................................15
Table of Figures
Figure 1: Module Physical Form..............................................................................................................................................6
Figure 2: Module Block Diagram.............................................................................................................................................6
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 3 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
References
Ref. Full Specification Name
[107] NIST, SP 800-107 Rev. 1, Recommendation for Applications Using Approved Hash Algorithms, Aug. 24, 2012
[108] NIST, SP 800-108, Recommendation for Key Derivation Using Pseudorandom Functions (Revised), Oct. 1, 2009
[131A] NIST, SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths, Mar. 21, 2019
[133] NIST, SP 800-133 Rev. 2, Recommendation for Cryptographic Key Generation, Jun. 4, 2020
[135] NIST, SP 800-135 Rev. 1, Recommendation for Existing Application-Specific Key Derivation Functions, Dec. 23, 2011
[140] NIST, FIPS 140-2, Security Requirements for Cryptographic Modules, May 25, 2001
[140DTR] NIST, Derived Test Requirements for FIPS PUB 140-2, Security Requirements for Cryptographic Modules, Jan. 4, 2011
[140IG] NIST, Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program, May 4, 2021
[180] NIST, FIPS 180-4, Secure Hash Standard (SHS), Aug. 4, 2015
[186] NIST, FIPS 186-4, Digital Signature Standard (DSS), Jul. 19, 2013
[197] NIST, FIPS 197, Advanced Encryption Standard (AES), Nov. 26, 2001
[198] NIST, FIPS 198-1, The Keyed-Hash Message Authentication Code (HMAC), July 16, 2008
[38A] NIST, SP 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques, Dec. 1, 2001
[38B] NIST, SP 800-38B, Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication, Oct. 6,
2016
[38C] NIST, SP 800-38C, Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and
Confidentiality, Jul. 20, 2007
[38D] NIST, SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC,
Nov. 28, 2007
[38F] NIST, SP 800-38F, Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping, Dec. 13, 2012
[90A] NIST, SP 800-90A Rev. 1, Recommendation for Random Number Generation Using Deterministic Random Bit
Generators, Jun. 24, 2015
[90B] NIST, SP 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation, Jan. 10, 2018
[56A] NIST, SP 800-56A Rev. 3, Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm
Cryptography, Apr. 16, 2018
[56C] NIST, SP 800-56C Rev. 11
, Recommendation for Key-Derivation Methods in Key-Establishment Schemes, Apr. 16, 2018
[57] NIST, SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1 - General, May 4, 2020
[BEKDF] A Security Credential Management System for V2X Communications. IEEE Transactions on Intelligent Transportation
Systems. PP. 10.1109/TITS.2018.2797529.
[RFC5246] IETF RFC5246: The Transport Layer Security (TLS) Protocol Version 1.2
[RFC5289] IETF RFC5289: TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)
[RFC5639] IETF RFC5639: Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation
[RFC7627] IETF RFC7627: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
[SP] i.MX 8X SECO HSMv2 FIPS 140-2 Non-Proprietary Security Policy (this document), June 11, 2021
1
Although SP 800-56Cr1 has been withdrawn, the current version SP 800-56Cr2 has not been added to FIPS 140-2 Annex D, as updates
are under consideration. Although this Module uses a function that is unchanged between the two releases, the CMVP has informed
CST Laboratories that modules cannot claim conformance to SP 800-56Cr2 at this time.
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 4 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
Acronyms and Definitions
Term Meaning
A35 ARM Cortex A35 array (on-chip, external to SECO)
AEAD Authenticated Encryption with Associated Data
AES Advanced Encryption Standard
CAAM Cryptographic Acceleration and Assurance Module
CAVP Cryptographic Algorithm Validation Program
CBC Cipher-Block Chaining
CCM Counter with CBC-MAC
CKG Cryptographic Key Generation
CMAC Cipher-based Message Authentication Code
CMVP Cryptographic Module Validation Program
CO Cryptographic Officer
CRNGT Continuous Random Number Generator Test
CSP Critical Security Parameter
CVL Component Validation List
DRBG Deterministic Random Bit Generator
DTCP Digital Transport Content Protection
ECB Electronic Code Book
ECC Elliptic Curve Cryptography
ECDSA Elliptic Curve Digital Signature Algorithm
ENT (P) Physical entropy source compliant with [90B]
FIPS Federal Information Processing Standard
GCM Galois/Counter Mode
HMAC Keyed-Hash Message Authentication Code
HSM Hardware Security Module
IEE Inline Encryption Engine (external to SECO)
IG Implementation Guidance; see [140IG]
IoT Internet of Things
IV Initialization Vector
KAS Key Agreement Scheme
Term Meaning
KAT Known Answer Test
KBKDF Key Based Key Derivation Function
KDA Key Derivation Algorithm
KDF Key Derivation Function
KEK Key Encryption Key (generalization of SDS-KEK)
KTS Key Transport Scheme
M0+ ARM Cortex-M0+ core
MAC Message Authentication Code
MU Messaging Unit
NDRNG Non-Deterministic Random Number Generator
NIST National Institute of Standards and Technology
OTP One Time Programmable
PCT Pairwise Consistency Test
PRF Pseudorandom Function
PSP Public Security Parameter
RSA Rivest, Shamir, and Adleman Algorithm
SCU System Control Unit (on-chip CPU, external to SECO)
SECO Security Controller
SHA/SHS Secure Hash Algorithm / Standard
SHE Secure Hardware Extension (automotive standard)
SNVS Secure Non-Volatile Storage
SoC System on Chip
SP NIST Special Publication
SSC Shared Secret Computation
SSP Sensitive Security Parameter
TLS Transport Layer Security (see [135])
V2X Vehicle to anything (“X”) interaction
WDog Watchdog timer
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 5 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
1 Overview
This document defines the Security Policy for the NXP Semiconductors i.MX 8X SECO HSMv2 (Security Controller Hardware
Security Module) cryptographic module, hereafter denoted the Module. The Module, validated to [140] overall Level 3, is
a sub-chip subsystem of a single-chip embodiment providing cryptographic engine and secure storage functions, intended
for use in automotive or IoT applications.
The Module is a limited operational environment under the [140] 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 [140] validation.
The Module conforms to the EMI/EMC requirements specified by part 47 Code of Federal Regulations, Part 15, Subpart B,
Unintentional Radiators, Digital Devices, Class B.
The FIPS 140-2 security levels for the Module are given in Table 1.
Table 1: Security Level of Security Requirements
Security Requirement Level
Cryptographic Module Specification 3
Cryptographic Module Ports and Interfaces 3
Roles, Services, and Authentication 3
Finite State Model 3
Physical Security 3
Operational Environment N/A
Cryptographic Key Management 3
EMI/EMC 3
Self-Tests 3
Design Assurance 3
Mitigation of Other Attacks 3
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.
The Module is available in the configurations shown in Table 2. All configuration variations are due to features outside the
logical boundary of the Module or more stringent environmental qualification (automotive or industrial vs. commercial),
and do not affect any of the Module’s [140] characteristics.
Table 2: Part Numbers
i.MX 8QuadXPlus (QX) i.MX 8DualXPlus (DX) i.MX 8DualX (UX)
MiMX8QX6FVLFZAC MiMX8DX6FVLFZAC MiMX8UX6FVLFZAC
MiMX8QX5FVLFZAC MiMX8DX5FVLFZAC MiMX8UX5FVLFZAC
MiMX8QX2FVLFZAC MiMX8DX4FVLFZAC MiMX8UX2FVLFZAC
MiMX8QX1FVLFZAC MiMX8DX3FVLFZAC MiMX8UX1FVLFZAC
MiMX8QX6GVLFZAC MiMX8DX2FVLFZAC MiMX8UX6GVLFZAC
MiMX8QX5GVLFZAC MiMX8DX1FVLFZAC MiMX8UX5GVLFZAC
PIMX8QX6AVLFZAC MiMX8DX6GVLFZAC
PIMX8QX6FVLFZAC MiMX8DX5GVLFZAC
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 6 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
The physical form of the Module is depicted in Figure 1. The cryptographic boundary is the surface, edges and solder bump
connections of the chip package.
Figure 1: Module Physical Form
Figure 2 depicts the Module logical functions, with the cryptographic boundary depicted as the dashed red line, and the
chip physical boundary depicted as the outer solid black line. SoC functions outside the logical boundary are simplified.
Figure 2: Module Block Diagram
The Module’s ports and interfaces are listed in Table 3 below, including the designation of [140] logical interface types.
The Table 3 DC column refers to Device Connection: Yes in the DC column means the port is available at the physical
boundary (solder ball); No in the DC column means the port is completely internal to the physical boundary.
In Figure 2 and Table 3, System Bus refers to the address/data bus with hardware enforced access control that connects
major i.MX 8X SoC subsystems. In Table 3, 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 logical 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 DTCP. These parameters are used by
algorithms that execute outside the Module boundary; they are not used by the Module and unrelated to Module security.
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 7 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
Table 3: Ports and Interfaces
DC Port Description Logical Interface Type
No System Bus: MU Interface between Messaging Units and external subsystems. Control in, Status out, Data in, Data out
No System Bus: CAAM Interface between CAAM and external subsystems. Control in, Status out, Data in, Data out
No System Bus: SCU SCU write-only access to M0+ RAM (firmware image load). Control in, Data in, Status out
No Private Bus Data output (no CSPs) to media (e.g., video) controllers. Control In, Data out
Yes Tamper I/O Tamper input: accept external tamper detection signals;
Tamper output: indicate tamper condition to external circuits.
Control in;
Status out
Yes Osc out SNVS oscillator output. Status out
Yes VSNVS-LP SNVS Low Power section power supply connection, also called
LP Battery.
Power
Yes VSS, VDD Supply voltage. Power
The Module is a dedicated security controller subsystem of the i.MX 8X SoC, compliant to [140IG] 1.20 Sub-chip
Cryptographic Subsystems:
● The physical boundary is the single-chip physical boundary as described above.
● The logical boundary is the set of components depicted in Figure 2 above within the dashed red line, with corresponding
SECO HSM firmware.
● 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
[140DTR] 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 logical and physical boundaries only in the form of AES-GCM authenticated ciphertext
blobs, meeting [140IG] 7.7 and D.9 requirements. An authentication token is provided in plaintext over a Trusted Path
from a source within the physical boundary of the Module.
● Versioning per [140IG] 1.20 requirements:
o Physical single-chip: SOC_iMX8_QuadX_CMOS28FDSOI_1.88 (SoC part number)
o Module subsystem: rpp_cm0p_sec_subsys (version tag DA_SSL_iMX8QX_SCU_SUBSYS_LN28FDSOI_1.72)
o Module firmware: ROM mem_i.MX8QX_s28roml_w20480x032m32B2_1Tlms_m0_1.3; SECO FW 4.8.0
The function of the Tamper I/O signals is to (optionally) support one or more external tamper mesh mechanisms external
to the device. Tamper input signals may be used to trigger zeroization of ZMK, effectively zeroizing the Module. The use of
Tamper I/O is not required for operation in the Approved mode; these signals are available as control signals and as an
alternative means to zeroize ZMK.
The Module provides two approved modes of operation and a non-approved mode of operation; non-approved algorithms
are available only in the non-approved mode:
● FIPS Boot Mode: firmware image verification services; associated with CO operator.
● FIPS HSM Mode: extended cryptographic engine services and secure storage; associated with User operators.
● Non-approved mode: supports non-approved algorithms required for use in automotive settings.
i.MX 8X devices are deployed for operation in a closed (unchangeable) lifecycle state. The FIPS Approved Mode OTP fuse
bit is permanently set in the factory prior to deployment, prior to setting the lifecycle state closed. Upon deployment, if
the FIPS Approved Mode is not set, the Module operates in the non-approved mode. If FIPS Approved Mode is set, on
power-on or reset, the Module begins execution in FIPS Boot Mode; on receipt of a FIPS HSM mode Initialization service
command, the Module transitions into the FIPS HSM mode.
See Section 4 for self-test descriptions. No CSPs are shared between the approved modes and the non-approved mode.
The Management service Get Info message response includes the information shown next; chip lifecycle and FIPS mode
constitute the indicator of the approved modes:
● 32-bit SECO FW version: 0x40080 (corresponding to SECO FW 4.8.0);
● 32-bit Extended version, SECO FW commit ID: 0xf0d7d020;
● 8-bit chip lifecycle state: 0x80;
● FIPS mode: 8-bit field, only the last two bits are used: 0x3 indicates the part is a validated part in the approved modes.
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 8 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
2 Cryptographic Functionality
The Module implements the Approved and Allowed cryptographic functions listed below.
Table 4: Approved Algorithms
Cert Algorithm Mode Description (security strength) Functions, Caveats
C1951 AES [197] [38A] ECB, CBC (128, 192, 256) Encrypt, decrypt.
C1954 AES [38C] AES CCM (128, 192, 256) Authenticated encrypt, decrypt.
C1956 AES [38B] AES CMAC (128, 192, 256) Generate, verify.
C1958 AES [38D] AES GCM (128, 192, 256) Authenticated encrypt, decrypt.
Vendor
Affirmed
CKG [133] Section 6.1: unmodified DRBG output. Symmetric key generation per [140IG] D.12, applicable to
Module generated symmetric keys except SDS-BEK, SDS-
RKEK.
C1957 CVL [186] P-256 (SHA-256);
P-384 (SHA-384)
ECC signature generation component.
A1251 CVL [135] TLS v1.2
KDF
HMAC-SHA-256;
HMAC-SHA-384
Key derivation for TLS (v1.2);
also supports [RFC7627] Extended Master Secret.
C1955 DRBG [90A] Hash SHA-256 Random number generation.
C1957 ECDSA [186] P-256, P-384 ECC key generation.
P-256 (SHA-256);
P-384 (SHA-384)
ECC signature generation.
P-256 (SHA-256, SHA-384, SHA-512);
P-384 (SHA-256, SHA-384, SHA-512);
P-521 (SHA-256, SHA-384, SHA-512)
ECC signature verification.
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.
A892 HMAC [198] SHA-224,
SHA-256,
SHA-384,
SHA-512
Key lengths 224, 256, 384, 5122
Keyed MAC used with TLS.
A904
A905
KAS KAS-SSC + KDA Key agreement for sensitive data communications.
A904 KAS-SSC
[56A]
KAS-ECC-SSC
Schemes: Ephemeral Unified, One-Pass DH
Roles: Initiator, Responder
ECC curves: P-256, P-384
Key agreement used for TLS support and for sensitive data
communications.
C1959 KBKDF [108] CTR KBKDF using 256-bit AES CMAC Key derivation used for SDS-BEK, SDS-RKEK.
A905 KDA [56C] One-Step Hash KDF, using SHA-256 Key derivation for sensitive data communications.
C1958 KTS [38F] §3.1¶3 (AES GCM with 256-bit keys) Sensitive data storage.
C1953 RSA [186] n=2048 (SHA-256, SHA-384, SHA-512);
n=3072 (SHA-256, SHA-384, SHA-512);
n=4096 (SHA-256, SHA-384, SHA-512)
PKCS 1.5 signature verification.
C1955 SHS [180] SHA-256 Message digest used exclusively by the DRBG.
C1952 SHS [180] SHA-224, SHA-256, SHA-384, SHA-512 Message digest for all purposes other than DRBG.
AES GCM is used by the Sensitive Data Storage service. In accordance with [140IG] A.5, the 96-bit IV is generated in its
entirety randomly using the Approved DRBG within the Module boundary. The DRBG seed is generated inside the Module
boundary, and the Module’s entropy source has been assessed in accordance with [140IG] 7.18 for conformance to [90B].
2
The Module facilitates the use of truncated MACing but enforces a minimum of 32 bits – see [107].
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 9 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
AES GCM is also used to support TLS primitives, and adheres to the [140IG] A.5 Resolution 1a TLS 1.2 protocol IV generation
requirements.3
The Module supports the following ciphersuites used in TLS primitives:
Table 5: Ciphersuites Supported for Use with Module TLS Primitives
Hex Enum IETF Cipher Suite Enumeration RFC TLS KEx Sig PRF Cipher Auth
0xC0,0x2B TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 5289 v1.2 ECDHE ECDSA HMAC-SHA-256 AES-128 GCM
0xC0,0x2C TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 5289 v1.2 ECDHE ECDSA HMAC-SHA-384 AES-256 GCM
0xC0,0xAD TLS_ECDHE_ECDSA_WITH_AES_256_CCM 7251 v1.2 ECDHE ECDSA HMAC-SHA-256 AES-256 CCM
0xC0,0x23 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 5289 V1.2 ECDHE ECDSA HMAC-SHA-256 AES-128 HMAC
0xC0,0x24 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 5289 V1.2 ECDHE ECDSA HMAC-SHA-384 AES-256 HMAC
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.8 Scenario X1 Path 2, option 2 (KAS-ECC-SSC using curve P-
256 and One-Step Hash KDF)4
;
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.8 Scenario X1 Path 2, option 1 (KAS-ECC-SSC using curve P-256 or
P-384 and TLS v1.2 KDF)5
.
Table 6: Non-Approved but Allowed Cryptographic Functions
Algorithm Description
AES CCM Hardware implementation of AES CCM (no security claimed - [140IG] 1.23), used by Generic Data Storage service.
ECDSA Use of Brainpool curves, allowed for use per [140IG] A.2:
- BrainpoolP256R1 (128-bit security strength);
- BrainpoolP384R1 (192-bit security strength).
KAS-ECC-SSC Use of Brainpool curves in KEK, allowed for use per [140IG] A.2 and scenario[140IG] D.8 Scenario X2:
- BrainpoolP256R1 (available for both KEK and TLS use cases; 128-bit security strength);
- BrainpoolP384R1 (available only for TLS use case; 192-bit security strength).
The set of functions in Table 4 above are available but not self-tested in the non-approved mode. In the non-approved
mode, the Module provides additional security functions not available in the approved modes, as shown next.
Table 7: Non-Approved Mode Security Functions
Attestation and manufacturing protection services.
Butterfly key expansion (see [BEKDF]).
ECIES-256 encryption/decryption (see IEEE Standard 1363a™-2004).
ECQV: public key reconstruction from implicit certificate.
Firmware image decryption.
3
Validated against an independently developed instance of TLS 1.2. The IV is generated from a 32-bit nonce provided by
the user protocol code followed by a 64-bit counter managed by the module. Rate limitation ensures uniqueness for more
than 6x106
years.
4
KAS (KAS-SSC Cert. #A904, KDA Cert. #A905); provides 128 bits of strength
5
KAS (KAS-SSC Cert. #A904, CVL Cert. #A1251); provides 128 or 192 bits of strength
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 10 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
2.1 Critical Security Parameters (CSPs) and Public Security Parameters (PSPs)
Table 8: CSPs and PSPs
Identifier Type and Usage Description
DRBG-EI Hash_DRBG entropy input – see detail below.
DRBG-State Hash_DRBG internal state (V and C).
DS-Private ECDSA (P-256, P-384; [SP] Table 6 Brainpool curves) digital signature generation private key.
DS-Public ECDSA (P-256, P-384; [SP] Table 6 Brainpool curves) public key for digital signature verification.
KEK-SS Key agreement shared secret, KEK use case.
KEK-Local-Private Key agreement ephemeral EC private key (P-256; BrainpoolP256R1), KEK use case.
KEK-Local-Public Key agreement ephemeral EC public key (P-256; BrainpoolP256R1), KEK use case.
KEK-Host-Public Key agreement ephemeral EC public key (P-256; BrainpoolP256R1), KEK use case.
MAC-AK AES key (128, 192 or 256-bit) used for AES CMAC generation and verification;
HMAC key (224, 256, 384 or 512-bit) used for HMAC generation and verification.
SC-EDK AES key (128, 192 or 256-bit) used for AES encrypt and decrypt.
SDS-AT 32-bit authentication token.
SDS-BEK Blob encryption key (256-bit AES) used for secure off-chip storage, derived from ZMK using KBKDF.
SDS-KEK Key encryption key, used to unwrap imported keys.
SDS-RKEK Root key encryption key, used to unwrap imported keys, derived from ZMK using KBKDF.
SRK-NXP ECDSA (P-384) public key used for SECO firmware authentication.
SRK-OEM Public key used for non-SECO firmware authentication.
ECDSA P-256, P-384, P-521 -- or -- RSA n=2048, n=3072, n=4096.
SRKH-NXP Reference used to verify SRK-NXP.
SRKH-OEM Reference used to verify SRK-OEM.
TLS-Local-Private EC (P-256, P-384; [SP] Table 6 Brainpool curves) local private key for key agreement.
TLS-Local-Public EC (P-256, P-384; [SP] Table 6 Brainpool curves) local public key for key agreement.
TLS-Peer-Public EC (P-256, P-384; [SP] Table 6 Brainpool curves) peer public key for key agreement.
TLS-MS TLS master_secret (48-byte value): TLS KDF intermediate value (used to derive TLS-KB).
TLS-PS TLS pre_master_secret: TLS KDF intermediate value (used to derive TLS-MS).
TLS-KB TLS key_block: TLS KDF intermediate value used to form a TLS SC-EDK instance; depending on key exchange call
flags, will derive either TLS MAC-AK instance or GCM or CCM IVs.
ZMK Zeroizable master key (256-bit AES key used to derive SDS-BEK, SDS-RKEK).
The DRBG is seeded via the [90A] hash_df 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.799 of min_entropy per bit of entropy input, hence the
DRBG is seeded with 409 bits of effective entropy, sufficient to support the strength of the largest key generated by the
Module.
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 established onto the Module in a factory setting prior to deployment.
ZMK is generated on the Module during provisioning.
SDS-BEK and SDS-RKEK are derived from ZMK 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; SDS-KEK must be imported into the Module encrypted by
SDS-RKEK or SDS-KEK. SDS-RKEK is exported in a factory setting during chip provisioning; at the end of provisioning, the
chip lifecycle state is advanced to the setting required for use of the Module in the Approved modes, and the provisioning
command to export SDS-RKEK is unavailable. 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.
● Use of services that require a CSP are authenticated via a Sensitive Data Storage service command;
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 11 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
● Keys may be locked to remain in Secure RAM, or if unlocked, may be swapped in and out as required.
The SDS-AT is entered into the Module in plaintext over a Trusted Path, managed entirely within the physical boundary of
the i.MX 8X SoC, and reliant on the Module’s physical protections. The Trusted Path is protected by the Module’s hardware
access control – 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).
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-Local-
Public 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:
o KEK-Local-Private and KEK-Local-Public are generated, compliant with [56A] §5.6.2.1 owner key pair assurances;
o KEK-Local-Private and KEK-Host-Public are used in KAS-ECC-SSC to calculate a shared secret (KEK-SS);
o KEK-SS is used with the [56C] One-Step KDF to derive SDS-KEK, which is retained within the Module;
o 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-Local-
Private 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.MX 8X 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:
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 [56A] §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 [135] 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 [135] 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 (TLS-
Local-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’s TLS support corresponds to [140IG] D.11 case 2 (providing a CAVP validated TLS v1.2 KDF),
which requires the following statement:
No parts of the TLS protocol, other than the KDF, have been tested by the CAVP and CMVP.
o Note 4. The Module addresses all [56A] §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. [56A] §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
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 12 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
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 [56A] assurance requirements are met.
3 Roles, Authentication and Services
All operator roles and corresponding authentication methods supported by the Module are listed below. 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.
Table 9: Module Roles
Role ID Role Description
CO Cryptographic Officer: 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.
3.1 CO Authentication
In the i.MX 8X 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 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 (P-384). P-384 equivalent security strength
is 192 bits according to [57], therefore the probability of false authentication for a single attempt is 1/(2^192) = 1.6E-58,
better than the required probability of 1E-06.
Authentication failure causes the Module to enter the Locked error state, with reboot (requiring at least 1 millisecond) to
clear the error state, therefore the probability of false authentication over a one-minute interval is (60*1000)/(2^192) =
9.6E-54, better than the required probability of 1E-05.
3.2 User Authentication
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 FIPS HSM mode for another
attempt). Therefore, the probability of false authentication:
● for one random attempt is 1/(2^32) = 2.3E-10, better than the 1E-06 requirement.
● over a one-minute interval is (60*500)/(2^32) = 7.0E-06, better than the 1E-05 requirement.
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 13 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
3.3 Approved Mode Services
Table 11 describes the Module services, and Table 11 describes access to those services by operator role, and access by
service to CSPs and PSPs (public security parameters, e.g., public keys).
Table 10: Service Descriptions
Service Description
FIPS Boot mode – Services available to CO role operator
Initialize (self-test) Authenticate and load SECO firmware; run FIPS Boot mode self-tests.
Authenticate Authenticate firmware images or commands.
Management (status) SECO device control and status. Get mode, status and version information; configure or manage the
SECO device.
FIPS HSM mode – Unauthenticated services
Initialize (FIPS self-test) Initialize, run FIPS HSM mode self-tests.
Authenticate Authenticate command or firmware images; verify a digital signature.
Generic Data Storage Management of generic data, media parameter storage.
Hash Generate or verify message digest.
Management (FIPS status) SECO device control and status. Get mode, status and version information; configure or manage the
SECO device.
Random DRBG generation of random bits.
Session Initialize session communications
FIPS HSM mode – Services available to User role operator
Generate Signature Generate a digital signature.
Key Agreement: KEK use case Perform the KAS-ECC-SSC and One-Step Hash KDF in an atomic command to establish an SDS-KEK
instance.
Key Agreement: TLS use case Perform the KAS-ECC-SSC and TLS v1.2 KDF in an atomic command to establish instances of SC-EDK
(for message encrypt / decrypt) and optionally, MAC-AK (when HMAC-SHA is used for integrity in
CBC base ciphersuites).
Support the TLS Finish calculation using TLS-MS.
Key Management Generate key or key pair; manage (invalidate, import, update) key or key group. Invalidate refers to
marking keys invalid – automatic zeroization on invalidation is a programmable option.
MAC CMAC or HMAC generate and verify.
PK Recover Recover public key from private key.
Sensitive Data Storage Management of sensitive data storage using AES GCM authenticated cipher.
Symmetric Cipher Encrypt or decrypt data (including authenticated encrypt / decrypt).
Zeroize Destroy ZMK; renders other CSPs unusable.
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 14 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
The modes of access shown in the table are defined as:
● E = Execute: The service uses the CSP/PSP in an algorithm.
● G = Generate: The service generates/derives the CSP/PSP.
● I = Input: The service inputs the CSP/PSP.
● O = Output: The service outputs the CSP/PSP.
● Z = Zeroize: The service zeroizes (destroys) the CSP/PSP.
● -- = No access. The service does not access the CSP/PSP.
Table 11: Service Access to CSPs and PSPs
Service
CSPs and PSPs
DRBG-EI
DRBG-State
DS-Private
DS-Public
KEK-SS
KEK-Local-Private
KEK-Local-Public
KM-Host-Public
MAC-AK
SC-EDK
SDS-AT
SDS-BEK
SDS-KEK
SDS-RKEK
SRK-NXP
SRK-OEM
SRKH-NXP
SRKH-OEM
TLS-Local-Private
TLS-Local-Public
TLS-Peer-Public
TLS-MS
TLS-PS
TLS-KB
ZMK
FIPS Boot mode – Services available to CO role operator
Initialize (self-test) -- -- -- -- -- -- -- -- -- -- -- -- -- -- IE -- E -- -- -- -- -- -- -- --
Authenticate -- -- -- -- -- -- -- -- -- -- -- -- -- -- IE IE E E -- -- -- -- -- -- --
Management (status) -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
FIPS HSM mode – Unauthenticated services
Initialize (FIPS self-test) GE GE -- -- -- -- -- -- -- -- -- G -- G -- -- -- GE -- -- -- -- -- E
Authenticate -- -- -- IE -- -- -- -- -- -- -- -- -- -- IE IE E E -- -- -- -- -- --
Generic Data Storage -- E -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Hash -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Management (FIPS status) -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Random -- E -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Session -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
FIPS HSM mode – Services available to User role operator
Generate Signature -- E IE -- -- -- -- -- -- -- E E -- -- -- -- -- -- -- -- -- -- -- -- --
Key Agreement: KEK use case -- E -- -- GE GEZ GO IE -- -- -- -- G -- -- -- -- -- -- -- -- -- -- -- --
Key Agreement: TLS use case -- E -- -- -- -- -- -- G G -- -- -- -- -- -- -- -- GEZ GO IE GE GEZ GZ --
Key Management -- E
G
IO
GO
--
G GO --
GE
IO
G
IO
E E
G
IE
E
G
IO
-- -- -- -- -- -- Z -- -- --
MAC -- -- -- -- -- -- -- -- IE -- E E -- -- -- -- -- -- -- -- -- -- -- -- --
PK Recover -- -- E GO -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Sensitive Data Storage -- -- -- -- -- -- -- -- -- -- IE E -- -- -- -- -- -- -- -- -- -- -- -- --
Symmetric Cipher -- -- -- -- -- -- -- -- -- IE E E -- -- IE -- -- -- -- -- -- -- -- -- --
Zeroize Z Z Z -- -- -- -- -- Z Z Z Z Z Z Z -- -- -- -- -- -- -- -- -- Z
In the non-approved mode of operation, the Module provides all functionality listed above as well as the functionality
listed in Table 7:
● Firmware image decryption associated with firmware authentication;
● Attestation and manufacturing protection (briefly, the digital signature of device information to confirm authenticity);
● Automotive security service (V2X):
o ECIES-256 encryption/decryption per IEEE Standard 1363a™-2004;
o Butterfly key expansion service per [BEKDF].
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 15 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
4 Initialization and Self-Test
The Module conforms to [140IG] 9.5 Module Initialization During Power-Up: the on-chip System Control Unit (SCU) copies
the SECO firmware container into the SECO M0+ RAM, raising an interrupt when firmware is available. The Module
initialization period starts in ROM. If configured for approved mode operation (as described in Section 1), the Module
executes FIPS Boot mode initialization, performing the self-tests listed in Table 12. As allowed by [140IG] 9.13, 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 SHA-512 hash of SRKs
to the OTP reference value SRKH.
Table 12: FIPS Boot Mode Self-Tests
Test Target Cert Description
Firmware integrity C1957 ECDSA signature verification (#C1957) using P-384, SHA-384.
ECDSA
(SHA-512, SHA-384)
C1957
C1952
ECDSA signature verification KAT using P-521, SHA-512;
per [140 IG] 9.4, covers SHA-512 and SHA-384 KATs.
RSA
(SHA-256)
C1953
C1952
RSA signature verification KAT using n=2048, SHA-256;
per [140 IG] 9.2, covers SHA-256 KAT.
Receipt of the FIPS HSM mode Initialize service message causes the Module to transition to the FIPS HSM mode
initialization period. In accordance with [140IG] 1.7, the Module performs the complete set of self-tests required for each
Approved mode of operation. The hardware DRBG implementation and accompanying SHA-256 self-tests are initiated on
transition into the FIPS HSM mode and completed before the Module completes the initialization period and begins
processing FIPS HSM mode services.
Table 13: FIPS HSM Mode Self-Tests
Test Target Cert Description
AES GCM
(AES CCM)
(AES CBC, ECB)
C1958
C1954
C1951
Separate encrypt and decrypt KATs using an AES-128 key in GCM mode;
per [140 IG] 9.4, covers CCM;
per [140 IG] 9.4, covers AES forward cipher.
AES C1951 Inverse (decrypt) KAT using an AES-128 key in ECB mode.
DRBG
(SHA-256)
C1955
C1955
Instantiate, generate and reseed KATs using the DRBG and associated SHA-256;
per [140 IG] 9.4, covers SHA-256.
ECDSA
(SHA-256)
C1957
C1952
ECDSA PCT using P-256, SHA-256;
per [140 IG] 9.2, covers SHA-256.
KAS-ECC-SSC A904 KAT using P-256; complies with [140 IG] D.8.
KDA A905 KAT of One-Step SHA-256 KDF; complies with [140 IG] D.8.
KBKDF
(AES CMAC)
C1959
C1956
KAT using 256-bit AES key;
per [140 IG] 9.2, covers AES CMAC KAT.
RSA
(SHA-256, SHA-224)
C1953
C1952
RSA signature verification KAT using n=2048, SHA-256;
per [140 IG] 9.2, covers SHA-256 and SHA-224 KATs.
SHA-512
(SHA-384)
C1952
C1952
SHA-512 KAT;
per [140 IG] 9.4, covers SHA-384.
TLS v1.2 KDF
(HMAC-SHA-256)
A1251
A892
KAT using 384-bit Z; complies with [140 IG] D.8;
per [140 IG] 9.2, covers HMAC-SHA-256.
Table 14: Module Conditional Self-Tests
Test Target Description
CRNGT
Entropy source health testing (Total Failure Test and a Bit Health Test) in accordance with [90B] section 4.4, as well
as the [140] Section 4.9.2 CRNGT.
ECDSA PCT Pairwise consistency test performed in accordance with [140 IG] 9.9 for each key pair generated.
NXP Semiconductors i.MX 8X SECO HSMv2 FIPS 140-2 Security Policy
Copyright NXP Semiconductors 2022 Version 2.0 Page 16 of 16
NXP Semiconductors Public Material – may be reproduced only in its original entirety (without revision)
5 Physical Security
The Module is a single-chip embodiment. No additional operator actions are required to ensure that physical security is
maintained.
6 Mitigation of Other Attacks
The Module implements defenses against temperature, voltage and clock frequency out of range. [140IG] 11.1 is
applicable to the clock frequency, temperature, and voltage sensors. [140IG] 5.5 is not claimed. The clock frequency,
temperature and voltage sensors generate an out-of-range signal that causes a security violation to clear authentication,
zeroize ZMK (effectively zeroizing the Module) and block access to sensitive information.
7 Security Rules and Guidance
The Module implementation enforces the following security rules:
● The Module provides two distinct operator roles: User and Cryptographic Officer.
● The Module does not support a maintenance interface or role.
● The Module provides identity-based authentication.
● 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 above. These services do not require use of secret or
private keys and conform to [140IG] 3.1.
● Power up self-tests do not require any operator action.
● No additional interface or service is implemented by the Module which would provide access to CSPs.
● Data output is inhibited during key generation, self-tests, zeroization, and error states.
● The Module clears previous authentications on power cycle.
● The Module does not support manual key entry.
● The Module does not output plaintext CSPs or intermediate key values.
● Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the Module.