存储加密与密钥管理

加密机制、自加密盘、密钥生命周期与安全启动链 —— 一份以「密钥管得住，加密才有效」为主线的电路设计参考 ｜ 编制日期 2026-10-14 ｜ 版本号 Rev 1.0

结论： 加密算法是公开的成熟件，存储安全的胜负手在密钥——生成靠真随机、驻留靠熔丝与安全区、使用靠只写内联引擎、销毁靠 crypto erase；再配一条从信任根出发的启动链与一个单调递增的计数器防回滚。密钥与数据不共介质、加密与认证不混为一谈、版本只进不退，这三条做到了，加密才从「合规说法」变成「真防护」。所有机制口径以正式规范与器件 datasheet 为准。

前言

这份文档的定位是电路与系统设计参考，不是密码学教材：它不证明算法为什么安全，也不复述任何标准的条文——那些事情标准组织已经做完了。它回答的是工程师在方案评审、原理图设计、固件架构与测试规划里真正会问出口的问题：密钥放哪、引擎怎么接、盘要不要选自加密、启动链验到哪一级、回滚怎么防。

因此全文的写法是「机制优先」：先建立威胁模型与攻击者分级，再逐层讲算法、引擎、SED、密钥生命周期、启动链与防回滚，最后用三个失效案例把前面的机制串起来，并给出标准与合规的映射。文中不写寄存器地址、位域位置、选项字节默认值与具体 opcode，也不写任何商业数据；所有数值均为量级口径，落地时以器件 datasheet、TCG 规范与 NIST / IEEE / JEDEC 等正式规范为准。

读者路径

• 先想清楚防谁：第 1 章（暴露面与攻击者分级）+ 第 2 章（加密与认证的边界）。
• 正在选加密方案：第 3 章（引擎与数据通路）+ 第 4 章（SED 与 TCG Opal）+ 第 9 章（加密位置三选一）。
• 负责密钥与固件安全：第 5 章（生成与派生）+ 第 6 章（驻留与保护）+ 第 7 章（启动链）+ 第 8 章（RPMB 防回滚）。
• 做安全评估与合规：第 10 章（失效案例）+ 第 11 章（标准与合规映射）+ 附录 B（密钥管理检查单）。
• 只想要结论与速查：第 12 章（要点汇总与清单）+ 附录 A（加密参数速查）+ 附录 C（术语表）。

1. 问题本质：数据在存储侧暴露了什么

这一章不涉及任何算法细节，只把问题还原成机制：数据在存储侧到底暴露在哪些面上、攻击者被分成几级能力、加密能解决什么不能解决什么。后面所有章节的技术选择，都是这一章四个判断的投影；先把威胁模型立住，后面的算法与密钥决策才有锚点。

1.1 存储侧的数据暴露面

存储器件在系统里的位置很特殊：它坐在数据通路的末端，却握着全量数据；它不参与运算，却要在掉电之后长期保管信息。这个位置决定了它的暴露面不是「一个」，而是至少六个——从整机丢失到供应链截获，攻击者能碰到存储的环节远比想象中多。

• 设备丢失：整机被带走，数据静态随设备流失，攻击者拿到的是「完整系统加全量数据」。
• 拆机取盘：把存储器件从板上拆下，用编程器或测试座直接读裸片，绕过一切软件防护。
• 维修流转：返厂、换主控、换板的过程中，旧板旧盘带着数据流出可控环境。
• 报废处置：二手盘被恢复软件读取残余数据，是数据泄露最古老的形态之一。
• 总线截获：运行时用探针接在数据总线上，偷的是「明文流动的瞬间」。
• 供应链截获：流通环节被替换、被预置、被改写固件，攻击发生在数据写入之前。

六个暴露面有一个共同点：攻击者最终拿到的是物理介质，或它的精确副本。这决定了防护思路也统一——让介质上的数据在没有密钥时不可读，并且让密钥不跟数据待在同一个暴露面上。第 5、6 章讲密钥怎么放，本质上就是在回答这个问题。

前四类针对静态数据（丢失、拆机、维修、报废）：介质在手，内容可读；后两类针对运行与流通（总线截获、供应链截获）：数据正在流动或尚未写入。这个切分很重要——静态加密对前四类有效，后两类要靠总线加密、安全启动与供应链接管兜底（第 3、7 章）。把六类暴露面混成一句「数据加密了就没事」，是存储安全里最常见的过度承诺。

