Red Hat Enterprise Linux 9 gnutls

Certificate

Approved Algorithms (78)

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

flowchart LR
  %% Deterministic review-risk graph for Red Hat Enterprise Linux 9 gnutls
  %% 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</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status Output<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 Red Hat Enterprise Linux 9 gnutls
  %% 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</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status Output<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

Red Hat Enterprise Linux 9 gnutls version 3.7.6-074d015ce201f434 document version 1.2 Last update: 2025-07-14 Prepared by: atsec information security corporation

4516 Seton Center Parkway, Suite 250

Austin, TX 78759 www.atsec.com © 2025 Red Hat, Inc./ atsec information security.

© 2025 Red Hat, Inc. / atsec information security.

3 of 46

This document is the non-proprietary FIPS 140-3 Security Policy for version 3.7.6-074d015ce201f434 of the Red Hat Enterprise Linux 9 gnutls cryptographic module. 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. 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.

Table 1 - Security Levels © 2025 Red Hat, Inc. / atsec information security.

4 of 46

Component

Description

The Red Hat Enterprise Linux 9 gnutls cryptographic module (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.

The module version is 3.7.6-074d015ce201f434 of the Red Hat Enterprise Linux 9 gnutls cryptographic module.

The module has been tested on the following platforms with the corresponding module variants and configuration options with and without PAA: Table 2 - Tested Operational Environments In addition to the configurations tested by the atsec CST laboratory, vendor-affirmed testing was performed on the following platforms for the module by F5, Inc. Table 3 - Vendor Affirmed Operation Environments Note: The 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. © 2025 Red Hat, Inc. / atsec information security.

5 of 46

Table 4 – Cryptographic Module Components 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 10. Please see section 4 for the details on service indicator provided by the module that identifies when an approved service is called.

The table below lists all security functions of the module, including specific key size(s) employed for approved or vendor-affirmed security functions, and implemented modes of operation. © 2025 Red Hat, Inc. / atsec information security.

6 of 46

© 2025 Red Hat, Inc. / atsec information security.

7 of 46

© 2025 Red Hat, Inc. / atsec information security.

8 of 46

Non-Approved Algorithms Allowed in the Approved Mode of Operation: The module does not implement any Non-Approved Algorithms Allowed in the Approved Mode of Operation. Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed: The module does not implement any non-Approved but Allowed algorithm in Approved mode of operation with no security claimed. Non-Approved Algorithms Not Allowed in the Approved Mode of Operation: The table below lists Non-Approved security functions that are not Allowed in the Approved Mode of Operation. © 2025 Red Hat, Inc. / atsec information security.

9 of 46

Table 6 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

The software block diagram below shows the module, its interfaces with the operational environment and the delimitation of its cryptographic boundary. © 2025 Red Hat, Inc. / atsec information security.

10 of 46

Figure 1

• Cryptographic Boundary The module is implemented as a shared library. The cryptographic module boundary consists of 5 components:
• libgnutls
• libnettle
• libhogweed
• libgmp
• statically linked
• gnutls hmac file © 2025 Red Hat, Inc. / atsec information security.

11 of 46

The logical interfaces are the API through which the applications request services. The following table summarizes the logical interfaces: Table 7 - Ports and Interfaces © 2025 Red Hat, Inc. / atsec information security.

12 of 46

The module supports the Crypto Officer role only. This sole role is implicitly assumed by the operator of the module when performing a service. The module does not support

Table below describes the authorized role(s) in which the service can be performed with specification

2 The enabled-curve input parameter can be adjusted relying on the crypto-policies package provided as part of the RHEL

OS. The usage of crypto-policies is discouraged by the vendor. Further info can be found at the vendor's documentation. © 2025 Red Hat, Inc. / atsec information security.

13 of 46

Table 8 - Roles, Service Commands, Input and Output

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 Crypto Officer role is authorized to access all services provided by the module (see Table - Approved Services and Table - Non-Approved Services below). The table below lists all approved services that can be used in the approved mode of operation. The following convention is used to specify access rights to an SSP:

• 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 = Zeroize: The module zeroizes the SSP.
• N/A: the calling application 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" depending on whether the API invoked corresponds to an approved algorithm. © 2025 Red Hat, Inc. / atsec information security.

14 of 46

Service Symmetric decryption Authenticated encryption Authenticated decryption Key wrapping Key unwrapping Key pair generation Digital signature generation

Description Perform AES decryption Encrypt a plaintext Decrypt a ciphertext Key wrapping (as part of the cipher suites in the TLS protocol) Key unwrapping (as part of the cipher suites in the TLS protocol) Generate RSA, ECDSA/ECDH and DH key pairs Generate RSA and ECDSA signature See Table 5 for SHA sizes

Approved Security Functions AES-CBC AES-ECB AES-CCM AES-GCM AES-CFB8 AES-CMAC AES-GMAC AES-XTS AES-CCM AES-CCM AES-CCM AES-GCM AES-CBC, HMAC AES-CCM AES-GCM AES-CBC, HMAC CKG DRBG ECDSA RSA Safe Primes Key generation DRBG ECDSA SHA RSA

Keys and/or SSPs AES key AES key AES key AES key AES key, HMAC key AES key AES key, HMAC key Module-generated RSA public key, Module generated RSA private key Module-generated ECDSA public key, Module generated ECDSA private key Module-generated Diffie-Hellman public key, Module-generated Diffie-Hellman private keys Module-generated EC Diffie-Hellman public key, Module-generated EC Diffie-Hellman private keys “enabled-curve” parameter DRBG internal state (V value, key) RSA private key DRBG internal state (V value, key) ECDSA private key

Roles

Access rights to Keys and/or SSPs W, E W, E W, E W, E W, E W, E W, E G, E, R G, E, R G, E, R G, E, R W, E W, E W, E

Indicator GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED

© 2025 Red Hat, Inc. / atsec information security.

15 of 46

Service Digital signature verification Public key verification Random number generation Message digest Message authentication code (MAC) Message authentication code verification Diffie-Hellman shared secret computation EC Diffie-Hellman shared secret computation TLS key derivation HKDF key derivation Password-based key derivation

Description Verify RSA, and ECDSA signature See Table 5 for SHA sizes Verify ECDSA public key Generate random bitstrings Compute SHA hashes Compute HMAC Compute AES- based CMAC Compute AES- based GMAC Verify MAC tag Compute a shared secret Compute a shared secret Perform TLS key derivation Perform key derivation using HKDF (in the context of TLS 1.3) Perform password- based key derivation

Approved Security Functions RSA ECDSA SHA ECDSA DRBG SHA Compute HMAC CMAC with AES GMAC with AES HMAC or GMAC with AES or CMAC with AES KAS-FFC-SSC KAS-ECC-SSC TLS v1.2 KDF RFC7627 KDA HKDF PBKDF

Keys and/or SSPs RSA public key ECDSA public key ECDSA public key Entropy input DRBG internal state (V value, key) DRBG seed None HMAC key AES key AES key AES key or HMAC key Diffie-Hellman public key, Diffie- Hellman private key Diffie-Hellman Shared secret EC Diffie-Hellman public key, EC Diffie-Hellman private key EC Diffie-Hellman Shared secret TLS pre-master secret TLS master secret TLS derived key Diffie-Hellman shared secret or EC Diffie-Hellman shared secret HKDF derived key Password/passphr ase PBKDF derived key

Roles

Access rights to Keys and/or SSPs W, E W, E W, E E, G E, G N/A W, E W, E W, E G, R W, E G, R W, E E, G G, R W, E G, R W, E G, R

Indicator GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED GNUTLS_FIPS140 _OP_APPROVED

© 2025 Red Hat, Inc. / atsec information security.

16 of 46

The table below lists all non-Approved services that can only be used in the non-Approved mode of operation. © 2025 Red Hat, Inc. / atsec information security.

17 of 46

Service Cryptographic Services Symmetric decryption Key pair generation Digital signature generation Digital signature verification Domain parameter generation Message digest Message authentication code (MAC) Key agreement Key encapsulation Key un- encapsulation Diffie-Hellman shared secret computation

Description Compute the cipher for decryption Generate RSA, DSA, and ECDSA key pairs Sign RSA, DSA, and ECDSA signatures Verify RSA, DSA, and ECDSA signatures Generate domain parameter Compute message digest Compute HMAC Perform key agreement Perform RSA key encapsulation Perform RSA key un- encapsulation Perform DH shared secret computation

Algorithms Accessed AES GCM not in the context of the TLS protocol Blowfish Camellia CAST ChaCha20 DES GOST RC2, RC4 Salsa20 Serpent Triple-DES Twofish DSA ECDSA with curves not listed in Table 5 RSA with keys smaller than 2048 bits or greater than 4096 bits DSA ECDSA with curves not listed in Table 5 RSA with keys smaller than 2048 bits or greater than 4096 bits DSA ECDSA with curves not listed in Table 5 RSA with keys smaller than 1024 bits or greater than 4096 bits DSA GOST MD2, MD4, MD5 RMD160 SM3 STREEBOG HMAC with keys smaller than 112-bit HMAC with GOST MD2, MD4, MD5 RMD160 STREEBOG UMAC Diffie-Hellman with keys generated with domain parameters other than safe primes EC Diffie-Hellman with curves not listed in Table 5 RSA encryption and decryption with any key sizes RSA encryption and decryption with any key sizes Diffie-Hellman with keys generated with domain parameters other than safe primes

Role

© 2025 Red Hat, Inc. / atsec information security.

18 of 46

Service Cryptographic Services EC Diffie-Hellman shared secret computation Password-based key derivation Public key verification Transport Layer Security (TLS) network protocol

Description Perform ECDH shared secret computation Perform password-based key derivation Verify ECDSA public key Establish non-supported TLS channel

Algorithms Accessed EC Diffie-Hellman with curves not listed in Table 5 PBKDF using non-approved message digest algorithms ECDSA with curves not listed in Table 5 Non-supported cipher suite (see Appendix A for the complete list of valid cipher)

Role

© 2025 Red Hat, Inc. / atsec information security.

19 of 46

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 preoperational test (i.e., integrity test) and the cryptographic algorithm self-tests (CASTs). The SelfTests 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 SelfTest 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.

The module consists of executable code in the form of libgnutls, libnettle, libgmp and libhogweed shared libraries as stated in section 2. © 2025 Red Hat, Inc. / atsec information security.

20 of 46

The module operates in a modifiable operational environment per FIPS 140-3 level 1 specification: the module executes on a general-purpose operating system (Red Hat Enterprise Linux 9), which allows modification, loading, and execution of software that is not part of the validated module.

See Section 2.3. The Red Hat Enterprise Linux operating system is used as the basis of other products which include but are not limited to:

• Red Hat Enterprise Linux CoreOS
• Red Hat Ansible Automation Platform
• Red Hat OpenStack Platform
• Red Hat OpenShift
• Red Hat Gluster Storage
• Red Hat Satellite Compliance is maintained for these products whenever the binaries are found unchanged.

The module shall be installed as stated in Section 11. 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. The module does not have the capability of loading software or firmware from an external source. 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 Red Hat, Inc. / atsec information security.

21 of 46

The module is comprised of software only and therefore this section is Not Applicable (N/A). © 2025 Red Hat, Inc. / atsec information security.

22 of 46

This module does not implement any non-invasive security mechanism and therefore this section is Not Applicable (N/A). © 2025 Red Hat, Inc. / atsec information security.

23 of 46

Table 11 summarizes the SSPs that are used by the cryptographic services implemented in the © 2025 Red Hat, Inc. / atsec information security.

24 of 46

© 2025 Red Hat, Inc. / atsec information security.

25 of 46

© 2025 Red Hat, Inc. / atsec information security.

26 of 46

© 2025 Red Hat, Inc. / atsec information security.

27 of 46

© 2025 Red Hat, Inc. / atsec information security.

28 of 46

© 2025 Red Hat, Inc. / atsec information security.

29 of 46

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-90Bcompliant Entropy Source specified in the table below to seed the DRBG. Table 12 - Non-Deterministic Random Number Generation Specification The module generates SSPs (e.g., keys) whose strengths are modified by available entropy. © 2025 Red Hat, Inc. / atsec information security.

30 of 46

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] according to section 6.1 of [SP800-133rev2] (vendor affirmed) by obtaining a random bit string directly from an approved [SP800-90Arev1] DRBG and that can support the required security strength requested by the caller (without any V, as described in Additional Comments 2 of IG D.H).

