eMMC, UFS and RPMB: interface, boot and security boundaries

Managed flash describes who manages the NAND

NAND is the storage medium. With managed flash, the package also includes a controller that handles flash-management work. With raw NAND, more of that responsibility sits in the host. Micron also documents an intermediate case: on-die ECC handles error correction but leaves wear leveling and bad-block management to the host. The distinction is not simply "has ECC" versus "has no ECC". [2]

eMMC combines NAND and a controller using a parallel MMC interface. KIOXIA's brief explicitly includes logical-to-physical translation among the controller's tasks. [1] UFS devices likewise integrate flash and a controller, but use a different serial interface. [4] Neither name is a substitute for TLC or QLC: interface and bits per cell answer different questions.

Do not turn an interface label into a benchmark

The UFS architecture uses SCSI command conventions transported in UFS protocol information units, above UniPro and M-PHY. A shared command vocabulary does not make the physical connection SAS or PCIe/NVMe. The Linux overview contains historical UFS-version examples; this guide uses its architecture, not its speed list as a current product catalogue. [3]

Full-duplex support permits traffic in both directions. It does not establish how fast a particular application finishes. [4] Hesela's comparison rule: hold the workload and completion criterion constant, then record the actual host, device, negotiated mode, temperature and cache state. A link ceiling is not a substitute for such measurements.

Boot areas are not filesystem partitions or RPMB

Linux exposes MMC boot areas as /dev/mmcblkXboot0 and /dev/mmcblkXboot1, separately from the user-area block device. Writes are disabled by default because damaging their contents may prevent booting. The driver also distinguishes its forced read-only setting from a device-supported lock until the next power-on. [5]

Practical inference: copying files from the user filesystem does not establish that boot-area contents or authenticated state have been captured. A recovery plan must name its scope. This is not an instruction to unlock boot areas or export secrets. See backup verification and restore evidence.

Authentication, confidentiality and recovery are separate

RPMB is supported within eMMC and UFS. Its authenticated writes include a counter: after an accepted write advances it, replaying the old authenticated operation cannot supply the expected current counter. [6] This is a storage protocol mechanism, not proof that every application object has a correctly enforced rollback policy.

RPMB is not encryption. OP-TEE distinguishes its RPMB authentication key from the keys used to encrypt stored files. [7] The pinned Linux mmc-utils help permits an RPMB read without the optional key used to verify the response. Obtaining bytes and verifying their authenticity are different outcomes. [8]

OP-TEE also documents one-time eMMC key programming and platform-specific secret handling. Treat provisioning as a security lifecycle decision, not a reversible tuning switch. [7] Our architectural inference: trusted software must enforce rollback policy; authentication cannot recreate data after device loss. Secure storage still needs an explicitly designed recovery policy.

Read freshness and transaction atomicity need separate checks

The fTPM paper by Raj and colleagues (USENIX Security 2016, section 6.1.1) distinguishes write counters from read nonces. A read request supplies a nonce; the authenticated response binds that nonce to the returned data. The caller must verify both authentication and the expected nonce. A valid old response is not evidence of a fresh read. [9]

Section 9.1 describes another layer: shadow copies and a bit vector committed in one atomic write make a multi-write state update atomic. That software mechanism is separate from replay protection. This is the paper's design, not a claim that every RPMB implementation uses it, or a hardware test by Hesela. [9]

OP-TEE adds a practical configuration boundary: with both REE and RPMB filesystems enabled, a hash of REE filesystem state is kept in RPMB. That does not mean all file contents live there. Its platform caveats also require real device-specific key support; a feature flag alone does not establish secure provisioning. [7]

Ask for evidence at the correct layer

• Identify the package and controller revision, not just the advertised capacity.
• Separate NAND organization, host interface and measured workload behavior.
• Inventory user storage, boot areas and protected state as distinct recovery dependencies.
• For RPMB, document who provisions the key, verifies responses and enforces rollback policy, without recording secret key material.
• State whether a result demonstrates integrity, confidentiality, replay resistance, persistence or an actual restore.

This is an evidence checklist, not a procedure tested on hardware. Continue with flash translation layers, authenticated encryption and integrity and freshness boundaries.

Method and limitations

Editorial comparison of primary manufacturer documentation, Linux documentation and pinned mmc-utils source, cross-checked against OP-TEE's secure-storage design and the fTPM paper's read-freshness and atomic-update mechanisms (USENIX Security 2016). The decision table and inspection checklist are Hesela's synthesis, not measurements.

No device was benchmarked, reconfigured or subjected to power loss. No RPMB key was provisioned. This is not a JEDEC conformance review or a security audit of a specific platform. Host support, device revision and trusted-software integration must be checked separately.

Manufacturer briefs support the described mechanisms, not universal reliability claims. Version-specific optional features and provisioning procedures require the applicable device specification and platform documentation.

Primary sources

1. KIOXIA: e-MMC Managed Flash, product brief Rev. 1.1 (2022)
2. Micron: Choosing the right NAND, raw, managed and on-die ECC NAND
3. Linux kernel documentation: Universal Flash Storage, architecture overview
4. KIOXIA: UFS for consumer and industrial applications, integrated controller and serial interface
5. Linux kernel documentation: SD and MMC Device Partitions
6. KIOXIA: Introducing Replay Protected Memory Block within the e-MMC and UFS Specifications, November 2022, Rev. 1.1
7. OP-TEE documentation: Secure storage, RPMB device access and security considerations
8. Linux mmc-utils: RPMB read-block help, pinned commit c6692d5
9. Raj et al.: fTPM: A Software-Only Implementation of a TPM Chip, USENIX Security 2016, sections 6.1.1 and 9.1

Sources checked 17 October 2026. Explanations are paraphrased; implications are identified as editorial synthesis.