Nuvoton Cryptographic Library 2.3

Certificate

Approved Algorithms (25)

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

flowchart LR
  %% Deterministic review-risk graph for Nuvoton Cryptographic Library 2.3
  %% 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>update<br/>Firmware Load</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>status output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<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 Nuvoton Cryptographic Library 2.3
  %% 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>update<br/>Firmware Load</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>status output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<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

Nuvoton Cryptographic Library 2.3 Hardware Version 2.3.8 Version 1.2 Last update: 2025-01-07 Prepared by: atsec information security corporation

Austin, TX 78759 www.atsec.com © 2024 Nuvoton Technology Corporation / atsec information security.

© 2024 Nuvoton Technology Corporation / atsec information security.

This document is the non-proprietary FIPS 140-3 Security Policy for Hardware version 2.3.8 of the Nuvoton Cryptographic Library 2.3. It has a one-to-one mapping to the [SP 800-140B] starting with section B.2.1 named “General” that maps to section 1 in this document and ending with section B.2.12 named “Mitigation of other attacks” that maps to section 12 in this document. This document also contains the security rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for a Security Level 1 module. Table 1 describes the individual security areas of FIPS 140-3, as well as the Security Levels of those individual areas: ISO/IEC 24759 FIPS 140-3 Section Title Security Section 6. Level [Number Below]

Overall Level 1 Table 1 - Security Levels © 2024 Nuvoton Technology Corporation / atsec information security.

The Nuvoton Cryptographic Library 2.3 cryptographic module (hereafter referred to as “the module”) is a Hardware single-chip cryptographic module. More specifically, the module is considered a sub-chip cryptographic subsystem as defined in IG 2.3.B. The module has been tested by atsec CST lab on the following platforms: Model/Part Hardware Firmware Processor(s) Non-Security Number(s) Version(s) Relevant Version(s) Distinguishing Features Nuvoton NPCM8mnx 2.3.8 N/A ARM Cortex -M4 N/A Core Arbel Baseboard Management Controller (BMC) Table 2 - Cryptographic Module Tested Configuration

The module only supports approved mode of operation. There are no non-approved but allowed algorithms used in approved mode. There are no non-approved algorithms used in the approved mode with no security claimed. There are no non-approved algorithms used in a non-approved mode.

The Table 3 below lists all security functions of the module, including specific key strengths employed for approved services, and implemented modes of operation. CAVP Algorithm and Mode / Method Description / Key / Use / Function Cert Curve / Modulus Standard Size(s) A4133 AES CBC ECB 128, 192, 256 bits AES Encryption and AES Decryption [SP 800-38 A] CCM OFB [SP 800-38 C] CFB128 AES CTR 128, 192, 256 bits [SP 800-38 A] AES GCM 128, 192, 256 bits [SP 800-38 D] AES CMAC 128, 192, 256 bits CMAC Message Authentication Code Generation and CMAC Message [SP 800-38 B] Authentication Code Verification © 2024 Nuvoton Technology Corporation / atsec information security.

CAVP Algorithm and Mode / Method Description / Key / Use / Function Cert Curve / Modulus Standard Size(s) AES GMAC 128, 192, 256 bits GMAC Message Authentication Code Generation and GMAC Message [SP 800-38 D] Authentication Code Verification HMAC HMAC-SHA2-256 256, 384, 512 bits HMAC Message Authentication Code Generation [FIPS 198-1] HMAC-SHA2-384 HMAC-SHA2-512 RSA RSA-PSS using SHA2-256, 2048 or 3072 modulus RSA Signature Generation, [FIPS 186-4] SHA2-384 or SHA2-512 RSA Signature Verification RSA-PKCS#1 v1.5 using SHA2-256, SHA2-384 or SHA2-512 KBKDF KDF Modes: Counter, 256, 384, 512 bits Key Derivation Function [SP800-108] Feedback, Double pipeline iteration MAC Modes: HMAC-SHA2256, HMAC-SHA2-384, HMAC-SHA2-512 KTS-IFC KTS-OAEP-basic 2048 or 3072 modulus RSA Key Transport (key wrapping and un-wrapping) [SP800-56Brev2] ECDSA B.4.2 Testing Candidates P-256, P-384, P-521 ECDSA Key Generation curves [FIPS 186-4] NA P-256, P-384, P-521 ECDSA Key Verification curves SHA2-256, SHA2-384, P-256, P-384, P-521 ECDSA Signature Generation, SHA2-512 curves ECDSA Signature Verification N/A P-256, P-384, P-521 ECDSA Signature Generation curves Component SHS SHA2-256 N/A Message Digest Generation [FIPS 180-4] SHA2-384 SHA2-512 KAS-ECC-SSC ephemeralUnified P-256, P-384, P-521 EC Diffie-Hellman Shared Secret [SP800-56Arev3] curves Computation (complete) © 2024 Nuvoton Technology Corporation / atsec information security.