• For generating RSA and ECDSA keys, the module implements asymmetric cryptographic key generation (CKG) services compliant with [FIPS186-4].
• 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-4] 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. The module provides the following SSP generation methods with associated SSP sizes and strengths:
• RSA [FIPS186-4] B.3.2 Random Provable Primes - 2048, 3072, 4096-bit keys with 112-149 bits of key strength
• ECDH/ECDSA [FIPS186-4] B.4.2 Testing Candidates - P-256, P-384, P-521 elliptic curves with 128-256 bits of key strength
• Safe Primes Key Generation [SP800-56Arev3] - 2048, 3072, 4096, 6144, 8192-bit keys with 112-200 bits of key 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 (RFC7627) The module supports the following key derivation methods according to [SP800-56Cr1]:
• HKDF for the TLS protocol 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 Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service.

SSPs are provided to the module via API input parameters in plaintext form and output via API output 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. The module does not support entry or output of cryptographically protected SSPs.

The module provides Diffie-Hellman and EC Diffie-Hellman shared secret computation compliant with SP800- 56Arev3, 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-ECC-SSC) followed by the derivation of the keying material using SP800-135rev1 KDF and SP800-56Crev1 KDF. © 2025 Red Hat, Inc. / atsec information security.

31 of 46

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)
• ffdhe2048 (ID = 256)
• ffdhe3072 (ID = 257)
• ffdhe4096 (ID = 258)
• ffdhe6144 (ID = 259)
• 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)
• 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 (in compliance with IG D.G). According to Table 2: Comparable strengths in [SP 800-57rev5], the key sizes of AES, DiffieHellman 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 128 or 256 bits of encryption strength.
• 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.

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. The module does not perform persistent storage of SSPs. The SSPs are temporarily stored in the RAM in plaintext form. SSPs are provided to the module by the calling process and are destroyed when released by the appropriate zeroization function calls.

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 © 2025 Red Hat, Inc. / atsec information security.

