RPMB 密钥误编程 · 不可逆操作防护

编制日期 2026-09-21 ｜ 版本号 Rev 1.0

XTX 芯天下 · FAE 现场技术文档 ｜ eMMC RPMB（Replay Protected Memory Block）密钥一次性编程防护 ｜ 量产不可逆事故预防 ｜ 2026-09 版

一句话结论：RPMB key 编程是一次性、不可逆的高危操作—— 写错即报废该芯片。必须与普通量产烧录工程物理隔离、权限分离、写入前双 key 校验、 写后用主机侧 HMAC 读回验证、关键操作双人复核并留日志。误编程批次立即停线、隔离在制与库存， 不可尝试反复改写。

这份文档解决什么

解决的是eMMC RPMB 密钥在量产中被误编程、导致整批芯片不可逆报废这一类问题的预防与应急方法。 覆盖 RPMB 机制基础、key 一次性写入特性、8 大误编程场景、6 条防护 SOP、写后读回与装板验证、 双人复核与 RMA 处理。全文按「机制 → 场景 → 防护 → 验证 → 应急 → 速查」组织， 第 9 章是可直接翻查的速查表，第 10 章与附录是可落地的防复发清单。

怎么用这份文档

1. 先确认是不是 RPMB key 问题：主机侧读 RPMB 返回 MAC 校验失败、或报 key 不匹配， 且器件已被编程过 key，先停线，不要反复试写——试写不会改变已锁死的 key。
2. 对照第 5 章 8 大场景定类：是测试 key 残留、混 key、批次错乱、还是算法回退？ 定类决定下一步是隔离、补 key 还是报废。
3. 用第 6 章 SOP 做根因复盘：key 文件是否物理隔离、写入前是否双 key 校验、 写后是否读回验证、是否双人复核留痕。漏哪条就补哪条。
4. 用第 7 章验证闭环：任何 RPMB 编程动作的最终判定，以「装板跑通主机侧 RPMB 读 / 安全服务」为准， 不是烧录器显示成功。
5. 用第 9 章速查表翻症状：看到什么现象 → 根因在哪一类 → 立即处置是什么。

1. 问题本质：RPMB 机制与 key 一次性写入

RPMB 误编程之所以被单列成一类高危问题，根本原因在于它的不可逆性。 普通烧录写错了可以重擦重写，RPMB key 写错了没有任何回退手段—— 器件不会因为你「再写一次」就改正来。本章先把机制讲清楚：RPMB 是什么、key 为什么不可逆、 以及「写错」在主机侧到底表现成什么，后面所有防护都建立在这三条认知上。

1.1 RPMB 是什么

RPMB（Replay Protected Memory Block，防重放内存块）是 eMMC 内部的一块安全分区， 用于存放需要防重放攻击的数据（典型如安全启动的度量值、防回滚计数器、设备唯一密钥等）。 它的保护与普通用户分区（User Area）完全不同：普通分区谁都能读能写，RPMB 的写入必须经过签名验证。

1.2 RPMB 的读写都靠 HMAC 签名

RPMB 的写入帧里必须携带一段 HMAC-SHA256 消息认证码（MAC）。 eMMC 内部保存着唯一的 256 bit key，收到写帧后用同一个 key 重新计算 MAC 并比对：

• 验签通过：说明请求来自持有正确 key 的主机，才允许写入。
• 验签失败：拒绝写入，数据不被接受。
• 读出：eMMC 返回数据的同时附带 MAC，主机用同一 key 验签即可判断数据真伪， 防止中间人重放旧数据。

这就意味着：能读写 RPMB 的前提是「主机与器件持有同一个正确的 key」。 一旦器件里被写入了错误的 key，主机侧拿正确 key 算出的 MAC 永远对不上——这就是「写错即报废」的来源。

1.3 key 为什么不可逆（重点）

这是全文最关键的一条事实，务必反复对齐：

1.4 「写错」在主机侧表现成什么

结合 1.2 可知，key 写错后主机侧的典型表现：

• 读 RPMB 时 MAC 校验失败：主机用正确 key 算出的 MAC 与器件返回的 MAC 不一致。
• 安全服务 / 安全启动失败：依赖 RPMB 的 boot 校验、防回滚计数器、密钥存储不可用。
• 写入被静默拒绝：带正确 key MAC 的写帧被器件以「验签失败」拒绝，看似「写不进去」。
• 烧录器显示「成功」但主机侧不可用：烧录器只验证了「写入动作完成」，没验证「主机侧能不能读」——这正是必须装板实跑的原因（第 7 章）。

2. 防护总览：流程与误编程场景

RPMB 误编程的防护不是靠某一个「神操作」，而是靠把不可逆操作拆成多道闸门， 任何一道漏掉都会把风险放大。本章先给一张总流程图和一张场景汇总图， 建立「先防前置、再验结果、最后留痕」的整体认知，后面第 3~8 章对每一道闸门逐一细化。

