NSS cryptography module for AlmaLinux 9

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for NSS cryptography module for AlmaLinux 9
  %% 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/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>IKEV<br/>HTTPS</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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 NSS cryptography module for AlmaLinux 9
  %% 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/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>IKEV<br/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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

Cloudlinux Inc., TuxCare division NSS cryptography module for AlmaLinux 9 Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 Document version: 1.1 www.atsec.com Last update: 2025-06-23

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

This document is the non-proprietary FIPS 140-3 Security Policy for version 3.90.0-b84457b0165f79bf of the NSS cryptography module for AlmaLinux 9. It 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 an overall Security Level 1 module. including this notice. Other documentation is proprietary to their authors.

This security police describes the features and design of the module named NSS cryptography module for AlmaLinux 9 using the terminology contained in the FIPS 140-3 specification. The FIPS 140-3 Security © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Requirements for Cryptographic Module specifies the security requirements that will be satisfied by a cryptographic module utilized within a security system protecting sensitive but unclassified information. The NIST/CCCS Cryptographic Module Validation Program (CMVP) validates cryptographic module to FIPS 140-3. Validated products are accepted by the Federal agencies of both the USA and Canada for the protection of sensitive or designated information. including this notice. Other documentation is proprietary of their authors. The further refining of the Security Policy document was conducted iteratively throughout the conformance testing, wherein the Security Policy was submitted to the vendor, who would edit, modify, and add technical contents. The vendor would also supply additional documentation, which the laboratory formatted into the existing Security Policy, and resubmitted to the vendor for their final editing. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Purpose and Use: The NSS cryptography module for AlmaLinux 9 (hereafter referred to as “the module”) is defined as a software module in a multi-chip standalone embodiment. It provides a C language application program interface (API) designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSLv3, TLS, IKEv2, PKCS#5, PKCS#7, PKCS#11, PKCS#12, S/MIME, X.509 v3 certificates, and other security standards supporting FIPS 140-3 validated cryptographic algorithms. It combines a vertical stack of Linux components intended to limit the external interface each separate component may provide. Module Type: Software Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: The cryptographic boundary consists only of the Softoken and Freebl libraries along with their associated integrity check values as listed in Section 2.2. If any other NSS API outside of these two libraries is invoked, the user is not interacting with the module specified in this Security Policy. Tested Operational Environment’s Physical Perimeter (TOEPP): The TOEPP of the module is defined as the general-purpose computer on which the module is installed. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Tested Module Identification

• Hardware: N/A for this module. Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Tested Operational Environments - Software, Firmware, Hybrid: Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module. CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

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

Modes List and Description: Table 4: Modes List and Description After passing all pre-operational self-tests and cryptographic algorithm self-tests executed on start-up, the module automatically transitions to the approved mode. No operator intervention is required to reach this point. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Mode Change Instructions and Status: The module automatically switches between the approved and non-approved modes depending on the services requested by the operator. The status indicator of the mode of operation is equivalent to the indicator of the service that was requested.

Approved Algorithms: © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 5: Approved Algorithms © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

The table above lists all approved cryptographic algorithms of the module, including specific key lengths employed for approved services in Section 4.3, and implemented modes or methods of operation of the algorithms. Vendor-Affirmed Algorithms: Table 6: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: The module does not implement non-approved algorithms that are allowed in the approved mode of operation. Non-Approved, Allowed Algorithms with No Security Claimed: The module does not implement non-approved algorithms that are allowed in the approved mode of operation with no security claimed. Non-Approved, Not Allowed Algorithms: © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 7: Non-Approved, Not Allowed Algorithms The table above lists all the non-approved cryptographic algorithms of the module employed by the nonapproved services in Section 4.4.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 8: Security Function Implementations © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

