GnuTLS cryptography module for AlmaLinux 9

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for GnuTLS 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/>Show Status</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 GnuTLS 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/>Show Status</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 GnuTLS cryptography module for AlmaLinux 9 Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

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

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

This document is the non-proprietary FIPS 140-3 Security Policy for version 3.7.6-396796fe0a32b434 of GnuTLS cryptography module for AlmaLinux 9. 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. 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

Table 1: Security Levels © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

This Security Policy describes the features and design of the module named GnuTLS cryptography module for AlmaLinux 9 using the terminology contained in the FIPS 140-3 specification. The FIPS 140-3 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 to their authors. In preparing the Security Policy document, the laboratory formatted the vendor-supplied documentation for consolidation without altering the technical statements therein contained. 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 then 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 GnuTLS cryptography module for AlmaLinux 9 (hereafter referred to as “the module”) is a software library. The module is an open-source, general-purpose set of libraries designed to support cross-platform development of security-enabled client and server applications. The module is a multiple-chip standalone cryptographic module. Module Type: Software Module Embodiment: MultiChipStand Module Characteristics [O]: Cryptographic Boundary: The block diagram in Figure 1 shows the cryptographic boundary of the module, its interfaces with the operational environment and the flow of information between the module and operator (depicted through the arrows). The module is implemented as a shared library. The cryptographic module boundary consists of the following components:

• libgnutls
• libnettle
• libhogweed
• libgmp
• statically linked
• gnutls hmac file Tested Operational Environment’s Physical Perimeter (TOEPP): The software block diagram below shows the module, its interfaces with the operational environment and the delimitation of its cryptographic boundary. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

The TOEPP is the general-purpose computer on which the module is installed. 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) © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Tested Module Identification – Hybrid Disjoint Hardware: N/A for this module. 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.

The module does not claim any excluded components.

Modes List and Description: Table 4: Modes List and Description © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

When the module starts up successfully, after passing all the pre-operational and conditional cryptographic algorithms self-tests (CASTs), the module is operating in the approved mode of operation by default and can only be transitioned into the non-Approved mode by calling one of the non-Approved services listed in Table 15. Please see section 4 for the details on service indicator provided by the module that identifies when an approved service is called. Degraded Mode Description: The module does not implement a degraded mode of operation.

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

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

2.0 © 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 The above table lists all approved cryptographic algorithms of the module, including specific key lengths employed for approved services, and implemented modes or methods of operation of the algorithms. Vendor-Affirmed Algorithms: Table 6: Vendor-Affirmed Algorithms © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Non-Approved, Allowed Algorithms: N/A for this module. 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: N/A for this module. The module does not implement any non-approved, allowed algorithm in the approved mode of operation with no security claimed. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

The above table lists non-Approved security functions that are not allowed in the approved mode of operation. © 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 8: Security Function Implementations

AES XTS The AES algorithm in XTS mode can be only used for the cryptographic protection of data on storage devices, as specified in [SP800-38E]. The length of a single data unit encrypted with the XTS-AES shall not exceed 220 AES blocks, that is 16MB of data. To meet the requirement stated in IG C.I, the module implements a check that ensures, before performing any cryptographic operation, that the two AES keys used in AES XTS mode are not identical. Note: AES-XTS shall be used with 128 and 256-bit keys only. AES-XTS with 192-bit keys is not an Approved service. AES-GCM IV The Crypto Officer shall consider the following requirements and restrictions when using the module. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

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. The module 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’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. 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 AESGCM), or terminate the connection. Key Derivation using SP 800-132 PBKDF The module provides password-based key derivation (PBKDF), compliant with SP800-132. The module supports option 1a from section 5.4 of [SP800-132], in which the Master Key (MK) or a segment of it is used directly as the Data Protection Key (DPK). In accordance with [SP800-132], the following requirements shall be met.

• Derived keys shall only be used in storage applications. The Master Key (MK) shall not be used for other purposes. The length of the MK or DPK shall be of 112 bits or more (this is verified by the module to determine the service is approved).
• A portion of the salt, with a length of at least 128 bits (this is verified by the module to determine the service is approved), shall be generated randomly using the SP800-90Arev1 DRBG,
• 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 minimum value shall be 1000 (this is verified by the module to determine the service is approved).
• Passwords or passphrases, used as an input for the PBKDF, shall not be used as cryptographic keys.
• The minimum length of the password or passphrase accepted by the module is 14 characters. The probability of guessing the value, assuming a worst-case scenario of all digits, is estimated to be at most 10-14. The calling application shall also observe the rest of the requirements and recommendations specified in [SP800-132]. Compliance to SP 800-56ARev3 assurances © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

In order to meet the required assurances listed in section 5.6 of SP 800-56ARev3, the module shall be used together with an application that implements the "TLS protocol" and the following steps shall be performed.

