FlashBlade Data Encryption Module

Certificate

Vendor resources (verify with the vendor)

Approved Algorithms (1)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for FlashBlade Data Encryption Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>2.10</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Upgrade</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Show Status</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>PCIe Bus, DDR in<br/>PCIe Bus, DDR out<br/>PCIe Bus</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I4["Interface reachability may<br/>vary by boot stage and<br/>lifecycle state."]
    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"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    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?"]
    R4["Are interfaces blocked<br/>before the bootloader<br/>runs, or only after<br/>approved mode starts?"]
    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"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E4["lifecycle reachability<br/>matrix · boot-stage<br/>interface timing ·<br/>factory/recovery/error-state<br/>access controls"]
    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
  C1 --> I1 --> R1 --> E1
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C4 --> I4 --> R4 --> E4
  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 C1,C2,C3,C4,C6 clue;
  class I1,I2,I3,I4,I6 infer;
  class R1,R2,R3,R4,R6 risk;
  class E1,E2,E3,E4,E6 evidence;

flowchart LR
  %% Deterministic clue tier for FlashBlade Data Encryption Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>2.10</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Upgrade</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Show Status</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>PCIe Bus, DDR in<br/>PCIe Bus, DDR out<br/>PCIe Bus</i><br/>src: securityPolicy.portsAndInterfaces"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>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 C1,C2,C3,C4 clueHigh;
  class C6 clueLow;

Security Policy, page by page

Pure Storage, Inc. FlashBlade Data Encryption Module Hardware Version: PM8607B1-F3EI; Firmware Version: 2.10 Non-Proprietary FIPS 140-3 Security Policy Document Version: 1.2 Date: April 2nd, 2025 Pure Storage, Inc.

Santa Clara, CA 95054 800-379-7873 © 2015-2025 Pure Storage, Inc. Version 1.2 Pure Storage Inc. Public Material

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

This document defines the Security Policy for the FlashBlade Data Encryption Module, hereafter denoted as the Module. The Module is validated to FIPS 140-3 overall Level 1 requirements with security levels as follows: N/A N/A © 2015-2025 Pure Storage, Inc. Version 1.2 Pure Storage Inc. Public Material

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

Cryptographic module specification The Module is a Hardware cryptographic module, as defined by [ISO19790]. The module consists of the Belmar ASIC for performing AES-256 XTS mode encryption and decryption for User data, and a firmware component to provide self-test functionality. For XTS mode, encrypt and decrypt operations are symmetric, thus the module is one logical block. Furthermore, the AES-256 XTS mode encryption and decryption can only be used for storage of User data. The Module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated Data Storage. The physical form of the Module is depicted in Figure 2. The cryptographic boundary is the single-chip Flash Controller, including an XTS-AES-256 hardware block in the Direct Memory Access engine, as well as a firmware component running on the ASIC. This component is responsible for loading the AES key into the cryptographic hardware and running the Self-Tests. Data is encrypted while being transported by the DMA engine into the drive and decrypted by the engine on the way out. The diagram below shows the flow of data through the module. Figure 1

• Cryptographic Boundary © 2015-2025 Pure Storage, Inc. Version 1.2 Pure Storage Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Figure 2

• Physical Perimeter The Module was validated with the specific configuration listed below: Table 2
• Cryptographic Module Tested Configuration N/A The Module implements the Approved functions listed in the table below. Table 3
• Approved Algorithms The module does not implement any non-Approved algorithms or services. AES is the only cryptographic algorithm available to operators. 2.1 Mode of Operation The Module only supports an Approved mode of operation. To verify that a module is in the Approved mode of operation and that the FIPS validated version is being used, the operator must check the version output using the “Show Status” service and compare it against the FIPS certificate. © 2015-2025 Pure Storage, Inc. Pure Storage Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Cryptographic Module Interfaces The data enters and exits the module via the memory subsystem. There are two ports to the memory subsystem, one from the PCIe interface, and one from the DDR interface, which are connected to the DMA hardware engine. For the firmware portion of the module, the logical interfaces are the application program interfaces (APIs) through which commands are issued to the flash controller firmware. The flash controller itself communicates using the NVMe over PCIe protocol. The five interfaces which are used in the cryptographic module are specified in Table 3 below. Table 4

• Ports and Interfaces Role, services, and authentication The Module supports two distinct operator roles, Cryptographic Officer (CO) and User. The cryptographic module uses implicit mapping between services and roles to enforce the separation of roles. The Module does not implement authentication. The Module does not support a maintenance role. The Module does not support concurrent operators. Table 5
• Roles, Service Commands, Input and Output The Control Output logical interface is omitted from this table, as it is not implemented by the module. © 2015-2025 Pure Storage, Inc. Version 1.2 Pure Storage Inc. Public Material
• May be reproduced only in its original entirety (without revision).

W U E Z Key: G = Generate, R = Read, W = Write, E = Execute, Z = Zeroize © 2015-2025 Pure Storage, Inc. Pure Storage Inc. Public Material

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

