Micron 7400 SSD Controller Sub Chip Security Subsystem

Certificate

Approved Algorithms (12)

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

flowchart LR
  %% Deterministic review-risk graph for Micron 7400 SSD Controller Sub Chip Security Subsystem
  %% 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>Firmware Load<br/>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>bootloader<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."]
    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?"]
    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"]
    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
  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,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Micron 7400 SSD Controller Sub Chip Security Subsystem
  %% 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>Firmware Load<br/>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>bootloader<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,C6 clueLow;

Security Policy, page by page

Micron Technology Micron Technology Micron 7400 SSD Controller Sub Chip Security Subsystem Non-Proprietary FIPS 140-3 Security Policy Document Version: 1.3 Date: April 11th, 2024 Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

Micron Technology Table of Contents Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

Micron Technology List of Tables Table 4

• Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed List of Figures Micron Technology, Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Micron Technology Controller Security Subsystem module, hereafter denoted as the Module. The Module is a Single Chip Hardware sub-chip cryptographic subsystem, as defined in FIPS 140-3 Implementation Guidance 2.3.B. The FIPS 140-3 security levels for the Module are as follows: Table 1

• Security Levels Micron Technology, Inc. Public Material
• May be reproduced only in its original entirety (without revision).

The Module is a Single Chip Hardware Sub-Chip cryptographic module operating on a single chip embodiment. The Module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated cryptographic controllers. The Module is embedded in the ASIC 7400 Controller package (see Figure 1 below). Figure 1 – Micron 7400 ASIC

The cryptographic module is tested on the following operational environment. Table 2 – Cryptographic Module Tested Configuration Module operational environment information is provided from the Module from the get status service and is returned from the controller as TCG Level 0 discovery content.

The physical form of the Module is depicted above in Figure 1. The cryptographic boundary of the Module is defined by the Security Subsystem and includes all cryptographic algorithm implementations. The physical embodiment is the Micron 7400 Controller ASIC and includes its package. The cryptographic boundary is depicted by the red outline line in Figure 2 below. The Module is a Single Chip Hardware Sub-Chip cryptographic module operating on a single chip embodiment. Table 2 above specifies the firmware components of the module. Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

Micron Technology M7400 SSD M7400 Controller NAND NAND NAND NAND NAND NAND NAND NAND NVMe Security Subsystem NAND NAND NAND NAND Figure 2 – Module

The Module only supports an Approved mode and cannot be configured to operate otherwise. To verify that the Module is in the Approved mode of operation, the operator may invoke the “Get Status” service, which will indicate the Approved mode of operation, as well as the version information for the Module. The following states are defined for the module.

• Firmware Load State
• In this state, the Module is capable of performing self-tests, key manifest verification, and firmware loading.
• NVMe State
• In this operating state, TCG ownership of the drive has not been taken. In this state the SSD provides services through NVME industry standard commands.
• TCG State
• Once TCG ownership has been taken the Module shall operate in this state. In this state the SSD provides services through NVME industry standard commands as well as TCG commands addressed to both the TCG Admin SP and the TCG locking SP. In addition, extra features are provided through the TCG commands. These commands are processed within the controller and are translated into security subsystem services. The Module provides these services to support the TCG mode of operation but is not responsible for TCG management functions. To initialize in this mode, the Module owner must take ownership of the device by invoking the Activate method on the Locking SP. This State has the capability to have multiple Users with independent access control to read, write or erase the data areas (LBA ranges). Micron Technology, Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Micron Technology Note: By default, the drive is issued with a single namespace encompassing the whole capacity of the drive. Once the drive is TCG activated this default namespace’s attributes are managed by the TCG “Global Range”.

The Module implements the cryptographic functions listed in table 3 below. The numbers and letters within square brackets reference standards which are defined in the References and Definitions section of this Security Policy. Table 3