第 1 章图 1 的读法：六张卡片是六个独立入口，不是六个同时成立的场景——一次攻击通常只走一条路径，但六条路径里任何一条没堵住，前面的加密努力就归零。这也解释了为什么本文的章节顺序是「威胁 → 算法 → 引擎 → 盘 → 密钥 → 启动 → 系统」：每一步都在堵一类路径，合起来才是完整防线。

1.2 攻击者能力分级

防护强度不能拍脑袋，先给攻击者分级。工程上按「能碰到什么、能花多少成本」分成四级：等级越高，能力越强，防护成本也越高。设计时先回答「防到哪一级」，再选机制——防 L0 用传输加密就够，防 L3 要上掩码与防拆，两者差着一个数量级的成本。分级的价值在于把「安不安全」这个主观问题，变成「防谁」这个可回答问题。

四个等级的判据是「攻击成本」而不是「攻击者身份」：同样一个攻击者，面对不同产品愿意投入的成本完全不同。按数据价值定级，而不是按产品档次定级——一把车钥匙里的凭证和一块广告屏里的缓存，不该用同一套防护预算。

第 1 章图 2 把四级画成了阶梯：左侧纵轴是能力方向，右侧每条横带给出「能攻破什么、对应什么防护」。注意 L2 到 L3 之间没有渐变——它是成本的分水岭：L2 及以下靠设计纪律（密钥隔离、内联引擎）就能防住，L3 要动用到材料与工艺（掩码、防拆、传感器），研发周期和成本都跳一档。多数消费与工业产品把设计目标定在「完整覆盖 L0~L1、尽力覆盖 L2、显式评估 L3」，而不是笼统追求「最高安全」。

1.3 加密能解决与不能解决的问题

加密交付的是机密性：没有密钥，介质上的数据与随机噪声不可区分。这一条价值极大——设备丢了、盘被拆了、报废流拍了，数据都不泄露；再往前一步，销毁密钥就等于销毁全部数据（crypto erase），这是加密送的一个额外红利，第 4、6 章会用到。

但加密只交付这一件事，另外三件事它不碰：完整性（数据被改没改）、真实性（数据是不是本系统写的）、可用性（系统还能不能正常启动）。把「不能」讲具体：XTS 这类模式不提供内建完整性，攻击者改一个密文块，解密后对应明文块会发生可预测的变化——不需要密钥，改得动密文，就间接改得动明文；重放攻击同理，把旧扇区的内容整体换回来，加密完全无感。所以「加密了」不等于「安全了」，差的是认证与版本绑定这两件事。

第 1 章图 3 把边界画成了左右两栏：左栏是加密买到的，右栏是加密买不到的。两栏之间没有灰色地带——「加密强度够高」不能兑换成「不怕篡改」，就像保险箱做得再厚，也不能阻止有人往箱子里塞一张假纸条。工程上的对应动作很直接：机密性用加密买，完整性用 MAC 或 AEAD 买，两笔账分开付。

1.4 密钥管理才是安全的瓶颈

AES 是公开标准，硬件引擎是成熟 IP，软件库随处可见——算法侧没有秘密可言，也没有门槛可言。真正的分水岭在密钥：怎么生成（要真随机，不能可预测）、存在哪（要抗读取，不能跟数据同盘）、谁能读（要最小暴露，不能明文过总线）、掉电后怎么办（要能恢复，也要能销毁）。这四个问题任何一个答错，前面用的算法再强，也是给数据上了一把「我知道钥匙在哪」的锁。

把经典失效模式列出来，会发现一个扎眼的事实：它们没有一个是算法被攻破的。学术界攻破 AES 的故事很精彩，工程界攻破存储加密的故事都很朴素——密钥文件就存在被加密的盘上。

六种失效的共同点：都不是算法被攻破，而是密钥管理失守。它们的代价也不对称——算法选错的代价是性能与合规麻烦，密钥管错的代价是整套防护归零。本文第 5~8 章逐条给出对策：生成与派生（第 5 章）、驻留与保护（第 6 章）、启动链与信任根（第 7 章）、RPMB 防回滚（第 8 章）；第 10 章再把其中三个做成完整案例，还原失效是怎么一层层发生的。

