Re: KLMBG4GEUF
Jan Kiszka via OP-TEE <[email protected]> Wed, 6 May 2026 09:26:13 +0200
| Newsgroups | org.trustedfirmware.lists.op-tee |
|---|---|
| Message-ID | <[email protected]> |
On 03.05.26 11:27, İsa Coşkun wrote: > Hello, > > I am working on embedded automotive systems repair and investigating > behavior of Samsung eMMC (KLMBG4GEUF) in systems that appear to use OP-TEE > for secure storage. > > Real scenario: > > - Two identical devices (same hardware) > - One working, one not booting > - Full eMMC dump taken from working device: > - USER > - BOOT1 / BOOT2 > - EXT_CSD > - RPMB (reported readable, but content appears empty or not usable) > > Tests: > > - Writing full dump to another device → no boot > - Swapping eMMC between boards → both fail > - Writing only USER → no change > > From observations: > > - RPMB appears non-clonable > - Secure storage likely bound to hardware > - Boot seems dependent on this binding > > Questions: > > 1. In OP-TEE, is RPMB always tied to a hardware unique key (HUK)? > 2. Is it expected that RPMB content cannot be reused across identical > devices? > 3. Does OP-TEE enforce secure storage binding in a way that prevents > cloning? > 4. In case of damaged eMMC, is there any supported way to reinitialize > or recover secure storage? > > I am not trying to bypass security, but to understand the architectural > limitation in real repair scenarios. > > Any clarification would be highly appreciated. This binding of the RPMB to a unique key is indeed by design and therefore prevents swapping eMMCs between boards or replacing them - at least without having am official way to re-establish the relationship between SoC and eMMC (shared secret key) and re-deploy any data that needs to be stored on the RPMB. However, this on-boarding process has to happen in a secure environment and is therefore normally part of the production process of a board. The capability to write the secret key to the RPMB may not even be present in the OP-TEE version on your board or it is gated by a hardware fuse which was burned in the factory long ago. BTW, if you want to study the logic of the RPMB from a "hardware" POV, it's now fairly accurately emulated in recent QEMU. We also have a demo integration available in [1]. Jan [1] https://gitlab.com/cip-project/cip-core/isar-cip-core -- Siemens AG, Foundational Technologies Linux Expert Center