This article gives an overview of the OEMiRoT and the OEMuRoT solutions integrated in STM32H5.
How to use it, step by step, is described in wiki pages How to start with OEMiRoT on STM32H5 and How to start with STiRoT-OEMuRoT on STM32H5
1. OEMiRoT/OEMuRoT presentation
1.1. Overview
OEMiRoT stands for OEM immutable (unchangeable) Root of Trust and acts as a first boot stage. OEMiRoT is an example based on the MCUboot open-source software (refer to mcuboot) provided with STM32CubeH5. 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 (Options Bytes), 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 new firmware image candidate. It checks its version (version downgrade prevention), authenticity and integrity 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 STM32H5, 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 (more details in Debug Authentication for STM32H5 wiki article).
- Boot configuration: BOOT_UBE, SECBOOT_LOCK , SECBOOTADD, NSBOOT_LOCK and NSBOOTADD option bytes are configured to establish a chain of trust, by forcing the system to boot on system flash memory (STiRoT) or user flash memory (OEMiRoT).
- Antitamper protection: the antitamper protection is used to protect sensitive data from physical attacks. 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 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 OEMiRoT_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: 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 key derived from HUK.
- WRP: write protection is used to protect OEMiRoT_Boot code from external attacks or even internal modifications such as unwanted writings/erase operations. In the OEMiRoT_Boot project, the system has been configured to make the OEMiRoT_Boot code as immutable.
- RAM ECC: RAM ECC is a mechanism to prevent external attacks. A reset is generated in case of RAM ECC detection.
See also STM32H5 Reference manual for more description on each feature.
Notes:
- WRP and HDP protections cannot be activated when OEMUROT_ENABLE switch is activated.
- There is no OBkeys on STM32H50x. Secrets such as encryption and authentication cryptographic keys are stored in the user flash under HDP protection. See also Memories layout
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.
1.3. OEMiRoT/OEMuRoT activation
On STM32H5, OEMiRoT/OEMuRoT activation is done by:
- Configuring the option bytes to boot on OEMiRoT or STiRoT.
- Configuring secrets: authentication and encryption keys used by OEMiRoT or OEMuRoT.
- Building OEMiRoT_Boot binary in the selected configuration (OEMiRoT or OEMuRoT).
All these operations operations are part of the provisioning process.
There are two different uses cases:
- One boot stage, OEMiRoT: OEMiRoT_Boot project binary is built in OEMiRoT configuration. OEMiRoT directly manages the user application binary.
- Two boot stages, STiRoT + OEMuRoT: OEMiRoT_Boot project binary is built in OEMuRoT configuration. STiRoT integrated inside the STM32H7S manages an updatable boot stage (OEMuRoT) located in the external flash memory, which manages the user application binary.
See also Secure Boot for STM32H5 article.
The following table identify the configuration available on STM32H5:
Boot | STM32H57x | STM32H56x | STM32H50x | |||
---|---|---|---|---|---|---|
Overwrite | Swap | Overwrite | Swap | Overwrite | Swap | |
OEMiRoT | X | X | X | X | X (primary only) | |
OEMuRoT | X | X |
1.3.1. One boot stage: OEMiRoT on STM32H50x
OEMiRoT is generated by compiling OEMiRoT_Boot project with OEMUROT_ENABLE switch de-activated.
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 user flash memory:
- In CLOSED or LOCKED product state with NSBOOT_LOCK and NSBOOTADD configured to boot on OEMiRoT located in the user flash memory, OEMiRoT is the first application executed in temporal isolation 1 (HDPL1).
- OEMiRoT checks if a new candidate image is stored in the application code and/or application data slots. A magic to trigger the installation must be detected (see also Images generation).
- If any, OEMiRoT decrypts it/them in place. See Features list for more details on PRIMARY_ONLY configuration slot mode.
- OEMiRoT controls the integrity, the authenticity and the antirollback counter of the application data and/or code images.
- If successful, OEMiRoT saves the new images counter in NV counters region for the antirollback verification then executes the user application in HDPL3. The jump to the user application code is done using a service from RSS located in the system flash memory. This service increases the temporal isolation (HDP level) HDPL1 to HDPL3 making the OEMiRoT_Boot project code and the secrets no longer accessible.
- In case of failure, the bootloader is started in HDPL3 to provide the capability to download a new image
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. One boot stage: OEMiRoT on STM32H56x / STM32H57x with overwrite strategy
OEMiRoT is generated by compiling OEMiRoT_Boot project with OEMUROT_ENABLE switch de-activated.
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 user flash memory. In this example, to simplify the presentation, the optional data image management is not activated (but data images are managed as code images) and the upgrade strategy is overwrite:
- In CLOSED or LOCKED product state with BOOT_UBE option byte configured to boot on OEMiRoT, OEMiRoT located in the user flash memory is the first application executed in temporal isolation 1 (HDPL1).
- OEMiRoT checks if a new candidate secure and/or nonsecure application(s) is/are stored in the download application code slots. A magic to trigger the installation must be detected (see also Images generation). If any, OEMiRoT decrypts it/them then controls its/their integrity, its/their authenticity, the antirollback version(s) and its/their dependency version.
- If successful, the image(s) is/are decrypted and copied in the application installation slot(s).
- OEMiRoT controls the integrity and the authenticity of the secure and nonsecure application images from the installation slots.
- If successful, OEMiRoT saves the new image(s) versionr in HDPL1 OBkeys for the antirollback verification then executes the secure application in HDPL3. The jump to the secure application code is done using a service from RSS located in the system flash memory. This service increases the temporal isolation (HDP level) HDPL1 to HDPL3 making the OEMiRoT_Boot project code and the data in HDPL1 OBkeys no longer accessible.
- In case of failure, the bootloader is started in HDPL3 to provide the capability to download a new image
Note: To avoid any risk of attack, when OEMiRoT 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.
1.3.3. One boot stage: OEMiRoT on STM32H56x / STM32H57x with swap strategy
OEMiRoT is generated by compiling OEMiRoT_Boot project with OEMUROT_ENABLE switch de-activated.
The following figure illustrates the secure boot and the secure update process by showing the steps (the first 2 steps are not represented but are the same as the ones with overwrite method) required to boot the user application code image located in the user flash memory. In this example to simplify the presentation the optional data image management is not activated (but data images are managed as code images) and the upgrade strategy is swap:
- In CLOSED or LOCKED product state with BOOT_UBE option byte configured to boot on OEMiRoT, OEMiRoT located in the user flash memory is the first application executed in temporal isolation 1 (HDPL1).
- OEMiRoT checks if a new candidate secure and/or nonsecure application(s) is/are stored in the download application code slots. A magic to trigger the installation must be detected (see also Images generation). If any, OEMiRoT decrypts it/them then controls its/their integrity, its/their authenticity, its/their antirollback version and its/their dependency version.
- If successful, the new image(s) is/are decrypted and swapped with the installed image(s). The scratch area is used during the swap process.
- OEMiRoT controls the integrity and the authenticity of the secure and nonsecure application images from the installation slots.
- If successful, OEMiRoT executes the secure application in HDPL3. The jump to the secure application code is done using a service from RSS located in the system flash memory. This service increases the temporal isolation (HDP level) HDPL1 to HDPL3 making the OEMiRoT_Boot project code and the data in HDPL1 OBkeys no longer accessible.
- In case of failure, the bootloader is started in HDPL3 to provide the capability to download a new image.
- If the new image(s) is/are validated during the user application execution, OEMiRoT saves the new image(s) version in HDLP1 OBkeys for the antirollback verification at next reset.
- If the new image(s) is/are not validated during the user application execution, the image(s) is/are swapped back (revert) at next reset.
Note: To avoid any risk of attack, when OEMiRoT 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.
1.3.4. Two boot stages: STiRoT + OEMuRoT on STM32H57x
OEMuRoT is generated by compiling OEMiRoT_Boot project with OEMUROT_ENABLE switch activated. OEMuRoT (updatable Root of Trust) acts as a second boot stage.
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 user flash memory. In this example the optional data image management is not activated and the upgrade strategy is overwrite:
- In CLOSED or LOCKED product state with BOOT_UBE option byte configured to boot on STiRoT, STiRoT is the first software executed in temporal isolation 1 (HDPL1).
- After executing the secure firmware update process (refer to STiRoT_for_STM32H5 article for more details on STiRoT), STiRoT controls OEMuRoT integrity and authenticity. If successful, STiRoT executes OEMuRoT in HDPL2.
- OEMuRoT checks if a new candidate secure and/or nonsecure application(s) is/are stored in the download application code slots. A magic to trigger the installation must be detected (see also Images generation). If any, OEMuRoT decrypts it/them then controls its/their integrity, its/their authenticity, the antirollback version and the dependency version.
- If successful, the image(s) is/are decrypted and copied in the secure and/or nonsecure application code installation slots.
- OEMuRoT controls the integrity and the authenticity of the secure and nonsecure application images from the installation slots.
- If successful, OEMuRoT saves the new image(s) version in HDPL2 OBkeys for the antirollback verification then executes the user application in HDPL3. The jump to the user application code is done using a service from RSS located in the system flash memory. This service increases the temporal isolation (HDP level) from HDPL2 to HDPL3 making the OEMiRoT_Boot project code and the data stored in HDPL2 OBkeys no longer accessible.
- In case of failure, the bootloader is started in HDPL3 to provide the capability to download a new image
Note: To avoid any risk of attack, 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.
1.3.5. Swap upgrade strategy
When OEMiRoT/OEMuRoT are 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.
The following figure illustrates the scratch buffer usage with OEMuRoT. The same exists for OEMiRoT :
Note : When the swap upgrade strategy is activated, the image version for antirollback control is stored in OBkeys only after reset.
2. Features list
The main features of the OEMiRoT/OEMuRoT are:
- 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 Image generation for more details.
- 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 next boot, the signature verification is skipped if the SHA256 of the image match the reference stored in OBkeys (STM32H56x, STM32H57x) or in Hash Ref region (STM32H503). This feature brings performance optimization (under the MCUBOOT_USE_HASH_REF compilation switch).
- Antirollback version check based on image version stored in OBkeys (STM32H56x, STM32H57x) or in NV counters region (STM32H503).
- Configurable slots mode:
- Single primary slot mode, which enables maximizing image size. The downloaded image is in the same memory slot as the installed image. The new downloaded image overwrites the previous installed image. The STM32H50x with 128 Kbytes of flash memory only support this configuration.
- Primary and secondary slots mode, which enables safe image programming. The downloaded image and installed image are in different memory slots.
- Image installation resistant to asynchronous power down and reset, in primary and secondary slots mode configuration.
- Flexible number of application images:
- Either one application image (secure and nonsecure binaries combined in a single image) with:
- Unique key pair
- Antirollback version check
- Or two application images (a secure image and a nonsecure image) with:
- Dedicated key pairs per firmware image
- Dedicated antirollback version check per firmware image
- Images version dependency management
- Flexible number of data images: 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).
- Data image: an optional data image can be activated/deactivated through MCUBOOT_DATA_IMAGE_NUMBER define. A dependency can be managed to synchronized installation of both code and data images .
- Integration of the full entropy TRNG source (RNG hardware peripheral) for random delays generation.
- Configurable slots mode:
- Single primary slot mode, which enables maximizing image size. The downloaded image is in the same memory slot as the installed image. The new downloaded image overwrites the previous installed image. The devices with 512 Kbytes of flash memory only support this configuration.
- Primary and secondary slots mode, which enables safe image programming. The downloaded image and installed image are in different memory slots.
- 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: all slots are located inside internal user flash (primary and secondary slots for secure and non-secure code and data images).
- Integration of hardware security peripherals and mechanisms in order to implement a root of trust. Product life cycle, BOOT_UBE, 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.
- Image generation with STM32TrustedPackageCreator tool delivered within STM32CubeProgrammer.
The following table identify the cryptography operations hardware-accelerated on the STM32H5 devices:
Hardware accelerator | STM32H57x | STM32H56x | STM32H50x |
---|---|---|---|
PKA |
X |
||
SAES |
X |
||
HASH |
X |
X |
X |
Features configurability:
Feature | OEMiRoT | OEMuRoT | Configuration switch |
---|---|---|---|
Boot project generation |
OEMiRoT generation |
OEMuRoT generation |
OEMUROT_ENABLE |
Image upgrade strategy |
|
|
MCUBOOT_OVERWRITE_ONLY |
Flash memory configuration |
|
|
MCUBOOT_OVERWRITE_ONLY MCUBOOT_DATA_IMAGE_NUMBER |
Load and run execution modes configuration |
|
|
OEMIROT_LOAD_AND_RUN |
Antitamper |
|
|
TAMPER_ENABLE |
Project phase (Application development phase ) |
|
|
OEMIROT_DEV_MODE |
OEMiRoT/OEMuRoT differencies:
Feature | OEMiRoT | OEMuRoT |
---|---|---|
WRP |
ON, immutable RoT |
OFF, updatable RoT |
HDP | activated on user flash to hide OEMiRoT code after execution | Not activated - OEMuRoT executed in internal RAM |
Execution environment | user flash - HDPL1 | internal RAM - HDPL2 |
Area to store secrets (cryptographic keys) | HDPL1 OBkeys | HDPL2 OBkeys |
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 code region: region to program the OEMiRoT_Boot code binary that manages the functions "Secure Boot" and "Secure Firmware Update”.
- OEMiRoT_Boot volatile data: region used to locate internal variables and call stack, during OEMiRoT_Boot code execution.
- Application installation (primary) slot region: region to program the image of an “active” firmware after installation.
- Application download (secondary) slot region: region to program the image of a “new” firmware, candidate for installation.
- Application execution slot region when load and run feature is activated.
- iLoader code region: region to program the STiRoT_iLoader code binary responsible to transfer the image from external flash to RAM for STiROT (specific to STiRoT/OMEuRoT use case).
- Image confirmation flag and RAM ECC handle:
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 |
FLASH_AREA_2_OFFSET | 0x00200000 | 0x00200000 | 0x00020000 |
FLASH_AREA_2_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
If the definition of the FLASH_AREA_0 or FLASH_AREA_2 is modified (offset or size), 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
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.
- Programming of the OBkeys, the option bytes, the application image in the device
Note: A set of scripts is provided in Firmware/Projects/STM32H7S78-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 four steps below:
- Configuration of STiRoT. At this stage, the location of the image, and the STiRoT cryptographic keys are defined. Refer to How to start with STiRoT on STM32H7S article.
- Configuration of OEMuRoT. At this stage, the OEMuRoT cryptographic keys for authentication and encryption are defined.
- Generation of the OEMuRoT code image as well as the application code image.
- Programming 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/STM32H7S78-DK/ROT_Provisioning/STiROT_OEMuROT folder. It guides the user all along the provisioning process. Refer to How to start with STiRoT-OEMuRoT on STM32H7S article.
4.3. OEMiRoT/OEMuRoT configuration file
OEMiRoT/OEMuRoT 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 obk file is encrypted and saved in HDPL1 OBkeys (OEMiRoT) or HDPL2 OBkeys (OEMuRoT).
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. Image generation
OEMiRoT/OEMuRoT 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, ECDSA signature, 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 the firmware code image. This image is encrypted and signed using the keys configured in OBkeys configuration file (OEMiRoT_Config.xml / OEMuRoT_Config.xml). OEMiRoT_Code_Image.xml / OEMuRoT_Code_Image.xml contains all the parameters driving the image generation such as:
- The authentication and encryption keys. Keys value inherited from OEMiRoT_Config.xml / OEMuRoT_Config.xml.
- The version. OEMiRoT_Code_Image.xml / OEMuRoT_Code_Image.xml can be edited with STM32TrustedPackageCreator in order to modify the version.
The following figure shows the firmware image generation:
6. Appendix
6.1. OEMiRoT/OEMuRoT start-up sequence
Note: When no valid firmware image is installed a reset will be triggered in loop. Debug authentication process must be executed to force the download of a new image. Refer to Debug Authentication for STM32H7RS article.
Performance measured @ 380 MHz:
Configuration | User application boot time | ||
---|---|---|---|
1 Mbytes | 2 Mbytes | 3 Mbytes | |
Execution from external flash | x ms | x ms | x ms |
Execution from external RAM memory | x ms | x ms | x ms |
Exceution from internal RAM memory | x ms | x ms | x ms |
6.2. Application development phase
During development phase, it is recommended to compile OEMiRoT_Boot project with DEV_MODE defined and to select OPEN state during provisioning process :
- When DEV_MODE is defined:
- additional 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.
- OPEN product state can be selected during provisioning process.
- When OPEN product state is selected during provisioning process, a specific script (obkey_provisioning_open.bat) is called in order to execute additional actions usually done in PROVISIONING product state :
- provision the AHKs (see STM32H7RS Reference manual for more description) used to encrypt OBkeys and to encrypt images with MCE peripheral.
- initialize the OEMiRoT data area in the OBkeys containing the version of the firmware installed as well as its SHA256 used when MCUBOOT_USE_HASH_REF is activated (Refer to the Features list for more details on MCUBOOT_USE_HASH_REF.
In CLOSED or LOCKED product state, the DA process should be run to be able to connect the debugger trough JTAG. At the end of the development phase, DEV_MODE must be disabled and the product state CLOSED or LOCKED must be selected during provisioning process.
6.3. OEMiRoT_Config.obk file format
Offset | Size | Type | Description |
---|---|---|---|
0 | 1 | uint8 | sdp command header : destination OBKey index |
1 | 1 | uint8 | sdp command header : destination OBKey HDP level |
2 | 2 | uint16 | sdp command header : reserved |
4 | 4 | uint32 | sdp command header : data size address |
8 | 4 | uint32 | sdp command header : encryption disabled/enabled (0/1) |
12 | 32 | array | SHA256 of the following data content (from offset 44 to xxx) |
44 | 91 | array | Authentication public key (MCU Boot format) |
135 | 70 | array | Encryption private key (MCU Boot format) |
205 | 31 | array | Reserved |
Same applied for OEMuRoT_Config.obk
6.4. OEMiRoT_Code_image xml file format
Parameter | Updatable | Description |
---|---|---|
Authentication key | Automatic | Private key inherited from OEMiROT_Config.xml file. |
Encryption key | Automatic | Public key inherited from OEMiROT_Config.xml file. |
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 OEMiRoT_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 | This parameter is removed by setting the <enable> property to 0. |
Write Option | Automatic | Image upgrade strategy: Overwrite, Swap. This value is updated during the postbuild of OEMiRoT_Boot project compilation based on MCUBOOT_OVERWRITE_ONLY definition from flash_layout.h. |
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 download area offset | Automatic | Used to generate .hex binary file format including the destination address. This value is updated during the postbuild of OEMiRoT_Boot project compilation based on slot configuration from flash_layout.h. |
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 OEMuRoT_Code_Image.xml