Oracle Linux 9 libgcrypt Cryptographic Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Oracle Linux 9 libgcrypt 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<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>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 libgcrypt 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<br/>Status Output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>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 libgcrypt Cryptographic Module Software Version: 1.10.0-3957adb8de08b15a Prepared by: atsec information security corporation

4516 Seton Center Parkway, Suite 250

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

Title: Oracle Linux 9 libgcrypt Cryptographic Module Security Policy Date: October 1st, 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 Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Oracle Linux 9 libgcrypt Cryptographic Module Security Policy i

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy iii

This document is the non-proprietary FIPS 140-3 Security Policy for version 1.10.0-3957adb8de08b15a of the Oracle Linux 9 libgcrypt 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 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.

Table 1: Security Levels Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Purpose and Use: The Oracle Linux 9 libgcrypt Cryptographic Module (hereafter referred to as “the module”) is a Software multi-chip standalone cryptographic module. The module is a software library implementing general purpose cryptographic algorithms. The module provides cryptographic services to applications running in the user space of the underlying operating system through an application program interface (API). Module Type: Software Module Embodiment: MultiChipStand Cryptographic Boundary: Figure 1 shows the cryptographic boundary of the module in orange, its interfaces with the operational environment and the flow of information between the module and operator (depicted through the arrows). The software component of the cryptographic module is listed in the Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets) table. 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: Block Diagram Oracle Linux 9 libgcrypt 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: Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

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.

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

Modes List and Description: 4.3 4.4 Table 5: Modes List and Description Mode Change Instructions and Status: After passing all pre-operational self-test and cryptographic algorithm self-tests (CASTs) executed on start-up, the module automatically transitions to the approved mode. No operator intervention is required to reach this point. The module automatically switches between the approved and nonapproved modes.

Approved Algorithms: Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Table 6: Approved Algorithms Vendor-Affirmed Algorithms:

Table 7: Vendor-Affirmed Algorithms

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Table 9: Security Function Implementations

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 provides password-based key derivation (PBKDF), 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 SP 800-132 and FIPS 140-3 IG D.N, the following requirements shall be met.

• Derived keys shall only be used in storage applications. The Master Key (MK) shall not be used for other purposes. The module accepts length of the MK or DPK of 112 bits or more.
• A portion of the salt shall be generated randomly using the SP 800-90Arev1 DRBG provided by the module. The minimum length required is 128 bits.
• The iteration count is 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 accepted by the module is 1000.
• 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 8 characters, and may consist of lowercase, uppercase, and numeric characters. Assuming the worst-case scenario of all digits, the probability is estimated to be at most 10-8. Combined with the minimum iteration count as described above in the third bullet, this provides an acceptable trade-off between user experience and security against brute-force attacks. The calling application shall also observe the rest of the requirements and recommendations specified in SP 800-132.

Table 10: Entropy Certificates N/A for this module. Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

The module provides an SP 800-90Arev1-compliant Deterministic Random Bit Generator (DRBG) for creation of key components of asymmetric keys, and random number generation. This entropy source is located within the module’s physical perimeter, but outside of the module’s cryptographic boundary. The module obtains 384 bits to seed the DRBG, and 256 bits to reseed it. The seeding (and automatic reseeding) of the DRBG is done with getrandom(). The DRBG supports the Hash_DRBG, HMAC_DRBG, and CTR_DRBG mechanisms. The DRBG is initialized during module initialization; the module loads by default the DRBG and using the HMAC_DRBG mechanism with SHA-256 and without prediction resistance. A different DRBG mechanism can be chosen by invoking the gcry_control(GCRYCTL_DRBG_REINIT) function. The module performs the DRBG health tests as defined in Section 11.3 of SP 800-90Arev1.

The module provides an SP 800-90Arev1-compliant DRBG for the creation of the key components of asymmetric keys, and random number generation. The Cryptographic Key Generation (CKG) methods implemented in the module for Approved Services in the approved mode are compliant with Section 5.1 of SP 800-133rev2. For generating RSA and ECDSA keys, the module implements asymmetric key generation services compliant with FIPS 186-4. A seed (i.e. the random value) used in asymmetric key generation is directly obtained from the SP 800-90Arev1 DRBG. Additionally, according to section 6.2 of SP 800-133rev2, the module implements the PBKDF2 key derivation method compliant with option 1a of SP 800-132. This implementation shall only be used to derive keys for use in storage applications.

As permitted by IG D.G, the module provides key transport either by using an approved authenticated encryption mode or by a combination of any approved symmetric encryption mode and an approved authentication method. The SSP transport methods are specified in the Security Function Implementations table.

