Cohesity FIPS Object Module

Certificate

Approved Algorithms (101)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Cohesity FIPS Object Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Self‐test<br/>failure</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Cipher (Unauth)<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/>DTLS</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 Cohesity FIPS Object Module
  %% 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>Self‐test<br/>failure</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Cipher (Unauth)<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/>DTLS</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

Cohesity, Inc. Cohesity FIPS Object Module FIPS 140‐3 Non‐Proprietary Security Policy Document Version 1.1 January 8, 2025 Prepared for: Prepared by: Cohesity, Inc.

Suite 1700 San Jose, CA 95110 cohesity.com KeyPair Consulting Inc.

San Luis Obispo, CA 93401 +1 805.316.5024 keypair.us This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module Table of Contents 1.1 1.2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 6.1 5.1 5.2 5.3 4.1 4.2 4.3 4.4 4.5 3.1 9.1 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy 9.2 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 Cohesity FIPS Object Module This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module List of Tables List of Figures This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module

This document defines the Non‐Proprietary Security Policy for the Cohesity FIPS Object Module by Cohesity, Inc., hereafter denoted the Module. The Module meets FIPS 140‐3 overall Level 1 requirements, with security levels as shown in Section 1.2. In accordance with AS02.05, ISO/IEC 19790:2012 §7.7 Physical Security is optional and does not apply to the Module.

Purpose and Use: The Module is a cryptographic software library, intended for use by US and Canadian Federal agencies and other markets that require FIPS 140‐3 validated cryptographic functionality. 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 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module 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 AS02.03. The pre‐operational approved integrity test is performed over all components within the cryptographic boundary. Tested Operational Environment’s Physical Perimeter (TOEPP): The General Purpose Computer is the TOEPP. Figure 1: Block Diagram This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): N/A Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments ‐ Software, Firmware, Hybrid: Table 3: Tested Operational Environments ‐ Software, Firmware, Hybrid

N/A for this Module. Modes List and Description: Table 4: Modes List and Description The Module only supports an Approved mode of operation. The conditions for using the Module in the Approved mode of operation are: 1. Installation of the Module as described in Section 11.1 results in the settings described below, which are required for operation in the Approved mode: a. security‐checks = 1 Enforce minimum key strengths and approved curve names. b. allow‐plaintext‐csp‐output = 1 Enforce the AS09.16 and AS09.17 requirement for a second independent action to output CSPs as a result of calls that produce CSPs, such as key generation, key unwrap (or decapsulate) and shared secret calculation. c. conditional‐errors = 1 Enforce the Module entering the error state on conditional test errors such as PCT failure. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module 2. 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 SP 800‐140D Rev. 2 (as the keys used by the Module for cryptographic purposes are provided over the call stack by the calling application). c. Use of a SP 800‐90B compliant entropy source outside the Module boundary with at least 256 bits of security strength. Entropy is supplied to the Module via callback functions. The callback functions shall return an error if the minimum entropy strength cannot be met.

Approved Algorithms: Cipher This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module Table 5: Approved Algorithms ‐ Cipher Key agreement Table 6: Approved Algorithms ‐ Key agreement Key derivation This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module Table 7: Approved Algorithms ‐ Key derivation Key management This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module Table 8: Approved Algorithms ‐ Key management Message authentication This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module Table 10: Approved Algorithms ‐ Message authentication Message digest Table 11: Approved Algorithms ‐ Message digest This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module Random Table 12: Approved Algorithms ‐ Random Table 13: Approved Algorithms ‐ Signature This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module Vendor‐Affirmed Algorithms: Table 14: Vendor‐Affirmed Algorithms Non‐Approved, Allowed Algorithms: N/A for this module. Non‐Approved, Allowed Algorithms with No Security Claimed: N/A for this Module. Non‐Approved, Not Allowed Algorithms: N/A for this Module.

This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module Table 15: Security Function Implementations This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module

