Nuvoton Cryptographic Library 2.0

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Nuvoton Cryptographic Library 2.0
  %% 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<br/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth</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.0
  %% 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<br/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth</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 Technology Corporation Nuvoton Cryptographic Library 2.0 Hardware Version 2.1.4 Document Version 1.2 Last update: 2025-04-21 Prepared by: atsec information security corporation

4516 Seton Center Parkway, Suite 250

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

© 2025 Nuvoton Technology Corporation / atsec information security.

3 of 38

This document is the non-proprietary FIPS 140-3 Security Policy for Hardware version 2.1.4 of the Nuvoton Cryptographic Library 2.0. It has a one-to-one mapping to the [SP 800-140Br1] 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: Table 1: Security Levels © 2025 Nuvoton Technology Corporation / atsec information security.

5 of 38

Purpose and Use: The Nuvoton Cryptographic Library 2.0 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. Module Type: Hardware Module Embodiment: SingleChip Cryptographic Boundary: The block diagram below shows the cryptographic boundary of the module, and its interfaces with the operational environment. The cryptographic boundary encompasses the entire physical chip. Figure 1: Block Diagram Tested Operational Environment’s Physical Perimeter (TOEPP): The red outline in Figure 1 above indicates the Tested Operational Environment’s Physical Perimeter (TOEPP). © 2025 Nuvoton Technology Corporation / atsec information security.

6 of 38

Figure 2 shows a picture of the NPCX998HB0BX (e.g., EC) in which the sub-chip module is embedded.

Tested Module Identification

• Hardware: Table 2: Tested Module Identification
• Hardware

There are no components within the cryptographic boundary excluded from the FIPS 140-3 requirements.

Modes List and Description: The module supports approved services in the approved mode of operation. There are no non-approved services supported by the module. Table 3: Modes List and Description The table below lists all security functions of the module, including specific key strengths employed for approved services, and implemented modes of operation. © 2025 Nuvoton Technology Corporation / atsec information security.

7 of 38

© 2025 Nuvoton Technology Corporation / atsec information security.

8 of 38

Table 4: Approved Algorithms Vendor-Affirmed Algorithms Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: N/A for this module. © 2025 Nuvoton Technology Corporation / atsec information security.

9 of 38

© 2025 Nuvoton Technology Corporation / atsec information security.

10 of 38

© 2025 Nuvoton Technology Corporation / atsec information security.

11 of 38

Table 6: Security Function Implementations

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. Steps to comply with the SP800-56Brev2 assurances can be found in section 11.3 Non-Administrator Guidance. Compliance to FIPS 186-5 is met using FIPS 186-4 CAVP certs as allowed by additional comment 2 of IG C.K.

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 the physical entropy source which provides 256-bits of entropy to seed and reseed the DRBG during initialization and reseeding. The estimated amount of entropy per entropy output bit is ~0.6/bit. 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. Table 7: Entropy Certificates Table 8: Entropy Sources © 2025 Nuvoton Technology Corporation / atsec information security.

12 of 38

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-133rev2] (vendor affirmed), compliant with [FIPS186-4] and using DRBG compliant with [SP800-90Arev1]. 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 KAS-ECC-SSC EC Diffie-Hellman Shared Secret Computation compliant to [SP80056Arev3] and IG D.F Scenario (2) path (1). o The shared secret computation provides between 128 and 256 bits of encryption strength.
2. Within the TOEPP, the module offers RSA key wrapping and unwrapping using KTS-OAEP-basic 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.3 Non-Administrator Guidance. The SSP establishment methodology provides 112 or 128 bits of encryption strength.

N/A for this module. © 2025 Nuvoton Technology Corporation / atsec information security.

13 of 38

Table 9: Ports and Interfaces

The module does not transmit unprotected SSPs over any of its interfaces. All authentication data is transmitted between the module and the other endpoints in protected manner on both the contact and contactless interfaces.

The control interface is inhibited while in the error state without any exceptions. © 2025 Nuvoton Technology Corporation / atsec information security.

14 of 38

FIPS 140-3 does not require authentication mechanism for level 1 modules. Therefore, the module does not implement an authentication mechanism. N/A for this module.

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. Table 10: Roles When a device is delivered, the Crypto Officer is responsible for initializing the module i.e., configure the device by properly setting up key registers for storage of keys/CSPs. The Crypto Officer is implicitly assumed. The User can perform services from Table 5 and 5a only after the Crypto Officer takes possession by initializing it, thus creating data to be protected is generated. The Users of the module are software applications that implicitly assume the User Role when requesting any cryptographic services provided by the module.

The module only implements Approved security functions in an Approved mode. The 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 in the Approved Mode of Operation (neither with nor without security claim). The module does not implement any non-approved security functions. 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. © 2025 Nuvoton Technology Corporation / atsec information security.

