NetApp Cryptographic Security Module (NCSM) based on the OpenSSL FIPS Provider

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for NetApp Cryptographic Security Module (NCSM) based on the OpenSSL FIPS Provider
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>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/>IPSEC</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["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    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["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  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 NetApp Cryptographic Security Module (NCSM) based on the OpenSSL FIPS Provider
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Show status</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</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,C5,C6 clueLow;

Security Policy, page by page

NetApp, Inc. NetApp Cryptographic Security Module (NCSM) based on the OpenSSL FIPS Provider Document Version 1.0 January 2026 Prepared by: www.lightshipsec.com NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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 based on the OpenSSL FIPS Provider cryptographic module (hereafter referred to as “the Module”) from NetApp, 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. 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: NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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 “ NetApp Cryptographic Security Module (NCSM) based on the OpenSSL FIPS Provider” 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 Type: Software 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. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Figure 1: NetApp Cryptographic Security Module (NCSM) based on the OpenSSL FIPS Provider Block Diagram

Tested Module Identification

• Hardware: N/A for this module. Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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: The table below details the Modes of Operation supported by the module. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 4: Modes List and Description

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 c. Enforce the Module entering the error state on conditional test errors such as PCT failure. 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. Mode Change Instructions and Status: NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Approved Algorithms: NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 5: Approved Algorithms The Module implements the Approved cryptographic functions listed in Table 5. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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 for this module. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The module does not support any Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed. Non-Approved, Not Allowed Algorithms: Table 8: Non-Approved, Not Allowed Algorithms The table below lists the Security Function Implementations supported by the module. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 9: Security Function Implementations NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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 [SP80057P1r5] 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 [SP800-57P1r5] Table
7. Equivalent strengths are annotated as approximate (i.e., s ~=) since [SP800-56Br2] Table 4 provides approximate security strengths. Note 8: Security strengths for KDA One Step are given in [SP800-56Cr2] Table 1 (hash), Table 2 (HMAC) and Table 3 (KMAC). 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, MODP6144, 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 AES-GCM mode encryptions within the protocol. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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 1character 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. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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 NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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-prf-ems-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, SHA2-256, 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 800-133r2 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. As a PRF in the KDFs X942 KDF-CONCAT, X963 KDF, KDA HKDF, KDA OneStep, KDF, ANS 9.42 [SP800135r1], KDF SSH [SP800-135r1], PBKDF [SP800-132], II. As a standalone SHA-1 hash function III. As a PRF in HMAC-SHA-1 IV. 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. V. 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). N/A for this module. N/A for this module.

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 NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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, KASFFC-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

Per IG C.F Additional Comment 2: The KAS-ECC-SSC and KAS-FFC-SSC implementations each support a scheme of the Diffie-Helllman variety. Per IG D.G: The module supports the Key Transport per NIST SP 800-56Br2 (RSA-OAEP) denoted by KTS-4 in the SFI Table 9. 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. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The table below details the module Ports and Interfaces. Table 10: Ports and Interfaces Table 10 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 10. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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. N/A for this module.

Table 11: 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.

s NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

s :Z Z Z :Z Z K: Z K: Z Z NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

