Purity Encryption Module

Certificate

Approved Algorithms (6)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Purity Encryption Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Show status</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    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?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    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
  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,C6 clue;
  class I3,I6 infer;
  class R3,R6 risk;
  class E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Purity Encryption Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Show status</i><br/>src: securityPolicy.services"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C3 clueHigh;
  class C6 clueLow;

Security Policy, page by page

Pure Storage, Inc. Purity Encryption Module FIPS 140-3 Cryptographic Module Non-Proprietary Security Policy Version: 1.0 October 2024 Pure Storage, Inc.

Mountain View, CA 94041 800-379-7873 Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

1. General Information This document defines the Security Policy for the Purity Encryption Module, hereafter denoted the Module. The Module is a multi-chip standalone software module (within the FlashArray product) and is run on a General Purpose Computer (GPC) with a modifiable 1.1 Security Levels The Overall Security rating of the module is Level
2. Table 1 contains the security levels for all areas. N/A N/A N/A Table 1 - Security Levels Pure Storage Inc. Public Material – May be reproduced only in its original entirety (without revision).

2. Cryptographic Module Specification Purity Encryption Module is a standalone cryptographic module for the Purity Operating Environment for FlashArray (Purity//FA). Purity//FA powers Pure Storage's FlashArray family of products which provide economical all-flash storage. Purity Encryption Module enables FlashArray to support always-on, inline encryption of data with an internal key management scheme that requires no user intervention. The cryptographic module is defined as a software module. The Module is intended for use by US Federal agencies and other markets that require FIPS 140-3 validated Data Storage. 2.1 Module Information The validated module name is “Purity Encryption Module”, and the current version is output by the module as “FA-1.5”. The identifier “FA” is used as a module identifier. 2.2 Mode of Operation The module supports a single Approved mode of operation. The Approved mode is enabled upon successful start-up of the module. There are no specific initialization steps required for start-up of the module beyond powering on the FlashArray product. The module does not support a non-approved mode of operation. 2.3 Operational Environments Table 2 lists the operational environments the module was tested on. # Table 2 - Tested Operational Environments Table 3 lists the operational environments that the vendor affirms can be used by the module. No claim is made as to the correct operation of the module or the security strengths of the generated keys when ported to an OE which is not listed on the validation certificate. Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

# 1. 2. 3. 4. 5. 6. 7. 8. 9. Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

Table 3 - Vendor Affirmed Operational Environments 2.4 Cryptographic Functionality Table 4 below summarizes the approved algorithms supported by the module. Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

[SP 80090Arev1] N/A Table 5 contains the non-approved algorithms allowed in the approved mode of operation Table 5 - Non-Approved Algorithms Allowed in Approved mode of operation with No Security Claimed There are no other non-approved algorithms allowed in the approved mode of operation. Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

2.5 Cryptographic Module Boundary The cryptographic boundary of the cryptographic module encompasses: - libcrypto.so - the dynamically linked library libcrypto.so - libcrypto.hash - the configuration file containing the module integrity code. The Tested Operational Environment’s Physical Perimeter (TOEPP) is defined as the physical General Purpose Computer (GPC) host platform on which the module is installed. A block diagram depicting the physical and cryptographic boundaries is shown in the figure below: 3. Cryptographic Module Interfaces As a software-only module, the module does not have physical ports. For the purpose of the FIPS 140-3 validation, the physical ports are interpreted to be the physical ports of the hardware platform on which it runs. The underlying logical interfaces of the module are the C++ language APIs. The module supports four logical interfaces: Data Input, Data Output, Control Input and Status Output. It does not support a Control Output interface. Table 6 defines the logical interfaces. Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

N/A N/A N/A N/A N/A N/A Table 6 - Interfaces 4. Roles, Services, and Authentication 4.1 Roles The module supports the Crypto Officer role, which is assumed implicitly by the operator of the module (the calling application) for all module services. No authentication mechanisms are provided to assume the Crypto Officer role. The module does not support concurrent operators and does not authenticate the Crypto Officer role. Furthermore, it does not support a maintenance role and/or bypass capability. Table 7 below contains the services associated with available role. Table 7 - Roles, Service Commands, Input and Output Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

4.2 Services Table 8 below lists the services that can be used in the approved mode of operation with corresponding input and output. The abbreviations of the access rights to keys and SSPs have the following interpretation. 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. N/A= The service does not access any SSP during its operation W,E W,E W,E AES KeyWrapping W,E G,E,Z n/a W n/a R N/A n/a Perform selftests HMAC-SHA256 E Z Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

N/A N/A n Table 8 - Approved Services

5. Software/Firmware Security 5.1 Integrity Techniques The Purity module is a single, shared object, binary component that is in an Executable and Linkable Format (ELF). A software integrity test is performed on this component using HMAC-SHA-256, which is implemented in the module. The integrity test succeeds if the computed integrity value is equal to the expected integrity value, loaded from the module’s configuration file. If the integrity test fails, the module enters the Error State and the module becomes inoperable. 5.2 On-Demand Integrity Test The integrity test is performed as part of the Pre-Operational Self-Tests, which are executed on load of the shared library. It can be also invoked by on demand by power-cycling the
6. Operational Environment The Module is designated as a modifiable operational environment under the FIPS 140-3 definitions. The operational environment is the Purity Operating System for FlashArray 6.4, which is based on Ubuntu Linux. The operational environment implicitly enforces a single mode of operation by managing process memory of the module and ensuring each calling process is logically separated and protected. No rules, settings or restrictions to the operational environment apply for operation of the
7. Physical Security The FIPS 140-3 physical security requirements do not apply to the Purity module. Pure Storage Inc. Public Material – May be reproduced only in its original entirety (without revision).

8. Non-invasive Security The requirements of this area are not applicable to the module. This is not currently required by FIPS 140-3. Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

9. Sensitive Security Parameter Management 9.1 Keys and SSPs Table 9 summarises the key Sensitive Security Parameters (SSPs) that are used by cryptographic services implemented in the module: h Generation Establishment Zeroisation c n t d d d (NonSSP) Table 9 - Keys and SSPs Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

9.2 DRBG and Entropy Sources The module employs a single DRBG instance for the purpose of supplying random numbers to the calling application via the module’s service random number generation service. This DRBG is used for this service only and is not used by the module for any other purpose. This module DRBG is CTR_DRBG with security strength of 256 bits. The module DRBG is seeded from the module’s entropy source, which is set by the calling application via a callback function as input to the applicable service API. The calling application and the supplied entropy source are external to the module boundary. It is a requirement of the FlashArray product that the entropy source configured for the module provides full entropy. As such, the 256-bits of data loaded from the entropy source to seed Table 10 - Non-Deterministic Random Number Generation Specification 10. Self-tests This section specifies the pre-operational self-tests and conditional self-tests performed by the module. They include the software integrity test and the cryptographic algorithm selftests. These tests ensure that the module is not corrupted and the algorithms function as expected. All self-tests are executed automatically when the module is loaded into memory before the module transitions to the operational state. The services of the module are not available prior to the completion of the self-tests. Successful completion of self-tests is indicated by a status message and passing control to the calling application. Failure of any self-test causes the module to enter the Error State, which is indicated by an error message. In this error state, the module is not operational, and no services are available. This is the only error state supported by the module. The module permits operators to initiate the self-tests on demand by power cycling the system.

The module performs the following pre-operational test: Software integrity test (using HMAC SHA256) Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

The module performs the following conditional Cryptographic Algorithm Self-Tests (CASTs) via Known Answer Tests (KAT): AES CTR Encrypt and Decrypt KATs (128, 256 bits) AES ECB Encrypt and Decrypt KATs (128, 256 bits) AES KW Wrap and Unwrap KATs (256 bits) CTR-DRBG KATs for Instantiate, Generate, Reseed SHA-256 KAT HMAC-SHA256 KAT (512 key bits) All CASTs are triggered by the module’s initial load sequence. Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

The module is built into Purity OS. There is no standalone delivery of the module as a software library. The vendor’s internal development process guarantees that the correct version of module is distributed with the intended device. The module does not have any specific maintenance requirements.

There is only one Approved mode of operation. Crypto Officer Role Guidance is provided by the API documentation provided by the module’s header files. Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).

12. Mitigation of other attacks The module does not claim mitigation of other attacks. Pure Storage Inc. Public Material

• May be reproduced only in its original entirety (without revision).