OEMuRoT for STM32N6

This article gives an overview of the OEMuRoT solution integrated in STM32N6 devices.

For a step-by-step user guide, go to the wiki pages on How to start with OEMuRoT on STM32N6 MCUs.

List of applicable products:

Type	Products
Microcontroller	STM32N645xx, STM32N647xx, STM32N655xx, STM32N657xx

1. OEMuRoT presentation

1.1. Overview

OEMuRoT stands for OEM updatable Root of Trust and acts as a second boot stage right after immutable BOOTROM code. OEMuRoT is an example based on the MCUboot open-source software (refer to MCUboot) provided with STM32CubeN6. OEMuRoT offers two services:

• The Secure Boot (root of trust service) is an updatable code, which is always executed after BOOTROM code. It 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 updatable code that detects new firmware image candidate. It checks its version (version downgrade prevention), authenticity, and integrity before installing it after decryption.

BOOTROM can be classified as an ST immutable Root of Trust (STiROT) and acts as a first boot stage.

2. Protection measures and security strategy

Cryptography ensures integrity, authentication, and confidentiality. However, the use of cryptography alone is not sufficient: 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 STM32N6, the security strategy is based on:

• Boot entry point: The Cortex-M55 always boots from the start of an on-chip ROM. This BOOTROM code is an immutable Root of Trust used to authenticate and decrypt images loaded into internal RAM from external flash memory, or through UART, USB.
• MCE*:The MCE implements an on-the-fly encryption/decryption of data to/from external memories: flash memory and SRAM.
• Device life cycle: product state locked must be selected in order to ensure that the JTAG debugger cannot access the device and that only trusted applications can be launched by the BOOTROM.
• Anti-tamper protection: the anti-tamper protection is used to protect sensitive data from physical tampering. The anti-tamper protection is activated at the start of OEMuROT_Boot project and remains active during OEMuROT_Appli execution. In case of tamper detection, sensitive data and caches are immediately erased, and a reboot is forced.
• 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 OEMuROT_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.
• BSEC: The boot and security control peripheral manages access to an embedded one time programmable (OTP) array of fuses that stores secrets such as encryption and authentication cryptographic keys and antirollback counters.

(*): available on STM32N657xx and STM32N647xx.

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

2.1. OEMuRoT activation

On STM32N6, OEMuRoT activation is done by:

• Configuring secrets: authentication and encryption keys used by OEMuRoT.
• Programing the OEMuROT_Boot binary in the external memory flash.

All these operations are part of the provisioning process. For more details, Refer to How to start with OEMuRoT on STM32N6 MCUs.

The OEMuRoT includes a post-build script that uses STM32 tools to sign and encrypt the generated binary to ensure compatibility with the BOOTROM. The flash mode must be selected after the programming step to enable the execution of the OEMuRoT stored in the external flash memory.

See also Security:BootRom for STM32N6 for more details on BOOTROM.

2.1.1. Overwrite upgrade strategy

At reset, BOOTROM, located in the STM32N6 on-chip boot ROM IP, is executed in temporal isolation 0 (HDPL0). After a successful decryption and verification of the authenticity and the integrity of the OEMuRoT image, BOOTROM executes the OEMuRoT in HDPL1.

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:

1. BOOTROM is the first software executed. It checks the integrity and the authenticity of OEMuRoT.
2. If verification is successful, BOOTROM decrypts the OEMuRoT code located in external flash and stores it in internal RAM right before executing it.
3. 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 counter. If successful, the image is decrypted and copied in the user application installation slot using MCE encryption*. The SAES (secure AES engine) uses an HDPL input when performing a derivation of the HUK to create the DHUK (derived-HUK) which make the key used by MCE unrecoverable at application level.
4. OEMuRoT controls the integrity and the authenticity of the user application image from the installation slot located in the external flash memory. 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. Refer to the Features list for more details on OEMuRoT execution modes.

(*): MCE encryption is only available on STM32N657xx and STM32N647xx.

Note:

1. 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.
   

This following figure demonstrates the overwrite upgrade process in which the image in the secondary slot overwrites the image in the primary slot. To simplify the example, data images are disabled and a unique application is used.

