Chainguard FIPS Provider for OpenSSL

Certificate

Approved Algorithms (73)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Chainguard FIPS Provider for OpenSSL
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Symmetric Encryption and Decryption<br/>Perform self- tests (All)<br/>Core (all except Teardown) (Show Status, Show…</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"]
    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"]
    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"]
    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
  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 C3,C5,C6 clue;
  class I3,I5,I6 infer;
  class R3,R5,R6 risk;
  class E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Chainguard FIPS Provider for OpenSSL
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Symmetric Encryption and Decryption<br/>Perform self- tests (All)<br/>Core (all except Teardown) (Show Status, Show…</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 C3 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Chainguard, Inc. Chainguard FIPS Provider for OpenSSL

Introduction Federal Information Processing Standards Publication 140-3

• Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140-3 program. The NVLAP accredits independent testing labs to perform FIPS 140-3 testing; the CMVP validates modules meeting FIPS 140-3 validation. Validated is the term given to a module that is documented and tested against the FIPS 140-3 criteria. More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program. About this Document for OpenSSL cryptographic module (hereafter referred to as “the Module”) from Chainguard, Inc. It contains specification of the security rules under which the Module operates, including the security rules derived from the requirements of the FIPS 140-3 standard. The OpenSSL Project may also be referred to as “OpenSSL” in this document. The following trademarks are referenced within this Security Policy:
• Linux®: Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
• Unix®: UNIX is a registered trademark of The Open Group.
• Microsoft Windows®: Windows is a registered trademark of Microsoft Corporation in the United States and other countries. © 2025 Chainguard, Inc. This document may be freely reproduced and distributed whole and intact including this OpenSSL 3.1.2 FIPS 140-3 Validation Contributors: KeyPair Consulting Inc

The Module meets FIPS 140-3 overall Level 1 requirements, with security levels as follows: Table 1: Security Levels N/A N/A

In accordance with AS02.05, [ISO19790] §7.7 Physical Security is optional and does not apply to the Module. In accordance with current CMVP policy, [ISO19790] §7.8 Non-Invasive Security is not applicable.

Purpose and Use: The Module is a cryptographic software library providing a C-language application program interface (API) for use by applications that require cryptographic functionality and is designated as a software module with a multi-chip standalone embodiment based on the descriptions of [ISO19790] AS02.03. The Module is intended for use by US and Canadian Federal agencies and other markets that require FIPS 140-3 validated cryptographic functionality. The Module’s formal name and version are “Chainguard FIPS Provider for OpenSSL ” and “3.1.2”, respectively. The Module design corresponds to the Module security rules. Security rules enforced by the Module are described in the appropriate context of this document. Module Embodiment: MultiChipStand

Cryptographic Boundary: Figure 1 depicts the Module operational environment, with the cryptographic boundary highlighted in red inclusive of all Module entry points (API calls). The Module is defined as a Software module per [ISO19790] AS02.03. The cryptographic boundary of the Module is the FIPS Provider, a dynamically loadable library. The Module performs no communication other than with the calling application via APIs that invoke the Module. The pre-operational approved integrity test is performed over all components within the cryptographic boundary. Tested Operational Environment’s Physical Perimeter (TOEPP): The Tested Operational Environment’s Physical Perimeter (TOEPP) is the General Purpose Computer. Figure 1: Chainguard FIPS Provider for OpenSSL Block Diagram

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets):

3.1.2 3.1.2 3.1.2 Table 2: Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments - Software, Firmware, Hybrid: Intel i78550U Intel i78550U Intel i78550U Intel i78550U Intel i710510U Intel i710510U Intel i710510U Intel i710510U N/A 3.1.2 N/A 3.1.2 N/A 3.1.2 N/A 3.1.2 N/A 3.1.2 N/A 3.1.2 N/A 3.1.2 N/A 3.1.2 N/A 3.1.2 N/A 3.1.2 N/A 3.1.2 N/A 3.1.2 Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: No operational environments are vendor affirmed.

No components are excluded from [FIPS140-3] requirements.

Modes List and Description: NonApproved NonApproved

1. Manual key entry is not supported.
2. Data output is inhibited during self-tests, zeroisation, SSP generation and error states.
3. The Module does not perform any cryptographic function if any self-test has failed. a. security-checks = 1 Enforce minimum key strengths and approved curve names. b. conditional-errors = 1 Enforce the Module entering the error state on conditional test errors such as PCT failure. c. drbg-no-trunc-md=1 Disallow use of truncated digests with HASH and HMAC DRBGs (IG D.R) d. tls1-prf-ems-check=1 Enforce Extended Master Secret (EMS) use with TLS 1.2 (IG D.Q)
4. The Module is a cryptographic library used by a calling application. The calling application is responsible for: a. Use of the primitives in the correct sequence. b. Use of keys in accordance with [SP800-140Dr2] (as the keys used by the Module for cryptographic purposes are provided over the call stack by the calling application). c. Use of a [SP800-90B] compliant entropy source. Entropy is supplied to the Module via callback functions. The callback functions return an error if the minimum entropy strength cannot be met.

Use of the Approved algorithms and Non-Approved Algorithms Allowed in the Approved Mode will ensure operation of the module in the Approved mode of operation. Use of the nonApproved Algorithms Not Allowed in the Approved Mode will place the module in the nonapproved mode of operation. Degraded Mode Description: The module does not support a degraded mode of operation.

Table 5: Approved Algorithms The Module implements the Approved cryptographic functions listed in Table 5. [FIPS 1864] [FIPS 1864] #3) #3)

#3) #3) N/A N/A 6.1 N/A N/A N/A N/A [FIPS 1864] [FIPS1864] Table 6: Vendor-Affirmed Algorithms

Non-Approved, Allowed Algorithms: Table 7: Non-Approved, Allowed Algorithms Non-Approved, Allowed Algorithms with No Security Claimed: N/A N/A N/A Table 8: Non-Approved, Allowed Algorithms with No Security Claimed The module does not support any Non-Approved Algorithms Allowed in the Approved Mode of Non-Approved, Not Allowed Algorithms: X942KDFCONCAT

Table 9: Non-Approved, Not Allowed Algorithms

SHA2512/224: SHA2512/256: HMAC-SHA2256)

