CryptoComply 140-3 FIPS Provider

Certificate

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

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

SafeLogic Inc. CryptoComply 140-3 FIPS Provider Software Versions 3.0.0-FIPS 140-3, 3.0.1-FIPS 140-3 Document Version 1.3 July 3, 2025 SafeLogic Inc.

530 Lytton Ave, Suite 200

Palo Alto, CA 94301 www.safelogic.com

This document provides a non-proprietary FIPS 140-3 Security Policy for CryptoComply 140-3 FIPS Provider. SafeLogic Inc.'s CryptoComply 140-3 FIPS Provider is designed to provide FIPS 140-3 validated cryptographic functionality and is available for licensing. For more information, visit www.safelogic.com/cryptocomply.

1.1.1 About FIPS 140

Federal Information Processing Standards Publication 140-3, Security Requirements for Cryptographic Modules, (FIPS 140-3) specifies the latest requirements for cryptographic modules utilized to protect sensitive but unclassified information. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) collaborate to run the Cryptographic Module Validation Program (CMVP), which assesses conformance to FIPS 140. NIST (through NVLAP) accredits independent testing labs to perform FIPS 140 testing. The CMVP reviews and validates modules tested against FIPS

140 criteria. Validated is the term given to a module that has successfully gone through this FIPS 140

validation process. Validated modules receive a validation certificate that is posted on the CMVP’s website. More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program.

This non-proprietary cryptographic module Security Policy for CryptoComply 140-3 FIPS Provider from SafeLogic Inc. (SafeLogic) provides an overview of the product and a high-level description of how it meets the security requirements of FIPS 140-3. This document includes details on the module’s cryptographic capabilities, services, sensitive security parameters, and self-tests. This Security Policy also includes guidance on operating the module while maintaining compliance with FIPS 140-3. CryptoComply 140-3 FIPS Provider may also be referred to as the “module” in this document.

The SafeLogic website (www.safelogic.com) contains information on SafeLogic services and products. The CMVP website maintains all FIPS 140 certificates for SafeLogic’s FIPS 140 validations. These certificates also include SafeLogic contact information.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

The following table lists the module’s level of validation for each area in FIPS 140-3. Table 1: Security Levels

Purpose and Use: CryptoComply 140-3 FIPS Provider is a standards-based “Drop-in Compliance™” cryptographic module. The module delivers core cryptographic functions to applications such as servers, personal computers, mobile devices, and appliances. The module features robust algorithm support, including CNSA algorithms. The module delivers cryptographic services to host applications through a C language Application Programming Interface (API). Module Type: Software Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: The module's cryptographic boundary is delimited by the module’s components, as well as the instantiation of the cryptographic module saved in memory and executed by the processor. The executable files that constitute the cryptographic module are listed in Security Policy Section 2.2 Tested and Vendor Affirmed Module Version and Identification. Additionally, the module’s integrity value is included inside the boundary. Refer to the block diagram in Figure 1 for additional detail. Tested Operational Environment’s Physical Perimeter (TOEPP): As a software cryptographic module, the module operates within the Tested Operational Environment’s Physical Perimeter (TOEPP). The TOEPP consists of the Operating System (OS) and the physical perimeter of the General Purpose Computer (GPC). This TOEPP comprises the Operational Environment (OE) that the module operates in, the module itself, and all other applications that operate within the OE, including the host application for the module. Refer to the block diagram in Figure 1 for additional detail.

Figure 1: Block Diagram The module’s block diagram depicts the cryptographic boundary, TOEPP, and the components of each. Additionally, it depicts the data flow between these components. The module’s logical interfaces are defined by its API. These interfaces are used by the host application to interact with the module. All input to the module occurs through the data input interface or control input interface. All output from the module occurs through the data output interface or status output interface. Refer also to Security Policy Section 3 - Cryptographic Module Interfaces and Section 9.2 - SSP Input-Output Methods. The module executes within the operating environments specified in Security Policy Section 2.2 - Tested and Vendor Affirmed Module Version and Identification.

Tested Module Identification – Hardware: N/A for this module.

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Note: module versions 3.0.0-FIPS 140-3, 3.0.1-FIPS 140-3 have identical functionality and APIs, however an internal modification permits the module to be built as a dynamic or static build in the latter version. Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: The module operates in a modifiable operational environment under the FIPS 140-3 definitions. The module operates on a general purpose computer (GPC) running a general purpose operating system (GPOS). The module was tested in the following operating environments.

Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: The module, when compiled from the same unmodified source code, is vendor affirmed to be FIPS 140-3 compliant when compiled as a static library for the tested operating environments listed above for which the module was tested as a shared object or dynamically loaded library.

