OEMiRoT for STM32C5

This article provides an overview of the OEMiRoT solution integrated into the STM32C5 devices.

For a step-by-step user guide, refer to the wiki page How to start with OEMiRoT on STM32C5.

Applicable products:

Type	Products
Microcontroller	STM32C542xx, STM32C562xx, STM32C5A3xx

1. OEMiRoT presentation

1.1. Overview

OEMiRoT stands for OEM immutable (unchangeable) Root of Trust and acts as a first boot stage. It is based on the MCUboot open-source software.

OEMiRoT provides two services:

• Secure Boot (root of trust service): immutable code, which is always executed after a system reset. It checks static protections (option bytes), activates runtime protections, and verifies the authenticity and integrity of the user application code before every execution.
• Secure Firmware Update: immutable code that detects new firmware image candidates. It checks the version (to prevent version downgrade), authenticity, and integrity before installing the firmware after decryption.

Information on STMicroelectronics modifications in MCUboot are available in the MCUboot User Guide.

1.2. Protection measures and security strategy

Cryptography ensures integrity, authentication, and confidentiality. However, the use of cryptography alone is insufficient; a combination of measures and system-level strategies is necessary to protect critical operations, sensitive data (such as secret keys), and the execution flow, thereby enhancing security robustness.

On the STM32C5 devices, the security strategy is based on the following hardware mechanisms:

• RDP (Readout Protection): Level 2 provides the highest protection. RDP level 2 with OEMKEY password capability ensures that a JTAG debugger cannot access the device except to inject the OEMKEY password. When the OEMKEY password is injected via the JTAG port, the RDP level regresses to level 0. The OEMKEY password must be provisioned while the RDP level is 0.
• Boot configuration: BOOT_LOCK and BOOTADD option bytes are configured to establish a chain of trust by forcing the system to boot from a unique user flash memory address.
• HDP (Hide Protection): When activated, any access (fetch, read, programming, erase) to the protected flash memory area is denied. All code and secrets inside this area are fully hidden. In OEMiRoT examples, the system hides the OEMiRoT code and nonvolatile data (secrets, antirollback counters, reference hashes) in user flash before launching the user application.
• WRP (Write Protection): Ensures OEMiRoT immutability as required by secure boot standards. The OEMiRoT code and personalized data (secrets) are configured as immutable.
• MPU (Memory Protection Unit): Defines specific access rights for memory-mapped resources (flash, SRAM, peripherals). The MPU limits execution to the OEMiRoT code section during its execution and extends to the user application after verifying integrity and authenticity. This is dynamically managed at runtime.
• Antitamper protection: Protects sensitive data from physical tampering. Activated at OEMiRoT start and remains active during execution. On tamper detection, sensitive data in SRAM and cryptographic peripherals are erased immediately, and a reboot is forced.
• SRAM Erase on reset: SRAM2 is automatically erased on system reset.
• SRAM Error code correction: Data integrity is verified on SRAM2 read access.

Refer to the STM32C5xx Reference manual for detailed descriptions.

Secure software coding techniques such as redundant critical tests, random delays, parameter validation, and flow control mechanisms are also implemented to enhance security robustness.

1.3. OEMiRoT activation

On STM32C5, activating OEMiRoT involves:

• Configuring the flash layout and personalizing secrets (authentication and encryption keys).
• Building the OEMiRoT and user application image binaries.
• Programming the binaries and option bytes according to the flash layout and security strategy.

All these operations are part of the Provisioning process.

1.3.1. OEMiRoT in dual slot overwrite mode

In overwrite mode, OEMiRoT installs the new firmware image by overwriting the previous one.

This figure illustrates the secure boot and secure firmware update processes in overwrite mode, showing all steps required to boot the application code from flash memory. For simplicity, optional application data image management is not activated in this example (but application data image is managed similarly to application code image).

1. At reset, boot is forced on OEMiRoT using BOOTADD and BOOT_LOCK option bytes.
2. OEMiRoT checks if new user application code is stored in the download slot. If so, it decrypts it and verifies its integrity, authenticity, security version (against antirollback counters), and optionally version dependencies with other image.
3. If verification succeeds, image is decrypted and copied to the user application installation slot.
4. OEMiRoT verifies the integrity and authenticity of the user application code image in the installation slot.
5. If successful, OEMiRoT updates antirollback counters in the nonvolatile counter region.
6. Then executes the user application and hides OEMiRoT.

