Rocky Linux 9 OpenSSL FIPS Provider

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Rocky 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<br/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>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 Rocky 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<br/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>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

Ctrl IQ, Inc. Rocky Linux 9 OpenSSL FIPS Provider Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 Document version: 1.1 www.atsec.com Last update: 2026-01-05

© 2025 Ctrl IQ, Inc., atsec information security.

This document is the non-proprietary FIPS 140-3 Security Policy for version Rocky9.20250210 of the Rocky 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. including this notice.

Table 1: Security Levels © 2025 Ctrl IQ, Inc., atsec information security.

Purpose and Use: The Rocky 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. Module Type: Software Module Embodiment: MultiChipStand Cryptographic Boundary: The cryptographic boundary of the module is defined as the shared library implementing the FIPS provider (fips.so). Tested Operational Environment’s Physical Perimeter (TOEPP): The TOEPP of the module is defined as the general-purpose computer on which the module is installed. The cryptographic boundary (orange) and TOEPP (purple) are schematically represented in Figure 1. Green lines indicate the flow of data between the cryptographic module and its operator application. Components in white are only included in the diagram for informational purposes and are not part of the module’s validation. Figure 1: Block Diagram © 2025 Ctrl IQ, Inc., atsec information security.

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments - Software, Firmware, Hybrid: Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module.

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

Modes List and Description: © 2025 Ctrl IQ, Inc., atsec information security.

Table 4: Modes List and Description Once the module is installed and initilized as per Section 11.1, after passing all pre-operational self-tests and conditional self-tests executed on startup, the module automatically transitions to the approved mode. On startup, no operator intervention is required to reach this point. The module automatically switches between the approved and non-approved modes depending on the

Approved Algorithms: © 2025 Ctrl IQ, Inc., atsec information security.

© 2025 Ctrl IQ, Inc., atsec information security.

2) 4) 5) Table 5: Approved Algorithms Vendor-Affirmed Algorithms: Table 6: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: © 2025 Ctrl IQ, Inc., atsec information security.

Table 7: Non-Approved, Not Allowed Algorithms

© 2025 Ctrl IQ, Inc., atsec information security.

© 2025 Ctrl IQ, Inc., atsec information security.

© 2025 Ctrl IQ, Inc., atsec information security.

© 2025 Ctrl IQ, Inc., atsec information security.

© 2025 Ctrl IQ, Inc., atsec information security.

Table 8: Security Function Implementations

For TLS 1.2, the module offers the AES GCM implementation and uses the context of Scenario 1 of FIPS 140-3 IG C.H. The module is compliant with SP 800-52 Rev. 2 Section 3.3.1 and the mechanism for IV generation is compliant with RFC 5288 and 8446. © 2025 Ctrl IQ, Inc., atsec information security.

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, compliant to Scenario 2 of FIPS 140-3 IG C.H. 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. 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 ciphersuites 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 SP 800-52 Rev. 2. 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.

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 800-38E. To meet the requirement stated in IG C.I, the module implements a check that ensures, before performing any cryptographic operation, that the two AES keys used in AES XTS mode are not identical. Key_1 and Key_2 shall be generated and/or established independently according to the rules for component symmetric keys from NIST SP 800-133r2, Section 6.3. 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 with SP 800-132 and FIPS 140-3 IG D.N, the following requirements must be met:

• Derived keys shall be used only for storage applications and shall not be used for any other purposes. The length of the MK or DPK must be 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. The Crypto Officer is responsible for choosing a sufficiently complex password. Assuming upper case, lower case, and numerical characters are used, the probability of guessing the password is approximately 1 / (628). Combined with the minimum iteration count as described below, this provides an acceptable trade-off between user experience and security against brute-force attacks. © 2025 Ctrl IQ, Inc., atsec information security.