32 of 46

functions provided in the module's API and listed in Table 11. 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 11 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 Red Hat, Inc. / atsec information security.

33 of 46

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 pre-operational test and the CASTs succeed, the module becomes operational. If any of the pre-operational test or any of the CASTs fail an error message is returned, and the module transitions to the error state.

The module performs the following pre-operational tests: the integrity test of the shared libraries that comprise the module using HMAC-SHA2-256. The details of integrity test are provided in section 5.1. Prior the first use, a CAST is executed for the algorithms used in the Pre-operational Self-Tests.

The following sub-sections describe the conditional self-tests supported by the module. 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.

The module performs cryptographic algorithm self-tests (CASTs) on all approved cryptographic algorithms. The CASTs consist of Known Answer Tests for all the approved cryptographic algorithms. © 2025 Red Hat, Inc. / atsec information security.

34 of 46

Table 13 - Conditional Cryptographic Algorithm Self-Tests

The module performs the Pair-wise Consistency Tests (PCT) shown in the following table. If any of Table 14 - Pairwise Consistency Test

The module provides the Self-Test service to perform self-tests on demand which includes the preTests 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 SelfTest 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. 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 The following table shows the error codes and the corresponding condition: Table 15 - Error States 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 per© 2025 Red Hat, Inc. / atsec information security.