1. OEMuRoT checks if a new candidate image is stored in the download slot area. A magic to trigger the installation must be detected (see also Images generation). If any, OEMuRoT decrypts it then controls its integrity, anthenticity, antirollback counter and its dependency version.
2. If successful, the image is decrypted and copied in the application installation slot.
3. OEMuRoT controls the integrity and the authenticity of the application image located in installation slot.
4. If successful, OEMuRoT executes it from external flash memory or from external/internal RAM memories. An additional copy is necessary when executing from RAM memories.

Note: For security robustness, when OEMuRoT jumps into the user application, the MPU is configured to ensure that only the secure application code area is allowed to be executed (execution surface controlled via MPU configuration). It is the secure application responsibility to reconfigure the MPU to fit with its security needs.

2.1.2. Swap upgrade strategy

When OEMuRoT is generated with the swap upgrade strategy activated, the scratch buffer is used two times during the secure firmware update process:

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

During the swap process, all download slots are encrypted using mcuboot encryption, and installation slots are encrypted with MCE using a derived hardware unique key.

The following figure illustrates the scratch buffer usage with OEMuRoT :

In the swap upgrade strategy, the antirollback counter 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 OEMuRoT start-up sequence for more details.

The scratch area size can be tuned according to the expected number of upgrades in the product life:

• Number_of_upgrades = Number_of_erase_cycles / (Image_size / Scratch_size)
• Example: 1000 firmware image possible updates with the following inputs:
  • Number_of_erase_cycles = 10.000 programming cycles
  • Image_size = 640 Kbytes firmware image
  • Scratch_size = 64 Kbytes

3. Features list

The main features of the OEMuRoT are:

• Hardware-accelerated cryptography operations with PKA, HASH, SAES*:
  • 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 Images generation for more details.
• MCE encryption*:
  • All external flash memory slots, except for secondary image slots, are encrypted using MCE with AES-CTR-256 derived hardware unique key.
  • All data stored in the external RAM are encrypted using MCE with AES-CTR-256 random key generated at every startup to maintains confidentiality.
• 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 a fixed location (so-called HASH REF). This feature brings performance optimization (under the MCUBOOT_USE_HASH_REF compilation switch).
• Antirollback counter check based on image counter stored in OTP fuses.
• Image installation resistant to asynchronous power down and reset.
• Flexible number of data images : no data image, one data image (secure or nonsecure) or two images (secure and nonsecure) with the policies defined on application images (authenticity and integrity verification, antirollback version check, decryption).
• 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:

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

1. Download slot in external flash memory.
2. Installation slot in external flash memory.

• Load and run execution mode capability. In addition to the standard execution mode (in place), the user application can be executed:

1. From external RAM memory
2. From internal RAM memory. In this configuration, the size of the application is limited. During the load of the application in internal RAM, OEMuRoT data, OEMuRoT code are also located in RAM.

• Debug authentication (DA) capability that allow user to open non-secure debug using a password.
• Image generation with STM32TrustedPackageCreator tool delivered within STM32CubeProgrammer.

The following table identifies the cryptography operations hardware-accelerated on the STM32N6 devices:

Hardware accelerator	Operation	STM32N657xx	STM32N655xx	STM32N647xx	STM32N645xx
PKA	ECDSA
SAES	AES
HASH	SHA256
RNG	Random generator
MCE	On-the-fly encryption/decryption

Features configurability:

Feature	OEMuRoT	Configuration switch	Configuration file
Image upgrade strategy	Overwrite only mode Swap mode	MCUBOOT_OVERWRITE_ONLY	OEMuROT_Boot\Inc\flash_layout.h
Load and run execution modes configuration	Execution from external flash memory Execution from internal RAM memory Execution from external RAM memory	OEMUROT_LOAD_AND_RUN	OEMuROT_Boot\Inc\flash_layout.h
Number of secure data image	S data image available S data image not available	MCUBOOT_S_DATA_IMAGE_NUMBER	OEMuROT_Boot\Inc\flash_layout.h
Number of non-secure data image	NS data image available NS data image not available	MCUBOOT_NS_DATA_IMAGE_NUMBER	OEMuROT_Boot\Inc\flash_layout.h
Anti-tamper protection	None Internal tamper	OEMIROT_TAMPER_ENABLE	OEMuROT_Boot\Inc\boot_hal_cfg.h
Project phase (Application development phase)	Development mode Production mode	OEMUROT_DEV_MODE	IDE preprocessor symbols
Cryptography type	HW accelerated cryptography Pure SW cryptography	BL2_HW_ACCEL_ENABLE* MCUBOOT_USE_MCE*	OEMuROT_Boot\Inc\mcuboot_config\mcuboot_config.h OEMuROT_Boot\Inc\flash_layout.h

(*): available on STM32N657xx and STM32N647xx

4. Memories layout

The STM32CubeN6 OEMuRoT relies on external memory layout that specifies multiple regions:

• SCRATCH region: region used by OEMuROT_Boot to store the image data temporarily during the image swap process (not used in overwrite-only mode).
• HASH REF region: region where the SHA256 references are stored (one reference per image).
• OEMuRoT code region: region to program the OEMuROT_Boot code binary that manages the functions "Secure Boot" and "Secure Firmware Update”.
• Secure application installation (primary) slot region: region to program the image of an “active” secure application after installation.
• Secure data installation (primary) slot region: region to program the image of an “active” secure data after installation.
• Non-secure application installation (primary) slot region: region to program the image of an “active” non-secure application after installation.
• Non-secure data installation (primary) slot region: region to program the image of an “active” non-secure data after installation.
• Secure application download (secondary) slot region: region to program the image of a “new” secure application, candidate for installation.
• Secure data download (secondary) slot region: region to program the image of a “new” secure data, candidate for installation.
• Non-secure application download (secondary) slot region: region to program the image of a “new” non-secure application, candidate for installation.
• Non-secure data download (secondary) slot region: region to program the image of a “new” non-secure data, candidate for installation.

External flash memory layout is as follow:

The OEMuROT code secondary partition is available from STM32CubeN6 version 1.1.0.

RAM layout in Load & Run internal RAM configuration is as follow:

RAM layout in Load & Run external RAM configuration is as follow:

The following tables provides detailed descriptions of the OTP words used in the OEMuRoT context.

OTP words used for keys:

OTP words used for antirollback counters:

5. Provisioning process

5.1. OEMuRoT provisioning process

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

1. Programming OEMuROT keys in OTP fuses. This step should only be completed once since OTP fuses are permanently locked after programming and cannot be reprogrammed.
2. Configuration and generation of OEMuRoT.
3. Generation of application and data images.
4. Programming the binaries in the external flash.

Note: A set of scripts is provided in Firmware/Projects/STM32N6570-DK/ROT_Provisioning/OEMuROT folders. It guides the user all along the provisioning process. Refer to How to start with OEMuRoT on STM32N6 MCUs article.

6. Images generation

OEMuRoT manages application code and data images based on MCUBoot format including:

• a header,
• the encrypted application code or data binary.
• some metadata information (TLV format: Tags Length Value) allowing the control of the image (SHA256, ECDSA-P256 signature…).
• a trailer is reserved at the end of the slot, for the swap process, so that the image size (header + binary + TLV) is limited to the slot area size minus the trailer size. The trailer size depends on the image and flash memory properties.
• a magic to trigger the installation at the end of the slot.

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

A PC tool STM32TrustedPackageCreator is provided to generate the images. These images are encrypted and signed using OEMuRoT keys. OEMuROT_XX_Code_Image.xml and OEMuROT_XX_Data_Image.xml contains all the parameters driving the image generation such as:

• The Authentication and encryption keys.
• The version.
• The antirollback counter.
• The dependency with other image if a synchronized installation is required.

OEMuROT_XX_Code_Image.xml and OEMuROT_XX_Data_Image.xml can be edited with STM32TrustedPackageCreator in order to modify the version and/or the dependency information.

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

7. Appendix

7.1. OEMuRoT start-up sequence