• A portion of the salt shall be generated randomly using the SP 800-90Ar1 DRBG implemented by the module. The minimum length accepted by the module is 128 bits.
• The iteration count shall be selected as large as possible, as long as the time required to generate the key using the password is acceptable to the user. The minimum value accepted by the module is 1000. If any of these requirements are not met, the requested service is non-approved.

To comply with the assurances found in Section 5.6.2 of SP 800-56Ar3, the operator must use the module in the context of the TLS or SSH protocols. Additionally, the module’s approved key pair generation service (see Section 4.3) 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.

To comply with the assurances found in Section 6.4 of SP 800-56Br2, the operator must use the module in the context of the TLS or SSH protocols. Additionally, the module’s approved key pair generation service (see Section 4.3) must be used to generate 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 validation of the generated public key. The operator must use the EVP_PKEY_public_check() API to perform partial public key validation of the peer public key, complying with Section 6.4.2.2 of SP 800-56Br2. The operator must also confirm the peer’s possession of private key by using any method specified in Section 6.4.2.3 of SP 800-56Br2.

For RSA key generation, signature generation, and signature verification, the approved modulus sizes of 2048, 3072, and 4096 bits are CAVP tested in compliance with FIPS 186-5. For KAS-IFC-SSC and KTSIFC, the approved modulus sizes of 2048, 3072, 4096, 6144, 8192 are CAVP tested in compliance with SP 800-56Br2. All other RSA modulus sizes listed in this document, and not mentioned above, cannot be tested by CAVP but are approved for RSA key generation, signature generation, and signature verification per FIPS 140-3 IG C.F, and KAS-IFC-SSC and KTS-IFC per SP 800-56Br2.

RSA signature verification using modulus sizes between 1024 and 2048 bits is allowed for legacy use only. These legacy algorithms can only be used on data that was generated prior to the Legacy Date specified in FIPS 140-3 IG C.M.

The module does not establish SSPs using an approved key agreement scheme (KAS). However, it does offer some or all of the underlying KAS cryptographic functionality to be used by an external operator/application as part of an approved KAS. © 2025 Ctrl IQ, Inc., atsec information security.

The module does not establish SSPs using an approved key transport scheme (KTS). However, it does offer approved authenticated algorithms that can be used by an external operator/application as part of an approved KTS.

Table 9: Entropy Certificates Table 10: Entropy Sources The module implements primary DRBG (AES-256-CTR-DRBG (A5957)) which acts as the conditioning component for the entropy source mentioned in the above table. It is only used internally by the module to seed the secondary DRBGs which can be of type (CTR, Hash, HMAC). The module complies with the Public Use Document for ESV certificate E208 by reading entropy data from the EVP_RAND_generate() function of the primary DRBG, which corresponds to the GetEntropy() conceptual interface. The operational environment on the ESV certificate is identical to the operating system described in this document. There are no maintenance requirements for the entropy source. As per the Public document of entropy certificate E208, the entropy source provides full entropy of 256 bits. When the module needs random data for internal purposes it uses two separate instances of AES-256 CTR_DRBG DRBG based on use case. i.e., it uses the “private DRBG” accessed via RAND_priv_bytes () for asymmetric key generation, signature generation, or other SSP use cases and it uses the “public DRBG” accessed via RAND_bytes() when it needs to generate IV or other non-SSP use cases. When an external caller needs the random data, it can access it via “Random Number Generation” service of the module and it has a choice to choose between Hash, HMAC or CTR DRBG listed in the algorithms table.