The module does not support any industry protocols listed within the publication of SP 800-135rev1. Therefore, this section is not applicable. Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Table 11: 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 Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

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. The module does not support multiple concurrent operators.

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

W,E W,E s W,E G,E G,W,E G,W,E W,E Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

W,E Z Z Z Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Z Table 13: Approved Services For all approved services, GPG_ERR_NO_ERROR (i.e., “0”) return code indicates the service is approved. In case the above-mentioned controls are used in conjunction, the operator is responsible to check that all the called functions return GPG_ERR_NO_ERROR (i.e., “0”). For all non-approved services, a "nonzero" return code indicates the service is not approved. The table above lists the approved services. For each service, the table lists the associated cryptographic algorithm(s), the role to perform the service, the cryptographic keys or CSPs involved, and their access type(s). The following convention is used to specify access rights to SSPs: • 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. • N/A: the calling application does not access any CSP or key during its operation. The details of the approved cryptographic algorithms including the CAVP certificate numbers can be found in Section 2.5. In order to check whether it utilizes an approved security function or not, the operator is responsible to invoke the gcry_control() API along with dedicated controls in the form of API input parameters. The module implements the following controls depending on the requested service:

1. GCRYCTL_FIPS_SERVICE_INDICATOR_CIPHER - For symmetric algorithms and the related modes.
2. GCRYCTL_FIPS_SERVICE_INDICATOR_KDF - For KDF operations.
3. GCRYCTL_FIPS_SERVICE_INDICATOR_PK_FLAGS - For asymmetric operations. 1
4. GCRYCTL_FIPS_SERVICE_INDICATOR_MD - For digest operations.
5. GCRYCTL_FIPS_SERVICE_INDICATOR_MAC - For MAC operations. The list of public key flags allowed in approved mode of operation is described in Section 4.4. Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

In addition to that, for the below-mentioned services, the approved service indicator corresponds to the GPG_ERR_NO_ERROR returned from listed functions in the indicator column below. They don’t use gcry_control() API:

1. Random number generation service: gcry_randomize(), gcry_random_bytes(), gcry_random_bytes_secure().
2. Public key validation service: gcry_mpi_ec_curve_point(). Table 14: Non-Approved Services The table above lists the non-approved services. The details of the non-approved cryptographic algorithms available in non-approved mode can be found in Section 2.5. For the services listed above, Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

the module implements an additional service indicator in the form of a control named GCRYCTL_FIPS_SERVICE_INDICATOR_FUNCTION. The operator is responsible to invoke the gcry_control() API along with the following input parameters: GCRYCTL_FIPS_SERVICE_INDICATOR_FUNCTION control; the name of the API 2 representing the service. The list of APIs is supported by the module can be found in the documentation included in the optional libgcryptdevel package. Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

The integrity of the module is verified by comparing a HMAC SHA-256 values calculated at run time with the HMAC SHA-256 value embedded within the module binary. If the HMAC values do not match, the test fails, and the module enters the Error state.

The integrity test is performed as part of the pre-operational self-test, which is executed when the module is initialized. In addition, the module provides the Self-Test service to perform self-tests on demand which includes the pre-operational test (i.e., integrity test) and cryptographic algorithm self-tests (CASTs). This service can be invoked relying on the gcry_control(GCRYCTL_SELFTEST) API function call or by powering-off and reloading the module. During the execution of the on-demand self-tests, services are not available, and data output or input is not possible. In order to verify whether the self-tests have succeeded and the module is in the Operational state, the calling application may invoke the gcry_control(GCRYTCL_OPERATIONAL_P) API. The function will return TRUE if the module is in the Operational state and FALSE if the module is in the Error state. Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

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

The module shall be installed as stated in Section 11.1. Instrumentation tools like the ptrace system call, gdb and strace, 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 nonvalidated operational environment. Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

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

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

Table 15: Storage Areas The module does not perform persistent storage of SSPs. The SSPs are temporarily stored in the RAM in Table 16: SSP Input-Output Methods The module does not support manual SSP input or intermediate SSP generation output. The SSPs are in plaintext form within the physical perimeter of the operational environment. This is allowed by FIPS 140-3 IG 9.5.A, according to the “CM Software to/from App via TOEPP Path” entry in the table above. Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Zeroization Method

Description

Rationale zeroization procedure succeeded.

Operator Initiation

