RPMB 全面解析：eMMC 防回滚安全区与 OP-TEE/Jetson 实战

📺B站视频讲解（Bilibili）：博主个人介绍

📘《Yocto项目实战教程》京东购买链接：Yocto项目实战教程

📘加博主微信，进技术交流群：jerrydev

RPMB 全面解析：eMMC 防回滚安全区与 OP-TEE/Jetson 实战

简介（先把结论讲透）

如果你在做 Secure Boot、磁盘加密、OP-TEE 安全存储或 OTA 防回滚，最终几乎都会遇到一个问题：

“关键状态必须可更新，但绝不能被回滚或伪造。”

磁盘加密擅长解决“离线窃取看不懂内容”（保密性），但它并不天然解决“状态回滚”（Replay/Rollback）。RPMB（Replay Protected Memory Block）正是为此而生：它是eMMC 内置的一块特殊安全存储区域，通过认证写入 + 单调递增写计数器的组合，提供硬件级别的防篡改与防回放能力。更重要的是，在 Jetson 平台上，RPMB 常与OP-TEE 安全存储、EKB/HUK 派生链紧密关联，是把“安全设计”落到“可验证工程闭环”的关键一环。

本文将从 0 到 1 讲清楚：

RPMB 到底是什么（以及它不是什么）
它解决的核心威胁模型
它与 OP-TEE、Jetson 的密钥链路如何衔接
你在工程里真正会用到的场景与实践方式
可复用的代码结构、调试方法与常见故障排查

RPMB 是什么：为什么它不是“普通分区”
RPMB 解决的核心问题：篡改与回放
关键机制：RPMB Key、MAC、Nonce、Write Counter
访问路径：为什么 OP-TEE 也要“借道 Linux”
RPMB 与安全存储、磁盘加密、Secure Boot 的边界
Jetson 平台：OEM_K1、ECID、RPMB Key、HUK/SSK/TSK 的分工
典型场景：OTA 防回滚、授权状态、密钥封装、计数器
实战一：Linux 上验证与操作 RPMB（mmc-utils）
实战二：OP-TEE 持久化对象落到 RPMB（TA 代码 + 后端切换）
工程设计建议：密钥生命周期、写入频率、迁移策略
常见问题与排查清单
总结

1. RPMB 是什么：为什么它不是“普通分区”

RPMB（Replay Protected Memory Block）是 eMMC 规范定义的一种能力：

它位于 eMMC 芯片内部，属于 eMMC 的一个特殊存储区域。
它不能像普通分区一样被 mount，也不是你在lsblk里看到的mmcblk0p1/mmcblk0p2那种“用户数据分区”。
对 RPMB 的读写必须走RPMB 专用协议（请求帧/响应帧），而不是普通块读写。

你可以把它理解为：

“eMMC 内置的、小容量、可认证、防回放的安全区。”

它的容量通常不大（常见为若干 MB 级别），设计目标从来不是存大量数据，而是存关键、小量、必须防回滚的状态。

2. RPMB 解决的核心问题：篡改与回放

2.1 两类常见攻击

在没有 RPMB 的情况下，如果你的关键状态保存在普通文件系统（甚至普通加密文件系统）里，攻击者可以：

离线篡改：拿到存储介质镜像，修改状态文件，然后写回。
回滚/回放：把“旧版本的状态”恢复回来，例如：
- 回滚授权状态（已过期 → 恢复为未过期）
- 回滚防回滚计数器（版本 10 → 版本 3）
- 回滚密钥轮换状态（新 key 生效 → 恢复旧 key）

2.2 为什么“加密”不等于“防回滚”

磁盘加密（dm-crypt/LUKS）能保证离线看不懂内容，但它并不天然保证“你读到的就是最新版本”。攻击者可以把旧的加密块整体回放回来——从加密角度看它仍然是合法密文。

RPMB 的关键价值在于：

写入必须认证，并且必须使用正确的写计数器，计数器单调递增，从而让旧数据回放失效。

3. 关键机制：RPMB Key、MAC、Nonce、Write Counter

RPMB 机制通常可以概括为“四件套”：

3.1 RPMB Key（认证密钥）