The module implements Cryptographic Key Generation (CKG, vendor affirmed), compliant with SP 800133r2. 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 80056Ar3. The method described in Section 5.6.1.1.4 of SP 800-56Ar3 (“Testing Candidates”) is used.
• EC (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. © 2025 Ctrl IQ, Inc., atsec information security.

• EdDSA key pair generation: compliant with SP 800-133r2, Section 5.1, which maps to FIPS 1865. The method described in Appendix A.2.3 of FIPS 186-5 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. 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-2001 key agreement scheme.
• 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 implements shared secret computation methods, asymmetric encryption and decryption services using RSA with OAEP padding, as listed in the Security Function Implementations table in Section 2.6.

The module implements key derivation functions for usage in the SSH (RFC 4253), TLS 1.2 (RFC 5288), and TLS 1.3 (RFC 8446) protocols. AES-GCM with internal IV generation is offered in the approved mode compliant with TLS 1.2 and TLS 1.3. Finally, the module supports the use of the safe primes defined in RFC 3526 (IKE) and RFC 7919 (TLS) for Diffie-Hellman. No parts of the SSH, TLS, or IKE protocols, other than those mentioned above, have been tested by the CAVP and CMVP. © 2025 Ctrl IQ, Inc., atsec information security.

Table 11: Ports and Interfaces The logical interfaces are the APIs through which the applications request services. These logical interfaces are logically separated from each other by the API design. The module does not implement a control output © 2025 Ctrl IQ, Inc., atsec information security.

The module does not implement any authentication methods.

Table 12: Roles No support is provided for multiple concurrent operators.

W,E © 2025 Ctrl IQ, Inc., atsec information security.

(V, W,E W,E G,R G,R © 2025 Ctrl IQ, Inc., atsec information security.

G,R G,R G,E,Z G,E,Z (V, G,W,E (V, C): G,W,E W,E W,E W,E W,E © 2025 Ctrl IQ, Inc., atsec information security.

W,E W,E W,E G,R W,E W,E W,E W,E W,E © 2025 Ctrl IQ, Inc., atsec information security.

W,E 2)) 2)) W,E G,R © 2025 Ctrl IQ, Inc., atsec information security.

Name

Descri ption

Indicator

Input s

Outpu ts

Securit y Functio ns

SSP Access G,R - Module - generat ed EC private key: G,R - Module - generat ed EC public key: G,R - Module - generat ed EdDSA private key: G,R - Module - generat ed EdDSA public key: G,R - Module - generat ed RSA private key: G,R - Module - generat ed RSA public key: G,R

G,R G,R G,R G,R G,R G,R G,R © 2025 Ctrl IQ, Inc., atsec information security.

G,E,Z W,E W,E W,E W,E © 2025 Ctrl IQ, Inc., atsec information security.

n n n n e e Z Z © 2025 Ctrl IQ, Inc., atsec information security.

Name

Descri ption

Indicator

Input s

Outpu ts

Securit y Functio ns

SSP Access - Passwo rd: Z - Derived key: Z - Entropy input: Z - DRBG seed: Z - DRBG internal state (V, Key): Z - DRBG internal state (V, C): Z - DH private key: Z - DH public key: Z - EC private key: Z - EC public key: Z - EdDSA private key: Z - EdDSA public key: Z - RSA private key: Z - RSA public key: Z - Module - generat

(V, (V, C): Z © 2025 Ctrl IQ, Inc., atsec information security.

Name

Descri ption

Indicator

Input s

Outpu ts

Securit y Functio ns

SSP Access ed DH private key: Z - Module - generat ed DH public key: Z - Module - generat ed EC private key: Z - Module - generat ed EC public key: Z - Module - generat ed EdDSA private key: Z - Module - generat ed EdDSA public key: Z - Module - generat ed RSA private key: Z - Module - generat

© 2025 Ctrl IQ, Inc., atsec information security.

Name

Descri ption

Indicator

Input s

Outpu ts

Securit y Functio ns

SSP Access ed RSA public key: Z - Interme diate key generat ion value: Z

Z Table 13: Approved Services For the above table, 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 rocky_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 the table below) associated with this request can contain a parameter (listed in the right column of the table below) which represents the approved service indicator. The details to use these functions and parameters are described in the module’s manual pages. They can be accessed using the “man openssl” command.

© 2025 Ctrl IQ, Inc., atsec information security.

