This article gives an overview of the OEMiRoT and the OEMuRoT solutions integrated in STM32H7S.

How to use it, step by step, is described in wiki pages How to start with OEMiRoT on STM32H7S and How to start with STiRoT-OEMuRoT on STM32H7S

List of applicable products:

Type	Products
Microcontroller	STM32H7S7A8, STM32H7S7I8, STM32H7S7L8, STM32H7S7N8 STM32H7S7Z8, STM32H7S3A8, STM32H7S3I8, STM32H7S3L8, STM32H7S3L8U, STM32H7S3N8, STM32H7S3R8, STM32H7S3V8, STM32H7S3Z8

1. OEMiRoT/OEMuRoT presentation

1.1. Overview

OEMiRoT stands for OEM immutable (unchangeable) Root of Trust and acts as a first boot stage. OEMiRoT is an example based on the MCUboot open-source software (refer to MCUboot) provided with STM32CubeH7RS. OEMiRoT offers two services:

The Secure Boot (root of trust service) is an immutable code, which is always executed after a system reset. It checks static protections (options bytes), activates runtime protections, and then verifies the authenticity and integrity of the user application code before every execution.
The Secure Firmware Update application is an immutable code that detects new firmware image candidate. It checks its version (version downgrade prevention), authenticity, and integrity before installing it after decryption.

An OEM updatable RoT (OEMuRoT) can be generated by compiling OEMiRoT_Boot project with OEMUROT_ENABLE switch activated. OEMuRoT acts as a second boot stage after STiRoT, and provides the same two services: Secure Boot and Secure Firmware Update. Both OEMiRoT and OEMuRoT examples are generated based on OEMiRoT_Boot project with the switch OEMUROT_ENABLE activated or not.

1.2. Protection measures and security strategy

Cryptography ensures integrity, authentication, and confidentiality. However, the use of cryptography alone is not enough: a set of measures and system-level strategies are needed for protecting critical operations, sensitive data (such as a secret key), and the execution flow in order to improve security robustness. On STM32H7S, the security strategy is based on:

Product life cycle: product state CLOSED or LOCKED must be selected in order to ensure that the JTAG debugger cannot access the device, except to execute the DA process (more details in Debug Authentication for STM32H7RS wiki article).
Boot configuration: IROT_SELECT option byte is set to establish a chain of trust by forcing the system to boot on system flash memory or user flash memory:

One boot stage: IROT_SELECT option byte must be set to OEMiRoT to force the boot from the user flash memory where the OEMiRoT code must be located.

Two boot stages: IROT_SELECT option byte must be set to STiRoT to force the boot from system flash memory.

Antitamper protection: the antitamper protection is used to protect sensitive data from physical tampering. The antitamper protection is activated at the start of OEMiRoT_Boot project and remains active during OEMiRoT_Appli execution. In case of tamper detection, sensitive data, caches, and cryptographic peripherals are immediately erased, and a reboot is forced. Both external active tamper pins and internal tamper events are used.
MPU: The MPU is a memory protection mechanism that allows specific access rights to be defined for any memory-mapped resources of the device: flash memory, SRAM, and peripheral registers. The MPU is configured to limit the execution surface to the code section of OEMiRoT_Boot project during its execution, then extended to the application code section after verifying its integrity and its authenticity. This protection is dynamically managed at runtime.
HDP: HDP area is configured to cover the whole OEMiRoT_Boot project code area in order to prevent any execution out of the OEMiRoT_Boot execution. When jumping in the application, the temporal isolation (HDP level) is increased from HDPL1 to HDPL3 making the OEMiRoT_Boot project code no longer accessible.
OBkeys: HDPL1 OBkeys (HDPL2 OBkeys for OEMuRoT) are a protected and isolated area used to store secrets such as encryption and authentication cryptographic keys. This area is no longer accessible when switching from HDPL1 to HDPL2 or to HDPL3. Data stored in this area is encrypted with a key derived from HUK.
WRP: Write protection is used to ensure OEMiRoT_Boot code immutability as requested by the state-of-the-art standards in secure boot implementation. In the OEMiRoT_Boot project, the system has been configured to make the OEMiRoT_Boot code as immutable.
RAM ECC: RAM ECC is a mechanism to prevent memory corruption. A reset is generated in case of RAM ECC detection.

