NetApp StorageGRID Kernel Crypto API

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for NetApp StorageGRID Kernel Crypto API
  %% 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>update<br/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>IKEV<br/>IPSEC</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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 StorageGRID Kernel Crypto API
  %% 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>update<br/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>IKEV<br/>IPSEC</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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 StorageGRID Kernel Crypto API Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 Document version: 1.1 www.atsec.com Last update: 2025-11-25

List of Tables Table 2: Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets) . 7 © 2025 NetApp, Inc., atsec information security.

List of Figures © 2025 NetApp, Inc., atsec information security.

This document is the non-proprietary FIPS 140-3 Security Policy for version kernel 6.1.129-1ntap1-amd64; libkcapi 1.4.0-1+ntap0 of the NetApp StorageGRID Kernel Cryptographic API module. It contains the security rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for an overall Security Level 1 module. intact and including this notice.

Table 1: Security Levels © 2025 NetApp, Inc., atsec information security.

Purpose and Use: The NetApp StorageGRID Kernel Cryptographic API (hereafter referred to as “the module”) provides a C language application program interface (API) for use by other (kernel space and user space) processes that require cryptographic functionality. The module operates on a general-purpose computer as part of the Linux kernel. Its cryptographic functionality can be accessed using the Linux Kernel Crypto API. Module Type: Software Module Embodiment: MultiChipStand Cryptographic Boundary: The cryptographic boundary of the module is defined as the kernel binary, the libkcapi shared library, and the sha512hmac binary, which is used to verify the integrity of the software components. In addition, the cryptographic boundary contains the .hmac files which store the expected integrity values for each of the software components. The cryptographic boundary is indicated by the small bold border in Figure

1. Tested Operational Environment’s Physical Perimeter (TOEPP): The TOEPP of the module is defined as the general-purpose computer on which the module is installed. It includes software in kernel and user space, as well as the PAA in the CPU. The TOEPP is indicated by the large thin border in Figure
2. Figure 1: Block Diagram © 2025 NetApp, Inc., atsec information security.

2.2 Tested and Vendor Affirmed Module Version and

Identification Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): 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 The module implements Processor Algorithm Acceleration (PAA) for the tested platforms listed above. There is no Processor Algorithm Implementation (PAI). Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: © 2025 NetApp, Inc., atsec information security.

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.

There are no components excluded from the requirements of the FIPS 140-3 standard.

Modes List and Description: Table 5: Modes List and Description After passing all pre-operational self-tests and cryptographic algorithm self-tests executed on start-up, the module automatically transitions to the approved mode. No operator intervention is required to reach this point. Mode Change Instructions and Status: The module automatically switches between the approved and non-approved modes depending on the services requested by the operator. The status indicator of the mode of operation is equivalent to the indicator of the service that was © 2025 NetApp, Inc., atsec information security.

© 2025 NetApp, Inc., atsec information security.

© 2025 NetApp, Inc., atsec information security.

Table 6: Approved Algorithms Vendor-Affirmed Algorithms: Table 7: 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: © 2025 NetApp, Inc., atsec information security.

Table 8: Non-Approved, Not Allowed Algorithms

© 2025 NetApp, Inc., atsec information security.

© 2025 NetApp, Inc., atsec information security.

© 2025 NetApp, Inc., atsec information security.

© 2025 NetApp, Inc., atsec information security.

© 2025 NetApp, Inc., atsec information security.

© 2025 NetApp, Inc., atsec information security.

Table 9: Security Function Implementations

The module implements AES-GCM IV generation in the context of IPsec, TLS 1.2, and TLS 1.3, compliant with RFC 4106, RFC 5288, and RFC 8446 respectively. These methods fall under Scenario 1 (“TLS/DTLS 1.2 protocol IV generation” and “IPsec-v3 protocol IV generation”) and Scenario 5 (“Provisions of an industry protocol supporting AES-GCM encryption, not included among the acceptable protocols in scenario 1”) of FIPS 140-3 IG C.H. The module is also compliant with SP 800-52r2 Section 3.3.1. IVs generated using these mechanisms may only be used in the context of AES-GCM encryption within their respective protocols. © 2025 NetApp, Inc., atsec information security.

