This article gives an overview of the OEMiRoT solution integrated in STM32WBA devices.
For a step-by-step user guide, go to the wiki pages on getting started with STM32WBA security.
Applicable products:
| Type | Products |
|---|---|
| Microcontroller | STM32WBA65xx, STM32WBA55xx |
1. OEMiRoT/OEMuRoT presentation
1.1. Overview
OEMiRoT stands for OEM immutable (unchangeable) Root of Trust and acts as a first boot stage. It is based on the MCUboot open-source software[1] provided with STM32CubeWBA.
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 (option bytes), activates runtime protections, and 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 candidates. It checks the 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 OEMiRoT and provides the same two services: Secure boot and secure firmware update. Both OEMiRoT and OEMuRoT examples are generated based on the 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, sensitive data (such as secret keys), and the execution flow, to improve security robustness.
On STM32WBA, 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 through the JTAG port, the RDP level regresses to level 1. The OEM2 password must first have been provisioned when the RDP level is 0. Refer to RDP for STM32WBA for more details.
- Boot configuration: BOOT_LOCK, SECBOOTADD0, NSBOOTADD0 and NSBOOTADD1 option bytes are configured to establish a chain of trust, by forcing the system to boot from the user flash memory.
- Antitamper protection: the antitamper protection is used to protect sensitive data from physical tampering. It is activated at the start of the OEMiRoT_Boot project and remains active during the OEMiRoT_Appli execution. In the case of tamper detection, sensitive data of OEMiRoT_Boot are immediately erased (tamper mode confirmed), 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 the OEMiRoT_Boot project during its execution and extended to the application code section after verifying its integrity and authenticity. This protection is dynamically managed at runtime.
- HDP: when the HDP secure hide protection is activated, any access to the protected flash memory area (fetch, read, programming, erase) is denied. All code and secrets located inside the protected flash memory area are fully hidden. In the OEMiRoT_Boot project example, the system is configured to hide the OEMiRoT_Boot code, the OEMiRoT_Boot personalized data (secrets), and the OEMiRoT_Boot nonvolatile counters area, located in the flash memory (refer to the chapter on memories layout for more details on the HDP area), just before launching the verified user application.
- WRP: write protection is used to ensure OEMiRoT_Boot code immutability as requested by the state-of-the-art standards in secure boot implementation. In the OEMiRoT_Boot project, the system has been configured to make the OEMiRoT_Boot code, the OEMiRoT_Boot personalized data (secrets) as immutable data.
- RAM Erase on reset: Data in SRAM2 is automatically erased when a system reset occurs.
Refer to the STM32WBA6xx Reference manual for in-depth descriptions of each feature.
Secure software coding techniques, such as doubling critical tests, doubling critical actions, random delay, checking parameter values, and flow control mechanisms, are implemented to improve security robustness.
1.3. OEMiRoT/OEMuRoT activation
On STM32WBA, OEMiRoT/OEMuRoT activation is done by:
- Configuring the option bytes to boot on OEMiRoT.
- Configuring secrets: authentication and encryption keys used by OEMiRoT or OEMuRoT.
- Building OEMiRoT_Boot binary in the selected configuration (OEMiRoT or OEMuRoT or OEMiRoT first boot stage).
All these operations are part of the provisioning process. There are two different use cases:
- One boot stage, OEMiRoT: OEMiRoT_Boot project binary is built in OEMiRoT configuration. OEMiRoT directly manages the user application binary.
- Two boot stages, OEMiRoT + OEMuRoT: OEMiRoT_Boot project binary is built in the OEMuRoT configuration. OEMiRoT_Boot first boot stage (provided in binary) manages an updatable boot stage (OEMuRoT), which manages the user application binary.
1.3.1. One boot stage: OEMiRoT with overwrite strategy
OEMiRoT is generated by compiling OEMiRoT_Boot project with OEMUROT_ENABLE switch deactivated.
This figure demonstrates secure boot and update processes, displaying all steps required to boot user application code from 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:
- At reset, boot is forced on OEMiRoT with SECBOOTADD0 and BOOT_LOCK.
- OEMiRoT checks if a new user application code and/or new data images are stored in the download slots. If so, OEMiRoT decrypts them and checks their integrity, authenticity, antirollback counter, and dependency version.
- If successful, the images are decrypted and copied to the user application installation slots.
- OEMiRoT checks the integrity and the authenticity of the user application code and data images from the installation slot.
- If successful, OEMiRoT saves the new image counters in the NV counter region for the antirollback verification, then executes the user application. The jump to the user application code is done by the code in the HDP activation code area.
1.3.2. One boot stage: OEMiRoT with swap strategy
OEMiRoT is generated by compiling OEMiRoT_Boot project with OEMUROT_ENABLE switch deactivated.
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 the 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:
- At reset, boot is forced on OEMiRoT with SECBOOTADD0 and BOOT_LOCK.
- OEMiRoT checks if a new user application code and/or new data images are stored in the download slot. If so, OEMiRoT decrypts them and checks their integrity, authenticity, antirollback counter, and dependency version.
- If successful, the new images are decrypted and swapped with the installed images, using the scratch area.
- OEMiRoT checks the integrity and authenticity of the user application code and data images from the installation slots.
- If successful, OEMiRoT executes the user application. The jump to the user application code is done by the code in the HDP activation code area.
- If the user application execution validates the new images, OEMiRoT saves the new image counters in the NV counter region for the antirollback verification at the next reset.
- If the user application execution does not validate the new images, the images are swapped back (reverted) at the next reset.
1.3.3. Two boot stage: OEMiRoT (overwrite strategy) + OEMuRoT with overwrite strategy
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:
- At reset, boot is forced on OEMiRoT with SECBOOTADD0 and BOOT_LOCK.
- After executing the secure firmware update process, OEMiRoT controls OEMuRoT integrity and authenticity. If successful, OEMiRoT executes OEMuRoT
- OEMuRoT checks if a new user application code and/or new data images are stored in the download slots. If so, OEMuRoT decrypts them and checks their integrity, authenticity, antirollback counter, and dependency version.
- If successful, the images are decrypted and copied to the user application installation slots.
- OEMuRoT checks the integrity and the authenticity of the user application code and data images from the installation slot.
- If successful, OEMuRoT saves the new image counters in the NV counter region for the antirollback verification, then executes the user application. The jump to the user application code is done by the code in the HDP activation code area.
- In case of failure, the Error_Handler is called.
1.3.4. Two boot stage: OEMiRoT (overwrite strategy) + OEMuRoT with swap 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.
The following figure illustrates the scratch buffer usage with OEMuRoT :
2. Feature list
The main features of OEMiRoT/OEMuRoT are:
- Software cryptography operations:
- 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 the chapter on images generation for more details.
- Accelerated boot with 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 a reference for the next boot. At this next boot, signature verification is skipped if the SHA256 of the image matches the reference stored in the Hash Ref region in the user flash memory (refer to memories layout for more). This feature brings performance optimization (under the MCUBOOT_USE_HASH_REF compilation switch).
- Antirollback version check based on the image counter stored in the NV counters region in the user flash memory (see also memories layout).
- Primary and secondary slots mode, enabling safe image programming. The downloaded image and the installed image are in different memory slots.
- Image installation is resistant to asynchronous power-down and reset, in primary and secondary slot mode configuration.
- Flexible number of application images on STM32WBA :
- 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 on STM32WBA : 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 delay generation.
- Configurable firmware image upgrade strategy, for primary and secondary slots mode:
- Overwrite strategy, in which the image in the secondary slot overwrites the image in the primary slot.
- Swap strategy, in which the images in the primary and secondary slots are swapped. After the swap, the new image in the primary slot must be confirmed by the user application, otherwise, the images are swapped back at the next boot.
- Memory configuration: all slots are located inside the internal user flash memory (primary and secondary slots for code and data images).
- Fast wake-up from standby mode (bypass of image authentication). This feature is enabled by default under the OEMIROT_FAST_WAKE_UP compilation switch in boot_hal_cfg.h.
- Integration of hardware security peripherals and mechanisms to implement a root of trust. RDP, BOOT_LOCK, MPU, WRP, HDP, and TAMPER are combined to achieve the highest security level. When connected to the hardware board, the internal tamper can be activated with the TAMPER_ENABLE define.
- Image generation with the STM32TrustedPackageCreator tool, included with STM32CubeProgrammer.
The following table identifies the cryptography operations hardware-accelerated on the STM32WBA devices:
| Hardware accelerator | Operation | STM32WBA65 | STM32WBA55 |
|---|---|---|---|
| PKA | ECDSA |  |
|
| SAES | AES | |
|
| HASH | SHA256 | |
|
| RNG | Random generator | |
|
Features configurability:
| Feature | OEMiRoT | OEMiRoT
First_boot_stage |
OEMuRoT | Compilation switch | Configuration file |
|---|---|---|---|---|---|
|
Boot project generation |
OEMiRoT generation |
OEMiRoT First boot stage generation |
OEMuRoT generation |
OEMUROT_ENABLE OEMIROT_FIRST_BOOT_STAGE |
flash_layout.h |
|
Image upgrade strategy |
|
|
|
MCUBOOT_OVERWRITE_ONLY |
flash_layout.h |
|
Slots mode |
|
|
|
- | |
|
Flash memory configuration |
|
|
|
MCUBOOT_OVERWRITE_ONLY MCUBOOT_APP_IMAGE_NUMBER MCUBOOT_S_DATA_IMAGE_NUMBER MCUBOOT_NS_DATA_IMAGE_NUMBER |
flash_layout.h |
|
Antitamper |
|
|
|
OEMIROT_TAMPER_ENABLE |
boot_hal_cfg.h |
|
Project phase (refer to Application development phase) |
|
|
|
OEMIROT_DEV_MODE |
IDE preprocessor symbols |
| Crypto implementation |
|
|
|
BL2_HW_ACCEL_ENABLE | mcuboot_config.h |
OEMiRoT/OEMuRoT differences:
| Feature | OEMiRoT | OEMiRoT
First_boot_stage |
OEMuRoT |
|---|---|---|---|
| WRP | ON, immutable RoT | ON, immutable RoT | OFF, updatable RoT |
| HDP | HDP activated on user flash to hide OEMiRoT code/data after execution | HDP not activated | HDP activated to hide OEMiRoT and OEMuRoT code/data after execution |
3. Memories layout
3.1. OEMiRoT layout
In STM32CubeWBA, the OEMiRoT relies on the flash memory layout, which defines several regions:
- HASH REF region: the region where the SHA256 references are stored (one reference per image).
- NV counters region: the region where OEMiRoT_Boot gets nonvolatile information about last-installed image (code and data) versions for the antirollback feature.
- SCRATCH region: the 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: the region to personalize OEMiRoT secret keys (authentication and encryption keys).
- OEMiRoT_Boot code region: the region to program the OEMiRoT_Boot code binary that manages the "Secure Boot" and "Secure Firmware Update” functions.
- Secure application code installation slot region: region to program the image of an “active” secure application code after installation.
- Nonsecure application code installation slot region: region to program the image of an “active” nonsecure application code after installation.
- Secure application code download slot region: region to program the image of a "new" candidate secure application code for installation.
- Nonsecure application code download slot region: region to program the image of a "new" candidate nonsecure application code for installation.
- Secure application data installation slot region: region to program the image of an “active” secure application data after installation.
- Nonsecure application data installation slot region: region to program the image of an “active” nonsecure application data after installation.
- Secure application data download slot region: region to program the image of a "new" candidate secure application data for installation.
- Nonsecure application data download slot region: region to program the image of a "new" candidate nonsecure application data for installation.
The flash memory layout is fixed but can be updated, especially when:
- There is no data image;
- The image upgrade strategy is overwrite;
Flash memory layout is as follows:
Default configuration of the flash memory layout is:
| OEMiRoT | ||
|---|---|---|
| Symbol | Updatable | Default value |
| MCUBOOT_APP_IMAGE_NUMBER | Yes | 2 |
| MCUBOOT_S_DATA_IMAGE_NUMBER | Yes | 0 |
| MCUBOOT_NS_DATA_IMAGE_NUMBER | Yes | 0 |
| MCUBOOT_OVERWRITE_ONLY | Yes | Activated |
| FLASH_AREA_BL2_SIZE | Yes | 64 Kbytes (Overwrite) or 72 Kbytes (Swap) |
| FLASH_AREA_BL2_NOHDP_SIZE | Yes | 8 KBytes |
| FLASH_S_PARTITION_SIZE | Yes | 32 Kbytes |
| FLASH_NS_PARTITION_SIZE | Yes | 200 Kbytes |
| FLASH_S_DATA_PARTITION_SIZE | Yes | 8 Kbytes (when MCUBOOT_S_DATA_IMAGE_NUMBER != 0) |
| FLASH_NS_DATA_PARTITION_SIZE | Yes | 8 Kbytes (when MCUBOOT_NS_DATA_IMAGE_NUMBER != 0) |
| FLASH_AREA_SCRATCH_SIZE | Yes | 64 Kbytes (when MCUBOOT_OVERWRITE_ONLY not activated) |
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: 64 Kbytes scratch size, 10 k programming cycles, 200 Kbytes firmware image size => 3200 firmware image updates
The NV counters region size can be tuned according to the expected number of security counter update upgrade in the product life:
- Each security counter upgrade consumes 8 bytes (Double word programming) in the NV counters area
- When NV counters region is full, security counter are no more updatable
- 8KB NV counters region => 1024 security versions upgrade
3.2. OEMiRoT + OEMuROT layout
This section describes OEMuRoT flash layout specificities only, compared to OEMiRoT flash layout.
Additional regions are present:
- OEMuRoT_Boot code download slot region: region to program the image of a "new" candidate OEMuRoT_Boot code binary for installation (managed by OEMiRoT first boot stage).
- OEMuRoT_Boot data download slot region: region to program the image of a "new" candidate OEMuRoT_Boot data binary for installation (managed by OEMiRoT first boot stage).
Flash memory layout is as follows:
Default configuration of the flash memory layout is:
| OEMiRoT first boot stage | OEMuRoT | |||
|---|---|---|---|---|
| Symbol | Updatable | Default value |
Updatable |
Default value |
| MCUBOOT_APP_IMAGE_NUMBER | No | 1 | Yes | 2 |
| MCUBOOT_S_DATA_IMAGE_NUMBER | No | 1 | Yes | 0 |
| MCUBOOT_NS_DATA_IMAGE_NUMBER | No | 0 | Yes | 0 |
| MCUBOOT_OVERWRITE_ONLY | No | Activated | Yes | Activated |
| FLASH_AREA_BL2_SIZE | No | 64 Kbytes | Yes | 64 Kbytes (Overwrite) or 72 Kbytes (Swap) |
| FLASH_AREA_BL2_NOHDP_SIZE | No | 8 Kbytes | No | 8 Kbytes |
| FLASH_S_PARTITION_SIZE | Yes | 80 Kbytes* | Yes | 32 Kbytes |
| FLASH_NS_PARTITION_SIZE | No | 0 | Yes | 200 Kbytes |
| FLASH_S_DATA_PARTITION_SIZE | Yes | 8 Kbytes** | No | 8 Kbytes (when MCUBOOT_S_DATA_IMAGE_NUMBER != 0) |
| FLASH_NS_DATA_PARTITION_SIZE | No | 0 | Yes | 8 Kbytes (when MCUBOOT_NS_DATA_IMAGE_NUMBER != 0) |
| FLASH_HASH_REF_AREA_SIZE | No | 8 Kbytes | No | 8 Kbytes |
| FLASH_BL2_NVCNT_AREA_SIZE | Yes | 8 Kbytes | Yes | 8 Kbytes |
| FLASH_AREA_PERSO_SIZE | No | 8 Kbytes | No | 8 Kbytes |
* Must be equal to the BL2_SIZE of OEMuRoT + FLASH_AREA_BL2_NOHDP_SIZE
** Must be equal to the PERSO_SIZE of the OEMuRoT
4. Provisioning process
4.1. OEMiRoT provisioning process
The product provisioning to activate and configure OEMiRoT is done by following these three steps:
- 1. Configuration of :
- Selecting the RDP level.
- Generating the OEMiRoT_Keys.bin
- 2. Images generation :
- Building the OEMiRoT_Boot.
- Building the OEMiRoT_Appli_Trustzone.
- Building the data image if any.
- 3. Provisioning :
- Provisioning of OEM2 key
- Programming the option bytes and flashing the images in the device.
The image below shows a visual representation of these steps.
4.2. OEMiRoT + OEMuROT provisioning process
The product provisioning to activate and configure OEMuRoT is done by following steps:
- 1. Configuration of :
- Selecting the RDP level.
- Generating the OEMiRoT_Keys.bin and OEMuRoT_Keys.bin
- 2. Images generation :
- Building the OEMuRoT_Boot.
- Building the OEMuRoT_Appli_Trustzone.
- Building the data image if any.
- 3. Provisioning :
- Provisioning of OEM2 key
- Programming the option bytes and flashing the images in the device.
5. Images generation
OEMiRoT manages images based on the MCUBoot format, including:
- A header;
- The encrypted firmware binary;
- Some metadata information (TLV format: tag length value) allowing the control of the image (SHA256, ECDSA-P256 signature, etc.).
- 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. In overwrite mode, the image size is limited to the slot area size minus the magic data size (16 bytes).
- a magic to trigger the installation at the end of the slot. A magic word to trigger the installation at the end of the slot.
Further information about the MCUBoot open-source software is available mcuboot.
A PC tool STM32TrustedPackageCreator is provided to generate the firmware code image. This image is encrypted and signed using the keys configured in configuration file (OEMiRoT_Config.xml / OEMuRoT_Config.xml).
2 types of images are generated:
- initial image: Image in clear to be programmed in installation area during initial device programming.
- update image: Encrypted image to be programmed in download area. Will be installed during secure firmware update process.
5.1. Initial images generation
OEMiRoT_xx_Code_Init_Image.xml, OEMiRoT_xx_Data_Init_Image.xml, OEMuRoT_xx_Code_Init_Image.xml and OEMuRoT_xx_Data_Init_Image.xml contains all the parameters driving the initial images generation such as:
- The authentication keys. Keys value inherited from OEMiRoT_Config.xml / OEMuRoT_Config.xml.
- The version.
OEMiRoT_xx_Code_Init_Image.xml, OEMiRoT_xx_Data_Init_Image.xml, OEMuRoT_xx_Code_Init_Image.xml and OEMuRoT_xx_Data_Init_Image.xml can be edited with STM32TrustedPackageCreator in order to modify the version information.
The following figure shows the application code initial image generation (same applied to other images):
5.2. Update Images generation
OEMiRoT_xx_Code_Image.xml, OEMiRoT_xx_Data_Image.xml, 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. Keys value inherited from OEMiRoT_Config.xml / OEMuRoT_Config.xml.
- The version.
- The dependency with another image if a synchronized installation is required.
OEMiRoT_xx_Code_Image.xml, OEMiRoT_xx_Data_Image.xml, 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 applied for data image):
6. Appendix
6.1. OEMiRoT/OEMuRoT startup sequence
Performance measured at 100 MHz in production mode (OEMIROT_DEV_MODE undefined: no logs) :
| 256 Kbytes | 512 Kbytes | 1024 Kbytes | |
|---|---|---|---|
| Boot time | --- ms | --- ms | --- ms |
6.2. Application development phase
During the development phase, it is recommended to compile the OEMiRoT_Boot project with OEMIROT_DEV_MODE defined and to select RDP level 0 during the provisioning process:
When OEMIROT_DEV_MODE is defined:
- Logs are displayed in Tera Term during the OEMiRoT_Boot project execution.
- An infinite loop is executed instead of a reset in the Error_Handler() function.
- A 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, OEMIROT_DEV_MODE must be disabled and the RDP level 2 must be selected during the provisioning process to achieve the highest security level.
6.3. OEMiRoT constraints
The list of constraints to be taken into account when activating the OEMiRoT boot path is the following:
- Internal tamper 9 (fault generation for cryptographic peripherals (SAES, PKA, AES, RNG) and internal tamper 15 (system fault detection ) are activated in confirmed mode, during OEMiRoT execution and remains activated when jumping into the user application. Reset is performed in case of tamper event detection during OEMiRoT execution.
- MPU is configured to allow only the user application code area to be executed when OEMiRoT jumps into the user application. It is the user application responsibility to reconfigure the MPU to fit with its security needs.
- SRAM2 is used by OEMiRoT and is therefore erased at each reset.
6.4. OEMiRoT/OEMuRoT Keys Configuration
OEMiRoT/OEMuRoT keys are generated using STM32TrustedPackageCreator with a template file listing all the different parameters (OEMiRoT_Config.xml, OEMuRoT_Config.xml) as input. The bin files are saved in OEMiRoT_Keys.bin and OEMuRoT_Keys.bin. The list of the configuration parameters is the following:
| Parameter | Description | Additional constraints |
|---|---|---|
| Authentication secure key | Key used to authenticate the secure code and data images | When this key is regenerated, both secure code and data images must be processed with TPC “Image Gen” tab (OEMiRoT_S_Code_Image.xml, OEMiRoT_S_Data_Image.xml) |
| Authentication nonsecure key | Key used to authenticate the nonsecure code and data images | When this key is regenerated, both nonsecure code and data images must be processed with TPC “Image Gen” tab (OEMiRoT_NS_Code_Image.xml, OEMiRoT_NS_Data_Image.xml) |
| 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) |
The key file format is :
| Offset | Size (Bytes) | Type | Description |
|---|---|---|---|
| 0 | 91 | array | ECDSA-P256 authentication public key for secure code and data images |
| 92 | 91 | array | ECDSA-P256 authentication public key for nonsecure code and data images |
| 184 | 70 | array | ECDSA-P256 encryption private key |
Same applied for OEMuRoT
6.5. OEMiRoT_S_Code_image xml file format
| Parameter | Updatable | Description |
|---|---|---|
| Authentication key | Yes | Private key inherited from OEMiROT_Config.xml file. |
| Encryption key | Yes | 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 area size. This value is updated during the postbuild operation based on the slot configuration from flash_layout.h. |
| Header size | No | 0x400 bytes. |
| Padding header | No | Padding the header with 0xFF to fulfill the 0x400 bytes. |
| Dependency with other image | Yes | Number and version of the image to be installed with: Number, x.y.z |
| 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 | The security counter value is automatically generated based on version information. |
| Align | No | The size of the encrypted binary generated is a multiple of 16 bytes. |
| 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 the env.bat file. |
| Image output file | Yes | Location of the encrypted image generated. If changed, the provisioning scripts must be updated accordingly. |
Same applied for OEMiRoT_NS_Code_Image.xml, OEMiRoT_S_Data_Image.xml, OEMiRoT_NS_Data_Image.xml, OEMuRoT_S_Code_Image.xml, OEMuRoT_NS_Code_Image.xml, OEMuRoT_S_Data_Image.xml, OEMuRoT_NS_Data_Image.xml.
6.6. OEMiRoT first boot stage
OEMiRoT first boot stage is used in OEMuROT use case and is generated by compiling OEMiRoT_Boot project with OEMIROT_FIRST_BOOT_STAGE switch activated that set the following configuration :
| Symbol | Value |
|---|---|
| MCUBOOT_APP_IMAGE_NUMBER | 1 |
| MCUBOOT_S_DATA_IMAGE_NUMBER | 0 |
| MCUBOOT_NS_DATA_IMAGE_NUMBER | 0 |
| MCUBOOT_OVERWRITE_ONLY | Activated |
| FLASH_S_PARTITION_SIZE | 80 Kbytes* |
| FLASH_NS_PARTITION_SIZE | 0 |
| FLASH_S_DATA_PARTITION_SIZE | 0 |
| FLASH_NS_DATA_PARTITION_SIZE | 0 |
| BL2_HW_ACCEL_ENABLE | Activated |
| OEMIROT_DEV_MODE | Activated |
| OEMIROT_TAMPER_ENABLE | INTERNAL_TAMPER_ONLY |
| OEMIROT_OB_RDP_LEVEL_VALUE** | OB_RDP_LEVEL_0 |
* Must be at least equal to FLASH_AREA_BL2_SIZE of OEMuRoT + FLASH_AREA_BL2_NOHDP_SIZE
** RDP minimum level authorized
At the end of the build, you must copy the OEMiROT_Boot/Binary/OEMiROT_Boot.bin in ROT_Provisioning/OEMiROT_OEMuROT/Binary/OEMiROT_Boot.bin.
7. References