The Crypto Officer shall consider the following requirements and restrictions when using the module. For TLS 1.2, the module offers the AES GCM implementation and uses the context of Scenario 1 of FIPS 140-3 IG C.H. NSS is compliant with SP 800-52r2 Section 3.3.1 and the mechanism for IV generation is compliant with RFC 5288 and 8446. The module does not implement the TLS protocol. The module’s implementation of AES GCM is used together with an application that runs outside the module’s cryptographic boundary. The design of the TLS protocol implicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values for a given session key. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES GCM key encryption or decryption under this scenario shall be established. Alternatively, the Crypto Officer can use the module’s API to perform AES GCM encryption using internal IV generation that complies with Scenario 2 of the IG C.H. These IVs are always at least 96 bits and generated using the approved DRBG internal to the module’s boundary. Additionally, the module offers an internal deterministic IV generation mode compliant with Scenario 3 of FIPS 140-3 IG C.H. The size of the fixed (name) field used by this IV generation mode is at least 32 bits. The module then internally generates a 32 bit or longer deterministic non-repetitive counter. The module explicitly ensures that this counter is monotonically increasing at each invocation of the AES-GCM for the same encryption key, and that this counter does not exhaust all its possible values. The generated GCM IV is at least 96 bits in length. In case the module’s power is lost and then restored, a new key for use with the AES-GCM encryption/decryption shall be established. Finally, for TLS 1.3, the AES GCM implementation uses the context of Scenario 5 of FIPS 140-3 IG C.H. The protocol that provides this compliance is TLS 1.3, defined in RFC8446 of August 2018, using the cipher-suites that explicitly select AES GCM as the encryption/decryption cipher (Appendix B.4 of RFC8446). The module supports acceptable AES GCM cipher suites from Section 3.3.1 of SP800-52r2. TLS 1.3 employs separate 64-bit sequence numbers, one for protocol records that are received, and one for protocol records that are sent to a peer. These sequence numbers are set at zero at the beginning of a TLS 1.3 connection and each time when the AES-GCM key is changed. After reading or writing a record, the respective sequence number is incremented by one. The protocol specification determines that the sequence number should not wrap, and if this condition is observed, then the protocol implementation must either trigger a re-key of the session (i.e., a new key for AES-GCM), or terminate the connection.

The module provides password-based key derivation (PBKDF2), compliant with SP 800-132. The module supports option 1a from Section 5.4 of SP 800-132, in which the Master Key (MK) or a segment of it is used directly as the Data Protection Key (DPK). In accordance to SP 800-132 and FIPS 140-3 IG D.N, the following requirements shall be met: • Derived keys shall only be used in storage applications. The MK shall not be used for other purposes. The module enforces the length of the MK or DPK to be of 112 bits or more for the service to be approved. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

• Passwords or passphrases, used as an input for the PBKDF2, shall not be used as cryptographic keys.
• The minimum length of the password or passphrase accepted by the module is 8 characters. The probability of guessing the value is estimated to be at most 1/628 = 4 x 1015, when the password is a combination of lowercase, uppercase, and numeric characters. If the password solely consists of digits, the probability of guessing the value is estimated to be 10 -8. Combined with the minimum iteration count as described below, this provides an acceptable trade-off between user experience and security against brute-force attacks.
• A portion of the salt shall be generated randomly using the SP 800-90Ar1 DRBG provided by the module. The module restricts minimum length to 128 bits.
• The iteration count shall be selected as large as possible, as long as the time required to generate the key using the entered password is acceptable for the users. The module only allows minimum iteration count to be 1000.

To comply with the assurances found in Section 5.6.2 of SP 800-56Ar3, the operator must use the module together with an application that implements the TLS protocol. Additionally, the module’s approved Key Pair Generation service (see Section 4.3) must be used to generate ephemeral DiffieHellman or EC Diffie-Hellman key pairs, or the key pairs 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.

The module supports RSA Signature Verification for 1024, 1280, 1536 and 1792-bit keys. This is allowed by FIPS 140-3 IG C.F. Specifically, 1280 and 1792 cannot be ACVP tested but are approved for signature verification in IG C.F. The 1024-bit modulus has been CAVP tested for RSA signature verification in compliance with FIPS 1864, while the 1536-bit modulus has been CAVP tested for RSA signature verification in compliance with FIPS 186-2. For all other approved moduli (namely 2048, 3072, and 4096 bit keys) supported by the module, RSA signature verification is approved and CAVP tested in compliance with FIPS 186-5.

