CryptoComply 140-3 FIPS Provider

Certificate

Approved Algorithms (164)

Security Levels (Table 1)

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["[high] Firmware update / recovery<br/>/ rollback services<br/><i>FIPS_STATE_ERROR<br/>entered an error</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>CO<br/>Self-Test<br/>Show Status</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["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input 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["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["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["[high] Firmware update / recovery / rollback services<br/><i>FIPS_STATE_ERROR<br/>entered an error</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>CO<br/>Self-Test<br/>Show Status</i><br/>src: securityPolicy.services"]
    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 clueHigh;
  class 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.1a June 27, 2024 SafeLogic Inc.

Palo Alto, CA 94301 www.safelogic.com Document Version 1.1a © SafeLogic Inc.

9.3 9.4 9.5 10.1 10.2 10.3 10.4 10.5 11.1 11.2 11.3 11.4 12.1 12.2 12.3 Document Version 1.1a © SafeLogic Inc.

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.

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. Document Version 1.1a © SafeLogic Inc.

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 [Number Below] Document Version 1.1a © SafeLogic Inc. N/A N/A

CryptoComply 140-3 FIPS Provider is a standards-based “Drop-in Compliance™” cryptographic engine. 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).

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 Table 4 - Executable Code Sets. Additionally, the module’s integrity value is included inside the boundary. Refer to the block diagram in Figure 1 (Security Policy Section 2.7 - Module Block Diagram) for additional detail. 2.1.5.1 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 TOEPPe 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. Document Version 1.1a © SafeLogic Inc.

Refer to the block diagram in Figure 1 (Security Policy Section 2.7 - Module Block Diagram) for additional detail.

Table 2 - Version Information Note: versions 3.0.0-FIPS 140-3 and 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.

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 specified in the table below. Testing on iOS 16 and iPadOS 16 was performed with module version 3.0.1-FIPS 140-3 and testing on all other OEs was performed with module version 3.0.0-FIPS 140-3. Table 3

• Tested Operational Environments # 1. 2. 3. 4. 5. 6. Document Version 1.1a © SafeLogic Inc.

# 7. 8. 9. Document Version 1.1a © SafeLogic Inc.

Table 4 - Executable Code Sets

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 operating system as listed on the validation entry or another compatible operating system. The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment that is not listed on the validation certificate. 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 operating environments listed in Table 3 for which the module was tested as a shared object or dynamically loaded library. Table 5 - Vendor Affirmed Operational Environments # 1. 2. 3. 4. 5. 6. 7. 8. Document Version 1.1a © SafeLogic Inc.

Table 6 - Modes of Operation

mode of operation and will operate in this mode once the module is powered on.

• Obtain the global indicator by calling EVP_default_properties_is_fips_enabled() and confirming Document Version 1.1a © SafeLogic Inc.

• o Returning as true indicates that the module is configured in Approved mode Confirm that the service that is called successfully completes. The successful completion of a service is an implicit indicator for the use of an approved service.

Not applicable. Document Version 1.1a © SafeLogic Inc.

The module implements the following approved algorithms that have been tested by the Cryptographic Algorithm Validation Program (CAVP). Table 7 - Approved Algorithms Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

• o
• Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Hash Algorithm: SHA2-512/256 Capabilities: Signature Type: PKCSPSS Properties: Modulo: 2048 Hash Pair: Hash Algorithm: SHA2-224 Salt Length: 28 Hash Pair: Hash Algorithm: SHA2-256 Salt Length: 32 Hash Pair: Hash Algorithm: SHA2-384 Salt Length: 48 Hash Pair: Hash Algorithm: SHA2-512 Salt Length: 64 Hash Pair: Hash Algorithm: SHA2-512/224 Salt Length: 28 Hash Pair: Hash Algorithm: SHA2-512/256 Salt Length: 32 Properties: Modulo: 3072 Hash Pair: Hash Algorithm: SHA2-224 Salt Length: 28 Hash Pair: Hash Algorithm: SHA2-256 Salt Length: 32 Hash Pair: Hash Algorithm: SHA2-384 Salt Length: 48 Hash Pair: Hash Algorithm: SHA2-512 Salt Length: 64 Hash Pair: Hash Algorithm: SHA2-512/224 Salt Length: 28 Hash Pair: Hash Algorithm: SHA2-512/256 Salt Length: 32 Properties: Modulo: 4096 Hash Pair: Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Hash Algorithm: SHA2-512 Hash Pair: Hash Algorithm: SHA2-512/224 Hash Pair: Hash Algorithm: SHA2-512/256 Properties: Modulo: 4096 Hash Pair: Hash Algorithm: SHA-1 Hash Pair: Hash Algorithm: SHA2-224 Hash Pair: Hash Algorithm: SHA2-256 Hash Pair: Hash Algorithm: SHA2-384 Hash Pair: Hash Algorithm: SHA2-512 Hash Pair: Hash Algorithm: SHA2-512/224 Hash Pair: Hash Algorithm: SHA2-512/256 Capabilities: Signature Type: ANSI X9.31 Properties: Modulo: 1024 Hash Pair: Hash Algorithm: SHA-1 Hash Pair: Hash Algorithm: SHA2-256 Hash Pair: Hash Algorithm: SHA2-384 Hash Pair: Hash Algorithm: SHA2-512 Properties: Modulo: 2048 Hash Pair: Hash Algorithm: SHA-1 Hash Pair: Hash Algorithm: SHA2-256 Hash Pair: Hash Algorithm: SHA2-384 Hash Pair: Hash Algorithm: SHA2-512 Properties: Modulo: 3072 Hash Pair: Document Version 1.1a © SafeLogic Inc.

Hash Algorithm: SHA-1 Hash Pair: Hash Algorithm: SHA2-256 Hash Pair: Hash Algorithm: SHA2-384 Hash Pair: Hash Algorithm: SHA2-512 Properties: Modulo: 4096 Hash Pair: Hash Algorithm: SHA-1 Hash Pair: Hash Algorithm: SHA2-256 Hash Pair: Hash Algorithm: SHA2-384 Hash Pair: Hash Algorithm: SHA2-512 Capabilities: Signature Type: PKCSPSS Properties: Modulo: 1024 Hash Pair: Hash Algorithm: SHA-1 Salt Length: 20 Hash Pair: Hash Algorithm: SHA2-224 Salt Length: 28 Hash Pair: Hash Algorithm: SHA2-256 Salt Length: 32 Hash Pair: Hash Algorithm: SHA2-384 Salt Length: 48 Hash Pair: Hash Algorithm: SHA2-512 Salt Length: 62 Hash Pair: Hash Algorithm: SHA2-512/224 Salt Length: 24 Hash Pair: Hash Algorithm: SHA2-512/256 Salt Length: 32 Properties: Modulo: 2048 Hash Pair: Hash Algorithm: SHA-1 Document Version 1.1a © SafeLogic Inc.

Salt Length: 20 Hash Pair: Hash Algorithm: SHA2-224 Salt Length: 28 Hash Pair: Hash Algorithm: SHA2-256 Salt Length: 32 Hash Pair: Hash Algorithm: SHA2-384 Salt Length: 48 Hash Pair: Hash Algorithm: SHA2-512 Salt Length: 64 Hash Pair: Hash Algorithm: SHA2-512/224 Salt Length: 24 Hash Pair: Hash Algorithm: SHA2-512/256 Salt Length: 32 Properties: Modulo: 3072 Hash Pair: Hash Algorithm: SHA-1 Salt Length: 20 Hash Pair: Hash Algorithm: SHA2-224 Salt Length: 28 Hash Pair: Hash Algorithm: SHA2-256 Salt Length: 32 Hash Pair: Hash Algorithm: SHA2-384 Salt Length: 48 Hash Pair: Hash Algorithm: SHA2-512 Salt Length: 64 Hash Pair: Hash Algorithm: SHA2-512/224 Salt Length: 24 Hash Pair: Hash Algorithm: SHA2-512/256 Salt Length: 32 Properties: Modulo: 4096 Hash Pair: Hash Algorithm: SHA-1 Salt Length: 20 Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

The module implements the vendor affirmed algorithms that are approved for use in Approved mode. Specifically, the module implements CKG per SP 800-133r2 for generation of symmetric keys and asymmetric keys. Refer to the CKG entries in Table 7 for additional details.

The module implements the following algorithms that are allowed for use in Approved mode. These are the brainpool curves as listed in SP 800-186 Appendix H.1. Table 8 - Non-Approved Algorithms Allowed in the Approved Mode of Operation

Not applicable. The module does not implement any non-approved algorithms with no security claimed.

Not applicable. The module does not implement any non-approved, not allowed algorithms. Document Version 1.1a © SafeLogic Inc.

Figure 1 - Module Block Diagram and Cryptographic Boundary 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.3 Operating Environments. Document Version 1.1a © SafeLogic Inc.

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. The SFIs below are used to encrypt or decrypt a key value on behalf of the calling application. SSPs are passed in by the calling application. Established SSPs are passed out to the calling application. 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, it provides the cryptographic functions required for implementing the 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
3. The module does not implement the TLS 1.3 protocol itself, however, it provides the cryptographic functions required for implementing the 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. Document Version 1.1a © SafeLogic Inc.

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 the following even RSA modulus sizes that are not testable by the CAVP:

• For RSA signature generation: 2048-16384 For RSA signature verification: 1024-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. Document Version 1.1a © SafeLogic Inc.

For the RSA KTS (KTS-IFC) algorithm, the module supports the KTS-OAEP-basic scheme. As indicated in Security Policy Section 2.9.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.

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. Document Version 1.1a © SafeLogic Inc.

Not applicable 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 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 does not include an entropy source. 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.6.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 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 keys per SP 800-133r2 using the Random Number Generation service, as indicated in Security Policy Section 2.6.2 - Vendor Affirmed Algorithms. The output of the module’s approved DRBGs may be used to generate asymmetric keys per FIPS 186-4 and per FIPS 186-5 (for EdDSA only) using the Asymmetric Key Generation service. Document Version 1.1a © SafeLogic Inc.

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 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 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 80056Ar3 Section 6.1.2.1. The module also provides ECC key agreement using the allowed curves specified in Table 8 - Non-Approved Algorithms Allowed in the Approved Mode of Operation in alignment with IG D.F scenario 3 via the Key Agreement 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 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 (this is the KeyTransport SFI). The module provides AES key wrapping (AES KW, AES KWP) that is conformant to SP 800-38F via the Key Wrapping service (this is the KeyWrapping SFI).

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.

The module is designed to meet the applicable requirements of FIPS 140-3. The module initializes when powered on, then performs the pre-operational self-tests and CASTs as specified in Security Policy Document Version 1.1a © SafeLogic Inc.

Section 10 - Self-Tests. After successfully passing these self-tests, the module automatically transitions to the operational state and awaits service requests.

The Module Initialization service is executed when the module is powered on. Document Version 1.1a © SafeLogic Inc.

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 N/A N/A N/A N/A The following interfaces are omitted from the table above because they are not applicable to the module: Control Output (not implemented), Power Input (N/A for software modules).

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. Document Version 1.1a © SafeLogic Inc.

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. Table 12 below describes the service inputs and outputs for the CO role and should be reviewed in conjunction with the service descriptions in Table 14. Table 12

• Roles, Service Commands, Input and Output Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Table 13

• Roles and Authentication N/A The module does not support authentication.

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. Read: The SSP is read from the module (e.g. the SSP is output). Write: The SSP is updated, imported, or written to the module. Execute: The module uses the SSP in performing a cryptographic operation. Zeroise: The module zeroises the SSP. 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.5 - Modes of Operation. Document Version 1.1a © SafeLogic Inc.

Table 14 - Approved Services N/A N/A N/A N/A N/A N/A N/A N/A Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc. N/A N/A Z) Z)

