A device deployed in the field operates in an untrusted environment and it is therefore subject to threats and attacks. To mitigate the risk of attack, the goal is to allow only authentic firmware to run on the device. Allowing the update of firmware to fix bugs, or introducing new features or countermeasures, is commonplace for connected devices, but it is prone to attacks if not executed in a secure way.
This article gives an overview of the OEMiRoT solution integrated in STM32H7S. How to use it, step by step, is described in wiki pages How to start with OEMiRoT on STM32H7S
1. OEMiRoT presentation
1.1. Overview
OEMiRoT stands for OEM immutable (unchangeable) Root of Trust and acts as a first boot stage. OEMiRoT is an example is 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 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 that a new firmware image is available. It checks its authenticity, then checks the integrity of the code 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 and sensitive data (such as a secret key), and the execution flow, in order to resist against possible attacks. On STM32H7S, the security strategy is based on (see also STM32H7RS Reference manual for more description):
- 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 (see DA wiki article).
- Boot configuration:
- 1 boot stage: IROT_SELECT option byte must configured to OEMiRoT to boot on 0x08000000 where must be located the OEMiRoT vector table.
- 2 boot stages: IROT_SELECT option byte must configured to STiRoT to boot on system flash.
- Antitamper protection: 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 configured to limit the surface execution to the code area during OEMiRoT_Boot project execution then extended to the application code area 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 HDPL2 making the OEMiRoT_Boot project code no longer accessible.
- OBkeys: HDPL1 OBkeys (HDPL2 OBkeys for OEMuRoT) are a protected and isolated enclave used to store secrets such as encryption and authentication cryptographic keys. This enclave is no longer accessible when switching from HDPL1 to HDPL2 or to HDPL3. Data stored in this enclave is encrypted with a HUK derivate key.
- WRP: this protection is set on the whole OEMiRoT_Boot project code area to make it immutable.
- RAM ECC: ECC is a mechanism to prevent external attacks. A reset is generated in case of ECC detection.
Note: WRP and HDP protections cannot be activated when OEMUROT_ENABLE switch is activated.
Secure software coding techniques such as doubling critical tests, doubling critical actions, checking parameter values, and testing a flow control mechanism, are implemented to resist basic fault-injection attacks.
The OEMiRoT_Boot application example is delivered with following cryptographic scheme:
- ECDSA-256 asymmetric cryptography for image authenticity verification, AES-CTR-128 symmetric cryptography with key ECIES-P256 encrypted for image confidentiality, and SHA256 cryptography for image integrity check.
- AES-ECB-128 symmetric cryptography for firmware encryption using MCE after installation in external flash memory.
- AES-ECB-128 symmetric cryptography for firmware encryption using MCE after transfer in execution slot in external RAM memory (load and run configuration).
1.3. OEMxRoT activation
On STM32H7S, OEMxRoT activation is done by:
- Configuring the IROT_SELECT option to boot on OEMiRoT or STiROT.
- Configuring OEMxRoT secrets. authentication and encryption keys used by OEMxRoT.
- Building OEMiRoT_Boot binary in the selected configuration (OEMiRoT or OEMuRoT).
All these operations operations are part of the provisioning process. OEMxRoT is activated in two different uses cases:
- One boot stage, OEMiRoT: OEMiRoT_Boot project binary is built using OEMiRoT configuration. OEMiRoT directly manages the user application.
- Two boot stages, STiRoT + OEMuRoT: OEMiRoT_Boot project binary is built using OEMuRoT configuration. STiROT integrated inside the STM32H7S manages an updatable boot stage, OEMuROT, located in the user flash memory which manages the user application.
See also Secure Boot for STM32H7RS article
1.3.1. One boot stage: OEMiRoT
OEMiRoT is generated by compiling OEMiRoT_Boot project with OEMUROT_ENABLE switch de-activated.
At reset, OEMiRoT, located in the user flash memory, is the first application 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 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 state 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, OEMuRoT decrypts it and controls its integrity and its authenticity. If successful, the image is copied in the user application installation slot. The image is re-encrypted by the MCE with OEMuRoT encryption keys.
- OEMiRoT controls the integrity and the authenticity of the user application image from the installation slot of the external flash memory. If successful, OEMiRoT executes it from external flash memory or from RAM memories. In this case an additional copy is made before its execution.
Note: 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.
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 the first application executed in temporal isolation 1, HDPL1. Refer to [2] for more details on temporal isolation levels. After a successful verification of the authenticity and the integrity of OEMuROT code image, STiROT executes OEMuROT in HDPL2 and 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 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 state 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), 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 and controls its integrity and its authenticity. If successful, the image is copied in the user application installation slot. The image is re-encrypted by the MCE with OEMuRoT encryption keys.
- 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 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 for the external memory. Refer to [5] for more details on OEMuRoT execution modes.
Note: To avoid any risk of attack, when OEMuRoT 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 OEMiRoT/OEMuRoT are:
- Asymmetric cryptography for image authentication based on EC-256.
- SHA256 cryptography for image integrity check.
- Retention of a hash reference (boot time acceleration). Image verification consists mainly of computing a hash over the image (integrity check) and then generating a signature of this hash (authentication check). With this feature, it is possible to avoid the computation of a signature by referencing the reference hash stored in OBKeys. This feature is performance optimization (under the MCUBOOT_USE_HASH_REF define) and is efficient from the second boot.
- AES-CTR cryptography for image encryption, with symmetric key encrypted in ECIES-P256 provided in the image itself.
- AES-ECB cryptography for firmware encryption with MCE after installation in external flash and after transfer in external RAM memory before its execution (load and run configuration). In both cases, a specific key derived from HUK is used.
- Anti rollback version check based on information saved in OBkeys.
- Image programming resistant to asynchronous power down and reset.
- Integration of the full entropy TRNG source (RNG hardware peripheral) for random numbers generation (boot seed generation, tamper protection) or random delays (FIH).
- 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, else, at the next boot, the images are swapped back.
- Memory configuration:
- Download and installation slots in external flash memory. Installation slot is encrypted with MCE based on specific key derived from HUK.
- Execution slot from external flash memory or from internal RAM, or external RAM memories (load and run configuration). External RAM memory slot is encrypted with MCE based on specific key derived from HUK. Load and run capability is configured with OEMIROT_LOAD_AND_RUN define.
- 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 achieve the highest security level. When connected on the HW board, external tamper can be activated with OEMIROT_TAMPER_ENABLE define.
- IDE integrated image tool to prepare the image, provided both as a Windows® executable and a Python™ source code.
- Activation of ICACHE peripheral for internal flash memory access to improve boot time performance.
Features configurability in OEMiRoT based example in the STM32CubeH7RS MCU Package.
| Feature | OEMiRoT | OEMuRoT |
|---|---|---|
|
OEMiRoT/OEMuRoT generation |
OEMUROT_ENABLE switch deactivated |
OEMUROT_ENABLE switch activated |
|
Image upgrade strategy |
|
|
|
Flash memory configuration |
|
|
|
Security peripherals |
|
|
|
Antitamper |
|
|
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 binary region: region to program the OEMiRoT_Boot code binary that manages the functions "Secure Boot" and "Secure Firmware Update”.
- Installation (primary) slot region: region to program the image of an “active” firmware after installation.
- Download (secondary) slot region: region to program the image of a “new” firmware, candidate for installation.
- Execution slot region when load and run feature is activated.
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 |
| IMAGE_PRIMARY_RUN_PARTITION_OFFSET | NA | 0x00000000 | 0x24040000 |
| FLASH_AREA_SCRATCH_OFFSET | 0x00400000 | 0x00400000 | 0x00040000 |
| FLASH_AREA_SCRATCH_SIZE | 0x00010000 | 0x00010000 | 0x00010000 |
| FLASH_AREA_BL2_OFFSET | 0x08000000 | 0x08000000 | 0x08000000 |
| FLASH_AREA_BL2_SIZE | 0x00010000 | 0x00010000 | 0x00010000 |
| BL2_RAM_OFFSET* | 0x24000000 | 0x24000000 | 0x24000000 |
| BL2_RAM_SIZE* | 0x00020000 | 0x00020000 | 0x00020000 |
| BL2_DATA_OFFSET** | 0x20000000 | 0x20000000 | 0x20000000 |
| BL2_DATA_SIZE** | 0x00020000 | 0x00020000 | 0x00020000 |
| RAMECC_HANDLER_START | 0x30004000 | 0x30004000 | 0x30004000 |
| RAMECC_HANDLER_SIZE | 0x40 | 0x40 | 0x40 |
| CONF_FLAG_SIZE | 0x20 | 0x20 | 0x20 |
*: specific to OEMiRoT
**: specific to OEMuRoT
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.
- Programing of the OBkeys, the option bytes, the application image in the device
Note: A set of scripts is provided in Firmware/Projects/STM32H573I-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. OEMuRoT provisioning process
The product provisioning to activate and configure OEMuRoT is done following the three steps below:
- Configuration of STiRoT. At this stage, the number of images managed (firmware code image only), the location of the image, and the STiRoT cryptographic keys are defined. Refer to article.
- Configuration of OEMuRoT. At this stage, the OEMuRoT cryptographic keys for authentication and encryption are defined.
- Generation of the OEMuRoT code images as well as the application code image.
- Programing 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/STM32H573I-DK/ROT_Provisioning/STiROT_OEMuROT folder. It guides the user all along the provisioning process. Refer to How to start with OEMuRoT on STM32H7S article.
4.3. OEMiRoT/OEMuRoT OBkeys configuration file
OEMiRoT/OEMuRoT OBkeys 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 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. Images generation
OEMiRoT manages an image 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, encryption key …), and
- 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 firmware and data images. These images are encrypted and signed using the keys configured in OBkeys configuration file. OEMiROT_Code_Image.xml contains all the parameters driving the image generation such as:
- The authentication and encryption keys,
- The version.
OEMiROT_Code_Image.xml can be edited with STM32TrustedPackageCreator in order to modify the version. Keys are directly inherited from OEMiROT_Config.xml file.
The following figure shows the firmware image generation: thumb