1.5 本文主线与读法

本文主线一句话：从威胁模型出发，讲透 XTS 扇区加密、SED / TCG Opal、密钥派生与驻留、信任根与安全启动链、RPMB 防回滚，最后收敛到「加密位置三选一」的系统设计决策。每一章只回答一个问题，章节顺序就是设计顺序——先想清楚防谁，再选算法，再定引擎，再管密钥，最后做系统决策。

读法上给两类读者一个捷径。做硬件的：第 1、2 章建立判据，第 3 章落到引擎与通路，第 6 章落到熔丝与安全区，这三章是原理图与 BOM 的直接输入。做系统与固件的：第 4 章决定用不用 SED，第 5、7、8 章决定密钥与启动链架构，第 9 章做最终收敛。两边都要读的是第 10、11 章——案例与合规章节是跨团队对话的共同语言。

2. 加密算法与工作模式基础

算法侧没有秘密：AES、SHA-2、XTS 全是公开标准，实现遍地都是。这一章要建立的是「选型口径」——什么场景用什么模式、认证为什么必须单独考虑、随机数与派生为什么是密钥质量的上游。所有参数以正式规范与器件 datasheet 为准，文中只讲机制与量级。

2.1 对称加密在存储中的角色

存储加密是典型的大量数据加解密场景：吞吐要求高、数据驻留久、加解密必须严格可逆。这三点决定了主角是对称分组加密——AES 是事实标准（FIPS 197），密钥长度 128 / 192 / 256 位三档，硬件引擎与软件指令集（AES-NI 一类）都很成熟。非对称算法（RSA、ECC）在存储里的角色不是加密数据，而是两件事：包装密钥（用公钥包一个对称密钥，方便分发）与签名验签（第 7 章启动链的主角）。

一个容易混淆的点：「用 AES」只解决了用哪个算法，没解决「怎么用」。同样的 AES，选错工作模式（比如 ECB）会泄露明文结构——相同的明文块永远加密成相同的密文块，等于给攻击者画了一张「哪些扇区内容相同」的地图。模式的选择就是下一节的主题，也是存储加密与通用通信加密分道扬镳的地方。

这张表的用法是「按角色找算法」：每个角色只对应一到两个成熟答案，选型空间比想象中小得多。真正的决策难点不在表里——在于这些角色在系统里怎么组合：谁给谁当上游、哪一级派生哪一把、哪一处只做校验不做认证。第 5 章讲派生链时会看到这张表怎么落成具体架构。

2.2 XTS 模式与扇区加密

存储加密的标准解法是 XTS-AES（IEEE Std 1619，NIST SP 800-38E 有对应说明）。它专门为「按扇区寻址的块设备」设计：每个扇区用一个 tweak（调整值）参与加密，tweak 的典型取法就是扇区号（LBA）。两个直接效果：同样的明文块，放在不同扇区，密文不同——否则攻击者一眼就能看出哪些扇区内容相同；改写一个扇区，只重加密该扇区——存储设备最频繁的操作就是改一个扇区，这个性质决定了 XTS 而不是别的模式统治了存储场景。

结构上 XTS 用两把密钥：一把加密数据，一把加密 tweak；XTS-AES-256 的口径是两把 256 位密钥（合计 512 位，以正式规范为准）。扇区内多个块之间，tweak 按块序号递推——所以同一个扇区里改一个块，不影响其他块；尾块不满整块时用密文挪用（ciphertext stealing）处理，扇区长度不变，不需要填充。「长度不变」这件事在存储里至关重要：填充会改变扇区映射，牵动 FTL 与文件系统的全部上层假设。

XTS 的软肋必须记住，第 10 章案例三会完整复盘它：它不提供完整性。密文被篡改，解密后明文发生可预测变化；旧扇区内容可被整体回放。这两个性质在「攻击者只能离线读」的模型下无所谓，但攻击者能写介质（换盘、改块、回退镜像）时就是致命伤——而「能写」恰恰是多数真实攻击的前提。

第 2 章图 4 上半是一条单扇区的数据流：明文进、调整值由扇区号生成、引擎出密文、按号落盘；下半三张卡是三个最常被问到的机制细节，底部三条性质是选型判据。注意第二条性质「改一个扇区只重加密该扇区」——它是 XTS 适配块设备的根本原因，通信场景常用的 CTR / GCM 模式在这里反而别扭（nonce 管理与标签存放都要额外设计）。