Table 9: Entropy Certificates © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 10: Entropy Sources The module employs a Deterministic Random Bit Generator (DRBG) implementation based on SP 80090Ar1. This DRBG is used internally by the module (e.g. to generate symmetric keys, seeds for asymmetric key pairs, and random numbers for security functions). It can also be accessed using the specified API functions. The DRBG implemented is a SHA-256 Hash_DRBG, seeded by the entropy source described in the table above. It does not employ prediction resistance. The DRBG is instantiated with a 384-bits long entropy input (corresponding to 384 bits of entropy). Additionally, the DRBG is reseeded with a 256-bits long entropy input (corresponding to 256 bits of

The module implements Cryptographic Key Generation (CKG, vendor affirmed), compliant with SP 800133r2. When random values are required, they are obtained from the SP 800-90Ar1 approved DRBG, compliant with Section 4 of SP 800-133r2. The following methods are implemented:

• Direct generation of symmetric keys: compliant with SP 800-133r2, Section 6.1.
• Safe primes key pair generation: compliant with SP 800-133r2, Section 5.2, which maps to SP 800-56Ar3. The method described in Section 5.6.1.1.4 of SP 800-56Ar3 (“Testing Candidates”) is used.
• RSA key pair generation: compliant with SP 800-133r2, Section 5.1, which maps to FIPS 186-5. The method described in Appendix A.1.3 of FIPS 186-5 (“Probable Primes”) is used.
• ECC (ECDH and ECDSA) key pair generation: compliant with SP 800-133r2, Section 5.1, which maps to FIPS 186-5. The method described in Appendix A.2.2 of FIPS 186-5 (“Rejection Sampling”) is used. Note that this generation method is also used to generate ECDH key pairs. Additionally, the module implements the following key derivation methods:
• KBKDF: compliant with SP 800-108r1. This implementation can be used to generate secret keys from a pre-existing key-derivation-key.
• HKDF: compliant with SP 800-56Cr2. This implementation shall only be used to generate secret keys in the context of an SP 800-56Ar3 key agreement scheme.
• TLS 1.2 KDF, IKEv2 PRF: compliant with SP 800-135r1. These implementations shall only be used to generate secret keys in the context of the TLS 1.2, and IKEv2 protocols, respectively.
• PBKDF2: compliant with option 1a of SP 800-132. This implementation shall only be used to derive keys for use in storage applications. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service.

The module provides Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) shared secret computation compliant with SP800-56Ar3, in accordance with scenario 2 (1) of FIPS 140-3 IG D.F. For Diffie-Hellman, the module supports the use of the safe primes defined in RFC 3526 (IKE) and RFC

7919 (TLS). Note that the module only implements domain parameter generation, key pair generation

and verification, and shared secret computation. No other part of the IKE or TLS protocols is implemented (with the exception of the TLS 1.2 KDF and IKEv2 PRF): IKE (RFC 3526):

• MODP-2048 (ID = 14)
• MODP-3072 (ID = 15)
• MODP-4096 (ID = 16)
• MODP-6144 (ID = 17)
• MODP-8192 (ID = 18) TLS (RFC 7919):
• ffdhe2048 (ID = 256)
• ffdhe3072 (ID = 257)
• ffdhe4096 (ID = 258)
• ffdhe6144 (ID = 259)
• ffdhe8192 (ID = 260) According to FIPS 140-3 IG D.B, the key sizes of DH and ECDH shared secret computation provide 112-

200 resp. 128-256 bits of security strength in an approved mode of operation.

The module also provides the following key transport mechanisms:

• Key wrapping using AES KW and AES KWP, with a security strength of 128, 192, or 256 bits, depending on the wrapping key size.
• Key wrapping using AES GCM with a security strength of 128, 192, or 256 bits.

For DH, the module supports the use of the safe primes defined in RFC 3526 (IKE) and RFC 7919 (TLS) as listed in Section 2.10. Note that the module only implements domain parameter generation, key pair generation and verification, and shared secret computation. No other part of the IKE or TLS protocols is implemented (with the exception of the TLS 1.2 KDF (RFC 7627) and IKEv2 KDF). TLS 1.2 KDF (RFC 7627) and IKEv2 implementations shall only be used to generate secret keys in the context of the TLS 1.2 and IKE protocols respectively. No other parts of the TLS and IKE protocols, other than the KDFs, have been tested by the CAVP or CMVP. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 11: Ports and Interfaces The logical interfaces are the APIs through which the applications request services. The module does not © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

N/A for this module. The module does not support authentication for roles.

Table 12: Roles The module supports the Crypto Officer role only. This sole role is implicitly and always assumed by the operator of the module. No support is provided for multiple concurrent operators or a maintenance role.

W,E W,E W,E t © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

W,E d) ) © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

C): G,W,E © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

, W,E , G,E,Z G G,E,Z © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

G,E,Z Z © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Z C): Z Z Table 13: Approved Services © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