• Approved Algorithms The XTS algorithm implementation includes a check to ensure Key_1 ≠ Key_2. XTS may only be used in storage applications. Micron Technology, Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Micron Technology The module does not implement any “Non-Approved Algorithms Allowed in the Approved Mode of Operation” or “Non-Approved Algorithms Not Allowed in the Approved Mode of Operation” per SP800140B. Only “Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed” are supported per Table 4 below. Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

Micron Technology Table 4 – Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed The following table shows the Security Function Implementations that the module implements: Table 5 - Security Function Implementation

1. The Module provides one distinct operator role: Controller, which acts as the Cryptographic Officer
2. The Module provides role-based authentication.
3. The Module clears previous authentications on reset.
4. An operator does not have access to any cryptographic services prior to assuming an authorized role.
5. The Module allows the operator to initiate power-up self-tests by power cycling power or resetting the Module.
6. Power up self-tests do not require any operator action.
7. Data outputs are inhibited during firmware loading, self-tests, zeroization, and error states.
8. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise
9. There are no restrictions on which keys or SSPs are zeroized by the zeroization service, except for the KManifestPUB_ROM.
10. The Module does not support concurrent operators.
11. The Module does not support a maintenance interface or role.
12. The Module does not support manual SSP establishment method.
13. The Module does not have any proprietary external input/output devices used for entry/output of data.
14. The Module does not output plaintext CSPs or intermediate key values. Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

Micron Technology

15. The Module does not provide bypass services.
16. The Module zeroizes temporary values generated and used during self-tests.

The Module is embedded within the Micron 7400 controller of the SSD. The Module shall be operated according to Section 11. Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

The Module’s ports and associated FIPS defined logical interface categories are listed in Table 5 above. Table 6

• Ports and Interfaces Micron Technology, Inc. Public Material
• May be reproduced only in its original entirety (without revision).

The Module supports one distinct operator role, Controller (Cryptographic Officer). Table 6 lists the operator role supported by the Module and their related services. In addition to the services listed in Table 6, the Module also supports a Self-Test service, which is invoked by power cycling the Module. The Module does not support a maintenance role or bypass capability. The Module does not support concurrent operators. Table 7

• Roles, Service Commands, Input and Output Micron Technology, Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Micron Technology *Requires additional authorization The role-based authentication methods are defined in Table 8 below. Table 8 – Roles and Authentication

All services implemented by the Module are listed in the Table 9 below. The services provided by the Module are defined in terms of the services being exposed at the Module (logical) boundary. Each service description also describes the operator roles involved along with the interface command associated with the service. The SSPs modes of access shown in Table 9 are defined as:

• 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. Implicitly include Read.
• Z = Zeroize: The Module zeroizes the SSP. The service indicator for approved services is the return code from an approved security service call (CCS). CCS = Command completion status, complies with the Approved Security Service Indicator defined in IG 2.4.C, Example Scenario #2. Micron Technology, Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Micron Technology Table 9

• Approved Services Micron Technology, Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Micron Technology ; E ; E Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

Micron Technology ; E E KFWModuleVerify; E; E KFWControllerVerify Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

The Module is composed of the following firmware components:

• Security Subsystem Operational: Runtime SCSS V2.3
• Security Subsystem Bootloader: Bootloader V1.0
• Function ROM v2.0
• Boot ROM v1.0 The pre-operational firmware integrity tests are performed using RSA SHA2-256 signature verification with a 2048-bit or 3072-bit key. The bootloader and operational runtime firmware are loadable components and are protected with the authentication technique, RSA SHA2-256 signature verification with a 2048-bit or 3072-bit key. Firmware candidates are isolated from load until they have successfully passed the Firmware Load Test. Firmware load and integrity checks are defined in the self-test section of this security policy. The ROM components are implemented in Non-Reconfigurable-Memory and are not subject to firmware integrity test per FIPS 140-3 IG 5.A. The operator can initiate the firmware integrity test on demand by power cycling/resetting the SSD. Micron Technology, Inc. Public Material
• May be reproduced only in its original entirety (without revision).