AES‐GCM: The Module supports internal IV generation using the Approved DRBG. The IV is at least 96 bits in length per SP 800‐38D Section 8.2.2, and the Approved DRBG generates outputs such that the (key, IV) pair collision probability is less than 2‐32 per SP 800‐38D Section 8. AES‐GCM IVs shall be used in compliance with FIPS 140‐3 IG C.H scenario 1a (TLS/DTLS 1.2, per RFC 5288), 1d (SSHv2, per RFC 5647) and 5 (TLS 1.3, per RFC 8446). The Module is compatible with TLS/DTLS 1.2 protocol and provides the primitives to support the AES GCM ciphersuites from SP 800‐52 Rev. 1 Section 3.3.1. The Module’s implementation of AES‐GCM is used together with one or more applications outside the Module’s cryptographic boundary that implement the specified protocols; these protocols have not been reviewed or tested by the CAVP and CMVP. In each of the protocols, if the Module’s power is lost and then restored, the key used for the AES GCM encryption/decryption shall be re‐distributed. This condition is not enforced by the Module but is met implicitly. The Module does not retain any state across reset or power‐cycles: AES‐GCM key/IVs are not stored in non‐volatile persistent memory (i.e., disk), hence no re‐connection can occur without a fresh key establishment operation and the associated SSPs. The Module explicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values of 264‐1 for a given session key. If this exhaustion condition is observed, the Module returns an error indication to the calling application, which will then need to either abort the connection, or trigger a handshake to establish a new encryption key. XTS‐AES: In accordance with SP 800‐38E, the XTS‐AES algorithm is to be used for confidentiality on storage devices. The Module complies with FIPS 140‐3 IG C.I by:   Generating Key_1 and Key_2 independently according to the rules for component symmetric keys from SP 800‐133 Rev. 2, Section 6.3. Explicitly checking that Key_1 ≠ Key_2 before using the keys in the XTS‐AES algorithm to process data with them. Key Agreement: The Module implements the following Approved key agreement methods which have been CAVP tested and validated:    KAS‐ECC‐SSC per SP 800‐56A Rev. 3 (FIPS 140‐3 IG D.F Scenario 2, path 1). KAS‐FFC‐SSC per SP 800‐56A Rev. 3 (FIPS 140‐3 IG D.F Scenario 2, path 1). KAS‐IFC‐SSC per SP 800‐56B Rev. 2 (FIPS 140‐3 IG D.F Scenario 1, path 1). The Module obtains the FIPS 140‐3 IG D.F required key agreement assurances:   SP 800‐56A Rev. 3 in accordance with Section 5.6.2. SP 800‐56B Rev. 2 in accordance with Section 6.4. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module PBKDF: The implemented PBKDF uses Option 1a specified in SP 800‐132 Section 5.4. FIPS 140‐3 IG D.N SP 800‐132 Password‐Based Key Derivation for Storage Applications notes that: The strength of the Data Protection Key is based on the strength of the Password and/or Passphrase used in key derivation. SP 800‐132 does not impose any strictly defined requirements on the strength of a password. It says that “passwords should be strong enough so that it is infeasible for attackers to get access by guessing a password.” The choice to use the PBKDF with a password or passphrase is entirely outside the scope of the Module, managed by the calling application

• and potentially would need to accommodate not only application‐level considerations, but end use environment considerations and policies as well. As examples, the end use environment may impose policies to reject words found in a dictionary, to use specific types of characters (upper case, lower case, punctuation) and so on. The Module does not enforce a reduced character space (referring to the set of allowed characters), and as such, any policy to restrict the character space weakens the potential strength of the derived Data Protection Key (KD_PW_PBKDF). In the summary of password strength guidance below, the term useful refers to characters which are not simply padding the string, for example with some combination of repetitive characters
• such means of skirting organizational policies are not recommended. The phrase character space refers to the set of characters that a password or passphrase is constrained to. The printable character space is assumed to be 95 printable characters. Integrators making use of PBKDF with this Module shall determine password policy and input length based on the intended output key size and strength, taking into consideration the probability of guessing KD_PW_PBKDF. The following examples are provided to guide parameter selection:     1/(2256) = 8.6E‐78 for a 32‐byte KD_PW_PBKDF field with no character space restriction (equivalent to a 256‐bit symmetric key). 1/(9518) = 2.5E‐36 for KD_PW_PBKDF with 18 useful printable characters (better than a 112‐bit symmetric key, i.e. 1/(2112) = 1.9E‐34). 1/(9520) = 3.4E‐48 for KD_PW_PBKDF with 20 useful printable characters (better than a 128‐bit symmetric key, i.e. 1/(2128) = 2.9E‐39). 1/(9540) = 7.8E‐80 for KD_PW_PBKDF with 40 useful printable characters (better than a 256‐bit symmetric key, i.e. 1/(2256) = 8.6E‐78). In accordance with SP 800‐132 and FIPS 140‐3 IG D.N, keys derived from passwords are only to be used in storage applications. The iteration count shall be selected as large as possible, as long as the time required to generate the key using the entered password is acceptable for the users. The Module enforces the following SP 800‐132 compliance checks:  The iteration count is at least 1000.  The salt length is at least 128 bits.  The derived key length is at least 112 bits. RSA: The Module complies with FIPS 140‐3 IG C.F as follows:  RSA Key Generation, Signature Generation and Signature Verification have been tested and validated with all implemented modulus lengths for which CAVP testing is available: k = 1024 (legacy Signature Verification only), k = 2048, k = 3072, and k = 4096.  The Module also supports RSA Key Generation, Signature Generation and Signature Verification with modulus lengths for which CAVP testing is not available: k > 4096. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module SHA‐3 and SHAKE: The Module complies with FIPS 140‐3 IG C.C as follows:  All implemented SHA‐3 and SHAKE functions have been tested and validated on all of the Module’s operating environments.  Vendor affirmation is claimed for use of the SHA3‐256 and SHA3‐512 hash functions as part of the Hash DRBG and HMAC DRBG, for which CAVP testing with SHA‐3 is not available.