Z) Z) © SafeLogic Inc. Document Version 1.1a Z)

Document Version 1.1a Z) Z) © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc. Z) Z) (G, R, Z)

Document Version 1.1a © SafeLogic Inc. Z) Z)

N/A © SafeLogic Inc. Document Version 1.1a N/A E, Z) (G, R, Z)

Document Version 1.1a © SafeLogic Inc. Z) (G, R, Z)

Z) Z) Z) Document Version 1.1a Z) © SafeLogic Inc.

N/A N/A Document Version 1.1a © SafeLogic Inc.

Not applicable. The module does not implement any non-approved, not allowed algorithms; therefore, it also does not provide any non-approved services.

Not applicable. The module does not support this functionality. Document Version 1.1a © SafeLogic Inc.

As specified in Security Policy Section 2.3.3 - Executable Code Sets, 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 Test can be performed on demand via the “Integrity Test” service. Document Version 1.1a © SafeLogic Inc.

Refer to Security Policy Section 2.3.4 for vendor affirmed operating environment porting guidance.

Supported operational environments are indicated in Security Policy Section 2.3 - Operating Environments. 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

• 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 a FIPS-conformant manner. It is advised to restrict write access to the module and its related configuration file to the administrator role in the operational environment. Document Version 1.1a © SafeLogic Inc.

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. Document Version 1.1a © SafeLogic Inc.