s I: Z Z NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicato r CBC- CS: AES- 128- CBC- CTS, AES- 192- CBC- CTS, AES- 256- CBC- CTS]; [AES- OFB: AES- 128- OFB, AES- 192- OFB, AES- 256- OFB]; [AES- CFB1: AES- 128- CFB1, AES- 192- CFB1, AES- 256- CFB1]; [AES- CFB8: AES- 128- CFB8, AES- 192- CFB8, AES- 256- CFB8]; [AES-

Inputs

Outputs

Security Function s

SSP Access

s NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicato r CFB128: AES- 128- CFB, AES- 192- CFB, AES- 256- CFB]; [AES- CTR: AES- 128- CTR, AES- 192- CTR, AES- 256- CTR]; [AES- CCM: AES- 128- CCM, AES- 192- CCM, AES- 256- CCM]; [AES- GCM: AES- 128- GCM, AES- 192- GCM, AES- 256- GCM]; [AES- XTS: AES- 128- XTS,

Inputs

Outputs

Security Function s

SSP Access

s NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

s NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicato r 384)]; [X963- KDF, (SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512)]; [X942KD F-ASNI, (SHA1, SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512, SHA2- 512/224, SHA2- 512/256, SHA3- 224, SHA3- 256, SHA3- 384, SHA3- 512)]; [NIST SP 800- 108r1 KDF KMAC: KBKDF, (KMAC- 128, KMAC- 256)]; [NIST SP 800- 108r1 KDF:

Inputs

Outputs

Security Function s

SSP Access

s NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicato r KBKDF, MAC: CMAC, Cipher: AES- 128- CBC, AES- 192- CBC, AES- 256- CBC, MAC: HMAC- SHA1, HMAC- SHA2- 224, HMAC- SHA2- 256, HMAC- SHA2- 384, HMAC- SHA2- 256, HMAC- SHA2- 384, HMAC- SHA2- 512, HMAC- SHA2- 512/224, HMAC- SHA2- 512/256, HMAC- SHA3- 224, HMAC- SHA3- 256, HMAC- SHA3-

Inputs

Outputs

Security Function s

SSP Access

s NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicato r 384, HMAC- SHA3- 512]; [KDF SSH: SSHKDF , (SHA1, SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512)]; [OneSte p KDF: SSKDF, (SHA1, SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512, SHA2- 512/224, SHA2- 512/256, SHA3- 224, SHA3- 256, SHA3- 384, SHA3- 512, HMAC- SHA1, HMAC- SHA2- 224, HMAC- SHA2- 256,

Inputs

Outputs

Security Function s

SSP Access

s NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicato r HMAC- SHA2- 384, HMAC- SHA2- 512, HMAC- SHA2- 512/224, HMAC- SHA2- 512/256, SHA3- 224, SHA3- 256, SHA3- 384, SHA3- 512, KMAC- 128, KMAC- 256)]; [TwoSte p KDF: HKDF, MAC: HMAC, (SHA1, SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512, SHA2- 512/224, SHA2- 512/256, SHA3- 224, SHA3- 256, SHA3- 384,

Inputs

Outputs

Security Function s

SSP Access

s NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

s G NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

s NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

s NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

s NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicato r 512, SHA2- 512/224, SHA2- 512/256) ]; [RSA Signatur e Primitive : RSA, 2048, hash algorith m: (null)]; [ECDSA SigGen: EC, (SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512, SHA3- 224, SHA3- 256, SHA3- 384, SHA3- 512)]; [ECDSA SigVer: EC, (SHA1, SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512, SHA2- 512/224,

Inputs

Outputs

Security Function s

SSP Access

s e m: NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicato r SHA2- 512/256) ]; [ECDSA SigGen Compon ent]: EC, hash: (null)]; [DSA, PQGGe n: DSA, (L= 2048, N=28, SHA2- 224, SHA2- 256, SHA2- 384, SHA2- 512, SHA2- 512/224, SHA2- 512/256) , (L=2048, 3072, N=32, =SHA2- 256, SHA2- 384, SHA2- 512, SHA2- 512/256) ]; [DSA PQGVer: DSA, N=20 bytes, 28 bytes, 32 bytes]; [DSA, SigGen:

Inputs

Outputs

Security Function s

SSP Access

s ]; (L= , NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

s (L= ] NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description scope SSPs Call stack cleanup is the duty of the application Restarting the general- purpose computer clears all SSPs in RAM OPENSSL_cl eanse provides zeroisation of SSPs managed by the caller; See the notes below this table for additional explanation

Indicato r

Inputs

Outputs

Security Function s

SSP Access - DS_SVK: Z - GKP_Pri vate: Z - GKP_Pu blic: Z - KAS_Priv ate: Z - KAS_Pu blic: Z - KAS_SS: Z - KD_DKM : Z - KH_Key: Z - KTS_KD K: Z - KTS_KE K: Z - KTS_SS: Z - DRBG_E I: Z - DRBG_S eed: Z - DRBG_S tate: Z - SC_EDK: Z - Software

s Z K: Z K: Z Z I: Z Z NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name

Description

Indicato r

Inputs

Outputs

Security Function s

SSP Access Integrity key: Z

s Table 12: Approved Services Note: The Indicators in Table 12 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/KAS-IFC/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) NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

• 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 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 outside the scope of the Module. 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.
• CSPs with a lifetime associated with the Module are zeroised on Module uninstantiation (the Teardown operation).
• The OPENSSL_cleanse function is used to zeroise CSPs owned by the caller.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 13: Non-Approved Services

The module does not support loading of any additional software.

The module does not support self-initiated cryptographic output. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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 NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Physical Security requirements are not applicable for this software Module. N/A for this module. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

In accordance with current CMVP policy, Non-Invasive Security is not applicable. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Name CALL STACK (API) INPUT PARAMETER S CALL STACK (API) OUTPUT PARAMETER S Stored at manufacture

From Calling application Module Manufacture r

To Module Calling application Stored in the module's configuratio n file

Format Type Plaintex t Plaintex t Plaintex t

Distributio n Type Manual Manual N/A

Entry Type Electroni c Electroni c N/A

SFI or Algorith m

m S S Table 15: 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).

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 16: SSP Zeroization Methods y n NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

y NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

y NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

y NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

y NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

y NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

y Table 17: SSP Table 1 n NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

n NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

n NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

n Table 18: 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. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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). The Module:

• 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. AESKTS keys are generated in accordance with [SP800-133r2] Section 6.3. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 19: 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 Answer Test (KAT) for the

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 20: 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 21: Pre-Operational Periodic Information NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 22: Conditional Periodic Information

also be called on demand, fulfilling AS05.11. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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 NetApp Cryptographic Security Module (NCSM) based on the OpenSSL FIPS Provider 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 NetApp Cryptographic Security Module (NCSM) based on the OpenSSL FIPS Provider (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: $ ./Configure enable-fips $ make $ make install Windows: $ 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 platformspecific 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: NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

$ openssl version -v The Installation of the NetApp Cryptographic Security Module (NCSM) based on the OpenSSL FIPS Provider 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 HMAC-SHA2-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 minimumsecurity 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. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.

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. NetApp, Inc. 2025 This document may be reproduced and distributed only in its original entirety without revision.