Red Hat Enterprise Linux 9 - OpenSSL FIPS Provider

Certificate

Approved Algorithms (375)

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

flowchart LR
  %% Deterministic review-risk graph for Red Hat Enterprise Linux 9 - OpenSSL FIPS Provider
  %% 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>Status Output<br/>Show status<br/>Self-test</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<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 - OpenSSL FIPS Provider
  %% 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>Status Output<br/>Show status<br/>Self-test</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<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 - OpenSSL FIPS Provider version 3.0.7-395c1a240fbfffd8 document version 1.5 Last update: 2025-07-08 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 corporation.

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

3 of 48

This document is the non-proprietary FIPS 140-3 Security Policy for version 3.0.7-395c1a240fbfffd8 of the Red Hat Enterprise Linux 9 - OpenSSL FIPS Provider. 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 and 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 describes the individual security areas of FIPS 140-3, as well as the security levels of those individual areas. © 2025 Red Hat, Inc. / atsec information security corporation.

4 of 48

Overall

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

5 of 48

The Red Hat Enterprise Linux 9 - OpenSSL FIPS Provider (hereafter referred to as “the module”) is defined as a software module in a multi-chip standalone embodiment. It provides a C language application program interface (API) for use by other applications that require cryptographic functionality. The module consists of one software component, the “FIPS provider”, which implements the FIPS requirements and the cryptographic functionality provided to the operator.

The module has been tested on the following platforms with the corresponding module variants and Table 2 - Tested Operational Environments In addition to the configurations tested by the atsec CST laboratory, the vendor affirms testing was performed on the following platforms for the module. Table 3 - Vendor Affirmed Operational Environments Note: the CMVP makes no statement as to the correct operation of the module or the security strengths of the generated SSPs when so ported if the specific operational environment is not listed on the validation certificate.

Table 4 lists all approved cryptographic algorithms of the module, including specific key lengths employed for approved services (Table 9), and implemented modes or methods of operation of the algorithms. The module supports RSA modulus sizes which are not tested by CAVP in compliance with FIPS 140-

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

6 of 48

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

7 of 48

1This algorithm is referred to as “Single Step KDF” or “SSKDF” by OpenSSL. © 2025 Red Hat, Inc. / atsec information security corporation.

8 of 48

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

9 of 48

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

10 of 48

5] © 2025 Red Hat, Inc. / atsec information security corporation.

11 of 48

The module does not offer any non-approved cryptographic algorithms that are allowed in approved services (with or without security claimed). Table 5 lists all non-approved cryptographic algorithms of the module employed by the nonapproved services in Table 10. © 2025 Red Hat, Inc. / atsec information security corporation.

12 of 48

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

Figure 1 shows a block diagram that represents the design of the module when the module is operational and providing services to other user space applications. In this diagram, the physical perimeter of the operational environment (a general-purpose computer on which the module is installed) is indicated by a purple dashed line. The cryptographic boundary is represented by the component painted in orange block, which consists only of the shared library implementing the FIPS provider (fips.so). Green lines indicate the flow of data between the cryptographic module and its operator application, through the logical interfaces defined in Section 3. Components in white are only included in the diagram for informational purposes. They are not included in the cryptographic boundary (and therefore not part of the module’s validation). For example, the kernel is responsible for managing system calls issued by the module itself, as well as other applications using the module for cryptographic services. Figure 1 – Software Block Diagram

Upon initialization, the module immediately performs all cryptographic algorithm self-tests (CASTs) as specified in Table 13. When all those self-tests pass successfully, the module automatically performs the pre-operational integrity test using the integrity value embedded in the fips.so file. Only if this integrity test also passed successfully, the module transitions to the operational state. No operator intervention is required to reach this point. The module operates in the approved mode of operation by default and can only transition into the non-approved mode by calling one of the nonapproved services listed in Table 10 of the Security Policy. © 2025 Red Hat, Inc. / atsec information security corporation.

13 of 48

In the operational state, the module accepts service requests from calling applications through its logical interfaces. At any point in the operational state, a calling application can end its process, thus causing the module to end its operation. The module supports two modes of operation:

• The approved mode of operation, in which the approved or vendor affirmed services are available as specified in Table 9.
• The non-approved mode of operation, in which the non-approved services are available as specified in Table 10. © 2025 Red Hat, Inc. / atsec information security corporation.

14 of 48

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. Table 6 summarizes the logical interfaces: Table 6 - Ports and Interfaces © 2025 Red Hat, Inc. / atsec information security corporation.

15 of 48

The module supports the Crypto Officer role only. This sole role is implicitly and always assumed by the operator of the module. No support is provided for multiple concurrent operators or a maintenance role. Table 7 lists the roles supported by the module with corresponding services with input and output parameters. © 2025 Red Hat, Inc. / atsec information security corporation.

16 of 48

Key Transport (un- RSA private key, wrapped Plaintext Key encapsulation) key Table 7 - Roles, Service Commands, Input and Output

The module does not support authentication for roles.

The module provides services to operators that assume the available role. All services are described in detail in the API documentation (manual pages). The next tables define the services that utilize approved and non-approved security functions in this module. For the respective tables, the convention below applies when specifying the access permissions (types) that the service has for each SSP.

• Generate (G): The module generates or derives the SSP.
• Read (R): The SSP is read from the module (e.g. the SSP is output).
• Write (W): The SSP is updated, imported, or written to the module.
• Execute (E): The module uses the SSP in performing a cryptographic operation.
• Zeroize (Z): The module zeroizes the SSP.
• N/A: The module does not access any SSP or key during its operation. To interact with the module, a calling application must use the EVP API layer provided by OpenSSL. This layer will delegate the request to the FIPS provider, which will in turn perform the requested service. Additionally, this EVP API layer can be used to retrieve the approved service indicator for the module. The redhat_ossl_query_fipsindicator() function indicates whether an EVP API function is approved. After a cryptographic service was performed by the module, the API context (listed in the left column of Table 8) associated with this request can contain a parameter (listed in the right column of Table 8) which represents the approved service indicator. Table 8 - Service Indicator Parameters The details to use these functions and parameters are described in the module’s manual pages. © 2025 Red Hat, Inc. / atsec information security corporation.

17 of 48

Table 9 lists the approved services in this module, the algorithms involved, the Sensitive Security Parameters (SSPs) involved and how they are accessed, the roles that can request the service, and the respective service indicator. In this table, CO specifies the Crypto Officer role. derivation VED © 2025 Red Hat, Inc. / atsec information security corporation.

18 of 48

Service HKDF Key derivation ANS X9.42 KDF Key derivation ANS X9.63 KDF Key derivation SSH KDF Key derivation TLS 1.2 KDF Key derivation

Descriptio n

Approved Security Functions HKDF ANS X9.42 KDF ANS X9.63 KDF SSH KDF TLS 1.2 KDF

Keys and/or SSPs RSA Shared secret KDA OneStep Derived key DH Shared secret ECDH Shared secret RSA Shared secret HKDF Derived key DH Shared secret ECDH Shared secret RSA Shared secret ANS X9.42 KDF Derived key DH Shared secret ECDH Shared secret RSA Shared secret ANS X9.63 KDF Derived key DH Shared secret ECDH Shared secret SSH KDF Derived key DH Shared secret ECDH Shared secret TLS 1.2 KDF Derived key

Roles

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

Indicator

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

19 of 48

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

20 of 48

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

21 of 48

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

22 of 48

Table 10 lists the non-approved services in this module, the algorithms involved, the roles that can request the service, and the respective service indicator. In this table, CO specifies the Crypto Officer Table 10 - Non-Approved Services © 2025 Red Hat, Inc. / atsec information security corporation.

23 of 48

The integrity of the module is verified by comparing a HMAC SHA-256 value calculated at run time with the HMAC SHA-256 value embedded in the fips.so file that was computed at build time.

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

24 of 48

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.2. 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 binary is 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 corporation.

25 of 48

The module is comprised of software only and therefore this section is not applicable. © 2025 Red Hat, Inc. / atsec information security corporation.

26 of 48

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

27 of 48