CAVP Algorithm and Mode / Method Description / Key / Use / Function Cert Curve / Modulus Standard Size(s) Hash_DRBG SHA2-512 512 Random Number Generation [SP800-90A] Vendor CKG (Cryptographic Key SP800-133rev2 Section N/A ECDSA Key Generation Affirmed Generation) 5.1 and FIPS 186-4: direct [SP800-133rev2] output U from approved DRBG; no XOR, no post[FIPS 186-4] processing E94 ESV N/A Used to seed the Random Number Generation [SP800-90B] SP800-90Arev1 DRBG Table 3 - Approved Algorithms

Figure 1 depicts the module’s block diagram with a red outline indicating the Tested Operational Environment’s Physical Perimeter (TOEPP) of the NPCM8mnx and the blue dotted outline depicting the cryptographic boundary of the sub-chip embedded within the physical perimeter. Figure 1 - [Block Diagram] © 2024 Nuvoton Technology Corporation / atsec information security.

Figure 2 shows a picture of the NPCM8mnx (BMC) in which the sub-chip module is embedded. Figure 2: Nuvoton NPCM8mnx © 2024 Nuvoton Technology Corporation / atsec information security.

The underlying logical interfaces of the module are the module’s C language Application Programming Interfaces (APIs). All data input and data output, status ports and control ports are directed through the interface of the module’s logical component, which are the APIs while the physical interface is considered the I/O ports of the sub-chip module through which the data input and data output, status output and control input traverse. Physical Interface Logical Interface1 Data that passes over port/interface I/O Ports Data Input Data inputs are provided in the variables passed in the API and callable service invocations, generally through caller-supplied buffers I/O Ports Data Output Data outputs are provided in the variables passed in the API and callable service invocations, generally through caller-supplied buffers I/O Ports Control Input Control inputs which control the operation of the module are provided through dedicated parameters. I/O Ports Status Output Status output is provided in return codes and through messages. Documentation for each API lists possible return codes. A complete list of all return codes returned by the C language APIs within the module is provided in the header files and the API documentation. Messages are documented also in the API documentation. Power Port Power Interface Power interface is provided internally by TEOPP in which the cryptographic module is embedded. Table 4 - Ports and Interfaces

© 2024 Nuvoton Technology Corporation / atsec information security.

The module supports two authorized roles: A Crypto Officer Role and a User Role. No support is provided for a Maintenance operator. The module does not implement a bypass mode nor concurrent operators. The Crypto Officer is implicitly assumed. Crypto Officer may be used to facilitate the module's audit functions by invoking the "Get Module Description" or "Show-Status" services. The User can perform any of the other services mentioned in Table 5. The Users of the module are software applications that implicitly assume the User Role when requesting any cryptographic services provided by the module. FIPS 140-3 does not require authentication mechanism for level 1 modules. Therefore, the module does not implement an authentication mechanism. The module only implements Approved security functions in an Approved mode. Table 5 below lists services available. The module provides an approved service indicator by receiving a return code of “NCL_STATUS_OK to indicate that the service executed an approved security function. NOTE: The module does not implement any non-Approved Algorithms (neither with nor without security claim). The abbreviations of the access rights to keys and SSPs have the following interpretation: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g., the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. Service Description Inputs Outputs Approved Keys Roles Access rights Indicator Security and/or to Keys and/or Functions SSPs SSPs AES Data AES key cipher text AES-CBC AES key User W, E NCL_STATUS_OK Encryption Encryption and plain AES-ECB text AES-CCM AES-OFB AES-CFB128 AES-CTR AES-GCM AES Data AES key plain text AES-CBC AES key User W, E NCL_STATUS_OK Decryption Decryption and AES-ECB cipher AES-CCM text AES-OFB AES-CFB128 AES-CTR AES-GCM CMAC Message AES key MAC AES-CMAC AES key User W, E NCL_STATUS_OK Message Authentication and Authenticatio Code message n Code Generation M Generation © 2024 Nuvoton Technology Corporation / atsec information security.

