Add support for using RPMB as a secure storage device

[sergioprado]

Tested on Verdin iMX8MP, Verdin iMX8MM and Verdin AM62.

You can view the documentation changes more clearly here: https://github.com/sergioprado/meta-toradex-security/blob/optee-rpmb/docs/README-optee.md

[jsrc27]

LGTM

[rborn-tx]

This is a nice addition to the layer.

I have raised only a clarification question and a suggestion.

[rborn-tx]

@sergioprado For clarification, for Toradex modules I imagine the procedure for provisioning a device in factory would involve (at least for NXP modules):

• Installing a version of the OS built with TDX_OPTEE_FS_RPMB_MODE=factory with Toradex Easy Installer.
• Booting that version (twice) to fuse and close the device.
• Booting that version again to write the private key to the RPMB partition. Btw, would this writing happen automatically?
• With the device closed, install a new version of the OS now built with TDX_OPTEE_FS_RPMB_MODE=production.

Does this seem correct? If so, then I'd say customers would not be able to perform the last step easily since it would require either a signed version of Toradex Easy Installer (which we don't provide yet) or provisioning the device to the platform and performing a normal (possibly offline) update. Not that this is a major issue since everything on Secure Boot is a work in progress 🙂.

[sergioprado]

@rborn-tx Alright, let me break this down and clarify the process for RPMB key provisioning.

To write to the RPMB partition, an authentication key must first be enrolled (written to the partition). This is a one-time operation - once the key is programmed, it cannot be changed or erased. After enrollment, only devices with the correct key can perform authenticated read and write operations to the RPMB.

There are multiple ways to handle RPMB key provisioning. You could, for example:

• Program the key during eMMC manufacturing.
• Use a specialized firmware for that.
• Create a custom OS image designed to write the key.

The specific method doesn't matter as long as it fits your requirements. Ultimately, it's up to the user to choose an approach that works within their production environment.

Anyway, for secure storage to function effectively, OP-TEE needs access to the RPMB authentication key. It's impractical (and insecure) to hard-code this key in OP-TEE. Instead, OP-TEE can derive the key from the SoC's Hardware Unique Key (HUK), which is securely stored within the chip. When the CFG_RPMB_WRITE_KEY configuration is enabled, OP-TEE automatically derives and programs the key at startup.

A crucial point to understand is that you don't want to do this in production. OP-TEE itself does not have direct access to the eMMC driver and therefore cannot send commands to the RPMB partition. It delegates this task to the TEE supplicant running in the normal (REE) world. If this key-writing functionality is left enabled in a production environment, there is a risk that an attacker could exploit this "window of opportunity" to compromise the key by intercepting commands sent through the normal world.

To mitigate this risk, I introduced the concept of factory and production modes:

• Factory Mode: This mode allows OP-TEE to derive and program the RPMB key. It is intended to be used only during secure provisioning, such as in a factory setting.
• Production mode: In this mode, OP-TEE assumes the RPMB key has already been enrolled. The system can securely access the RPMB partition but cannot write or overwrite the key. This mode is designed for field devices to prevent key exposure.

However, this is just one possible solution. There are other approaches to RPMB key provisioning, which is why I emphasized in the documentation:

Be aware that alternative RPMB key provisioning methods exist, and the approach should align with your threat model.

To summarize, the complete process would be:

• Fuse keys and close the device.
• Write the RPMB key (derived from the HUK) in a secure provisioning environment (e.g., using the factory image).
• Transition the device to production mode with key provisioning disabled.

Does this make sense? Please let me know if you have further questions.

Thanks for reviewing!