The module does not implement IPsec. The module’s implementation of AES-GCM is used together with an application that runs outside the module’s cryptographic boundary. This application must use RFC 7296 compliant IKEv2 to establish the shared secret SKEYSEED from which the AES-GCM encryption keys are derived. The design of the IPsec protocol implicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values for a given session key. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES-GCM key encryption or decryption under this scenario shall be established. The module does not implement TLS. The module’s implementation of AES-GCM is used together with an application that runs outside the module’s cryptographic boundary. This application must use RFC 5288 (TLS 1.2) or RFC 8446 (TLS 1.3) to establish the cryptographic keys and initial values of the initialization vectors. For both TLS 1.2 and TLS 1.3, the nonce_explicit part of the IV does not exhaust the maximum number of possible values for a given session key. The design of the TLS protocol implicitly ensures that the nonce_explicit, or counter portion of the IV does not exhaust the maximum number of possible values for a given encryption key. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES-GCM key encryption or decryption under this scenario shall be established. Finally, the module also provides a non-approved AES-GCM encryption service which accepts arbitrary external IVs from the operator. This service can be requested by invoking the crypto_aead_encrypt API function with an AES-GCM handle. When this is the case, the API will not set an approved service indicator, as described in this document.

The length of a single data unit encrypted or decrypted with AES-XTS shall not exceed 220 AES blocks, that is 16MB, of data per XTS instance. An XTS instance is defined in Section 4 of SP 800-38E. The XTS mode shall only be used for the cryptographic protection of data on storage devices. It shall not be used for other purposes, such as the encryption of data in transit. To meet the requirement stated in IG C.I, the module implements a check to ensure that the two AES keys used in AES XTS mode are not identical. As the module does not implement symmetric key generation, this check is performed when the keys are input by the operator. Key_1 and Key_2 shall be generated and/or established independently according to the rules for component symmetric keys from NIST SP 800-133r2, Section 6.3.

All supported modulus sizes for RSA signature verification have been CAVP tested.

The module does not establish SSPs using an approved key agreement scheme (KAS). However, it does offer some or all of the underlying KAS cryptographic functionality to be used by an external operator/application as part of an approved KAS. To comply with the assurances found in Section 5.6.2 of SP 800-56Ar3, the operator must use the Diffie-Hellman and Elliptic Curve Diffie-Hellman shared secret computation algorithms with the NVMe and Bluetooth related protocols. Additionally, the module’s approved key pair generation service must be used to generate ephemeral Diffie-Hellman or EC Diffie-Hellman key pairs, or the key pairs must be obtained from another FIPS-validated module. As part of © 2025 NetApp, Inc., atsec information security.

this service, the module will internally perform the full public key validation of the generated public key. The module’s shared secret computation service will internally perform the full public key validation of the peer DH public key, and the partial public key validation of the peer EC public key, complying with Section 5.6.2.2.2 of SP 800-56Ar3.

Digital signature verification using SHA-1 is allowed for legacy use only. Digital signature generation using SHA-1 is non-approved and not allowed in approved services. These legacy algorithms can only be used on data that was generated prior to the Legacy Date specified in FIPS 140-3 IG C.M.

