Replay Protected Memory Block (RPMB)

• RPMB is a hardware-enforced memory partition that secures critical system data using an authenticated HMAC protocol and a monotonic counter.
• It protects essential elements like anti-rollback counters, bootloader state, and cryptographic keys to prevent unauthorized modifications.
• Recent EMFI attacks have exposed vulnerabilities in its HMAC verification process, highlighting the need for improved hardware and software defenses.

The Replay Protected Memory Block (RPMB) is a hardware-enforced, authenticated storage partition embedded in modern non-volatile memory devices such as eMMC, UFS, and NVMe. Its principal function is to provide a tamper-resistant area for storing critical system data—such as anti-rollback counters, bootloader state, and cryptographic public keys—to guarantee data authenticity and protect against rollback or unauthorized modification. Despite robust cryptographic design, recent research has demonstrated that RPMB authentication can be circumvented using precisely timed electromagnetic fault injection (EMFI), exposing fundamental vulnerabilities in some commercial implementations (Fukami et al., 27 Nov 2025).

1. RPMB Architecture and Purpose

RPMB resides as a distinct partition within eMMC, UFS, and NVMe storage, separate from standard user data partitions. Unauthenticated reads are permitted on RPMB, but all write operations mandate a valid message authentication code (MAC), computed using a secret key provisioned once at device manufacture. The RPMB region securely stores data requiring immutability under normal user privilege, including:

• Anti-rollback/version counters
• Bootloader lock state
• Public keys for secure boot or cryptographic protocols

Notably, even if the main storage area is reflashed or factory reset, RPMB contents and its internal monotonic counter persist, preventing downgrade attacks and enforcing continuity of security policies. Access to RPMB occurs through two JEDEC-defined classes of commands:

• Authenticated write sequence: CMD23 (set block count), followed by CMD25 (send 512-byte frame)
• Authenticated read sequence: CMD23 (set block count), followed by CMD18 (read frame)

Each 512-byte RPMB frame encapsulates 256 bytes of application data, a nonce (read) or reserved area (write), a 4-byte write counter, block and address fields, request/response type, and a 32-byte HMAC tag.

2. Authentication Protocol and Replay Protection

RPMB’s core authentication is realized through an HMAC-SHA256 scheme. Let $K$ represent the 256-bit device secret, $CTR$ the 32-bit write counter, $ADDR$ the 16-bit block index, $BCNT$ the 16-bit block count, and $D$ the user data payload. The host computes the MAC as:

$$\mathrm{MAC} = \mathsf{HMAC\_SHA256}(K,\; CTR \,\|\, ADDR \,\|\, BCNT \,\|\, D)$$

This MAC is included in the frame transmitted during a write request. The RPMB controller verifies that the write counter $CTR$ is strictly greater than $C_{\mathrm{stored}}$, its secure internal register value—rejecting any frame with a non-monotonic counter as a suspected replay. Only upon successful MAC verification is $C_{\mathrm{stored}}$ incremented and the data written; otherwise, an error code (such as authentication failure) is returned.

A typical authenticated write operation proceeds as follows:

1. Host issues a “read counter” command to retrieve $C_{\mathrm{stored}}$.
2. Host prepares data and increments counter $C = C_{\mathrm{stored}} + 1$.
3. Host computes MAC using the incremented counter.
4. Host sends the write request containing updated counter, address, data, and MAC.
5. Controller checks the counter and then the MAC.
6. On success: data is written, $C_{\mathrm{stored}}$ is updated, “Operation OK” is returned.
7. On failure: controller returns an error code.

This architecture provides strong replay protection and ensures the resilience of security policies under normal operation.

3. Electromagnetic Fault Injection (EMFI) Attack Methodology

The EMFI attack on RPMB targets the HMAC authentication logic at the hardware level. In the referenced paper, Samsung-manufactured eMMC controllers mounted on custom PCBs were subjected to precise EMFI using a NewAE ChipSHOUTER CW520, with a 1 mm coil precisely positioned over regions determined by X-ray and hotspot profiling. The attack platform comprised:

• A Raspberry Pi Pico issuing exact eMMC command sequences as trigger/control,
• Programmable delay for synchronizing the EM pulse with internal authentication routines,
• A Raspberry Pi 4 orchestrating the campaign,
• Oscilloscope monitoring on DAT0 and CLK lines, and EM probes for compute burst observation.

Key pulse parameters found effective were a voltage of 200 V and a pulse width of 100 ns, focused over the controller logic. The EMFI trigger was precisely timed to align with the HMAC check routine, at $t_{\mathrm{pulse}} = t_0 + \delta$, with $\delta$ ranging from $117.7 \mu s$ to $118.3 \mu s$ after the last bit on DAT0 for Target 1 (slightly shorter for Target 3). The attack methodology involved stepping across a grid over the silicon die, issuing command bursts, and categorizing responses as Normal, Crash, or Glitch, with up to 30% “Glitch” rates at optimal locations.

4. Attack Results: Authentication Bypass and Data Integrity

Reverse engineering revealed the key firmware routine responsible for HMAC verification:

uint32_t rpmb_check_hmac(void *hmac, uint32_t len) { if ((len+3)>>2 != 0) { for (i=0; i<(len+3)>>2; i++) if (*(uint32_t*)(hmac+4*i) != HW_HMAC_REG[0x60 +4*i]) return 0; } return 1; }

The EMFI allowed three classes of fault primitives in the authentication path:

1. Setting $len=0$, thus avoiding the HMAC comparison loop entirely
2. Corrupting the return-value register to non-zero before return,
3. Skipping the call instruction to the verification routine.

This manipulation caused the controller firmware to misinterpret the MAC as valid, permitting arbitrary data writes with intentional MAC mismatches and incrementing the monotonic counter. Both Target 1 and Target 3 were successfully compromised within ten attempts; Target 2 became unresponsive under test.

Importantly, only the RPMB region was affected, with no evidence of user or user-data corruption per full dd-style dumps and SHA-256 checksums. Nonetheless, some profiling runs did induce flash crashes or ECC errors, underscoring the collateral risks inherent to low-level fault injection.

5. Security Implications in Practical Systems

RPMB is widely deployed for safeguarding anti-rollback counters, bootloader state, and authentication keys—integral to devices such as smartphones, automotive ECUs (e.g., NXP i.MX, Trusty/TEE), and IoT gateways. The EMFI vulnerability permits attackers to reset rollback counters, unlock restricted bootloaders, or inject OS images with elevated privileges, undermining the chain of trust and paving the way for persistent, device-level compromise.

The low cost of commercial EMFI tools (significantly less than \$7,000) and the absence of package decapsulation requirements render this attack feasible for well-resourced adversaries, including criminal entities. This suggests a broader threat profile for RPMB-backed authentication in security-sensitive applications.

6. Proposed Countermeasures and Residual Challenges

Mitigation options encompass both software and hardware defenses:

• Software hardening:
  • Employ constant-time, full-length HMAC comparisons, prohibiting any early exit on mismatch conditions.
  • Return a non-trivial value (e.g., $0xA5C3B4D2$) for successful authentication, raising the bar for single-fault exploits.
  • Perform MAC verification at randomized offsets or with unpredictable timing, necessitating multiple fault attempts.
• Hardware countermeasures:
  • Integrate voltage and clock glitch monitors (e.g., brown-out and clock anomaly detectors) to force secure lockdown upon detecting irregularities.
  • Employ on-die EM/luminescence sensors to identify injection probes and trigger tamper interrupts.
  • Implement shielding, on-package mesh sensors, and redundant MAC engines or intra-controller control flow integrity features.

While RPMB’s theoretical security is robust, practical implementations are susceptible to hardware fault attacks such as EMFI. Comprehensive mitigations spanning both firmware and hardware are required to restore the integrity and security guarantees expected of RPMB in critical and high-value deployments (Fukami et al., 27 Nov 2025).