How to access Replay Protected Memory Block (RPMB) in eMMC?

Question

RPMB is a special partition in eMMC 4.5. Internet research suggests that it is used for saving keys and is the only special partition that responds to commands like READ, WRITE. etc. Can anyone explain to me how to use RPMB and how it can actually mitigate replay attacks?

Answer 1

RPMB can be used using mmc-utils.

It can withstand replay attacks by requiring a key to write to this region. The rpmb has a key that can be programmed once. Later, the host reads a counter value from the rpmb. It uses this counter value and the programmed key to generate a MAC. The device then checks the MAC given vs the MAC it calculated using the same key, and if it matches, write access is granted (reference, slide 4).

Answer 2

Typically, before any access (e.g. read or write) to RPMB partition, a RPMB authentication key must be programmed into RPMB controller in eMMC/UFS or NVMe device.

Note that this key must only be programmed once (at least according to the RPMB specification), and in the programming command/request, the RPMB key must be sent with cleartext, hence it normally should be provisioned in a safe environment (e.g. the factory manufacturing line, or the trusted firmware environment in the field after eMMC/UFS/NVMe is replaced with a new one).

After programming, this RPMB key should also be well protected, so typically RPMB usage should come with a TEE (trusted execution environment), like OP-TEE, Google Android Trusty or here for x86 Intel platform. However, such TEE environment normally doesn't have RPMB driver, but it has the RPMB key, and keeps this key safe inside the TEE (or secure world) for protection, while the RPMB driver itself should be in normal non-secure world like Linux (see Tomas Winkler's RPMB driver upstream).

Then, take writing access to RPMB as an example, TEE will use the RPMB key to sign the RPMB data, and send RPMB data together with the HMAC-SHA256 authentication signature (MAC) to Linux over IPC (between secure world TEE and non-secure world Linux), the Linux kernel driver is responsible for sending that piece of data (aka RPMB frame) together to RPMB physical device for authentication write.

As for REPLAY protection, it can be achieved like these for read/write access: Storage controller H/W built-in monotonic Write Counter is used for replay-protection on WRITE access, whenever an authenticated write is successful, the H/W write counter gets increased by 1, (initially it is zero), so any replayed write access will be rejected because the write counter can never be decreased. This can ensure the data freshness, however, once the counter reaches its max value (32-bit), any write access will be denied (it means that the RPMB will be a read-only storage);

While the Software generated Random Number (nonce) is used for replay-protection on READ access, because on read access, the software in TEE is responsible for authenticating the data and verifying its freshness, it must never use the same nonce or a poor random number generator to generate nonce to prevent data replay for read access.

For more details, you can see my talk in Linux Security Summit Europe 2018: Implement Android Tamper-Resistant Secure Storage and Secure it in Virtualization, in this slides, by the way, it also talks about one of RPMB virtualization solutions on top of hypervisor if you're interested in.

Hope this helps.