什么是EMMC的RPMB保护

少于 1 分钟阅读次阅读

RPMB (Replay Protected Memory Block，重放保护内存块) 是 eMMC、UFS 和 NVMe 等存储设备中的一个具有安全访问控制的隐藏硬件分区。

顾名思义，RPMB 保护的核心目的不仅是防止未授权的数据读写，更重要的是防御“重放攻击”（Replay Attack）。在典型的嵌入式 Linux 和底层硬件架构中，它通常被用作系统中最受信任的非易失性存储区域。

一、 RPMB 的核心工作原理

RPMB 的安全性建立在共享密钥（Authentication Key）和单向递增计数器（Write Counter）的基础之上。

密钥注入（Key Provisioning）： 在设备出厂或首次安全启动时，Host（如 SoC 内部的 Secure Boot ROM 或 TEE 环境）会生成一个 256-bit 的安全密钥，并将其一次性写入 RPMB 分区。这个密钥一旦写入，在存储芯片的生命周期内不可更改，且无法通过任何物理或软件接口被直接读出。
数据鉴权（Authentication）： 此后，Host 对 RPMB 进行的每一次读写操作，都必须附带基于该共享密钥计算出的 HMAC SHA-256 签名。eMMC 内部的控制器会校验这个签名，签名不匹配则拒绝执行。
防重放机制（Anti-Replay）： RPMB 内部维护着一个只增不减的写入计数器（Write Counter）。每次成功的写入操作都会使计数器加 1。Host 在发起写入请求时，必须包含当前的计数器值并将其纳入 HMAC 计算。如果黑客截获了过去某次合法的写入数据包并尝试重新发送（即重放攻击），由于 eMMC 内部的计数器已经增加，黑客发送的旧计数器值无法通过校验，写入将被硬件直接拒绝。

通过下表可以直观对比普通分区与 RPMB 分区的访问差异：

维度	普通 eMMC/UFS 分区 (User Area)	RPMB 分区
访问权限	操作系统 (如 Linux Kernel) 直接挂载和读写。	仅限受信任的执行环境 (如 OP-TEE、Secure Boot ROM) 访问。
数据加密	通常不加密，或依赖软件层面的文件系统加密。	传输命令带有 HMAC 签名校验（注：RPMB 协议本身只做鉴权和防重放，数据本身的加密通常由 SoC 的 TEE 在写入前完成）。
防御重放	无。黑客可以通过烧录器刷入旧版本固件。	有。强依赖内部 Write Counter 校验。
通信开销	低。直接发送 CMD 读写块。	高。需要多次发送 CMD（如 eMMC 的 CMD23, CMD25, CMD18）来传递签名、计数器和结果寄存器。

在基于 ARM 架构的 SoC 设计和底层固件（如 U-Boot、TrustZone 体系）中，RPMB 保护扮演着极其关键的角色：

防回滚保护（Anti-Rollback / ARB）： 安全启动（Secure Boot）体系中，为了防止黑客将系统降级到存在漏洞的旧版本（例如烧录带有已知内核漏洞的旧版本 Ubuntu/Android 镜像），系统会将当前的“最低允许版本号”存储在 RPMB 中。每次 U-Boot 或 Boot ROM 启动时都会校验当前镜像版本是否低于 RPMB 中记录的值。
TEE 安全存储（Secure Storage）： 在 TrustZone/OP-TEE 架构中，操作系统的指纹模板、面部识别特征、支付安全证书（如微信/支付宝 SOTER 密钥）等敏感数据，其加密后的密文会存放在普通文件系统中，而解密这些数据的“主密钥”或哈希值则被锁定在 RPMB 中。
DRM 与设备强绑定： 例如 Widevine L1 视频硬件解码所需的设备唯一证书、MAC 地址、或者客户定制的强绑定 SN 码，为了防止被克隆或篡改，通常在产线阶段被固化入 RPMB。

如果在底层开发或驱动调试中遇到 RPMB 相关问题，通常表现为：

系统在 TEE 阶段 Kernel Panic 或死机： 往往是因为更换了全新的 eMMC 芯片，但没有重新执行 RPMB Key 注入流程，导致 OP-TEE 无法挂载安全文件系统。
U-Boot 阶段读写超时： RPMB 的交互时序非常严格，频繁的读写可能会受阻于 eMMC 的内部调度。在驱动设计时，状态机的流转（发送鉴权请求 -> 读取 Result Register -> 校验 MAC）需要严格按照 JEDEC 规范实现。