Table 11 summarizes the Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module in the approved services (Table 9). SSPs (including CSPs) are directly imported as input parameters and exported as output parameters from the module. Because these SSPs are only transiently used for a specific service, they are by definition exclusive between approved and non-approved services. © 2025 Red Hat, Inc. / atsec information security corporation.

28 of 48

ECDH Sha- red secret (CSP)

112-256 bits

KAS-ECC-SSC KDA OneStep HKDF ANS X9.42 KDF ANS X9.63 KDF SSH KDF TLS 1.2 KDF TLS 1.3 KDF A4807 A4813 A4814 A4823 A4824 A4825 A4826 A4837 A4838 A4839 A4840 A4841 A4844 A5578 A5579 A5585 A5586 A5587

N/A

MD/EE Import: API input pa- rameters From: Opera- tor calling ap- plication (TOEPP) To: Crypto- graphic mod- ule Export: API output pa- rameters From: Crypto- graphic mod- ule To: Operator calling appli- cation (TOEPP)

SP 800- 56Ar3 (ECDH shared secret compu- tation)

RAM

EVP_KDF_CT X_free

Use: Shared secret computation KDA OneStep Key derivation HKDF Key deri- vation ANS X9.42 KDF Key derivation ANS X9.63 KDF Key derivation SSH KDF Key derivation TLS 1.2 KDF Key derivation TLS 1.3 KDF Key derivation Related SSPs: KDA OneStep Derived key HKDF Derived key ANS X9.42 KDF Derived key

rived key rived key rived key DH private key DH public key © 2025 Red Hat, Inc. / atsec information security corporation.

29 of 48

rived key rived key rived key © 2025 Red Hat, Inc. / atsec information security corporation.

30 of 48

KDA OneStep Derived key (CSP) HKDF Deri- ved key (CSP) ANS X9.42 KDF De- rived key (CSP) ANS X9.63 KDF De- rived key (CSP) SSH KDF Derived key (CSP) TLS 1.2 KDF Derived key (CSP)

112-256 bits

KDA OneStep A4844 HKDF A4807 ANS X9.42 KDF A4813 A4814 A4823 A4824 A4825 A4826 A5578 A5585 A5587 ANS X9.63 KDF A4813 A4814 A4823 A4824 A4825 A4826 A5578 A5585 A5587 SSH KDF A4837 A4838 A4839 A4840 A4841 A5579 A5586 TLS 1.2 KDF A4813 A4823 A4824 A4825 A4826 A5578 A5585

SP 800-56Cr2 SP 800-133r2, Sec- tion 6.2 SP 800-135r1 SP 800-133r2, Sec- tion 6.2

MD/EE Import: None Export: API output pa- rameters From: Crypto- graphic mod- ule To: Operator calling appli- cation (TOEPP)

N/A

RAM

EVP_KDF_CT X_free

Use: KDA OneStep Key derivation Related SSPs: DH Shared se- cret ECDH Shared se- cret RSA Shared se- cret Use: HKDF Key deri- vation Related SSPs: DH Shared se- cret ECDH Shared se- cret RSA Shared se- cret Use: ANS X9.42 KDF Key derivation Related SSPs: DH Shared se- cret ECDH Shared se- cret RSA Shared se- cret Use: ANS X9.63 KDF Key derivation Related SSPs: DH Shared se- cret ECDH Shared se- cret RSA Shared se- cret Use: SSH KDF Key derivation Related SSPs: DH Shared se- cret ECDH Shared se- cret Use: TLS 1.2 KDF Key derivation Related SSPs: DH Shared se- cret

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

31 of 48

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

32 of 48

module tion © 2025 Red Hat, Inc. / atsec information security corporation.

33 of 48

Intermedi- ate key generation value (CSP)

112-256 bits

CKG vendor affirmed

SP 800-133r2 Sec- tion 4, 5.1, and 5.2

Import: None Export: None

N/A

RAM

Automatic

Use: Key pair genera- tion Related SSPs: DH private key DH public key EC private key EC public key RSA private key RSA public key

The module employs two Deterministic Random Bit Generator (DRBG) implementations based on SP 800-90Ar1. These DRBGs are used internally by the module (e.g. to generate seeds for asymmetric key pairs and random numbers for security functions). They can also be accessed using the specified API functions. The following parameters are used:

1. Private DRBG: AES-256 CTR_DRBG with derivation function. This DRBG is used to generate secret random values (e.g. during asymmetric key pair generation). It can be accessed using RAND_priv_bytes.
2. Public DRBG: AES-256 CTR_DRBG with derivation function. This DRBG is used to generate general purpose random values that do not need to remain secret (e.g. initialization vectors). It can be accessed using RAND_bytes. These DRBGs will always employ prediction resistance. More information regarding the configuration and design of these DRBGs can be found in the module’s manual pages. Table 12 – Non-Deterministic Random Number Generation Specification The module generates SSPs (e.g., keys) whose strengths are modified by available entropy.

800-133r2. When random values are required, they are obtained from the SP 800-90Ar1 approved DRBG, compliant with Section 4 of SP 800-133r2. The following methods are implemented:

• Safe primes key pair generation: compliant with SP 800-133r2, Section 5.2, which maps to SP 800-56Ar3. The method described in Section 5.6.1.1.4 of SP 800-56Ar3 (“Testing Candidates”) is used.
• RSA key pair generation: compliant with SP 800-133r2, Section 5.1, which maps to FIPS 186-5. The method described in Appendix A.1.6 of FIPS 186-5 (“Probable Primes with Conditions Based on Auxiliary Probable Primes”) is used. © 2025 Red Hat, Inc. / atsec information security corporation.

34 of 48

• ECC (ECDH and ECDSA) key pair generation: compliant with SP 800-133r2, Section 5.1, which maps to FIPS 186-5. The method described in Appendix A.2.2 of FIPS 186-5 (“Rejection Sampling”) is used. Additionally, the module implements the following key derivation methods:
• KBKDF: compliant with SP 800-108r1. This implementation can be used to generate secret keys from a pre-existing key-derivation-key.
• KDA OneStep, HKDF: compliant with SP 800-56Cr2.
• ANS X9.42 KDF, ANS X9.63 KDF: compliant with SP 800-135r1. These implementations shall only be used to generate secret keys in the context of an ANS X9.42-2001 resp. ANS X9.63-

• SSH KDF, TLS 1.2 KDF, TLS 1.3 KDF: compliant with SP 800-135r1. These implementations shall only be used to generate secret keys in the context of the SSH, TLS 1.2, or TLS 1.3 protocols, respectively.
• PBKDF2: compliant with option 1a of SP 800-132. This implementation shall only be used to derive keys for use in storage applications. Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service.

The module provides Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) shared secret computation compliant with SP800-56Ar3, in accordance with scenario 2 (1) of FIPS 140-3 IG D.F. For Diffie-Hellman, the module supports the use of the safe primes defined in RFC 3526 (IKE) and RFC 7919 (TLS). Note that the module only implements key pair generation, key pair verification, and shared secret computation. No other part of the IKE or TLS protocols is implemented (with the exception of the TLS 1.2 and 1.3 KDFs):

• IKE (RFC 3526):
• MODP-2048 (ID = 14)
• MODP-3072 (ID = 15)
• MODP-4096 (ID = 16)
• MODP-6144 (ID = 17)
• MODP-8192 (ID = 18)
• TLS (RFC 7919)
• ffdhe2048 (ID = 256)
• ffdhe3072 (ID = 257)
• ffdhe4096 (ID = 258)
• ffdhe6144 (ID = 259)
• ffdhe8192 (ID = 260) For Elliptic Curve Diffie-Hellman, the module supports the NIST-defined P-224, P-256, P-384, and P-

According to FIPS 140-3 IG D.B, the key sizes of DH and ECDH provide the following security strengths in the approved mode of operation:

• Diffie-Hellman shared secret computation provides between 112 and 200 bits of security strength.
• EC Diffie-Hellman shared secret computation provides between 112 and 256 bits of security strength. In addition, the module provides RSA shared secret computation compliant with SP800-56Br2, in accordance with scenario 1 (1) of FIPS 140-3 IG D.F. For RSA key generation, the module provides 2048-15360 bits keys. Therefore, according to FIPS 140-3 IG D.B, the key sizes of RSA shared secret computation provide 112-256 bits of security strength in the approved mode of operation. © 2025 Red Hat, Inc. / atsec information security corporation.