2.3 哈希与完整性校验

哈希把任意长数据压成定长摘要（SHA-256 一类，FIPS 180-4），用途是检测「变了没有」：位翻转、传输错误、存储磨损都能查出来。但无密钥哈希挡不住恶意替换——攻击者把数据和摘要一起换掉，校验照样过。要挡恶意，必须上带密钥的机制：HMAC（FIPS 198）或 CMAC（NIST SP 800-38B），没有密钥就生成不出有效标签。这就是「校验和」与「认证标签」的分界线，也是第 1 章图 3 右栏的技术落点。

存储系统里三个位置最需要认证。元数据：映射表、目录项、锁状态——被改会造成系统性错乱，而不是单点错误；密钥相关结构：包装后的密钥块、版本计数器——被改直接影响安全根基；配置与策略区：安全启动参数、锁定状态——被改等于改游戏规则。这三处只做「校验和」是不够的，要 MAC。

想同时拿到机密性与完整性，用认证加密（AEAD）：AES-GCM（NIST SP 800-38D）一类，一次算出密文和认证标签，解密先验证认证标签（tag），通过后再输出明文。代价是 GCM 类模式面向「整条消息」设计，直接用于随机改写的块设备要做工程适配——nonce 不能重复、标签要有地方存、部分改写要整条重算。这也是存储场景至今仍普遍选择 XTS、把认证单独做在元数据上的原因。

第 2 章图 5 把三条链路并排：最左防「东西坏了」，中间防「有人使坏」，最右一次交付两样。三者的选择判据不是性能，是攻击者模型——模型里有没有「恶意」二字。有，就必须带密钥；没有，无密钥哈希足够，还能省下密钥管理的全部成本。

2.4 随机数与密钥派生

密钥质量的上游是随机数。硬件随机数发生器（TRNG）以物理噪声为熵源（NIST SP 800-90 系给出口径），输出经健康测试与连续自检后才可用于生成密钥；确定性随机比特发生器（DRNG）在种子足够好的前提下扩展输出，适合批量需求。底线：禁止用时间戳、计数器、器件序列号一类可预测值直接当密钥或种子——这类「伪随机」在攻击者眼里等于明文。

派生（KDF）解决的是「一把根密钥不够用、又不能到处放」的矛盾：用密钥派生函数从根密钥算出多把子密钥，每把子密钥绑定一个用途标签（NIST SP 800-108 的计数器模式是典型口径，HKDF 一类亦常见）。派生的两个纪律：每次派生必须带上下文（用途、版本、域分隔标签），同一把根密钥永远不直接用于两个用途——否则一处泄露处处泄露，派生就白做了。

存储里典型的派生链：器件根密钥 → 卷级 KEK（包装密钥）→ 各卷 DEK（数据密钥）→ 必要时按域再派生。口令类场景（解锁 PIN 派生）用慢哈希（PBKDF2 一类，NIST SP 800-132），刻意放慢派生速度以对抗暴力尝试。派生链的每一级都要可重复、可验证——恢复密钥时靠的是同一套输入重建同一把子密钥，不是靠备份每一把，这正是派生相对「每把都存起来」的工程优势。

2.5 计算开销与选型准则

加密不是免费的：它吃引擎周期、加延迟、占内存。开销的三个来源：算法本身（AES 共 10~14 轮、每轮数个固定步骤，硬件化后单块延迟在纳秒量级）、模式结构（XTS 每块两次加密调用，GCM 额外算标签）、IO 路径（小 IO 场景下固定开销被放大）。工程上的判据从来不是「哪个算法快」，而是「加密吞吐是否高于介质吞吐一个量级」——只要引擎不成为瓶颈，加密对端到端的影响就可控；反过来，引擎再快，小 IO 的排队延迟也省不掉。

选型收敛成三条准则。其一，按安全目标选模式：只要机密性，XTS；要机密性加完整性且消息边界清晰，AEAD；只验不改，HMAC / CMAC。其二，按数据形态选粒度：随机改写的块设备优先扇区级，归档与备份流可整条消息 AEAD。其三，按实现选算法参数：有硬件引擎就吃硬件（XTS-AES-256），只有软件且平台无 AES 指令集时，评估 ChaCha 一类的替代（以实测为准，不写绝对数字）。

