OEMiRoT OEMuRoT for STM32H7S

Revision as of 14:33, 2 October 2023 by Registered User

OEMiRoT stands for Original Equipment Manufacturer immutable Root of Trust. The users can develop OEMiRoT on all the STM32H5xx devices.

1. Introduction

This wiki article describes the OEMiRoT process developed for STM32H5 MCUs. For practical examples, refer to OEMiROT STM32H5 How to Introduction, which introduces the many steps to use OEMiRoT.

2. OEMiRoT services

1) The secure boot (Root of Trust services):
It is an immutable code always executed after a system reset. It activates STM32 runtime protections and verifies the authenticity and integrity of the application code before every execution.
  • Integrity: to ensure that a firmware about to be executed has not been corrupted or maliciously modified.
  • Authenticity: to verify that firmware is coming from a trusted and known source to prevent unauthorized entities from installing and executing code.
2) The Secure Firmware Update:
It is an immutable code that detects if a new firmware image is available, checks its authenticity and verifies the integrity of the code before installing it after decryption.

3. OEMiRoT use cases

There are two possible cases explained below:

3.1. Case 1: The user application starts after OEMiRoT

After resetting, the OEMiRoT firmware in user flash is run first in HDPL1. It is the user's responsibility to develop a root of trust firmware that:

  • First, checks the authenticity and integrity of the user application
  • Then jumps to the user application or bootloader depending on the authenticity and integrity checks.
SECURITY User app executed after OEM-iROT.png

After a positive check of the authenticity and integrity of the user application, OEMiRoT can jump directly into HDPL2 or HDPL3, potentially receiving the user application. User Application can be a fully secure application, a fully nonsecure application, or a combined secure/nonsecure application. If parameters configured in the user Root of Trust are not respected or if Authenticity and integrity checks fail, OEMiRoT executes the bootloader to download the new user application and user data. The user is responsible for activating all the required security protections during the User Application execution.

3.2. Case 2: Two boot stage: The updatable Root of Trust (uRoT) runs after the OEMiRoT

The uRoT is in the user flash memory and runs as a second boot stage adapted to customer requirements. The following figure shows the entry point after reset and the OEMiRoT controlling the step to uRoT.

SECURITY Urot executed after OEM-iROT.png

OEMiRoT is the entry point executed after any reset.

After the OEMiRoT successfully verifies the uRoT, it is executed in HDPL2 and verifies the secure and nonsecure applications before jumping to secure and switching to HDPL3.

In the provided example from STM32CubeH5 FW, if there is a verification failure of the uRoT, OEMiRoT executes the bootloader to download a new uRoT code or data. By default, the bootloader is used in this example to get new firmware, but the user can develop other connections like OTA.

4. OEMiRoT provisioning steps

Three steps can characterize OEMiRoT provisioning:

  • Step 1 – OEMiRoT and Debug Authentication configuration

This step configures the keys used to encrypt/decrypt the data and sign/check the signature of the user application.

  • Step 2 – Code and data image generation

The tools and IDE compile all the firmware and generate the images.

  • Step 3 – Product state setting

The user can choose the final product state.

OEMiROT STM32H5 How to Introduction introduction of the How-to articles details these steps. Many use cases present examples in STM32CubeH5 firmware that you can use with the help of the How to articles to start a new project. How to articles about OEMiRoT :