1.3.2. OEMiRoT in dual slot swap mode

In swap mode, OEMiRoT installs the new firmware image and backups the previous one. The new image in the installation slot must be confirmed by the user application, otherwise the images are swapped back at the next boot.

This figure illustrates the secure boot and secure firmware update processes in swap mode, showing all steps required to boot the application code from flash memory. For simplicity, optional application data image management is not activated in this example (but application data image is managed similarly to application code image).

1. At reset, boot is forced on OEMiRoT using BOOTADD and BOOT_LOCK option bytes.
2. OEMiRoT verifies if the application code image in the installation slot is confirmed. If yes OEMiRoT updates antirollback counters in the nonvolatile counter region.
3. OEMiRoT checks if new user application code is stored in the download slot. If so, it decrypts it and verifies its integrity, authenticity, security version (against antirollback counters), and optionally version dependencies with other image.
4. If the verification succeeds, the new image is decrypted and copied to the user application installation slot while the previous installed image is re-encrypted and copied to the user application download slot.
5. OEMiRoT verifies the integrity and authenticity of the user application code image in the installation slot.
6. It updates the hash reference.
7. Then executes the user application and hides OEMiRoT.

In case the image in installation slot is not confirmed, the image is reverted.

2. Feature list

The main features of OEMiRoT include:

• Integration of hardware security peripherals and mechanisms to implement a root of trust: RDP, BOOT_LOCK, BOOTADD, MPU, WRP, HDP, and TAMP are combined to achieve the highest security level.
• Dual slots mode: The downloaded image and the installed image reside in different memory slots, enabling:
  • Safe image programming in the download slot.
  • Image installation resistant to asynchronous power-down and reset.
• Firmware image upgrade strategies:
  • Overwrite mode: The image in the download slot overwrites the image in the installation slot; no rollback is possible.
  • Swap mode: The images in the primary and secondary slots are swapped. After the swap, the new image in the primary slot must be confirmed by the user application, otherwise, the images are swapped back at the next boot.
• Cryptography algorithms:
  • ECDSA-P256 asymmetric cryptography for image authentication.
  • SHA256 for image integrity verification.
  • AES-CTR-128 symmetric encryption with keys encrypted via ECIES-P256, included in the image.
• Hardware peripherals integration:
  • PKA peripheral for signature verification acceleration (when supported by the product).
  • SAES peripheral for image decryption acceleration (when supported by the product).
  • HASH peripheral for SHA256 computation acceleration.
  • RNG peripheral for true random number generation.
• Software cryptography fallback using STCryptoLib when hardware peripherals are unavailable.
• Version anti-rollback: Images with security versions lower than the anti-rollback monotonic counters stored in flash are rejected.
• Accelerated boot: Image verification uses stored SHA256 references to skip signature verification if the image is unchanged, improving performance (MCUBOOT_USE_HASH_REF compilation switch).
• Fast wake-up from standby: Firmware image control is bypassed on wake-up to accelerate resume time, with software countermeasures maintaining security (OEMIROT_FAST_WAKE_UP compilation switch). Software countermeasures ensures the same level of security of the secure boot.
• Support for one application code image and optionally one application data image, each with dedicated anti-rollback counters, and sharing the same authentication and encryption keys.
• Firmware image dependencies: New images can depend on other images’ versions; installation is pending until dependencies are met.
• Flash usage: Download and installation slots are located inside internal user flash memory

The different OEMiRoT use cases are demonstrated by dedicated OEMiRoT examples.

The following table lists the OEMiRoT examples on the STM32C5 series:

Example	STM32C5A3	STM32C562	STM32C542	Description
oemirot_overwrite				OEMiRoT in dual slot overwrite mode, with cryptography relying on STCryptoLib software and the HASH/RNG peripherals.

3. Memory layout

3.1. Flash memory layout