本章刻意不写任何绝对吞吐数字——那个数字取决于引擎规模、时钟频率、IO 深度与介质档位，写死就会误导。性能的账在第 3 章按数据通路逐段算：引擎吞吐多少、排队损失多少、端到端剩多少，一段一段对得上，结论才站得住。测试口径以实测为准，文中所有量级仅用于建立排序判断。

3. 硬件加密引擎与数据通路

算法选定之后，下一个问题是「引擎长什么样、插在哪里」。本章回答三个问题：主芯片的 AES 引擎有哪几种形态、它对密钥长度与模式的支持怎么核对、数据从主机内存到介质要走哪几段路——以及加密插进这条通路之后，带宽到底损失在哪。本章的口径是「先看通路再看性能」：通路决定了明文与密钥暴露在哪，性能只是通路算完之后的账。所有引擎能力以器件 datasheet 为准，文中只给核对方法与量级判断。

3.1 主芯片 AES 引擎的形态

主芯片里做 AES 的位置不止一种，工程上常见三种形态。其一是内联引擎（inline）：加密单元串在数据通路里，总线与存储控制器之间数据流过时顺路加解密，软件只配置、不搬运数据；其二是协处理器引擎（coprocessor）：加密单元是独立的运算部件，软件把数据送进去、取回来，灵活但要付搬运成本；其三是外置安全芯片：加密与密钥管理整体移出主芯片，做成独立器件，安全性可以做得更高，但要增加一路接口与一颗物料。

三种形态的分水岭在数据通路的位置，不在算法本身——三者用的都是同一套 AES 标准（FIPS 197）。内联引擎的明文不出主芯片，总线与介质上只有密文，这是第 1 章 L2 级威胁（探针、拆机）的直接对策；协处理器形态的数据要在主芯片内多走一段，通路设计要保证这段路上密钥不与数据并肩；外置芯片把边界推得更远，代价是主机与安全芯片之间的这条新总线成了新的暴露面，要看它自己有没有加密保护。

3.2 密钥长度与模式的硬件支持

引擎支持什么，是 datasheet 说了算，不是软件库说了算——软件层再全，引擎不认的模式一样跑不起来，最后会退化成纯软件实现，性能账完全重算。核对清单有六项：密钥长度档位（128 / 192 / 256 三档是否齐）、XTS 的双密钥结构是否原生支持、GCM / CMAC 一类认证模式是否在硬件里、支持的块与数据单元粒度、密钥装载接口的形态、标称吞吐的测试条件。

其中最容易被想当然的是 XTS 的双密钥结构：XTS 要数据密钥与 tweak 密钥两把独立密钥（第 2 章），有的引擎原生按双密钥接口设计，有的只给单密钥接口靠软件拼装——拼装不是不行，但要确认拼出来的密钥调度不破坏规范要求的独立性。同样要核对的是认证模式：引擎若不含 GCM / CMAC，元数据的 MAC 要么走软件、要么另配引擎，预算里要留这一笔。

3.3 引擎与总线的数据通路

把「加密在主芯片里」展开成通路，实际是三段并行的路。密钥通路：根密钥从熔丝或片内安全区出发，经专用接口装载进引擎，之后不可读；数据通路：写方向明文进引擎、密文出引擎，读方向相反，明文只存在于主机内存与引擎内部；密文通路：密文经总线控制器上总线、落介质，这一段是探针与拆机能直接接触的范围。三段路的责任划分，就是安全边界的划分——任何一段把明文或密钥漏到片外，整套加密就归零。

第 3 章图 6 的读法：上半是数据从主机内存到介质的单向链，下半三张卡是三条并行通路各自的纪律。最容易漏的是密钥通路——设计者对数据通路的明密文边界很敏感，对「密钥装载窗口」却常常没有概念：密钥从熔丝进入引擎的那一小段时间，它以明文形态存在于片内，装载完成后的回读必须被硬件拒绝。这段窗口有多长、有没有独立时钟与复位域、装载失败后的状态是什么，都以器件安全手册为准。

3.4 加密对读写带宽的影响