Table 10: Entropy Certificates Table 11: Entropy Sources The module implements three different Deterministic Random Bit Generator (DRBG) implementations based on SP 800-90Ar1: Counter DRBG, Hash DRBG, and HMAC DRBG. Each of these DRBG implementations can be instantiated by the operator of the module, using the parameters listed specified in the Security Function Implementations table. When instantiated, these DRBGs can be used to generate random numbers for external usage. Additionally, the module employs a specific HMAC-SHA-512 DRBG implementation for internal purposes (e.g. to generate asymmetric key pairs). The module complies with the Public Use Document for ESV certificate E223 by reading entropy data from the jent_kcapi_random() function, which corresponds to the GetEntropy() conceptual interface. This function outputs 256 bits of full entropy. The HMAC-SHA-512 DRBG is instantiated with a 384-bit entropy input and reseeded with a 256-bits long entropy input. Outputs of multiple GetEntropy() calls are concatenated to receive the entropy input length greater than 256 bits. The output is truncated to get the entropy input string which is not a multiple of 256. The operational environment on the ESV certificate is identical to the operating system described in this document, and the entropy source is implemented inside the cryptographic boundary. Thus, the module is compliant with scenario 1 of IG 9.3.A. There are no maintenance requirements for the entropy source. © 2025 NetApp, Inc., atsec information security.

The module implements asymmetric key pair generation compliant with SP 800-133r2. When random values are required, they are directly obtained as output from the SP 800-90Ar1 approved DRBG, compliant with Section 4 of SP 800-133r2 (without XOR). The following methods are implemented:

• Safe Primes key pair generation: compliant with SP 800-133r2, Section 5.2, which maps to SP 800-56Ar3. The method described in Section 5.6.1.1.3 of SP 800-56Ar3 (“Extra Random Bits”) is used.
• EC key pair generation: compliant with SP 800-133r2, Section 5.1, which maps to FIPS 186-5. The method described in Appendix A.2.2 of FIPS 186-5 (“Rejection Sampling”) is used. Note that this generation method is also used to generated ECDH key pairs. Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service.

The module implements shared secret computation methods as listed in the Security Function Implementations table in Section 2.6.

AES-GCM with internal IV generation in the approved mode is compliant with RFC 4106, RFC 5288, and RFC 8446 and shall only be used in conjunction with the IPsec, TLS 1.2, or TLS 1.3, protocols. Diffie-Hellman and EC Diffie-Hellman shall only be used with the NVMe and Bluetooth related protocols. No other parts of the NVMe, Bluetooth, IPsec, or TLS protocols, other than those mentioned above, have been tested by the CAVP and CMVP. © 2025 NetApp, Inc., atsec information security.

Table 12: Ports and Interfaces The logical interfaces are the APIs through which the applications request services. These logical interfaces are logically separated from each other by the API design, AF_ALG type socket message types, and SOL_TLS socket types. The module does not implement a control © 2025 NetApp, Inc., atsec information security.

The module does not implement any authentication methods.

Table 13: Roles No support is provided for multiple concurrent operators.

d) d) © 2025 NetApp, Inc., atsec information security.

G,E,Z G,E,Z G,W,E © 2025 NetApp, Inc., atsec information security.

G,E,Z C): G,W,E G,E,Z G,W,E G,R © 2025 NetApp, Inc., atsec information security.

G,E,Z ) © 2025 NetApp, Inc., atsec information security.

n n n n n n © 2025 NetApp, Inc., atsec information security.

n Z Z C): Z © 2025 NetApp, Inc., atsec information security.

Name

Descrip tion

Indicator

Inputs

Output s

Security Functio ns

SSP Access Seed: Z - CTR_DR BG internal state (V, Key): Z - DH public key: Z - DH private key: Z - EC public key: Z - EC private key: Z - Interme diate key generati on value: Z

Table 14: Approved Services The following convention is used to specify access rights to SSPs:

• Generate (G): The module generates or derives the SSP.
• Read (R): The SSP is read from the module (e.g. the SSP is output).
• Write (W): The SSP is updated, imported, or written to the module.
• Execute (E): The module uses the SSP in performing a cryptographic operation.
• Zeroize (Z): The module zeroizes the SSP.
• N/A: The module does not access any SSP or key during its operation.

© 2025 NetApp, Inc., atsec information security.

Table 15: Non-Approved Services

The module does not load external software or firmware. © 2025 NetApp, Inc., atsec information security.

