Oracle Linux 9 GnuTLS Cryptographic Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Oracle Linux 9 GnuTLS Cryptographic Module
  %% 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>Recovery<br/>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>library named: gnutls</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 Oracle Linux 9 GnuTLS Cryptographic Module
  %% 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>Recovery<br/>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>library named: gnutls</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

Oracle Corporation Oracle Linux 9 GnuTLS Cryptographic Module Software Version: 3.7.6-39e2433a29b33b55 Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 www.atsec.com Document Version 1.4. ©Oracle Corporation

Title: Oracle 9 GnuTLS Cryptographic Module Security Policy Date: August 28th, 2025 Contributing Authors: Oracle Linux Engineering Security Evaluations – Global Product Security atsec information security Oracle Corporation World Headquarters

Austin, TX 78741 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Oracle specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy i

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy iii

This document is the non-proprietary FIPS 140-3 Security Policy for version 3.7.6-39e2433a29b33b55 of the Oracle

9 GnuTLS Cryptographic Module. 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.

This Security Policy describes the features and design of the module named GnuTLS Cryptographic Module 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. 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. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Purpose and Use: The Oracle 9 GnuTLS Cryptographic Module (hereafter referred to as “the module”) is a cryptographic module that provides cryptographic services to applications running in the user space of the underlying operating system through a C language Application Program Interface (API). Module Type: Software Module Embodiment: MultiChipStand Cryptographic Boundary: Figure 1 shows the cryptographic boundary of the module, its interfaces with the operational environment and the information flow between the module and operator (depicted through the arrows). The module components consist of the libgnutls.so.30, libnettle.so.8, libhogweed.so.6, and libgmp.so.10. The module integrity is verified for each of the component separately using HMAC at power on by comparing with the pre-computed HMAC values stored in .libgnutls.so.30.hmac file 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. Figure 1: Cryptographic Boundary Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments - Software, Firmware, Hybrid: Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: Table 4: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid 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. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

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

Modes List and Description: Table 5: Modes List and Description Mode Change Instructions and Status: When the module starts up successfully, after passing the pre-operational and all 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 Non-Approved Services table. Please see Section 4 or the details on service indicator provided by the module that identifies when

Approved Algorithms: Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Vendor-Affirmed Algorithms: Table 7: Vendor-Affirmed Algorithms Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Table 9: Security Function Implementations

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. 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 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. 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. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

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 IV generated in both TLS 1.2 and TLS 1.3 scenarios is only used within the context of the TLS protocol implementation.

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 with [SP800-132], the module ensures that the following requirements are met when running the PBKDF approved service.