Service Description Inputs Outputs Approved Keys Roles Access rights Indicator Security and/or to Keys and/or Functions SSPs SSPs CMAC Message MAC and “VALID” or AES-CMAC AES key User W, E NCL_STATUS_OK Message Authentication Message “INVALID” Authenticatio Code n Code Verification Verification GMAC Message AES key, authenticat AES-GMAC AES key User W, E NCL_STATUS_OK Message Authentication AAD ion tag Authenticatio Code n Code Generation Generation GMAC Message AES key, “PASS” or AES-GMAC AES key User W, E NCL_STATUS_OK Message Authentication AAD, IV, “FAIL” Authenticatio Code authentic n Code Verification ation tag Verification HMAC Message HMAC MAC HMAC-SHA2- HMAC User W, E NCL_STATUS_OK Message Authentication key and 256 HMAC- key Authenticatio Code message SHA2-384 n Code Generation HMAC-SHA2Generation 512 Message SHS Message message digest SHA2-256 none User N/A NCL_STATUS_OK Digest Digest (hash SHA2-384 Generation Generation value) SHA2-512 RSA Key Key RSA encapsulat KTS-IFC RSA User W, E NCL_STATUS_OK Transport encapsulation public ed key public (encapsulatio using KTS- key and key n) OAEP-basic key to be encapsul ated RSA Key Key Un- RSA plaintext KTS-IFC RSA User W, E NCL_STATUS_OK Transport encapsulation private key private (un- using KTS- key and key encapsulation OAEP-basic key to be ) unencapsul ated RSA Digital Digital RSA signature RSA-PSS, RSA User W, E NCL_STATUS_OK Signature Signature private RSA-PKCS#1 private Generation Generation key, v1.5 Signature key message Generation, and hash Hash_DRBG algorithm RSA Digital Digital RSA True or RSA-PSS, RSA User W, E NCL_STATUS_OK Signature Signature public False RSA-PKCS#1 public Verification Verification key, v1.5 Signature key signature Verification and hash algorithm © 2024 Nuvoton Technology Corporation / atsec information security.

Service Description Inputs Outputs Approved Keys Roles Access rights Indicator Security and/or to Keys and/or Functions SSPs SSPs ECDSA Digital Digital ECDSA signature ECDSA Digital ECDSA User W, E NCL_STATUS_OK Signature Signature private Signature private Generation Generation key, Generation, key message Hash_DRBG and hash algorithm ECDSA Digital Digital ECDSA signature ECDSA Digital ECDSA User W, E NCL_STATUS_OK Signature Signature private Signature private Generation Generation key and Generation key Component Component message Component, digest Hash_DRBG ECDSA Digital Digital ECDSA True or ECDSA Digital ECDSA User W, E NCL_STATUS_OK Signature Signature public False Signature public Verification Verification key, Verification key signature and hash algorithm ECDSA Key Asymmetric Curve generated ECDSA Key ECDSA User G, R NCL_STATUS_OK Generation Key Pair size private and Generation, Key pair Generation public keys Hash_DRBG, CKG EC Diffie- Shared Secret received shared KAS-ECC-SSC ECDH User W, E NCL_STATUS_OK Hellman Computation public secret public Shared Secret using Elliptic key and key Computation Curve possesse Cryptography d private ECDH E key private key shared G, R secret Key Perform key Key Derived KBKDF Derived User G, R, E NCL_STATUS_OK derivation derivation material key key Random Deterministic number random Hash_DRBG Entropy User W NCL_STATUS_OK Number Random of bits numbers input Generation Number string, Generation nonce seed, V, G and C Get Module Outputs None Module N/A None CO N/A N/A Description Module Name Name + + Version Module Number Version Number © 2024 Nuvoton Technology Corporation / atsec information security.

Service Description Inputs Outputs Approved Keys Roles Access rights Indicator Security and/or to Keys and/or Functions SSPs SSPs SSP zeroizes handle of zeroized N/A All Keys User Z N/A Zeroisation crypto crypto and / SSPs function function released context and context memory releases space memory space Show-Status Outputs None Operational N/A None CO N/A N/A Operational/ /Error Error status of status the module Self-test2 Executes on- None Pass/Fail HMAC-SHA2- HMAC User E NCL_STATUS_OK demand self- status 512 Key test and outputs SHA2-256 N/A Pass/Fail status AES-CCM AES Key AES-CBC AES Key RSA PKCS#1 RSA v1.5 Signature Private Generation Key RSA PKCS#1 RSA v1.5 Signature Public Verification Key KBKDF Key Derivati on Key, Derived Key KTS-IFC RSA Key (encapsulation) Pair, Encapsu lated key ECDSA ECDSA Signature Private Generation Key ECDSA ECDSA Signature Public Verification Key 2Keys and SSPs used in this service are hard-coded in the module and used exclusively for self-tests. © 2024 Nuvoton Technology Corporation / atsec information security.

