Nuvoton Cryptographic Library 3.0

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Nuvoton Cryptographic Library 3.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 3.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 3.0 Document Version 1.2 Last update: 2025-11-19 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 47

This document is the non-proprietary FIPS 140-3 Security Policy for Hardware version 3.0.7 / 3.0.8 of the Nuvoton Cryptographic Library 3.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 47

Purpose and Use: The Nuvoton Cryptographic Library 3.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 Module Characteristics: SubChip Cryptographic Boundary: The block diagram below shows the cryptographic boundary of the module (shown by the blue dotted outline), and its interfaces with the operational environment. 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 47

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 47

© 2025 Nuvoton Technology Corporation / atsec information security.

8 of 47

© 2025 Nuvoton Technology Corporation / atsec information security.

9 of 47

© 2025 Nuvoton Technology Corporation / atsec information security.

10 of 47

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

11 of 47

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.

12 of 47

() © 2025 Nuvoton Technology Corporation / atsec information security.

13 of 47

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

14 of 47

The module does not establish SSPs using an approved key transport scheme (KTS). However, it does offer approved authenticated algorithms that can be used by an external operator/application as part of an approved KTS. 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 module makes use of the GetEntropy() interface of the entropy source to make two independent calls that output 512-bit each of full entropy from the SP 800-90B entropy source then concatenating them together to form 1024-bits of entropy input for the DRBG. The Hash_DRBG can generate random numbers with up to 256-bits of security strength. 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

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-5] 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 example 1 of [SP800-133rev2], where V is a string of binary zeroes, meaning B = U (i.e., the output of an approved RBG). 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 key derivation service using SP800-108 KBKDF.

The module implements KAS-ECC-SSC EC Diffie-Hellman Shared Secret Computation compliant to [SP800-56Arev3] and IG D.F Scenario (2) path (1). • The shared secret computation provides between 128 and 256 bits of encryption strength. © 2025 Nuvoton Technology Corporation / atsec information security.

15 of 47

Table 9: Ports and Interfaces © 2025 Nuvoton Technology Corporation / atsec information security.

16 of 47

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 11 only after the Crypto Officer takes possession by initializing the module, 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.

17 of 47

© 2025 Nuvoton Technology Corporation / atsec information security.

18 of 47

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

19 of 47

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

20 of 47

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

21 of 47

W,E Table 11: Approved Services © 2025 Nuvoton Technology Corporation / atsec information security.

22 of 47

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

23 of 47

The Nuvoton Cryptographic Library 3.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: Limited © 2025 Nuvoton Technology Corporation / atsec information security.

24 of 47

The Nuvoton Cryptographic Library 3.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.

25 of 47

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.

26 of 47

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 into or output from the module from outside of 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. Entropy input remains within the module's sub-chip boundary. Table 14: SSP Input-Output Methods Keys and SSPs are explicitly zeroized automatically prior to the structure associated with the cipher being deallocated or implicitly when the device is powered down thereby rendering the data irretrievable. Input and output interfaces are 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. Keys and SSPs may be zeroized explicitly by calling the respective NCL_<alg>_Clear API listed in the table below which immediately zeroizes all sensitive data. © 2025 Nuvoton Technology Corporation / atsec information security.

27 of 47

Table 15: SSP Zeroization Methods

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.

28 of 47

© 2025 Nuvoton Technology Corporation / atsec information security.

29 of 47

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

30 of 47

© 2025 Nuvoton Technology Corporation / atsec information security.

31 of 47

© 2025 Nuvoton Technology Corporation / atsec information security.

32 of 47

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

33 of 47

The module is solely implemented in hardware (i.e., only contains executable code that is stored in non- reconfigurable memory). As such, the module does not perform any pre-operational software/firmware integrity test, but instead performs Self-tests ensure that the module is not corrupted and that the cryptographic algorithms work as expected. While the module is executing the above self-tests, no services are available and input and output are inhibited. The module will boot only after successfully passing the SHA2-256, HMAC- SHA2-512 and KBKDF-HMAC-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 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. © 2025 Nuvoton Technology Corporation / atsec information security.

34 of 47

© 2025 Nuvoton Technology Corporation / atsec information security.

35 of 47

© 2025 Nuvoton Technology Corporation / atsec information security.

36 of 47

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.

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 entropy source 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.

37 of 47

© 2025 Nuvoton Technology Corporation / atsec information security.

38 of 47

© 2025 Nuvoton Technology Corporation / atsec information security.

39 of 47

© 2025 Nuvoton Technology Corporation / atsec information security.

40 of 47

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 Table 20: Error States © 2025 Nuvoton Technology Corporation / atsec information security.

41 of 47

The module is delivered as part of the Nuvoton NPCX499HA0BX (EC), Nuvoton NPCD324HA0DX (SIO) and Nuvoton NPCX499HA1BX (EC) platforms (listed in Table 2). During manufacturing

• each chip is tested to ensure the module was manufactured correctly. 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.

The module does not establish any SSPs for itself. Instead, the module provides this functionality as a service for other components within the TOEPP. The entity using the IUT must obtain required assurances listed in section 6.4 of SP 80056BRev2 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.
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. To comply with the assurances found in Section 5.6.2 of SP 800-56Ar3, the operator must use module’s approved key pair generation service to generate ephemeral EC Diffie-Hellman key pair, or the key pair must be obtained from another FIPS-validated module. As part of this service, the module will internally perform the full public key validation of the generated public key. The module’s shared secret computation service will internally perform the full public key validation of the peer public key, complying with Sections 5.6.2.2.1 and 5.6.2.2.2 of SP 800-56Ar3.

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, 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
• NCL_HSS_Clear - For each of existing HSS contexts © 2025 Nuvoton Technology Corporation / atsec information security.

42 of 47

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

43 of 47

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 EOL               End Of Life FIPS              Federal Information Processing Standards Publication GCM               Galois Counter Mode HMAC              Hash Message Authentication Code HSS               Hierarchical Signature System KAS               Key Agreement Scheme KAT               Known Answer Test LMS               Leighton-Micali Signature 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.

44 of 47

SP800-140Br1 NIST Special Publication 800-140Br1 - CMVP Security Policy Requirements November 2023 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Br1.pdf © 2025 Nuvoton Technology Corporation / atsec information security.

47 of 47