1. The entity using the module, must use the module's "Key pair generation" service for generating DH/ECDH ephemeral keys. This meets the assurances required by key pair owner defined in the section 5.6.2.1 of SP 800-56ARev3.
2. As part of the module's shared secret computation (SSC) service, the module internally performs the public key validation on the peer's public key passed in as input to the SSC function. This meets the public key validity assurance required by the sections 5.6.2.2.1/5.6.2.2.2 of SP 800-56ARev3. The module does not support static keys therefore the "assurance of peer's possession of private key" is not applicable.

Table 9: Entropy Certificates Table 10: Entropy Sources The module employs a Deterministic Random Bit Generator (DRBG) based on [SP800-90ARev1] for the generation of random value used in asymmetric keys, and for providing a RNG service to calling applications. The approved DRBG provided by the module is the CTR_DRBG with AES-256. The DRBG does not employ prediction resistance or a derivation function. The module uses an SP800-90B-compliant Entropy Source specified in the table above to seed the DRBG. 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 entropy). © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys according to section 5.1 and 5.2 of [SP800-133rev2].

• For generating RSA and ECDSA keys, the module implements asymmetric cryptographic key generation (CKG) services compliant with [FIPS186-5].
• The public and private keys used in the EC Diffie-Hellman key agreement schemes are generated internally by the module using the ECDSA key generation method compliant with [FIPS186-5] and [SP800-56Arev3].
• The public and private keys used in the Diffie-Hellman key agreement scheme are also compliant with [SP800-56Arev3]. The module generates keys using safe primes defined in RFC7919 and RFC3526, as described in the next section. Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service.

The module provides Diffie-Hellman and EC Diffie-Hellman shared secret computation compliant with SP80056Arev3, in accordance with scenario 2 (1) of IG D.F and used as part of the TLS protocol key exchange in accordance with scenario 2 (2) of IG D.F; that is, the shared secret computation (KAS-FFC-SSC and KAS-ECCSSC) followed by key derivation using TLS KDF. For Diffie-Hellman, the module supports the use of safe primes from RFC7919 for domain parameters and key generation, which are used in the TLS key agreement implemented by the module.

• TLS (RFC7919) o ffdhe2048 (ID = 256) o ffdhe3072 (ID = 257) o ffdhe4096 (ID = 258) o ffdhe6144 (ID = 259) o ffdhe8192 (ID = 260) The module also supports the use of safe primes from RFC3526, which are part of the Modular Exponential (MODP) Diffie-Hellman groups that can be used for Internet Key Exchange (IKE). Note that the module only implements key generation and verification, and shared secret computation using safe primes, but no part of the IKE protocol.
• IKEv2 (RFC3526)
• MODP-2048 (ID=14)
• MODP-3072 (ID=15)
• MODP-4096 (ID=16) © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

• MODP-6144 (ID=17)
• MODP-8192 (ID=18) The module also provides the following key transport mechanisms:
• Key wrapping using AES-CCM, AES-GCM, and AES-CBC with HMAC, used in the context of the TLS protocol cipher suites with 128-bit or 256-bit keys. According to Table 2: Comparable strengths in [SP 800-57rev5], the key sizes of AES, Diffie-Hellman and EC Diffie-Hellman provides the following security strength in Approved mode of operation:
• AES key wrapping using AES-CCM, AES-GCM, and AES in CBC mode and HMAC, provides between

• Diffie-Hellman shared secret computation provides between 112 and 200 bits of security strength.
• EC Diffie-Hellman shared secret computation provides between 128 and 256 bits of security strength. The module supports the following key derivation methods according to [SP800-135rev1]:
• KDF for the TLS protocol, used as pseudo-random functions (PRF) for TLSv1.2, HKDF as part of TLSv1.3. The module also supports password-based key derivation (PBKDF). The implementation is compliant with option 1a of [SP800-132]. Keys derived from passwords or passphrases using this method can only be used in storage applications.

The module implements KDF for the TLS protocol TLSv1.0, TLSv1.1, TLSv1.2. No parts of the TLS 1.0/1.1/1.2, other than the key derivation functions mentioned above, have been tested by the CAVP and CMVP. The module implements HKDF for the TLS protocol TLSv1.3. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

The logical interfaces are the API through which the applications request services. The following table summarizes the logical interfaces: Table 11: Ports and Interfaces All data output via data output interface is inhibited when the module is performing pre-operational test conditional cryptographic algorithms self-tests or zeroization or when the module enters error state. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

FIPS 140-3 does not require an authentication mechanism for level 1 modules. Therefore, the module does not implement an authentication mechanism for Crypto Officer. The module supports the Crypto Officer role only. The Crypto Officer role is authorized to access all services provided by the module and this sole role is implicitly assumed by the operator of the module when performing a service. N/A for this module. The module does not support authentication.

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.

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

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

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

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

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