Table 4: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid Porting guidance is defined in the FIPS 140-3 CMVP Management Manual Section 7.9. FIPS 140-3 validation compliance can be maintained when the following requirements are met:

• No source code modifications are required to recompile the module and port it to another operating environment
• The module is operating on any general-purpose platform/processor that supports the specified operating system as listed on the validation entry or another compatible operating system. CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

Modes List and Description:

Table 5: Modes List and Description Mode Change Instructions and Status: No instructions are needed to invoke the Approved mode in the module. The module only supports this mode of operation and will operate in this mode once the module is powered on. To confirm that the module is operating in Approved mode, the operator should: • Obtain the global indicator by calling EVP_default_properties_is_fips_enabled() and confirming that this returns as true.

Approved Algorithms: The module implements the following approved algorithms that have been tested by the Cryptographic Algorithm Validation Program (CAVP).

Vendor-Affirmed Algorithms: The module implements the following vendor affirmed algorithms that are approved for use in Approved mode.

Table 7: Vendor-Affirmed Algorithms The module implements the following algorithms that are allowed for use in Approved mode.

Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. The module does not implement any non-approved algorithms with no security claimed.

N/A for this module. The module does not implement any non-approved, not allowed algorithms.

Security function implementations (SFIs) are defined by the table below. The module is a software library, therefore the SFIs map directly to the module’s services. Refer also to Security Policy Section 4.3 - Approved Services for a description of the module’s services and SSP access.

Table 9: Security Function Implementations

The module is compatible with TLS 1.2 and supports AES-GCM IV construction in alignment with IG C.H scenario

1. The module does not implement the TLS 1.2 protocol itself. However, the module provides the cryptographic functions required for implementing the TLS 1.2 protocol, including for AES-GCM cipher suites specified in Section 3.3.1 of SP 800-52r2. AES GCM encryption is used in the context of the TLS 1.2 protocol and the mechanism for IV generation is compliant with RFC 5288. The counter portion of the AES GCM IV is set by the module within its cryptographic boundary. The counter portion of the IV is strictly increasing. When the IV exhausts the maximum number of possible values for a given session key, encryption will fail. A handshake to establish a new encryption key is required. It is the responsibility of the user of the module (i.e., the first party to encounter this condition, either the client or the server) to trigger this handshake in accordance with RFC 5246. The module supports internal IV generation by the module’s approved DRBGs, in alignment with IG C.H scenario
2. The IV is at least 96 bits in length per NIST SP 800-38D, Section 8.2.2.

The module is compatible with TLS 1.3 and supports AES-GCM IV construction in alignment with IG C.H scenario 5. The module does not implement the TLS 1.3 protocol itself. However, the module provides the cryptographic functions required for implementing the TLS 1.3 protocol. AES GCM encryption is used in the context of the TLS 1.3 protocol. When used in the context of TLS 1.3, the GCM IV is constructed in accordance with RFC 8446.

Per SP 800-38E, AES-XTS should only be used for storage applications.

DSA KeyGen (FIPS186-4) and DSA PQGGen (FIPS 186-4) are only implemented for use as a part of an approved SP 800-56Ar3 FFC scheme. In accordance with this, only the FIPS 186-type parameter sets FB (2048, 224) and FC (2048, 256) from SP 800-56Arev3 are supported by the module. For DSA signatures, only DSA PQGVer (FIPS186-4) and DSA SigVer (FIPS186-4) are only implemented. Refer to Security Policy Section 9.5 - Transitions for additional context.

Per FIPS 186-5, Edwards curves are only used for digital signatures using EdDSA. Per FIPS 186-5, only SHA-512 is supported with curve Edwards25519 and only SHAKE256 is supported with curve Edwards448.

The PBKDF aligns with Option 1a in Section 5.4 of SP 800-132. Keys derived from passwords using the PBKDF may only be used in storage applications. The PBKDF function can be called using the Key Derivation service, but it does not establish keys into the module. The PBKDF function supports passwords from 8 to 128 bytes and iteration counts from 1 to 10,000. SP 800-132 Section 5.2 recommends a minimum iteration count of 1,000. Operators should select an appropriate password length and iteration count for their use case, bearing in mind that both should be as large as is feasible for the application.

