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

9130 Jollyville Road, Suite 260

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

© 2024 Nuvoton Technology Corporation / atsec information security.

2 of 31

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: Table 1 - Security Levels © 2024 Nuvoton Technology Corporation / atsec information security.

3 of 31

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: 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

The Table 3 below lists all security functions of the module, including specific key strengths employed for approved services, and implemented modes of operation. © 2024 Nuvoton Technology Corporation / atsec information security.

4 of 31

CAVP Cert

Algorithm and Standard AES [SP 800-38 D] HMAC [FIPS 198-1] RSA [FIPS 186-4] KBKDF [SP800-108] KTS-IFC [SP800-56Brev2] ECDSA [FIPS 186-4] SHS [FIPS 180-4] KAS-ECC-SSC [SP800-56Arev3]

Mode / Method GMAC HMAC-SHA2-256 HMAC-SHA2-384 HMAC-SHA2-512 RSA-PSS using SHA2-256, SHA2-384 or SHA2-512 RSA-PKCS#1 v1.5 using SHA2-256, SHA2-384 or SHA2-512 KDF Modes: Counter, Feedback, Double pipeline iteration MAC Modes: HMAC-SHA2- 256, HMAC-SHA2-384, HMAC-SHA2-512 KTS-OAEP-basic B.4.2 Testing Candidates NA SHA2-256, SHA2-384, SHA2-512 N/A SHA2-256 SHA2-384 SHA2-512 ephemeralUnified

Description / Key / Curve / Modulus Size(s) 128, 192, 256 bits 256, 384, 512 bits 2048 or 3072 modulus 256, 384, 512 bits 2048 or 3072 modulus P-256, P-384, P-521 curves P-256, P-384, P-521 curves P-256, P-384, P-521 curves P-256, P-384, P-521 curves N/A P-256, P-384, P-521 curves

Use / Function GMAC Message Authentication Code Generation and GMAC Message Authentication Code Verification HMAC Message Authentication Code Generation RSA Signature Generation, RSA Signature Verification Key Derivation Function RSA Key Transport (key wrapping and un-wrapping) ECDSA Key Generation ECDSA Key Verification ECDSA Signature Generation, ECDSA Signature Verification ECDSA Signature Generation Component Message Digest Generation EC Diffie-Hellman Shared Secret Computation (complete)

© 2024 Nuvoton Technology Corporation / atsec information security.

5 of 31

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.

6 of 31

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.

7 of 31

Table 4 - Ports and Interfaces © 2024 Nuvoton Technology Corporation / atsec information security.

8 of 31

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

9 of 31

© 2024 Nuvoton Technology Corporation / atsec information security.

10 of 31

© 2024 Nuvoton Technology Corporation / atsec information security.

11 of 31

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.

12 of 31

Service

Description

Inputs

Outputs

Approved Security Functions KAS-ECC-SSC Hash_DRBG

Keys and/or SSPs ECDH Key Pair, Shared Secret Seed

Roles

Access rights to Keys and/or SSPs

Indicator

Table 5 - Approved Services © 2024 Nuvoton Technology Corporation / atsec information security.

13 of 31

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.

14 of 31

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.

15 of 31

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.

16 of 31

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.

17 of 31

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.

3 TOEPP - Tested Operational Environment’s Physical Perimeter

© 2024 Nuvoton Technology Corporation / atsec information security.

18 of 31

© 2024 Nuvoton Technology Corporation / atsec information security.

19 of 31

© 2024 Nuvoton Technology Corporation / atsec information security.

20 of 31

Table 6 - SSPs The module employs a Hash_DRBG using a SHA-512 PRF. Per section 10.1.1.1 of [SP800-90A], the seeded with 1024-bits of entropy input thereby providing 256-bits of entropy during initialization values used by approved security functions, SSP generation, or SSP establishment method are 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.

21 of 31

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.

22 of 31

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.

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.

23 of 31

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

24 of 31

Table 9 - Error States © 2024 Nuvoton Technology Corporation / atsec information security.

25 of 31

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.

26 of 31

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.

27 of 31

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

28 of 31

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.

29 of 31