Non-Invasive Security The requirements of this section are not applicable to the module. Document Version 1.1a © SafeLogic Inc.

Table 16

• 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.8 - Security Function Implementations) is used to encrypt the output CSP. Document Version 1.1a © SafeLogic Inc.

Table 17

• SSP Zeroisation Methods As indicated in Table 14 - 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. Document Version 1.1a © SafeLogic Inc.

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. N/A Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a N/A N/A N/A N/A © SafeLogic Inc. N/A

N/A N/A N/A N/A Document Version 1.1a © SafeLogic Inc.

N/A N/A N/A N/A N/A N/A Document Version 1.1a © SafeLogic Inc.

N/A N/A N/A N/A N/A N/A Document Version 1.1a © SafeLogic Inc.

N/A N/A N/A N/A N/A N/A Document Version 1.1a © SafeLogic Inc.

N/A N/A N/A Document Version 1.1a © SafeLogic Inc.

© SafeLogic Inc. Document Version 1.1a

Document Version 1.1a N/A N/A N/A © SafeLogic Inc.

N/A N/A N/A Document Version 1.1a © SafeLogic Inc.

N/A N/A © SafeLogic Inc. Document Version 1.1a

The table below provides additional detail for the SSPs listed in Table 18

• SSPs. © SafeLogic Inc. Document Version 1.1a