Service Description Inputs Outputs Approved Keys Roles Access rights Indicator Security and/or to Keys and/or Functions SSPs SSPs KAS-ECC-SSC ECDH Key Pair, Shared Secret Hash_DRBG Seed Table 5 - Approved Services © 2024 Nuvoton Technology Corporation / atsec information security.

The module’s executable code is programmed in a masked ROM which is a type of Read-Only Memory (ROM) where content is programmed by the integrated circuit manufacturer during the silicon manufacturing (rather than by the Operator of the module). The memory technology is non reconfigurable memory as defined in IG 5.A, which will not have any change or degradation of data for a minimum of 10 years after manufactured date. As such, it is considered a hardware only module with a non-modifiable operational environment. The requirements of this area are not applicable to the module. © 2024 Nuvoton Technology Corporation / atsec information security.

The Nuvoton Cryptographic Library 2.3 operates in a non-modifiable operational environment. The module is programmed by the manufacturer during the silicon manufacturing (rather than by the user). It maintains its own memory region which can only be accessed by the module. There is no additional application present within the operating environment. The module does not spawn any cryptographic processes. The operational environments in which the module was tested are listed in Table 2. © 2024 Nuvoton Technology Corporation / atsec information security.

The Nuvoton Cryptographic Library 2.3 cryptographic module is a Hardware cryptographic module in a single-chip embodiment. More specifically, the module is considered a sub-chip cryptographic subsystem. The module consists of production-grade components that include standard passivation techniques (e.g., a conformal coating applied over the module’s circuitry to protect against environmental or other physical damage). The module does not implement a maintenance role and has no maintenance access interface. © 2024 Nuvoton Technology Corporation / atsec information security.

Currently, the non-invasive security is not required by FIPS 140-3 (see NIST SP 800-140F). The requirements of this area are not applicable to the module. © 2024 Nuvoton Technology Corporation / atsec information security.

The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module. Modification of PSPs by unauthorized operators is prohibited. Key/SSP Streng Securit Generati Import Establishm Stora Zeroizati Use & Name/ th y on ent ge on related /Export Type Functi keys on and Cert. Numb er AES key 128, AES Not Entry: The N/A Volatile automatic Use: AES 192, 256 Applicable. key is memor zeroization Data - bits of CAVP The key is entered into y when Encryption security Cert. entered via the module structure is and strength #A4133 API within the deallocated Decryption parameter TOEPP3 via or when API input the system Related parameters is powered Keys: N/A in plaintext. down. Output: N/A RSA 112 to KTS-IFC Not Entry: The N/A Volatile automatic Use: Key private 128 bits Applicable. key is memor zeroization Encapsulati and public of CAVP The key is entered into y when on and Unkey security Cert. entered via the module structure is encapsulati strength #A4133 API within the deallocated on parameter TOEPP via or when API input the system Related parameters is powered Keys: Used in plaintext. down. to establish Encapsulat Output: The ed key key is output from the module within the TOEPP via API output parameters in plaintext Encapsulat 112 to KTS-IFC N/A Entry: The Established by Volatile automatic Use: ed key 128 bits key is KTS-IFC memor zeroization Established of CAVP entered into y when by KTS-IFC security Cert. the module structure is strength #A4133 within the deallocated Related TOEPP via or when Keys: API input the system Established parameters is powered using RSA in plaintext. down. private and public keys Output: The key is output from the module within the

© 2024 Nuvoton Technology Corporation / atsec information security.