[SP800-90Ar1]:SHA1 (s = 160), SHA2256 (s = 256), SHA2512 (s = 512) SHA3256 (s = 256), SHA3512 (s = 512) () 4: ()

(1):B-233, K-233, PResponder KAS-ECCSSC Sp80056Ar3:

KAS-FFCSSC Sp80056Ar3:

DigSigSigGen rsakpg2- primefactor CDHComponent

KAS-ECCSSC Sp80056Ar3: KAS-FFCSSC Sp80056Ar3: 6.1: ()

6.3: () Table 10: Security Function Implementations Equivalent strength in bits is given for each key or algorithm type (as some algorithms do not use or produce keys). The term s is used throughout to indicate security strength, following the notation used in the majority of the sources. Note 1: Preimage resistance strength applies to hash algorithms used in DRBG, KDFs. Described also in [SP800-57P1r5] Table

3. Note 2: Elliptic curve strengths are annotated as approximate (i.e., s ~=) since [SP800-186] Table 1 provides approximate security strengths. Note 3: [SP800-186] (cited in [SP800-140Cr2]) and [FIPS140-3_IG] C.K indicate that the Binary (B-) and Koblitz (K-) curves are deprecated. Note 4: Approved elliptic curves for ECC key agreement are given in [SP800-56Ar3] Table
4. Note 5: In Digital Signature applications, security strength is primarily associated with the asymmetric key pair specification. The hash function used must have equivalent strength equal to or greater than the security strength of the associated key pair. Note 6: Approved key types for FFC key agreement are given in [SP800-56Ar3] Tables 25,
5. The group notation of Table 26 is used for consistency with CAVP algorithm listings and ACVP capability registration. Note 7: Approved key types for IFC key agreement are given in [SP800-56Br2] Table
6. IFC key types approved for Digital Signature Generation and Verification are given also in [SP80057P1r5] Table
7. Equivalent strengths are annotated as approximate (i.e., s ~=) since [SP80056Br2] Table 4 provides approximate security strengths. Note 8: Security strengths for KDA One Step are given in [SP800-56Cr2] Table 1 (hash), Table

Note 9: Security strength for L=2048/N=256 is determined in accordance with [FIPS140-3_IG] D.B Strength of SSP Establishment Methods as y = min(x, N/2), where x is 112 and therefore y = min(112, 128) = 112. Other reference sources for the strengths are as follows:

• AES (AES-128, AES-192, AES-256): [SP800-57P1r5] Table 2.
• ECC (B-163, B-233, B-283, B-409, B-571, K-163, K-233, K-283, K-409, K-571, P-192, P-224, P-256, P-384, P-521): [SP800-186] Table 1.
• FFC (L=1024/N=160, L=2048/N=224, L=2048/N=256, L=3072/N=256): [SP800-57P1r5] Table 2.
• FFC (ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192, MODP-2048, MODP-3072, MODP-4096, MODP-6144, MODP-8192): [SP800-56Ar3] Tables 25 and 26.
• IFC (k=1024, k=2048, k=3072, k=4096, k=6144, k=8192): [SP800-56Br2] Table 4.
• KMAC (KMAC128, KMAC256): [SP800-56Cr2] Table 3.
• SHA-1, SHA2 (SHA2-224, SHA2-256, SHA2-384, SHA2-512, SHA2-512/224, SHA2-512/256): [SP800-107] Table 1.
• SHA3 (SHA3-224, SHA3-256, SHA3-384, SHA3-512): [SP800-57P1r5] Table 3.
• SHAKE (SHAKE128, SHAKE256): [SP800-185] Section 8.1.