The table above lists the approved services in this module, the algorithms involved, the Sensitive Security Parameters (SSPs) involved and how they are accessed, the roles that can request the service, and the respective service indicator. In this table, CO specifies the Crypto Officer role. The module provides services to operators that assume the available role. All services are described in detail in the API documentation (manual pages). The service tables define the services that utilize approved and non-approved security functions in this module. For the respective tables, the convention below applies when specifying the access permissions (types) that the service has for each SSP. • Generate (G): The module generates or derives the SSP. • Read (R): The SSP is read from the module (e.g. the SSP is output). • Write (W): The SSP is updated, imported, or written to the module. • Execute (E): The module uses the SSP in performing a cryptographic operation. • Zeroize (Z): The module zeroizes the SSP. • N/A: The module does not access any SSP or key during its operation. To interact with the module, a calling application must use the FIPS token APIs provided by Softoken. The FIPS token API layer can be used to retrieve the approved service indicator for the module. This indicator consists of four independent service indicators:

1. The session indicator, which must be used for all cryptographic services except the key (pair) generation and key derivation services. It can be accessed by invoking the NSC_NSSGetFIPSStatus function with the CKT_NSS_SESSION_LAST_CHECK parameter. If the output parameter is set to CKS_NSS_FIPS_OK (1), the service was approved.
2. The object indicator, which must be used for the key (pair) generation and key derivation services. It can be accessed by invoking the NSC_NSSGetFIPSStatus function with the CKT_NSS_OBJECT_CHECK parameter and the output derived key. If the output parameter is set to CKS_NSS_FIPS_OK (1), the service was approved.
3. The DRBG service indicator, which must be used for the DRBG service. It can be accessed by invoking the C_SeedRandom or C_GenerateRandom functions. If any of these functions returns CKR_OK, the service was approved. Any other service indicator value not listed above such as CKS_NSS_FIPS_NOT_OK (0) indicates that non-approved service is called. Also, for DRBG service, an error returned by the specified APIs indicates that the service was not approved.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 14: Non-Approved Services The table above lists the non-approved services in this module, the algorithms involved, and the roles that can request the service. In this table, CO specifies the Crypto Officer role.

The module does not load external software or firmware. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Each software component of the module has an associated HMAC-SHA2-256 integrity check value. The integrity of the module is verified by comparing the HMAC-SHA2-256 values calculated at run time with the integrity values embedded in the check files that were computed at build time. If the integrity test fails, the module enters the Power-On Error state.

Integrity tests are performed as part of the pre-operational self-tests, which are executed when the module is initialized. The integrity tests may be invoked on-demand by unloading and subsequently reinitializing the module, which will perform (among others) the software integrity tests. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Type of Operational Environment: Modifiable How Requirements are Satisfied: The module shall be installed as stated in Section 11.2. If properly installed, operating system provides process isolation and memory protection mechanisms that ensure appropriate separation for memory access among the processes on the system. Each process has control over its own data and uncontrolled access to the data of other processes is prevented. There are no concurrent operators.

Instrumentation tools like the ptrace system call, gdb and strace, userspace live patching, as well as other tracing mechanisms offered by the Linux environment such as ftrace or systemtap, shall not be used in the operational environment. The use of any of these tools implies that the cryptographic module is running in a non-validated operational environment. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

The module is comprised of software only and therefore this section is not applicable. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

This module does not implement any non-invasive security mechanism and therefore this section is not applicable. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 15: Storage Areas SSPs imported, generated, derived, or otherwise established by the module are stored in RAM while the module is operational. The operator application can use these SSPs to perform cryptographic operations, or export them as described in Section 9.2. The module maintains internal separation of the SSPs (including CSPs) in approved and non-approved modes of operation using an internal isFIPS flag for each SSP. This flag indicates whether the SSP can be used in approved or non-approved services.

Table 16: SSP Input-Output Methods CSPs (with the exception of passwords) can only be imported to and exported from the module when they are wrapped using an approved security function (e.g. AES KW or KWP). PSPs can be imported and exported in plaintext. Import and export is performed using API input and output parameters. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 17: SSP Zeroization Methods All data output is inhibited during zeroization. Memory is deallocated after zeroization. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

G G © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

G G © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 18: SSP Table 1 © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Name

Input - Output

Storage

Storage Duration

Zeroization

Related SSPs RSA Public Key:Generation Of