G,W,E W,E © 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.

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

Name

Description

Indicator

Inputs

Outputs

Security Functions

SSP Access private key: Z - ECDSA public key: Z - Module- generated EC Diffie- Hellman Private Key: Z - Module- generated EC Diffie- Hellman Public Key: Z - EC Diffie- Hellman private key: Z - EC Diffie- Hellman public key: Z - Module- generated Diffie- Hellman Private Key: Z - Module- generated Diffie- Hellman Public Key: Z - Diffie- Hellman private key: Z - Diffie-

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

Name

Description

Indicator

Inputs

Outputs

Security Functions

SSP Access Hellman public key: Z - Diffie- Hellman shared secret: Z - EC Diffie- Hellman shared secret: Z - Entropy Input: Z - DRBG seed: Z - DRBG internal state (V value, key): Z - TLS Pre- master Secret: Z - HKDF Derived Key: Z - TLS Master Secret: Z - TLS Derived Secret: Z

Z Z Table 13: Approved Services The above table lists all approved services that can be used in the approved mode of operation. For the above table, 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. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

• Zeroize (Z): The module zeroizes the SSP.
• N/A: The module does not access any SSP or key during its operation. The service indicator is invoked by calling the function "gnutls_fips140_get_operation_state()" and it returns "GNUTLS_FIPS140_OP_APPROVED" or "GNUTLS_FIPS140_OP_NOT_APPROVED" depending on whether the API invoked corresponds to an approved or non-approved algorithm.

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

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

The above table lists all non-approved services that can only be used in the non-approved mode of operation.

The module does not have the capability of loading software or firmware from an external source. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

The integrity of the module is verified by comparing an HMAC-SHA2-256 value calculated at run time with the HMAC value stored in the .hmac file that was computed at build time for each software component of the module listed in section

2. The .hmac file has HMAC value for libgnutls, libnettle and libhogweed listed in section
3. If the HMAC values do not match, the test fails, and the module enters the error state. Integrity tests are performed as part of the Pre-Operational Self-Tests.

The module provides the Self-Test service to perform self-tests on demand which includes the pre-operational test (i.e., integrity test) and the cryptographic algorithm self-tests (CASTs). The Self-Tests service can be called on demand by invoking the gnutls_fips140_run_self_tests() function which will perform integrity tests and the cryptographic algorithms self-tests. Additionally, the Self-Test service can be invoked by powering-off and reloading the module. During the execution of the on-demand self-tests, services are not available, and no data output is possible. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Type of Operational Environment: Modifiable How Requirements are Satisfied: The module operates in a modifiable operational environment per FIPS 140-3 level 1 specification: the module executes on a general-purpose operating system, which allows modification, loading, and execution of software that is not part of the validated module. The module shall be installed as stated in Section 11. The user should confirm that the module is installed correctly by running: 1. fips-mode-setup --check command to verify that the system is operating in Approved mode 2. check the output of the the gnutls_get_library_config() API, which should output GnuTLS cryptography module for AlmaLinux 9 3.7.6-396796fe0a32b434 If properly installed, the 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 (N/A). © 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 (N/A). © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 15: Storage Areas plaintext form. SSPs are provided to the module by the calling process and are destroyed when released by the appropriate zeroization function calls. Symmetric keys, public and private keys are provided to the module by the calling application via API input parameters and are destroyed by the module when invoking the appropriate API function calls.

Table 16: SSP Input-Output Methods parameters in plaintext form within the physical perimeter of the operational environment. This is allowed by [FIPS140-3_IG] IG 9.5.A, according to the “CM Software to/from App via TOEPP Path” entry on the Key Establishment Table. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Table 17: SSP Zeroization Methods © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

The memory occupied by SSPs is allocated by regular memory allocation operating system calls. The application that is acting as the CO is responsible for calling the appropriate zeroization functions provided in the module's API and listed in Table 20. Calling the gnutls_deinit() will zeroize the SSPs stored in the TLS protocol internal state and also invoke the corresponding API functions listed in Table 20 to zeroize SSPs. The zeroization functions overwrite the memory occupied by SSPs with “zeros” and deallocate the memory with the regular memory deallocation operating system call. The completion of a zeroization routine(s) will indicate that a zeroization procedure succeeded. All data output is inhibited during zeroization.

© 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 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.

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

Table 19: SSP Table 2 The tables above summarize the Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module.

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 The module performs the pre-operational self-test and CASTs automatically when the module is loaded into memory. Pre-operational self-test ensure that the module is not corrupted, and the CASTs ensure that the cryptographic algorithms work as expected. While the module is executing the self-tests, the module services are not available, and input and output are inhibited. The module is not available for use by the calling application until the pre-operational self-test and the CASTs are completed successfully. After the preany of the CASTs fail an error message is returned, and the module transitions to the 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.

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

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