a. AES-GCM Usage AES GCM IV generation must be compliant to [FIPS140-3_IG] C.H Key/IV Pair Uniqueness Requirements from SP 800-38D Scenario 1(a), tested per option (ii) under C.H TLS/DTLS 1.2 protocol IV generation per RFC7627, Scenario 1(d) SSHv2 per RFC4252, RFC4253 and RFC5647 and Scenario 5 TLS 1.3 per RFC8446. IV constructed in compliance with a protocol shall only be used in the context of the AESGCM mode encryptions within the protocol. The Module does not implement the TLS and SSH protocols itself, however, it provides the cryptographic functions required for implementing the protocols. AES GCM encryption is used in the context of the SSH and TLS protocol versions 1.2 and 1.3. The module provides the primitives to support the AES GCM ciphersuites from [SP800-52r1] Section 3.3.1. The module’s implementation of AES-GCM is used together with an application that runs outside the module’s cryptographic boundary. The application negotiates the protocol session’s keys and the 32-bit nonce value of the IV. When the IV exhausts the maximum number of possible values for a given session key (2^64 - 1), this results in a failure in encryption and a handshake to establish a new encryption key will be required. It is the responsibility of the user of the module, i.e., the first party, client or server, to encounter this condition, to trigger this handshake in accordance with the TLS/SSH protocol. The Module also supports internal IV generation using the module’s approved DRBG. The IV is at least 96 bits in length per [SP800-38D] Section 8.2.2. Per [FIPS140-3_IG] C.H Scenario 2 and [SP800-38D], the approved DRBG generates outputs such that the (key, IV) pair collision probability is less than 2^-32. In each case, in the event that the Module power is lost and restored the user must ensure that the AES GCM encryption/decryption keys are re-distributed in accordance with IG C.H Scenario 3. The module does not support persistent storage of SSPs. The Module also supports importing of GCM IVs when an IV is not generated within the Module. In the approved mode, an IV must not be imported for encryption from outside the cryptographic boundary of the Module as this will result in a non-conformance. This

is in accordance with IG 2.4.A: If the module operator (e.g., calling application) can do things outside of the module’s control/visibility that can take an otherwise approved algorithm and use it in a non-approved way (e.g., use PBKDF and/or AES XTS outside of storage applications), the corresponding module service may still be considered approved (and if so, shall have an approved indicator per AS02.24) and the Security Policy shall clarify how to use the service in an approved manner (per ISO 19790 B.2.2 on Overall security design and the rules of operation). b. PBKDF Usage The lower limit on the supported length of a password/passphrase used in key derivation is 1-character. The ASCII system comprises of 94 printable characters (letters, digits, punctuation, and symbols). For a 1-character password/passphrase chosen from 94 printable ASCII characters, the total combinations are: 94^1. Thus, the probability of guessing the correct password/passphrase on a random attempt is: 1/94^1 ~0.010. The module being a software module, does not restrict the usage of a password/string used as the password and input to the PBKDF. The onus is on the calling application to provide a password of an appropriate length based on the intended security strength (and size) of the key to be derived. In accordance with NIST SP 800-132, passwords shorter than 10 characters are usually considered to be weak. There are many other properties that may render a password weak. For example, it is not advisable to use sequences of numbers or sequences of letters as passwords. Easily accessed personal information, such as the user’s name, phone number, and date of birth, should not be used directly as a password. Passphrases frequently consist solely of letters, but they make up for their lack of entropy by being much longer than passwords, typically 20 to 30 characters. Passphrases shorter than 20 characters are usually considered weak. The module complies with NIST SP 800-132 Section 5.4 Option 1 a and IG D.N. The iteration count values used range from 1 to 10000 per NIST SP 800-132 Section 5.2 whereby the iteration count shall be selected as large as possible, as long as the time required to generate the key using the entered password is acceptable for the users. Keys derived from passwords, as shown in SP 800-132, may only be used in storage applications. The security strength of the derived key is at least 112 bits. The module implements CKG per NIST SP 800-133r2 Section 6.2.2. c. AES-XTS Usage Usage In accordance with [SP800-38E], the XTS-AES algorithm shall only be used for confidentiality on storage devices. The Module complies with [FIPS140-3_IG] C.I by explicitly checking that Key_1 ≠ Key_2 before using the keys in the XTS-AES algorithm to process data with them. The module implements CKG per NIST SP 800-133r2 Section 6.3. d. Legacy Usage The module supports the following implementations for legacy use/support per NIST SP 800-131Ar2:

• RSA (modulus 1024 bits), DSA (modulus 1024 bits), ECDSA (B-163, K-163 and P-192, curves) digital signature verification providing less than 112 bits of security strength.