• The length of the MK or DPK is 112 bits or more.
• A portion of the salt, with a length of at least 128 bits (it shall be generated randomly using the [SP80090Ar1] DRBG).
• The minimum value of the iteration count is 1000 (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 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. Passwords or passphrases, used as an input for the PBKDF, shall not be used as cryptographic keys. Derived keys shall only be used in storage applications. The Master Key (MK) shall not be used for other purposes. The calling application shall also observe the rest of the requirements and recommendations specified in [SP800-132].

The length of a single data unit encrypted or decrypted with AES XTS shall not exceed 220 AES blocks, that is 16MB, of data per XTS instance. An XTS instance is defined in Section 4 of SP 800-38E. To meet the requirement stated in IG C.I, the module implements a check to ensure that the two AES keys used in AES XTS mode are not identical. The XTS mode shall only be used for the cryptographic protection of data on storage devices. It shall not be used for other purposes, such as the encryption of data in transit.

The module offers DH and ECDH shared secret computation services compliant to the SP 800-56Ar3. To meet the required assurances listed in section 5.6 of SP 800-56Ar3, the module shall be used together with an application that implements the “TLS protocol” and the following steps shall be performed. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

• 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-56Ar3.
• 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-56Ar3.
• The module does not support static keys therefore the "assurance of peer's possession of private key" is not applicable.

Table 10: Entropy Certificates Table 11: Entropy Sources RNG Information: The module employs a Deterministic Random Bit Generator (DRBG) based on SP 800-90Ar1 for keys and random numbers for security functions (e.g. ECDSA signature generation), and server and client random numbers for the TLS protocol. In addition, the module provides a Random Number Generation service to calling applications. The DRBG supports the CTR_DRBG with AES-256, without a derivation function and without prediction resistance. The module uses an [SP800-90B]-compliant entropy source specified in the Entropy Source table. This entropy source is located within the physical perimeter, but outside of the cryptographic boundary of the module. The module obtains 384 bits to seed the DRBG, and 256 bits to reseed it, sufficient to provide a DRBG with 256 bits of security strength.

The module implements key generation methods according to SP 800-133r2 section 4 example 1, without the use of V. The key generation methods are specified in the Vendor Affirmed Algorithms table and the Security Function Implementations table. Additionally, the module implements key derivation methods according to section 6.2 of SP 800-133r2. The key derivation methods are specified in the Security Function Implementations table.

The module implements SSP agreement, compliant with IG D.F scenario 2(1) and scenario 2(2). Additionally, the module implements SSP transport, compliant with IG D.G. The Key Establishment methods are specified in the Security Function Implementations table. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

The module implements KDF for the TLS protocol TLSv1.2. No parts of the TLS 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. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Table 12: Ports and Interfaces The logical interfaces are the APIs through which the applications request services. These logical interfaces are logically separated from each other by the API design. The module does not implement a control output interface.

The module does not implement a trusted channel.

The module does not implement a control output interface. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

The module does not implement authentication for roles.

Table 13: Roles The module supports the Crypto Officer role only. This sole role is implicitly and always assumed by the operator of the module. The module does not support multiple concurrent operators.

W,E W,E Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

G,R W,E G,R G,R G,R Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

G,E G,E Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Z Z Z Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

G,E G,E G,E G,R G,R Table 14: Approved Services The following convention is used to specify access rights to SSPs: • Generate (G): The module generates or derives the SSP. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

• 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. The service indicator API functions that must be used to verify the service indicator for each of the services. The function gnutls_fips140_get_operation_state() indicates GNUTLS_FIPS140_OP_NOT_APPROVED or GNUTLS_FIPS140_OP_APPROVED depending on whether the API invoked corresponds to an approved or nonapproved algorithm. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Table 15: Non-Approved Services

The module does not load external software or firmware. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

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 the software components of the module listed in section 2. If the HMAC values do not match, the test fails, and the module enters the error state.

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. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Type of Operational Environment: Modifiable How Requirements are Satisfied: 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.

The module shall be installed as stated in Section 11.1. 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. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

The module is comprised of software only and therefore this section is not applicable. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

This module does not implement any non-invasive security mechanism and therefore this section is not applicable. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Name API input parameters API output parameters

From Operating calling application (TOEPP) Cryptographic module

To Cryptographic module Operator calling application (TOEPP)

Format Type Plaintext Plaintext

Distribution Type Manual Manual

Entry Type Electronic Electronic

SFI or Algorithm

Table 16: Storage Areas Table 17: SSP Input-Output Methods API output parameters in the plaintext form within the physical perimeter of the operational environment. This is allowed by [FIPS140-3_IG] IG 9.5.A. Table 18: SSP Zeroization Methods All data output is inhibited during zeroization. Once the zeroization is started, all data output via the data output interface is inhibited until the zeroization is completed successfully. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Name Module- generated AES Key AES Key Module- generated HMAC Key HMAC Key Shared Secret Password PBKDF Derived Key Entropy Input DRBG Seed Internal State (V, Key) DH Public Key DH Private Key Module Generated DH Public Key Module Generated DH Private Key EC Private Key

Description AES key generated during Symmetric Key Generation AES key used for encryption, decryption, authenticated encryption, authenticated decryption and computing MAC tags HMAC key generated during Symmetric Key Generation HMAC Key Shared secret generated by DH/ECDH PBKDF password PBKDF2 derived key Entropy input used to seed the DRBGs DRBG seed derived from entropy input as defined in SP 800-90Ar1 Internal state of CTR_DRBG Public key used for DH Private key used for DH DH public key generated by the module DH private key generated by the module Private key used for ECDSA signature generation and Shared Secret Computation

Size - Strength 128, 192, 256 bits - 128, 192, 256 bits 128, 192, 256 bits - 128, 192, 256 bits HMAC key generated during Symmetric Key Generation - 112- 256 bits 112-524288 bits - 112-256 bits 224-8192 bits - 112-256 bits 112-256 bits - N/A 112-4096 bits - 112-256 bits 128-448 bits - 128-256 bits 128, 192, 256 bits - 128-256 bits 128, 192, 256 bits - 128-256 bits 2048, 3072, 4096, 6144, 8192 bits - 112-200 bits 2048, 3072, 4096, 6144, 8192 bits - 112-200 bits 2048, 3072, 4096, 6144, 8192 bits - 112-200 bits 2048, 3072, 4096, 6144, 8192 bits - 112-200 bits P-224, P-256, P- 384, P-521 - 128- 256 bits

Type - Category Symmetric key - CSP Symmetric key - CSP Authentication key - CSP Authentication key - CSP Shared secret - CSP Password - CSP Derived Key - CSP Entropy - CSP SEED - CSP DRBG Internal state - CSP Public key - PSP Private key - CSP Public key - PSP Private key - CSP Private key - CSP

Generated By Symmetric Key Generation with Counter DRBG Symmetric Key Generation with Counter DRBG Password-based Key Derivation Counter DRBG Counter DRBG Safe Primes Key Generation Safe Primes Key Generation

Established By KAS-ECC-SSC KAS-FFC-SSC

Used By AES CCM (Key Wrapping/Unwrapping) AES CBC with HMAC AES GCM (Key Wrapping/Unwrapping) AES-CBC AES-CMAC AES-CFB8 AES-XTS AES-GMAC AES CCM (Authenticated Encryption/Decryption) AES GCM (Authenticated Encryption/Decryption) HMAC HKDF Key Derivation TLS 1.2 Key Derivation KDA HKDF Sp800-56Cr1 (A4750) Password-based Key Derivation Counter DRBG Counter DRBG Counter DRBG KAS-FFC-SSC KAS-FFC-SSC TLS Handshake TLS Handshake KAS-ECC-SSC

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Name EC Public Key Module Generated EC Private Key Module Generated EC Public Key RSA Private Key RSA Public Key Module Generated RSA Private Key Module Generated RSA Public Key TLS Pre-Master Secret TLS Master Secret TLS Derived Secret Intermediate Key Generation Value HKDF Derived Key

Description Public key used for ECDSA signature verification primitive and Shared Secret Computation EC private key generated by the module EC public key generated by the module Private key used for RSA signature generation Public key used for RSA signature verification RSA private key generated by the module RSA public key generated by the module TLS pre-master secret used for deriving the TLS master secret TLS master secret used for deriving the TLS derived secret TLS derived secret, derived from TLS master secret Intermediate key generation value HKDF derived key

Size - Strength P-224, P-256, P- 384, P-521 - 128- 256 bits P-224, P-256, P- 384, P-521 - 128- 256 bits P-224, P-256, P- 384, P-521 - 128- 256 bits 2048, 3072, 4096 bits - 112, 128, 150 bits 1024, 2048, 3072, 4096 bits - 80, 112, 128, 150 bits 2048, 3072, 4096 bits - 112, 128, 150 bits 2048, 3072, 4096 bits - 112, 128, 150 bits 112-256 bits - N/A 112-256 bits - N/A 112-256 bits - 112-256 bits 224-4096 bits - 112-256 bits 112-256 - 112-256 bits

Type - Category Public key - PSP Private key - CSP Public key - PSP Private key - CSP Public key - PSP Private key - CSP Public key - PSP TLS Pre-master secret - CSP TLS Master secret - CSP Symmetric key - CSP Intermediate value - CSP Derived key - CSP

Generated By ECDSA Key Generation ECDSA Key Generation RSA Key Generation RSA Key Generation TLS 1.2 Key Derivation TLS 1.2 Key Derivation ECDSA Key Generation RSA Key Generation Safe Primes Key Generation KDA HKDF Sp800-56Cr1 (A4750)

Established By KAS-ECC-SSC KAS-FFC-SSC

Used By KAS-ECC-SSC TLS Handshake TLS Handshake RSA Signature Generation RSA Signature Verification TLS Handshake TLS Handshake TLS Handshake ECDSA Key Generation RSA Key Generation Safe Primes Key Generation

Table 19: SSP Table 1 Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

The SHA-1 algorithm as implemented by the module will be non-approved for all purposes, starting January 1, 2031. The RSA, ECDSA algorithm as implemented by the module conforms to FIPS 186-4, which has been superseded by FIPS 186-5. FIPS 186-4 will be withdrawn on February 3, 2024. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Table 21: Pre-Operational Self-Tests The pre-operational software integrity test is performed automatically (after the CASTs) when the module is powered on, before the module transitions into the operational state. 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. The module transitions to the operational state only after the pre-operational self-test has passed successfully. If the pre-operational self-test fails, the module transitions to the error state.

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Algorithm or Test

Test Properties

Test Method

Test Type

Indicator services are available for use

Details

Conditions

Table 22: Conditional Self-Tests If any conditional self-test fails, the module transitions to the error state.

Table 23: Pre-Operational Periodic Information Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Table 24: Conditional Periodic Information Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Table 25: Error States In the error state, the data output interface is inhibited, and the module accepts no more inputs or requests (as the module is no longer running). The calling application can obtain the module state by calling the gnutls_fips140_get_operation_state() API function.

The module provides the Self-Test service to perform self-tests on demand which includes the pre-operational test (i.e., integrity test) and 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 selftests. 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. The PCTs can be invoked on demand by requesting the Asymmetric Key Generation service. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

The module is distributed as a part of the Oracle Linux 9 (OL9) RPM in the form of gnutls-3.7.6-21.0.1.el9_2_fips, nettle-3.8-3.el9_0, gmp-6.2.0-10.el9 RPM packages that are in the “Oracle Linux 9 Security Validation (Update 3)” yum repository (ol9_u3_security_validation). Note: libhogweed is provided by nettle-3.8-3.el9_0. The Oracle Linux 9 system FIPS validated configuration can be achieved by:

• For installation 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.
• For switching the system into the FIPS validated configuration after the installation execute the fips-modesetup --enable command. Restart the system. In both cases, the Crypto Officer must verify that the Oracle Linux 9 system operates in a FIPS validated configuration by executing the fips-mode-setup --check command, which shall output “FIPS mode is enabled.” For more information on Oracle Linux 9 system FIPS validated configuration, please see Oracle Linux 9 product documentation. After installation of the gnutls-3.7.6-21.0.1.el9_2_fips, nettle-3.8-3.el9_0, gmp-6.2.0-10.el9 RPM packages, the Crypto Officer must execute the “Show module name and version” service using the gnutls_get_library_config API. The service output must be as follows: fips-module-name: Oracle Linux 9 GnuTLS Cryptographic Module fips-module-version: 3.7.6-39e2433a29b33b55 libgnutls-soname: libgnutls.so.30 libnettle-soname: libnettle.so.8 libhogweed-soname: libhogweed.so.6

The Approved and non-Approved modes of operation are specified in section 2.4. The administrative functions are specified in the Approved Services table. All the logical interfaces are specified in section 3.1. The requirements and restrictions that shall be considered when operating the module in approved mode are specified in section 2.7 (for algorithm-specific information) and section 6 (for operational environment). The installation, initialization, and startup procedures specified in section 11.1 shall be followed.

The module does not have any guidance for non-administrator.

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 gnutls-3.7.6-21.0.1.el9_2_fips, nettle-3.83.el9_0, gmp-6.2.0-10.el9 RPM packages can be uninstalled from the Oracle Linux 9 system. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

The module does not offer mitigation of other attacks. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Appendix A. TLS Cipher Suites The module supports the following cipher suites for the TLS protocol version 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. Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Appendix B. Glossary and Abbreviations Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Appendix C. References Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy

SP 800-140B

CMVP Security Policy Requirements March 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140B.pdf

Oracle Linux 9 GnuTLS Cryptographic Module Security Policy