OEMiRoT STM32H7S How to Introduction

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

1. Introduction

This wiki article describes OEMiRoT process steps developed in STM32CubeH7RS firmware and should be read before the How to start with OEMiRoT on STM32H7S wiki article.

For more information about OEMiRoT please refer to OEMiRoT and OEMuRoT for STM32H7S.

2. OEMiRoT services

1) The secure boot (Root of Trust services):

It is an immutable code that runs after every system reset. It activates STM32 runtime protections and verifies the authenticity and integrity of the application code before every execution.

• Integrity: to ensure that no corrupted or maliciously modified firmware is about to run.
  
• Authenticity: to verify that firmware comes 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 process in STM32CubeH7RS firmware examples

In the STM32CubeH7RS firmware package, an OEMiRoT use case is given as example.
In this example OEMiRoT boot path is automatically configured in a provisioning script.
For more details about the use case developed in STM32CubeH7RS package go to the One boot stage example
described in OEMiRoT for STM32H7RS - One boot stage

The figure below illustrates the boot scheme followed in the OEMiRoT example.

• At reset, RSS jumps from system flash to OEMiRoT in internal Flash (Option Byte IROT_SELECT is configured in the script to boot on OEMiRoT).
• OEMiRoT checks if a new user application is stored in the download slot in external Flash.
• If any, OEMiRoT decrypts it then controls its integrity, its authenticity and the anti-rollback version.
• If successful, the image is re-encrypted with MCE_1 encryption key and copied in the user application installation slot.

Information

MCE_1 encryption key is derived from HUK. For more details please refer to Feature list for OEMiRoT

• OEMiRoT controls the integrity and the authenticity of the user application image from the installation slot located in the external flash memory.
• If successful, OEMiRoT executes it from external flash memory.

In the OEMiRoT use case example described above user application is executed in place (external flash memory), but it can be executed from external RAM memory or from internal RAM memory depending on theOEMIROT_LOAD_AND_RUN define parameter. Please refer to OEMiRoT - One boot stage for more explanations about the different execution modes.

3.1. OEMiRoT provisioning steps

Please refer to OEMiRoT for STM32H7S : Provisioning process if you need more details about OEMiRoT mechanism.

3.1.1. Step 1 – Preliminary stage

3.1.1.1. Define product state value

The following figure shows the possible product states.

The provisioning script provisioning.bat given as an example in STM32CubeH7RS firmware guides the user during this phase.
At the beginning of the provisioning script execution, the user chooses the product state that automatically sets the corresponding option byte.
The product state is chosen depending on the user application development phase and the wanted security level.

• Open:
  

• This state is mainly used during the development phase since the device is fully open.
  
• Debug is fully open.
  
• Bootloader is usable.
  

• Provisioning:
  

• This state is used during the provisioning.
  

It is the device state during the provisioning script execution (provisioning.bat given as an example in STM32CubeH7RS firmware).

This state is not part of the proposed state selectable at the end of the script execution.

• Debug access is only available if DA-Config is provisioned. Allowed actions: Full-Regression or Intrusive debug
• Bootloader is usable.
  
• In this state user code will not execute : Provisioning state can't be the final targeted state of the product.

• Closed:
  

• This state occurs with the fully provisioned product.
  
• The debug is fully closed but can be opened by launching the Debug Authentication (see Debug Authentication setting).
  

• Locked:
  

• This state is used with the fully provisioned product without any more changes.
  
• Locked is a final unchangeable product state. No method can modify the embedded firmware and product configuration.
  
• The debug is definitively closed and cannot be reopened through debug authentication.
  
• No regression is possible anymore.
  

3.1.1.2. Define Debug Authentication method

On STM32H7S MCUs the user is free to select the Debug Authentication method : password or certificate. Certificate method allows to do debug reopening with Debug Authentication while the password method only allows to do full regressions.
For more details about Debug Authentication mechanisms, please refer to Debug authentication for STM32H7RS MCUs.

3.1.2. Step 2 - Configuration management

3.1.2.1. OEMiRoT configuration

STM32TrustedPackageCreator tool is used to generate OEMiRoT configuration file (.obk) based on template OEMiROT_Config.xml provided in STM32CubeH7RS firmware package (Projects\STM32H7S78-DK\ROT_Provisioning\OEMiROT\Config).

These parameters are configurable during the OEMiRoT configuration:

• Authentication key, used to authenticate the firmware image.
• Encryption key, used to encrypt the firmware image.
• Output file : the generate provisioning data will be stored in this file

For OEMiRoT use caseOEMiRoT configuration file.obk is encrypted and saved in HDPL1 OBkeys.

OEMiROT_boot application is available for each OEMiRoT example in Applications\ROT\OEMiROT_Boot.

3.1.2.2. DA configuration

STM32TrustedPackageCreator also generates the Debug Authentication configuration file (.obk) based on template provided in STM32CubeH7RS software package. This file configures the conditions to reopen a protected device and the debugger.

For more details about debug authentication mechanisms, please refer to Debug authentication for STM32H7RS MCUs.

3.1.3. Step 3 – Images generation

STM32CubeH7RS firmware package delivers Boot firmware and User firmware projects for OEMiRoT use case in Applications\ROT folder.

During this step the two firmware OEMiRoT_Boot and OEMiRoT_Appli are compiled. Compilation of OEMiRoT_Appli links to a postbuil script. This script calls STM32TrustedPackageCreator witch encrypts and signs the image of the firmware.

3.1.4. Step 4 – Option Bytes configuration

This last step configures the Option Bytes and flash the images. The board is at least configured and final product state is set.

4. How to start with STM32 and OEMiRoT

You can refer to the following pages for getting started examples of OEMiRoT: How to start with OEMiRoT on STM32H7S.