• RSA, ECDSA and DSA digital signature verification with SHA-1 used as the underlying hash algorithm. e. Component Validation List (CVL) In accordance with IG 2.4.B, all tested components that may be called during the operation of the module and shown in the module’s CVL certificates have been listed individually in Table 5. All vendor affirmed components that may be called during the operation of the module have also been listed individually in Table 6 per IG 2.4.B. f. FIPS 202 Usage In accordance with IG C.C Resolution 2. a., each SHA-3 and SHAKE function has been tested and validated on all of the module’s operating environments. Per Resolution 2. c., SHA-3 hash functions used as part of the higher-level DRBG algorithms for which the CAVP testing is not yet available have been vendor affirmed as documented in Table 6. g. RSA Usage
• Per IG C.E, the module generates RSA signature keys using an approved key generation procedure per RSA KeyGen validated for conformance to FIPS 186-4 Cert. #A3548.
• Per IG C.F, the RSA SigGen and SigVer implementations have been tested for all implemented RSA modulus lengths where CAVP testing is available. The module supports generation of RSA keys with the following untested approved moduli/sizes: 4096 <nlen<= 16384. The module also supports the following untested, approved moduli for the RSA SigGen and SigVer: 4096 <nlen<= 16384. h. TLS 1.2 KDF In accordance with IG D.Q, the module has been implemented to enforce usage of the extended master secret in the TLS 1.2 KDF as specified per Section 2.4.1. d. (tls1-prfems-check set option set to 1 due to initialization of the module per Section 11). The module complies with RFC 7627. i. DRBG Usage Per IG D.R, the Hash_DRBG and HMAC_DRBG implementations use SHA-1, SHA2256, SHA2-512, SHA3-256 and SHA3-512. j. NIST SP 800-108 KDF Usage The SP 800-108 KDF is not used to generate asymmetric keys directly in that the module restricts generation of keys to approved methods only. For keys passed into the module, the onus lies on the calling application to ensure correct generation of such keys using approved mechanisms. The module implements CKG per NIST SP 800133r2 Section 6.2.3. k. SHA-1 Usage: The module implements SHA-1 for usage in the following (this can be vetted from the SFI Table 9 in the Security Policy): I. II. As a PRF in the KDFs X942 KDF-CONCAT, X963 KDF, KDA HKDF, KDA OneStep, KDF, ANS 9.42 [SP800-135r1], KDF SSH [SP800-135r1], PBKDF [SP800-132], As a standalone SHA-1 hash function

III. IV. V. As a PRF in HMAC-SHA-1 As the underlying hash function for RSA SigVer, ECDSA SigVer and DSA SigVer for legacy use/support per NIST SP 800-131Ar2 as specified in the Security Policy Section 2.7 d. As the underlying hash function in Hash DRBG and HMAC DRBG

The Module relies on the use of a [SP800-90B] compliant entropy source outside the Module boundary. The calling application is responsible for use of an [SP800-90B] compliant entropy source with sufficient entropy based on the required security strength. Entropy is supplied to the Module via callback functions (see Section 2.4 2. c). Minimum Number of Bits of Entropy, depending on the target security strength of generated SSPs are 128, 192 or 256 bits. When using the Counter DRBG implementation without the derivation function enabled, full entropy from the entropy source is required. The following caveat applies to the module: No assurance of the minimum strength of generated SSPs (e.g., keys).

The module implements NIST SP 800-90Ar1 DRBGs and supports the following sections per NIST SP 800-133r2 (CKG): Sections 4, 5.1, 5.2, 6.1, 6.2 and 6.3.

Key Agreement Per IG D.F: The module supports Key Agreement Schemes per NIST SP800-56Ar3 and [FIPS140-3_IG] D.F Scenario 2 (path 1) and NIST SP 800-56Br2 and [FIPS140-3_IG] D.F Scenario 1 (path 1). The KAS-1, KAS-2, KAS-3 in the SFI Table 9 have been documented accordingly. The Approved Algorithm list includes the tested components (KAS-ECC-SSC, KAS-FFC-SSC and KAS-IFC-SSC) as individual entries. The Module obtains the [FIPS140-3_IG] D.F required key agreement assurances: [SP800-56Ar3] in accordance with Section 5.6.2. [SP800-56Br2] in accordance with Section 6.4. Per IG C.F Additional Comment 1.e: The elliptic curve used in the key agreement scheme and the associated domain parameters provide more than 112 bits of security as seen in the KAS-1 entry per Table

9. Per IG C.F Additional Comment 2: The KAS-ECC-SSC and KAS-FFC-SSC implementations each support a scheme of the DiffieHelllman variety. Per IG D.G: The module supports the Key Transport per NIST SP 800-56Br2 (RSA-OAEP) denoted by KTS4 in the SFI Table
10. The RSA modulus sizes and key generation method have been

documented in the table as well. The module can also optionally be used in the context of IETF protocols and provide key transport using any approved AES mode(s) and an approved MAC. The corresponding entries KTS-1, KTS-2 and KTS-3 in the SFI Table 9 have been documented accordingly. All KTS entries have been documented in accordance with Additional Comment 4 in the IG. The module also supports the following untested approved moduli for KTS-4: 6144 < nlen <=16384, where nlen denotes the modulus. Per IG D.A and IG D.B: The strengths of the established key have been documented in accordance with IG D.A Additional Comment 4. and per the Resolution in IG D.B.

The Module conforms to Resolution 3 per [FIPS140-3_IG] D.C References to the Support of Industry Protocols: while it provides [SP800-56Ar3] conformant schemes and API entry points oriented to SSH and TLS usage, the Module does not contain the full implementation of SSH or TLS. The following caveat is required: No parts of the SSH and TLS protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

N/A N/A N/A N/A Table 11: Ports and Interfaces Table 11 defines the Module’s [FIPS140-3] logical interfaces; the Module does not interact with physical ports. The Control Output logical interface is not applicable to the Module and is intentionally omitted from Table 11.

The Module does not provide an authentication or identification method of its own. The CO role is assumed by meeting the conditions of Section 11 of this document.