The SHA-1 algorithm as implemented by the module will be non-approved for all purposes, starting January 1, 2030. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 20: Pre-Operational Self-Tests Each software component of the module has an associated HMAC-SHA2-256 integrity check value. The software integrity tests ensure that the module is not corrupted. The HMAC-SHA2-256 algorithm goes through a CAST before the software integrity tests are performed. Upon initialization, the module immediately performs all Freebl cryptographic algorithm self-tests (CASTs) as specified in the Conditional Self-Tests table. When all those self-tests pass successfully, the module automatically performs the pre-operational integrity test on the libfreeblpriv3.so file using its associated check value. Then, the module performs the RSA CAST in the Softoken library, followed by the pre-operational integrity test on the libsoftokn3.so file using its associated check value. Finally, all remaining CASTs for the algorithms implemented in Softoken are executed (see the Conditional Self-Tests table). Only if all CASTs and pre-operational integrity tests passed successfully, the module transitions to the operational state. No operator intervention is required to reach this point. While the module is executing the self-tests, services are not available, and data output (via the data output interface) is inhibited until the tests are successfully completed. If any of the self-tests fails, an error message is returned, and the module transitions to an error state.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 21: Conditional Self-Tests The module performs self-tests on all FIPS approved cryptographic algorithms as part of the approved services supported in the approved mode of operation, using the tests shown in the Conditional SelfTests table above. Upon generation of a key pair, the module will perform a pair-wise consistency test (PCT) as shown in the table above, which provides some assurance that the generated key pair is well formed. For DH and EC key pairs, these tests consist of the PCT described in Section 5.6.2.1.4 of SP 800-56Ar3. For RSA and EC key pairs, this test consists of a signature generation and a signature verification operation. Note that two PCTs are performed for EC key pairs.

Table 22: Pre-Operational Periodic Information © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

© 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 23: Conditional Periodic Information

Table 24: Error States In any error state, the output interface is inhibited, and the module accepts no more inputs or requests.

The software integrity tests and CASTs can be invoked on demand by unloading and subsequently reinitializing the module. The PCTs can be invoked on demand by requesting the Key Pair Generation service. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Before the nss-softokn-3.90.0-6.el9_2.tuxcare.1 and nss-softokn-freebl-3.90.0-6.el9_2.tuxcare.1 RPM packages are installed, the AlmaLinux 9 system must operate in the approved mode. This can be achieved by:

• Adding the fips=1 option to the kernel command line during the system installation. During the software selection stage, do not install any third-party software.
• Switching the system into the approved mode after the installation. Execute the fips-mode-setup -enable command. Restart the system. In both cases, the Crypto Officer must verify the AlmaLinux 9 system operates in the approved mode by executing the fips-mode-setup --check command, which should output “FIPS mode is enabled.” After installation of the nss-softokn-3.90.0-6.el9_2.tuxcare.1 and nss-softokn-freebl-3.90.06.el9_2.tuxcare.1 RPM packages, the Crypto Officer must execute the “Show module name and version” service by accessing the CKA_NSS_VALIDATION_MODULE_ID attribute of the CKO_NSS_VALIDATION object in the default slot. The object attribute must contain the value: NSS cryptography module for AlmaLinux 9 3.90.0-b84457b0165f79bf Alternatively, the /usr/lib64/nss/unsupported-tools/validation tool is provided as a convenience by the nsstools-3.90.0-6.el9_2.tuxcare.1 RPM package. This tool performs the same steps, and also outputs the FIPS module identifier as above.

The version of the RPMs containing the FIPS validated Module is stated in section 11.1. The RPM packages forming the Module can be installed by standard tools recommended for the installation of RPM packages on an AlmaLinux system (for example, dnf and rpm). All RPM packages are signed with the TuxCare build key, which is an RSA 4096-bit key using SHA-256 signatures. The signature is automatically verified upon installation of the RPM package. If the signature cannot be validated, the RPM tool rejects the installation of the package. In such a case, the Crypto Officer is requested to obtain a new copy of the module's RPMs from TuxCare.

There is no non-administrator guidance.

As the module does not persistently store SSPs, secure sanitization of the module consists of unloading the module. This will zeroize all SSPs in volatile memory. Then, if desired, the nss-softokn-3.90.06.el9_2.tuxcare.1 and nss-softokn-freebl-3.90.0-6.el9_2.tuxcare.1 RPM packages can be uninstalled from the AlmaLinux 9 systems. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Timing attacks on RSA