N/A for this Module. The calling application is responsible for use of a SP 800‐90B compliant entropy source outside the Module boundary providing at least 256 bits of security strength. Entropy is supplied to the Module via callback functions. The following caveat applies per FIPS 140‐3 IG 9.3.A: No assurance of the minimum strength of generated SSPs (e.g., keys).

The Module:  Produces random values in accordance with SP 800‐133 Rev. 2 Section 4, in that the DRBG output is provided directly as the random output.  Does not provide any service beyond random value generation for symmetric key generation. SSPs used with symmetric key algorithms are provided by the calling application.  Produces asymmetric keys in accordance with SP 800‐133 Rev. 2 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 symmetric key derivation in accordance with SP 800‐133 Rev. 2 Section 6.2, using the approved and CAVP listed KDF algorithms.

The Module implements key agreement methods compliant with FIPS 140‐3 IG D.F and key transport methods compliant with FIPS 140‐3 IG D.G. Strengths are provided in Section 2.6.

The Module conforms to FIPS 140‐3 IG D.C References to the Support of Industry Protocols: while it provides SP 800‐56A Rev. 3 conformant schemes and API entry points oriented to TLS usage, the Module does not contain the full implementation of TLS. The following caveat is required: No parts of the TLS protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module

Table 16: Ports and Interfaces The Module does not interact with physical ports. The Control Output interface is not applicable, as the Module does not control other components.

Table 17: 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. 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 and in associated Guidance Documentation.

Indicator Inputs This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module Table 18: Approved Services All services implemented by the Module correspond to the functionality described by the fips_query function, which returns available services based on an operation_id input. The fips_get_params function provides access to 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. The OpenSSL toolkit OSSL_PROVIDER_get_params function is used to invoke fips_get_params, when called with the Module’s global handle and a pointer to a parameter structure (initialized using provider_gettable_params or the equivalent). Regarding the Indicator of approved security services, the Module conforms to FIPS 140‐3 IG 2.4.C Approved Security Service Indicator, similar to example 2. 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). 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 operating in the approved mode with only approved security services. 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 outside the scope of the Module.

N/A for this Module. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module

The Module uses HMAC‐SHA2‐256 as the approved integrity technique; the file fips.so.mac contains the integrity reference value. The Module is provided in an executable form (as fips.so shared object for use in Linux environments).

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 ISO/IEC 19790:2012 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

Type of Operational Environment: Modifiable 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.4. The Module conforms to FIPS 140‐3 IG 2.3.C Processor Algorithm Accelerators (PAA) and Processor Algorithm Implementation (PAI). The AES‐NI functions are identified by FIPS 140‐3 IG 2.3.C as a known PAA.

N/A for this Module. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module

I O Table 20: SSP Input‐Output Methods

C T Table 21: SSP Zeroization Methods All SSPs are zeroized (overwritten with 0s) when they are no longer needed:

• CSPs and PSPs with a lifetime associated with an OpenSSL object (e.g., EVP_PKEY) are zeroized when freed or reinitialized. The OPENSSL_cleanse function is used to zeroize CSPs and PSPs owned by the caller.
• CSPs with a lifetime associated with the Module are zeroized on Module uninstantiation (the Teardown operation).

This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module Table 22: SSP Table 1 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy I O I I O I O I I I I I I I I O O O O O O O O I I I I I I O Cohesity FIPS Object Module C C C T C C T C C C C C C C C C C C C C C C C C C C C C C C This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module O C O C O O I I I I I I I I O C C C C C C C C C C C Table 23: SSP Table 2 I I C C 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. The Module maintains only the Counter DRBG state used for key generation as a persistent CSP; this DRBG instance is used exclusively for approved services. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module