Table 12: Roles The Module supports the mandatory Cryptographic Officer (CO) operational role only (implicitly identified) and does not support a maintenance role or a bypass capability.

r s [KTSIFC: K); K) [AESECB: AES128ECB, AES192ECB, AES256ECB]; [AESCBC: AES128CBC, AES192CBC, AES256CBC]; [AESCBCCS: c n :Z K: E K: E R :E E

r AES128CBCCTS, AES192CBCCTS, AES256CBCCTS]; [AESOFB: AES128OFB, AES192OFB, AES256OFB]; [AESCFB1: AES128CFB1, AES192CFB1, AES256CFB1]; [AESCFB8: AES128CFB8, AES192CFB8, AES256CFB8]; [AESCFB128: s

r 128CFB, AES192CFB, AES256CFB]; [AESCTR: AES128CTR, AES192CTR, AES256CTR]; [AESCCM: AES128CCM, AES192CCM, AES256CCM]; [AESGCM: AES128GCM, AES192GCM, AES256GCM]; [AESXTS: AES128XTS, s

r [AESKW, AES128WRAP, AES256WRAP] , (SHA1, SHA2224, SHA2256, SHA2384, SHA2512, SHA2512/224, SHA2512/256, SHA3224, SHA3256, SHA3384, SHA3512)]; [TLS1PRF, (SHA2256, SHA2384, SHA2512)]; [TLS13KDF, (SHA2256, SHA2384)]; s n W,E : G,R W,E d: W,E,Z

r [X963KDF, (SHA2224, SHA2256, SHA2384, SHA2512)]; SHA2224, SHA2256, SHA2384, SHA2512, SHA2512/224, SHA2512/256, SHA3224, SHA3256, SHA3384, SHA3512)]; SP 800108r1 (KMAC128, KMAC256)]; SP 800108r1 s

r AES128CBC, AES192CBC, AES256CBC, HMACSHA1, HMACSHA2224, HMACSHA2256, HMACSHA2384, HMACSHA2256, HMACSHA2384, HMACSHA2512, HMACSHA2512/224, HMACSHA2512/256, HMACSHA3224, HMACSHA3256, HMACSHA3384, s

r HMACSHA3512]; F, SHA2224, SHA2256, SHA2384, SHA2512)]; SHA2224, SHA2256, SHA2384, SHA2512, SHA2512/224, SHA2512/256, SHA3224, SHA3256, SHA3384, SHA3512, HMACSHA1, HMACSHA2224, HMACSHA2256, s

r HMACSHA2384, HMACSHA2512, HMACSHA2512/224, HMACSHA2512/256, SHA3224, SHA3256, SHA3384, SHA3512, KMAC128, KMAC256)]; SHA2224, SHA2256, SHA2384, SHA2512, SHA2512/224, SHA2512/256, SHA3224, SHA3256, SHA3384, s

r SHA3512]; SHA2224, SHA2256, SHA2384, SHA2512, SHA2512/224, SHA2512/256, SHA3224, SHA3256, SHA3384, SHA3512]; [KASFFCSSC: [KASECCSSC: s A: c) G n

r HMACSHA1, HMACSHA2224, HMACSHA2256, HMACSHA2384, HMACSHA2512, HMACSHA2512/224, HMACSHA2512/256, HMACSHA3224, HMACSHA3256, HMACSHA3384, HMACSHA3512]; KMAC128, s E

r AES128GCM, AES192GCM, AES256GCM] SHA2224, SHA2256, SHA2384, SHA2512, SHA2512/224, SHA2512/256, SHA3224, SHA3256, SHA3384, SHA3512, SHAKE128, SHAKE256] HASHDRBG, SHA2256, SHA2512)]; [HMACDRBG, s I n I: E

r SHA2256, SHA2512)]; [CTRDRBG, (AES128CTR, AES192CTR, AES256CTR)] (SHA2224, SHA2256, SHA2384, SHA2512, SHA2512/224, SHA2512/256) SHA2224, SHA2256, SHA2384, s K); n n n :E E

r SHA2512/224, SHA2512/256) e m: (SHA2224, SHA2256, SHA2384, SHA2512, SHA3224, SHA3256, SHA3384, SHA3512)]; SHA2224, SHA2256, SHA2384, SHA2512, SHA2512/224, s

r SHA2512/256) ]; (L= SHA2224, SHA2256, SHA2384, SHA2512, SHA2512/224, SHA2512/256) , =SHA2256, SHA2384, SHA2512, SHA2512/256) s

r (L= (SHA2224, SHA2256, SHA2384, SHA2512, SHA2512/224, SHA2512/256) SHA2224, SHA2256, SHA2384, SHA2512, SHA2512/224, SHA2512/256) ] s -

r Table 13: Approved Services s Note: The Indicators in Table 13 above follow the format: [Algorithm name: Indicator 1, Indicator 2, etc.] where Indicator 1 is an algorithm identifier and Indicators 2, 3 etc. depending on the algorithm are the specifics i.e. modes/supported curves/SafePrime groups/PRFs, etc.) per algorithm. Each combination of the Indicator 1 along with Indicators 2, 3, etc. in the comma separated list can be observed when the corresponding modes/curves/SafePrimes, PRFs etc. are invoked for a given algorithm in the context of a given service. The service indicators must be requested by the calling applications as by calling the following EVP APIs of the module in the context of each service:

• Hash (SHA) algorithms:
• EVP_MD_get0_name
• Symmetric encryption algorithms (all AES modes, expect CMAC):
• EVP_CIPHER_get0_name
• MAC algorithms (KMAC, HMAC, CMAC):
• EVP_MAC_get0_name
• Key Derivation algorithms (KDFs):
• EVP_KDF_get0_name used in conjunction with either of  EVP_MAC_get0_name (for a MAC as the PRF)  EVP_MD_get0_name (for Hash as the PRF)
• Key Exchange (KAS-ECC-SSC, KAS-FFC-SSC, KAS-IFC, SafePrimes), Key Generation (RSA, ECDSA, DSA):
• EVP_PKEY_get0_type_name for ECDSA/KAS-ECC-SSC/KASIFC/RSA/DSA/KAS-FFC-SSC
• EVP_PKEY_get_bits for RSA/DSA/IFC modulus size
• EVP_PKEY_get_bn_param for DSA N value.
• Signature Generation/Verification (RSA, ECDSA, DSA):
• EVP_PKEY_get0_type_name used in conjunction with EVP_MD_get0_name
• EVP_PKEY_get_bits for RSA/DSA modulus size
• EVP_PKEY_get_bn_param for DSA N value.
• ECDSA Signature Generation Component:
• EVP_PKEY_get0_type_name and
• EVP_MD_get0_name (returns null to indicate that a hash is not used)
• Random bit generators:

EVP_RAND_get0_name used in conjunction with  EVP_MD_get0_name for Hash and HMAC DRBG or  EVP_CIPHER_get0_name for Counter DRBG. Key Transport (OEAP):

• EVP_PKEY_get0_type_name used in conjunction with  EVP_PKEY_get_bits for RSA modulus size and  EVP_PKEY_CTX_get_rsa_padding for padding (returns 4 to indicate OEAP). RSA Signature Primitive:
• EVP_MD_get0_name and
• EVP_PKEY_get_bits for RSA modulus size and
• EVP_MD_get0_name (returns null to indicate that a hash is not used) DSA PQGGen:
• EVP_PKEY_get_bits for L and
• EVP_PKEY_get_bn_param for N DSA PQGVer:
• EVP_PKEY_get_bn_param for N o
• The OpenSSL toolkit OSSL_PROVIDER_get_params function when called with the Module’s global handle and a pointer to a parameter structure (initialized using provider_gettable_params or the equivalent), can be used to retrieve the current status of the Module as well as the name and version; this information correlates to the validation listing. A 1 value returned in status indicates the Module is running without error (FIPS_OK); a 0 return indicates an error (with additional error details indicated as described in the release specific API documentation). Services are only operational in the running state. Any attempts to access services in any other state will result in an error being returned. If the integrity test or any CAST fails then any attempt to access any service will result in an error being returned. Table 12 describes Module service access to SSPs; ‘--’ indicates the cell is intentionally empty, not applicable or not relevant. The following annotations indicate the type of access by the Module service:
• G = Generate: The Module generates or derives the SSP.
• R = Read: The SSP is read from the Module (e.g. the SSP is output).
• W = Write: The SSP is updated, imported, or written to the Module.
• E = Execute: The Module uses the SSP in performing a cryptographic operation.
• Z = Zeroise: The Module zeroises the SSP. Regarding the Indicator of approved security services, the Module conforms to [FIPS140-3_IG] 2.4.C Approved Security Service Indicator, similar to example 2. The Module’s name and version parameters (as cited in Section 2) along with the Module’s internal indicators of the security-check and conditional-errors settings are used to confirm the Module is the validated Module. Each service provides context sensitive status responses as described in the OpenSSL 3 API manual pages; generally, functions of return type int return the value 1 for success with other error codes as appropriate for the call (described in API documentation).

Note that the caller provides the KAS_Private and KAS_Public keys for shared secret computation; the caller’s exchange and assurance of PSPs with the remote participant is All CSPs are zeroized (overwritten with 0s) when they are no longer needed:

• Temporary copies of CSPs are zeroised within the relevant function for the scope within which they are used.
• CSPs with a lifetime associated with an OpenSSL object (e.g., EVP_PKEY) will be zeroized when reinitialized. Teardown operation).
• The OPENSSL_cleanse function is used to zeroise CSPs owned by the caller. Table 14: Non-Approved Services

The module does not support loading of any additional software. X942KDFCONCAT

The module does not support bypass.

The module does not support self-initiated cryptographic output.

The Module uses HMAC-SHA2-256 as the approved integrity technique; the file fipsmodule.cnf contains the integrity reference value. The HMAC key used for the integrity test is considered a non-SSP. The HMAC-SHA2-256 CAST is performed prior to the software integrity test. The Module is provided in an executable form (as fips.so shared object for use in Linux environments, fips.dylib for use in Mac environments and fips.dll for use in Windows environments). The module does not support loading of any additional software.

