NetApp CryptoMod

Certificate

Approved Algorithms (18)

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

flowchart LR
  %% Deterministic review-risk graph for NetApp CryptoMod
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>IPSEC<br/>HTTPS</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>kernel<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for NetApp CryptoMod
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>IPSEC<br/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>kernel<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

NetApp, Inc. NetApp CryptoMod 3.0

The NetApp CryptoMod module, hereby referred to as either CryptoMod, or “the Module”, is a multi-chip standalone module validated at FIPS 140-3 Security Level 1. Specifically, the module meets the following security levels for each of the individual sections in the FIPS 140-3 standard:

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

Purpose and Use: The Module is a kernel mode cryptographic software library providing a C-language application program interface (API) for use by ONTAP kernel modules that require cryptographic functionality. The Module is designated as a software module with multi-chip standalone embodiment based on the descriptions of [ISO 19790] 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 “CryptoMod” and “3.0”, respectively. The Module’s design corresponds to the Module security roles. Security roles enforced by the Module are described in the appropriate context of the document.

Module Type: Software Module Embodiment: MultiChipStand Cryptographic Boundary: The cryptographic boundary of the CryptoMod module is the cryptomod_fips kernel module of the ONTAP OS kernel. The cryptographic boundary is depicted in red in the figure below. The Module’s approved DRBG is used to supply the Module’s cryptographic keys. Tested Operational Environment’s Physical Perimeter (TOEPP): The Tested OE’s Physical Perimeter (TOEPP) for the module is the enclosure of the NetApp controller.

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: Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid:

Table 4: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

No components are excluded from the [FIPS 140-3] requirements.

Modes List and Description: Table 5: Modes List and Description mode when all the power up self-tests have completed successfully, and only Approved

algorithms are invoked. If the power-up self-tests fail, then the module reboots the hardware platform. Mode Change Instructions and Status: The Module only supports an Approved mode of operation. Degraded Mode Description: The Module does not support a degraded mode of operation.

Approved Algorithms: Table 6: Approved Algorithms Vendor-Affirmed Algorithms: 2) Table 7: Vendor-Affirmed Algorithms

Non-Approved, Allowed Algorithms: N/A for this module. The Module does not support any Non-Approved, Allowed Algorithms. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. The Module does not support any Non-Approved, Allowed Algorithms with No Security Claimed. Non-Approved, Not Allowed Algorithms: N/A for this module. The Module does not support any Non-Approved, Not Allowed Algorithms.

Table 8: Security Function Implementations

The AES-GCM IV is partially generated by an industry protocol and is always passed to the module via an API call. The counter portion of the IV is set by the module within the module’s cryptographic boundary. When used with TLS 1.2/1.3, the AES-GCM IV is constructed in compliance with IG C.H scenario 1. The GCM IV generation follows RFC 5288. The counter portion of the IV is set by the module within the module’s cryptographic boundary. The module does not implement the TLS protocol. The module’s implementation of AES-GCM, when used for TLS, is used with another ONTAP application running outside of the module’s boundary. The design of the TLS

protocol implicitly ensures that the counter portion of the IV will not exhaust all its possible values. When used with the IPsec-v3 protocol, GCM IV generation follows RFC 4106 and is constructed in compliance with IG C.H scenario

