Red Hat Enterprise Linux 9 OpenSSL FIPS Provider

Certificate

Approved Algorithms (321)

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.1-3f45e68ee408cd9c document version 1.2 Last update: 2024-06-14 Prepared by: atsec information security corporation

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

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

This document is the non-proprietary FIPS 140-3 Security Policy for version 3.0.13f45e68ee408cd9c 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 Security Level 1 module. and including this notice. Other documentation is proprietary to their authors.

was further consolidated into this document by atsec information security together with other vendor-supplied documentation. 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. ISO/IEC 24759 Section 6. [Number FIPS 140-3 Section Title Security Level Below]

1 General 1

2 Cryptographic Module Specification 1

3 Cryptographic Module Interfaces 1

4 Roles, Services, and Authentication 1

5 Software/Firmware Security 1

6 Operational Environment 1

7 Physical Security Not Applicable

8 Non-invasive Security Not Applicable

9 Sensitive Security Parameter Management 1

10 Self-tests 1

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

11 Life-cycle Assurance 1

12 Mitigation of Other Attacks 1

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

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 configuration options with and without PAA: # Operating System Hardware Platform Processor PAA/ Acceleration

1 Red Hat Enterprise Dell PowerEdge R440 Intel(R) Xeon(R) Silver AES-NI, SHA

2 Red Hat Enterprise IBM z16 3931-A01 IBM z16 CPACF

3 Red Hat Enterprise IBM 9080 HEX IBM POWER10 ISA

Linux 9 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. # Operating System Hardware Platform

1 Red Hat Enterprise Linux 9 Intel(R) Xeon(R) E5

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-3 IG C.F. © 2024 Red Hat, Inc. / atsec information security corporation.

CAVP Algorithm and Mode / Method Description / Key Size(s) Use / Function Cert / Key Strengths Standard A3544 SHA [FIPS 180-4] SHA-1, SHA-224, SHA-256, N/A Message digest A3545 SHA-384, SHA-512, SHAA3546 512/224, SHA-512/256 A3547 A4022 A4459 A3534 SHA-3 [FIPS 202] SHA3-224, SHA3-256, SHA3- N/A Message digest A4024 384, SHA3-512 SHA-3 [FIPS 202] SHAKE128, SHAKE256 N/A XOF A3527 AES [FIPS 197, SP ECB, CBC, CBC-CTS-CS1, 128, 192, 256 bits with 128, Encryption A3528 800-38A, SP 800- CBC-CTS-CS2, CBC-CTS-CS3, 192, 256 bits of security Decryption A3529 38A Addendum, CFB1, CFB8, CFB128, CTR, strength A4018 SP 800-38C, SP OFB, CCM A4023 800-38F] KW, KWP (KTS) A4460 A4461 A4465 A3535 AES [FIPS 197, SP GCM (internal IV) 128, 192, 256 bits with 128, Encryption A3536 800-38D] 192, 256 bits of security A3537 strength A3538 A3539 AES [FIPS 197, SP GCM (external IV) 128, 192, 256 bits with 128, Decryption A3540 800-38D] 192, 256 bits of security A3541 strength A3542 A3543 A4019 A4020 A4021 A4458 A4462 A3527 AES [FIPS 197, SP XTS 128, 256 bits with 128, 256 Encryption A3528 800-38E] bits of security strength Decryption A3529 A4018 AES [FIPS 197, SP CMAC 128, 192, 256 bits with 128, Message A4461 800-38B] 192, 256 bits of security authentication A4465 strength © 2024 Red Hat, Inc. / atsec information security corporation.

CAVP Algorithm and Mode / Method Description / Key Size(s) Use / Function Cert / Key Strengths Standard A3535 AES [FIPS 197, SP GMAC 128, 192, 256 bits with 128, Message A3536 800-38D] 192, 256 bits of security authentication A3537 strength A3538 A3539 A3540 A3541 A3542 A3543 A4019 A4020 A4021 A4458 A4462 A3544 HMAC [FIPS 198- SHA-1, SHA-224, SHA-256, 112-524288 bits with 112-256 Message A3545 1] SHA-384, SHA-512, SHA- bits of security strength authentication A3546 512/224, SHA-512/256 A3547 A4022 A4459 A3534 SHA3-224, SHA3-256, SHA3A4024 384, SHA3-512 A3553 KBKDF [SP 800- Counter and feedback 112-4096 bits with 112-256 KBKDF Key 108r1] mode, using CMAC and bits of security strength derivation HMAC SHA-1, SHA-224, SHA-256, SHA-384, SHA512, SHA-512/224, SHA512/256, SHA3-224, SHA3256, SHA3-384, SHA3-512 A3525 KDA OneStep1 [SP (HMAC) SHA-1, SHA-224, 224-8192 bits with 112-256 KDA OneStep Key 800-56Cr2] SHA-256, SHA-384, SHA- bits of security strength derivation 512, SHA-512/224, SHA512/256, SHA3-224, SHA3256, SHA3-384, SHA3-512 A3526 HKDF [SP 800- SHA-1, SHA-224, SHA-256, 224-8192 bits with 112-256 HKDF Key derivation 56Cr2] SHA-384, SHA-512, SHA- bits of security strength 512/224, SHA-512/256, SHA3-224, SHA3-256, SHA3384, SHA3-512 A3534 ANS X9.42 KDF AES KW with SHA-1, SHA- 224-8192 bits with 112-256 ANS X9.42 KDF Key A3544 [SP 800-135r1] 224, SHA-256, SHA-384, bits of security strength derivation A3545 CVL SHA-512, SHA-512/224, A3546 SHA-512/256, SHA3-224, A3547 SHA3-256, SHA3-384, SHA3A4022 512 1This algorithm is referred to as “Single Step KDF” or “SSKDF” by OpenSSL. © 2024 Red Hat, Inc. / atsec information security corporation.