Table 14: Non-Approved Services

The module does not load external software or firmware. © 2025 Ctrl IQ, Inc., atsec information security.

The integrity of the module is verified by comparing a HMAC-SHA2-256 value calculated at run time with the HMAC-SHA2-256 value embedded in the fips.so file that was computed at build time. The module performs a KAT for the HMAC SHA-256 algorithm in order to test its proper operation before performing the checksum of the fips.so file.

Integrity tests are performed as part of the pre-operational self-tests, which are executed when the module is initialized. The integrity tests can be invoked on demand by unloading and subsequently re-initializing the module (i.e., rebooting the system), which will perform (among others) the software integrity tests. © 2025 Ctrl IQ, Inc., atsec information security.

Type of Operational Environment: Modifiable How Requirements are Satisfied: Any SSPs contained within the module are protected by the process isolation and memory separation mechanisms, and only the module has control over these SSPs. If properly installed, the operating system provides process isolation and memory protection mechanisms that ensure appropriate separation for memory access among the processes on the system. Each process has control over its own data and uncontrolled access to the data of other processes is prevented.

The module shall be installed as stated in Section 11.1. Instrumentation tools like the ptrace system call, gdb and strace, as well as other tracing mechanisms offered by the Linux environment such as ftrace or systemtap, shall not be used in the operational environments. The use of any of these tools implies that the cryptographic module is running in a nonvalidated operational environment. © 2025 Ctrl IQ, Inc., atsec information security.

The module is comprised of software only and therefore this section is not applicable. © 2025 Ctrl IQ, Inc., atsec information security.

The module does not implement any non-invasive security mechanisms. © 2025 Ctrl IQ, Inc., atsec information security.

Table 15: Storage Areas The module does not perform persistent storage of SSPs; SSPs in use by the module exist in volatile Table 16: SSP Input-Output Methods 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. © 2025 Ctrl IQ, Inc., atsec information security.

Table 17: SSP Zeroization Methods All data output is inhibited during zeroization. © 2025 Ctrl IQ, Inc., atsec information security.

© 2025 Ctrl IQ, Inc., atsec information security.

© 2025 Ctrl IQ, Inc., atsec information security.

© 2025 Ctrl IQ, Inc., atsec information security.

Table 18: SSP Table 1 © 2025 Ctrl IQ, Inc., atsec information security.

© 2025 Ctrl IQ, Inc., atsec information security.

© 2025 Ctrl IQ, Inc., atsec information security.

The SHA-1 algorithm as implemented by the module will be non-approved for all purposes, starting January 1, 2031. © 2025 Ctrl IQ, Inc., atsec information security.

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. If any of the self-tests fails, the module immediately transitions to the error state.

Table 20: Pre-Operational Self-Tests The pre-operational software integrity tests are performed automatically when the module is powered on, before the module transitions into the operational state.

© 2025 Ctrl IQ, Inc., atsec information security.

© 2025 Ctrl IQ, Inc., atsec information security.

Table 21: Conditional Self-Tests

Table 22: Pre-Operational Periodic Information © 2025 Ctrl IQ, Inc., atsec information security.

Table 23: Conditional Periodic Information

Table 24: Error States In any error state, the output interface is inhibited, and the module accepts no more inputs or requests (as the module is no longer running).

The pre-operational self-tests and CASTs can be invoked on demand by unloading and subsequently reinitializing the module. The PCTs can be invoked on demand by requesting the key pair generation service. © 2025 Ctrl IQ, Inc., atsec information security.

Before the openssl-fips-provider-so-3.0.7-27.el9_2.ciqfips.0.2.7.x86_64 RPM package is installed, the Rocky Linux 9 system must operate in the FIPS validated configuration. 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.
• Switching the system into the validated configuration after installation. Execute the “fips- modesetup --enable” command. Restart the system. In both cases, the Crypto Officer must verify the system operates in the validated configuration by executing the “fips-mode-setup --check” command, which should output “FIPS mode is enabled.”

