OEMiRoT for STM32U0

This article gives an overview of the OEMiRoT solution integrated in STM32U0 devices.

For a step-by-step user guide, go to the wiki pages on getting started with STM32U0 security.

Applicable products:

Type	Products
Microcontroller	STM32U083xx, STM32U073xx

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 provided with STM32CubeU0.

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 (option bytes), activates runtime protections, and 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 candidates. It checks the version (version downgrade prevention), authenticity, and integrity before installing it after decryption.

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 secret keys), and the execution flow, to improve security robustness.

On STM32U0, the security strategy is based on:

• RDP: read protection level 2 achieves the highest protection level. Read protection level 2 with OEM2-password capability is used to ensure that a JTAG debugger cannot access the device, except to inject the OEM2 password. In RDP level 2, when the OEM2 password is injected through the JTAG port, the RDP level regresses to level 1. The OEM2 password must first have been provisioned when the RDP level is 0. Refer to RDP for STM32U0 for more details.
• Boot lock: the BOOT_LOCK option byte is configured to establish a chain of trust, by forcing the system to boot from the user flash memory at 0x08000000.
• Antitamper protection: the antitamper protection is used to protect sensitive data from physical attacks. It is activated at the start of the OEMiRoT_Boot project and remains active during the OEMiRoT_Appli execution. In the case of tamper detection, sensitive data in the backup SRAM 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 the OEMiRoT_Boot project during its execution and extended to the application code section after verifying its integrity and authenticity. This protection is dynamically managed at runtime.
• HDP: when the HDP secure hide protection is activated, any access to the protected flash memory area (fetch, read, programming, erase) is denied. All code and secrets located inside the protected flash memory area are fully hidden. In the OEMiRoT_Boot project example, the system is configured to hide the OEMiRoT_Boot code, the OEMiRoT_Boot personalized data (secrets), and the OEMiRoT_Boot nonvolatile counters area, located in the flash memory (refer to the chapter on flash memory layout for more details on the HDP area), just before launching the verified user application.
• 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, the OEMiRoT_Boot personalized data (secrets), and the OEMiRoT_Loader code as immutable data.

Refer to the STM32U0 reference manual for in-depth descriptions of each feature.

Secure software coding techniques, such as doubling critical tests, doubling critical actions, random delay, checking parameter values, and flow control mechanisms, are implemented to improve security robustness.

1.3 OEMiRoT activation

On STM32U0, OEMiRoT activation is done by:

• Setting the BOOT_LOCK option byte to 1.
• Programing the OEMiRoT_Boot and OEMiRoT_Loader binaries in the user flash memory.

These operations are all part of the provisioning process.

1.3.1 Overwrite-only mode

The following figure illustrates the Secure Boot and Secure Update process by showing all steps required to boot the user application code image:

1. At reset, boot is forced on OEMiRoT when BOOT_LOCK is set to 1.
2. OEMiRoT checks if a new user application code and/or new data images are stored in the download slots. If so, OEMiRoT decrypts them and checks their integrity, authenticity, antirollback counter, and dependency version.
3. If successful, the images are decrypted and copied to the user application installation slots.
4. OEMiRoT checks the integrity and the authenticity of the user application code and data images from the installation slot.
5. If successful, OEMiRoT saves the new image counters in the NV counter region for the antirollback verification, then executes the user application. The jump to the user application code is done using a service from the bootloader located in the system flash memory. This service activates the HDP (HDP1_ACCDIS different from 0xA3 and HDP1EN different from 0xB4; refer to the STM32U0 reference manual for more information) outside of the HDP area.
6. In the case of control failure (bad integrity or bad authenticity), the local loader programmed in the user flash memory is started, to download a new image.

Information

For security robustness, when OEMiRoT jumps into the user application, the MPU is configured to ensure that only the user application code area is allowed execution (the MPU configuration controls the execution surface). It is the responsibility of the user application to reconfigure the MPU to fulfill the security needs.

1.3.2 Swap mode

The following figure illustrates the Secure Boot and Secure Update process by showing all steps required to boot the user application code image:

1. At reset, boot is forced on OEMiRoT when BOOT_LOCK is set to 1.
2. OEMiRoT checks if a new user application code and/or new data images are stored in the download slot. If so, OEMiRoT decrypts them and checks their integrity, authenticity, antirollback counter, and dependency version.
3. If successful, the new images are decrypted and swapped with the installed images, using the scratch area.
4. OEMiRoT checks the integrity and authenticity of the user application code and data images from the installation slots.
5. If successful, OEMiRoT executes the user application. The jump to the user application code is done using a service from the bootloader located in the system flash memory. This service activates the HDP (HDP1_ACCDIS different from 0xA3 and HDP1EN different from 0xB4; refer to the STM32U0 reference manual for more information) outside of the HDP area.
6. In the case of control failure (bad integrity or bad authenticity), the local loader programmed in the user flash memory is started, to download a new image.
7. If the user application execution validates the new images, OEMiRoT saves the new image counters in the NV counter region for the antirollback verification at the next reset.
8. If the user application execution does not validate the new images, the images are swapped back (reverted) at the next reset.

Information

For security robustness, when OEMiRoT jumps into the user application, the MPU is configured to ensure that only the user application code area is allowed execution (the MPU configuration controls the execution surface). It is the responsibility of the user application to reconfigure the MPU to fulfill the security needs.

2 Feature list

The main features of OEMiRoT are:

• Software cryptography operations:

1. ECDSA-P256 asymmetric cryptography for image authentication.
2. SHA256 cryptography for image integrity check.
3. AES-CTR-128 cryptography for image encryption with symmetric key encrypted in ECIES-P256 provided in the image itself. Refer to the chapter on image generation for more details.

• Accelerated boot with 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 a reference for the next boot. At this next boot, signature verification is skipped if the SHA256 of the image matches the reference stored in the Hash Ref region in the user flash memory (refer to flash memory layout for more). This feature brings performance optimization (under the MCUBOOT_USE_HASH_REF compilation switch).

• Antirollback version check based on the image counter stored in the NV counters region in the user flash memory (see also flash memory layout).

• Configurable slot mode:

1. Single primary slot mode, enabling the maximization of the image size. The downloaded image is stored in the same memory slot as the installed image. The new downloaded image overwrites the previously installed image.
2. Primary and secondary slots mode, enabling safe image programming. The downloaded image and the installed image are in different memory slots.

• Image installation is resistant to asynchronous power-down and reset, in primary and secondary slot mode configuration.

• Data image: an optional data image can be activated or deactivated through the MCUBOOT_DATA_IMAGE_NUMBER define. A dependency can be managed to synchronize the installation of both code and data images (see also OEMiRoT_Code_image xml file format).

• Integration of the full entropy TRNG source (RNG hardware peripheral) for random delay generation.

• Configurable firmware image upgrade strategy, for primary and secondary slots mode:

1. Overwrite strategy, in which the image in the secondary slot overwrites the image in the primary slot.
2. Swap strategy, in which 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.

• Memory configuration: all slots are located inside the internal user flash memory (primary and secondary slots for code and data images).

• Integration of hardware security peripherals and mechanisms to implement a root of trust. RDP, BOOT_LOCK, MPU, WRP, HDP, and TAMPER are combined to achieve the highest security level. When connected to the hardware board, the external tamper can be activated with the TAMPER_ENABLE define.

• Image generation with the STM32TrustedPackageCreator tool, included with STM32CubeProgrammer.

Features configurability:

Feature	Configuration	Compilation switch
Image upgrade strategy	Overwrite-only mode Swap mode	MCUBOOT_OVERWRITE_ONLY
Slots mode	Single primary slot mode Primary and secondary slots mode	MCUBOOT_PRIMARY_ONLY
Flash memory configuration	Code image slots Data image slots	MCUBOOT_OVERWRITE_ONLY MCUBOOT_DATA_IMAGE_NUMBER
Antitamper	None Internal tampers only Internal and external tampers	TAMPER_ENABLE
Project phase	Development mode Production mode	OEMIROT_DEV_MODE

3 Flash memory layout

In STM32CubeU0, the OEMiRoT relies on the flash memory layout, which defines several regions:

• HASH REF region: the region where the SHA256 references are stored (one reference per image).
• NV counters region: the region where OEMiRoT_Boot gets nonvolatile information about last-installed image (code and data) versions for the antirollback feature.
• SCRATCH region: the region used by OEMiRoT_Boot to store the image data temporarily during the image swap process (not used in overwrite-only mode).
• Integrator personalized data region: the region to personalize OEMiRoT secret keys (authentication and encryption keys).
• OEMiRoT_Boot code region: the region to program the OEMiRoT_Boot code binary that manages the "Secure Boot" and "Secure Firmware Update” functions.
• Application installation (primary) slot region: the region to program the image code and data after installation.
• Application download (secondary) slot region: the region to program the "new" image code and data candidate for installation.
• Loader code region: the region to program the OEMiRoT_Loader code binary.