CAVP Algorithm and Mode / Method Description / Key Size(s) Use / Function Cert / Key Strengths Standard A4024 ANS X9.63 KDF SHA-224, SHA-256, SHA- 224-8192 bits with 112-256 ANS X9.63 KDF Key A4459 [SP 800-135r1] 384, SHA-512, SHA- bits of security strength derivation CVL 512/224, SHA-512/256, SHA3-224, SHA3-256, SHA3384, SHA3-512 A3530 SSH KDF [SP 800- AES-128, AES-192, AES-256 224-8192 bits with 112-256 SSH KDF Key A3531 135r1] with SHA-1, SHA-224, SHA- bits of security strength derivation A3532 CVL 256, SHA-384, SHA-512 A3533 A4023 A4460 A3544 TLS 1.2 KDF [SP SHA-256, SHA-384, SHA-512 224-8192 bits with 112-256 TLS 1.2 KDF Key A3545 800-135r1] bits of security strength derivation A3546 CVL A3547 A4022 A4459 A3526 TLS 1.3 KDF [RFC SHA-256, SHA-384 224-8192 bits with 112-256 TLS 1.3 KDF Key 8446] bits of security strength derivation CVL A3534 PBKDF2 [SP 800- Option 1a with SHA-1, SHA- 8-128 characters with Password-based key A3544 132] 224, SHA-256, SHA-384, password strength between derivation A3545 SHA-512, SHA-512/224, 108 and 10128 A3546 SHA-512/256, SHA3-224, A3547 SHA3-256, SHA3-384, SHA3A4022 512 A4024 A4459 A3570 CTR_DRBG [SP AES-128, AES-192, AES-256, 256, 320, 384 bits with 128, Random number 800-90Ar1] with/without derivation 192, 256 bits of security generation function, with/without strength prediction resistance A3570 Hash_DRBG [SP SHA-1, SHA-256, SHA-512 880, 1776 bits with 128, 256 Random number 800-90Ar1] with/without prediction bits of security strength generation resistance A3570 HMAC_DRBG [SP SHA-1, SHA-256, SHA-512 320, 512, 1024 bits with 128, Random number 800-90Ar1] with/without prediction 256 bits of security strength generation resistance A3554 KAS-FFC-SSC [SP dhEphem MODP-2048, MODP-3072, Shared secret 800-56Ar3] (initiator/responder) MODP-4096, MODP-6144, computation MODP-8192, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192 with 112-200 bits of security strength © 2024 Red Hat, Inc. / atsec information security corporation.

CAVP Algorithm and Mode / Method Description / Key Size(s) Use / Function Cert / Key Strengths Standard A3544 KAS-ECC-SSC [SP Ephemeral Unified Model P-224, P-256, P-384, P-521 Shared secret A3545 800-56Ar3] (initiator/responder) with 112, 128, 192, 256 bits of computation A3546 security strength A3547 A4022 RSA [FIPS 186-4] PKCS#1 v1.5 and PSS with 2048-16384 bits with 112-256 Signature A4459 SHA-224, SHA-256, SHA- bits of security strength generation 384, SHA-512, SHARSA [FIPS 186-4] 512/224, SHA-512/256, NIST SP 800-131Ar2 Legacy Signature SHA3-224, SHA3-256, SHA3- use: 1024-2047 bits with 80- verification 384, SHA3-512 111 bits of security strength NIST SP 800-131Ar2 Acceptable: 2048-16384 bits with 112-256 bits of security strength A3534 ECDSA [FIPS 186- SHA-224, SHA-256, SHA- P-224, P-256, P-384, P-521 Signature A3544 4] 384, SHA-512, SHA- with 112, 128, 192, 256 bits of generation A3545 512/224, SHA-512/256, security strength A3546 ECDSA [FIPS 186- SHA3-224, SHA3-256, SHA3- Signature A3547 4] 384, SHA3-512 verification A4022 A4024 A4459 A3554 Safe primes [SP SP 800-56Ar3 Section MODP-2048, MODP-3072, Key pair generation 800-56Ar3] 5.6.1.1.4 Testing MODP-4096, MODP-6144, Candidates MODP-8192, ffdhe2048, ffdhe3072, ffdhe4096, A3554 Safe primes [SP SP 800-56Ar3 Sections ffdhe6144, ffdhe8192 with Key pair verification 800-56Ar3] 5.6.2.1.2 and 5.6.2.1.4 112-200 bits of security strength A3544 RSA [FIPS 186-4] FIPS 186-4 Appendix B.3.6 2048-15360 bits with 112-256 Key pair generation A3545 Probable Primes with bits of security strength A3546 Conditions Based on A3547 Auxiliary Probable Primes A4022 A4459 ECDSA [FIPS 186- FIPS 186-4 Appendix B.4.2 P-224, P-256, P-384, P-521 Key pair generation 4] Testing Candidates with 112, 128, 192, 256 bits of security strength ECDSA [FIPS 186- N/A Key pair verification 4] Vendor CKG [SP 800- Safe primes MODP-2048, MODP-3072, Key pair generation affirme 133r2 Section 4] MODP-4096, MODP-6144, d MODP-8192, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192 with 112-200 bits of security strength RSA 2048-16384 bits with 112-256 bits of security strength © 2024 Red Hat, Inc. / atsec information security corporation.

