SBSFU legacy

This wiki page depicts SBSFU legacy, which is an ST implementation of Secure Boot and Secure Firmware Update security feature.
SBSFU legacy is not based on MCUboot open-source software (refer to mcuboot).

Examples of SBSFU legacy are provided in the X-CUBE-SBSFU Expansion Package.
The X-CUBE-SBSFU Expansion Package comes with examples running on the STM32L4 Series, STM32F4 Series, STM32F7 Series, STM32G0 Series, STM32G4 Series, STM32H7 Series, STM32L0 Series, STM32L1 Series, and STM32WB Series. On STM32WL Series, example is provide within STM32Cube WL Firmware Package.

A detailed description of SBSFU legacy is provided in UM2262

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. SBSFU presentation

SBSFU example 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.

Keys dedicated to authentication and confidentiality are OEM assets and can be customized by OEM during the provisioning process.
Refer to UM2262 for more details on cryptography operations

3. 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 SBSFU code.
• Make SBSFU 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 SBSFU 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: Firewall, PCROP, HDP, WRP, Tampers, Security option bytes, OB keys, RDP, MPU, . Please refer to the reference manual of the series for a detailed presentation of the mechanisms.

Refer to UM2262 for more details hardware mechanisms configured for each series.

4. SBSFU : next

There is no longer evolutions on SBSFU legacy which is now replaced by OEMiRoT/OEMuRoT based on MCUboot open-source software (refer to mcuboot) for all new series.

This new implementation allows to provide 1 or a 2 boot stages strategy :

1. 1 boot stage: The Root of Trust is immutable
2. 2 boot stages: The Root of Trust is based one immutable part + one updatable part

Refer to https://wiki.st.com/stm32mcu/wiki/Security:SBSFU_by_mcuboot wiki article for more detailsOEMiRoT + OEMuRoT. the OEMiRoT controls the authenticity and the integrity of the application before its execution.

2 boot stages: STiRoT + OEMuRoT Immutable and Updatable ROT. STiRoT controls the authenticity and the integrity of the OEMuRoT the application before its execution. OEMiRoT controls the authenticity and the integrity of the application before its execution. 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. - OEMiRoT -

based soltuiFor our recent seriesOption 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.

4.1. 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.

5. 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.

6. 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 ...)