35 of 48

The module offers RSA key wrapping and unwrapping using KTS-OAEP-basic scheme. The implementation supports 2048-15360 bits modulus size, with both key encapsulation and un-encapsulation supported. The module does not implement key confirmation. See section 11.2.4 for operator guidance details. The SSP establishment methodology provides 112 to 256 bits of encryption strength. The module also supports the AES KW, AES KWP, and AES GCM key wrapping mechanisms. These algorithms can be used to wrap SSPs with a security strength between 128 and 256 bits, depending on the wrapping key size.

The module only supports SSP entry and output to and from the calling application running on the same operational environment. This corresponds to manual distribution, electronic entry/output (“CM Software to/from App via TOEPP Path”) per FIPS 140-3 IG 9.5.A Table 1. There is no entry or output of cryptographically protected SSPs. SSPs can be entered into the module via API input parameters in plaintext form, when required by a service. SSPs can also be output from the module via API output parameters, immediately after generation of the SSP (see Section 9.2).

SSPs are provided to the module by the calling application and are destroyed when released by the appropriate API function calls. The module does not perform persistent storage of SSPs.

The memory occupied by SSPs is allocated by regular memory allocation operating system calls. The operator application is responsible for calling the appropriate destruction functions provided in the module’s API. The destruction functions (listed in Table 11) overwrite the memory occupied by SSPs with zeroes and de-allocate the memory with the regular memory de-allocation operating system call. All data output is inhibited during zeroization. © 2025 Red Hat, Inc. / atsec information security corporation.

36 of 48

The module performs pre-operational self-tests and conditional self-tests. 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 does not return control to the calling application until the tests are completed. Both conditional and pre-operational self-tests can be executed on-demand by unloading and subsequently re-initializing the module. All the self-tests are listed in Table 12, with the respective condition under which those tests are performed. Note that the pre-operational integrity test is only executed after all cryptographic algorithm self-tests (CASTs) executed successfully. © 2025 Red Hat, Inc. / atsec information security corporation.

37 of 48

The module performs pre-operational tests automatically when the module is powered on. The pre-operational self-tests ensure that the module is not corrupted. The module transitions to the operational state only after the pre-operational self-tests are passed successfully. The types of pre-operational self-tests are described in the next sub-sections.

The integrity of the shared library component of the module is verified by comparing an HMAC SHA-256 value calculated at run time with the HMAC SHA-256 value embedded in the fips.so file that was computed at build time. If the software integrity test fails, the module transitions to the error state (Section 10.3). As mentioned previously, the HMAC and SHA-256 algorithms go through their respective CASTs before the software integrity test is performed.

2 According to FIPS IG 10.3.B and IG D.F scenario 1, this CAST also covers the self-test for the KAS-

IFC implementation. © 2025 Red Hat, Inc. / atsec information security corporation.

38 of 48

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 13. Data output through the data output interface is inhibited during the self-tests. If any of these tests fails, the module transitions to the error state (Section 10.3).

Upon generation of a DH, RSA or EC key pair, the module will perform a pair-wise consistency test (PCT) as shown in Table 13, which provides some assurance that the generated key pair is well formed. For DH key pairs, this test consists of the PCT described in Section 5.6.2.1.4 of SP 80056Ar3. For RSA and EC key pairs, this test consists of a signature generation and a signature verification operation. If the test fails, the module transitions to the error state (Section 10.3).

If the module fails any of the self-tests, the module enters the error state. In the error state, the module immediately stops functioning and ends the application process. Consequently, the data output interface is inhibited, and the module accepts no more inputs or requests (as the module is no longer running). Table 14 lists the error states and the status indicator values that explain the error that has occurred. Table 14 – Error States © 2025 Red Hat, Inc. / atsec information security corporation.

39 of 48