The operator can initiate the integrity test on demand by calling fips_self_test (invoked using OSSL_PROVIDER_self_test called with the Module’s global handle) or reloading the Module.

In accordance with [ISO19790] Annex B, as the Module is open source, the tools used to build the Module as tested are:

• gcc version 9.3.0
• perl v5.30.0
• gnu make v4.2.1 Compilers Used for Each Operational Environment The specific compilers used to generate the Module for the respective operational environments are listed below:
• Ubuntu Linux 22.04.1 Server: gcc 11.2.0
• Debian 11.5: gcc 10.2.1
• FreeBSD 13.1: clang 11.0.1
• Windows 10: Visual Studio 2019
• macOS 11.5.2 (M1): clang 12.0.5
• macOS 11.5.2 (i7): clang 12.0.5

Type of Operational Environment: Modifiable How Requirements are Satisfied : The operational environment for the Module is modifiable as it runs in General Purpose Computers (GPC). The Module conforms to [FIPS140-3_IG] 2.3.C Processor Algorithm Accelerators (PAA) and Processor Algorithm Implementation (PAI). The AES-NI functions are identified by [FIPS140-3_IG] 2.3.C as a known PAA.

Table 3 lists the operational environments on which the Module was tested; no operational environment restrictions are required for operation in the approved mode. All conditions for operation of the Module in the approved mode are given in Section 2.

Physical Security requirements are not applicable for this software Module.

In accordance with current CMVP policy, Non-Invasive Security is not applicable.

S t c r t N/A N/A m Table 16: SSP Input-Output Methods The module is complaint with FIPS 140-3 IG 9.5.A MD/EE (CM Software to/from App via TOEPP Path).

Table 17: SSP Zeroization Methods

c n DiffieHellman [SP80056Br2]: 112, DiffieHellman y

n [SP80056Br2] RSA [SP80056Br2] RSA y n

n HMACSHA2-256 y Table 18: SSP Table 1 n

n n Table 19: SSP Table 2 All SSPs used by the Module are described in this section, arranged for consistency with Table 12; ‘--’ indicates the cell is intentionally empty, not applicable, or not relevant. Keys used for CASTs and the temporary value used in the integrity test are not SSPs; however, the latter is deleted after use as required by AS05.10. Equivalent strength is given for each key or algorithm type (as some algorithms do not use or produce keys). The Module maintains only the DRBG CSPs used for key generation as persistent CSPs; these are used exclusively for approved services. DRBG outputs are used internally to the Module for asymmetric key pair generation and used by calling applications to generate a random value (potentially for use as a symmetric key).

• Produces random values in accordance with [SP800-133r2] Section 4, in that the DRBG output is provided directly as the random output.
• SSPs used with symmetric key algorithms are provided by the calling application.
• Produces asymmetric keys in accordance with [SP800-133r2] Section 5, in that all asymmetric keys generated by the module (the Key management service) provide the output of the approved key generation algorithm with no post-processing or manipulation of the generated key pairs. As noted in the previous item, random values used in the asymmetric key generation algorithms are direct outputs of the DRBG. Keys produced by the module use an internal Counter DRBG for which the minimum key size and equivalent security strength is 128 bits.
• Supports direct generation of symmetric keys in accordance with [SP800-133r2] Section 6.1 and symmetric key derivation in accordance with [SP800-133r2] Section 6.2, using the approved and CAVP listed KDF algorithms. AES-KTS keys are generated in accordance with [SP800-133r2] Section 6.3.

Table 20: Pre-Operational Self-Tests The module is complaint with FIPS 140-3 IG 10.2.A in that it performs a self-test, a Known

(FIPS1864) (A3548) (FIPS1864) (A3548) (FIPS1864) (A3548) (FIPS1864) (A3548) HMACSHA-1 HMACSHA2-256 KASECC-SSC Sp80056Ar3 KAS-FFCSSC Sp80056Ar3 Curve: P256 HMACSHA2-256 KAS-IFCSSC SP800108 (HMACSHA2-256).

SP80056Cr2 SP80056Cr2 (FIPS1864) (A3548) (FIPS1864) (A3548) H = SHA2224 H= HMACSHA2-256

(FIPS1864) (A3548) PRF: SHA1 (FIPS1864) (A3548) (FIPS1864) (A3548) (FIPS1864) (A3548) (FIPS1864) (A3548) Table 21: Conditional Self-Tests Each time the Module is powered up it tests that the cryptographic algorithms still operate correctly and that sensitive data has not been damaged. On instantiation, the Module performs the pre-operational self-tests and all CASTs listed above. All KATs must complete successfully prior to any other use of cryptography by the Module.

Table 22: Pre-Operational Periodic Information

Table 23: Conditional Periodic Information

The operator can reload the module or the fips_self_test function (inclusive of software integrity verification) can also be called on demand, fulfilling AS05.11.