2.1 防护总流程

把一次 RPMB key 编程看作一条单向不可逆的产线：进入「写 key」这一步之后， 结果就定格了。因此所有能拦住错误的动作，都必须发生在写 key 之前或刚写完的瞬间。

2.2 误编程 8 大典型场景

以下 8 类是现场统计中最常出现的误编程来源。它们的共同特征在图 3 底部一句话里： key 在被写入器件之前就已经错了——所以防护重心永远在前置，不在事后。

2.3 防护维度地图

把「防护」按维度拆开，能更清楚地看到每一类场景该被哪一道闸门拦住：

3. 第 1 类：key 一次性写入的不可逆特性

第 1 类问题不是「某一个环节出错」，而是「出错这件事本身无法被修正」。 理解不可逆性是建立全部防护心态的前提：普通烧录写错了可以擦、可以重来， RPMB key 写错了没有任何软件或硬件手段能把器件救回可用状态。本章把「不可逆」拆成可感知的三层含义。

3.1 第一层：写操作本身是一次性的

RPMB key 区是 OTP 设计。eMMC 内部只允许对 key 区执行一次成功编程； 第一次写完后该区域即被锁定，后续任何写请求都会被器件以「已编程」拒绝。 这意味着不存在「覆盖写」这条路——你看到的「再写一次」，在器件侧只是又一次被拒绝。

3.2 第二层：擦除与复位都清不掉

很多人第一反应是「那我全片擦除 / 恢复出厂 / 重新上电总行了吧」。答案是不行：

• 全片擦除（erase / secure erase）：只清用户分区与增强属性，不动 RPMB key 区。
• 复位 / 重新上电：key 保存在非易失存储，掉电不丢。
• 重新量产初始化：标准流程里没有「清 RPMB key」这一步，原厂也不提供。

所以「写错 → 想擦掉重来」是一条死路。图 4 右侧的红色路径没有任何回退箭头，正是要强调这一点。

3.3 第三层：唯一恢复路径是报废

当 key 被错误写入，器件对该客户的主机侧而言等价于报废： 应用层读不到 RPMB、依赖 RPMB 的安全服务不可用、产品无法出厂或启动。 唯一的处置是物理报废该芯片并计入物料损耗，同时评估客户侧损失（第 8 章）。

3.4 立即动作与根治动作

4. 第 2 类：HMAC 签名验证机制

防护要有效，得先懂「为什么防护能拦住错误」。RPMB 的全部安全性建立在 HMAC-SHA256 签名验证之上：只有持有正确 key 的一方，才能算出正确的 MAC。 本章把 MAC 的输入、计算过程与判据讲清，后面「写前双 key 校验」和「写后读回验证」都是这一机制的工程化应用。

4.1 MAC 的输入必须两侧一致

HMAC-SHA256 的 MAC 是由key + 数据 + nonce + 写计数器共同算出的。 主机侧要验证通过，这四个输入必须和器件侧完全一致：

• key：256 bit，每设备唯一（理想情况下），OTP 写入后不可改。
• 数据：本次要写或读的内容。
• nonce：随机数，防止重放旧帧。
• 写计数器（write counter）：RPMB 用于防重放的核心，每次写后自增。

其中key 不一致是误编程的根本来源——只要主机与器件持有的 key 不同，MAC 必然算错。

4.2 写入验证：验签通过才写

写 RPMB 时，主机用 key 算好 MAC，把「数据 + MAC」作为写帧发给 eMMC。 器件用内部保存的同一 key 重新计算 MAC 并比对：

• 一致：说明请求来自持有正确 key 的主机，允许写入，写计数器自增。
• 不一致：拒绝写入，数据不被接受，原内容不变。

这带来一个重要结论：写错 key 后，主机用正确 key 发的「改写」请求会被器件拒绝—— 又一次印证第 3 章的「不可覆盖」。

4.3 读出验证：返回 data + MAC

读 RPMB 时，eMMC 返回「数据 + 该数据对应的 MAC」。主机用 key 验签： MAC 通过 = 数据真实未被篡改；MAC 失败 = 数据不可信或 key 不对。 这正是「写后读回验证」（第 7 章）能确认 key 是否正确的原理。

4.4 key 派生算法必须版本一致

实际量产中，主机侧往往不是直接持有 256 bit 器件 key，而是持有母 key， 按一份派生算法算出每颗器件的 key（可能结合器件唯一标识）。 这份算法的版本必须与烧录器侧完全一致：

• 算法回退（场景 8）→ 两端算出的 key 不同 → MAC 永远失败。
• 算法升级未同步 → 新母 key + 旧派生 = 错 key，且这种错是「静默」的，烧录器显示成功。