RPMB 可以使用mmc-utils.

它可以通过要求写入该区域的密钥来抵御重放攻击。rpmb 有一个可以编程一次的键。稍后，主机从 rpmb 读取计数器值。它使用此计数器值和编程的密钥来生成 MAC。然后，设备检查给定的 MAC 与使用相同密钥计算的 MAC，如果匹配，则授予写访问权限（参考，幻灯片 4）。

通常，在对 RPMB 分区进行任何访问（例如读取或写入）之前，必须将 RPMB 身份验证密钥编程到 eMMC/UFS 或 NVMe 设备中的 RPMB 控制器中。

请注意，此密钥只能编程一次（至少根据 RPMB 规范），并且在编程命令/请求中，RPMB 密钥必须以明文形式发送，因此通常应在安全环境（例如工厂生产线，或者eMMC/UFS/NVMe更换后的现场可信固件环境）。

编程之后，这个 RPMB 密钥也应该得到很好的保护，所以通常 RPMB 的使用应该附带一个 TEE（可信执行环境），如OP-TEE、Google Android Trusty或这里用于 x86 Intel 平台。但是，这种 TEE 环境通常没有 RPMB 驱动程序，但它有 RPMB 密钥，并将此密钥安全地保存在 TEE（或安全世界）中以进行保护，而 RPMB 驱动程序本身应该处于正常的非安全世界中，如Linux（参见 Tomas Winkler 的RPMB 驱动程序上游）。

然后，以对RPMB的写访问为例，TEE将使用RPMB密钥对RPMB数据进行签名，并将RPMB数据连同HMAC-SHA256认证签名（MAC）通过IPC（在安全世界TEE和非安全世界之间）发送给Linux安全世界 Linux），Linux 内核驱动程序负责将那段数据（又名 RPMB 帧）一起发送到 RPMB 物理设备以进行身份​​验证写入。

至于 REPLAY 保护，对于读/写访问可以这样实现： Storage controller H/W built-in monotonic Write Counter 用于 WRITE access 的 replay-protection，只要经过验证的写入成功，H/W write counter 增加 1（最初为零），因此任何重放的写访问都将被拒绝，因为写计数器永远不会减少。这样可以保证数据的新鲜度，但是一旦计数器达到最大值（32位），任何写访问都将被拒绝（这意味着RPMB将是一个只读存储）；

虽然软件生成的随机数 (nonce) 用于 READ 访问时的重放保护，但由于在读取访问时，TEE 中的软件负责验证数据并验证其新鲜度，它绝不能使用相同的 nonce 或差的随机数数字生成器生成随机数以防止数据重放以进行读取访问。

有关更多详细信息，您可以查看我在 Linux Security Summit Europe 2018 中的演讲： 实现 Android 防篡改安全存储并在虚拟化中保护它，在这张幻灯片中，顺便说一下，它还谈到了基于虚拟机管理程序的 RPMB 虚拟化解决方案之一如果你有兴趣。

希望这可以帮助。