35 of 46

operational self-test and the CASTs to recover from these errors. If failures persist, the module must be re-installed. © 2025 Red Hat, Inc. / atsec information security.

36 of 46

The module is distributed as a part of the Red Hat Enterprise Linux 9 (RHEL 9) package in the form of:

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

The binaries of the 'Red Hat Enterprise Linux 9 gnutls version 3.7.6-074d015ce201f434’ are contained in the RPM packages for delivery listed below. Before the 'Red Hat Enterprise Linux 9 gnutls’ RPM packages are installed, the RHEL 9 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 thirdparty 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 RHEL 9 system operates in Approved mode by executing the fips-mode-setup --check command, which should output “FIPS mode is enabled.” The following RPM packages contain the FIPS validated module: Table 16 - RPM packages

The TLS protocol implementation provides both server and client sides. In order to operate in the approved mode, digital certificates used for server and client authentication shall comply with the © 2025 Red Hat, Inc. / atsec information security.

37 of 46

restrictions of key size and message digest algorithms imposed by [SP800-131Arev2]. In addition, as required also by [SP800-131Arev2], Diffie-Hellman with keys smaller than 2048 bits must not be used. The TLS protocol lacks the support to negotiate the used Diffie-Hellman key sizes. To ensure full support for all TLS protocol versions, the TLS client implementation of the module accepts DiffieHellman key sizes smaller than 2048 bits offered by the TLS server. For complying with the requirement to not allow Diffie-Hellman key sizes smaller than 2048 bits, the Crypto Officer must ensure that:

• in case the module is used as a TLS server, the Diffie-Hellman parameters must be 2048 bits or larger;
• in case the module is used as a TLS client, the TLS server must be configured to only offer Diffie-Hellman keys of 2048 bits or larger.

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 2²⁰ AES blocks, that is 16MB of data. 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 (in compliance with IG C.I). Note: AES-XTS shall be used with 128 and 256-bit keys only. AES-XTS with 192-bit keys is not an Approved service.

The module implements AES GCM for being used in the TLS v1.2 and v1.3 protocols. AES GCM IV generation is in compliance with [FIPS140-3_IG] IG C.H for both protocols as follows:

• For TLS v1.2, IV generation is in compliance with scenario 1.a of IG C.H and [RFC5288]. The module supports acceptable AES-GCM ciphersuites from section 3.3.1 of [SP800-52rev2].
• For TLS v1.3, IV generation is in compliance with scenario 5 of IG C.H and [RFC8446]. The module supports acceptable AES-GCM ciphersuites from section 3.3.1 of [SP800-52rev2]. The IV generated in both scenarios is only used within the context of the TLS protocol implementation. The nonce_explicit part of the IV does not exhaust the maximum number of possible values for a given session key. The design of the TLS protocol in this module implicitly ensures that the nonce_explicit, or counter portion of the IV will not exhaust all of its possible values. In case the module's power is lost and then restored, the key used for the AES GCM encryption or decryption shall be redistributed. The Crypto Officer can use the module’s API to perform AES GCM encryption using internal IV generation. These IVs are always 96 bits and generated using the approved DRBG internal to the module’s boundary. This is in compliance with Scenario 2 of FIPS 140-3 IG C.H.

The module provides password-based key derivation (PBKDF), compliant with SP800-132 and IG D.N. 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. © 2025 Red Hat, Inc. / atsec information security.

38 of 46

• 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 length of the password or passphrase shall be of at least 14 characters (this is verified by the module to determine the service is approved), and shall consist of lower-case, uppercase and numeric characters. The probability of guessing the value is estimated to be 10-14 (assuming all digits) The calling application shall also observe the rest of the requirements and recommendations specified in [SP800-132].

To comply with the assurances listed in section 5.6.2 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. © 2025 Red Hat, Inc. / atsec information security.

39 of 46

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 Red Hat, Inc. / atsec information security.

40 of 46

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 Red Hat, Inc. / atsec information security.

41 of 46

© 2025 Red Hat, Inc. / atsec information security.

42 of 46

Appendix B. Glossary and Abbreviations AES            Advanced Encryption Standard AES-NI         Advanced Encryption Standard New Instructions CAVP           Cryptographic Algorithm Validation Program CBC            Cipher Block Chaining CCM            Counter with Cipher Block Chaining-Message Authentication Code CFB            Cipher Feedback CKG            Cryptographic Key Generation CMAC           Cipher-based Message Authentication Code CMVP           Cryptographic Module Validation Program CPACF          CP Assist for Cryptographic Functions CSP            Critical Security Parameter CTR            Counter Mode DES            Data Encryption Standard DF             Derivation Function DSA            Digital Signature Algorithm DRBG           Deterministic Random Bit Generator ECB            Electronic Code Book ECC            Elliptic Curve Cryptography FFC            Finite Field Cryptography FIPS           Federal Information Processing Standards Publication GCM            Galois Counter Mode GMAC           Galois Counter Mode Message Authentication Code HMAC           Hash Message Authentication Code KAS            Key Agreement Scheme 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 PBKDF2         Password-based Key Derivation Function v2 PKCS           Public-Key Cryptography Standards PCT            Pairwise Consistency Test PR             Prediction Resistance RNG            Random Number Generator RSA            Rivest, Shamir, Addleman SHA            Secure Hash Algorithm SHS            Secure Hash Standard © 2025 Red Hat, Inc. / atsec information security.

43 of 46

SP800-135rev1 NIST Special Publication 800-135 Revision 1 - Recommendation for Existing Application-Specific Key Derivation Functions December 2011 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-135r1.pdf © 2025 Red Hat, Inc. / atsec information security.

45 of 46