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:
- 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.
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). Refer to [features on STM32H7RS MCUs] for more details on temporal isolation levels. 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 Secure Boot and Secure Firmware Update application 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 (MCE) after installation in external flash and after transfer in external RAM memory for 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.