STiRoT for STM32H5

STiRoT Overview

STiRoT states for Immutable Root Of Trust and acts as a first boot stage.
This is a ROM code developed by STMicroelectronics, which is SESIP Level3 certified and stored in the STM32 System Flash.

Since the STiRoT is requiring hardware cryptographic features, it is only available on STM32H57x product lines.

To use STiRoT, TrustZone^® needs to be activated.
This article describes the different services provided by the STiRoT and the different user application use cases.

1. STiRoT services

The STiRoT provides two services.

1) The Secure Boot (Root of Trust Services):

It is an immutable code, always executed after a system reset that activates STM32 runtime protections and verifies the authenticity and integrity of the application code before every execution.

• Integrity: to ensure that a firmware that is going to be executed has not been corrupted or maliciously modified.
  
• Authenticity: to verify that a firmware is coming from a trusted and known source in order to prevent unauthorized entities to install and execute code.

2) The Secure Firmware Update:

It is an immutable code that detects if a new firmware image is available, checks its authenticity and verifies the integrity of the code before installing it after decryption.

• Note: For a Secure Firmware Update, the new firmware needs first to be stored in a download area of the user flash (see figure1). To protect this new firmware, it is mandatory to store it as an encrypted and signed image. (see How_to_start_with_STiRoT_on_STM32H573 for a practical example of image generation).

2. STiRoT use cases

There are two possible cases explained below.

• Case 1: The user application is executed after the STiRoT (1 boot stage)
  

Two examples are provided in the STM32H5 MCU package that contains the STM32Cube_FW_H5:

• For a full secure user application and data ( (\Projects\STM32H573I-DK\Applications\ROT\STiROT_Appli),)
• For a secure and nonsecure user application and data (\Projects\STM32H573I-DK\Applications\ROT\STiROT_Appli_TrustZone).

The STiRoT application is the first application executed after any reset. STiRoT application is executed in temporal isolation 1 (HDPL1)..

The following figure gives an example of the memory mapping when STiRoT is activated in a 1 boot stage configuration.

It shows the user application and data download areas for the different images and the user application location once installed. This is explained in the following sections.

The user application can be full secure or divided in a secure and nonsecure application. The image stored in the download area is in both cases a single image.

A secure user application is mandatory and must contain at least the vector table and the reset handler.

The figure indicates also the entry point after reset.

Figure 1. Case1 User application is executed after STiRoT

After a successful verification of the user application (integrity and authenticity), the STiRoT executes the user application in temporal isolation level 2 (HDPL2) and in secure mode.

To avoid any risk of attack, the MPU is configured to ensure that only the user application is allowed to be executed.

It is the user application responsibility to update and adapt the MPU configuration to its needs.

The user application can, for instance, move to temporal isolation level 3 (HDPL3) and/or switch in nonsecure mode.

A data image is optional. During the STiRoT configuration it can be chosen to activate it or not.

The data can be for instance used to store keys or any other secret information needed by the user.

In case there is a verification failure of the user application code, the STiRoT executes the Embedded Bootloader to download a new user app code and data if application.

A verification failure means that the user application code has been altered and is not safe anymore to be executed. For instance, following a hardware attack of the user flash.

• Case 2: The updatable Root of Trust (uRoT) is executed after the STiRoT (2 boot stage)

An example is available in the STM32H5 MCU package that contains the STM32Cube_FW_H5 (\Projects\STM32H573I-DK\Applications\ROT\STiROT_OEMuROT_Appli).

The uRoT is located in the user flash and will act as a second boot stage adapted by the user for his own requirements.

The following figure shows the entry point after reset and the STiRoT controlling the step to uRoT.