2. The counter portion of the IV is set by the module within the module’s cryptographic boundary. The module does not implement the IPsec protocol. The module’s implementation of AES-GCM, when used for IPsec, is used with another ONTAP application running outside of the module’s boundary. The design of the IPsec protocol implicitly ensures that the counter portion of the IV will not exhaust all its possible values. When used with SMB 3.x, the AES-GCM IV is constructed in compliance with IG C.H scenario 5 with 8 bytes of random data followed by 8 bytes from the network context. The counter portion of the IV is set by the module within the module’s cryptographic boundary. The module does not implement the SMB protocol. The module’s implementation of AES-GCM, when used for SMB, is used with another ONTAP application running outside of the module’s boundary. The design of the SMB protocol implicitly ensures that the counter portion of the IV will not exhaust all its possible values. In all instances, the AES-GCM IV is not persistently stored; therefore, whenever the module’s power is lost and then restored, the user of the module (i.e., TLS, IPsec, or SMB) along with the ONTAP application that implements the protocol, must re-establish keying material using new random values and a KDF operation to establish the pertinent network communication channel. b) PBKDF Usage The module provides password-based key derivation (PBKD), compliant with NIST SP 800-132 Rev.
3. The CryptoMod module supports option 1a from section 5.4 of [SP800-132]. In option 1a, the Master Key (MK), or a segment of the MK, is used directly as the Data Protection Key (DPK). In line with the requirements for NIST SP800-132, keys generated using the approved PBKDF algorithm must only be used for storage applications. The length of the MK or DPK shall be 112 bits or more. A salt, with a length of at least 128 bits, shall be generated using the NIST SP 800-90Arev1 DRBG. The iteration count shall be selected as large as possible, with a minimum value of 1000. Passwords or passphrases, used as input for the PBKDF, shall not be used as cryptographic keys. The length of the password of passphrase shall be at least 32 characters and shall consist of ASCII printable characters. The probability of guessing the value is estimated to be: 1/9532 <10-64, which is less than 2-112. As the module is a general-purpose software module, it is not possible to predict the use of the PBKDF, however a user of the module should also note that a password should contain at least enough entropy to be unguessable and contain enough entropy to reflect

the security strength required for the key being generated. Users are referred to Appendix A, “Security Considerations” of NIST SP 800-132 Rev. 2 for further information on password selection. c) AES-XTS Usage Per the requirements of NIST SP 800-38E, AES-XTS mode shall be used for storage purposes only. The length of the AES-XTS data unit does not exceed 220 blocks. In accordance with IG C.I when generating an AES-XTS key, the module checks to ensure that key1 is not equal to key2. If key1 is equal to key2, then the module fails the key generation request. d) SHA-1 Usage The module implements SHA-1 for usage in the following:

• As a PRF in the KDF for PBKDF [SP800-132]
• As a standalone SHA-1 hash function
• As a PRF in HMAC-SHA-1 e) FIPS 202 Usage In accordance with IG C.C Resolution 2.a, each SHA-3 function has been tested and validated on all the module’s operating environments.

Table 9: Entropy Certificates Table 10: Entropy Sources

