STiRoT

This wiki page depicts STiRoT, which is an ST implementation of Secure Boot and Secure Firmware Update security feature.

1. Product security overview

A device deployed in the field operates in an untrusted environment and it is therefore subject to threats and attacks. To mitigate the risk of attack, the goal is to allow only authentic firmware to run on the device. Allowing the update of firmware images to fix bugs, or introducing new features or countermeasures, is commonplace for connected devices, but it is prone to attacks if not executed in a secure way.

Consequences may be damaging such as firmware cloning, malicious software download, or device corruption. Security solutions must be designed in order to protect sensitive data (potentially even the firmware itself) and critical operations.

Typical countermeasures are based on cryptography (with an associated key) and on memory protections:

• Cryptography ensures integrity (the assurance that data has not been corrupted), authentication (the assurance that a certain entity is what it claims to be) and confidentiality (the assurance that only authorized users can read sensitive data) during firmware transfer.
• Memory protection mechanisms prevent external attacks (for example, by accessing the device physically through JTAG) and internal attacks from other embedded nonsecure processes.

2. STiRoT presentation

STiRoT stands for ST immutable (unchangeable) Root Of Trust and acts as a first boot stage.

STiRoT is embedded in an immutable area of the system and provides two services:

• The Secure Boot (root of trust services) is an immutable code, which is always executed after a system reset (1). It activates STM32 runtime protections and then, it verifies the authenticity and integrity of the Application (2) code before every execution (3).

• The Secure Firmware Update application is an immutable code that detects that a new firmware image is available. It checks its authenticity (1), then checks the integrity (2) of the code before installing it after decryption (3).

Cryptography is used to ensure confidentiality, integrity, and authentication.

• Confidentiality is implemented to protect the firmware image, which may be a key asset for the manufacturer. The firmware image sent over the untrusted channel is encrypted so that only the devices having access to the encryption key can decrypt the firmware package.
• Integrity is verified to check that the received image is not corrupted.
• Authenticity checks verify that the firmware image is coming from a trusted and known source, in order to prevent unauthorized entities to install and execute code.

For STiRoT, the selected configuration is:

• ECDSA-256 asymmetric cryptography for image authenticity verification,
• AES-CTR-128 symmetric cryptography with key ECIES-P256 encrypted for image confidentiality,
• SHA 256 cryptography for image integrity check.

Keys dedicated to authentication and confidentiality are OEM assets and can be customized by OEM during the provisioning process.

2.1. 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 possible attacks.

Secure software coding techniques such as doubling critical tests, doubling critical actions, checking parameter values, and testing a flow control mechanism, are implemented to resist to basic fault-injection attacks.

The security strategy is based on the following concepts:

• Ensure single entry point at reset: force code execution to start with STiRoT code.
• Make STiRoT code and secrets immutable: no possibility to modify or alter them once security is fully activated.
• Create a protected and isolated enclave to store secrets.
• Limit surface execution to STiRoT code during his execution.
• Remove JTAG access to the device.
• Monitor the system: intrusion detection and SBSFU execution time.

Depending on the STM32 series, different hardware mechanisms can be configured to implement the security strategy such as: HDP, WRP, Tampers, Security option bytes, OB keys, Life cycle, MPU, TrusteZone, SAU, GTZC. Please refer to the reference manual of the series for a detailed presentation of the mechanisms.

2.2. Startup sequence

Option bytes should be configured to force the boot on STiROT. This configuration is specific to each STM32 series. At reset, the following sequence will be executed.

Step 5 is optional and can be disabled throught STiRoT configuration. When not allowed, a reset is generated instead of jumping to the loader.

2.3. Use cases

There are two possible cases:

• 1 boot stage: Immutable ROT.

In this use case, most of the time STiRoT is configured to manage only one image: the user application.

At reset, STiRoT detects if a new user application is available in the download area, checks its authenticity and checks the integrity of the code before installing it (after decryption) in the execution area. After a successful verification (integrity and authenticity of the user application in the execution area), the STiRoT executes the user application.

• 2 boot stages: Immutable and Updatable ROT.

STiRoT is configured to manage two images, the uROT code and its associated secret data, such as authentication and encryption keys.

At reset, STiRoT manages the installation of a new uROT image, if any. After a successful verification of the execution area (integrity and authenticity), the STiRoT executes the uROT.

The uROT is in charge of managing the installation of a new user application, if any. The uROT verifies the integrity and authenticity of the application, using its own secret keys, before executing it.

3. Image generation

STiRoT manages images at MCUBoot format including:

• a header,
• the encrypted firmware or data binary,
• some metadata information (TLV format: Tags Length Value) allowing the control of the image (SHA256, encryption key ...), and
• a magic to trigger the installation.

Further information about the MCUBoot open source software is available at mcuboot.com.

A PC tool STM32TrustedPackageCreator is provided to generate such an image, based on the binary generated at the end of the compilation process.

The following figure shows the firmware binary image generation.

The following figure shows the data image generation.

4. Provisioning

The product provisioning to activate the boot path STiRoT is done following the three steps below:

• Step 1, STiRoT configuration definition. At this stage, the number of images managed (firmware image only, or firmware and data images), the location of the images and cryptographic keys are defined.
• Step 2: Image generation at MCUBoot format.
• Step 3: Option bytes, OB keys (when supported) and Image programing in the device.

A provisioning.bat script is provided in Firmware/Projects/Board/ROT_Provisioning/STiRoT folder. It guides the user all along the provisioning process. The provisioning process configures the device in the state selected by the user (It depends on the series: product state, RDP ...)