OEMiRoT relies on a specific flash memory layout that defines several regions:

• OEMiRoT code region: Stores the OEMiRoT code binary managing Secure Boot and Secure Firmware Update functions.
• Keys region: Stores personalized OEMiRoT secret keys (authentication and encryption keys).
• Antirollback counters region: Holds nonvolatile information about the last installed image versions (code and data) for the antirollback feature.
• Hash References region: Stores SHA256 references (one per image).
• Application code installation region: Where the verified application executes.
• Application code download region: Where candidate application code images are downloaded (encrypted).
• Application data installation region: Where verified application data images are installed.
• Application data download region: Where candidate application data images are downloaded (encrypted).

The flash memory layout is as follows:

Flash memory layout configuration:

Flash region	STM32C542xx default config	STM32C562xx default config	STM32C5A3xx default config	Configurability	Configuration variable	Configuration file
OEMiRoT code size	72 KB	72 KB	72 KB	Multiple of WRP group size + One FLASH page size	oemirot_size	mx_memory_config.ini
OEMiRoT keys	8 KB	8 KB	8 KB	No	NA	NA
OEMiRoT antirollback counters	8 KB	8 KB	8 KB	No	NA	NA
OEMiRoT hash references	8 KB	8 KB	8 KB	No	NA	NA
Application code slots size (download and installation slots)	80 KB	208 KB	464 KB	Multiple of FLASH page size	app_size	mx_memory_config.ini
Application data image	0	0	0	0 (disabled) or 1 (enabled)	data_image	mx_memory_config.ini
Application data slots size (download and installation slots)	0	0	0	Multiple of FLASH page size	data_size	mx_memory_config.ini

3.2. SRAM memory layout

SRAM2 is selected for OEMiRoT execution because it supports erase on reset and ECC features.

• The entire SRAM2 is available for the application but is not persistent through reset or standby modes due to the erase-on-reset feature.
• Other SRAM regions are fully dedicated to application use and can be persistent across reset and standby modes based on user configuration.

SRAM memory layout usage:

Flash region	STM32C542xx	STM32C562xx	STM32C5A3xx
OEMiRoT RAM size	20 KB	20 KB	20 KB

4. Provisioning process

4.1. OEMiRoT provisioning process

The product provisioning process includes the following steps:

1. Configuration of:
   • Flash memory layout
   • RDP (Readout Protection level, minimum RDP, RDP passwords)
   • OEMiRoT keys
2. Building of:
   • OEMiRoT binary
   • Application code image
   • Application data image (if applicable)
3. Programming of:
   • RDP passwords and OEMiRoT keys
   • Option bytes (WRP, HDP, BOOTADD, RDP, etc.)
   • Binaries

Information

The entire provisioning process is managed through a provisioning script that guides the user step-by-step. For more information, refer to the How to start with OEMiRoT on STM32C5 wiki page.

The image below shows a visual representation of all these steps.

Prebuild and postbuild commands are integrated into the projects:

• The prebuild command propagates the flash memory layout into the projects before building.
• The postbuild command generates firmware images from the application build output.

5. Images generation

OEMiRoT manages images based on the MCUboot format, which includes:

1. A header.
2. The firmware binary (encrypted or clear, depending on image type).
3. Metadata in TLV (Tag-Length-Value) format, enabling decryption and verification (hash, signature, etc.).

A magic value (16 bytes) is written at the end of the download slot (not part of the image) to trigger the installation request to OEMiRoT at the next boot.

More information about the MCUboot image format is available in the MCUboot open-source software documentation.

A PC tool, STM32TrustedPackageCreator (provided through STM32CubeProgrammer), is provided to generate firmware images. This tool contains an executable version of the imgtool script, which manages the MCUboot image creation.

The images are encrypted and signed using user-personalized keys.

Two types of images are generated:

• Provisioning image: Signed and in cleartext, programmed in the installation area during initial device programming.
• Firmware update image: Signed and encrypted, programmed in the download area and installed during the secure firmware update process.

5.1. Initial images generation

The files appli_code_provisioning_image.xml and appli_data_provisioning_image.xml contain all parameters for generating initial images, including:

• Authentication keys (inherited from oemirot_keys_config.xml)
• Version information

These XML files can be edited using STM32TrustedPackageCreator to modify user-selectable parameters (refer to Image xml format).

The following figure shows the initial image generation:

5.2. Update images generation

The files appli_code_fwu_image.xml and appli_data_fwu_image.xml contain parameters for generating update images, such as:

• Authentication and encryption keys (inherited from oemirot_keys_config.xml)
• Version information
• Dependency on other images if synchronized installation is required

These XML files can be edited using STM32TrustedPackageCreator to modify user-selectable parameters (refer to Image xml format).

The following figure shows the update images generation:

6. Appendix

6.1. Startup sequence

The following diagram illustrates the OEMiRoT startup sequence.

Boot time performance was measured at 144 MHz in production mode (withOEMIROT_DEV_MODE undefined, that is, no logs):

Image size	64 Kbytes	256 Kbytes	464 Kbytes
Boot time	8.7 ms	30.2 ms	53.4 ms

Wake-up time performance measured at 144 MHz in production mode:

Image size	64 Kbytes	256 Kbytes	464 Kbytes
Wake-up time	1.6 ms	1.6 ms	1.6 ms

6.2. From development to production phase

During development, it is recommended to compile the OEMiRoT project with the OEMIROT_DEV_MODE compile switch defined (default configuration) and to select RDP level 0 and minimum RDP level 0 during provisioning:

• When OEMIROT_DEV_MODE is defined:
  • Logs are displayed in a terminal emulator (for example Tera Term, Minicom) during the OEMiRoT project execution.
  • The Error_Handler() function executes an infinite loop instead of resetting.
• When RDP level 0 is selected:
  • The device is open and a debug interface is available.
  • OEMiRoT does not authorize secure boot if the RDP level is lower than the minimum RDP level.

At the end of development, OEMIROT_DEV_MODE must be undefined, and RDP level 2 (with or without boundary scan) and minimum RDP level 2 must be selected during provisioning to achieve the highest security level.

This configuration can be set during the provisioning script (user interaction) or by modifying the configuration variable/switch.

Development/production configuration:

Configuration	Possible values	Configuration variable or SWITCH	Configuration file
Development / Production mode	Development mode Production mode	OEMIROT_DEV_MODE	Pre_Include_Global.h
RDP level	RDP level 0 RDP level 2 with BS RDP level 2	final_rdp_level	provisioning.ini
RDP level min (control by OEMiRoT)	RDP level 0 RDP level 2 with BS RDP level 2	min_rdp_level	provisioning.ini

Information

Disabling OEMIROT_DEV_MODE may allow reducing the OEMiRoT code area size in flash to maximize application image areas (refer to Flash memory layout).

Information

The provisioning script generates a list of STM32CubeProgrammer commands (option bytes and binaries programming) in the cubeprogrammer_cmd.txt file, which can assist in preparing production scripts.

6.3. Constraints

When activating the OEMiRoT boot path, the following constraints must be considered:

• For enhanced security, the MPU is configured to allow execution only in the application code area when OEMiRoT transfers control. It is the user application’s responsibility to reconfigure the MPU according to its security requirements.
• Internal tamper 9 (fault generation for cryptographic peripherals such as SAES, PKA, AES, RNG) is activated in confirmed mode during OEMiRoT execution and remains active when jumping into the user application.
• SRAM2 is used by OEMiRoT and is erased on every reset.
• The system clock is configured to the maximum frequency using the PLL when the user application starts

6.4. Keys personalization

Default keys in .pem format are provided in the OEMiRoT examples:

Key filename	Description
oemirot_authentication.pem	SECP256R1 authentication private key
oemirot_encryption.pem oemirot_encryption_pub.pem	SECP256R1 encryption private key SECP256R1 encryption public key

Warning

Default keys must not be used in a product!

Keys can be personalized using the STM32TrustedPackageCreator tool with a template file (oemirot_keys_config.xml) listing all parameters. The main parameters include:

• Authentication key: Used to authenticate firmware images.
• Encryption key: Used to encrypt firmware images.