The ESV (#E1) entropy source used by the Counter DRBG in the module is described above. The module’s embedded entropy source provides 256 bits of min-entropy per 256-bit output sample of full entropy.

CryptoMod implements a NIST SP800-90A Rev. 1 Counter DRBG for the generation of random bits and keys. The implementation of the Counter DRBG uses AES-256 (maximum of 256 bits of security strength) as the block cipher along with the appropriate derivation function. On the tested system, entropy is provided from the module’s embedded jitter-entropy CPU ESV (#E1) implementation. The module uses its embedded entropy source in accordance with the ESV (#E1) Public Use Document. The module requests a minimum number of 512 bits of entropy from its Operational Environment per each call. In addition, the vendor affirmed CKG implementation uses an Approved Counter DRBG as specified in NIST SP 800-90 A Rev.

1. The key generation method adheres to NIST SP800-133 Rev. 2, and the module utilizes post processing. The output of the CryptoMod DRBG is XOR’d with a random mask obtained from ESV (#E1) to compute the secret value "K" as per Section 6.3, method #2 in NIST SP800-133 Rev. 2 with m = 1 and n =
2. The post-processing is performed on the DRBG output with the post-processing operation resulting in the new "U".

Key Agreement Schemes The Module does not support any key establishment algorithms. Key Transport Schemes The module implements the following Approved/allowed key transport methods as specified in [FIPS140-3_IG] IG D.G which have been CAVP tested and validated: • AES-KWP wrap/unwrap

The Module conforms to Resolution 3 per [FIPS140-3_IG] D.C References to the Support of Industry Protocols: while it provides cryptographic APIs that may be used by IPSec and TLS components, the Module does not contain an implementation for IPSec or TLS. The following caveat is required: No parts of the IPSec and TLS protocols, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

Table 11: Ports and Interfaces As a software-only module, CryptoMod does not have any physical ports. The logical interfaces for the module are defined by the API for CryptoMod. If the module enters an error state, then data output interfaces are disabled (note: the module does not utilize control input or output interfaces).

The Module does not provide an authentication or identification method of its own; operators implicitly assume an authorized role based on the service selected.

Table 12: Roles The module supports the User and mandatory Cryptographic Officer operational role, which is implicitly defined. The module does not support a maintenance role, nor does it support a bypass capability. The module does not support multiple concurrent operators.

e: Z Table 13: Approved Services Legend: 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 = Zeroize: The module zeroizes the SSP.

N/A for this module. The Module does not support any non-approved services.

The Module does not have the capability of loading software or firmware from an external source.

The module compares the HMAC-SHA2-256 digest created over the .text and .data sections of the module versus the digest pre-calculated at compile time. The module’s self-integrity check is automatically performed when the module is loaded into kernel memory. Since the module, once loaded, cannot be unloaded, the self-integrity check can only be initiated by rebooting the platform.

The Module does not support initiate on demand functionality. The self-integrity check can only be initiated by rebooting the platform.

Type of Operational Environment: Modifiable

How Requirements are Satisfied: The module operates in a modifiable operational environment on the validated platforms and the vendor-affirmed platforms listed in Section 2.2 Tested and Vendor Affirmed Module Version and Identification. 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.

No operational environment restrictions are required for operation in the approved mode. As indicated in Section 2, the Module always operates in the approved mode.

Physical Security requirements are not applicable for this software Module.

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

Table 14: Storage Areas The cryptographic module does not persistently store keys. Keys and CSPs are passed to the module by the calling kernel process. The keys and CSPs are stored in nondumpable memory in plaintext. Keys and CSPs residing in internally allocated data structures (during the lifetime of an API call) can only be accessed using the module defined API. The ONTAP operating system protects memory and process space from unauthorized access.

Table 15: SSP Input-Output Methods

Table 16: SSP Zeroization Methods h

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

Each time the platform is powered up it tests that the cryptographic algorithms still operate correctly and that sensitive data has not been damaged. On Module instantiation, the Module performs the pre-operational self-tests and CASTs listed above. All KATs must complete successfully prior to any other use of cryptography by the Module.

Table 21: Pre-Operational Periodic Information

Table 22: Conditional Periodic Information

Table 23: Error States Errors encountered during the power-on self-test operations will result in an automatic reboot of the operating system. If the module encounters a fatal error state, other than one encountered during self-tests, then the Crypto-Officer must manually reboot the system to return the module to normal operation.

The operator can reload the module by rebooting the NetApp platform, fulfilling AS05.11.

The module consists of a single kernel object module that provides cryptographic services as part of the NetApp ONTAP operating system. The CryptoMod module is automatically installed with ONTAP and is automatically initialized and started up whenever the appliance and/or ONTAP instance is restarted. See the NetApp documentation center (https://docs.netapp.com) for ONTAP product documentation. ONTAP 9.15 and greater will use the NetApp CryptoMod version 3.0 module without any required user intervention. When used with ONTAP versions less than ONTAP 9.15, the FIPS 140-3 variant of the module is initialized by executing the following ONTAP CLI diagnostic level command: *> security cryptomod_fips modify -node local -is_iut_enabled true followed by a reboot of the controller. Once the controller has rebooted, the FIPS 140-3 variant of the module will be automatically used.

ONTAP 9.15 and greater will use the NetApp CryptoMod version 3.0 module without any required administrator intervention. When used with ONTAP versions less than ONTAP 9.15, the FIPS 140-3 variant of the module is initialized by executing the following ONTAP CLI diagnostic level command: *> security cryptomod_fips modify -node local -is_iut_enabled true followed by a reboot of the controller. Once the controller has rebooted, the FIPS 140-3 variant of the module will be automatically used.

Users can determine if they are using the FIPS 140-3 variant of the module by running the following ONTAP CLI command: *> security cryptomod-fips show

This section is not applicable. The module does not claim to mitigate against any attacks beyond the FIPS 140-3 requirements for a Level 1 module.