After installation of the openssl-fips-provider-so-3.0.7-27.el9_2.ciqfips.0.2.7.x86_64 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: Rocky Linux 9 - OpenSSL FIPS Provider version: Rocky9.20250210 status: active The cryptographic boundary consists only of the FIPS provider as listed. If any other OpenSSL or thirdparty provider is invoked, the user is not interacting with the module specified in this Security Policy.

There is no non-administrator guidance.

As the module does not persistently store SSPs, secure sanitization of the module consists of unloading the module. This will zeroize all SSPs in volatile memory. Then, if desired, the openssl-fips-provider-so3.0.7-27.el9_2.ciqfips.0.2.7.x86_64 RPM package can be uninstalled from the Rocky Linux 9 system. © 2025 Ctrl IQ, Inc., atsec information security.

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)
• EdDSA implementations
• 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 Ctrl IQ, Inc., atsec information security.

A Glossary and Abbreviations AES                        Advanced Encryption Standard API                        Application Programming Interface CAST                       Cryptographic Algorithm Self-Test CAVP                       Cryptographic Algorithm Validation Program CBC                        Cipher Block Chaining CBC-CS                     Cipher Block Chaining with Ciphertext Stealing 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 CVL                        Component Validation List DH                         Diffie-Hellman DRBG                       Deterministic Random Bit Generator EC                         Elliptic Curve ECB                        Electronic Code Book ECC                        Elliptic Curve Cryptography ECDH                       Elliptic Curve Diffie-Hellman ECDSA                      Elliptic Curve Digital Signature Algorithm EdDSA                      Edwards Curve Digital Signature Algorithm ESV                        Entropy Source Validation 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 IFC                        Integer Factorization Cryptography IG                         Implementation Guidance IKE                        Internet Key Exchange IV                         Initialization Vector KAS                        Key Agreement Scheme KAT                        Known Answer Test KBKDF                      Key-based Key Derivation Function KDA                        Key Derivation Algorithm KDF                        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 PAA                        Processor Algorithm Acceleration PBKDF                      Password-Based Key Derivation Function PCT                        Pair-wise Consistency Test PKCS                       Public-Key Cryptography Standards PSP                        Public Security Parameter PSS                        Probabilistic Signature Scheme RSA                        Rivest Shamir Adleman © 2025 Ctrl IQ, Inc., atsec information security.

SHA                        Secure Hash Algorithm SSC                        Shared Secret Computation SSH                        Secure Shell SSP                        Sensitive Security Parameter TOEPP                      Tested Operational Environment’s Physical Perimeter XOF                        Extendable Output Function XTS                        XEX-based Tweaked-codebook mode with cipher text Stealing © 2025 Ctrl IQ, Inc., atsec information security.

B References ANSI X9.42-2001 Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography 2001 https://webstore.ansi.org/standards/ascx9/ansix9422001 ANSI X9.63-2001 Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography 2001 https://webstore.ansi.org/standards/ascx9/ansix9632001 FIPS 140-3 Security Requirements For Cryptographic Modules March 2019 https://doi.org/10.6028/NIST.FIPS.140-3 FIPS 140-3 IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validationprogram/documents/fips%20140-3/FIPS%20140-3%20IG.pdf FIPS 180-4 Secure Hash Standard (SHS) August 2015 https://doi.org/10.6028/NIST.FIPS.180-4 FIPS 186-2 Digital Signature Standard (DSS) January 2000 https://doi.org/10.6028/NIST.FIPS.186-2 FIPS 186-4 Digital Signature Standard (DSS) July 2013 https://doi.org/10.6028/NIST.FIPS.186-4 FIPS 186-5 Digital Signature Standard (DSS) February 2023 https://doi.org/10.6028/NIST.FIPS.186-5 FIPS 197 Advanced Encryption Standard (AES) November 2001; Updated May 2023 https://doi.org/10.6028/NIST.FIPS.197-upd1 FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC) July 2008 https://doi.org/10.6028/NIST.FIPS.198-1 FIPS 202 SHA-3 Standard: Permutation-Based Hash and Extendable- Output Functions August 2015 https://doi.org/10.6028/NIST.FIPS.202 PKCS#1 PKCS #1: RSA Cryptography Specifications Version 2.2 November 2016 https://doi.org/10.17487/RFC8017 RFC 3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) May 2003 https://doi.org/10.17487/RFC3526 RFC 4253 The Secure Shell (SSH) Transport Layer Protocol January 2006 https://doi.org/10.17487/RFC4253 RFC 5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS August 2008 https://doi.org/10.17487/RFC5288 RFC 7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension September 2015 © 2025 Ctrl IQ, Inc., atsec information security.