RSA SigVer (FIPS186-4) ANSI X9.31 functionality is only implemented for legacy support. Refer to Security Policy Section 9.5 - Transitions for additional context. The module supports even RSA modulus sizes that are not testable by the CAVP in the following ranges:

• For RSA signature generation: 2048-16384
• For RSA signature verification: 2048-16384

• For RSA KAS and RAS KTS per SP 800-56Br2: 2048-16384 All conformance requirements from IG C.F have been met. All implemented modulus sizes for which CAVP testing is available have been validated under CAVP certificates A4593 and A5173. The minimum number of Miller-Rabin tests used in primality testing is conformant with both FIPS 186-4 and FIPS 1865.

For the RSA KTS (KTS-IFC) algorithm, the module supports the KTS-OAEP-basic scheme. As indicated in Security Policy Section 2.7.6, the module supports even RSA modulus sizes that are not testable by the CAVP. The module supports moduli 2048-16384 for RSA KTS. This is conformant to IG C.F. Refer also to Security Policy Section 2.7.10 - SP 800-140Br1 SSP Establishment for more information on the SSP establishment by the module.

As indicated under CAVP certificates A4593 and A5173, the module supports TLS 1.2 KDF per RFC 7627, i.e. using the extended master secret.

TDES-CBC and TDES-ECB Decryption functionality is only implemented for legacy support. Refer to Security Policy Section 9.5 - Transitions for additional context.

As a cryptographic software library, SSPs used for services are passed in by the calling application. Established SSPs are passed out to the calling application and are not stored in the module. Accordingly, the following statements are required for conformance. For additional details, see also Security Policy Section 2.10 - Key Establishment. 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. 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.

Entropy Certificates: N/A for this module. Entropy Sources: N/A for this module. The module does not include an entropy source. The module aligns with IG 9.3.A, scenario 2b, therefore the module’s certificate includes the caveat “No assurance of the minimum strength of generated SSPs (e.g., keys).” The module accepts input from entropy sources external to the cryptographic boundary for use as seed material for the module’s approved DRBG implementations. Entropy is supplied to the module by means of callback functions. Those functions return an error if the minimum entropy strength is not met. Entropy strength requirements are per NIST Special Publication 800-90A Rev. 1 Table 2 (Hash_DRBG, HMAC_DRBG) and Table 3 (CTR_DRBG). At a minimum, the entropy source shall provide at least 128 bits of entropy to the DRBG. All random values used by the module for approved algorithms are provided by the module’s approved DRBGs. The module includes Counter DRBG, Hash DRBG, and HMAC DRBG, all of which are approved RBGs. The output of these approved RBGs is used to generate random data, symmetric keys, and asymmetric keys, as indicated in Security Policy Section 2.5.2 - Vendor-Affirmed Algorithms.

Any generated SSPs are passed out to the calling application and are not stored in the module. Additional detail is provided in Security Policy Section 2.6 - Security Function Implementations and Section 4.3 - Approved Services. Random values for key generation are provided by the module’s approved DRBGs. The output of the module’s approved DRBGs may be used to generate symmetric and asymmetric keys per SP 800-133r2, as indicated in Security Policy Section 2.5.2 - Vendor-Affirmed Algorithms. The module is a software library that provides a service (called Random Number Generation) for direct output of the approved DRBG (U). This output is approved for generating keys or SSPs. Symmetric keys are generated per SP 800-133r2 Section 6.1 using the Random Number Generation service; additionally, Section 6.3 is applicable for AES-XTS keys. Asymmetric keys are generated per SP

800-133r2 Section 5 per FIPS 186-4 and per FIPS 186-5 (for EdDSA only) using the Asymmetric Key Generation service.