The flash memory layout is fixed but can be updated, especially when:

• There is no data image;
• The image upgrade strategy is overwrite;
• The local loader is not required.

If the flash memory layout is modified, the MPU region configuration must be updated, taking into account these constraints on the Cortex^®-M0+ MPU:

• The region start address is a multiple of the region size.
• Each region can be divided into eight subregions.
• A maximum of eight regions can be defined.

The following figure shows the flash memory layout.

4 Provisioning process

The product provisioning to activate and configure OEMiRoT is done by following these four steps:

1. Selecting the RDP level.
2. Building the OEMiRoT_Boot and OEMiRoT_Loader projects.
3. Generating the user application code and data images.
4. Programming the option bytes, OEMiRoT_Boot binary, OEMiRoT_Loader binary, and application images in the device.

The image below shows a visual representation of these steps.

Information

The Firmware/Projects/NUCLEO-U083RC/ROT_Provisioning/OEMiRoT folder contains a set of scripts guiding the user through the provisioning process. Refer to the getting started with STM32U0 security wiki page for more information.

5 Image generation

OEMiRoT manages images based on the MCUBoot format, including:

• A header;
• The encrypted firmware binary;
• Some metadata information (TLV format: tag length value) allowing the control of the image (SHA256, ECDSA-P256 signature, etc.).
• A magic word to trigger the installation at the end of the slot.

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

The PC tool STM32TrustedPackageCreator is provided to generate both code and data images. These images are encrypted and signed using the configured keys.

OEMiRoT_Code_Image.xml/OEMiRoT_Data_Image.xml contains all parameters driving the image generation, such as:

• The authentication and encryption keys.
• The version.
• The dependency with a code or data image if a synchronized installation is required.

OEMiRoT_Code_Image.xml/OEMiRoT_Data_Image.xml can be edited with STM32TrustedPackageCreator to modify the version and the dependency parameters. Keys are directly inherited from the OEMiRoT_Config.xml file.

The following figure shows the code image generation (the same applies for data image generation):

6 Appendix

6.1 OEMiRoT startup sequence

Performance measured at 48 MHz:

	32 Kbytes	64 Kbytes	128 Kbytes
Boot time	216 ms	345 ms	595 ms

6.2 Application development phase

During the development phase, it is recommended to compile the OEMiRoT_Boot project with OEMIROT_DEV_MODE defined and to select RDP level 0 during the provisioning process:

When OEMIROT_DEV_MODE is defined:

• Logs are displayed in Tera Term during the OEMiRoT_Boot project execution.
• An infinite loop is executed instead of a reset in the Error_Handler() function.
• A tamper event is cleared at startup when required. No need to power off/on the board to clear this event.
• RDP level 0 can be selected during the provisioning process.

At the end of the development phase, OEMIROT_DEV_MODE must be disabled and the RDP level 2 must be selected during the provisioning process to achieve the highest security level.

6.3 OEMiRoT_Code_image xml file format

Parameter	Updatable	Description
Authentication key	Yes	Private key. Can be updated with keygen.bat.
Write option	Automatic	Image upgrade strategy: overwrite, swap. This value is updated during the postbuild operation based on MCUBOOT_OVERWRITE_ONLY definition from flash_layout.h.
Encryption key	Yes	Public key. Can be updated with keygen.bat.
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/data area size	Automatic	Firmware/data area size. This value is updated during the postbuild operation based on the slot configuration from flash_layout.h.
Header size	No	0x400 bytes.
Padding header	No	Padding the header with 0xFF to fulfill the 0x400 bytes.
Dependency with data image	Yes	This parameter must be enabled when the installation of both data and code images must be synchronized.
Version	Yes	x.y.z firmware image version.
Security counter	No	The security counter value is automatically generated based on version information.
Align	No	The size of the encrypted binary generated is a multiple of 16 bytes.
Firmware binary input file	Automatic	Location of the firmware binary file. This parameter is updated during the provisioning process based on information from the env.bat file.
Image output file	Yes	Location of the encrypted image generated. If changed, the provisioning scripts must be updated accordingly.

The same applies for OEMiRoT_Data_Image.xml.