SBSFU by MCUboot

This wiki page depicts the SBSFU by MCUboot, which is an open-source implementation of the secure boot and secure firmware update feature.

This implementation replaces the SBSFU legacy implementation no more deployed on the latest STM32 series.

For the STM32L5, STM32U5 and STM32WBA5 series, examples of the SBSFU by MCUboot application are provided in STM32Cube firmware packages under SBSFU names (Secure Boot and Secure Firmware Update). Refer respectively to UM2671, UM2851 and UM3128 that are covering SBSFU application examples on these series.

For other applicable STM32 series (STM32U0, STM32H5, STM32H7RS...), examples of the SBSFU by MCUboot application are provided in STM32Cube firmware packages under OEMiRoT and OEMuRoT names (OEM immutable and updatable Root of Trust). For more details, refer to OEMiRoT and OEMuRoT wikis articles of the corresponding series ( OEMiRoT for STM32U0 OEMiRoT OEMuRoT for STM32H5, OEMiRoT OEMuRoT for STM32H7S...).

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

1. Product security overview

A device deployed in the field operates in an untrusted environment and it is therefore subject to threats. To mitigate this risk, 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 common place for connected devices, and must be executed in a secure way.

Security solutions must be designed 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 limiting nongenuine external accesses (for example, by accessing the device physically through JTAG) and nongenuine internal accesses from other embedded non-secure processes.

2. OEMiRoT presentation

OEMiRoT stands for OEM immutable Root of Trust.

OEMiRoT 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 that the firmware image is coming from a trusted and known source to prevent unauthorized entities to install and execute the code.

Keys dedicated to authentication and confidentiality are OEM assets and can be customized by the OEM during the provisioning process.
Refer to the OEMiRoT wiki articles of each series for more details.

3. OEMuRoT presentation

OEMuRoT stands for OEM updatable Root of Trust.

OEMuRoT example provides the same services as OEMiRoT.

The main difference is that OEMuRoT is updatable, contrary to OEMiRoT, and therefore shall execute as a second boot stage, following an iRoT (immutable Root of Trust: STiRoT or OEMiRoT).

Refer to the OEMuRoT wiki articles of each series for more details.

4. SBSFU presentation

SBSFU examples are equivalent to OEMiRoT examples.

5. 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, to improve security robustness.

The security strategy is based on the following concepts:

• Ensure a single entry point at reset: force code execution to start with OEMiRoT code.
• Make OEMiRoT 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 OEMiRoT code during his execution.
• Remove JTAG access to the device.
• Monitor the system: intrusion detection.

Depending on the STM32 series, different hardware mechanisms can be configured to implement the security strategy such as: Boot lock, HDP, WRP, anti-tampers, security option bytes, OB keys, RDP, Product State, MPU, RAM ECC, RAM erase on secret. Refer to the reference manual of the series for a detailed presentation of the mechanisms.

Refer to the wiki OEMiRoT/OEMuRoT pages of the related STM32 series for more details on relevant hardware mechanisms configured for the related STM32 series.

6. Features list

The main features of the OEMiRoT/OEMuRoT are (depending on series):

• Image slots mode
  • Single slot: The downloaded image is in the same memory slot as the installed image. The new downloaded image overwrites the previous installed image. During installation, the new image is decrypted in place. This mode allows to maximize the image size. However this mode requires an external loader application, as the image application can not manage the download of new image during its execution.
  • Dual slot: The downloaded image and installed image are in different memory slots. Image size is reduced. However the application can directly manage the download of new image, during its execution.
• Image upgrade strategy (Dual slots only):
  • Overwrite strategy: During installation, the new image is decrypted and overwrites the previously installed image. Installation is definitive.
  • Swap strategy: During installation, the new image and previous image are swapped (new image is decrypted, previous image is re-encrypted). The new image shall be confirmed by the application, else it will be reverted at next boot.
• Flexible image number
• Image version anti-rollback
  • New image with lower version than previous image is not accepted for installation.
• Cryptography
  • ECDSA or RSA asymmetric cryptography for image authentication.
  • SHA cryptography for image integrity check.
  • AES-CTR cryptography for image encryption, with symmetric key encrypted in ECIES or RSA-OAEP provided in the image itself.
  • HW cryptography acceleration
• Accelerated boot
  • Image signature verification at first boot, then image signature skip for further boot thanks to management of SHA reference.
• Fast wake-up from stand-by