The module is distributed as a part of the Red Hat Enterprise Linux 9 (RHEL 9) package in the form of the openssl-3.0.7-18.el9_2 RPM package. Also, the module can be distributed using the opensslfips-provider-3.0.7-2.el9 RPM package.

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 installed RPM package can be uninstalled from the RHEL 9 system.

Before the RPM package is installed, the RHEL 9 system must operate in the approved mode. This can be achieved by:

• Starting the installation in the approved mode. Add the fips=1 option to the kernel command line during the system installation. During the software selection stage, do not install any third-party software. More information can be found at the vendor documentation.
• Switching the system into the approved mode after the installation. Execute the fips-modesetup –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 the approved mode by executing the fips-mode-setup --check command, which should output “FIPS mode is enabled.” After installation of the RPM package, the Crypto Officer must execute the openssl list -providers command. The Crypto Officer must ensure that the fips provider is listed in the output as follows: fips name: Red Hat Enterprise Linux 9 - OpenSSL FIPS Provider version: 3.0.7-395c1a240fbfffd8 status: active The cryptographic boundary consists only of the FIPS provider as listed. If any other OpenSSL or third-party provider is invoked, the user is not interacting with the module specified in this Security Policy. The crypto policies package provided as part of the RHEL OS should be set with no restrictions, any options selected will reduce the available services.

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. OpenSSL 3 is compliant with SP 800-52r2 Section 3.3.1 and the mechanism for IV generation is compliant with RFC 5288 and 8446. The module does not implement the TLS protocol. The module’s implementation of AES GCM is used together with an application that runs outside the module’s cryptographic boundary. The design of the TLS protocol implicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values for a given session key. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES GCM key encryption or decryption under this scenario shall be established. Alternatively, the Crypto Officer can use the module’s API to perform AES GCM encryption using internal IV generation. 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. © 2025 Red Hat, Inc. / atsec information security corporation.

40 of 48

The module also provides a non-approved AES GCM encryption service which accepts arbitrary external IVs from the operator. This service can be requested by invoking the EVP_EncryptInit_ex2 API function with a non-NULL IV value. When this is the case, the API will set a non-approved service indicator as described in Section 4.3. 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 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 80038E. 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. In compliance with IG C.I, the module implements the check to ensure that the two AES keys used in AES XTS are not identical.

The module provides password-based key derivation (PBKDF2), compliant with SP 800-132. The module supports option 1a from Section 5.4 of SP 800-132, in which the Master Key (MK) or a segment of it is used directly as the Data Protection Key (DPK). In accordance to SP 800-132 and FIPS 140-3 IG D.N, the following requirements shall be met:

• Derived keys shall only be used in storage applications. The MK shall not be used for other purposes. The length of the MK or DPK shall be of 112 bits or more.
• Passwords or passphrases, used as an input for the PBKDF2, shall not be used as cryptographic keys.
• The minimum length of the password or passphrase accepted by the module is 8 characters. This will result in a password strength equal to 108. Combined with the minimum iteration count as described below, this provides an acceptable trade-off between user experience and security against brute-force attacks.
• A portion of the salt, with a length of at least 128 bits, shall be generated randomly using the SP 800-90Ar1 DRBG provided by the module.
• The iteration count shall be selected as large as possible, as long as the time required to generate the key using the entered password is acceptable for the users. The module only allows minimum iteration count to be 1000.

To comply with the assurances found in Section 5.6.2 of SP 800-56Ar3, the operator must use the module together with an application that implements the SSH/TLS protocol. Additionally, the module’s approved key pair generation service (see Table 9) must be used to generate ephemeral Diffie-Hellman or EC Diffie-Hellman key pairs, or the key pairs must be obtained from another FIPSvalidated module. As part of this service, the module will internally perform the full public key validation of the generated public key. © 2025 Red Hat, Inc. / atsec information security corporation.

41 of 48

The module’s shared secret computation service will internally perform the full public key validation of the peer public key, complying with Sections 5.6.2.2.1 and 5.6.2.2.2 of SP 800-56Ar3.

To comply with SP800-56Br2 assurances found in its Section 6 (specifically SP800-56Br2 Section

6.4 Required Assurances) the entity using the module must obtain required assurances listed in