Table 17: SSP Zeroization Methods All data output is inhibited during zeroization.

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Table 18: SSP Table 1 Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt 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 and ECDSA algorithms as implemented by the module conforms to FIPS 186-4, which has been superseded by FIPS 186-5. The transition started on July 25, 2023, and ended on February 4, 2024. FIPS 186-4 has been withdrawn since February 3, 2024. Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Table 20: Pre-Operational Self-Tests The pre-operational software integrity test is performed automatically 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 passes successfully.

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Table 21: Conditional Self-Tests The module performs self-tests on all approved cryptographic algorithms as part of the approved services supported in the approved mode of operation, using the tests shown in table above. Services are not available, and data output (via the data output interface) is inhibited during the self-tests. If any of these tests fails, the module transitions to the Error state.

Table 22: Pre-Operational Periodic Information Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Table 23: Conditional Periodic Information

Table 24: Error States The table above shows the error codes and the corresponding condition. When the module fails any preOracle Linux 9 libgcrypt Cryptographic Module Security Policy

enter the Error state. Any further cryptographic operation is inhibited. The calling application can obtain the module state by calling the gcry_control(GCRYCTL_OPERATIONAL_P) API function. The function returns FALSE if the module is in the Error state and TRUE if the module is in the Operational state. In the Error state, all data output is inhibited, no cryptographic operation is allowed, and the module accepts no more inputs or requests (as the module is no longer running). Recovery from the Error state includes restarting (i.e., powering off and powering on) of the module or running self-tests. Recovery from the Fatal Error state can only be done by restarting the module.

The software integrity tests, cryptographic algorithm self-tests, and entropy source start-up tests can be invoked on demand by unloading and subsequently re-initializing the module. The pair-wise consistency tests can be invoked on demand by requesting the key pair generation service. Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

The module is distributed as part of the Oracle Linux 9 (OL9) RPM package in the form of libgcrypt1.10.0-10.0.1.el9_2_fips RPM package that is located in the “Oracle Linux 9 Security Validation (Update 3)” yum repository (ol9_u3_security_validation). The operational environment needs to be set up in the FIPS validated configuration by installing the module as follows:

• 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.
• Switching the system into the FIPS validated configuration after the installation, execute the fips-mode-setup --enable command. Restart the system using the reboot command.
• For verifying that the FIPS validated configuration is enabled, execute the fips-mode-setup -check command as specified in Section 11.2.

The binaries of the module are contained in the RPM packages for delivery. The Crypto Officer shall follow Section 11.1 to configure the operational environment and install the module to be operated as a FIPS 140-3 validated module. The following RPM packages contain the FIPS validated module:

• libgcrypt-1.10.0-10.0.1.el9_2_fips.x86_64.rpm for Intel and AMD 64-bit processors
• libgcrypt-1.10.0-10.0.1.el9_2_fips.aarch64.rpm for Ampere 64-bit processor
• libgcrypt-1.10.0-10.0.1.el9_2_fips.mips64.rpm for OCTEON III 64-bit processor The Crypto Officer must verify the Oracle Linux 9 system operates in the FIPS validated configuration by executing the fips-mode-setup --check command, which should output “FIPS mode enabled”. After installation of the libgcrypt-1.10.0-10.0.1.el9_2_fips RPM packages, the Crypto Officer must check the output of the gcry_get_config() API. From the output, the Crypto Officer must ensure that the proper name is listed in the output as follows: Oracle Linux 9 libgcrypt Cryptographic Module 1.10.0-3957adb8de08b15a Once libgcrypt has been put into the FIPS validated configuration, it is not possible to switch back to the non-validated configuration without terminating the process first. If the logging verbosity level of libgcrypt has been set to at least 2, the state transitions and self-tests are logged.

There is no non-administrator guidance.

As the module does not persistently store SSPs, secure sanitization of the module consists of unloading the module. This will zeroize all SSPs in volatile memory. Then, if desired, the libgcrypt-1.10.010.0.1.el9_2_fips RPM packages can be uninstalled from the Oracle Linux 9 system. Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

The module implements blinding against RSA Timing Attacks. RSA is vulnerable to timing attacks. In a setup where attackers can measure the time of RSA decryption or signature operations, blinding must be used to protect the RSA operation from that attack.

By default, the module uses the following blinding technique: instead of using the RSA decryption directly, a blinded value y = x re mod n is decrypted and the unblinded value x' = y' r−1 mod n returned. The blinding value r is a random value with the size of the modulus n. Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

Listed below are the approved public key flags for an input s-expression: Oracle Linux 9 libgcrypt Cryptographic Module Security Policy

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

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

Oracle Linux 9 libgcrypt Cryptographic Module Security Policy