Table 19

• SSPs, Additional Details Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

All algorithms implemented by the module are approved for FIPS 140-3 and 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.9

• 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. Document Version 1.1a © SafeLogic Inc.

• 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, this functionality is still supported by the module. Document Version 1.1a © SafeLogic Inc.

Table 20

• 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 self-tests 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-SHA256) has received CAVP certificates A4593 and A5173.

The module mainly performs two types of conditional self-tests, which are Cryptographic Algorithm Self-Tests (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 Please refer also to the HMAC-SHA-256 CAST, which is performed before the pre-operational SW integrity test Document Version 1.1a © SafeLogic Inc.

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, the Module State (queried via Show Status) is updated to indicate that the module is in the Running state (FIPS_STATE_RUNNING). All other conditional self-tests are executed when the relevant condition occurs, as specified in the table below. Table 21 - Conditional Self-Tests Document Version 1.1a © SafeLogic Inc.

CryptoComply 140SigGen Document Version 1.1a © SafeLogic Inc.

Document Version 1.1a © SafeLogic Inc.

Sp80056Ar3 before preoperational KAS-ECCSSC Sp80056Ar3 HMACSHA2-256 Also serves as a self-test for SHA-256 and covers the self-test requirement for SHA-224 Per Scenario 2 of IG D.F and Section 6 of SP 800-56Ar3. Also covers the self-test requirement for EC Diffie-Hellman with non-NIST recommended curves. Per Scenario 2 of IG D.F and Section 6 of SP 800-56Ar3 Per Scenario 1 of IG D.F and Section 8.2.2 in SP 800-56Br2 Document Version 1.1a © SafeLogic Inc.

SP80056Cr2 SP80056Cr26 KDF SP800108 KTS-OAEPBasic7 KTS-OAEPBasic8 Per IG D.G and SP 800-56Br2 Per IG D.G and SP 800-56Br2 Per IG D.G and SP 800-56Br2 Document Version 1.1a © SafeLogic Inc.

Per Section 5.3 of SP 800-132 Also serves as a self-test for KMAC and SHAKE since it utilizes the same Keccak-p permutation Also covers the self-test requirements for SHA-384, SHA-512/224, and SHA-512/256. SHA-256 is tested by the HMAC-SHA-256 self-test. Document Version 1.1a © SafeLogic Inc.

Per VE10.35.03 Per VE10.35.02. At the time of key pair generation, the keys’ intended usage is not known (key pairs may be used for digital signatures or key agreement); per IG 10.3.A comment 1, any of the AS10.35 PCTs is acceptable. Per VE10.35.03. At the time of key pair import, the keys’ intended usage is not known (key pairs may be used for digital signatures or key agreement); per IG 10.3.A comment 1, any of the AS10.35 PCTs is acceptable. Per VE10.35.02. EdDSA keys can only be used for digital signatures. Document Version 1.1a © SafeLogic Inc.

Per VE10.35.03. At the time of key pair generation or import, the keys’ intended usage is not known (key pairs may be used for key transport, digital signatures, or key agreement); per IG 10.3.A comment 1, any of the AS10.35 PCTs is acceptable. Per IG C.I Document Version 1.1a © SafeLogic Inc.

Table 23 - Error States Document Version 1.1a © SafeLogic Inc.

The module supports two error states, both triggered by failures of the module’s self-tests. The module must be restarted to recover from a failure of the pre-operational or CAST self-test, but it recovers automatically from a failure in the other conditional self-tests.

Self-tests can be called on demand using the Self-Test service. This service calls the module’s integrity test and all CASTs (i.e. KATs). PCTs are not called by this service; PCTs are only called under the conditions specified in Section 10.2 - Conditional Self-Tests. The integrity test is automatically called as part of the Pre-Operational Self-Tests and can also be manually called by the Integrity Test service (or the Self-Test service). Document Version 1.1a © SafeLogic Inc.

Failure to follow initialization instructions for the module (provided below) will result in the module being in a non-compliant state. The module is only provided to the end user in the form of a compiled binary file. Its source code is not provided. The module is provided to the end user by the vendor as a binary archive and an associated hash value. The end user should validate the integrity of the binary archive against the SHA-256 hash value provided with the binary archive. If the integrity value for the archive is correct, the archive should be extracted, and the binaries should be installed. The module is a FIPS-validated cryptographic provider for use by OpenSSL 3.x. OpenSSL 3.x should be installed per its documentation prior to module installation. The FIPS module may be installed using the following procedure:

1. If the module is provided as a dynamic library: a. Copy the module binary and configuration files to the OpenSSL Provider Directory, e.g. [OPENSSL_INSTALL_LOCATION]/lib/ossl-modules/
2. If the module is provided as a static library: a. Copy the module library archive and configuration file to the OpenSSL directory, e.g. [OPENSSL_INSTALL_LOCATION]/lib/ and [OPENSSL_INSTALL_LOCATION]/conf/
3. If the module is provided as part of an XCFramework bundle: a. Integrate the module framework into an XCode application and install the application on an iOS device. b. Note, when provided as a XCFramework bundle (fips.xcframework), the OpenSSL framework (openssl.xcframework) should also be integrated into the application project. The OpenSSL framework is a general implementation of the OpenSSL 3.x API (common and crypto).
4. To initialize and start up the module, use the OSSL_PROVIDER_load API call from OpenSSL. An example is specified below: int main(int argc, char **argv) { OSSL_PROVIDER *fips_provider; fips_provider = OSSL_PROVIDER_load(NULL, "fips"); if (fips_provider == NULL) { printf("Could not load FIPS provider\n"); return 1; } printf("Provider %s loaded \n", OSSL_PROVIDER_get0_name(fips_provider)); Document Version 1.1a © SafeLogic Inc.

//Execute commands for the FIPS module if (fips_provider != NULL) OSSL_PROVIDER_unload(fips_provider); return 0; } After the module starts up, the operator should confirm that the module outputs the Approved mode status indicator (refer to Security Policy Section 2.5 - Modes of Operation) and verify the module’s version using the “Output ID/ Version Information” service (refer to Security Policy Section 4.3 Approved Services).

Additional administrator guidance is provided separately in other operator documentation, including the User Manual.

If the module power is lost and restored, the operator shall establish a new key for use with AES-GCM encryption/decryption. Refer also to Security Policy Section 2.9.1 - AES-GCM (IG C.H conformance). Additional guidance is provided separately in other operator documentation, including the User Manual.

The vendor documentation (User Guide) specifies the procedures for the removal of the FIPS module and secure sanitization of the device that the module was installed on. Document Version 1.1a © SafeLogic Inc.

The module implements two types of mitigations of other attacks, which are constant-time implementations and numeric blinding. Constant-time implementations protect cryptographic implementations in the module against timing analysis. With this mitigation, variations in execution time cannot be traced back to an SSP, key, or secret data. Numeric Blinding protects RSA, DSA, and ECDSA from timing attacks, where attackers measure the time of signature operations or RSA decryption. To mitigate this attack, the module generates a random blinding factor that is provided as an input to the decryption/signature operation and is discarded once the operation has completed. With this mitigation, the execution time cannot be correlated to the RSA, DSA, or ECDSA key via a timing attack because the attacker does not know the blinding factor.

These mitigations should make the timing of the encryption, decryption, and signing operations independent of the key material or the input data. This should prevent an attacker from recovering information by measuring the timing of these operations.

While the module implements countermeasures to prevent timing analysis and timing attacks, other side-channel attacks may be possible. As a Level 1, software-based module, the module is limited in its ability to prevent access at the hardware level; power analysis attacks may be possible for an attacker with physical access. Users of software-based modules should be aware of these limitations and incorporate this information into their threat model. Document Version 1.1a © SafeLogic Inc.

Referenced URLs

• www.safelogic.com
• www.safelogic.com/cryptocomply
• https://csrc.nist.gov/projects/cryptographic-module-validation-program