The Module is provided to vendors who integrate it into their product, typically in a manufacturing environment, and is not provided directly to US or Canadian Federal agencies. Adherence to the instructions in this document maintains security throughout the distribution, build, installation and configuration processes. An authorized Cryptographic Officer is required to perform these steps on each platform where it is intended to be used. The config file output contains information about the Module (such as the self-test status and the Module checksum) and must not be manually modified without using the openssl fipsinstall command. Crypto Officer Guidance a. Installation and Usage Guidance The Module is installed as part of the OpenSSL 3.1.2 library. The source distribution package is located at https://www.openssl.org/source/openssl-3.1.2.tar.gz. The Chainguard FIPS Provider for OpenSSL can be installed on the Tested Configurations listed in Table 3 by performing the following steps: 1. Build and install OpenSSL 3.1.2 to the default location: The Chainguard FIPS Provider for OpenSSL (i.e., the Module) does not get built and installed automatically. To install the Module automatically during the normal OpenSSL 3.1.2 installation process it must be enabled by configuring OpenSSL using the ‘enable-fips’ option. Unix/Linux/macOS: $ perl -i -pe "s/OpenSSL FIPS Provider/Chainguard FIPS Provider for OpenSSL/" providers/fips/fipsprov.c test/drbgtest.c $ ./Configure enable-fips $ make $ make install Windows: $ perl -i -pe "s/OpenSSL FIPS Provider/Chainguard FIPS Provider for OpenSSL/" providers\fips\fipsprov.c test\drbgtest.c $ perl Configure enable-fips $ nmake $ nmake install

The ‘install_fips’ make target can also be invoked explicitly to install the FIPS Provider independently, without installing the rest of OpenSSL: $ make install_fips Note: The instructions for building and installing OpenSSL 3.1.2 on other platforms can be found in the platform-specific guidance provided in INSTALL.md and README-FIPS.md in the OpenSSL 3.1.2 distribution package. Please see Appendix A for further information on porting the Module to platforms apart from the Tested Configurations in Table 3. 2. Verify the version: $ openssl version -v The Installation of the Chainguard FIPS Provider for OpenSSL that occurs as a result of Step 1 above ensures that the shared library and the configuration file containing information about the Module (e.g., the Module checksum) is copied to its installed location. To install the configuration file to a non-default location, this can be achieved by running the ‘fipsinstall’ command line application manually: $ openssl fipsinstall -pedantic Please see fipsinstall.html /docs/man3.1/man1/openssl-fipsinstall.html for options supported for the ‘openssl fipsinstall’ command. Note: The software integrity check (per Section 5 of this document) is performed using HMACSHA2-256 on the Module file to validate that the Module has not been modified. The integrity value is compared to a value written to the config file during installation. b. CVEs The publication of a CVE does not require immediate re-validation or maintenance in the CMVP process. The module may be updated in the field as needed depending on the severity or consequences of the CVE. The Module will be kept up to date with re-validation and maintenance as required, generally bundling fixes for known CVEs in a next release. The OpenSSL organization maintains a Vulnerabilities page which describes known vulnerabilities and potential resolution. These are reported to the NVD, where they are independently assessed. The OpenSSL group publishes fixes for these vulnerabilities according to their triage process. c. Miscellaneous The module performs run-time checks related to enforcement of security parameters such as the minimum-security strength of keys, valid key sizes, and usage of approved curves. These checks shall not be disabled (by using OPENSSL_NO_FIPS_SECURITYCHECKS or any other method). Validation of domain parameters prior to generating keys using functions provided by the module is the responsibility of the Cryptographic Officer and not enforced by the module itself.

No additional guidance applies for the operation of the module apart from that specified in Sections 2, 3 of this document and other subsections under this section.

No additional guidance applies for the operation of the module apart from that specified in Sections 2, 3 of this document and other subsections under this section.

No additional rules apply for the operation of the module apart from those specified in the remainder of this section and Section 2.4 of this document.

No maintenance requirements apply for operation of the module in the Approved/non-Approved modes as defined above.

Module Sanitization and Destruction Sanitization is defined in [ISO19790] as “... the process of removing sensitive information (e.g. SSPs, user data, etc.) from the module, so that it may either be distributed to other operators or disposed.” The Module itself does not manage persistent SSPs, authentication data or any user data. The Module may be securely sanitized by deletion of the folder in which the Module was located. There are no additional procedures required for secure destruction of the Module.

The Module implements mitigations for some types of attacks using the constant-time implementations and blinding. Constant-time implementations protect cryptographic implementations in the Module against timing analysis since such attacks exploit differences in execution time depending on the cryptographic operation, and constant-time implementations ensure that the variations in execution time cannot be traced back to the key, CSP or secret data. Numeric blinding protects the RSA, DSA and ECDSA algorithms from timing attacks. These algorithms are vulnerable to such attacks since attackers can measure the time of signature operations or RSA decryption. To mitigate this, the Module generates a random blinding factor which is provided as an input to the decryption/signature operation and is discarded once the operation has completed and resulted in an output. This makes it difficult for attackers to

attempt timing attacks on such operations without the knowledge of the blinding factor, and therefore the execution time cannot be correlated to the RSA/DSA/ECDSA key.

Referenced URLs

• https://csrc.nist.gov/projects/cryptographic-module-validation-program
• https://www.openssl.org/source/openssl-3.1.2.tar.gz