Note: When no valid firmware image is installed a reset will be triggered in loop.

Performance measured @ 600 MHz in production mode (OEMUROT_DEV_MODE undefined) with EWARM toolchain :

Configuration	Typical user application boot time
	128 Kbytes	256 Kbytes	512 Kbytes	1 Mbyte	2 Mbytes
Execution from external flash	46 ms	70 ms	117 ms	221 ms	291 ms
Execution from external RAM memory	197 ms	247 ms	349 ms	553 ms	962 ms
Execution from internal RAM memory	164 ms	196 ms	259 ms	385 ms	NA

The measured time spans from the start of OEMuROT_Boot to the initiation of the non-secure application, with various sizes of both secure and non secure application. These measurements were carried out with MCE and hardware-accelerated cryptography. They are not applicable on devices without hardware acceleration. Moreover, the execution timing depends on the IDE compiler used (EWARM, MDK-ARM or STM32CubeIDE).

7.2. Application development and production phases

During development phase, it is recommended to compile OEMuROT_Boot project with OEMUROT_DEV_MODE defined:

• When OEMUROT_DEV_MODE is defined:

• Logs are displayed in tera term during OEMuROT_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.

At the end of the development phase, the integrator must:

1. Enable the production mode by disabling OEMUROT_DEV_MODE (managed as a preprocessor symbol of the OEMuROT_Boot).
2. Enable the OEMuRoT boot encryption in the postbuild script.
3. Change the product state to SECURED_LOCKED_PROVD. To lock the device refer to How to install a trusted application on STM32N6 MCUs

Once SECURED_LOCKED_PROVD state is set, development mode is disabled, and BOOTROM will only accept signed images. Therefore, it is crucial to provision BOOTROM secrets correctly.

7.3. Debug Authentication

The STM32CubeN6 OEMuRoT implements debug authentication feature which allows user to open non-secure debug at HDPL 2 using a password.

In order to access the debug authentication feature, the host sends the debug authentication password to the STM32 using DBGMCU registers. When the STM32N6 OEMuRoT

receives the password, it verifies that its hash corresponds to the one that is provisioned in OTP fuses and allows debugging in HDPL 2 non-secure mode if that is the case.

Once the debug is open, it remains until the next PowerOn reset.

Moreover, debug authentication includes a service called discovery, which allows the user to obtain information about the device, such as the product ID and product state.

The used protocol is defined by Arm®: ARM PSA ADAC V1.0. (Authenticated Debug Access Control).

7.4. OEMuRoT constraints

• Internal tamper 9 (fault generation for cryptographic peripherals (SAES, PKA, AES, RNG) is activated in confirmed mode, during OEMuRoT execution and remains activated when jumping into the user application. Reset is performed in case of tamper event detection during OEMuRoT execution.
• MPU is configured to allow only the user application code area to be executed when OEMuRoT jumps into the user application. It is the user application responsibility to reconfigure the MPU to fit with its security needs.

7.5. OEMuROT_S_Code_Image xml file format

Parameter	Updatable	Description
Authentication key	Yes	Private key file used to sign the firmware image, ensuring its authenticity and integrity.
Encryption key	Yes	Public key file used to encrypt the firmware image, ensuring its confidentiality.
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 OEMuROT_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 post-build of OEMuROT_Boot project compilation based on MCUBOOT_OVERWRITE_ONLY definition from flash_layout.h.
Version	Yes	x.y.z firmware image version.
Security Counter	Yes	Security counter value between 0 and 128. It is independent from image version number.
Align	No	The size of the encrypted binary generated is multiple of 16 bytes.
Number of scratch sectors	Automatic	Specifies the maximum number of sectors the image can span
Firmware binary input file	Automatic	Location of the firmware binary file. This parameter is updated during the post-build of the application project, based on information from the env.bat or env.sh file.
Image output file	Automatic	Location of the encrypted image generated. This parameter is updated during the post-build of the application project, based on information from the env.bat or env.sh file.

This format also applies on OEMuROT_NS_Code_Image.xml, OEMuROT_S_Data_Image.xml and OEMuROT_NS_Data_Image.xml.