Key/SSP Streng Securit Generati Import Establishm Stora Zeroizati Use & Name/ th y on ent ge on related /Export Type Functi keys on and Cert. Numb er TOEPP via API output parameters in plaintext RSA 112 to RSA Not Entry: The N/A Volatile automatic Use: private 128 bits Applicable. key is memor zeroization Signature and public of CAVP The key is entered into y when Generation key pair security Cert. entered via the module structure is and strength #A4133 API within the deallocated Verification parameter TOEPP via or when API input the system Related parameters is powered Keys: N/A in plaintext. down. Output: The key is output from the module within the TOEPP via API output parameters in plaintext ECDSA 128 to ECDSA The private Entry: The N/A Volatile automatic Use: Key private 256 bits keys can key is memor zeroization Generation and public of CAVP be entered into y when and key pair security Cert. generated the module structure is Verification, strength #A4133 using within the deallocated Signature FIPS186-4 TOEPP via or when Generation Key API input the system and Generation parameters is powered Verification method, in plaintext. down. and the Related random Output: The Keys: value used key is Generated in the key output from using DRBG generation the module internal is within the state generated TOEPP via using API output SP800- parameters 90Arev1 in plaintext DRBG HMAC key 112 or HMAC Not Entry: The N/A Volatile automatic Use: greater Applicable. key is memor zeroization Hashed bits of CAVP The key is entered into y when Message security Cert. entered via the module structure is Authenticati strength #A4133 API within the deallocated on Code parameter TOEPP via or when Generation API input the system parameters is powered Related in plaintext. down. Keys: N/A Output: N/A © 2024 Nuvoton Technology Corporation / atsec information security.