这是 RPMB 访问的核心。eMMC 内部存有一把 RPMB Key。
典型特性：一次性写入（OTP）、不可读出。
任何写操作都需要用这把 key 生成认证信息，否则 eMMC 会拒绝。

3.2 MAC（消息认证码）

写请求携带 MAC，eMMC 用内部 RPMB Key 验证。
读响应也可以携带 MAC，主机端验证响应未被伪造。

3.3 Nonce（挑战值）

主要用于读流程：主机发 nonce，设备响应时回带 nonce 并签 MAC。
这样可以避免“把旧响应原封不动回放”的攻击。

3.4 Write Counter（单调递增写计数器）

eMMC 内部维护一个 write counter（只增不减）。
写请求必须携带“当前 counter 值”，且验证通过后写成功，counter 自动加 1。
因此旧 counter 的写请求会失效，旧数据也难以回放成“最新状态”。

3.5 一句话记忆

Key 负责认证
Counter 负责防回滚
Nonce 负责读响应防回放

4. 访问路径：为什么 OP-TEE 也要“借道 Linux”

这是很多人第一次接触 RPMB 的困惑点：

既然 RPMB 用于 TEE 安全存储，为什么访问时还要经过 normal world？

原因在于：

TEE（例如 OP-TEE）通常不直接驱动 eMMC 控制器。
设备访问由 normal world 的驱动完成，TEE 通过 RPC 请求 normal world 代为执行。

典型路径：

TA (secure world) -> OP-TEE Core -> RPC -> tee-supplicant (normal world user space) -> /dev/mmcblkXrpmb + ioctl -> MMC 驱动 -> eMMC RPMB 区域

安全性靠什么保证？

normal world 负责“搬运请求与响应”，但关键的认证 key 不应在 normal world 以明文可得。
即使 normal world 试图伪造写入，也无法生成正确 MAC；试图回放旧写入，会卡在 counter。

5. RPMB 与安全存储、磁盘加密、Secure Boot 的边界

先把边界讲清楚，后面才不会“概念互相打架”。

5.1 RPMB 不是磁盘加密

磁盘加密：面向“大容量数据的保密性”。
RPMB：面向“小容量关键状态的认证与防回滚”。

5.2 RPMB 也不等价于 OP-TEE 安全存储

OP-TEE 安全存储（Secure Storage）是“上层能力”，RPMB 只是“可选后端之一”。

REE FS：数据落在普通文件系统，但由 OP-TEE 做加密/认证。
RPMB FS：数据落在 RPMB 区域，额外获得硬件级防回滚语义。

5.3 Secure Boot 解决的是“启动链”可信

Secure Boot 关注的是：BootROM/MB1/MB2/UEFI/Kernel/DTB 是否被授权。
RPMB 更常用于：

存放防回滚版本号
存放可更新的安全状态
存放 TEE 的持久化对象

6. Jetson 平台：OEM_K1、ECID、RPMB Key、HUK/SSK/TSK 的分工

在 Jetson（尤其是 Orin）体系里，经常会看到多个“看似类似”的 key：EKB_RK、HUK、RPMB key、OEM_K1 等。它们并非同一把钥匙，而是分工明确。

6.1 先给出一张分工图（建议你直接记住）

(1) TEE 安全存储密钥体系（用于加密 TA 数据） EKB_RK -> HUK -> SSK -> TSK -> FEK -> 加密/认证 secure storage 内容 (2) RPMB 硬件认证密钥（用于与 eMMC RPMB 协议对话） OEM_K1 + ECID + 固定源 -> 派生/生成 RPMB Key -> eMMC 验证 MAC + counter

6.2 为什么会同时出现 ECID

ECID 是“设备唯一标识”类信息，常被用作派生输入（context/iv），用于实现“每设备不同”。

用在 HUK 派生：让 TEE 的根密钥链与设备绑定。
用在 RPMB key 派生：让每台设备的 RPMB key 不同，避免跨设备复制。

6.3 固定 label 的意义

当你用 KDF（例如 NIST SP 800-108）派生多把不同用途的 key，固定 label 用于“域隔离”：

同一根 key，不同 label 派生得到的子 key 不会“撞域”。
可以避免误用，例如：把本用于认证的 key 拿去加密，或反过来。

7. 典型场景：你真正会用到 RPMB 的地方