The template generates a binary file (oemirot_keys_config.bin) programmed on the device during provisioning. Its format is:

Offset (Bytes)	Size (Bytes)	Description
0	32	SHA256 of the SECP256R1 authentication public key
32	32	Raw SECP256R1 encryption private key

After key personalization, firmware images must be regenerated.

6.5. Image xml format

For each firmware image (code and data), there are two variants of the image XML file: the provisioning XML and the fwu (firmware update) XML. Most parameters are common to both variants.

Parameter	Image xml variant	Updatable	Description
Authentication key	All	Yes	Private key inherited from `oemirot_keys_config.xml`.
Encryption key	All	Yes	Public key inherited from `oemirot_keys_config.xml`.
No encryption(clear)	provisioning	No	Image is clear in the installation slot but includes encryption metadata for re-encryption if swapped to download slot.
Symmetric key length	All	No	128 bit AES-CTR symmetric key.
Endianness	All	No	Little endian.
Public key format	All	No	Authentication public key fully provided in image metadata (must match SHA256 of provisioned key).
Firmware area size	All	Automatic	Firmware area size, updated during provisioning based on flash layout.
Header size	All	No	Size of image header (0x400 bytes for application code image due to vector table alignment; 0x20 for application data image).
Padding header	All	No	Padding the header with 0xFF to fulfill the header size.
Version	All	Yes	Firmware image version in x.y.z format (x ≤ 255, y ≤ 255, z ≤ 65535).
Security version	All	Yes	Value used for antirollback. Can be 'auto' (aligned to image version) or manually set (32-bit). Note that antirollback feature is inactive if security version remains unchanged at each update of image.
Dependency with other image	fwu	Yes	Index and version of other image required for synchronized installation. Format is 'Index, version': Index: '0' for application code image, '2' for application data image Version: x.y.z As long as dependency condition is not satisfied, the candidate image remains pending in download slot.
Installation mode	All	No	Set according to OEMiRoT example type (overwrite or swap mode). It impacts the maximum image size inside the image area. In overwrite mode: maximum allowed firmware image size is the Firmware area size. In Swap mode: maximum allowed firmware image size is 2 flash pages below the Firmware area size, as some space is reserved for the swap process.
Image type	All	No	Image index value: '0' for application code image, '2' for application data image.
Align	All	No	Encrypted binary size is a multiple of 16 bytes.
Firmware download area offset	provisioning	Automatic	Used to generate .hex binary file format with destination address.
Firmware binary input file	All	No	Location of the firmware binary file.
Image output file	All	No	Location of the firmware image generated.

6.6. Antirollback feature

Information on antirollback counters usage during the product lifecycle:

• Each upgrade of a firmware image’s security version consumes 16 bytes (hardware programming granularity) in the anti-rollback counters region.
• The anti-rollback counters region size of 8 KB allows the management of up to 512 security version upgrades.
• For more details on the security versions, refer to the security version.
• When the anti-rollback counters region is full, counters cannot be updated further, but anti-rollback protection remains active based on the latest counter value

6.7. imgtool script

The STM32TrustedPackageCreator PC tool generates firmware images. It includes an executable version of the MCUboot imgtool Python script (including STMicroelectronics modifications), to manage the MCUboot image format. Refer to imgtool documentation in MCUboot open-source software for more information on imgtool script.

imgtool executable can be found in the /bin/Utilities directory of the STM32TrustedPackageCreator installation folder.

To check the imgtool command line used for image generation, a log file named imgtool-command.log is automatically created by STM32TrustedPackageCreator under the following path: <User-Home>\STMicroelectronics\STM32CubeProgrammer\imgtool-command.log.

For detailed information, refer to Appendix B of the STM32TrustedPackageCreator tool user manual .

The source code of the imgtool Python script is available in the scripts directory of the MCUboot pack.

It is possible to modify the imgtool script to meet customer-specific needs (e.g., using an HSM for authentication key, changing the cryptography scheme...).

After modification, user can generate an executable version of the script (for example, using PyInstaller) and replace the imgtool executable in the STM32TrustedPackageCreator installation folder, or directly invoke imgtool script starting from logged command in imgtool-command.log file.