Key/SSP Streng Securit Generati Import Establishm Stora Zeroizati Use & Name/ th y on ent ge on related /Export Type Functi keys on and Cert. Numb er ECDH key 128 to EC The private Entry: The N/A Volatile automatic Use: ECDH pair 256-bits keygen keys are public key memor zeroization Shared (including of generated is entered y when Secret intermedia security CAVP using into the structure is Computatio te key strength Cert. FIPS186-4 module deallocated n generation #A4133 Key within the or when values) Generation TOEPP via the system Related method, API input is powered Keys: and the parameters down. Generated random in plaintext. using DRBG value used internal in the key Output: The state, Used generation key is to establish is output from EC Diffiegenerated the module Hellman using within the Shared SP800- TOEPP via Secret 90Arev1 API output DRBG parameters in plaintext ECC KAS- N/A Entry: N/A Established by Use: ECDH Shared ECC-SSC KAS-ECC-SSC Shared Secret Output: The Secret CAVP key is Computatio Cert. output from n #A4133 the module within the Related TOEPP via Keys: API output Established parameters from ECDH in plaintext key pair Derived 256, KBKDF Derived by Entry: N/A N/A Use: Key key 384, 512 SP 800-108 derivation bits CAVP KBKDF Output: The Cert. key is Related #A4133 output from Keys: the module Derived within the from Key TOEPP via Derivation API output Key parameters in plaintext Key 256, KBKDF The key Entry: The N/A Use: Key Derivation 384, 512 can be key is derivation Key bits CAVP entered via entered into Cert. API the module Related #A4133 parameter within the Keys: Used s, or TOEPP via to derive generated API input Derived key using parameters SP800- in plaintext. 90Arev1 DRBG Output: N/A © 2024 Nuvoton Technology Corporation / atsec information security.

Key/SSP Streng Securit Generati Import Establishm Stora Zeroizati Use & Name/ th y on ent ge on related /Export Type Functi keys on and Cert. Numb er Entropy 256-bits Entropy N/A Entry: N/A N/A Use: Input of Source Random String + security Output: N/A Number Nonce strength ESV Generation Cert. E94 Related Keys: DRBG internal state, Seed DRBG 256-bits Hash Derived Entry: N/A N/A Use: internal of DRBG from Random state (i.e., security entropy Output: N/A Number Hash_DRB strength CAVP input string Generation G V and C Cert. as defined values), #A4133 by SP800- Related Seed 90Arev1 Keys: Entropy Input String + Nonce Table 6 - SSPs

The module employs a Hash_DRBG using a SHA-512 PRF. Per section 10.1.1.1 of [SP800-90A], the internal state of the Hash_DRBG is the V, C, and reseed counter. The Hash_DRBG is seeded by an SP800-90B Entropy Source for which the estimated amount of entropy is ~0.6/bit. The DRBG is seeded with 1024-bits of entropy input thereby providing 256-bits of entropy during initialization and reseeding. The DRBG internal state is not accessible by non-DRBG functions. All random values used by approved security functions, SSP generation, or SSP establishment method are provided by the Hash_DRBG. Entropy Source Minimum number of Details bits of entropy E94 256-bits strength The module includes SP800-90B compliant entropy source based on Ring Oscillators implemented in hardware TRNG. When output is requested from the entropy source, the entropy source fills a 1024-bit buffer with random bits obtained with a single request for entropy data. All 1024-bits are then provided as output from the entropy source. Table 7 - Non-Deterministic Random Number Generation Specification

The module generates Keys and SSPs in accordance with FIPS 140-3 IG D.H. The cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per [SP800© 2024 Nuvoton Technology Corporation / atsec information security.

133rev2] (vendor affirmed), compliant with [FIPS186-4] and using DRBG compliant with [SP80090Arev1]. A seed (i.e., the random value) used in asymmetric key generation is obtained from [SP800-90Arev1] DRBG as described in Section 4 of [SP800-133rev2]. The key generation service for ECDSA, as well as the [SP 800-90Arev1] DRBG have been ACVT tested with algorithm certificates found in Table 3.

The module provides the following key/SSP establishment services:

1. The module implements a key-based key derivation method compliant with SP800-108.
2. The module implements KAS-ECC-SSC EC Diffie-Hellman Shared Secret Computation compliant to [SP800-56Arev3] and IG D.F Scenario (2) path (1). o The shared secret computation provides between 128 and 256 bits of encryption strength.
3. Within the TOEPP, the module offers RSA key wrapping and unwrapping using KTS-OAEPbasic scheme. The implementation supports 2048 and 3072 modulus size, with both key encapsulation and un-encapsulation supported. The module does not implement key confirmation. See section 11.2 for operator guidance details. o The SSP establishment methodology provides 112 or 128 bits of encryption strength.

Keys/SSPs entered or output the module are electronically entered in plaintext form from the invoking User firmware running on the same device. No Keys/SSPs are entered or output from the module to outside the TOEPP. According to IG 2.3.B, Transferring SSPs including the entropy input between a sub-chip cryptographic subsystem and an intervening functional subsystem for Security Levels 1 and 2 on the same single chip is considered as not having Sensitive Security Parameter Establishment crossing the HMI of the sub-chip module per IG 9.5.A.

The module does not provide persistent storage for keys/SSPs. Keys/SSPs are stored in volatile memory only and are received for use by the module only at the request of the User firmware.

The module includes different methods for zeroization:

• Implicit Zeroization which is done automatically by the module when a SSP is no longer needed. Specifically, when completing any service call before the module returns the control to the caller, the module clears out any SSPs that are no longer needed by writing zeros using the memset() function.
• Explicit Zeroization which can be invoked by the caller using NCL_*_Clear (where '*' is the one of the approved algorithms implemented in the module) which deallocates the structure associated with the cipher and overwriting the SSP values with all zeros OR the caller can also power down the device to zeroize all SSPs. While zeroization is being performed, the interface with the module is inhibited and the successful completion of a requested zeroization service suffices as the implicit indicator that zeroization has completed. © 2024 Nuvoton Technology Corporation / atsec information security.

Self-tests ensure that the module is not corrupted and that the cryptographic algorithms work as expected. While the module is executing the self-test, no services are available, and input and output are inhibited. The module will boot only after successfully passing the SHA2-256, HMACSHA2-512 and KBKDF-HMAC-SHA2-256 CASTs. If an error is detected in any self-test, the module will enter the Error State.

The module is solely implemented in hardware (i.e., only contains executable code that is stored in non- reconfigurable masked ROM4). As such, the module does not perform any pre-operational software/firmware integrity test, but instead performs a Cryptographic Algorithm Self-Test on the SHA2-256, HMAC-SHA2-512 and KBKDF-HMAC-SHA2-256 algorithms when the module is powered on. The module does not implement a pre-operational bypass test nor pre-operational critical functions test.

The module performs a conditional self-test when the conditions specified for the following tests occur: Conditional Cryptographic Algorithm Self-Test Conditional Pair-Wise Consistency Test The module does not implement a Software/Firmware Load Test, Manual Entry Test, Conditional Bypass Test nor Conditional Critical Functions Test.

The module conducts conditional cryptographic algorithm self-test prior to the first operational use of each cryptographic algorithm (with the exception of KBKDF, HMAC and SHA CASTs, which are performed at power on). The table below describe the conditional tests supported by the module. Algorithm Test HMAC HMAC-SHA2-512 MAC Generation KAT using 160-bit key SHA SHA2-256 Message Digest KAT KBKDF Counter mode using HMAC-SHA2-256 using 160-bit key AES AES-CCM Encryption KAT using 128-bit key AES-CBC Decryption KAT using 128-bit key KTS-IFC KTS-OAEP-basic Encryption KAT with 2048 -bit key and SHA2-256 KTS-OAEP-basic Decryption KAT with 2048 -bit key and SHA2-256

4 A masked ROM is a type of Read-Only Memory (ROM) where content is programmed by the integrated circuit

manufacturer during the silicon manufacturing. © 2024 Nuvoton Technology Corporation / atsec information security.

Algorithm Test RSA PKCS#1 v1.5 Signature Generation KAT with 2048 -bit key and SHA2-256 PKCS#1 v1.5 Signature Verification KAT with 2048 -bit key and SHA2-256 ECDSA ECDSA Signature Generation KAT with P-256 curve and SHA2-256 ECDSA Signature Verification KAT with P-256 curve and SHA2-256 KAS-ECC-SSC

• ECDH shared secret computation KAT with P-256 curve Hash_DRBG
• Hash_DRBG random number generation KAT using predefined seed. ENT
• RCT (Repetition Count Test)
• APT (Adaptive Proportion Test)
• Startup self-tests with 1024-bit samples (Same process as the two continuous tests shown above) Table 8 - Conditional Cryptographic Algorithm Self-Tests

The module performs a pair-wise consistency test on when a new ECDSA key pair is generated. The pair-wise consistency test is performed by calculating a digital signature and then verifying it. If the signature cannot be verified, the pair-wise consistency test will fail.

During runtime, operators can initiate the conditional self-tests on demand by calling NCL_MISC_SelfTest and passing the algorithm as an argument. The module’s entropy source is powered on only momentarily to seed the module’s SP80090Arev1 DRBG. The module performs ENT health tests defined in Section 4 of SP800-90B on the generated output prior to seeding the SP800-90Arev1 DRBG. After completing its execution, the entropy source powers down.

For any of the conditional self-tests, the module enters an error state upon failing the self-test. A failure in the conditional CAST or conditional PCT results in “NCL_STATUS_FAIL”. Likewise, a failure of the ENT health tests will result in an “ENTROPY_SRC_ERROR” status returned to the user. When in the error state, no cryptographic services are provided. The control and data output interfaces are prohibited while in the error state. The only method to clear this error state is to power cycle the device and then successfully pass the conditional self-tests. Cause of Error Status Indicator failure in conditional self-test NCL_STATUS_FAIL (conditional CAST or conditional PCT) © 2024 Nuvoton Technology Corporation / atsec information security.

Cause of Error Status Indicator failure of the ENT health test ENTROPY_SRC_ERROR Table 9 - Error States © 2024 Nuvoton Technology Corporation / atsec information security.

As explained in Section 10.1.1, the module is placed in a masked ROM by manufacturer during the silicon manufacturing. The module is delivered as part of the Nuvoton NPCM8mnx platform (listed in Table 2). During manufacturing

• each chip is tested to make sure the masked ROM was manufactured correctly; this is done using CRC32 algorithm on the entire masked ROM code on each device before it is shipped out. The hardware version can be found printed on the chip package. The last three letters of the printed version may be represented with the following:
• m: # of cores
• n: GFX (0=No, 5=yes)
• x: Customer During execution
• As part of the device boot process, the code is verified by a dedicated hardware inside the chip that checks every byte of code compared to a known parity bit. If any byte fails, the parity test then an internal error is generated; the error is handled by the application (User) firmware.

The module is configured to be operational by default. If the device starts up successfully and has successfully passed the SHA2-256, HMAC-SHA2-512 and KBKDF-HMAC-SHA2-256 CASTs, it is operating correctly and can begin servicing User requests.

Once the module reaches its end-of-life stage (End of Life (EOL) date for the Nuvoton device is 10 years from manufacturing date) or sanitation is initiated by the module’s Operator, it is the Operator’s responsibility to clear all existing SSPs from the module. This can be achieved by either performing a full device reset, or by explicitly invoking the following sequence of APIs to clear the data from all modules:

• NCL_SHA_Clear - For each of existing SHA, HMAC and KBKDF contexts
• NCL_DRBG_Clear - For each of existing DRBG contexts
• NCL_AES_Clear - For each of existing AES contexts
• NCL_RSA_Clear - For each of existing RSA contexts
• NCL_ECC_Clear - For each of existing ECDSA and ECDH contexts

The module’s AES-GCM implementation conforms to IG C.H scenario 2. The module uses the approved Hash_DRBG to generate the IV with a length of 96-bits. The entropy source producing the DRBG seed is located inside the module’s cryptographic boundary. © 2024 Nuvoton Technology Corporation / atsec information security.

To comply with SP800-56Brev2 assurances found in its Section 6 (specifically SP800-56Brev2 Section 6.4 Required Assurances) The entity using the IUT must obtain required assurances listed in section 6.4 of SP 800-56BRev2 by performing the following steps:

1. The entity requesting the RSA key unwrapping (un-encapsulation) service from the module, shall only use an RSA private key that was generated by an active FIPS validated module that implements FIPS 186-4 compliant RSA key generation service and performs the key pair validity and the pairwise consistency as stated in section 6.4.1.1 of the SP 80056BRev2. Additionally, the entity shall renew these assurances over time by using any method described in section 6.4.1.5 of the SP 800-56BRev2.
2. For use of an RSA key wrapping (encapsulation) service in the context of key transport per IG D.G, the entity using the module, shall verify the validity of the peer's public key using any method specified in section 6.4.2.1 of the SP 800-56BRev2.
3. The entity using the module, shall confirm the peer's possession of private key by using any method specified in section 6.4.2.3 of the SP 800-56BRev2. © 2024 Nuvoton Technology Corporation / atsec information security.

The module does not implement security mechanisms to mitigate other attacks. © 2024 Nuvoton Technology Corporation / atsec information security.

Appendix A. Glossary and Abbreviations AES Advanced Encryption Standard ACVP Algorithm Certification Validation Program CBC Cipher Block Chaining CAST Cryptographic Algorithm Self-Test CCM Counter with Cipher Block Chaining-Message Authentication Code CFB Cipher Feedback CMAC Cipher-based Message Authentication Code CMVP Cryptographic Module Validation Program CSP Critical Security Parameter CTR Counter Mode DRBG Deterministic Random Bit Generator ECB Electronic Code Book ECC Elliptic Curve Cryptography ESV Entropy Source Validation EOL End Of Life FIPS Federal Information Processing Standards Publication GCM Galois Counter Mode HMAC Hash Message Authentication Code KAS Key Agreement Scheme KAT Known Answer Test MAC Message Authentication Code NIST National Institute of Science and Technology OFB Output Feedback PSS Probabilistic Signature Scheme RSA Rivest, Shamir, Addleman SHA Secure Hash Algorithm SHS Secure Hash Standard SSC Shared Secret Computation TOEPP Tested Operational Environment’s Physical Perimeter © 2024 Nuvoton Technology Corporation / atsec information security.

Appendix B. References FIPS140-3 FIPS PUB 140-3 - Security Requirements For Cryptographic Modules March 2019 https://doi.org/10.6028/NIST.FIPS.140-3 FIPS140-3_IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program November 2023 https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips 140-3/FIPS 140-3 IG.pdf FIPS180-4 Secure Hash Standard (SHS) March 2012 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS186-4 Digital Signature Standard (DSS) July 2013 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf FIPS197 Advanced Encryption Standard November 2001 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf FIPS198-1 The Keyed Hash Message Authentication Code (HMAC) July 2008 http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf PKCS#1 Public Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 February 2003 http://www.ietf.org/rfc/rfc3447.txt RFC3394 Advanced Encryption Standard (AES) Key Wrap Algorithm September 2002 http://www.ietf.org/rfc/rfc3394.txt RFC5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm September 2009 http://www.ietf.org/rfc/rfc5649.txt SP800-38A NIST Special Publication 800-38A - Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf SP800-38B NIST Special Publication 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication May 2005 http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf SP800-38C NIST Special Publication 800-38C - Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality May 2004 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf © 2024 Nuvoton Technology Corporation / atsec information security.

SP800-38D NIST Special Publication 800-38D - Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf SP800-38F NIST Special Publication 800-38F - Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping December 2012 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf SP800-56Arev3 NIST Special Publication 800-56A Revision 3 - Recommendation for Pair Wise Key Establishment Schemes Using Discrete Logarithm Cryptography April 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf SP800-56Brev2 Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography March 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf SP800-90Arev1 NIST Special Publication 800-90A - Revision 1 - Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf SP800-90B NIST Special Publication 800-90B - Recommendation for the Entropy Sources Used for Random Bit Generation January 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf SP800-133rev2 NIST Special Publication 800-133 - Recommendation for Cryptographic Key Generation December 2012 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf SP800-140B NIST Special Publication 800-140B - CMVP Security Policy Requirements March 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140B.pdf © 2024 Nuvoton Technology Corporation / atsec information security.