The STiRoT application is the first application executed after any reset (STiRoT application is executed in temporal isolation level 1 (HDPL1).

Figure 2. Case2 updatable Root of Trust executed after STiRoT

After a successful verification (integrity and authenticity) of the uRoT, the STiRoT executes the uRoT in temporal isolation level 2 (HDPL2) and in secure mode.

The uRoT will then execute the secure user application (S-User app) after a successful verification in temporal isolation level 3 (HDPL3) and in secure mode.

In case there is a verification failure of the uRoT application, the STiRoT executes the Embedded Bootloader in order to download a new uRoT code and/or data.

A verification failure means that the uRoT code has been altered and is not anymore safe to be executed. For instance, after a hardware attack of the user flash.

3. STiRoT configuration

The possible configuration options are described in the STiRoT configuration detailed table.

The STiRoT configuration options used by default in the provided STM32CubeFW examples are listed below:

• User application images:
  

• One image: user application code image.
  
• Two images: one user application code image & one user application data images.
  

• User application secure and nonsecure:
  

• User application full secure.
  
• User application secure & user application nonsecure.
  

• User application image and execution:
  

• Flash location and size reserved for code image download.
  
• Flash location and size reserved for user application installation.
  

• User data image:
  

• Flash location and size reserved for data image download.
  
• Flash location and size reserved for decrypted user data.
  

• Encryption and authentication key location (only ECDSA256 supported).
  
• Minimal product state:
  

• STiRoT will execute the firmware only if the product state is equal or greater than the "Product state minimal allowed".
  

The STiRoT configuration is done using a configuration file (STiROT_Config.xml). STM32CubeFW contains an example.

All the configurations can be chosen by directly editing this STiROT_Config.xml file or graphically using STM32TrustedPackageCreator.

• Default configuration parameters are visible in TrustedPackageCreator.
• Hidden parameters can be made visible by edditing the "Hidden" value in the STiROT_Config.xml file.
• Two keys are provisioned: a key for the authentication and a key for the file encryption.
  
• Default keys are provided in the STM32Cube_FW but can be regenerated using STM32TrustedPackageCreator.
  

When the STiRoT configuration file (STiROT_Config.xml) is ready an OBKey configuration file (STiROT_Config.obk) is generated using STM32Trusted Package Creator.

This generated STiROT_Config.obk file is used to configure the device during the device provisioning.

A script (Provisioning.bat) provided in the STM32Cube_FW, is guiding the user during the configuration definition and device programming.

4. Firmware code and data images generation

To be compatible with STiRoT, the user application firmware image and user data image need to fulfill a specific format.
These images are encrypted and signed using the keys mentioned in the previous section.
User data are optional and defined during the STiRoT configuration.

4.1. User application code image

The figure below provides an overview of the user application code image generation.
To be installed successfully by the STiRoT, this image needs to be encrypted, signed, and aligned with the flash memory map config.
The user application can be full secure or split in a secure and a nonsecure application. In any case, a single image is generated.

4.1.1. Memory mapping constraints for the user application code

The following figure provides some details about the mapping configuration and image format requirements for the user application to be compatible with STiRoT.

Figure 3. User application mapping and image format

• The Header is a fixed size of 0x400.
  
• The Magic is a reserved 16 bytes memory region used to manage the installation.
• The TLV is a reserved 296 bytes memory region placed at the end of the image. It states for Type Length Value and contains metadata used to manage the images.

On the left of the above figure, the user application code image structure is written in a download flash area by the STiRoT.
On the right of the above figure, the user application code structure is written in the execution flash area by the STiRoT.

For a practical example how to set the firmware code download and execution area offsets, refer to How to start with STiRoT article.

4.1.2. User application code image generation

The user application code binary file can be generated by any IDE.
The mandatory generation of the encrypted and signed image is done with STM32TrustedPackageCreator.

• With an IDE supporting the postbuild command, the STM32TrustedPackageCreator is launched automatically at the end of the compilation. In this case, the encrypted and signed image creation is done automatically during the user application compilation.
  
• STM32TrustedPackageCreator can be launched separately to generate from a binary file, an encrypted and signed image file using the same encryption and authenticity keys provisioned during the STiROT configuration (refer to Memory mapping constraints for the user application code).
  

As shown in the figure below, STM32TrustedPackageCreator is using a configuration file named STiRoT_Code_Image.xml.
An example is available in the STM32Cube_FW repository, in \STM32Cube_FW_H5\Projects\STM32H573I-DK\ROT_Provisioning\STiROT\Image.
It can be edited directly in the xml file or graphically by using STM32TrustedPackageCreator.
A dependency with a user data image version can be added in order to have simultaneous installation of firmware code and data images.
The related version of the data image is defined in the STiROT_Code_Image.xml and can be updated accordingly.

Figure 4. User application code image generation (signed and encrypted)

The STM32TrustedPackageCreator generates the stm32h573xx_flash.if file defining a vector table located at: 0x0C000000 + code execution slot offset + 0x400 (header size).
For IAR Embedded Workbench IDE, this file is located in the STiROT_Appli\EWARM directory.
In case of configuration modification, it is mandatory to recompile the user application project to generate the correct binary file.

4.2. User Data Image

As mentioned previously, data is optional and defined during the STiRoT configuration.
To be installed successfully by the STiRoT, this image needs to be encrypted, signed, and aligned with the flash memory map config.

4.2.1. Memory mapping constraints for the user data

The following figure gives some details about the mapping configuration and image format for the user data to be compatible with the STiRoT.

Figure 5. User Data mapping and image format

On the left of the above figure, the user data image structure is written in a download flash area by the STiRoT.
On the right of the above figure, the user application data structure is written in the Obkey.
Note: that the user data is stored in the Obkey secure storage area and not in a user flash area.

4.2.2. User data image generation

The following figure gives an overview of the user data image generation.

STM32TrustedPackageCreator need to be launched separately to generate the encrypted and signed image file using the same encryption and authenticity keys provisioned during the STiRoT configuration. The same keys are also used for the user application code image generation.

As figure shows, STM32TrustedPackageCreator is using a configuration file (STiROT_Data_Image.xml).
A file example is available in the STM32Cube_FW (STM32Cube_FW_H5\Projects\STM32H573I-DK\ROT_Provisioning\STiROT\Image).
It can be edited directly in the xml file or graphically by using STM32TrustedPackageCreator (refer to How to start with STiRoT article)
The user data download offset is defined in the xml file.
A dependency with a user application firmware image version can be added in order to have simultaneous installation of firmware code and data images.
The related version of the user application firmware image is defined in the STiROT_Data_Image.xml and can be updated accordingly.

Figure 6. Data image generation (signed and encrypted)

5. Provisioning

The provisioning includes the option bytes programming, the image flashing and the final product state setting.

How to practically perform the provisioning is explained in the How to start with STiRoT article.
The provisioning script provides step by step guidance for a straightforward provisioning.

5.1. STiRoT and DA provisioning

The STiRoT and DA configurations are programmed on the device based on the two OBK generated files.

The figure below provides an overview of the provisioning and the needed input files.

Figure 7. STiRoT Provisioning

• Points one and two in the above figure show the generation of the configuration OBK (STiROT_Config.obk and DA_Config.obk).
• The STiROT_Config.obk configuration file is used during the provisioning to store the STiROT configuration in the OB key level1 secure storage of the device.
• The DA_Config.obk configuration file is used during the provisioning to store the Debug Authentication configuration in the OB key secure storage of the device.
• The STiROT_Data.obk file contains some working data, for instance the installed firmware version. For the provisioning, it should be initialized with "zero" values. This file is provided in the STM32CubeFW.
• Point three in the above figure shows the provisioning script that also launches four different scripts.
  

• update_appli_setup.bat: setting of the STiRoT configuration (different settings, download and execution area, postbuild path for IDE) and update of specific files used for tests.
• obkey_provisioning.bat: configure Obkeys and set the option to boot in STiRoT (UBE option byte).
• update_ob_setup.bat: updating of option byte.
• ob_flash_programming.bat : removal of the protection and erase the use flash. Configure the option bytes according to the STiRoT configuration and images download.

All these scripts are located in STM32Cube_FW_H5_Vx.x.x\Projects\STM32H573I-DK\ROT_Provisioning\STiROT with related log files giving a trace of the executed operations.

As mentioned previously, the provisioning.bat script guides you during the complete procedure and automatically launches the scripts.

The provisioning script, as shown in the figure above, includes code and data flashing in the dowload area and the final product state setting. These topics are described below.

Note: The option bytes configuration, such as SECWM, SRAM2_RST, SRAM2_ECC, is extracted from the STiRoT configuration. Others option bytes such as TZ_EN, SECBOOT_LOCK are configured with a fixed value.

5.2. User application firmware and data installation

The following figure summarizes the steps for the user application firmware and data installation.
The download area locations and sizes are defined during the STiRoT configuration (refer to STiRoT configuration section) .
The execution slot location and size are also defined during the STiRoT configuration.
For the CubeFW STiRoT example, the user application code and data are in isolation level 2 (HDPL2).

• The encrypted user application code is written in the download area, with a single image also in the case of secure and nonsecure user applications.
• After authenticity and integrity verifications, the user application codes are decrypted and written in the user flash execution area.
• The encrypted data is written in the download area.
• The data authenticity and integrity are verified. Then, the data is decrypted and reencrypted with the DHUK (Derived Hardware Unique Key) and stored in the secure storage (HDPL2 OB Keys area) (For explanation about the DHUK, please refer to the "Secure storage" wiki article).

Figure 8. Case1 User application is executed after STiRoT

A firmware or data update is possible in any product state (except Locked state) through launch of the Embedded Bootloader.
A practical example is shown in the How to start with STiRoT article

• The Embedded Bootloader is used to copy the encrypted new user application firmware and/or new user data in the user flash download area
• At next hardware reset, the STiRoT installs one or more updates after authenticity and integrity verifications.

5.3. Product state setting

When the user application code and data is flashed into the device, the final product state can be set.
The product state is done using the previously mentioned provided script.
The product state can also be set using STM32CubeProgrammer.
Note: Having a good understanding of the Debug authentication is recommended before using product states other than OPEN .

The following figure shows the possible product state.

The provided script mentioned previously (Provisioning.bat) guides the user also during this phase (refer to STM32_STiROT_DA_getting_started).
At the end of the provisioning script execution, the product state can be chosen, and the related option byte will be automatically set.
The product state is chosen depending on the user application development phase and the wanted security level.

Figure 9. Product Lifecycle

• Open:
  

• This state is mainly used during development phase since the device is fully open.
  
• Debug is fully open.
  
• The TrustZone^® can be disabled or enabled (TZEN option byte programming).
  
• Embedded Bootloader can be used.
  

• Provisioning:
  

• This state is used during the provisioning.
  

It is the device state during the provisioning script execution (Provisioning.bat).

So this state will not be part of the proposed state that can be chosen at the end of the script execution.

• The debug is only available when non secure user application is executed.
  
• The TrustZone^® can be disabled or enabled (TZEN option byte programming).
  
• Embedded Bootloader can be used.
  
• Secure Firmware install can be launched in this state (not anymore possible in following states).
  
• There is a risk of partial or full regression.
  

• Provisioned:
  

• In this state the STiRoT setup is done.
  
• Debug is available only when non secure user application is executed.
  
• Debug access for secure application can be available by launching Debug authentication (refer to Debug authentication settings).
  
• The STiRoT can launch the Embedded Bootloader if the verification of the code located in the next isolation level is failing (authentication, integrity or missing code)
  
• There is a risk of partial or full regression.
  

• TZ-Closed:
  

• The Trust Zone closed state is used when the STiRoT is provisioned and the secure user application (case 1) or the uRoT+Secure user application (case2) (refere to section 5.1.2).
  
• For case 2, the uRoT is allowing the update of the next isolation level (Code and Data).
  
• uRoT can launch the Embedded Bootloader if the verification of the code located in the next isolation level is failing (authentication, integrity, or missing code).
  
• The debug is only available when nonsecure user application is executed.
  
• Debug access for secure application can be available by launching the Debug authentication (refer to Debug authentication settings).
  
• There is a risk of partial or full regression.
  

• Closed:
  

• This state is used when the product is fully provisioned.
  
• The debug is fully closed but can be open by launching the Debug authentication (refer to Debug authentication settings).
  
• There is a risk of partial or full regression.
  

• Locked

• Locked is the final product state. It cannot be changed anymore at a later stage.
  
• The debug is definitively closed. It cannot be reopened through Debug authentication.
  
• There is no possibility of regression.
  

6. Provisioning without uploading a user application image or user data image

The previous sections detailed the different steps according to the STM32CubeFW provisioning script and the related examples.
However, the provisioning of the device is also possible without uploading a user application firmware or user data.

• If after a reset the STiRoT detects that no valid code is present in the download user flash area, it will start the Embedded Bootloader (with the correct setting of the STiROT_Config.xml indicated below).
• The encrypted and signed user application firmware image and the optional user data image are copied in the download using one of the supported Bootloader interface (USART, SPI, I2C, I3C, USB, FDCAN).
• At next reset the STiRoT:
  • If a user application firmware image is present in the download area: after authenticity and integrity verifications, the firmware image is decrypted and installed in the execution area.
  • If a data image is present in the download area: after authenticity and integrity verifications, the data image is decrypted and copied in the secure storage (Obkey HDPL2) after encryption using the DHUK.

The figure below gives an overview. Click on the picture to display it full screen.

Figure 10. Image download and installation

• The Embedded Bootloader starts only if the correct option is selected in the STiROT_Config.xml file
  • This file can be directly updated using a text editor.
  • Or the "Hidden" can be set to "0" in order to see this option setting in the STM32TrustedPackageCreator.

Figure 11. Bootloader launch when no valid image in the download area

• It is stronly advised reusing the scripts available in STM32CubeFW (refer to How to start with STiRoT article) and to only comment out the "Download images" part of the ob_flash_programming.bat (one of the scripts launched by the provisioning.bat script)

7. User application firmware update and user data update

When the user application code and user data are installed into the device and that the final product state is set, the firmware or the data can be updated unless the device is in "Locked" product state.
For that, the code executed after the STiRoT needs to include the possibility to launch the Embedded Bootloader in order to upload the new image in the download area.
At next reset, the STiRoT installs it, after authenticity and integrity verifications, and following the same principles described previously.

An example is shown in the How to start with STiRoT section.

8. Appendix STiRoT

8.1. Application development phase

The most efficient way to develop and debug an application is first to boot directly on user flash in the Open product state, by setting with STM32CubeProgrammer the UBE to 0xB4 and the SECBOOTADD to 0x0C000400 (by default the firmware execution offset is 0x0)

Figure 11. Application development

As long as the device is in Open state, the user flash can be erased without performing a regression and a debugger can be connected without performing a Debug authentication. Once validated, the Secure Boot path can be activated and following steps performed:

• Configuration of Debug Authentication and STiRoT (refer to How to start with STiRoT article).
• Encrypted and signed image generation.
• Provisioning of the device (option bytes programming, image(s) flashing and final product state setting).

8.2. STiRoT Configuration detailed description

Parameter	Hidden	Description	Additional controls/constraints
Product state minimal allowed	No	STiRoT is executed only if the device is in the chosen minimum life cycle state (Open, Provisioning, Provisioned, TZ-Closed, Closed, Locked).	This information is duplicated from option bytes in order to control that the option bytes are well configured.
Number of images managed by STiRoT	No	1: Firmware image only. Configuration selected for any application, which does not manage secret information. 2: Firmware and data images. As an example, in STiRoT_OEMuRoT bootpath, the data image contains the cryptographic keys of OEMuRoT boot.	Data image slot definition (size and offset) will be available trough STM32TrustedPackageCreator as soon as 2 images configuration is selected.
High speed clock activation	Yes	0 : 64 MHz, default configuration 1: 200 MHz, best speed supporting the full range of temperature 2: 250 MHz, max speed clock	-
Is the firmware full secure	No	Yes : the firmware booted is full secure. As example STiRoT_Appli provided in STM32H5 Cube. No : the firmware booted is made of a secure part and nonsecure part. As an example, STiRoT_Appli_TrustZone provided in STM32H5 Cube.	The size of the secure area inside the firmware execution area must be specified as soon as the firmware is not full secure. In this configuration, the image generation triggered by the post build command of the nonsecure project is preceded by an assembly command of the secure and nonsecure binaries.
Firmware execution area offset	No	Offset from begin of the user flash memory. It must me aligned on a sector start address.	No overlap allowed between execution areas and download areas. Firmware execution area cannot be mapped between the 2 download areas.
Firmware download area offset	No	Offset from begin of the user flash memory. It must me aligned on a sector start address.	No overlap allowed between execution areas and download areas. Firmware execution area cannot be mapped between the 2 download areas. Both firmware and data download areas can overlap. In this case, the installation of a data and firmware image in a single execution using the dependency feature is not possible.
Firmware area size	No	Size of the firmware. It must be a multiple of the sector size.	No overlap allowed between execution areas and download areas. Firmware slots definition should not exceed the user flash capacity.
Data area offset in HDPL2 OBkeys	No	Offset from the beginning of HDPL2 Obkeys area (0xFFD0900).	Range allowed from 0xFFD0900 to 0xFFD0BF0: no overlap with HDPL3 OBKeys. Parameter disabled for 1 image configuration.
Data slot size in HDPL2 OBKeys	No	Size of the data area in HDPL2 OBkeys. Maximum is 0x2F0.	Range allowed from 0xFFD0900 to 0xFFD0BF0: no overlap with HDPL3 OBKeys. Parameter disabled for the “1 image” configuration.
Data download area offset	No	Offset from begin of the user flash memory. It must me aligned on a sector start address.	Both firmware and data download areas can overlap. In this case, the installation of a data and firmware image in a single execution using the dependency feature is not possible.
Data download slot size	Yes	Offset from begin of the user flash memory. It must me aligned on a sector start address.	Must be 0x2000 for STM32H5 product (parameter hidden).
Size of the secure area inside the firmware execution area	No	Size of the secure part of the firmware image. It must be a multiple of the sector size.	Parameter disabled for the “firmware full secure” configuration. STiRoT configures the MPU to allow execution only for the secure part of the firmware. Then, it is up to the secure application to update (disable, reconfigure) the MPU configuration depending on its needs.
SRAM2 erasing in case of reset	Yes	Yes (default value) : the SRAM2 is automatically erased by hardware in case of reset. Ensure that all secrets are erased in case of reset. No: SRAM2 is not erased. Less secure configuration but it can be required when the application has no other possibility to manage persistent information in SRAM2.	This information is duplicated from option bytes in order to control that the option bytes are well configured.
SRAM2 ECC management activation	Yes	Yes (default value) : a reset is generated in case of ECC detection. ECC is a mechanism to prevent mechanisms prevent external attacks.No : ECC not managed. Less secure configuration but it can be selected if hardware attack is not possible.	This information is duplicated from option bytes in order to control that the option bytes are well configured.
Encryption key	No	Key used to encrypt the firmware and data images	When this key is regenerated, both firmware and data images must be processed with STM32TrustedPackageCreator “Image Gen” tab (STiROT_Code_Image.xml & STiROT_Data_Image.xml)
Authentication key	No	key used to authenticate the firmware and data images.	When this key is regenerated, both firmware and data images must be processed with STM32TrustedPackageCreator “Image Gen” tab (STiROT_Code_Image.xml & STiROT_Data_Image.xml)
Output File	No	Name of the output file	-

8.3. STiRoT Config.obk file format

• Important note: endianness: uint32_t 0x01234567 is represented in obk file as 0xx67452312
  

Offset	Size	Type	Description
0	4	uint32_t	sdp command header : destination address
4	4	uint32_t	sdp command header : data size address
8	4	uint32_t	sdp command header : encryption enabled/disabled (1/0)
12	32	array	SHA256 of the following data content (from offset 44 to 268)
44	1	uint8_t	Number of images managed by STiRoT
45	1	uint8_t	250 MHz / 200 MHz / 64 MHz : 2 / 1 / 0
46	1	uint8_t	Firmware full secure (1/0)
47	1	uint8_t	Jump into ST bootloader when no valid image(s)
48	4	uint32_t	Firmware execution area offset
52	4	uint32_t	Firmware download area offset
56	4	uint32_t	Firmware area size
60	4	uint32_t	Data area offset in HDPL2 OBkeys
64	4	uint32_t	Data slot size in HDPL2 OBKeys
68	4	uint32_t	Data download area offset
72	4	uint32_t	Data download slot size
76	4	uint32_t	Size of the secure area inside the firmware execution area (meaningful only when the firmware is not fully secure.
80	4	uint32_t	SRAM2 erasing in case of reset
84	4	uint32_t	SRAM2 ECC management activation
88	4	uint32_t	Product state minimal allowed (0x0000ED00,Open / 0x00001700,Provisioning / 0x00002E00,Provisioned / 0x0000C600,TZ-Closed / 0x00007200,Closed / 0x00005C00,Locked
92	70	array	Encryption private key (MCU Boot format)
162	2	array	Reserved
164	91	array	Authentication public key (MCU Boot format)
255	13	array	Reserved (Global alignment of OBKkeys data on 16 bytes)

8.4. STiRoT DA.obk file format

• Important note: endianness: uint32_t 0x01234567 is represented in obk file as 0xx67452312 L
  

Offset	Size	Type	Description
0	4	uint32_t	sdp command header : destination address
4	4	uint32_t	sdp command header : data size address
8	4	uint32_t	sdp command header : encryption enabled/disabled (1/0)
12	32	array	SHA256 of the following data content (from offset 44 to 108)
44	32	array	SHA256 of the DA root authentication public key
76	32	array	Permissions (cf DA Getting_started for more details)

8.5. STiRoT Data.obk file format

• Important note: endianness: uint32_t 0x01234567 is represented in obk file as 0xx67452312
  

Offset	Size	Type	Description
0	4	uint32_t	sdp command header : destination address
4	4	uint32_t	sdp command header : data size address
8	4	uint32_t	sdp command header : encryption enabled/disabled (1/0)
12	32	array	SHA256 of the following data content (from offset 44 to 108)
44	4	uint32_t	Version n of the firmware image
48	4	uint32_t	Version n-1 (previous) of the firmware image
52	4	uint32_t	Version n of the data image
56	4	uint32_t	Version n-1 (previous) of the data image
60	32	array	Reserved
92	16	array	Reserved

8.6. STiRoT execution status

The STiRoT is executed as a black box, but there is a way to verify the steps that have been executed and in case of an issue where the STiRoT execution has stopped.
For each HDPL Obkey, there are four bytes reserved for the status log. For further details, refer to the table below.

Item #	Executed step	Status coding	Description
1	STIROT_INIT_DONE	0x00000001UL	Device intialization done. STiRoT bootpath selected. STiRoT executed
2	STIROT_CONFIG_DONE	0x00000002UL	STiRoT configuration according STiRoT_Config.obk is verified to be correct in Obkeys HDPL1
3	STIROT_SECURITY_DONE	0x00000004UL	Security activated (MPU, SAU, GTZC, Tamper, Flash, RAM). Obkeys STiRoT configuration verified to be correct
4	STIROT_SLOT_PRIMARY_1_VALID	0x00000010UL	Authenticity and integrity verified for the user application FW image in the execution slot
5	STIROT_SLOT_PRIMARY_2_VALID	0x00000020UL	Authenticity and integrity verified for the data image in the HDPL2 Obkey secure storage
6	STIROT_SLOT_SECONDARY_1_VALID	0x00000040UL	Authenticity and integrity verified for the user application FW image in the download slot
7	STIROT_SLOT_SECONDARY_2_VALID	0x00000080UL	Authenticity and integrity verified for the data image in the download slot
8	STIROT_PARSING_DONE	0x00000100UL	Slots parsing done (process MCUBoot)
9	STIROT_INSTALLATION_DONE	0x00000200UL	Image in the download slot (1 or 2 images depending on config) are installed
10	STIROT_VALIDATION_DONE	0x00000400UL	Primary slots analysis completed to verify which image is valid (integrity and authenticity)
11	STIROT_JUMP_BL	0x00001000UL	At least one image is not valid -> Embedded Bootloader execution
12	STIROT_JUMP_APPLI	0x00002000UL	All images (1 or 2 depending on config) are valid, application execution
13	STIROT_NOJUMP	0x00004000UL	At least one image is not valid, but Embedded Bootloader execution is not allowed(option defined in STiROT_Config.xml)

The following figure shows an example of a discover done with STM32CubeProgrammer after completing an STiRoT provisioning with a product state set to CLOSED.
(To access to the Discover command, follow STM32CubeProgrammer => Debug Authentication => Discover => the Log window displays the details)

Figure 12. STM32CubeProgrammer Discover command

The STiRoT is executed in HDPL1, so the status given by the Discover command corresponds to this isolation level.
In this example, the indicated code is 0x2737.

• The digit 0x0007, is obtained by the sum of item 1, 2 and 3 of the above table. It means that all these operations have been executed successfully (STIROT_INIT_DONE; STIROT_CONFIG_DONE ; STIROT_SECURITY_DONE).
• The digit 0x0030 is obtained by successful execution of item 4 and 5 of the above table.
• The digit 0x0700 is obtained by successful execution of item 8, 9, and 10 of the above table.
• The digit 0x2000 is obtained by successful execution of item 12 of the above table => so the jump to user application (STIROT_JUMP_APPLI )