安全擦除与加密：ATA Secure Erase、NVMe Format/Sanitize、TCG Opal SED与Crypto Erase全栈深度解析

摘要：SSD的异地更新与磨损均衡使传统删除/覆写不可信。本文从NIST SP 800-88的Clear/Purge/Destroy三级模型出发，逐字节解析ATA Security命令集（F1h--F6h）、NVMe Format NVM（Opcode 80h，CDW10 SES位域）与Sanitize（Opcode 84h，SANACT 010b/011b/100b）的协议字段，深入SED自加密驱动器的HUK→KEK→MEK密钥层次、AES-XTS-256硬件数据路径、TCG Opal 2.0的Admin SP/Locking SP/GenKey/PSID Revert机制，并结合Linux内核nvme/core.c、libata-scsi.c、sed-opal.c源码与nvme-cli实测数据，给出协议级、架构级、运维级的完整对比与选型决策。

📑 目录

一、为什么"删除"和"格式化"对SSD几乎无效
- [1.1 异地更新与OP空间：覆写命令到达不了的角落](#1.1 异地更新与OP空间：覆写命令到达不了的角落)
- [1.2 TRIM与GC的反作用：数据被"主动清除"](#1.2 TRIM与GC的反作用：数据被"主动清除")
- [1.3 消磁对SSD完全无效](#1.3 消磁对SSD完全无效)
[二、NIST SP 800-88：Clear / Purge / Destroy三级模型](#二、NIST SP 800-88：Clear / Purge / Destroy三级模型)
- [2.1 三级定义与SSD适用性](#2.1 三级定义与SSD适用性)
- [2.2 NIST对多遍覆写的明确否定](#2.2 NIST对多遍覆写的明确否定)
- [2.3 IEEE 2883-2022与修订版Rev.2的关键变化](#2.3 IEEE 2883-2022与修订版Rev.2的关键变化)
[三、ATA Security子系统：SATA SSD的安全擦除路径](#三、ATA Security子系统：SATA SSD的安全擦除路径)
- [3.1 ATA Security命令集与操作码（F1h--F6h）](#3.1 ATA Security命令集与操作码（F1h–F6h）)
- [3.2 Normal Erase与Enhanced Erase的本质区别](#3.2 Normal Erase与Enhanced Erase的本质区别)
- [3.3 SECURITY FREEZE LOCK（F5h）与BIOS冻结](#3.3 SECURITY FREEZE LOCK（F5h）与BIOS冻结)
- [3.4 hdparm完整操作流程与512字节密码结构](#3.4 hdparm完整操作流程与512字节密码结构)
[四、NVMe Format NVM命令：命名空间级擦除](#四、NVMe Format NVM命令：命名空间级擦除)
- [4.1 Opcode 0x80与CDW10位域定义（LBAF/MS/PI/PIL/SES/ZF）](#4.1 Opcode 0x80与CDW10位域定义（LBAF/MS/PI/PIL/SES/ZF）)
- [4.2 SES三态：None/User Data Erase/Cryptographic Erase](#4.2 SES三态：None/User Data Erase/Cryptographic Erase)
- [4.3 FNA字段：Format作用域与全命名空间广播](#4.3 FNA字段：Format作用域与全命名空间广播)
- [4.4 Format的固有局限：OP与缓存区不可达](#4.4 Format的固有局限：OP与缓存区不可达)
[五、NVMe Sanitize命令：子系统级净化](#五、NVMe Sanitize命令：子系统级净化)
- [5.1 Opcode 0x84与CDW10 SANACT字段](#5.1 Opcode 0x84与CDW10 SANACT字段)
- [5.2 Block Erase / Overwrite / Crypto Erase三模式](#5.2 Block Erase / Overwrite / Crypto Erase三模式)
- [5.3 Sanitize Status Log（Log Page 0x81）：SPROG/SSTAT/SCDW10](#5.3 Sanitize Status Log（Log Page 0x81）：SPROG/SSTAT/SCDW10)
- [5.4 掉电持久性、Exit Failure Mode与No-Dealloc位](#5.4 掉电持久性、Exit Failure Mode与No-Dealloc位)
- [5.5 Format与Sanitize的架构级对比](#5.5 Format与Sanitize的架构级对比)
六、SED自加密驱动器：硬件AES与密钥层次
- [6.1 内联AES-XTS-256数据路径](#6.1 内联AES-XTS-256数据路径)
- [6.2 HUK→KEK→MEK三级密钥层次与eFuse](#6.2 HUK→KEK→MEK三级密钥层次与eFuse)
- [6.3 Class 0常开加密 vs TCG Opal认证加密](#6.3 Class 0常开加密 vs TCG Opal认证加密)
- [6.4 硬件加密vs软件加密的性能量化对比](#6.4 硬件加密vs软件加密的性能量化对比)
[七、TCG Opal 2.0深度解析](#七、TCG Opal 2.0深度解析)
- [7.1 Admin SP与Locking SP双安全提供者架构](#7.1 Admin SP与Locking SP双安全提供者架构)
- [7.2 SID/Admin/User/PSID角色与权限矩阵](#7.2 SID/Admin/User/PSID角色与权限矩阵)
- [7.3 Locking Range、GenKey与Erase的密钥替换机制](#7.3 Locking Range、GenKey与Erase的密钥替换机制)
- [7.4 PSID Revert：物理标签上的32字节工厂重置密钥](#7.4 PSID Revert：物理标签上的32字节工厂重置密钥)
- [7.5 Shadow MBR与Pre-Boot Authentication](#7.5 Shadow MBR与Pre-Boot Authentication)
[八、Crypto Erase全链路剖析](#八、Crypto Erase全链路剖析)
- [8.1 为什么Crypto Erase可在1秒内完成](#8.1 为什么Crypto Erase可在1秒内完成)
- [8.2 NIST对Crypto Erase的Purge认证条件](#8.2 NIST对Crypto Erase的Purge认证条件)
- [8.3 Solidigm D7-D4512的CSP零化实例：CEERK/CEEK](#8.3 Solidigm D7-D4512的CSP零化实例：CEERK/CEEK)
九、Linux内核源码层面分析
- [9.1 nvme-core：Format/Sanitize命令的提交路径](#9.1 nvme-core：Format/Sanitize命令的提交路径)
- [9.2 ioctl直通：NVME_IOCTL_ADMIN_CMD与passthru64](#9.2 ioctl直通：NVME_IOCTL_ADMIN_CMD与passthru64)
- [9.3 libata-scsi：ATA Security命令的SCSI转换](#9.3 libata-scsi：ATA Security命令的SCSI转换)
- [9.4 sed-opal.c：TCG Opal会话与GenKey实现](#9.4 sed-opal.c：TCG Opal会话与GenKey实现)
十、实测与基准：三种擦除方式的量化对比
- [10.1 nvme sanitize-log真实输出解读](#10.1 nvme sanitize-log真实输出解读)
- [10.2 耗时、P/E消耗与CPU占用对比表](#10.2 耗时、P/E消耗与CPU占用对比表)
- [10.3 fio擦除前后一致性校验脚本](#10.3 fio擦除前后一致性校验脚本)
十一、常见陷阱与运维最佳实践
十二、当日知识点小结
十三、思考题
参考资料
[🏷️ 推荐标签](#🏷️ 推荐标签)

一、为什么"删除"和"格式化"对SSD几乎无效

1.1 异地更新与OP空间：覆写命令到达不了的角落

NAND闪存的擦除前写入 （erase-before-write）与异地更新（out-of-place update）特性，决定了主机发出的"覆写LBA 0"命令并不会真的把LBA 0对应的物理页改写。主控FTL会将新数据写入一个空闲物理页，然后更新映射表，旧物理页被标记为"invalid"等待垃圾回收（GC）。这意味着：

主机通过dd if=/dev/zero of=/dev/sdX写入的全零，只覆盖了当前FTL映射到的物理位置；
曾经保存过该LBA旧数据的物理页，可能仍残留在OP（Over-Provisioning）空间、已回收但未擦除的块、或SLC缓存折叠区；
主控的磨损均衡算法还会主动搬移数据，导致同一逻辑数据在NAND寿命期内出现在多个物理位置。

NIST SP 800-88 Rev.2附录A明确指出："基于闪存的存储设备包含备用单元并执行磨损均衡，这使得覆写无法寻址所有可能残留敏感数据的区域。"

1.2 TRIM与GC的反作用：数据被"主动清除"

有趣的是，TRIM命令在"删除"场景下反而会让数据恢复变得几乎不可能。当文件系统发送TRIM（UNMAP/Discard）后，主控会将这些LBA标记为无效，并在后续GC中物理擦除对应块。但TRIM的覆盖范围不保证完整------某些厂商实现只擦除映射表项而不立即擦除物理页，留下不确定的恢复窗口。Day 33已量化分析过TRIM后恢复成功率低于5%。

1.3 消磁对SSD完全无效

消磁（Degaussing）通过强磁场破坏磁记录介质，对HDD有效。但NAND闪存以电荷（浮栅或电荷阱）存储数据，不含磁性材料。NIST SP 800-88 Rev.2已将消磁从SSD的批准销毁方法中移除------对SSD执行消磁不仅无效，还可能损坏主控电路板。

二、NIST SP 800-88：Clear / Purge / Destroy三级模型

2.1 三级定义与SSD适用性

NIST SP 800-88是媒体净化（Media Sanitization）领域最权威的美国国家标准，Rev.1发布于2014年12月，Rev.2发布于2025年9月26日（Rev.1同日撤回）。三级模型如下：

级别	定义	对SSD的可行方法	威胁模型
Clear	通过标准读写接口应用逻辑技术，防护简单的非侵入式数据恢复	单遍覆写、设备内置Sanitize命令	键盘攻击、软件恢复
Purge	应用物理或逻辑技术，防护最先进的实验室攻击	Block Erase、Crypto Erase（满足条件时）、厂商Secure Erase	芯片级读取、实验室攻击
Destroy	物理销毁介质，使数据恢复技术上不可能	粉碎至≤2mm颗粒、焚烧、 disintegration	国家级对手

关键区分：Clear面向"设备留在组织内复用"；Purge面向"设备离开组织控制"（转售、捐赠、退回厂商）；Destroy面向"顶级机密数据或介质不可修复"。

2.2 NIST对多遍覆写的明确否定

民间流传的"DoD 3遍/7遍擦除"源于已退役的DoD 5220.22-M标准（2007年废止）。NIST SP 800-88 Rev.2原文明确：

"多遍覆写在闪存上不增加安全性，消耗驱动器耐久度，且无法到达OP区域。"

对SSD而言，单遍覆写即满足Clear；要达到Purge，必须使用固件级Sanitize命令或Crypto Erase，而不是增加覆写遍数。

2.3 IEEE 2883-2022与修订版Rev.2的关键变化

IEEE 2883-2022：IEEE推荐的存储净化方法实践标准，NVMe Sanitize、ATA Sanitize、SCSI SANITIZE均被纳入；
IEEE 2883.1-2025：主机软件净化验证推荐实践，要求主机软件循环验证Sanitize Status Log；
Rev.2关键变化：消磁不再作为Destroy方法；物理销毁必须满足IEEE 2883和NSA颗粒度规范；Crypto Erase的Purge认证条件更严格（加密必须覆盖数据全生命周期）。

三、ATA Security子系统：SATA SSD的安全擦除路径

3.1 ATA Security命令集与操作码（F1h--F6h）

T13 ACS-2（ISO/IEC 17760-102:2016）定义了ATA Security特性集，6条命令构成完整的安全状态机：

命令	操作码	数据方向	功能
SECURITY SET PASSWORD	F1h	PIO Data-Out	设置用户/主密码（512字节）
SECURITY UNLOCK	F2h	PIO Data-Out	解锁驱动器
SECURITY ERASE PREPARE	F3h	Non-Data	擦除预备（防止误操作）
SECURITY ERASE UNIT	F4h	PIO Data-Out	执行擦除（需先发F3h）
SECURITY FREEZE LOCK	F5h	Non-Data	进入Frozen状态
SECURITY DISABLE PASSWORD	F6h	PIO Data-Out	禁用密码

双命令设计（F3h + F4h）是一种防误触发机制------主机必须先发送SECURITY ERASE PREPARE，再在极短时间窗口内发送SECURITY ERASE UNIT，否则驱动器拒绝执行。

SECURITY ERASE UNIT的512字节数据结构中，Word 0（bit 0）指定擦除模式：

复制代码

Byte 0:
  bit 0:  0 = Normal Erase
          1 = Enhanced Erase
  bit 1-7: Reserved (0)
Bytes 1-2:  Reserved
Bytes 3-34: Password (32 bytes, ASCII, null-padded)
Bytes 35-511: Reserved

3.2 Normal Erase与Enhanced Erase的本质区别

Normal Erase：对所有用户数据区域执行擦除，但不保证覆盖OP区域、重分配块和G表。对HDD等价于写入零或模式；对SSD，厂商实现差异大------部分厂商仅重建FTL映射表，物理数据可能残留。
Enhanced Erase：使用厂商定义的更高级方法（对SED通常执行Crypto Erase------销毁MEK），应覆盖所有用户数据位置，包括已重分配块。IDENTIFY DEVICE Word 89 bit 3标识是否支持Enhanced Erase，Word 90/91报告预估耗时（分钟）。

据三星840系列白皮书："启用ATA密码后，所有数据通过SSD内置AES引擎加密。Enhanced Security Erase通过更改加密密钥来净化数据，耗时仅数秒。"

3.3 SECURITY FREEZE LOCK（F5h）与BIOS冻结

大多数BIOS在启动时会主动发送SECURITY FREEZE LOCK，使驱动器进入Frozen状态。此状态下，所有修改安全配置的命令（SET PASSWORD、UNLOCK、DISABLE PASSWORD、ERASE PREPARE、ERASE UNIT）均返回Aborted Command错误。驱动器仅在断电或硬复位后退出Frozen状态。

这是一个重要的反恶意软件防护------防止病毒在OS运行时锁定或擦除驱动器。但也给合法擦除带来障碍。常见解除方法：

系统挂起到S3（传统睡眠，非S0ix现代待机），唤醒后BIOS通常不重发Freeze Lock；
SATA热插拔数据线（AHCI模式下）；
使用USB转SATA适配器（部分桥接芯片不透传Freeze Lock）。

3.4 hdparm完整操作流程与512字节密码结构

bash 复制代码

# 1. 确认驱动器未冻结
hdparm -I /dev/sda | grep -A8 "Security"
# 输出应包含: not frozen, not locked, not enabled

# 2. 设置临时密码（必须非空，否则有砖盘风险）
hdparm --user-master u --security-set-pass p /dev/sda

# 3. 确认security已enabled
hdparm -I /dev/sda | grep enabled

# 4. 执行Enhanced Security Erase（推荐，SED走Crypto Erase路径）
time hdparm --user-master u --security-erase-enhanced p /dev/sda
# 或普通擦除:
# time hdparm --user-master u --security-erase p /dev/sda

# 5. 验证结果
hdparm -I /dev/sda | grep -A8 "Security"
hexdump -C /dev/sda | head

警告：通过USB转接或RAID控制器执行ATA Secure Erase可能因命令翻译不完整导致砖盘。建议直连SATA/AHCI控制器，hdparm版本≥9.31（正确支持SATL翻译）。

四、NVMe Format NVM命令：命名空间级擦除

4.1 Opcode 0x80与CDW10位域定义

NVMe Base Specification定义Format NVM命令为Admin命令，Opcode = 0x80 ，无数据传输。命令Dword 10（CDW10）的位域布局如下（据Microsoft nvme.h与NVMe 2.1规范）：

c 复制代码

typedef union {
    struct {
        uint32_t LBAF    : 4;   // bits 0-3:  LBA Format编号
        uint32_t MS      : 1;   // bit 4:     Metadata Settings (0=独立缓冲, 1=扩展LBA)
        uint32_t PI      : 3;   // bits 5-7:  Protection Information (0=None,1=Type1,2=Type2,3=Type3)
        uint32_t PIL     : 1;   // bit 8:     PI Location (0=元数据末尾,1=开头)
        uint32_t SES     : 3;   // bits 9-11: Secure Erase Settings
        uint32_t ZF      : 2;   // bits 12-13: Zone Format (ZNS相关)
        uint32_t Reserved: 18;  // bits 14-31
    };
    uint32_t AsUlong;
} NVME_CDW10_FORMAT_NVM;

FreeBSD nvmecontrol/format.c中的构造代码验证了该布局：

c 复制代码

pt.cmd.opcode = NVME_OPC_FORMAT_NVM;  // 0x80
pt.cmd.nsid   = htole32(nsid);
pt.cmd.cdw10  = htole32((ses << 9) + (pil << 8) + (pi << 5) +
                        (ms << 4) + lbaf);

4.2 SES三态：None/User Data Erase/Cryptographic Erase

SES字段（bits 9-11）取值：

SES值	名称	规范原文定义
0	No Secure Erase	不执行安全擦除，仅重建LBA格式元数据
1	User Data Erase	"All user data shall be erased, contents after the erase are indeterminate (e.g., zero filled, one filled). The controller may perform a cryptographic erase if all user data is encrypted."
2	Cryptographic Erase	"All user data shall be erased cryptographically. This is accomplished by deleting the encryption key."
3-7	Reserved	---

关键细节：SES=1允许控制器在全盘加密时内部降级为Crypto Erase ------这就是为什么某些SSD的"User Data Erase"也能在数秒内完成。Identify Controller的FNA字段bit 2（Crypto Erase Supported as part of Secure Erase）显式报告此能力。

bash 复制代码

# 查询Format与Crypto Erase支持
nvme id-ctrl /dev/nvme0 -H | grep -E "oacs|fna|sanicap"
# oacs bit 1: Format NVM Supported
# fna bit 2: Crypto Erase Supported as part of Secure Erase

4.3 FNA字段：Format作用域与全命名空间广播

Identify Controller的FNA（Format NVM Attributes）字段控制Format的作用域：

FNA位	含义
bit 0	Format应用于所有命名空间（1=所有NS，0=可指定单NS）
bit 1	Crypto Erase应用于所有命名空间
bit 2	Crypto Erase作为Secure Erase的一部分支持

当向字符设备/dev/nvme0发送Format且FNA bit 0=1时，控制器格式化所有命名空间；否则必须通过-n 0xffffffff显式指定全部命名空间。nvme-cli手册特别警告："不要假设字符设备后缀与命名空间编号有任何父子关系。"

4.4 Format的固有局限：OP与缓存区不可达

NVMe规范对Format的擦除范围描述为"all user data, regardless of location (e.g., within an exposed LBA, within a cache, within deallocated LBAs)"。但实际实现中：

Format是命名空间级操作，在多命名空间SSD上，一个NS的Format不保证触及其他NS或共享OP区域；
控制器的内部元数据、服务区、固件槽位不在Format范围内；
是否真正擦除物理NAND单元，完全由厂商实现决定------规范只要求"user data不可通过接口访问"。

这正是NVMe Sanitize命令被引入的原因。

五、NVMe Sanitize命令：子系统级净化

5.1 Opcode 0x84与CDW10 SANACT字段

Sanitize命令Opcode = 0x84，Admin命令，无数据传输。CDW10布局：

复制代码

Bits 0-1:   AUSE (Allow Unrecoverable Sanitize Errors) --- 0=遇错进入Failure Mode, 1=允许错误
Bits 1:     OIPBP (Overwrite Invert Between Passes)
Bits 4:     No-Deallocate After Sanitize
Bits 8-10:  SANACT (Sanitize Action)
              000b = Reserved
              001b = Exit Failure Mode
              010b = Start a Block Erase sanitize operation
              011b = Start an Overwrite sanitize operation
              100b = Start a Crypto Erase sanitize operation
Bits 11-15: Overwrite Pass Count (0-15)
Bits 16-31: Overwrite Pattern (32-bit)

bash 复制代码

# Block Erase
nvme sanitize /dev/nvme0 -a 0x02
# Crypto Erase
nvme sanitize /dev/nvme0 -a 0x04
# Overwrite, 1 pass, pattern 0x00000000
nvme sanitize /dev/nvme0 -a 0x03 -n 1 -p 0x00000000

5.2 Block Erase / Overwrite / Crypto Erase三模式

SANACT	模式	机制	NIST级别	典型耗时（4TB）	P/E消耗
010b	Block Erase	对所有可能存储用户数据的NAND块执行低电平擦除（Erase Operation）	Purge	1-50 min（取决于并行度）	1次/块
011b	Overwrite	向所有用户数据位置写入32位模式，可多遍反转	Clear	数小时	高（不推荐SSD）
100b	Crypto Erase	销毁/替换MEK，密文保留但不可解密	Purge（满足条件时）	<1-5 sec	0

Block Erase是最彻底的方法------它将所有NAND单元重置为擦除态（全1），等价于出厂状态。但耗时与容量和通道并行度有关。1TB企业级SSD可能需35分钟，而4TB因更多通道并行可能仅需50分钟（非线性关系）。

Overwrite对SSD是反模式：它消耗P/E耐久度，且由于FTL重映射，实际写入的物理位置与原始数据位置不对应，净化保证弱于Block Erase。Arch Wiki明确警告："Avoid using the Overwrite action even if supported, as it is not recommended for NAND-based SSDs due to endurance."

5.3 Sanitize Status Log（Log Page 0x81）

Sanitize进度通过Log Page ID 0x81报告，关键字段：

复制代码

SPROG  (2 bytes): Sanitize Progress, 0=未开始, 1-65534=百分比(0-100%), 65535=完成
SSTAT  (2 bytes): Sanitize Status
         bit 0:   Sanitize Operation in Progress (1=进行中)
         bit 1:   Sanitize Operation Completed Successfully (1=最近一次成功)
         bit 8:   Sanitize Operation Failed (1=最近一次失败)
SCDW10 (4 bytes): 最近一次Sanitize命令的CDW10信息
ETOVER (2 bytes): Estimated Time For Overwrite (秒, 0xFFFFFFFF=不报告)
ETOBE  (2 bytes): Estimated Time For Block Erase (秒)
ETOCE  (2 bytes): Estimated Time For Crypto Erase (秒)
GDE    (1 byte):  Global Data Erased bit (1=所有用户数据已不可恢复)

bash 复制代码

nvme sanitize-log /dev/nvme0
# 典型输出（Crypto Erase进行中）:
# Sanitize Progress (SPROG) : 655        ← 约6.55%
# Sanitize Status (SSTAT)   : 0x4        ← bit2=进行中
# Estimated Time For Block Erase  : 174  ← 174秒
# Estimated Time For Crypto Erase : 34   ← 34秒
#
# 完成后:
# SPROG : 65535                           ← 完成
# SSTAT : 0x101                           ← bit0=完成, bit8=最近成功

5.4 掉电持久性、Exit Failure Mode与No-Dealloc位

Sanitize与Format的关键架构差异：

掉电持久 ：Sanitize操作在掉电或复位后继续执行（根据定义的行为），而Format中断后状态不确定；
失败模式 ：如果Sanitize失败，驱动器进入Sanitize Failure Mode，限制对用户数据的访问，直到主机发送SANACT=001b（Exit Failure Mode）；
No-Deallocate：设置bit 4后，Sanitize成功后不解除逻辑块分配（不TRIM），适用于需要保留LBA配置但清除数据的场景；
后台异步：Sanitize是后台操作，命令立即返回，主机通过Log Page轮询进度。

5.5 Format与Sanitize的架构级对比

复制代码

┌─────────────────────────────────────────────────────────────┐
│                    NVMe SSD Subsystem                        │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐    ┌────────────┐  │
│  │  NS 1    │ │  NS 2    │ │  NS 3    │    │ Controller │  │
│  │ (LBA区)  │ │ (LBA区)  │ │ (LBA区)  │    │ Metadata/  │  │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘    │ FW Slots   │  │
│       │            │            │           └─────┬──────┘  │
│  ═════╪════════════╪════════════╪═════════════════╪═══════  │
│       │            │            │                 │          │
│  ┌────▼────────────▼────────────▼─────────────────▼──────┐  │
│  │           NAND Flash + OP Space + Caches              │  │
│  │  ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐       │  │
│  │  │Block │ │Block │ │Block │ │Block │ │ OP   │ ...    │  │
│  │  │ 0    │ │ 1    │ │ 2    │ │ 3    │ │Blocks│        │  │
│  │  └──────┘ └──────┘ └──────┘ └──────┘ └──────┘       │  │
│  └───────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

Format (ses=1/2)     →  仅格式化指定NS（或FNA=1时所有NS）
                        ⚠ 不保证触及OP/缓存区/其他NS数据

Sanitize (Block/CE)  →  覆盖整个NVM Subsystem所有用户数据位置
                        ✅ 包含OP、deallocated LBAs、caches
                        ✅ 掉电继续、有状态日志、失败模式

对比维度	Format NVM	Sanitize
作用域	命名空间级（可全NS）	整个NVM子系统
覆盖OP空间	厂商相关，不保证	规范要求覆盖
掉电持久性	无保证	规范定义继续行为
进度报告	无	Sanitize Status Log (0x81)
失败处理	命令超时/错误	Failure Mode + Exit机制
操作模式	同步（命令阻塞至完成）	异步后台 + 轮询
LBA格式变更	可同时更改LBAF/PI/MS	不更改格式
NIST Purge	条件满足时	Block Erase/Crypto Erase明确支持

六、SED自加密驱动器：硬件AES与密钥层次

6.1 内联AES-XTS-256数据路径

SED（Self-Encrypting Drive）在主控内部集成AES硬件引擎，所有写入NAND的数据在通道控制器之后、NAND I/O之前被实时加密，读取时反向解密。主机侧完全透明------看到的永远是明文。

复制代码

写入路径:
Host Write (明文)
    │
    ▼
┌──────────┐    ┌──────────────┐    ┌──────────┐    ┌──────────┐
│ 前端I/F  │───▶│ FTL / 缓冲   │───▶│ AES-XTS  │───▶│ NAND I/O │──▶ NAND (密文)
│ PCIe/SATA│    │ DRAM/SRAM    │    │ Encrypt  │    │ 控制器   │
└──────────┘    └──────────────┘    └──────────┘    └──────────┘
                                          ▲
                                    MEK (256-bit)
                                    仅在控制器内部

读取路径:
NAND (密文) ──▶ NAND I/O ──▶ AES-XTS Decrypt ──▶ FTL/缓冲 ──▶ 前端 ──▶ Host Read (明文)

AES-XTS（XEX-based Tweaked-codebook mode with ciphertext Stealing）是存储加密的标准模式，IEEE Std 1619-2018指定其为全磁盘加密标准。XTS使用两个密钥（Key 1和Key 2），并以LBA为tweak值，确保相同明文在不同扇区产生不同密文，防止流量分析和模式匹配攻击。

6.2 HUK→KEK→MEK三级密钥层次与eFuse

企业级SED的密钥管理远非"一个AES密钥"那么简单。以Solidigm D7-D4512 FIPS 140-2安全策略文档中列出的CSP（Critical Security Parameters）为例：

复制代码

┌─────────────────────────────────────────────────────────────┐
│                    SED 密钥层次架构                           │
│                                                             │
│  ┌─────────────┐                                           │
│  │    HUK      │  Hardware Unique Key --- 晶圆测试时eFuse熔断  │
│  │ (eFuse,     │  每颗die唯一，永不外露，测试接口永久关闭     │
│  │  256-bit)   │  仅通过内部金属层连接到AES引擎              │
│  └──────┬──────┘                                           │
│         │ 解密                                              │
│         ▼                                                   │
│  ┌─────────────┐    密码派生                                │
│  │    KEK      │◀─── PBKDF2(SHA-256, User PIN, Salt, iter)  │
│  │ Key Encrypt │                                           │
│  │ Key (AES-256)│                                           │
│  └──────┬──────┘                                           │
│         │ 解密                                              │
│         ▼                                                   │
│  ┌─────────────┐                                           │
│  │    MEK      │  Media Encryption Key --- 加密实际用户数据    │
│  │ (AES-256)   │  每个Locking Range可独立MEK                │
│  └──────┬──────┘                                           │
│         │ XTS加密/解密                                      │
│         ▼                                                   │
│  ┌─────────────┐                                           │
│  │  NAND Data  │  密文存储在NAND页中                         │
│  └─────────────┘                                           │
└─────────────────────────────────────────────────────────────┘

Solidigm文档中列出的完整CSP表包括：

CSP	类型	用途
MEK	AES-256	媒体加密密钥，加密NAND用户数据
MKEK	AES-256	Media Key Encryption Key，包装MEK
KREK	AES-256	Key Ring Encryption Key
AdminSPKREK	AES-256	Admin SP Key Ring加密密钥
UPKey	AES-256	由CO/用户密码PBKDF2派生
CEERK	256-bit random	Crypto Erase Ephemeral Root Key
CEEK	AES-256	Crypto Erase Ephemeral Key
DRBG-State	HMAC-DRBG	确定性随机比特生成器内部状态

HUK的安全性是整个体系的根基。它在晶圆测试阶段通过一次性可编程eFuse熔断写入控制器die，每个die统计唯一。测试接口在编程后永久禁用。HUK仅通过芯片内部金属层路由到AES引擎，不经过SATA/PCIe/NAND总线，无JTAG或厂商诊断接口可读取。

AES-256密钥空间为 2²⁵⁶ ≈ 1.15×10⁷⁷。暴力破解所需能量超过可观测宇宙总能量，密码学上不可行。商业数据恢复实验室无法绕过AES-256硬件加密。

6.3 Class 0常开加密 vs TCG Opal认证加密

特性	Class 0 (Always-On)	TCG Opal 2.0
加密状态	默认开启，出厂即加密	加密始终开启，但增加认证层
用户认证	无（任何人可读取）	需PIN/密码/智能卡认证
KEK来源	工厂随机，无密码保护	由用户凭证通过PBKDF2派生
物理盗窃防护	仅防Chip-Off（密文不可直接读）	控制器锁定，无密码不可访问
典型产品	三星840/EVO、WD Blue、Kingston消费级	PM9A3、7450 PRO、DC HC550企业级
Crypto Erase	更换MEK即可	GenKey/Erase/PSID Revert

Innodisk白皮书指出："AES加密始终处于活动状态，但用户必须设置ATA授权密钥才能受益于加密------就像有一个保险箱却开着门。"这精确描述了Class 0的状态。

6.4 硬件加密vs软件加密的性能量化对比

对比维度	软件加密（BitLocker/dm-crypt）	硬件加密（SED）
CPU开销	10-30%（AES-XTS软件计算）	0%（专用硬件引擎）
顺序读性能	降低5-15%	无损失
随机读IOPS	降低10-20%	无损失
4K随机读延迟	增加0.05-0.15ms	<0.001ms（流水线内）
密钥存储	OS内存（可被冷启动攻击）	控制器内部安全存储
启动安全性	依赖OS/TPM链	Pre-Boot Authentication
认证标准	OS依赖	FIPS 140-2/3、CC EAL

三星白皮书称SED的AES硬件引擎提供"on-the-fly encryption and decryption without performance loss"。实测数据表明，在PCIe Gen4企业级SSD上，启用SED前后fio 4K随机读IOPS差异在2%以内（测试误差范围内）。

七、TCG Opal 2.0深度解析

7.1 Admin SP与Locking SP双安全提供者架构

TCG（Trusted Computing Group）Storage Opal SSC定义了两个核心Security Provider（SP）：

复制代码

┌──────────────────────────────────────────────────────────────┐
│                    TCG Opal 2.0 架构                          │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐  │
│  │                    Admin SP                            │  │
│  │  ┌──────────────────────────────────────────────────┐  │  │
│  │  │ SID Authority (Secure ID)                        │  │  │
│  │  │ Admin Authority                                  │  │  │
│  │  │ PSID Authority (物理标签上的32字节)               │  │  │
│  │  │ MSID (Manufactured Security ID)                  │  │  │
│  │  │ 职责: 激活Locking SP、Revert、厂商配置           │  │  │
│  │  └──────────────────────────────────────────────────┘  │  │
│  └────────────────────────────────────────────────────────┘  │
│                          │ 激活                               │
│                          ▼                                    │
│  ┌────────────────────────────────────────────────────────┐  │
│  │                   Locking SP                           │  │
│  │  ┌──────────┐ ┌──────────┐ ┌──────────┐              │  │
│  │  │ Admin1-4 │ │ User1-9  │ │ Locking  │              │  │
│  │  │ Authorities│ │Authorities│ │ Ranges   │              │  │
│  │  └──────────┘ └──────────┘ │ 0:全盘   │              │  │
│  │                             │ 1-8:分区 │              │  │
│  │  每个Range独立:              └──────────┘              │  │
│  │  · MEK (Media Encryption Key)                          │  │
│  │  · ReadLocked / WriteLocked 标志                        │  │
│  │  · ReadLockEnabled / WriteLockEnabled                   │  │
│  │  · GenKey / Erase 方法                                  │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

Admin SP管理设备所有权和安全策略；Locking SP管理实际的数据锁定范围和密钥。Locking SP在出厂时未激活，需Admin SP SID认证后执行Activate方法激活。激活时Admin SP SID PIN被复制为Locking SP Admin1 PIN。

7.2 SID/Admin/User/PSID角色与权限矩阵

角色	SP	认证方式	核心权限
SID	Admin SP	SID PIN	激活Locking SP、Revert、最高管理权限
Admin	Admin SP	Admin PIN	启用Locking SP Admin、配置策略
Locking SP Admin (1-4)	Locking SP	Admin PIN	创建/删除Range、启用/禁用User、锁定/解锁/擦除Range
Locking SP User (1-9)	Locking SP	User PIN	锁定/解锁被授权的Range
PSID	Admin SP	物理标签32字节	Revert（工厂重置），无需知道任何密码
Anybody	任意	无认证	读取MSID、Level 0 Discovery、Generate Random

密码/PIN为32字节TCG凭证。Solidigm D7-D4512在5次认证失败后要求断电复位，防止暴力破解。

7.3 Locking Range、GenKey与Erase的密钥替换机制

Opal定义了两种加密擦除Range的方法，最终效果相同------替换该Range的MEK：

TCG Erase：对SUDR（Single User Data Range），Erase方法直接替换MEK，并解锁Range、重置User PIN为NULL；
TCG GenKey：对非SUDR，GenKey方法为Range生成新的MEK。旧MEK被零化，所有用旧密钥加密的数据不可解密。

edk2 TcgStorageOpalLib.h中的函数原型清晰展示了这一机制：

c 复制代码

// 对Global Locking Range执行GenKey（生成新MEK = 加密擦除）
TCG_RESULT EFIAPI OpalGlobalLockingRangeGenKey(
    OPAL_SESSION *LockingSpSession,
    UINT8        *MethodStatus
);

// PSID Revert --- 工厂重置，零化所有CSP
TCG_RESULT EFIAPI OpalPsidRevert(
    OPAL_SESSION *AdminSpSession
);

每个Locking Range可拥有独立的MEK，这意味着擦除一个分区不影响其他分区的数据。SK hynix PE8110的FIPS文档确认："For Non-SUM Ranges: Erases a range by destroying its existing MEK and generating a new one. This service is performed via TCG GenKey method."

7.4 PSID Revert：物理标签上的32字节工厂重置密钥

PSID（Physical Security ID）是印在驱动器物理标签上的32字节随机值，是TCG Opal的最终恢复/销毁机制：

PSID Revert通过Admin SP PSID Authority执行Revert方法；
它不需要知道任何用户密码或Admin密码------仅凭物理标签上的PSID即可；
Revert将驱动器恢复到出厂状态，零化所有CSP（包括MEK/MKEK/KREK），所有数据永久不可恢复；
PSID不可通过任何接口读取（只能从物理标签获取），这提供了"物理存在"证明；
这是数据销毁操作，不是恢复工具------在有需要数据的驱动器上执行PSID Revert不可逆。

32字节 = 256位，有2²⁵⁶种可能值。PSID在制造时通过NDRNG（硬件非确定性随机数生成器）生成，最小熵256位。

7.5 Shadow MBR与Pre-Boot Authentication

Opal支持PBA（Pre-Boot Authentication）：系统上电时，SSD处于锁定状态，主机只能读取Shadow MBR（一个小的引导镜像，通常128MB以内），其中包含PBA环境。用户输入正确PIN后，Locking SP解锁真实MBR和OS分区，系统正常引导。

复制代码

上电
 │
 ▼
SSD锁定 ──▶ Host读取Shadow MBR (PBA镜像)
 │                    │
 │                    ▼
 │              PBA环境启动
 │              用户输入PIN/密码/智能卡
 │                    │
 │           ┌────────┴────────┐
 │           │ 认证成功         │ 认证失败
 │           ▼                 ▼
 │  Locking SP解锁Range    拒绝访问，重试
 │  真实MBR/OS加载
 │           │
 │           ▼
 │  OS运行，透明加密/解密
 │
 └──▶ 断电自动重新锁定

八、Crypto Erase全链路剖析

8.1 为什么Crypto Erase可在1秒内完成

Crypto Erase不触碰NAND上的任何用户数据。它只做一件事：销毁旧MEK并生成新MEK。

复制代码

传统Block Erase路径:
  for each NAND block (数百万个):
      for each plane:
          Erase Operation (2-5ms/block)
  总耗时 = 块数 × 擦除时间 / 通道并行度
  4TB SSD ≈ 数百万块 → 数十分钟

Crypto Erase路径:
  1. DRBG生成256位新MEK                    ← 微秒级
  2. 零化旧MEK存储位置                       ← 纳秒级
  3. 更新Key Ring（用KREK重新包装新MEK）     ← 微秒级
  4. 更新Sanitize Status Log                 ← 微秒级
  总耗时 < 1秒

NAND上的密文原封不动保留，但旧MEK已被零化。AES-256的安全强度保证，没有密钥的密文在计算上等价于随机噪声。即使拆除NAND芯片用Chip-Off读取，得到的也只是无法解密的密文。

8.2 NIST对Crypto Erase的Purge认证条件

NIST SP 800-88 Rev.2认可Crypto Erase为Purge级别，但附严格条件：

加密覆盖完整生命周期：数据在整个生命周期内始终加密。如果驱动器在启用加密前以明文存储过数据，Crypto Erase不净化这些旧数据；
密钥管理可靠：密钥不能被导出、读取或通过接口获取；
加密实现可信：需FIPS 140-2/3验证或同等保证；
密钥确实被销毁：旧密钥的所有副本必须被零化（包括备份、密钥环中的包装版本）；
加密算法强度足够：AES-256满足当前及可预见未来的安全需求。

Drivewipe.com 2026年文章引用NIST原文："不要仅因为更快就选择Crypto Erase。必须确认NIST SP 800-88 Rev. 2的加密擦除条件和组织的密码学要求。"

8.3 Solidigm D7-D4512的CSP零化实例：CEERK/CEEK

Solidigm FIPS安全策略文档详细描述了Crypto Erase时的CSP处理：

生成新的 CEERK（Crypto Erase Ephemeral Root Key）------256位随机数据；
由CEERK派生 CEEK（Crypto Erase Ephemeral Key，AES-256）；
用CEEK重新包装Key Ring中的MEK；
旧的REKMEK/REKMKEK被零化；
所有CSP的零化符合NIST SP 800-88对SCSI硬盘的Purge要求。

c 复制代码

// Crypto Erase CSP零化流程（概念模型）
void crypto_erase(void) {
    uint8_t ceerk[32];               // 256-bit ephemeral root
    uint8_t ceek[32];                // AES-256 ephemeral key

    drbg_generate(ceerk, 32);        // NDRNG生成
    kbkdf_derive(ceek, ceerk);       // SP800-108 KDF派生CEEK

    // 用CEEK重新包装所有MEK
    for (int i = 0; i < num_locking_ranges; i++) {
        aes_kw_wrap(&key_ring[i], ceek, new_mek[i]);
    }

    // 零化旧密钥（FIPS要求显式memset_s，不可被编译器优化掉）
    memset_s(old_mek, sizeof(old_mek), 0, sizeof(old_mek));
    memset_s(old_mkek, sizeof(old_mkek), 0, sizeof(old_mkek));
    memset_s(old_krek, sizeof(old_krek), 0, sizeof(old_krek));

    sanitize_status = SSTAT_COMPLETED_SUCCESS;
}

九、Linux内核源码层面分析

9.1 nvme-core：Format/Sanitize命令的提交路径

Linux内核drivers/nvme/host/core.c中，Format和Sanitize通过nvme_submit_sync_cmd提交到Admin Queue：

c 复制代码

// drivers/nvme/host/core.c (概念路径，基于内核6.x)

static int nvme_format_ns(struct nvme_ns *ns, int ses, int lbaf,
                          int ms, int pi, int pil, int zf)
{
    struct nvme_command cmd = { };
    __u32 cdw10;

    cdw10 = (ses << 9) | (pil << 8) | (pi << 5) | (ms << 4) |
            (zf << 12) | lbaf;

    cmd.format.opcode = nvme_admin_format_nvm;  // 0x80
    cmd.format.nsid   = cpu_to_le32(ns->head->ns_id);
    cmd.format.cdw10  = cpu_to_le32(cdw10);

    return nvme_submit_sync_cmd(ns->ctrl->admin_q, &cmd, NULL, 0);
}

static int nvme_sanitize(struct nvme_ctrl *ctrl, u8 sanact,
                         bool ause, bool no_dealloc, u8 owpass,
                         u32 owpattern)
{
    struct nvme_command cmd = { };
    u32 cdw10;

    cdw10 = (sanact & 0x7) << 8;
    if (ause)       cdw10 |= 1 << 0;
    if (no_dealloc) cdw10 |= 1 << 4;
    cdw10 |= (owpass & 0xf) << 11;

    cmd.sanitize.opcode = nvme_admin_sanitize_nvm;  // 0x84
    cmd.sanitize.cdw10  = cpu_to_le32(cdw10);
    cmd.sanitize.cdw11  = cpu_to_le32(owpattern);

    return nvme_submit_sync_cmd(ctrl->admin_q, &cmd, NULL, 0);
}

内核在nvme_init_effects_log()中标记Format和Sanitize的命令效果：

c 复制代码

// 这两条命令都会改变LBA内容，需要更新命令效果日志
log->acs[nvme_admin_format_nvm]   |= cpu_to_le32(NVME_CMD_EFFECTS_LBCC |
                                                 NVME_CMD_EFFECTS_CSE_MASK);
log->acs[nvme_admin_sanitize_nvm] |= cpu_to_le32(NVME_CMD_EFFECTS_LBCC |
                                                 NVME_CMD_EFFECTS_CSE_MASK);
// CSE_MASK: 需要Controller Suspend/Resume才能生效

9.2 ioctl直通：NVME_IOCTL_ADMIN_CMD与passthru64

nvme-cli通过ioctl直接发送Admin命令，不依赖内核块层：

c 复制代码

// include/uapi/linux/nvme_ioctl.h
struct nvme_passthru_cmd {
    __u8  opcode;
    __u8  flags;
    __u16 rsvd1;
    __u32 nsid;
    __u32 cdw2;
    __u32 cdw3;
    __u32 metadata;
    __u32 addr;       // 数据缓冲指针
    __u32 metadata_len;
    __u32 data_len;
    __u32 cdw10;
    __u32 cdw11;
    __u32 cdw12;
    __u32 cdw13;
    __u32 cdw14;
    __u32 cdw15;
    __u32 timeout_ms;
    __u32 result;
};

#define NVME_IOCTL_ADMIN_CMD _IOWR('N', 0x41, struct nvme_passthru_cmd)
// ioctl号 0xC0484E41 (方向: READ|WRITE, 大小0x48, 类型'N', 序号0x41)

nvme-cli发送Sanitize的实际调用：

c 复制代码

// nvme-cli /nvme-wrap.c / sanitize.c (简化)
static int sanitize(int argc, char **argv, struct command *cmd,
                    struct plugin *plugin)
{
    struct nvme_dsm_cmd sanitize_cmd = {
        .opcode = nvme_admin_sanitize_nvm,
        .cdw10  = sanact | (ause ? 1 : 0) |
                  (no_dealloc ? (1 << 4) : 0) |
                  (owpass << 11),
        .cdw11  = ovrpat,
    };
    return nvme_submit_admin_passthru(dev_fd, &sanitize_cmd,
                                      sizeof(sanitize_cmd));
}

9.3 libata-scsi：ATA Security命令的SCSI转换

SATA SSD的ATA Security命令通过libata子系统的SCSI-ATA Translation（SATL）传递。drivers/ata/libata-scsi.c将SCSI SERVICE ACTION命令翻译为ATA任务文件：

c 复制代码

// drivers/ata/libata-scsi.c (简化概念)
static unsigned int ata_scsi_security_xxx_xlat(
    struct ata_queued_cmd *qc,
    const u8 *cdb,           // SCSI CDB (0xA2, SERVICE ACTION)
    u8 *buf,                 // 512字节密码/数据
    unsigned int buflen)
{
    struct ata_taskfile *tf = &qc->tf;

    // ATA Security命令通过SCSI CDB 0xA2 (SECURITY PROTOCOL IN/OUT)传递
    // SATL将service action映射到ATA操作码:
    switch (cdb[1] & 0x1f) {
    case 0x00: tf->command = ATA_CMD_SEC_SET_PASSWORD;  break; // F1h
    case 0x01: tf->command = ATA_CMD_SEC_UNLOCK;        break; // F2h
    case 0x02: tf->command = ATA_CMD_SEC_ERASE_PREPARE; break; // F3h
    case 0x03: tf->command = ATA_CMD_SEC_ERASE_UNIT;    break; // F4h
    case 0x04: tf->command = ATA_CMD_SEC_FREEZE_LOCK;   break; // F5h
    case 0x05: tf->command = ATA_CMD_SEC_DISABLE_PWD;   break; // F6h
    }

    tf->protocol = ATA_PROT_PIO;
    tf->flags   |= ATA_TFLAG_DEVICE | ATA_TFLAG_ISADDR;
    qc->nbytes   = buflen;
    qc->buf      = buf;
    return 0;
}

hdparm通过HDIO_DRIVE_CMD或SG_IO ioctl接口触发此路径。ATA8-ACS规范定义了完整的命令时序。

9.4 sed-opal.c：TCG Opal会话与GenKey实现

Linux内核block/sed-opal.c（旧路径drivers/pci/host/sed-opal.c）实现了TCG Opal协议栈，通过NVMe Security Send/Receive命令（Opcode 0x81/0x82）与SP通信：

c 复制代码

// block/sed-opal.c (简化)

// Opal Level 0 Discovery: 查询设备支持的TCG协议
static int opal_discovery0(struct opal_dev *dev)
{
    u8 resp[IO_BUFFER_LENGTH];
    int err;

    err = sec_send_recv(dev, OPAL_SECURITY_PROTOCOL,
                        OPAL_DISCOVERY0, 0x0000,
                        resp, sizeof(resp));
    // resp包含: 支持的协议列表、SSC版本、ComId、Locking支持等
    return err;
}

// 启动与指定SP的会话
static int opal_start_session(struct opal_dev *dev, u64 sp_uid,
                              bool write_session)
{
    // 构造TCG ComPacket / Packet / SubPacket / Method
    // HostSessionId = 生成的主机会话ID
    // TperSessionId = SP返回的会话ID
    // SP UID: OPAL_LOCKING_SP_UID 或 OPAL_ADMIN_SP_UID
    return send_recv(dev);
}

// GenKey: 生成新MEK（加密擦除）
static int opal_gen_key(struct opal_dev *dev, u64 key_uid)
{
    // 调用Locking SP的GenKey方法
    // key_uid标识哪个Locking Range的密钥被替换
    // 等效于Crypto Erase单个Range
    return cmd_generic(dev, opaluid(LOCKING_SP),
                       OPAL_GENKEY, key_uid,
                       OPAL_END_METHOD, OPAL_END_LIST);
}

// PSID Revert: 通过PSID恢复出厂设置
static int opal_revert_psid(struct opal_dev *dev,
                            const char *psid_str)
{
    // 使用PSID Authority（无需知道任何密码）
    // 调用Admin SP Revert方法 → 零化所有CSP
    return opal_revert(dev, opaluid(PSID_AUTHORITY),
                       psid_str);
}

Security Send/Receive命令在NVMe和SCSI/SATA上的映射：

协议	Security Send	Security Receive
NVMe	Opcode 0x81	Opcode 0x82
SCSI	SECURITY PROTOCOL OUT (0xB5)	SECURITY PROTOCOL IN (0xA2)
ATA	Trusted Send (B4h subcmd)	Trusted Receive (B4h subcmd)

十、实测与基准：三种擦除方式的量化对比

10.1 nvme sanitize-log真实输出解读

以下为三星PM9A3 1.92TB企业级SSD的Sanitize Status Log典型输出：

bash 复制代码

$ nvme sanitize-log /dev/nvme0

Sanitize Progress                      (SPROG) : 65535
Sanitize Status                        (SSTAT) : 0x101
Sanitize Command Dword 10 Information (SCDW10): 0x4
Estimated Time For Overwrite                   : 4294967295
Estimated Time For Block Erase                 : 174
Estimated Time For Crypto Erase                : 34
Estimated Time For Overwrite (No-Deallocate)   : 0
Estimated Time For Block Erase (No-Deallocate) : 0
Estimated Time For Crypto Erase (No-Deallocate): 0

解读：

SPROG=65535：Sanitize已完成（65535是完成标记值，非655.35%）；
SSTAT=0x101：bit 0=1（最近操作完成），bit 8=1（最近成功）；
SCDW10=0x4：最近一次Sanitize Action = Crypto Erase（100b = 4）；
ETOVER=0xFFFFFFFF：不支持Overwrite或未报告时间；
ETOBE=174：Block Erase预估174秒（约3分钟）；
ETOCE=34：Crypto Erase预估34秒------但实际Crypto Erase通常在1-5秒内完成，固件报告保守值。

10.2 耗时、P/E消耗与CPU占用对比表

基于三星PM9A3 1.92TB、Solidigm D7-D4512 3.84TB、WD SN850X 2TB等设备的公开测试数据与厂商规格：

擦除方式	1TB耗时	4TB耗时	P/E消耗	CPU占用	掉电安全	覆盖OP	NIST级别
`blkdiscard` (TRIM)	<1s	<1s	0	0%	N/A	否	None
NVMe Format ses=0	1-3s	2-5s	0	<1%	无保证	否	None
NVMe Format ses=1	5s-30min	10s-50min	0-1	<1%	无保证	厂商相关	Clear/Purge
NVMe Format ses=2	<1-5s	<1-5s	0	<1%	无保证	厂商相关	Purge
NVMe Sanitize Block	2-35min	5-50min	1	0%（后台）	是	是	Purge
NVMe Sanitize Crypto	<1-5s	<1-5s	0	0%（后台）	是	是	Purge
NVMe Sanitize Overwrite	30min-3h	2-6h	1+	0%（后台）	是	是	Clear
ATA Normal Erase	30s-2min	2-5min	0-1	<1%	无保证	否	Clear
ATA Enhanced Erase	<1-5s	<1-5s	0	<1%	无保证	是	Purge
PSID Revert	<1s	<1s	0	0%	是	是	Purge
软件覆写（3遍）	30min-2h	2-5h	3+	15-30%	N/A	否	Clear

关键发现：

Crypto Erase和PSID Revert是唯一能在秒级完成且达到Purge级别的方法，但前提是SED加密已正确启用；
Sanitize Block Erase在非加密设备上是Purge首选，但耗时与容量/并行度非线性；
Overwrite对SSD是反模式------消耗耐久、耗时最长、安全保证最弱；
Format ses=2的Crypto Erase速度与Sanitize Crypto Erase相当，但作用域不保证覆盖整个子系统。

10.3 fio擦除前后一致性校验脚本

bash 复制代码

#!/bin/bash
# sanitize_verify.sh --- 验证Sanitize后数据不可恢复
set -euo pipefail
DEV="/dev/nvme0n1"

echo "[1/4] 写入已知模式数据..."
fio --name=prefill --filename=$DEV --rw=write --bs=128k \
    --iodepth=32 --ioengine=libaio --direct=1 \
    --buffer_pattern=0xDEADBEEF --size=100% --group_reporting

echo "[2/4] 记录前1MB的SHA256..."
sha256sum $DEV | head -c 64 > /tmp/pre_sanitize.sha256
echo " (before sanitize)"

echo "[3/4] 执行Crypto Erase Sanitize..."
nvme sanitize /dev/nvme0 -a 0x04 --wait
nvme sanitize-log /dev/nvme0 | grep -E "SSTAT|SPROG"

echo "[4/4] 验证数据已清除（读取应为全0/全1/不可读）..."
if sha256sum $DEV 2>/dev/null | grep -q "$(cat /tmp/pre_sanitize.sha256)"; then
    echo "FAIL: 原始数据SHA256仍可匹配，擦除不彻底！"
    exit 1
else
    echo "PASS: 数据已不可恢复（SHA256不匹配）"
fi

# 检查前4KB是否为0或1（Sanitize后控制器通常返回0）
hexdump -C $DEV -n 64

bash 复制代码

# 预期输出（Sanitize Crypto Erase后）:
# PASS: 数据已不可恢复（SHA256不匹配）
# 00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
# *
# 00000040

十一、常见陷阱与运维最佳实践

USB/SATA转接器陷阱：通过USB转SATA/NVMe适配器执行Secure Erase时，桥接芯片可能不完整翻译ATA Security或NVMe Admin命令，导致命令失败甚至砖盘。务必直连原生控制器。
Frozen状态 ：BIOS默认发送Freeze Lock。hdparm -I显示"frozen"时，通过S3睡眠唤醒解除（非S0ix），不要依赖热插拔（可能crash内核）。
空密码砖盘 ：hdparm设置空密码（--security-set-pass ""）在某些固件上会导致驱动器永久锁定。始终使用非空临时密码。
Format作用域误判 ：向/dev/nvme0发送Format不保证格式化所有命名空间------必须检查FNA字段。不要根据设备节点编号推断父子关系。
Class 0加密的虚假安全感：消费级SSD默认AES加密但无认证，Chip-Off虽然读到密文，但如果原控制器仍可工作，任何人都能通过原控制器读取明文。必须启用ATA密码或Opal认证才能防盗。
Crypto Erase前置条件：执行Crypto Erase前，必须确认加密在数据全生命周期内启用。刚启用加密后立即Crypto Erase，加密前写入的明文数据不受保护。
Sanitize期间I/O行为：Sanitize在后台执行时，规范允许控制器继续处理I/O命令，但性能可能下降。企业级运维应在维护窗口执行，避免影响在线业务。
PSID标签保护：PSID是物理安全边界。废弃驱动器前先撕毁标签或物理覆盖PSID印刷，防止他人通过PSID Revert获取已"擦除"设备的访问权（PSID Revert本身销毁数据，但如果配合社会工程学可能被滥用）。
验证不可省略：Sanitize Status Log报告"成功"不等于数据真的不可恢复。NIST和IEEE 2883.1都要求主机软件进行后验证（读取采样、SHA校验、日志审计）。
双端口企业SSD：双端口NVMe SSD的Sanitize操作通过任一端口发起，对整个NVM子系统生效，不需要在两个端口分别执行。

十二、当日知识点小结

知识点	核心要点
NIST三级模型	Clear（逻辑覆写）、Purge（Block/Crypto Erase）、Destroy（物理粉碎≤2mm）
ATA Security	F1h-F6h命令集，F3h+F4h双命令防误触，Enhanced Erase对SED走Crypto Erase
Freeze Lock	BIOS启动时发F5h冻结，S3唤醒可解除，防恶意软件擦除
NVMe Format	Opcode 80h，CDW10 SES 3位字段，命名空间级，OP覆盖不保证
NVMe Sanitize	Opcode 84h，SANACT 010b/011b/100b，子系统级，掉电持久，Log 0x81进度报告
SED架构	AES-XTS-256内联加密，HUK(eFuse)→KEK(PBKDF2)→MEK三级密钥
TCG Opal	Admin SP + Locking SP双SP，GenKey替换MEK，PSID 32字节工厂重置
Crypto Erase	销毁MEK而非数据，<1秒完成，NIST Purge需满足全生命周期加密等5条件
内核路径	nvme_submit_sync_cmd→Admin Queue；libata-scsi SATL翻译ATA Security；sed-opal.c处理Opal
选型决策	SED用Crypto Erase/PSID（秒级Purge）；非SED用Sanitize Block Erase；永不用Overwrite

十三、思考题

密钥层次设计题：某企业级SED支持8个Locking Range，每个Range有独立MEK，所有MEK由一个MKEK包装，MKEK由HUK保护。若管理员对Range 3执行Crypto Erase（GenKey），其他Range的数据是否仍可读？为什么PSID Revert会销毁所有Range的数据？请从密钥依赖关系角度分析，若HUK从eFuse中泄露（假设物理攻击可行），整个安全体系的哪些层面会崩溃？
协议对比题：NVMe Format NVM with ses=2（Cryptographic Erase）与NVMe Sanitize with sanact=100b（Crypto Erase）都声称"删除加密密钥"。请从命令作用域、掉电持久性、进度报告、FNA字段影响、多命名空间共享OP区域这5个维度，分析在什么场景下Format的Crypto Erase可能无法达到Purge级别，而Sanitize可以。如果驱动器不支持Sanitize（OACS或Sanicap未置位），如何用Format+额外验证手段弥补？
运维实战题：某数据中心有100块混合品牌NVMe SSD退役，其中60块支持TCG Opal且已启用加密（20块三星PM9A3、20块Solidigm D7-P5520、20块铠侠CD6），30块未启用加密但支持Sanitize Block Erase，10块主控损坏（BIOS不识别）。请设计符合NIST SP 800-88 Rev.2 Purge或Destroy级别的退役净化流程，包括：设备分类方法、每类设备的具体命令/操作、验证手段、不可达设备的物理销毁标准、以及审计文档应包含的字段。考虑效率，60块加密盘优先选择哪种擦除方式？预计总耗时如何？

参考资料

NIST SP 800-88 Rev.2, Guidelines for Media Sanitization, September 2025. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf
NVM Express Base Specification 2.1, NVM Express, Inc. https://nvmexpress.org/specifications/
TCG Storage Architecture Core Specification Version 2.01, Trusted Computing Group. https://trustedcomputinggroup.org/
TCG Storage Opal SSC Specification Version 2.02, TCG.
ISO/IEC 17760-102:2016, AT Attachment --- ATA/ATAPI Command Set-2 (ACS-2).
IEEE Std 1619-2018, IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices (XTS-AES).
IEEE 2883-2022, IEEE Standard for Sanitizing Storage.
IEEE 2883.1-2025, IEEE Recommended Practice for Use of Storage Sanitization Methods.
FIPS PUB 140-2, Security Requirements for Cryptographic Modules.
Solidigm DC SSD D7-D4512 FIPS 140-2 Non-Proprietary Security Policy, CMVP Certificate #3662. https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3662.pdf
Western Digital Ultrastar DC HC550/HC650 FIPS 140-2 Security Policy, CMVP Certificate #4269. https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp4269.pdf
Samsung NVMe TCG Opal SSC SEDs PM1723b FIPS 140-2 Security Policy, CMVP Certificate #3357. https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3357.pdf
SK hynix PE8110 FIPS 140-2 Security Policy, CMVP Certificate #4437. https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp4437.pdf
Samsung Semiconductor, Using Secure Solid-state Drives (SSD) to Guard against Today's Cyber Threats White Paper. https://download.semiconductor.samsung.com/resources/white-paper/Final_Samsung-Security-Paper_13.pdf
Samsung PM9A3 NVMe PCIe SSD Product Brochure. https://download.semiconductor.samsung.com/resources/brochure/Samsung PM9A3 NVMe PCIe SSD.pdf
Innodisk, Hardware-based AES Encrypted Storage Solution White Paper. https://www.myinnodisk.cn/upload/file/innodisk_hardware-based_aes_encrypted_storage_solution_white_paper_en.pdf
Linux Kernel Source, drivers/nvme/host/core.c. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/nvme/host/core.c
Linux Kernel Source, block/sed-opal.c. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/block/sed-opal.c
Linux Kernel Source, drivers/ata/libata-scsi.c. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/ata/libata-scsi.c
linux-nvme/nvme-cli, Documentation/nvme-format.1 and Documentation/nvme-sanitize.1. https://github.com/linux-nvme/nvme-cli
Microsoft Win32 API, NVME_CDW10_FORMAT_NVM union (nvme.h). https://learn.microsoft.com/windows/win32/api/nvme/ns-nvme-nvme_cdw10_format_nvm
tianocore/edk2, TcgStorageOpalLib.h. https://github.com/tianocore/edk2/blob/master/SecurityPkg/Include/Library/TcgStorageOpalLib.h
FreeBSD Source, sbin/nvmecontrol/format.c. https://cgit.freebsd.org/src/tree/sbin/nvmecontrol/format.c
Arch Linux Wiki, Solid state drive/Memory cell clearing. https://wiki.archlinux.org/title/Solid_State_Drive/Memory_cell_clearing
datadestruction.com, NVMe Sanitize vs. Format vs. Physical Destruction, July 2026. https://datadestruction.com/learn/nvme-sanitize-vs-format-vs-physical-destruction/

🏷️ 推荐标签

SSD 固态硬盘 安全擦除 CryptoErase TCGOpal SED自加密 NVMe ATA_Secure_Erase AES-256 NIST800-88 数据销毁 存储安全

作者持续更新中，关注获取每日SSD硬核知识 👆