「加密掉多少性能」这个问题没法一句话回答，因为它混了两个量：引擎吞吐（加密单元每秒能处理多少数据）与端到端带宽（系统最终表现出来的读写速度）。正确的关系是：加密只是数据通路里新增的一段，端到端带宽由最慢的一段决定——加密段远快于介质段时，几乎无感；加密段接近介质段时，排队延迟开始放大，端到端明显劣化。

开销的来源按影响排序：其一，模式结构——XTS 每块要两次加密运算（数据一次、tweak 一次），开销天然是单次运算的一倍量级；其二，小 IO 的固定开销——每次请求都要付请求解析、密钥就绪、结果校验的固定成本，IO 越小占比越大；其三，排队与仲裁——引擎挂在共享总线上时，与其它主设备的仲裁损耗随负载上升；其四，软件回退——引擎不支持的模式落到软件路径，CPU 占用挤占业务。

第 3 章图 7 用两根横条把这件事画直白：上面一根是三段串行的原通路，下面一根是插进引擎段的四段通路。读图的关键不是比条子的长短，而是认出「最慢段」的位置——设计目标就是让最慢段始终是介质，让加密段缩到不构成瓶颈。图下三张卡是三种典型状态：充裕、吃紧、小 IO 放大。评估加密性能必须用小 IO 口径：顺序大块读人人好看，而真实业务里最多的是几 KB 的随机读写，固定开销恰恰在这个口径被放大。

3.5 引擎初始化与安全配置

引擎不是上电就能用的：它的初始化有一套顺序，而且顺序本身是安全要求——熵源自检没过就装载密钥，等于把密钥交给了不可信环境；密钥装载后才发现配置错，等于把密钥暴露在错误配置的通路里。工程上的标准顺序是六步：时钟与电源域就绪、随机数发生器自检、密钥装载（熔丝或安全区到引擎）、模式与密钥长度配置、已知答案自检、最后才使能加密通路。

每一步都有「做错的表现」：熵源自检被跳过或失败后强行继续，密钥的可预测性失去保障；密钥装载在配置之前完成，装载窗口被拉长，且错误配置可能把密钥引向不该去的通路；已知答案自检（用固定明密文对验证引擎运算正确）省掉之后，引擎硬件故障只能靠数据损坏来发现——那时已经是用户数据买单。六步顺序与各步的合格判据，以器件安全手册为准；本文给的是顺序逻辑，不是配置手册。

4. 自加密盘与 TCG Opal

主机侧做加密是一条路，把加密整个塞进盘里是另一条路——这就是自加密盘（SED，Self-Encrypting Drive）。本章讲清四件事：SED 的架构为什么让密钥管理天然省心、TCG Opal 怎么组织密钥层级、锁定与解锁的流程长什么样、掉电瞬间密钥的行为为什么是 SED 的立身之本。读完这一章，你应该能在「选不选 SED」这个问题上给出有依据的答案，并知道选型时核对什么。机制细节以 TCG 规范与盘 datasheet 为准。

4.1 SED 的架构与定位

SED 的定义很干脆：加密引擎与密钥管理都收进盘内，介质上永远只有密文。主机看到的仍然是一块普通块设备——读写命令照发、文件系统照装，加密对上完全透明；差异全在盘内：内联加密引擎坐在主机接口与闪存介质之间，所有数据过引擎，密文的边界就是引擎自身。主机唯一要「多做」的事是认证：提交凭据解锁，之后一切照旧。

这个架构的价值在密钥侧：数据加密密钥（MEK）从生成、使用到销毁全程不出盘——盘内自生成、盘内引擎里以明文存在、盘内销毁。第 1 章那张失效模式表里的「密钥与数据同介质」「密钥明文过总线」「硬编码密钥进固件」三条，在 SED 架构下被结构性消灭，而不是靠纪律防范。代价同样清楚：密钥策略受盘固件约束，产品能做什么不能做什么，要看盘给了哪些配置能力；这也是 TCG Opal 标准存在的意义——把「能做什么」标准化。

第 4 章图 8 把 SED 的架构与密钥层级画在了一幅图里：上半是四节点的数据链——主机只发命令与凭据，接口进引擎，介质只见密文；下半三张卡分别是两级密钥结构、明密文边界的位置、以及 crypto erase 的连带红利。注意「包装后的 MEK 也存在介质上」这件事不矛盾：介质上存的是被 KEK 包装（加密）后的 MEK，没有凭据解不开；明文 MEK 只在引擎内部存在，且掉电即消失——这正是 4.4 的主题。