See also STM32H7RS Reference manual for more description on each feature.

Note: WRP and HDP protections cannot be activated when OEMUROT_ENABLE switch is activated.

1.3. OEMiRoT/OEMuRoT activation

On STM32H7S, OEMiRoT/OEMuRoT activation is done by:

Configuring the IROT_SELECT option to boot on OEMiRoT or STiRoT.
Configuring secrets: authentication and encryption keys used by OEMiRoT or OEMuRoT.
Building OEMiRoT_Boot binary in the selected configuration, OEMiRoT or OEMuRoT.

All these operations are part of the provisioning process.

There are two different uses cases:

One boot stage, OEMiRoT: OEMiRoT_Boot project binary is built in OEMiRoT configuration. OEMiRoT directly manages the user application binary.
Two boot stages, STiRoT + OEMuRoT: OEMiRoT_Boot project binary is built in OEMuRoT configuration. STiRoT integrated inside the STM32H7S manages an updatable boot stage (OEMuRoT) located in the external flash memory, which manages the user application binary.

1.3.1. One boot stage: OEMiRoT

OEMiRoT is generated by compiling OEMiRoT_Boot project with the OEMUROT_ENABLE switch de-activated.

At reset, OEMiRoT, located in the user flash memory, is executed in temporal isolation 1 (HDPL1). After a successful verification of the authenticity and the integrity of the user application code image, OEMiRoT executes the user application in HDPL3. In case of verification failure, a reset will be triggered except if OEMIROT_DEV_MODE compilation switch is activated during OEMiRoT_Boot project generation. In this case the execution will fall into an infinite loop.

The following figure illustrates the secure boot and the secure update process by showing all the steps required to boot the user application code image located in the installation slot of the external flash memory:

In CLOSED or LOCKED product state, RSS is the first software executed. RSS jumps into OEMiRoT if IROT_SELECT option byte is configured to boot on OEMiRoT.
OEMiRoT checks if a new user application is stored in the download slot. If any, OEMiRoT decrypts it then controls its integrity, its authenticity and the antirollback version. If successful, the image is decrypted and copied in the user application installation slot. The image is re-encrypted (AES) with MCE_1 key.
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 or from external/internal RAM memories. In case of RAM memory execution (load and run use case), an additional copy is made before its execution with an MCE re-encryption (NOEKEON) using MCE_2 key for the external RAM memory. Refer to the Features list for more details on OEMiRoT execution modes.

Note: To ensure the security of the device, the MPU is configured to allow only the user application code area to be executed when OEMiRoT jumps into the user application, minimizing the risk of unauthorized code execution. It is the user application responsibility to reconfigure the MPU to fit with its security needs.

1.3.2. Two boot stages: STiRoT + OEMuRoT

OEMuRoT is generated by compiling OEMiRoT_Boot project with OEMUROT_ENABLE switch activated. OEMuRoT (updatable Root of Trust) acts as a second boot stage.

At reset, STiRoT is executed in temporal isolation 1 (HDPL1). After a successful verification of the authenticity and the integrity of OEMuRoT code image, STiRoT executes OEMuRoT in HDPL2 in RAM memory. Then, OEMuRoT verifies the user application before executing it from external flash or external/internal RAM memories. In case of verification failure, a reset will be triggered except if OEMIROT_DEV_MODE compilation switch is activated during OEMiRoT_Boot project generation. In this case the execution will fall into an infinite loop.

The following figure illustrates the main steps performed to execute a user application in the two boot stages configuration:

In CLOSED or LOCKED product state, RSS is the first software executed. RSS jumps into STiRoT if IROT_SELECT option byte is configured to boot on STiRoT.
After executing the secure firmware update process (refer to STiRoT_for_STM32H7S article for more details on STiRoT), STiRoT requests iLoader to load the OEMuRoT image from installation slot in the internal RAM memory.
Then STiRoT controls its integrity and its authenticity. If successful, STIRoT executes OEMuRoT in internal RAM memory.
OEMuRoT checks if a new user application is stored in the download slot. If any, OEMuRoT decrypts it then controls its integrity, its authenticity and the antirollback version. If successful, the image is decrypted and copied in the user application installation slot. The image is re-encrypted (AES) with MCE_1 key.
OEMuRoT controls the integrity and the authenticity of the user application from the installation slot. If successful, OEMuRoT executes it from external flash memory or from external/internal RAM memories. In case of RAM memory execution (load and run use case), an additional copy is made before its execution with an MCE re-encryption (NOEKEON) using MCE_2 key for the external RAM memory. Refer to the Features list for more details on OEMuRoT execution modes.

