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