4.2 Opal 的密钥层级

Opal 的密钥组织是两级结构，理解了这两级，SED 的一切行为都说得通。第一级是数据加密密钥（MEK）：真正加密数据的对称密钥，随机生成、只以明文形态存在于引擎内部、掉电即消失；介质上驻留的是它的包装形态。第二级是凭据与包装密钥（KEK）：主机认证用的口令或凭据派生出的密钥，作用是「解开包装后的 MEK」——认证通过，KEK 解包 MEK 送进引擎；认证不过，MEK 永远出不来。

两级结构换来的是「改凭据不动数据」：换口令只是换 KEK，MEK 不变、介质不用重写；反过来，「换 MEK 不动介质」就是 crypto erase——作废旧 MEK 换新的，全盘数据瞬间不可读，介质甚至不用擦。这个分离是 SED 架构里最漂亮的一笔，4.4 会把它与掉电行为放在一起看。另一个要点是锁定范围：Opal 允许全局范围与多个次级范围各自持有独立的密钥与锁定策略，范围怎么划、密钥怎么对应，是方案设计要拍板的事，不是盘自动替你决定的事。

4.3 锁定与解锁流程

SED 的锁定状态机可以压缩成五步：上电时内存无密钥、介质全密文；引擎随即进入初始锁定，以一个易失的随机 MEK 加密所有读写（此时盘「能写但读不回」）；主机提交凭据，盘内校验；校验通过，解包真正的 MEK 送进引擎；之后读写透明执行，介质永远只见密文。认证失败的路径同样重要：维持锁定、不解包——失败多少次触发什么策略（延迟、锁死），取决于盘的实现与配置。

第 4 章图 9 的主线是五步链，红色分支是认证失败路径。初始锁定那一步最值得琢磨：盘上电后立刻用一个内存里的随机数加密一切，这个设计的含义是——即使攻击者在盘解锁前拆机直读，得到的也是被「一次性密钥」加密的数据；而掉电后这个随机 MEK 消失，介质上那部分「锁定期间写入」的数据若没有对应的包装密钥记录，同样不可恢复。解锁行为绑定会话而非长期粘死，掉电即回到锁定态——这是 SED「掉电瞬间自动回到受保护状态」的机制根源，也是它比主机软件加密更适合流转场景的原因。

4.4 加密密钥的掉电行为

SED 的安全叙事有一半建立在掉电上，值得单独讲透。运行时：明文 MEK 在引擎与盘内易失内存中；包装后的 MEK 在介质保留区；数据在介质上是密文。掉电瞬间：易失内存清零，明文 MEK 消失——介质上只有密文与包装密钥，没有任何一条路径能直接得到明文。再次上电：回到初始锁定态，等凭据、等解锁。整个循环里，安全状态是「默认态」，解锁是「临时态」——这个方向性是 SED 与很多主机侧方案的本质区别，后者的常见默认态恰恰是「已解锁」。

掉电行为的另一面是数据完整性：掉电可能打断一次写入，介质上留下不完整的密文；SED 解决的是机密性，掉电一致性要靠介质自身的掉电保护与上层日志机制（与加密无关的常规设计）。把两件事混在一起——期待加密顺带解决掉电损坏——是常见误会，评审时要把「掉电后数据是否一致」与「掉电后数据是否保密」分开问。

4.5 SED 与主机加密的取舍

SED 不是处处优于主机加密的默认答案，取舍集中在三件事。其一，密钥主权的归属：SED 的密钥在盘内，主机侧拿不到明文 MEK——安全上更好，但也意味着密钥策略（轮换、托管、审计）都要通过盘的接口做，定制空间受限于固件；主机加密的密钥在自己手里，自由度高，但密钥管理的全部成本（第 5、6 章）都要自己担。其二，威胁模型的侧重：防拆盘、流转、报废，SED 天然占优；防主机侧运行时攻击（恶意软件在解锁后读明文），两者同样无解——解锁状态下的明文在主机内存里，这是所有静态加密共同的边界（第 1 章 1.3）。其三，供应链与合规：SED 把加密能力下沉到器件，合规叙事里「介质加密」一栏可以直接引用盘的认证；主机加密则要自己组织证据。