Key/Algorithm Type Equivalent Strengths: Reference sources for the strengths provided in SSP Table 1 are specified below. Equivalent strength is given for each key or algorithm type (as some algorithms do not use or produce keys). Block Cipher (and related functions):  AES (AES‐128, AES‐192, AES‐256): SP 800‐57 Part 1 Rev. 5 Table

2. Digital Signature:     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): SP 800‐186 Table 1 (provides approximate elliptic curve security strengths). SP 800‐186 and FIPS 140‐3 IG C.K indicate that the Binary (B‐) and Koblitz (K‐) curves are deprecated. EdDSA (ED‐25519, ED‐448): SP 800‐186 Table
3. FFC (DSA: L=1024/N=160, L=2048/N=224, L=2048/N=256, L=3072/N=256): SP 800‐57 Part 1 Rev. 5 Table
4. Security strength for L=2048/N=256 is determined in accordance with FIPS 140‐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. IFC (RSA: k=1024, k=2048, k=3072, k=4096): SP 800‐57 Part 1 Rev. 5 Table
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. Secure Hash (and related functions):    SHA‐1, SHA2 (SHA2‐224, SHA2‐256, SHA2‐384, SHA2‐512, SHA2‐512/224, SHA2‐512/256): SP 800‐107 Rev. 1 Table
6. SHA3 (SHA3‐224, SHA3‐256, SHA3‐384, SHA3‐512): SP 800‐57 Part 1 Rev. 5 Table
7. SHAKE (SHAKE128, SHAKE256): SP 800‐185 Section 8.1. Preimage resistance strength applies to hash algorithms used in DRBG, KDFs. Described also in SP 800‐57 Part 1 Rev. 5 Table
8. Message Authentication:  KMAC (KMAC128, KMAC256): SP 800‐56C Rev. 2 Table
9. Key Agreement:    KAS‐ECC‐SSC (B‐233, B‐283, B‐409, B‐571, K‐233, K‐283, K‐409, K‐571, P‐224, P‐256, P‐384, P‐521): SP 800‐56A Rev. 3 Table
10. KAS‐FFC‐SSC (FB, FC, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192, modp‐2048, modp‐3072, modp‐4096, modp‐6144, modp‐8192): SP 800‐56A Rev. 3 Tables 25 and
11. KAS‐IFC‐SSC (k=2048, k=3072, k=4096, k=6144, k=8192): SP 800‐56B Rev. 2 Table 4 (provides approximate security strengths). Key Agreement Key Derivation:  KDA OneStep: SP 800‐56C Rev. 2 Table 1 (hash), Table 2 (HMAC) and Table 3 (KMAC). This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module

Table 24: Pre‐Operational Self‐Tests

This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module OneStep SP80056Cr2 TwoStep SP80056Cr2 This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module Table 25: Conditional Self‐Tests The intended usage of asymmetric key pairs generated by the Module is not known at the time when the key pair is generated and the pairwise consistency test (PCT) is performed. In all cases, a sign and verify PCT is performed.

Table 26: Pre‐Operational Periodic Information This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Table 27: Conditional Periodic Information Cohesity FIPS Object Module This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module

Each time the Module is powered up it tests that the cryptographic algorithms still operate correctly and that sensitive data has not been damaged. The pre‐operational self‐tests are available on demand by reloading the Module. On instantiation, the Module performs the pre‐operational self‐test and all CASTs. All KATs must complete successfully prior to any other use of cryptography by the Module. The fips_self_test function (inclusive of software integrity verification) can also be called on demand, fulfilling AS05.11.

During the manufacturing process, Cohesity executes the build and installation instructions for the Module. The Module is pre‐installed and configured in supported Cohesity solutions. The approved mode is enabled by default. There are no additional installation, configuration, or usage instructions for operators intending to use the Module.

Guidance Documentation is inclusive of all information required per ISO/IEC 19790:2012 Section 7.11.9.

The inherent properties of the Module are:

1. Manual key entry is not supported.
2. Data output is inhibited during self‐tests, zeroization, SSP generation, and error states.
3. The Module does not perform any cryptographic function if any self‐test has failed. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.

FIPS 140‐3 Security Policy Cohesity FIPS Object Module

The Module implements mitigations for constant‐time implementations and blinding attacks.

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.

The mitigation mechanisms described in Section 12.2 are inherent within the validated algorithms. No other guidance or constraints are specified. This non‐proprietary Security Policy document may be freely reproduced and distributed in its entirety without modification.