On system boot, the sha512hmac binary first performs an integrity test on itself and the libkcapi library, using the HMAC-SHA2-512 and HMAC-SHA2-256 algorithms (respectively) implemented by the module. Then, the sha512hmac binary performs an integrity test on the kernel binary using the HMAC-SHA2-512 algorithm. These tests are all performed using a key hardcoded in the sha512hmac binary, by recomputing the MAC tags and verifying they are equal to the MAC tags specified in the .hmac file.

Integrity tests are performed as part of the pre-operational self-tests, which are executed when the module is initialized. The integrity tests can be invoked on demand by unloading and subsequently re-initializing the module (i.e. rebooting the system), which will perform (among others) the software integrity tests. © 2025 NetApp, Inc., atsec information security.

Type of Operational Environment: Modifiable How Requirements are Satisfied: The operating system provides process isolation and memory protection mechanisms that ensure appropriate separation for memory access among the processes on the system. Each process has control over its own data and uncontrolled access to the data of other processes is prevented.

The module shall be installed as stated in Section 11. Instrumentation tools like the ptrace system call, gdb and strace, user space live patching, as well as other tracing mechanisms offered by the Linux environment such as ftrace or systemtap, shall not be used in the operational environment. The use of any of these tools implies that the cryptographic module is running in a non-validated operational environment. © 2025 NetApp, Inc., atsec information security.

The module is comprised of software only and therefore this section is not applicable. © 2025 NetApp, Inc., atsec information security.

This module does not implement any non-invasive security mechanism and therefore this section is not applicable. © 2025 NetApp, Inc., atsec information security.

Table 16: Storage Areas The module does not perform persistent storage of SSPs. The SSPs are temporarily stored in destroyed when released by the appropriate zeroization function calls. Table 17: SSP Input-Output Methods © 2025 NetApp, Inc., atsec information security.

Table 18: SSP Zeroization Methods All data output is inhibited during zeroization. h © 2025 NetApp, Inc., atsec information security.

h 6, 4, © 2025 NetApp, Inc., atsec information security.

h 6, 4, 6, © 2025 NetApp, Inc., atsec information security.

h 4, Table 19: SSP Table 1 © 2025 NetApp, Inc., atsec information security.

© 2025 NetApp, Inc., atsec information security.

The SHA-1 algorithm as implemented by the module will be non-approved for all purposes, starting January 1, 2031. © 2025 NetApp, Inc., atsec information security.

While the module is executing the self-tests, services are not available, and data output (via the data output interface) is inhibited until the tests are successfully completed. The module does not return control to the calling application until the tests are completed. If any of the self-tests fails, the module immediately transitions to the error state.

Table 21: Pre-Operational Self-Tests The pre-operational software integrity tests are performed automatically when the module is powered on, before the module transitions into the operational state.

e © 2025 NetApp, Inc., atsec information security.

e © 2025 NetApp, Inc., atsec information security.

e © 2025 NetApp, Inc., atsec information security.

e © 2025 NetApp, Inc., atsec information security.

e © 2025 NetApp, Inc., atsec information security.

e © 2025 NetApp, Inc., atsec information security.

e © 2025 NetApp, Inc., atsec information security.

e n n © 2025 NetApp, Inc., atsec information security.

e , n , , n © 2025 NetApp, Inc., atsec information security.

e , 5.6.2.1.4 , , 5.6.2.1.4 Table 22: Conditional Self-Tests Data output through the data output interface is inhibited during the conditional self-tests. The module does not return control to the calling application until the tests are completed. If any of these tests fails, the module transitions to the error state (Section 10.4).

Table 23: Pre-Operational Periodic Information © 2025 NetApp, Inc., atsec information security.

© 2025 NetApp, Inc., atsec information security.

© 2025 NetApp, Inc., atsec information security.

© 2025 NetApp, Inc., atsec information security.

© 2025 NetApp, Inc., atsec information security.

Table 24: Conditional Periodic Information

Table 25: Error States In the error state, the output interface is inhibited, and the module accepts no more inputs or requests (as the module is no longer running). © 2025 NetApp, Inc., atsec information security.