The Module has a limited operational environment under the FIPS 140-3 definitions. The tested operational environment is listed in Table 2. The Module includes a firmware verification and load service to support necessary updates. Firmware versions validated through the FIPS 140-3 CMVP will be explicitly identified on a validation certificate. Any firmware not identified in this Security Policy does not constitute the Module defined by this Security Policy or covered by this validation. Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

Micron Technology The Module is a Single Chip Hardware sub-chip cryptographic subsystem, and the embodiment is a single chip. The chip is encapsulated in a standard IC package. The IC packaging itself provides the necessary opacity and tamper evidence required for Level 2 conformance. Table 10

• Physical Security Inspection Guidelines Figure 3
• Tamper Evidence Example

The Module does not implement any mitigation method against non-invasive attack. Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

The SSPs access methods are described in below. The SSPs management methods as shown in Table 11 below are defined as:

• G1 = Externally generated and installed during manufacturing
• G2 = Internally generated using the DRBG
• G3 = Derived using SP 800-108 compliant KBKDF
• G4 = Derived using SP 800-132 compliant PBKDF2
• S1 = Only stored in volatile memory (RAM).
• S2 = Stored in e-Fuse in plaintext
• S3 = Stored in register in plaintext
• S4 = Stored in ROM in plaintext
• E1 = Input in plaintext
• E2 = Input signed and verified using KManifestPub_ROM
• E3 = Input using SP800-38F AES key Transport
• O1 = Output in plaintext public key
• O2 = Output using SP800-38F Key Transport (specify AES key wrap key)
• O3 = Output using KTS-IFC [56Br2]
• Z1 = Zeroized implicitly after use, by Module power cycle, and reset
• Z2 = Zeroized explicitly by the “zeroize” service by overwriting with a fixed pattern

All CSPs and PSPs used by the Module are described in this section. All usage of these SSPs by the Module is described in the services detailed in Section 4.3. The numbers and letters within square brackets reference standards which are defined in the References and Definitions section of this Security Policy. Table 11

• SSPs Micron Technology, Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Micron Technology Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

Micron Technology Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

The DRBG Randomness source (i.e., entropy) is loaded at manufacturing. Per IG 9.3.A, Example 2A, there is no assurance of the minimum strength of generated SSPs. The DRBG mechanism is SHA2-256, which has a security strength of 256-bits (per SP800-57, Part 1, Revision 5). The HASH DRBG is seeded with 128 bytes of entropy and 64 bytes of nonce material during manufacturing and is assumed to initialize the HASH DRBG to the full 256-bits security strength.

The Module performs self-tests to ensure the proper operation of the Module. Per FIPS 140-3 these are categorized as either pre-operational self-tests or conditional self-tests. Pre-operational and conditional self-tests are available on demand by resetting or power cycling the The self-tests error states and status indicator are described in Table 12 below: Table 12

• Error States and Indicators The Module performs the following pre-operational self-tests: Table 13
• Pre-Operational Self-Test The Module performs the following conditional self-tests: Micron Technology, Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Micron Technology Table 14 – Conditional Self-Tests DPE self-tests are initiated when functionality is requested. All other self-tests are initiated automatically when the module boots. The self-tests cannot be interrupted and will run to completion.

This section documents the operational behavior of the device.

The device is shipped from the factory in the Approved mode of operation and no further initialization is required to operate in the Approved mode. Going further, it is not possible to configure the module in such a way that it would operate in a non-compliant state or non-Approved mode. On receipt of the Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).

Micron Technology Module, examine the product to ensure it has not been tampered with during shipping according to the procedures outlined in Section 7.

The Module does not implement any mitigation method against other attacks.

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

• References Micron Technology, Inc. Public Material
• May be reproduced only in its original entirety (without revision).

Micron Technology Table 16– Acronyms and Definitions Micron Technology, Inc. Public Material – May be reproduced only in its original entirety (without revision).