15 of 38

© 2025 Nuvoton Technology Corporation / atsec information security.

16 of 38

W,E G,R © 2025 Nuvoton Technology Corporation / atsec information security.

17 of 38

(i.e., G © 2025 Nuvoton Technology Corporation / atsec information security.

18 of 38

Z (i.e., Z © 2025 Nuvoton Technology Corporation / atsec information security.

19 of 38

Name

Description

Indicator

Inputs

Outputs

Security Functions

SSP Access internal state (i.e., Hash_DRB G V and C values), Seed: E

N/A for this module. © 2025 Nuvoton Technology Corporation / atsec information security.

20 of 38

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.

The module does not implement any software/firmware integrity test. The requirements of this area are not applicable to the module. © 2025 Nuvoton Technology Corporation / atsec information security.

21 of 38

The Nuvoton Cryptographic Library 2.0 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. Type of Operational Environment: Non-Modifiable © 2025 Nuvoton Technology Corporation / atsec information security.

22 of 38

The Nuvoton Cryptographic Library 2.0 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. Table 12: Mechanisms and Actions Required © 2025 Nuvoton Technology Corporation / atsec information security.

23 of 38

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. © 2025 Nuvoton Technology Corporation / atsec information security.

24 of 38

The module does not provide persistent storage for keys/SSPs. Keys/SSPs are stored in memory only and are received for use by the module only at the request of the User firmware. Table 13: Storage Areas 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. Table 14: SSP Input-Output Methods Keys and SSPs are explicitly zeroized automatically when structure associated with the cipher is deallocated or implicitly when the device is powered down thereby rendering the data irretrievable. Interface with the module is inhibited while zeroization is being performed. For Keys and SSPs explicitly zeroized automatically the successful completion of a requested service suffices as the implicit indicator that zeroisation has completed. Table 15: SSP Zeroization Methods © 2025 Nuvoton Technology Corporation / atsec information security.

25 of 38

The following 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. © 2025 Nuvoton Technology Corporation / atsec information security.

26 of 38

Table 16: SSP Table 1 © 2025 Nuvoton Technology Corporation / atsec information security.

27 of 38

Table 17: SSP Table 2 © 2025 Nuvoton Technology Corporation / atsec information security.

28 of 38

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 not available, and input and output are inhibited. The module will boot only after successfully passing the HMAC-SHA2-512 and SHA2-256 CASTs. If an error is detected in any self-test, the module will enter the Error State. N/A for this module. The module is solely implemented in hardware (i.e., only contains executable code that is stored in non- reconfigurable masked ROM1). As such, the module does not perform any pre-operational software/firmware integrity test, but instead The module does not implement a pre-operational bypass test nor pre-operational critical functions test.

algorithm. The table below describe the conditional tests supported by the module.

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

manufacturing. © 2025 Nuvoton Technology Corporation / atsec information security.

29 of 38

Table 18: Conditional Self-Tests The module does not implement a Software/Firmware Load Test, Manual Entry Test, Conditional Bypass Test nor Conditional Critical Functions Test. © 2025 Nuvoton Technology Corporation / atsec information security.

30 of 38

During runtime, operators can initiate the conditional self-tests on demand by calling NCL_MISC_SelfTest and passing The module’s entropy source is powered on only momentarily to seed the module’s SP800-90B DRBG. The module performs ENT health tests defined in Section 4 of SP800-90B on the generated output prior to seeding the SP800-90B DRBG. After completing its execution, the entropy source powers down. N/A for this module. © 2025 Nuvoton Technology Corporation / atsec information security.

31 of 38

Table 19: Conditional Periodic Information

For any of the conditional self-tests, the module enters an error state upon failing the self-test. A failure in the conditional “ENTROPY_SRC_ERROR” status returned to the user. When in the error state, no cryptographic services are provided, successfully pass the conditional self-tests. © 2025 Nuvoton Technology Corporation / atsec information security.

32 of 38

Table 20: Error States © 2025 Nuvoton Technology Corporation / atsec information security.

33 of 38

As explained in Section 10.1 Pre-Operational Self-Tests, the module is placed in a masked ROM by manufacturer during the silicon manufacturing. The module is delivered as part of the Nuvoton NPCX998HB0BX 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. 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 HMAC-SHA2-512 and SHA2-256 CAST, it is operating correctly and can begin servicing User requests.

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-5 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 800-56BRev2. 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. The entity using the module, shall confirm the peer's possession of private key by using any method specified in section

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 and HMAC 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 © 2025 Nuvoton Technology Corporation / atsec information security.

34 of 38

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

35 of 38

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 ENT               Entropy Source 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 © 2025 Nuvoton Technology Corporation / atsec information security.

36 of 38