下面这些场景几乎覆盖了“为什么工程里要引入 RPMB”。

场景 1：OTA 防回滚（最典型）

目标：设备升级到新版本后，攻击者不能把系统回滚到旧版本。

设计要点：

RPMB 中保存rollback_index（或最小允许版本号）。
每次升级成功，更新rollback_index。
启动时由 bootloader/TEE/安全服务检查，拒绝低版本。

为什么必须用 RPMB：

攻击者回放旧的rollback_index会被 counter 机制阻断。

场景 2：授权状态与计费/次数

目标：授权次数/订阅有效期不能被离线改回。

把授权状态（或关键计数器）放在 RPMB 或由 OP-TEE secure storage 落 RPMB。

场景 3：密钥封装与密钥轮换状态

目标：密钥轮换后不能回到旧 key。

把 key version、轮换序列号写入 RPMB。

场景 4：OP-TEE TA 的持久化对象

目标：TA 的持久化数据不仅要加密，还要防回滚。

开启 OP-TEE RPMB FS 后端，TA 不用改代码。

8. 实战一：Linux 上验证与操作 RPMB（mmc-utils）

目标：把 RPMB 变成“可观测、可验证”的对象，而不是抽象概念。

8.1 确认 rpmb 设备节点

在不同内核/平台上常见类似：

/dev/mmcblk0rpmb
/dev/mmcblk1rpmb

可以用：

ls -l /dev/mmcblk*rpmb
dmesg | grep -i rpmb

8.2 读取 write counter（最安全的探测）

mmc rpmb read-counter /dev/mmcblk0rpmb

意义：

如果读 counter 都失败，说明设备节点/驱动链路尚未通。
成功则说明基本通信链路可用。

8.3 读写块（注意：写会改变 counter）

读取：

mmc rpmb read-block /dev/mmcblk0rpmb01out.bin

写入（需要 key file）：

ddif=/dev/zeroof=data256.binbs=256count=1printf"HELLO_RPMB"|ddof=data256.binbs=1conv=notrunc mmc rpmb write-block /dev/mmcblk0rpmb0data256.bin rpmb_key.bin

验证 counter 是否递增：

mmc rpmb read-counter /dev/mmcblk0rpmb

8.4 重要提醒：write-key 基本是不可逆操作

生产流程才会执行write-key，因为写错就会导致后续认证全部失败。

9. 实战二：OP-TEE 持久化对象落到 RPMB（TA 代码 + 后端切换）

9.1 核心结论

TA 代码不需要“知道”后端是 REE FS 还是 RPMB FS。

你只要调用 GP API 创建/打开/读写持久化对象：

后端选 REE FS：对象落在普通文件系统（但内容被 OP-TEE 加密/认证封装）。
后端选 RPMB FS：对象落在 RPMB，获得认证 + 防回滚能力。

9.2 TA 代码示例（可直接复用）

写入：

#include<tee_internal_api.h>#include<tee_internal_api_extensions.h>staticconstuint32_tOBJ_ID=0x11223344;TEE_Resultwrite_state(constvoid*buf,uint32_tlen){TEE_ObjectHandle h=TEE_HANDLE_NULL;uint32_tflags=TEE_DATA_FLAG_ACCESS_WRITE|TEE_DATA_FLAG_ACCESS_READ|TEE_DATA_FLAG_OVERWRITE;TEE_Result res=TEE_CreatePersistentObject(TEE_STORAGE_PRIVATE,&OBJ_ID,sizeof(OBJ_ID),flags,TEE_HANDLE_NULL,NULL,0,&h);if(res!=TEE_SUCCESS)returnres;res=TEE_WriteObjectData(h,buf,len);TEE_CloseObject(h);returnres;}

读取：

TEE_Resultread_state(void*buf,uint32_tbuf_len,uint32_t*out_len){TEE_ObjectHandle h=TEE_HANDLE_NULL;uint32_tflags=TEE_DATA_FLAG_ACCESS_READ;TEE_Result res=TEE_OpenPersistentObject(TEE_STORAGE_PRIVATE,&OBJ_ID,sizeof(OBJ_ID),flags,&h);if(res!=TEE_SUCCESS)returnres;res=TEE_ReadObjectData(h,buf,buf_len,out_len);TEE_CloseObject(h);returnres;}