https://doi.org/10.17487/RFC7627 RFC 7919 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) August 2016 https://doi.org/10.17487/RFC7919 RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3 August 2018 https://doi.org/10.17487/RFC8446 SP 800-38A Recommendation for Block Cipher Modes of Operation: Methods and Techniques December 2001 https://doi.org/10.6028/NIST.SP.800-38A SP 800-38A-Add Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode October 2010 https://doi.org/10.6028/NIST.SP.800-38A-Add SP 800-38B Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication May 2005; Updated October 2016 https://doi.org/10.6028/NIST.SP.800-38B SP 800-38C Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality May 2004; Updated July 2007 https://doi.org/10.6028/NIST.SP.800-38C SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 https://doi.org/10.6028/NIST.SP.800-38D SP 800-38E Recommendation for Block Cipher Modes of Operation: the XTS-AES Mode for Confidentiality on Storage Devices January 2010 https://doi.org/10.6028/NIST.SP.800-38E SP 800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping December 2012 https://doi.org/10.6028/NIST.SP.800-38F SP 800-52r2 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations August 2019 https://doi.org/10.6028/NIST.SP.800-52r2 SP 800-56Ar3 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography April 2018 https://doi.org/10.6028/NIST.SP.800-56Ar3 SP 800-56Br2 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography March 2019 https://doi.org/10.6028/NIST.SP.800-56Br2 SP 800-56Cr2 Recommendation for Key-Derivation Methods in Key-Establishment Schemes August 2020 https://doi.org/10.6028/NIST.SP.800-56Cr2 SP 800-90Ar1 Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 © 2025 Ctrl IQ, Inc., atsec information security.

https://doi.org/10.6028/NIST.SP.800-90Ar1 SP 800-90B Recommendation for the Entropy Sources Used for Random Bit Generation January 2018 https://doi.org/10.6028/NIST.SP.800-90B SP 800-108r1 Recommendation for Key Derivation Using Pseudorandom Functions August 2022 https://doi.org/10.6028/NIST.SP.800-108r1-upd1 SP 800-131Ar2 Transitioning the Use of Cryptographic Algorithms and Key Lengths Marcy 2019 https://doi.org/10.6028/NIST.SP.800-131Ar2 SP 800-132 Recommendation for Password-Based Key Derivation - Part 1: Storage Applications December 2010 https://doi.org/10.6028/NIST.SP.800-132 SP 800-133r2 Recommendation for Cryptographic Key Generation June 2020 https://doi.org/10.6028/NIST.SP.800-133r2 SP 800-135r1 Recommendation for Existing Application-Specific Key Derivation Functions December 2011 https://doi.org/10.6028/NIST.SP.800-135r1 SP 800-140Br1 Cryptographic Module Validation Program (CMVP) Security Policy Requirements: CMVP Validation Authority Updates to ISO/IEC 24759 and ISO/IEC 19790 Annex B November 2023 https://doi.org/10.6028/NIST.SP.800-140Br1 © 2025 Ctrl IQ, Inc., atsec information security.