SSPs used for services are passed in by the calling application. Established SSPs are passed out to the calling application and are not stored in the module. Additional detail is provided in Security Policy Section 2.6 - Security Function Implementations and Section 4.3 - Approved Services. The module provides ECC and FFC shared secret computation that is conformant to SP 800-56Ar3 in alignment with IG D.F scenario 2 (path 1) via the Key Agreement (ECC/FFC) service. For ECC, the module supports the (Cofactor) Ephemeral Unified Model, C(2e, 0s, ECC CDH) Scheme described in SP 800-56Ar3 Section 6.1.2.2. For FFC, the module supports the dhEphem, C(2e, 0s, FFC DH) Scheme described in SP 800-56Ar3 Section 6.1.2.1. The module also provides ECC key agreement using the allowed curves specified in Security Policy Section 2.5.3 - Non-Approved, Allowed Algorithms in alignment with IG D.F scenario 3 via the Key Agreement (ECC/FFC) service. The appropriate public key validation assurances are implemented. For ECC, full public key validation is implemented (SP 800-56Ar3 Section 5.6.2.3.3). For FFC, both full public key validation (per SP 800-56Ar3 Section 5.6.2.3.1) and partial public key validation (per SP 800-56Ar3 Section 5.6.2.3.2) are implemented. The module provides RSA shared secret computation that is conformant to SP 800-56Br2 in alignment with IG D.F scenario 1 (path 1) via the Key Agreement (RSA) service. The module supports the KAS1 basic and KAS2 basic schemes. The module supports various key derivation functions separately via the Key Derivation service. Supported KDFs are conformant to SP 800-108r1 (KBKDF), SP 800-132 (PBKDF), SP 800-56Cr2 (HKDF, KDA OneStep KDA, TwoStep KDA), SP 800-135r1 (ANSI 9.42 KDF, ANSI 9.63 KDF, SSH KDF, TLS 1.2 KDF), and RFC 8446 (TLS 1.3 KDF). The module provides RSA key encapsulation that is conformant to SP 800-56Br2 via the Key Transport service. The module provides AES key wrapping (AES KW, AES KWP) that is conformant to SP 800-38F via the Key Wrapping service. Refer also to Security Policy Section 2.7.10 - SP 800-140Br1 SSP Establishment for more information on the SSP establishment by the module.

The module implements KDFs from SP 800-135r1 (Recommendation for Existing Application-Specific Key Derivation Functions) and the TLS 1.3 KDF. These KDFs have been validated by the CAVP and received

CVL certificates (A4593, A5173). No parts of these protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

As a software cryptographic module, the module supports logical interfaces only and not physical ports. All access to the module is through the module’s API. The API provides and defines the module’s logical interfaces. The API provides functions that may be called by a host application (refer to Security Policy Section 4.3 - Approved Services). Table 10: Ports and Interfaces

All interfaces are logically separated by the module’s API. The data output path is inhibited during pre-operational self-tests, zeroisation, and when the module is in an error state.

Table 11: Roles Crypto Officer is the only role supported by the module. The module does not support a User role or a Maintenance role. The Crypto Officer role is implicitly selected by calling the module’s services.

The following table describes the services the module provides and the access to SSPs by each service. Additional details on each service are available in the module’s user guidance documentation. SSP Access is divided into the following access types:

• Generate: The module generates or derives the SSP.
• Write: The SSP is updated, imported, or written to the module.
• Execute: The module uses the SSP in performing a cryptographic operation. In alignment with IG 2.4.C example scenario 2, the module provides a global indicator that services are approved and a status code indicating the completion of each service, as specified in the “Indicator” column of the table below. The module only provides approved services. The successful completion of a service is an implicit indicator for the use of an approved service. Additional detail is provided in Security Policy Section 2.4 - Modes of Operation.

N/A for this module. The module does not implement any non-approved, not allowed algorithms; therefore, it also does not provide any non-approved services.

Not applicable for this module.

As specified in the executable code sets table in Security Policy Section 2.2 - Tested and Vendor Affirmed Module Version and Identification, the module implements integrity techniques for all executable code sets. The integrity technique used by the module is HMAC-SHA-256. The integrity technique has received CAVP certificates A4593 and A5173. The integrity technique is implemented by the module itself. The integrity authentication key for the integrity technique is an HMAC-SHA-256 key with a key length of

256 bits. It is integrated into the module during compilation and cannot be changed afterwards. The

module is only provided to the end user in the form of a compiled binary (refer to Security Policy Section 11.1). Note, per ISO 19790:2012 Section 7.5, this key is not considered a SSP. The installation process generates the HMAC digest for the module using this key and the module. For dynamic libraries, the HMAC digest is generated from the module file and is then stored in the module's configuration file. For static and iOS libraries, the HMAC digest is generated from the memory the module is loaded at and is then stored in the executable the module is linked into. To verify the module's integrity (for the pre-operational self-test or on demand), the module generates a new HMAC digest and compares it with the corresponding stored value. The test passes if the values match.

The Integrity Test can be performed on demand via the “Integrity Test” service.

Type of Operational Environment: Modifiable How Requirements are Satisfied: Supported operational environments are indicated in Security Policy Section 2.2 - Tested and Vendor Affirmed Module Version and Identification. Refer also to that section for vendor affirmed operating environment porting guidance. The operating environments ensure that every application using the module operates in its own private and isolated environment (memory, I/O, etc.) and that user processes are segregated into separate process spaces. The module does not spawn any processes.