The software integrity tests, CASTs and entropy source start-up tests can be invoked on demand by unloading and subsequently re-initializing the module. The PCTs can be invoked on demand by requesting the key pair generation service. © 2025 NetApp, Inc., atsec information security.

The module is distributed as a part of the StorageGRID 12 operating system. The StorageGRID Grid Manager is used to install the module:

1. Open the sidebar menu and click CONFIGURATION
2. Under Security, click Security settings
3. Install the FIPS module using one of the following options: a. Use the “FIPS strict” policy b. Configure and use a custom policy with the “fipsMode” key set to “true”
4. After enabling the policy, a rolling reboot must be performed; the module is not considered installed until a reboot is performed

After installation of module, the Crypto Officer must use the StorageGRID Grid Manager to verify the correct name and version of the module:

1. Open the sidebar menu and click SUPPORT
2. Under Tools, click Diagnostics
3. Find the “FIPS module versions” diagnostic and verify the FIPS module name and FIPS module version are listed as follows: NetApp StorageGRID Kernel Crypto API 6.1.129-1-ntap1-amd64 kcapi-tools 1.4.0-1+ntap0 libkcapi1:amd64 1.4.0-1+ntap0 The FIPS module is only installed on a given node if the aforementioned names and versions are displayed for that node.

There is no non-administrator guidance.

As the module does not persistently store SSPs, secure sanitization of the module consists of unloading the module. This will zeroize all SSPs in volatile memory. © 2025 NetApp, Inc., atsec information security.

The module does not offer mitigation of other attacks and therefore this section is not applicable. © 2025 NetApp, Inc., atsec information security.

AES

Advanced Encryption Standard

A Glossary and Abbreviations API                     Application Programming Interface CAST                    Cryptographic Algorithm Self-Test CAVP                    Cryptographic Algorithm Validation Program CBC                     Cipher Block Chaining CBC-CS3                 Cipher Block Chaining with Ciphertext Stealing 3 CCM                     Counter with Cipher Block Chaining-Message Authentication Code CFB                     Cipher Feedback CKG                     Cryptographic Key Generation CMAC                    Cipher-based Message Authentication Code CMVP                    Cryptographic Module Validation Program CSP                     Critical Security Parameter CTR                     Counter DH                      Diffie-Hellman DRBG                    Deterministic Random Bit Generator ECB                     Electronic Code Book ECC                     Elliptic Curve Cryptography ECDSA                   Elliptic Curve Digital Signature Algorithm ESV                     Entropy Source Validation FFC                     Finite Field Cryptography FIPS                    Federal Information Processing Standards GCM                     Galois Counter Mode GMAC                    Galois Counter Mode Message Authentication Code HKDF                    HMAC-based Key Derivation Function HMAC                    Keyed-hash Message Authentication Code IG                      Implementation Guidance IPsec                   Internet Protocol Security IV                      Initialization Vector KAS                     Key Agreement Scheme KAT                     Known Answer Test KBKDF                   Key-based Key Derivation Function KDA                     Key Derivation Algorithm KDF                     Key Derivation Function KW                      Key Wrap MAC                     Message Authentication Code NIST                    National Institute of Science and Technology OFB                     Output Feedback PAA                     Processor Algorithm Acceleration PAI                     Processor Algorithm Implementation PBKDF                   Password-Based Key Derivation Function PCT                     Pair-wise Consistency Test PKCS                    Public-Key Cryptography Standard PSP                     Public Security Parameter PUB                     Processing Standards Publication RSA                     Rivest Shamir Adleman SHA                     Secure Hash Algorithm SSC                     Shared Secret Computation SSP                     Sensitive Security Parameter TLS                     Transport Layer Security TOEPP                   Tested Operational Environment’s Physical Perimeter XTS                     XEX-based Tweaked-codebook mode with cipher text Stealing © 2025 NetApp, Inc., atsec information security.