CAVP Algorithm and Mode / Method Description / Key Size(s) Use / Function Cert / Key Strengths Standard ECDSA P-224, P-256, P-384, P-521 with 112, 128, 192, 256 bits of security strength Vendor RSA [FIPS 186-4] RSA PKCS#1 v1.5 and PSS 2048-16384 bits with 112-256 Signature affirme SHA-3 [FIPS 202] with SHA3-224, SHA3-256, bits of security strength generation d SHA3-384, SHA3-512 [FIPS 140-3 IG NIST SP 800-131Ar2 Legacy Signature C.C] use: 1024-2047 bits with 80- verification

NIST SP 800-131Ar2 Acceptable: 2048-16384 bits with 112-256 bits of security strength Table 4 - Approved Algorithms

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. Algorithm / Functions Use / Function AES GCM (external IV) Encryption HMAC (< 112-bit keys) Message authentication KBKDF, KDA OneStep, HKDF, ANS X9.42 KDF, ANS X9.63 KDF (< 112-bit keys) KBKDF Key derivation KDA OneStep Key derivation HKDF Key derivation ANS X9.42 KDF Key derivation ANS X9.63 KDF Key derivation KDA OneStep (SHAKE128, SHAKE256) KDA OneStep Key derivation ANS X9.42 KDF (SHAKE128, SHAKE256) ANS X9.42 KDF Key derivation ANS X9.63 KDF (SHA-1, SHAKE128, SHAKE256) ANS X9.63 KDF Key derivation SSH KDF (SHA-512/224, SHA-512/256, SHA-3, SHAKE128, SHAKE256) SSH KDF Key derivation TLS 1.2 KDF (SHA-1, SHA-224, SHA-512/224, SHA-512/256, SHA-3) TLS 1.2 KDF Key derivation TLS 1.3 KDF (SHA-1, SHA-224, SHA-512, SHA-512/224, SHA-512/256, SHA-3) TLS 1.3 KDF Key derivation © 2024 Red Hat, Inc. / atsec information security corporation.

PBKDF2 (short password; short salt; insufficient iterations; < 112-bit keys) Password-based key derivation KAS1, KAS2 Shared secret computation RSA and ECDSA (pre-hashed message) Signature generation Signature verification RSA-PSS (invalid salt length) RSA-OAEP Asymmetric encryption Asymmetric decryption 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. © 2024 Red Hat, Inc. / atsec information security corporation.

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 non-approved services listed in Table 10 of the Security Policy. 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. © 2024 Red Hat, Inc. / atsec information security corporation.

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: Physical Port Logical Interface Data that passes over port / interface As a software-only module, the Data Input API input parameters module does not have physical ports. API output parameters Physical Ports are interpreted to be Data Output the physical ports of the hardware Control Input API function calls platform on which it runs. Status Output API return codes, error queue Table 6 - Ports and Interfaces The module does not implement a control output interface. © 2024 Red Hat, Inc. / atsec information security corporation.

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. Role Service Input Output Crypto Message digest Message Digest value Officer XOF Message, output length Digest value Encryption Plaintext, AES key Ciphertext Decryption Ciphertext, AES key Plaintext Message authentication Message, AES key or HMAC MAC tag key KBKDF Key derivation Key-derivation key KBKDF Derived key KDA OneStep Key Shared secret KDA OneStep Derived key derivation HKDF Key derivation Shared secret HKDF Derived key ANS X9.42 KDF Key Shared secret ANS X9.42 KDF Derived key derivation ANS X9.63 KDF Key Shared secret ANS X9.63 KDF Derived key derivation SSH KDF Key derivation Shared secret SSH KDF Derived key TLS 1.2 KDF Key derivation Shared secret TLS 1.2 KDF Derived key TLS 1.3 KDF Key derivation Shared secret TLS 1.3 KDF Derived key Password-based key Password, salt, iteration PBKDF2 Derived key derivation count Random number Output length Random bytes generation Shared secret computation Owner private key, peer Shared secret public key Signature generation Message, private key Signature Signature verification Message, public key, Pass/fail signature Asymmetric encryption Plaintext, public key Ciphertext Asymmetric decryption Ciphertext, private key Plaintext Key pair generation Key size Key pair Key pair verification Key pair Pass/fail © 2024 Red Hat, Inc. / atsec information security corporation.

Show version N/A Name and version information Show status N/A Module status Self-test N/A Pass/fail results of self-tests Zeroization Any SSP N/A 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 associated with this request can contain a parameter (listed in Table 8) which represents the approved service indicator. Context Service Indicator EVP_CIPHER_C OSSL_CIPHER_PARAM_REDHAT_FIPS_INDICATOR TX EVP_MAC_CTX OSSL_MAC_PARAM_REDHAT_FIPS_INDICATOR EVP_KDF_CTX OSSL_KDF_PARAM_REDHAT_FIPS_INDICATOR EVP_PKEY_CTX OSSL_SIGNATURE_PARAM_REDHAT_FIPS_INDICATOR EVP_PKEY_CTX OSSL_ASYM_CIPHER_PARAM_REDHAT_FIPS_INDICATOR Table 8 - Service Indicator Parameters The details to use these functions and parameters are described in the module’s manual pages. 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. © 2024 Red Hat, Inc. / atsec information security corporation.