The module must be installed, and the correct installation confirmed, as described in Security Policy Section 11.1 - Installation, Initialization, and Startup Procedures. No specific configuration options are required for the operational environments. No security rules, settings, or restrictions to the configuration of the operational environment are needed for the module to function in an approved manner. It is advised to restrict write access to the module and its related configuration file to the administrator role in the operational environment.

The requirements of this section are not applicable to the module. The module is a software module and does not implement any physical security mechanisms.

The requirements of this section are not applicable to the module.

Table 14: SSP Input-Output Methods The information in the table above aligns with IG 9.5.A. IG 9.5.A indicates that SSPs established by a software cryptographic module to or from a general purpose application that operates outside the module’s boundary but within the TOEPP are classified as Manually Distributed using Electronic Entry. The module does not support any other methods of SSP input or output. Specifically, the module does not support Automated Distribution, Wireless Distribution, or Direct Entry. The module outputs CSPs in plaintext unless a KeyTransport (RSA) or KeyWrapping (AES) Security Function Implementation (refer to Security Policy Section 2.6 - Security Function Implementations) is used to encrypt the output CSP. Table 15: SSP Zeroization Methods As indicated in Security Policy Section 4.3 - Approved Services, the completion of a zeroisation routine indicates that the zeroisation procedure succeeded. Zeroisation can be confirmed via EVP_RAND_verify_zeroization: 1 for success (i.e. the DRBG CSPs have been zeroised), 0 for failure. The following two tables define the module’s Sensitive Security Parameters (SSPs). Access to SSPs is defined under Security Policy Section 4.3 - Approved Services.

All algorithms implemented by the module are approved for FIPS 140-3 and their approval status will not be impacted by the transitions specified below. The information below provides context for the algorithms not supported by the module due to algorithm transitions. Refer also to Security Policy Section 2.7 - Algorithm Specific Information. After December 31, 2023, Triple-DES transitioned to non-approved (refer to SP 800-131Ar2.). After December 31, 2023, the following functionality remains approved for legacy use. Because this functionality remains approved, this is the only Triple-DES functionality supported by the module. • Triple-DES decryption remains approved for legacy use After February 3, 2024, DSA and RSA X9.31 transitioned to non-approved for all new FIPS module submissions (refer to FIPS 186-4 and IG C.K). Although this validation was submitted to the CMVP before February 3, 2024, the module only implements the DSA and RSA X9.31 functionality that remains approved for submissions after this transition:

• DSA primes and group generators used exclusively in a SP 800-56Ar3-compliant scheme remain approved
• DSA verification remains approved
• RSA X9.31 verification remains approved After December 31, 2030, SHA-1 transitions to non-approved (refer to NIST announcements). Because this functionality remains approved currently, SHA-1 functionality is still supported by the module.

Table 18: Pre-Operational Self-Tests The module only performs one pre-operational self-test, which is the software/firmware integrity test. The module does not implement any other pre-operational self-tests, including pre-operational selftests for bypass or critical functions, because the module does not implement corresponding functions. The pre-operational self-tests are executed automatically by the Module Initialization service when the module is powered on. Automatic execution of the pre-operational self-tests relies on use of the default entry point (DEP); no operator intervention is required. For the pre-operational self-tests, the module performs an HMAC-SHA-256 CAST, and then verifies the integrity of the runtime executable using a HMAC-SHA-256 digest computed at build time. If the digests match, the CAST tests are then performed. The integrity technique (HMAC-SHA-256) has received CAVP certificates A4593 and A5173. Note, please refer also to the HMAC-SHA-256 CAST, which is performed before the pre-operational

The module mainly performs two types of conditional self-tests, which are Cryptographic Algorithm SelfTests (CASTs) and Pairwise Consistency Tests (PCTs). The module also performs one critical function test for AES-XTS, per IG C.I. The module does not implement any other conditional self-tests, including conditional self-tests for software/firmware loading, manual entry, or bypass, because the module does not implement corresponding functions. The CAST tests below are executed automatically by the Module Initialization service when the module is powered on. Automatic execution of the CASTs relies on use of the default entry point (DEP); no operator intervention is required.

The CASTs execute before the module transitions to the operational state. If the CASTs are successful, All other conditional self-tests are executed when the relevant condition occurs, as specified in the table below. d G) G)

d Table 19: Conditional Self-Tests

Table 20: Pre-Operational Periodic Information

Table 21: Conditional Periodic Information