section 6.4 of SP 800-56Br2 by performing the following steps:

1. The entity requesting the RSA key unwrapping (un-encapsulation) service from the module, shall only use an RSA private key that was generated by an active FIPS validated module that implements FIPS 186-5 compliant RSA key generation service and performs the key pair validity and the pairwise consistency as stated in section 6.4.1.1 of the SP 800-56Br2. Additionally, the entity shall renew these assurances over time by using any method described in section 6.4.1.5 of the SP 800-56Br2.
2. For use of an RSA key wrapping (encapsulation) service in the context of key transport per IG D.G the entity using the module shall: a. verify the validity of the peer’s public key using the public key validation service of the module (EVP_PKEY_check() API). b. confirm the peer’s possession of private key by using any method specified in section

Only after the above assurances are successfully met, shall the entity use the peer’s public key to perform the RSA key wrapping (encapsulation) service of the module.

To comply with the assurances found in Section 6.4 of SP 800-56Br2, the module’s approved RSA key pair generation service (see Table 9) must be used to generate the RSA key pairs, or the key pairs must be obtained from another FIPS-validated module. As part of this service, the module will internally perform the key pair validity and the pairwise consistency according to section 6.4.1.1 of SP 800-56Br2. Additionally, the entity requesting the shared secret computation service shall verify the validity of the peer’s public key using the public key validation service of the module (EVP_PKEY_check() API). This service will perform the full public key validation of the peer’s public key, complying with Section 6.4.2.1 of SP 800-56Br2. © 2025 Red Hat, Inc. / atsec information security corporation.

42 of 48

Certain cryptographic subroutines and algorithms are vulnerable to timing analysis. The module mitigates this vulnerability by using constant-time implementations. This includes, but is not limited to:

• Big number operations: computing GCDs, modular inversion, multiplication, division, and modular exponentiation (using Montgomery multiplication)
• Elliptic curve point arithmetic: addition and multiplication (using the Montgomery ladder)
• Vector-based AES implementations In addition, RSA, ECDSA, ECDH, and DH employ blinding techniques to further impede timing and power analysis. No configuration is needed to enable the aforementioned countermeasures. © 2025 Red Hat, Inc. / atsec information security corporation.

43 of 48

Appendix A. Glossary and abbreviations AES          Advanced Encryption Standard AES-NI       Advanced Encryption Standard New Instructions API          Application Programming Interface CAST         Cryptographic Algorithm Self-Test 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 CSP          Critical Security Parameter CTR          Counter CTS          Ciphertext Stealing DH           Diffie-Hellman DRBG         Deterministic Random Bit Generator ECB          Electronic Code Book ECC          Elliptic Curve Cryptography ECDH         Elliptic Curve Diffie-Hellman ECDSA        Elliptic Curve Digital Signature Algorithm EVP          Envelope FFC          Finite Field Cryptography FIPS         Federal Information Processing Standards GCM          Galois Counter Mode GMAC         Galois Counter Mode Message Authentication Code HKDF         HMAC-based Key Derivation Function HMAC         Keyed-Hash Message Authentication Code IKE          Internet Key Exchange KAS          Key Agreement Scheme KAT          Known Answer Test KBKDF        Key-based Key Derivation Function KTS          Key Transport Scheme KW           Key Wrap KWP          Key Wrap with Padding MAC          Message Authentication Code NIST         National Institute of Science and Technology OAEP         Optimal Asymmetric Encryption Padding OFB          Output Feedback © 2025 Red Hat, Inc. / atsec information security corporation.

44 of 48

PAA          Processor Algorithm Acceleration PCT          Pair-wise Consistency Test PBKDF2       Password-based Key Derivation Function v2 PKCS         Public-Key Cryptography Standards PSS          Probabilistic Signature Scheme RSA          Rivest, Shamir, Addleman SHA          Secure Hash Algorithm SSC          Shared Secret Computation SSH          Secure Shell SSP          Sensitive Security Parameter TLS          Transport Layer Security XOF          Extendable Output Function XTS          XEX-based Tweaked-codebook mode with cipher text Stealing © 2025 Red Hat, Inc. / atsec information security corporation.

45 of 48