Table 21: Conditional Self-Tests Conditional Cryptographic Algorithm Tests The module performs self-tests on approved cryptographic algorithms, using the tests shown in the table above. Data output through the data output interface is inhibited during the self-tests. All CASTs performed are in the form of the Known Answer Tests (KATs) and are run prior to performing the integrity test. The KAT includes comparison of the calculated output with the expected known answer, hard coded as part of the test vectors used in the test. If one of the conditional self-tests fail, the module transitions to the ‘Error’ state and a corresponding error indication is given. The entropy source performs its required self-tests; those are not listed here, as the entropy source is not part of the cryptographic boundary of the module. Conditional Pair-Wise Consistency Tests The module implements RSA, ECDSA, DH and ECDH key generation service and performs the respective pairwise consistency test (PCT) using sign and verify functions when the keys are generated. If any of the tests fails, the module returns an error code and enters the Error state. When the module is in the Error state, no data is output, and cryptographic operations are not allowed. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

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.

Table 23: Conditional Periodic Information This information can be found in Section 5.2.

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

Name

Description

Conditions key pair fails the PCT When the module is in error state and caller requests cryptographic operations

Recovery Method

Indicator

Table 24: Error States When the module fails any pre-operational self-test or conditional test, the module will return an error code to indicate the error and enters error state. Any further cryptographic operations and the data output via the data output interface are inhibited. The calling application can obtain the module state by calling the gnutls_fips140_get_operation_state() API function. The function returns GNUTLS_FIPS140_OP_ERROR if the Self-test errors transition the module into an error state that keeps the module operational but prevents any cryptographic related operations. The module must be restarted and perform the pre-operational self-test and the CASTs to recover from these errors. If failures persist, the module must be re-installed.

The module provides the Self-Test service to perform self-tests on demand which includes the pre-operational test (i.e., integrity test) and the cryptographic algorithm self-tests (CASTs). The Self-Tests service can be called on demand by invoking the gnutls_fips140_run_self_tests() function which will perform integrity tests and the cryptographic algorithms self-tests. Additionally, the Self-Test service can be invoked by powering-off and reloading the module. During the execution of the on-demand self-tests, services are not available, and no data output is possible. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

The module is distributed as a part of the GnuTLS cryptography module for AlmaLinux 9 package in the form of the gnutls-3.7.6-23.el9_2.tuxcare.3.x86_64 RPM package for x86 systems. The binaries of the ‘GnuTLS cryptography module for AlmaLinux 9 version 3.7.6-396796fe0a32b434’ are contained in the RPM packages for delivery listed below, which contain the FIPS validated module:

• gnutls-3.7.6-23.el9_2.tuxcare.3.x86_64.rpm
• nettle-3.8-3.el9_2.tuxcare.1.x86_64.rpm Before the ‘GnuTLS cryptography module for AlmaLinux 9’ RPM packages are installed, the system must operate in Approved mode. This can be achieved by:
• Starting the installation in Approved mode. Add 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. More information can be found at the vendor documentation.
• Switching the system into Approved mode after the installation. Execute the fips-mode-setup --enable command. Restart the system. More information can be found at the vendor documentation. In both cases, the Crypto Officer must verify the system operates in Approved mode by executing the fipsmode-setup --check command, which should output “FIPS mode is enabled.”

All the functions, ports and logical interfaces described in this document are available to the Crypto Officer.

The module implements only the Crypto Officer. There are no requirements for non-administrator guidance.

For secure sanitization of the cryptographic module, the module needs first to be powered off, which will zeroize all keys and CSPs in volatile memory. Then, for actual deprecation, the module shall be upgraded to a newer version that is FIPS 140-3 validated. The module does not possess persistent storage of SSPs, so further sanitization steps are not required. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

RSA is vulnerable to timing attacks. In a setup where attackers can measure the time of RSA decryption or signature operations, blinding is always used to protect the RSA operation from that attack. The internal API function of rsa_blind() and rsa_unblind() are called by the module for RSA signature generation and RSA decryption operations. The module generates a random blinding factor and include this random value in the RSA operations to prevent RSA timing attacks. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

Appendix A. TLS Cipher Suites The module supports the following cipher suites for the TLS protocol version 1.0, 1.1, 1.2 and 1.3, compliant with section 3.3.1 of [SP800-52rev2]. Each cipher suite defines the key exchange algorithm, the bulk encryption algorithm (including the symmetric key size) and the MAC algorithm. © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

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

Appendix B. Glossary and Abbreviations

Appendix C. 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-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 © 2025 Cloudlinux Inc., TuxCare division/atsec information security.

SP800-56Crev2 NIST Special Publication 800-56C

• Revision 2 - Recommendation for Key-Derivation Methods in Key-Establishment Schemes 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-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 ApplicationSpecific 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.