is run automatically on power up and before the module is operational, and if the test fails then the Module will not enter an operational state. The firmware itself is executed as a BIN executable. The Belmar ASIC has 16 separate cores, each which runs a respective binary. The binary is constructed from an ELF executable, and similarly consists of sections which are given a loading address and section size. Each section is loaded into memory in the Secondary Boot Loader during the boot process. Operational Environment The Module has a non-modifiable operational environment under the FIPS 140-3 definitions. Firmware versions validated through the FIPS 140-3 CMVP will be explicitly identified on a validation certificate, along with the Belmar ASIC model number. Any firmware or hardware not identified in this Security Policy does not constitute the Module defined by this Security Policy or covered by this validation. Physical Security Policy The Module, which has a single-chip embodiment, meets the FIPS 140-3 requirements for production grade components and standard passivation. The PMC Flashtec NVMe 2016 Controller Chip (referred to as the Belmar ASIC) the module consists of is produced for high performance enterprise workloads. Non-invasive security Not Applicable. The module does not support non-invasive attack security. Sensitive Security Parameter Management All SSPs used by the Module are described in this section. All usage of these SSPs by the Module are described in the services detailed in Section 4. The SSPs are kept in volatile write-only registers in the Module, and all intermediate values used for loading SSPs are zeroized immediately after use. Table 7

• Sensitive Security Parameters (SSPs) 9.1 All SSPs managed by the module are stored in volatile memory. The Crypto-office can zeroize all SSPs by:
• removing power from the module, or invoking the 'reset module' service. © 2015-2025 Pure Storage, Inc. Version 1.2 Pure Storage Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Each time the Module is powered on it will perform self-tests to ensure its proper operation. Per FIPS 140-3 these are categorized as either pre-operational self-tests or conditional self-tests. Pre-operational self–tests are available on demand by power cycling the module, or through an API call. Conditional selftests are available through an API call. All cryptographic algorithm self-tests (CASTs) must complete successfully prior to any other use of cryptography by the Module. The Module performs the following pre-operational self-tests.

• Firmware Integrity: CRC16 EDC of the firmware component, performed within the cryptographic boundary over the whole binary The Module performs the following conditional cryptographic algorithm self-tests:
• AES-XTS-256 Encrypt/Decrypt KAT The Module performs the following conditional critical function self-tests:
• XTS Duplicate key test - during key initialization the module checks that XTS key1 does not equal key2 and fails to load the key if this condition is not satisfied (IG C.I XTS-AES). All pre-operational self-tests must be completed successfully prior to any other use of cryptography by the Module. The only pre-operational test for the Module is the integrity test. If the integrity test fails, then the firmware will fail to start the Belmar ASIC, prohibiting any read or write operations. The drive will return a CRC_CHECK_FAILED code and control input will not be allowed. To become operational, the AES KAT test must be run. This will be run automatically during the “key initialization service” or can be run manually through the “run self-test” service. If the AES KAT test fails, the Module enters the KAT_ERROR error state, and the output of the “Show Status” service will be kat_test_passed=TEST_FAILED. Upon power-up, a user can read the self-test status through the "Show Status” service to determine the status of the self-tests. If the module is in the error state, then all cryptographic functions will be disabled, and a power cycle is required to get out of the error state. Below are the possible ways to enter the error state, and the accompanying status indicators:
• Integrity Test Failed ○ integrity_test_status=TEST_FAILED AES KAT Test Failed ○ kat_test_status=TEST_FAILED Key Initialization Failed ○ key_init_status=TEST_FAILED © 2015-2025 Pure Storage, Inc. Version 1.2 Pure Storage Inc. Public Material
• May be reproduced only in its original entirety (without revision).

The FlashBlade Data Encryption Module is integrated into Pure Storage Inc. storage products and is not delivered on its own as a standalone product. Pure Storage Inc.’s internal development process guarantees that the correct version of module goes with its intended products.

The module is configured to be operational by default. If the Flash Controller Chip starts up successfully and has successfully passed the Self-tests detailed in Section 10, it is operating correctly and can begin servicing requests. All the functions, ports and logical interfaces described in this document are implicitly available to the Crypto Officer and User roles. The module only provides approved functions, and as such there are no special procedures to configure or administer the approved mode of operation. There are no requirements for non-administrator operators. The operator can verify that the module is in the Approved mode of operation and that the FIPS validated version is being used, by checking the version output using the "Show Status" service. This is performed by invoking the 'wssdtool dump' command. The output will include the following: Chip version: NVMe2016.B1 Firmware Version: 2.10.27

When decommissioning the Flash Controller Chip a reset of the power will sanitize all SSPs in the module (the AES-XTS keys).

Not Applicable. The module does not support mitigation of other attacks. © 2015-2025 Pure Storage, Inc. Version 1.2 Pure Storage Inc. Public Material

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

The following standards are referred to in this Security Policy. Table 8

• References Table 9
• Acronyms and Definitions © 2015-2025 Pure Storage, Inc. Version 1.2 Pure Storage Inc. Public Material
• May be reproduced only in its original entirety (without revision).