B References FIPS 140-3 Security Requirements For Cryptographic Modules March 2019 https://doi.org/10.6028/NIST.FIPS.140-3 FIPS 140-3 IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program https://csrc.nist.gov/CSRC/media/Projects/cryptographic-modulevalidation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf FIPS 180-4 Secure Hash Standard (SHS) August 2015 https://doi.org/10.6028/NIST.FIPS.180-4 FIPS 186-4 Digital Signature Standard (DSS) July 2013 https://doi.org/10.6028/NIST.FIPS.186-4 FIPS 186-5 Digital Signature Standard (DSS) February 2023 https://doi.org/10.6028/NIST.FIPS.186-5 FIPS 197 Advanced Encryption Standard (AES) November 2001; Updated May 2023 https://doi.org/10.6028/NIST.FIPS.197-upd1 FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC) July 2008 https://doi.org/10.6028/NIST.FIPS.198-1 FIPS 202 SHA-3 Standard: Permutation-Based Hash and ExtendableOutput Functions August 2015 https://doi.org/10.6028/NIST.FIPS.202 PKCS#1 PKCS #1: RSA Cryptography Specifications Version 2.2 November 2016 https://doi.org/10.17487/RFC8017 RFC 4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) June 2005 https://doi.org/10.17487/RFC4106 RFC 5288 The Transport Layer Security (TLS) Protocol Version 1.2 August 2008 https://doi.org/10.17487/RFC5246 RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3 August 2018 https://doi.org/10.17487/RFC8446 SP 800-38A Recommendation for Block Cipher Modes of Operation: Methods and Techniques December 2001 https://doi.org/10.6028/NIST.SP.800-38A SP800-38A- Recommendation for Block Cipher Modes of Operation: Three Add Variants of Ciphertext Stealing for CBC Mode October 2010 https://doi.org/10.6028/NIST.SP.800-38A-Add SP 800-38B Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication May 2005; Updated October 2016 https://doi.org/10.6028/NIST.SP.800-38B © 2025 NetApp, Inc., atsec information security.

SP 800-38C Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality May 2004; Updated July 2007 https://doi.org/10.6028/NIST.SP.800-38C SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 https://doi.org/10.6028/NIST.SP.800-38D SP 800-38E Recommendation for Block Cipher Modes of Operation: the XTSAES Mode for Confidentiality on Storage Devices January 2010 https://doi.org/10.6028/NIST.SP.800-38E SP 800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping December 2012 https://doi.org/10.6028/NIST.SP.800-38F SP 800-52r2 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations August 2019 https://doi.org/10.6028/NIST.SP.800-52r2 SP 800-56Ar3 Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography April 2018 https://doi.org/10.6028/NIST.SP.800-56Ar3 SP 800-56Cr2 Recommendation for Key-Derivation Methods in KeyEstablishment Schemes August 2020 https://doi.org/10.6028/NIST.SP.800-56Cr2 SP 800-90Ar1 Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 https://doi.org/10.6028/NIST.SP.800-90Ar1 SP 800-90B Recommendation for the Entropy Sources Used for Random Bit Generation January 2018 https://doi.org/10.6028/NIST.SP.800-90B SP 800-108r1 Recommendation for Key Derivation Using Pseudorandom Functions August 2022 https://doi.org/10.6028/NIST.SP.800-108r1-upd1 SP 800-131Ar2 Transitioning the Use of Cryptographic Algorithms and Key Lengths Marcy 2019 https://doi.org/10.6028/NIST.SP.800-131Ar2 SP 800-133r2 Recommendation for Cryptographic Key Generation June 2020 https://doi.org/10.6028/NIST.SP.800-133r2 SP 800-140Br1 Cryptographic Module Validation Program (CMVP) Security Policy Requirements: CMVP Validation Authority Updates to ISO/IEC 24759 and ISO/IEC 19790 Annex B November 2023 https://doi.org/10.6028/NIST.SP.800-140Br1 © 2025 NetApp, Inc., atsec information security.