OEMiSB for STM32U0

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

How to use it, step by step, is described in wiki pages How to start with OEMiSB on STM32U0.

1. OEMiSB presentation

1.1. Overview

OEMiSB stands for OEM immutable (unchangeable) Secure Boot. OEMiSB offers only one 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 integrity of the user application code before every execution.

1.2. Protection measures and security strategy

A set of measures and system-level strategies are needed for protecting critical operations and sensitive data (such as the SHA256 of the application), and the execution flow, in order to resist against possible attacks. 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 on the JTAG port, the RDP level is regressed to level 1. The OEM2 password must first have been provisioned when the RDP level is 0. Refer to RDP for U0 wiki article for more details.
• Boot lock: BOOT_LOCK option byte is set to establish a chain of trust, by forcing the system to boot from the user flash memory in 0x08000000.
• 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 OEMiSB_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: when the HDP secure hide protection is activated, any accesses to the protected flash memory area (fetch, read, programming, erase) are rejected. All the code and secrets located inside the protected flash memory area are fully hidden. In the OEMiSB example, the system is configured to hide the OEMiSB_Boot code, and the data (SHA256) area located in flash memory (Refer to the Memory layout for more details on HDP area) just before launching the verified user application.
• WRP: write protection is used to protect OEMiSB_Boot code from external attacks or even internal modifications such as unwanted writings/erase operations on critical code/data. In the OEMiSB example, the system is configured to make the OEMiSB_Boot code, and data (SHA256) as immutable.

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

Secure software coding techniques such as doubling critical tests, doubling critical actions, random delay, checking parameter values, and flow control mechanism, are implemented to resist to double synchronized fault-injection attacks.

A SHA256 is implemented to verify the integrity of the user application. This cryptography operation is done in software (no hardware acceleration).

1.3. OEMiRoT activation

On STM32U0, OEMiSB is done by:

• Configuring the BOOT_LOCK to 1
• Configuring the SHA256 and the size of the user application

The following figure illustrates the secure boot process by showing all the steps required to boot the user application:

1. At reset, boot is forced on OEMiSB when BOOT_LOCK set to 1.
2. OEMiSB calculated the SHA256 on the application code using the application size parameter.
3. If the result matches the SHA256 stored as reference and if the padding area is fulfilled with 0xFFFFFFFF, OEMiSB jumps into the application code. The jump to the application code is done using a service from bootloader located in the system flash memory. This service activates the HDP (HDP1_ACCDIS different from 0xA3 and HDP1EN different from 0xB4, see also STM32U0 Reference manual) out of the HDP area.

Note: A verifier !!!!!!!!!!!!!!!!!!!!!To avoid any risk of attack, when OEMiRoT jumps into the user application, the MPU is configured to ensure that only the user application code area is allowed to be executed (execution surface controlled via MPU configuration). It is the user application responsibility to reconfigure the MPU to fit with its security needs.

2. Features list

The main features of the OEMiSB are:

• SHA256 cryptography for application code integrity check.
• Configurable data area : from 0 Kbytes to 16 Kbytes

3. Flash memory layout

The STM32CubeU0 OEMiRoT relies on flash memory layout defining several regions:

• HASF REF region: region where the SHA256 references are stored (one reference per image).
• NV counters region: region where OEMiRoT_Boot gets nonvolatile information about last installed images (code and data) versions for the antirollback feature.
• SCRATCH region: 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: region to personalize OEMiRoT secrets (authentication and encryption keys).
• OEMiRoT_Boot code region: region to program the OEMiRoT_Boot code binary that manages the functions "Secure Boot" and "Secure Firmware Update”.
• Application installation (primary) slot region: region to program the image code and data after installation.
• Application download (secondary) slot region: region to program the "new" image code and data, candidate for installation.
• Loader code region: 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 regions configuration must be updated taking into account the constraints on Cortex M0+ 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
• a maximum of 8 regions can be defined

Flash memory layout is as follow:

4. Provisioning process

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

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

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

5. Images generation

OEMiRoT manages images at 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 signature, encryption key …),
• a magic to trigger the installation.

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

A PC tool STM32TrustedPackageCreator is provided to generate both code and data images. These images are encrypted and signed using the keys configured. OEMiRoT_Code_Image.xml / OEMiRoT_Data_Image.xml contains all the parameters driving the image generation such as:

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

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

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

6. Appendix

6.1. OEMiRoT start-up sequence

Performance measured @ xx MHz:

	32 KBytes	64 KBytes	128 KBytes
Boot time	x ms	x ms	x ms

6.2. Application development phase

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

• When OEMIROT_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.
• RDP level 0 can be selected during provisioning process.

At the end of the development phase, OEMIROT_DEV_MODE must be disabled and the RDP level 2 must be selected during 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 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	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	Security counter value automatically generated based on version information.
Align	No	16 bytes alignment
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 OEMiRoT_Data_Image.xml