Service Description Approved Keys and/or Roles Access Indicator Security SSPs rights Functions to Keys and/or SSPs Message Compute a SHA-1, SHA-224, N/A CO N/A EVP_DigestFinal_ex digest message SHA-256, SHA-384, returns 1 digest SHA-512, SHA512/224, SHA512/256, SHA3-224, SHA3-256, SHA3384, SHA3-512 XOF Compute the SHAKE128, N/A CO N/A EVP_DigestFinalXOF output of an SHAKE256 returns 1 XOF Encryption Encrypt a AES ECB, CBC, CBC- AES key CO W, E AES GCM: plaintext CTS-CS1, CBC-CTS- EVP_CIPHER_REDHAT_FI CS2, CBC-CTS-CS3, PS_INDICATOR_APPROVE D CFB1, CFB8, CFB128, CTR, OFB, Others: CCM, KW, KWP, EVP_EncryptFinal_ex returns 1 GCM, XTS Decryption Decrypt a CO W, E AES GCM: ciphertext EVP_CIPHER_REDHAT_FI PS_INDICATOR_APPROVE D Others: EVP_DecryptFinal_ex returns 1 Message Compute a AES CMAC AES key CO W, E HMAC: authenticatio MAC tag OSSL_MAC_PARAM_RED AES GMAC HMAC key HAT_FIPS_INDICATOR_AP n HMAC SHA-1, HMAC PROVED SHA-224, HMAC Others: EVP_MAC_final SHA-256, HMAC returns 1 SHA-384, HMAC SHA-512, HMAC SHA-512/224, HMAC SHA-512/256, HMAC SHA3-224, HMAC SHA3-256, HMAC SHA3-384, HMAC SHA3-512 KBKDF Key Derive a key KBKDF Key-derivation key CO W, E EVP_KDF_REDHAT_FIPS_I derivation from a key- NDICATOR_APPROVED derivation key KBKDF Derived key G, R KDA OneStep Derive a key KDA OneStep DH Shared secret W, E Key from a shared derivation secret ECDH Shared secret KDA OneStep G, R Derived key HKDF Key HKDF DH Shared secret W, E derivation ECDH Shared secret © 2024 Red Hat, Inc. / atsec information security corporation.

Service Description Approved Keys and/or Roles Access Indicator Security SSPs rights Functions to Keys and/or SSPs HKDF Derived key G, R ANS X9.42 ANS X9.42 KDF DH Shared secret W, E KDF Key derivation ECDH Shared secret ANS X9.42 KDF G, R Derived key ANS X9.63 ANS X9.63 KDF DH Shared secret W, E KDF Key derivation ECDH Shared secret ANS X9.63 KDF G, R Derived key SSH KDF Key SSH KDF DH Shared secret W, E derivation ECDH Shared secret SSH KDF Derived G, R key TLS 1.2 KDF TLS 1.2 KDF DH Shared secret W, E Key derivation ECDH Shared secret TLS 1.2 KDF G, R Derived key TLS 1.3 KDF TLS 1.3 KDF DH Shared secret W, E Key derivation ECDH Shared secret TLS 1.3 KDF G, R Derived key Password- Derive a key PBKDF2 Password CO W, E EVP_KDF_REDHAT_FIPS_I based key from a NDICATOR_APPROVED derivation password PBKDF2 Derived G, R key Random Generate CTR_DRBG Entropy input CO W, E EVP_RAND_generate number random bytes returns 1 generation DRBG seed E, G Internal state (V, W, E, G Key) Hash_DRBG Entropy input W, E DRBG seed E, G Internal state (V, C) W, E, G HMAC_DRBG Entropy input W, E DRBG seed E, G © 2024 Red Hat, Inc. / atsec information security corporation.