Note: To ensure the security of the device, the MPU is configured to allow only the user application code area to be executed when OEMuRoT jumps into the user application, minimizing the risk of unauthorized code execution. It is the user application responsibility to reconfigure the MPU to fit with its security needs.

1.3.3. Swap upgrade strategy

When the swap upgrade strategy is configured when generating OEMiRoT or OEMuRoT, the scratch buffer is used:

during installation, to swap download and installation slots.
at reset, the images are swapped back if the new user application is not confirmed.

In the swap upgrade strategy, the antirollback version is saved at reset if the user application is confirmed. However, in overwrite mode, it is saved at the end of the installation process. Refer to OEMiRoT/OEMuRoT start-up sequence for more details.

2. Features list

The main features of the OEMiRoT/OEMuRoT are:

Hardware-accelerated cryptography operations with PKA, HASH, SAES and MCE:

ECDSA-P256 asymmetric cryptography for image authentication.
SHA256 cryptography for image integrity check.
AES-CTR-128 cryptography for image encryption with symmetric key encrypted in ECIES-P256 provided in the image itself. Refer to Image generation for more details.
AES-ECB-128 cryptography for image encryption with MCE_1 key after installation in external flash memory. MCE_1 is derived from HUK.
NOEKEON cryptography for image encryption with MCE_2 key after transfer in external RAM memory before its execution (load and run configuration). MCE_2 is derived from HUK.

Accelerated boot thanks to image SHA256 reference management. Image verification mainly consists of verifying the SHA256 of the image (integrity check), and then verifying the signature of this SHA256 (authentication check). If successful, the SHA256 is stored as reference for next boot. At the next boot, the signature verification is skipped if the SHA256 of the image match the reference stored in OBKeys. This feature brings performance optimization (under the MCUBOOT_USE_HASH_REF compilation switch).
Antirollback version check based on image version stored in OBkeys.
Image installation resistant to asynchronous power down and reset.
Integration of the full entropy TRNG source (RNG hardware peripheral) for random delays generation.
Configurable firmware image upgrade strategy for primary and secondary slots mode:

Overwrite strategy, for which the image in the secondary slot overwrites the image in the primary slot.
Swap strategy, for which the image in primary and secondary slots are swapped. After the swap, the new image in the primary slot must be confirmed by the user application. Otherwise, at the next boot, the images are swapped back.

Note: A reset must be generated by the user application after confirmation to update the confirmation flag inside the image in the installation slot. The "read while write" feature is not managed for the external flash memory.

Memory configuration:

Download slot in external flash memory. The image is encrypted in AES-CTR-128 with a symmetric key. This key is encrypted in ECIES-P256 with MCUBootkey.
Installation slot in external flash memory. This slot is encrypted in AES-ECB-128 with the MCE_1 based on a key derived from HUK.
Execution slot from internal RAM or external RAM memories (load and run configuration). The external RAM memory slot is encrypted in NOEKEON with the MCE_2 based on a specific key derived from HUK.

Load and run execution mode capability is configured with OEMIROT_LOAD_AND_RUN define. In addition to the standard execution mode (in place), the user application can be executed:

from external RAM memory
from internal RAM memory. In this configuration, the size of the application is limited to 128 Kbytes. During the load of the application in internal RAM, OEMiRoT/OEMuRoT data, OEMuRoT code (depends on the bootpath selected) and the application code are mapped in RAM at the same time.

Integration of hardware security peripherals and mechanisms in order to implement a root of trust. Product life cycle, IROT_SELECT, MPU, WRP, HDP, and TAMPER are combined to protect the product. When connected on the HW board, external tamper can be activated with OEMIROT_TAMPER_ENABLE define.
Image generation with STM32TrustedPackageCreator tool delivered within STM32CubeProgrammer.

Features configurability:

Feature	OEMiRoT	OEMuRoT	Configuration switch
Boot project generation	OEMiRoT generation	OEMuRoT generation	OEMUROT_ENABLE
Image upgrade strategy	Overwrite only mode Swap mode	Overwrite only mode Swap mode	MCUBOOT_OVERWRITE_ONLY
Flash memory configuration	External flash memory for download and installation slots Execution slot definition depending on load and run configuration	External flash memory for download and installation slots Execution slot definition depending on load and run configuration	MCUBOOT_OVERWRITE_ONLY
Load and run execution modes configuration	No: execution from external flash memory Execution from external RAM memory Execution from internal RAM memory	No: execution from external flash memory Execution from external RAM memory Execution from internal RAM memory	OEMIROT_LOAD_AND_RUN
Antitamper	None Internal tampers only Internal and external tampers	None Internal tampers only Internal and external tampers	OEMIROT_TAMPER_ENABLE
Project phase (Application development phase )	Development mode Production mode	Development mode Production mode	OEMIROT_DEV_MODE

OEMiRoT/OEMuRoT differencies:

Feature	OEMiRoT	OEMuRoT
WRP	ON, immutable RoT	OFF, updatable RoT
HDP	activated on user flash to hide OEMiRoT code after execution	Not activated - OEMuRoT executed in internal RAM
Execution environment	user flash - HDPL1	internal RAM - HDPL2
Area to store secrets (cryptographic keys)	HDPL1 OBkeys	HDPL2 OBkeys

3. Memories layout

The STM32CubeH7RS OEMiRoT/OEMuRoT relies on memories layout defining several regions:

SCRATCH region: region used by OEMiRoT_Boot to store the image data temporarily during the image swap process (not used in overwrite-only mode).
OEMiRoT_Boot code region: region to program the OEMiRoT_Boot code binary that manages the functions "Secure Boot" and "Secure Firmware Update”.
OEMiRoT_Boot volatile data: region used to locate internal variables and call stack, during OEMiRoT_Boot code execution.
Application installation (primary) slot region: region to program the image of an “active” firmware after installation.
Application download (secondary) slot region: region to program the image of a “new” firmware, candidate for installation.
Application execution slot region when load and run feature is activated.
iLoader code region: region to program the STiRoT_iLoader code binary responsible to transfer the image from external flash to RAM for STiROT (specific to STiRoT/OMEuRoT use case).
Image confirmation flag and RAM ECC handle:

Memories layout is as follow:

For both configuration, default values are:

Symbol	Execute in place	Load and run in external RAM	Load and run in internal RAM
FLASH_AREA_0_OFFSET	0x00000000	0x00000000	0x00000000
FLASH_AREA_0_SIZE	0x00200000	0x00200000	0x00020000
FLASH_AREA_2_OFFSET	0x00200000	0x00200000	0x00020000
FLASH_AREA_2_SIZE	0x00200000	0x00200000	0x00020000
PRIMARY_RUN_PARTITION_START	NA	0x70000000	0x24040000
FLASH_AREA_SCRATCH_OFFSET	0x00400000	0x00400000	0x00040000
FLASH_AREA_SCRATCH_SIZE	0x00010000	0x00010000	0x00010000
FLASH_AREA_BL2_OFFSET*	0x00000000	0x00000000	0x00000000
FLASH_AREA_BL2_SIZE*	0x00010000	0x00010000	0x00010000
BL2_RAM_BASE**	0x24000000	0x24000000	0x24000000
BL2_RAM_SIZE**	0x00020000	0x00020000	0x00020000
BL2_DATA_START	0x20000000	0x20000000	0x20000000
BL2_DATA_SIZE	0x00020000	0x00020000	0x00020000
RAMECC_HANDLE_START	0x30007FA0	0x30007FA0	0x30007FA0
RAMECC_HANDLE_SIZE	0x40	0x40	0x40
CONF_FLAG_SIZE	0x20	0x20	0x20

*: specific to OEMiRoT
**: specific to OEMuRoT

If the definition of the FLASH_AREA_0 or FLASH_AREA_2 is modified (offset or size), the MPU regions configuration must be updated taking into account the constraints on Cortex M7 MPU (refer to ARM documentation for more details):

region start address is multiple of the region size
each region can be divided in 8 sub-regions

4. Provisioning process

4.1. OEMiRoT provisioning process

The product provisioning to activate and configure OEMiRoT is done following the three steps below:

Configuration of OEMiRoT. At this stage, the cryptographic keys for authentication and encryption are defined.
Generation of the firmware image.
Programming of the OBkeys, the option bytes, the application image in the device.

Note: A set of scripts is provided in Firmware/Projects/STM32H7S78-DK/ROT_Provisioning/OEMiRoT folder. It guides the user all along the provisioning process. Refer to How to start with OEMiRoT on STM32H7S article.

4.2. STiRoT + OEMuRoT provisioning process

The product provisioning to activate and configure OEMuRoT is done following the four steps below:

Configuration of STiRoT. At this stage, the location of the image, and the STiRoT cryptographic keys are defined. Refer to How to start with STiRoT on STM32H7S article.
Configuration of OEMuRoT. At this stage, the OEMuRoT cryptographic keys for authentication and encryption are defined.
Generation of the OEMuRoT code image as well as the application code image.
Programming of the OBkeys, the option bytes, the OEMuRoT code image and the application code image in the device.

Note: A set of scripts is provided in Firmware/Projects/STM32H7S78-DK/ROT_Provisioning/STiROT_OEMuROT folder. It guides the user all along the provisioning process. Refer to How to start with STiRoT-OEMuRoT on STM32H7S article.

4.3. OEMiRoT/OEMuRoT configuration file

OEMiRoT/OEMuRoT configuration file (OEMiRoT_Config.obk, OEMuRoT_Config.obk) is generated using STM32TrustedPackageCreator with a template file listing all the different parameters (OEMiRoT_Config.xml, OEMuRoT_Config.xml) as input. The obk file is encrypted and saved in HDPL1 OBkeys (OEMiRoT) or HDPL2 OBkeys (OEMuRoT).

The list of the configuration parameters is the following:

Parameter	Description	Additional constraints
Encryption key	Key used to encrypt the firmware image	When this key is regenerated, firmware image must be processed with TPC “Image Gen” tab (OEMiRoT_Code_Image.xml)
Authentication key	Key used to authenticate the firmware image	When this key is regenerated, firmware image must be processed with TPC “Image Gen” tab (OEMiRoT_Code_Image.xml)

A detailed presentation of the format of STiROT_Config.obk file is provided in Appendix 5.3 STiROT Config.obk file format.

5. Image generation

OEMiRoT/OEMuRoT manages an image based on MCUBoot format including:

a header,
the encrypted firmware binary,
some metadata information (TLV format: Tags Length Value) allowing the control of the image (SHA256, ECDSA-P256 signature…), and
a magic to trigger the installation at the end of the slot.

Further information about the MCUBoot open-source software is available at MCUboot.

A PC tool STM32TrustedPackageCreator is provided to generate the firmware code image. This image is encrypted and signed using the keys configured in OBkeys configuration file (OEMiRoT_Config.xml / OEMuRoT_Config.xml). OEMiRoT_Code_Image.xml / OEMuRoT_Code_Image.xml contains all the parameters driving the image generation such as:

The authentication and encryption keys. Keys value inherited from OEMiRoT_Config.xml / OEMuRoT_Config.xml.
The version. OEMiRoT_Code_Image.xml / OEMuRoT_Code_Image.xml can be edited with STM32TrustedPackageCreator in order to modify the version.

The following figure shows the firmware image generation:

6. Appendix

6.1. OEMiRoT/OEMuRoT start-up sequence

Note: When no valid firmware image is installed a reset will be triggered in loop. Debug authentication process must be executed to force the download of a new image. Refer to Debug Authentication for STM32H7RS article.

Performance measured in "production mode (OEMIROT_DEV_MODE not defined)" @ 380 MHz:

Configuration	Typical user application boot time
Configuration	64 Kbytes	127 Kbytes	512 Kbytes	1 Mbyte	2 Mbytes
Execution from external flash	64 ms	86 ms	222 ms	403 ms	764 ms
Execution from external RAM memory	106 ms	176 ms	605 ms	1175 ms	2309 ms
Execution from internal RAM memory	81 ms	128 ms	NA	NA	NA

Note: In the configuration STiRoT + OEMuRoT, the boot time increases by 35 ms.

6.2. Application development phase

During development phase, it is recommended to compile OEMiRoT_Boot project with DEV_MODE defined and to select OPEN state during provisioning process:

When DEV_MODE is defined:

logs are displayed in tera term during OEMiRoT_Boot project execution.
an infinite loop is executed instead of a reset in Error_Handler() function.
tamper event is cleared at startup when required. No need to power off/on the board to clear this event.
OPEN product state can be selected during provisioning process.

When OPEN product state is selected during provisioning process, a specific script (obkey_provisioning_open.bat (.sh)) is called in order to execute additional actions usually done in PROVISIONING product state:

provision the AHKs (see STM32H7RS Reference manual for more description) used to encrypt OBkeys and to encrypt images with MCE peripheral.
initialize the OEMiRoT data area in the OBkeys containing the version of the firmware installed as well as its SHA256 used when MCUBOOT_USE_HASH_REF is activated. Refer to the Features list for more details on MCUBOOT_USE_HASH_REF.

In CLOSED or LOCKED product state, the DA process should be run to be able to connect the debugger through JTAG. At the end of the development phase, DEV_MODE must be disabled and the product state CLOSED or LOCKED must be selected during provisioning process. Refer to Debug Authentication for STM32H7RS article.

6.3. OEMiRoT_Config.obk file format

Offset	Size	Type	Description
0	1	uint8	sdp command header : destination OBKey index
1	1	uint8	sdp command header : destination OBKey HDP level
2	2	uint16	sdp command header : reserved
4	4	uint32	sdp command header : data size
8	4	uint32	sdp command header : encryption disabled/enabled (0/1)
12	32	array	SHA256 of the following data content (from offset 44 to 235)
44	91	array	ECDSA-P256 authentication public key
135	70	array	ECDSA-P256 encryption private key
205	31	array	Reserved

Same applied for OEMuRoT_Config.obk

6.4. OEMiRoT_Code_image xml file format

Parameter	Updatable	Description
Authentication key	Automatic	Private key inherited from OEMiROT_Config.xml file.
Encryption key	Automatic	Public key inherited from OEMiROT_Config.xml file.
Endianness	No	Little endian.
Padding	No	Add an installation magic value at the end of the image to trigger image installation. Padding with 0xFF when required.
Firmware area size	Automatic	Firmware slot size information. This value is updated during the postbuild of OEMiRoT_Boot project compilation based on slot configuration from flash_layout.h
Header Size	No	0x400 bytes
Padding Header	No	Padding the header with 0xFF to fulfil the 0x400 bytes.
Dependency with data image	No	The dependency is disabled by setting the <enable> property to 0.
Write Option	Automatic	Image upgrade strategy: Overwrite, Swap. This value is updated during the postbuild of OEMiRoT_Boot project compilation based on MCUBOOT_OVERWRITE_ONLY definition from flash_layout.h.
Version	Yes	x.y.z firmware image version.
Security Counter	No	Security counter value automatically generated based on version information.
Align	No	The size of the encrypted binary generated is multiple of 16 bytes.
Firmware download area offset	Automatic	Used to generate .hex binary file format including the destination address. This value is updated during the postbuild of OEMiRoT_Boot project compilation based on slot configuration from flash_layout.h.
Firmware binary input file	Automatic	Location of the firmware binary file. This parameter is updated during the provisioning process based on information from env.bat file.
Image output file	Yes	Location of the encrypted image generated. If changed, provisioning scripts must be updated accordingly.

Same applied for OEMuRoT_Code_Image.xml

6.5. System clock frequency

The system clock is set to 380 MHz to be functional with all hardware configurations (ECC_ON_SRAM enabled, no internal regulator) and with the full range of temperature (Tj up to 125 degrees).

If the constraints related to power and temperature are met, and if the RAMECC security feature is disabled (boot_hal_cfg.h, ob_flash_programming.bat (.sh) for OEMiRoT bootpath or STiROT_Config.xml for STiRoT + OEMuRoT bootpath), it is possible to increase the system clock up to 600MHz.

The system clock configuration shall then be updated in OEMiROT_Boot project. A compatible power configuration shall be applied either in OEMiROT_Boot project for the OEMiRoT bootpath or in STiROT_iLoader project for the STiRoT + OEMuRoT bootpath. This power configuration shall be applied before any XSPI configuration.

OEMiRoT OEMuRoT for STM32H7S

Contents