• RSA blinding: timing attack on RSA was first demonstrated by Paul Kocher in 1996, who contributed the mitigation code to our module. Most recently Boneh and Brumley showed that RSA blinding is an effective defense against timing attacks on RSA.
• Specific Limit: None Cache-timing attacks on the modular exponentiation operation used in RSA
• Cache invariant module exponentiation: this is a variant of a modular exponentiation implementation that Colin Percival showed to defend against cache-timing attacks
• Specific Limit: this mechanism requires intimate knowledge of the cache line sizes of the processor. The mechanism may be ineffective when the module is running on a processor whose cache line sizes are unknown. Arithmetic errors in RSA signatures
• Double-checking RSA signatures: arithmetic errors in RSA signatures might leak the private key. Ferguson and Schneier recommend that every RSA signature generation should verify the signature just generated.
• Specific Limit: None © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Appendix A. Glossary and Abbreviations AES                     Advanced Encryption Standard CAVP                    Cryptographic Algorithm Validation Program CBC                     Cipher Block Chaining 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 FIPS                    Federal Information Processing Standards Publication GCM                     Galois Counter Mode HMAC                    Hash Message Authentication Code KAT                     Known Answer Test KW                      AES Key Wrap MAC                     Message Authentication Code NIST                    National Institute of Science and Technology PAA                     Processor Algorithm Acceleration PAI                     Processor Algorithm Implementation PR                      Prediction Resistance PSP                     Public Security Parameter PSS                     Probabilistic Signature Scheme RNG                     Random Number Generator RSA                     Rivest, Shamir, Adleman SHA                     Secure Hash Algorithm SSP                     Sensitive Security Parameter XTS                     XEX-based Tweaked-codebook mode with cipher text Stealing © 2025 Cloudlinux Inc., TuxCare division/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 January 2024 https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validationprogram/documents/fips%20140-3/FIPS%20140-3%20IG.pdf FIPS180-4 Secure Hash Standard (SHS) March 2012 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS186-2 Digital Signature Standard (DSS) January 2000 https://csrc.nist.gov/files/pubs/fips/186-2/final/docs/fips186-2.pdf FIPS186-4 Digital Signature Standard (DSS) July 2013 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf FIPS186-5 Digital Signature Standard (DSS) February 2023 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf FIPS197 Advanced Encryption Standard November 2001 https://csrc.nist.gov/publications/fips/fips197/fips-197.pdf FIPS198-1 The Keyed Hash Message Authentication Code (HMAC) July 2008 https://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf SP800-38A NIST Special Publication 800-38A - Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 https://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 https://csrc.nist.gov/publications/detail/sp/800-38b/final SP800-38D NIST Special Publication 800-38D - Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf SP800-38E NIST Special Publication 800-38E - Recommendation for Block Cipher Modes of Operation: The XTS AES Mode for Confidentiality on Storage Devices January 2010 https://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf SP800-38F NIST Special Publication 800-38F - Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping December 2012 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf SP800-52rev2 NIST Special Publication 800-52

• Revision 2 - Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations August 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf SP800-56Arev3 NIST Special Publication 800-56A
• Revision 3 - Recommendation for Pair-Wise KeyEstablishment Schemes Using Discrete Logarithm Cryptography April 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf SP800-56Crev2 NIST Special Publication 800-56C
• Revision 2 - Recommendation for Key-Derivation Methods in Key-Establishment Schemes © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

August 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf SP800-90Arev1 NIST Special Publication 800-90A

• Revision 1 - Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 https://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-108rev1 NIST Special Publication 800-108
• Revision 1 - Recommendation for Key Derivation Using Pseudorandom Functions August 2022 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1-upd1.pdf SP800-132 NIST Special Publication 800-132 - Recommendation for Password-Based Key Derivation - Part 1: Storage Applications December 2010 https://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf SP800-133rev2 NIST Special Publication 800-133
• Revision 2 - Recommendation for Cryptographic Key Generation June 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf SP800-135rev1 NIST Special Publication 800-135
• Revision 1
• Recommendation for Existing Application-Specific Key Derivation Functions December 2011 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-135r1.pdf SP800-140Br1 NIST Special Publication 800-140B
• Revision 1 - CMVP Security Policy Requirements November 2023 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Br1.pdf © 2025 Cloudlinux Inc., TuxCare division/atsec information security.