Service Description Approved Keys and/or Roles Access Indicator Security SSPs rights Functions to Keys and/or SSPs Internal state (V, W, E, G Key) Shared Compute a KAS-FFC-SSC DH private key CO W, E EVP_PKEY_derive returns secret shared secret (owner), DH public 1 computation key (peer) DH Shared secret G, R KAS-ECC-SSC EC private key W, E (owner), EC public key (peer) ECDH Shared G, R secret Signature Generate a RSA signature RSA private key CO W, E RSA: generation signature generation/verificati EC private key OSSL_RH_FIPSINDICATO on (PKCS#1 v1.5 R_APPROVED and Signature Verify a EVP_SIGNATURE_REDHA and PSS) RSA public key CO W, E T_FIPS_INDICATOR_APPR verification signature ECDSA signature EC public key OVED generation/verificati ECDSA: on OSSL_RH_FIPSINDICATO R_APPROVED Key pair Generate a CKG DH private key, DH CO G, R EVP_PKEY_generate generation key pair public key returns 1 CTR_DRBG, Hash_DRBG, RSA private key, HMAC_DRBG RSA public key Safe primes key pair EC private key, EC generation public key RSA key pair Intermediate key generation generation value ECDSA key pair generation Key pair Verify a key Safe primes key pair DH private key, DH CO W, E EVP_PKEY_public_check verification pair verification public key or EVP_PKEY_private_check ECDSA key pair EC private key, EC or EVP_PKEY_check verification public key returns 1 Show version Return the N/A N/A CO N/A None name and version information Show status Return the N/A N/A CO N/A None module status © 2024 Red Hat, Inc. / atsec information security corporation.

Service Description Approved Keys and/or Roles Access Indicator Security SSPs rights Functions to Keys and/or SSPs Self-test Perform the SHA-1, SHA-224, SHA- AES key CO E None CASTs and 256, SHA-512, SHA3- HMAC key integrity test 256 Key-derivation key AES ECB, KW, GCM Password HMAC DH private key, DH KBKDF, KDA OneStep, public key HKDF, ANS X9.42 KDF, RSA private key, ANS X9.63 KDF, SSH RSA public key KDF, TLS 1.2 KDF, TLS

public key PBKDF2 CTR_DRBG, DH Shared secret E, G Hash_DRBG, ECDH Shared HMAC_DRBG secret KAS-FFC-SSC, KAS- KBKDF Derived key ECC-SSC KDA OneStep RSA (PKCS#1 v1.5) Derived key ECDSA HKDF Derived key See Table 13 for ANS X9.42 KDF specifics Derived key ANS X9.63 KDF Derived key SSH KDF Derived key TLS 1.2 KDF Derived key TLS 1.3 KDF Derived key PBKDF2 Derived key DRBG seed Internal state (V, Key) Internal state (V, C) Zeroization Zeroize all N/A Any SSP CO Z None SSPs Table 9 - Approved Services 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 role. Service Description Algorithms Accessed Role Encryption Encrypt a AES GCM (external IV) CO plaintext © 2024 Red Hat, Inc. / atsec information security corporation.

Service Description Algorithms Accessed Role Message Compute a MAC HMAC (< 112-bit keys) CO authenticatio tag n KBKDF Key Derive a key KBKDF (< 112-bit keys) CO derivation from a keyderivation key KDA OneStep Derive a key KDA OneStep (< 112-bit keys) Key from a shared KDA OneStep (SHAKE128, SHAKE256) derivation secret HKDF Key HKDF (< 112-bit keys) derivation ANS X9.42 ANS X9.42 KDF (< 112-bit keys) KDF Key ANS X9.42 KDF (SHAKE128, SHAKE256) derivation ANS X9.63 ANS X9.63 KDF (< 112-bit keys) KDF Key ANS X9.63 KDF (SHA-1, SHAKE128, SHAKE256) derivation SSH KDF Key SSH KDF (< 112-bit keys) derivation SSH KDF (SHA-512/224, SHA-512/256, SHA-3, SHAKE128, SHAKE256) TLS 1.2 KDF TLS 1.2 KDF (< 112-bit keys) Key TLS 1.2 KDF (SHA-1, SHA-224, SHA-512/224, SHA-512/256, SHAderivation 3) TLS 1.3 KDF TLS 1.3 KDF (< 112-bit keys) Key TLS 1.3 KDF (SHA-1, SHA-224, SHA-512, SHA-512/224, SHAderivation 512/256, SHA-3) Password- Derive a key PBKDF2 (short password; short salt; insufficient iterations; < CO based key from a password 112-bit keys) derivation Shared Compute a KAS1, KAS2 CO secret shared secret computation Signature Generate a RSA and ECDSA signature generation/verification (pre-hashed CO generation signature message) Signature Verify a CO verification signature Asymmetric Encrypt a RSA-OAEP encryption/decryption CO encryption plaintext Asymmetric Decrypt a CO decryption plaintext Table 10 - Non-Approved Services © 2024 Red Hat, Inc. / atsec information security corporation.

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

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

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

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

Table 10 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. Key / Strength Security Generation Import / Esta Stor Zeroiza Use and SSP Function Export blish age tion related Name / and Cert. ment keys Type Number AES key AES-XTS: 128, AES N/A MD/EE N/A RAM EVP_CIPHER Use: (CSP) 256 bits AES CMAC _CTX_free Encryption Rest of AES GMAC EVP_MAC_C Decryption Import: modes: 128, A3527, A3528, TX_free 192, 256 bits A3529, A3535, API input Message A3536, A3537, parameters authentication A3538, A3539, From: Related SSPs: A3540, A3541, Operator None A3542, A3543, calling A4018, A4019, application A4020, A4021, (TOEPP) A4023, A4458, To: A4460, A4461, Cryptographic A4462, A4465 module Export: None HMAC key 112-256 bits HMAC N/A MD/EE N/A RAM EVP_MAC_C Use: (CSP) A3534, A3544, TX_free Message A3545, A3546, Import: authentication A3547, A4022, Related SSPs: A4024, A4459 API input parameters None From: Operator calling application (TOEPP) To: Cryptographic module Export: None Key- 112-256 bits KBKDF N/A MD/EE N/A RAM EVP_KDF_CT Use: derivation A3553 X_free KBKDF Key key (CSP) derivation Import: API input Related SSPs: parameters KBKDF Derived key From: Operator calling application (TOEPP) To: Cryptographic module © 2024 Red Hat, Inc. / atsec information security corporation.

Export: None DH Shared 112-256 bits KAS-FFC-SSC N/A MD/EE SP 800- RAM EVP_KDF_CT Use: secret (CSP) A3554 56Ar3 X_free Shared secret (DH computation Import: shared KDA OneStep KDA OneStep HKDF API input secret parameters comput Key derivation ANS X9.42 KDF ANS X9.63 KDF From: ation) HKDF Key SSH KDF Operator derivation TLS 1.2 KDF calling ANS X9.42 KDF TLS 1.3 KDF application Key derivation A3525, A3526, (TOEPP) ANS X9.63 KDF A3530, A3531, To: Key derivation A3532, A3533, Cryptographic SSH KDF Key A3534, A3544, module derivation A3545, A3546, A3547, A3553, TLS 1.2 KDF Key A4022, A4023, Export: derivation A4024, A4459, API output TLS 1.3 KDF Key A4460 parameters derivation From: Related SSPs: Cryptographic KDA OneStep module Derived key To: Operator HKDF Derived calling key application (TOEPP) ANS X9.42 KDF Derived key ANS X9.63 KDF Derived key SSH KDF Derived key TLS 1.2 KDF Derived key TLS 1.3 KDF Derived key DH private key DH public key ECDH Shared 112-256 bits KAS-ECC-SSC N/A MD/EE SP 800- RAM EVP_KDF_CT Use: secret (CSP) KDA OneStep 56Ar3 X_free Shared secret HKDF (ECDH computation ANS X9.42 KDF Import: shared ANS X9.63 KDF API input secret KDA OneStep SSH KDF parameters comput Key derivation TLS 1.2 KDF From: ation) HKDF Key TLS 1.3 KDF Operator derivation A3525, A3526, calling ANS X9.42 KDF A3530, A3531, application Key derivation A3532, A3533, (TOEPP) ANS X9.63 KDF A3534, A3544, To: Key derivation A3545, A3546, Cryptographic A3547, A3553, SSH KDF Key module derivation A4022, A4023, A4024, A4459, TLS 1.2 KDF Key A4460 Export: derivation API output TLS 1.3 KDF Key parameters derivation From: Related SSPs: Cryptographic KDA OneStep module Derived key To: Operator HKDF Derived © 2024 Red Hat, Inc. / atsec information security corporation.

calling key application ANS X9.42 KDF (TOEPP) Derived key ANS X9.63 KDF Derived key SSH KDF Derived key TLS 1.2 KDF Derived key TLS 1.3 KDF Derived key EC private key EC public key Password Password PBKDF2 N/A MD/EE N/A RAM EVP_KDF_CT Use: (CSP) strength: 108 - A3534, A3544, X_free Password-based

10128 A3545, A3546, key derivation

Import: A3547, A4022, Related SSPs: A4024, A4459 API input parameters PBKDF2 Derived key From: Operator calling application (TOEPP) To: Cryptographic module Export: None KBKDF 112-256 bits KBKDF SP 800-133r2, MD/EE N/A RAM EVP_KDF_CT Use: Derived key A3553 Section 6.2 X_free KBKDF Key (CSP) derivation Import: None Related SSPs: Export: Key-derivation key API output KDA OneStep KDA OneStep parameters Use: Derived key A3525 KDA OneStep (CSP) From: Cryptographic Key derivation module Related SSPs: To: Operator DH Shared calling secret application ECDH Shared (TOEPP) secret HKDF HKDF Use: Derived key A3526 HKDF Key (CSP) derivation Related SSPs: DH Shared secret ECDH Shared secret ANS X9.42 ANS X9.42 KDF Use: KDF Derived A3534 A3544 ANS X9.42 KDF key (CSP) A3545 A3546 Key derivation A3547 A4022 Related SSPs: A4024 A4459 DH Shared secret © 2024 Red Hat, Inc. / atsec information security corporation.

ECDH Shared secret ANS X9.63 ANS X9.63 KDF Use: KDF Derived A3534 A3544 ANS X9.63 KDF key (CSP) A3545 A3546 Key derivation A3547 A4022 Related SSPs: A4024 A4459 DH Shared secret ECDH Shared secret SSH KDF SSH KDF Use: Derived key A3530 A3531 SSH KDF Key (CSP) A3532 A3533 derivation A4023 A4460 Related SSPs: DH Shared secret ECDH Shared secret TLS 1.2 KDF TLS 1.2 KDF Use: Derived key A3544 A3545 TLS 1.2 KDF Key (CSP) A3546 A3547 derivation A4022 A4459 Related SSPs: DH Shared secret ECDH Shared secret TLS 1.3 KDF TLS 1.3 KDF Use: Derived key A3526 TLS 1.3 KDF Key (CSP) derivation Related SSPs: DH Shared secret ECDH Shared secret PBKDF2 PBKDF2 Use: Derived key A3534 A3544 Password-based (CSP) A3545 A3546 key derivation A3547 A4022 Related SSPs: A4024 A4459 Password Entropy input 112-336 bits CTR_DRBG N/A Import: None N/A RAM EVP_RAND_ Use: (CSP) Hash_DRBG Export: None CTX_free Random number HMAC_DRBG generation A3570 Related SSPs: DRBG seed DRBG seed CTR_DRBG: CTR_DRBG Import: None N/A RAM EVP_RAND_ Use: (CSP) 128, 192, 256 Hash_DRBG Export: None CTX_free Random number IG D.L bits HMAC_DRBG generation compliant Hash_DRBG: Related SSPs: 128, 256 bits Entropy input HMAC_DRBG: 128, 256 bits Internal state (V, Key) Internal state (V, C) Internal state CTR_DRBG CTR_DRBG Import: None N/A RAM EVP_RAND_ Use: (V, Key) HMAC_DRBG HMAC_DRBG Export: None CTX_free Random number (CSP) A3570 generation IG D.L © 2024 Red Hat, Inc. / atsec information security corporation.

compliant Related SSPs: DRBG seed Internal state Hash_DRBG Hash_DRBG (V, C) (CSP) A3570 IG D.L compliant DH private 112-200 bits KAS-FFC-SSC SP 800-56Ar3 (safe MD/EE N/A RAM EVP_PKEY_fr Use: key (CSP) A3554 primes) Section ee Shared secret

Candidates Import: API input Key pair parameters generation From: Key pair Operator verification calling Related SSPs: application DH public key (TOEPP) Intermediate To: key generation Cryptographic value module DH public 112-200 bits Use: key (PSP) Shared secret Export: computation API output Key pair parameters generation From: Key pair Cryptographic verification module Related SSPs: To: Operator calling DH private key application Intermediate (TOEPP) key generation value EC private 112, 128, 192, KAS-ECC-SSC FIPS 186-4 MD/EE N/A RAM EVP_PKEY_fr Use: key (CSP) 256 bits ECDSA Appendix B.4.2 ee Shared secret A3534, A3544, Testing Candidates computation Import: A3545, A3546, Signature A3547, A4022, API input parameters generation A4024, A4459 From: Key pair Operator generation calling Key pair application verification (TOEPP) Related SSPs: To: EC public key Cryptographic module Intermediate key generation value EC public key 112, 128, 192, Export: Use: (PSP) 256 bits API output Shared secret parameters computation From: Signature Cryptographic verification module Key pair To: Operator generation calling application Key pair (TOEPP) verification Related SSPs: EC private key Intermediate key generation © 2024 Red Hat, Inc. / atsec information security corporation.

value RSA private 112-256 bits RSA FIPS 186-4 MD/EE N/A RAM EVP_PKEY_fr Use: key (CSP) A3544, A3545 Appendix B.3.6 ee Key pair A3546, A3547, Probable Primes generation with Conditions Import: A4022, A4459 Signature Based on Auxiliary API input Probable Primes parameters generation From: Related SSPs: Operator RSA public key calling Intermediate application key generation (TOEPP) value RSA public 80-256 bits To: Use: key (PSP) Cryptographic module Key pair generation Signature Export: verification API output Related SSPs: parameters RSA private key From: Cryptographic Intermediate module key generation value To: Operator calling application (TOEPP) Intermediate 112-256 bits CKG SP 800-133r2 Import: None N/A RAM Automatic Use: key vendor affirmed Section 4, 5.1, and Export: None Key pair generation 5.2 generation value (CSP) Related SSPs: DH private key DH public key EC private key EC public key RSA private key RSA public key Table 11 - SSPs

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. Entropy Source Minimum number Details © 2024 Red Hat, Inc. / atsec information security corporation.

of bits of entropy SP 800-90B 238 bits of entropy OpenSSL CPU Jitter 2.2.0 entropy source is located compliant Non- in the 256-bit within the physical perimeter of the module but Physical Entropy output partially outside the cryptographic boundary of the Source module. (ESV cert. E48) Table 12 - Non-Deterministic Random Number Generation Specification The module generates SSPs (e.g., keys) whose strengths are modified by available entropy.

The module implements Cryptographic Key Generation (CKG, vendor affirmed), compliant with SP 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-4. The method described in Appendix B.3.6 of FIPS 186-4 (“Probable Primes with Conditions Based on Auxiliary Probable Primes”) is used.
• ECC (ECDH and ECDSA) key pair generation: compliant with SP 800-133r2, Section 5.1, which maps to FIPS 186-4. The method described in Appendix B.4.2 of FIPS 186-4 (“Testing Candidates”) 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. These implementations shall only be used to generate secret keys in the context of an SP 800-56Ar3 key agreement scheme.
• 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): © 2024 Red Hat, Inc. / atsec information security corporation.

• 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 shared secret computation provide 112-200 resp. 112-256 bits of security strength in an approved mode of operation. SP 800-56Ar3 assurances: 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 TLS protocol. Additionally, the module’s approved “Key pair generation” service must be used to generate ephemeral Diffie- Hellman or EC Diffie-Hellman 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 full public key validation of the generated public key. 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. The module also supports the AES KW and AES KWP key wrapping mechanisms. These algorithms can be used to wrap SSPs with a security strength of 128, 192, or 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, 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. © 2024 Red Hat, Inc. / atsec information security corporation.

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

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. Algorithm Parameters Condition Type Test HMAC SHA-256 Initialization Pre-operational Integrity MAC tag verification on fips.so file (after CASTs) Test SHA-1 N/A Initialization Cryptographic Algorithm KAT digest generation Self-Test SHA-512 N/A Initialization Cryptographic Algorithm KAT digest generation Self-Test SHA3-256 N/A Initialization Cryptographic Algorithm KAT digest generation Self-Test AES GCM 256-bit key Initialization Cryptographic Algorithm KAT encryption and decryption Self-Test AES ECB 128-bit key Initialization Cryptographic Algorithm KAT decryption Self-Test KBKDF HMAC SHA-256 in counter Initialization Cryptographic Algorithm KAT key derivation mode Self-Test KDA OneStep SHA-224 Initialization Cryptographic Algorithm KAT key derivation Self-Test HKDF SHA-256 Initialization Cryptographic Algorithm KAT key derivation Self-Test ANS X9.42 KDF AES-128 KW with SHA-1 Initialization Cryptographic Algorithm KAT key derivation Self-Test ANS X9.63 KDF SHA-256 Initialization Cryptographic Algorithm KAT key derivation Self-Test SSH KDF SHA-1 Initialization Cryptographic Algorithm KAT key derivation Self-Test TLS 1.2 KDF SHA-256 Initialization Cryptographic Algorithm KAT key derivation Self-Test TLS 1.3 KDF SHA-256 Initialization Cryptographic Algorithm KAT key derivation Self-Test PBKDF2 SHA-256 with 4096 iterations Initialization Cryptographic Algorithm KAT password-based key derivation © 2024 Red Hat, Inc. / atsec information security corporation.

Algorithm Parameters Condition Type Test and 288-bit salt Self-Test CTR_DRBG AES-128 with derivation Initialization Cryptographic Algorithm KAT DRBG generation and reseed function and prediction Self-Test resistance Hash_DRBG SHA-256 with prediction Initialization Cryptographic Algorithm KAT DRBG generation and reseed resistance Self-Test HMAC_DRBG SHA-1 with prediction Initialization Cryptographic Algorithm KAT DRBG generation and reseed resistance Self-Test KAS-FFC-SSC ffdhe2048 Initialization Cryptographic Algorithm KAT shared secret computation Self-Test KAS-ECC-SSC P-256 Initialization Cryptographic Algorithm KAT shared secret computation Self-Test RSA PKCS#1 v1.5 with SHA-256 Initialization Cryptographic Algorithm KAT signature generation and and 2048-bit key Self-Test verification ECDSA SHA-256 and P-224, P-256, P- Initialization Cryptographic Algorithm KAT signature generation and 384, and P-521 Self-Test verification DH N/A DH key pair Pair-wise Consistency Test Section 5.6.2.1.4 pair-wise generation consistency RSA PKCS#1 v1.5 with SHA-256 RSA key pair Pair-wise Consistency Test Sign/verify pair-wise consistency generation ECDSA SHA-256 EC key pair Pair-wise Consistency Test Sign/verify pair-wise consistency generation Table 13 - Self-Tests

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

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 tests 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 8 lists the error states and the status indicator values that explain the error that has occurred. Error State Cause of Error Status Indicator Error Software integrity test failure Module will not load CAST failure Module will not load PCT failure Module stops functioning Table 14 - Error States © 2024 Red Hat, Inc. / atsec information security corporation.

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.1-46.el9_0.3 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 openssl3.0.1-46.el9_0.3 RPM package can be uninstalled from the RHEL 9 system.

Before the openssl-3.0.1-46.el9_0.3 RPM package is installed, the RHEL 9 system must operate in the approved mode. This can be achieved by:

• Adding 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 fipsmode-setup --enable command. Restart the system. More information can be found at the vendor documentation. In both cases, the Crypto Officer must verify the RHEL 9 system operates in the approved mode by executing the fips-mode-setup --check command, which should output “FIPS mode is enabled.” After installation of the openssl-3.0.1-46.el9_0.3 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.1-3f45e68ee408cd9c 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 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. © 2024 Red Hat, Inc. / atsec information security corporation.

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

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 length of a single data unit encrypted or decrypted with AES XTS shall not exceed 2²⁰ 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.

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 module accepts a minimum length of 112 bits for the MK or DPK.
• 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. © 2024 Red Hat, Inc. / atsec information security corporation.

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

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

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 CPACF CP Assist for Cryptographic Functions 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 KW Key Wrap KWP Key Wrap with Padding MAC Message Authentication Code NIST National Institute of Science and Technology OAEP Optimal Asymmetric Encryption Padding © 2024 Red Hat, Inc. / atsec information security corporation.

OFB Output Feedback 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 © 2024 Red Hat, Inc. / atsec information security corporation.

Appendix B. References ANS X9.42- Public Key Cryptography for the Financial Services Industry: Agreement of

2001 https://webstore.ansi.org/standards/ascx9/ansix9422001 ANS X9.63- Public Key Cryptography for the Financial Services Industry, Key Agreement and

2001 https://webstore.ansi.org/standards/ascx9/ansix9632001 FIPS 140-3 FIPS PUB 140-3 - Security Requirements For Cryptographic Modules March 2019 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf FIPS 140-3 IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-igannouncements FIPS 180-4 Secure Hash Standard (SHS) March 2012 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS 186-4 Digital Signature Standard (DSS) July 2013 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf FIPS 197 Advanced Encryption Standard November 2001 https://csrc.nist.gov/publications/fips/fips197/fips-197.pdf FIPS 198-1 The Keyed Hash Message Authentication Code (HMAC) July 2008 https://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf FIPS 202 SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions August 2015 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf PKCS#1 Public Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 February 2003 https://www.ietf.org/rfc/rfc3447.txt RFC 3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) May 2003 https://www.ietf.org/rfc/rfc3526.txt RFC 5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS August 2008 https://www.ietf.org/rfc/rfc5288.txt © 2024 Red Hat, Inc. / atsec information security corporation.

RFC 7919 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) August 2016 https://www.ietf.org/rfc/rfc7919.txt RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3 August 2018 https://www.ietf.org/rfc/rfc8446.txt SP 800-38A Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 https://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf SP 800-38A Recommendation for Block Cipher Modes of Operation: Three Variants of Addendum Ciphertext Stealing for CBC Mode October 2010 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a-add.pdf SP 800-38B Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication May 2005 https://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf SP 800-38C Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality May 2004 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 https://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf SP 800-38E Recommendation for Block Cipher Modes of Operation: The XTS AES Mode for Confidentiality on Storage Devices January 2010 https://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf SP 800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping December 2012 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf SP 800-52r2 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations August 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf SP 800-56Ar3 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography April 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf SP 800-56Cr2 Recommendation for Key-Derivation Methods in Key-Establishment Schemes August 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf © 2024 Red Hat, Inc. / atsec information security corporation.

SP 800-90Ar1 Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf SP 800-90B Recommendation for the Entropy Sources Used for Random Bit Generation January 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf SP 800-108r1 NIST Special Publication 800-108 - Recommendation for Key Derivation Using Pseudorandom Functions August 2022 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1.pdf SP 800-131Ar2 Transitioning the Use of Cryptographic Algorithms and Key Lengths March 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf SP 800-132 Recommendation for Password-Based Key Derivation - Part 1: Storage Applications December 2010 https://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf SP 800-133r2 Recommendation for Cryptographic Key Generation June 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf SP 800-135r1 Recommendation for Existing Application-Specific Key Derivation Functions December 2011 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-135r1.pdf SP 800-140B CMVP Security Policy Requirements March 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140B.pdf © 2024 Red Hat, Inc. / atsec information security corporation.