|
Coming soon |
1. What is SBSFU
Secure Boot and Secure Firmware Update is a STM32Cube based expansion package (see STM32Cube expansion package article) showcasing utilization of various STM32 security features to create a product capable of performing controlled secure boot and updating it's firmware reliably, eliminating threats of loading unauthorized or malicious code.
The SBSFU is constantly evolving, adding support for new microcontroller series and features while fixing identified vulnerabilities of previous versions.
It's however not a definitive and universal solution covering all the possible application needs, rather a proven starting point for customer-side development.
For most STM32 lines the SBSFU comes in two variants. Single-slot for maximum image size and dual-slot for more image manipulating options such as over-the-air.
The use of STM32Cube ensures easy portability of the code to similar STM32 devices which are not supported directly.
2. Components of SBSFU
SBSFU consists of several sub-projects. The secure engine, the SBSFU itself and the application projects. There may be just single application, but presumably in several versions.
2.1. Secure Engine
Using a service of Secure Engine it's possible to externalize critical secure operations related mainly to cryptography and improve overall security while avoiding the need for both SBSFU and application to implement cryptographic functions.
Other functions may include secure manipulation with Flash memory, holding secure state-machines and key management.
The Secure Engine is a middleware used by other software components and may be configured to feature various cryptographic algorithms, symmetric and asymmetric. It's running in an isolated enclave, as permitted by the features of the used STM32 MCU, either firewall or MPU. Code used in the SE enclave is supposed to be trusted.
2.2. Secure Firmware Update
Third major component of the SBSFU is the update capability. It's relying on Secure Boot for RoT foundations and on the Secure engine to provide trusted services of cryptography and image manipulation.
It's expected that a new firmware image is made available and a communication must be established between the SBSFU equipped device and the remote entity holding the image.
2.3. Secure Boot
The Secure Boot is an immutable code that checks the device static protections, sets volatile protections and then makes sure the code it gives control to ( application ) is not corrupted. A boot protection such as BOOT_LOCK is used to prevent attacker from diverting the boot from the intended starting address.
The Secure Boot is an implementation of the generic Root of Trust principle, which introduces a fixed (immutable) boot location and a chain of software components that use cryptographic means to authenticate each subsequent component, including integrity check.
Practical technical solution of this goal depends on the security features available in each particular series. Depending on STM32 in particular, following are used:
- RDP ( + BOOT_LOCK )
- First step is to disable external access and fix the boot address to the secure boot location
- Also locks option bytes with permanent protection settings and access restrictions
- WRP
- Protection of the trusted code and other non-volatile memory locations
- Settings of Firewall and MPU are trusted and protected
- MPU
- Protection of peripheral settings in registers
- Shielding other address space locations
- HDP/Firewall
- Firewall (where available) acts as a secure gateway to Secure Engine and other sensitive libraries
- HDP is used to prevent jumping back to initialization code with goal of changing the trusted settings
- Cryptography
- Used to validate the User Application before putting it in control
For the description of the abbreviations see Guide to use specific security feature article.
2.4. Secure Firmware Update
Sharing the same project with Secure Boot, the update part is activated when there is no active image, or if there is a new image in the Download slot and needs to be swapped with the Active image.
2.4.1. Communication interface
In the basic example provided within the X-CUBE-SBSFU[1] package the default method of firmware delivery is an USART serial interface using a subset of the YMODEM protocol. While this delivery method is still relevant, it's expected that many adopters of the SBSFU will eventually adapt the SBSFU to use one of many alternative interfaces, or even an external storage to obtain the new firmware image.
The USART is practical for demonstration purposes because every ST development board features an ST-link with virtual serial port established using USB interface and this communication interface has very little software overhead, leaving more code space for firmware image.
2.4.2. Cryptographic protection of firmware image
Most communication interfaces do not inherently guarantee neither authenticity nor confidentiality of the communication. In such case it's necessary to provision these protection cryptographically.
Following schemes are supported in the X-CUBE-SBSFU[1] package:
| Features | Asymmetric with AES encryption | asymmetric w/o encryption | Symmetric (AES-GCM) |
|---|---|---|---|
| Confidentiality | AES-CBC | None | AES-GCM |
| Integrity | SHA256 | SHA256 | AES-GCM |
| Authenticity | ECDSA signed | ECDSA signed | AES-GCM Tag |
| Keys needed in device | private AES-CBC, public ECDSA | public ECDSA (X.509 certificate option) | private AES-GCM |
2.4.3. Firmware image
Firmware image consists of the firmware binary (sometimes also referred as image) and a firmware header with information meta data. The header should include:
- random nonce value
- firmware size
- product identification
- firmware version
- certificate in case of X.509 based authentication
- supplemental information about binary encryption
- binary hash
- valid signature
Existence of elaborate Image header implies existence of a Firmware Image preparation tool. Such utility is included in the X-CUBE-SBSFU[1] package in two forms. As a Windows executable and as a set of Python scripts. The Python scripts not only work on alternative OS, but allow customization of header including use of alternative encryption schemes.
Possibilities of dealing with the firmware image depend on the chosen configuration model. In case of single image slot the SBSFU only can manage the download and application must be erased before programming the new image. If download fails, it must be restarted from the beginning.
With more than one slot it's possible to:
- Download firmware during other application functionality execution and minimize downtime.
- Use application code to load contents of a new slot.
- Validate the new download integrity in application (search IMAGE_STATE_HANDLING).
- Resume interrupted downloading, partial image load option.
- Roll-back to previous version in case of failure.
2.5. Key management services
An optional part of the SBSFU is a KMS. Without a KMS of some sort, the cryptography involved in the SBSFU functionality must be carried out completely with static keys defined before SBSFU image creation. Such keys will be, in accordance with the SBSFU nature, immutable.
KMS middleware as available in the selected SBSFU implementations, implements a subset of the PKCS #11 API functions necessary to deal with keys and certificates involved in each particular SBSFU supported cryptographic scheme.
- Basic key object operations (new/update/delete)
- AES encrypt/decrypt
- HASH
- ECDSA ( and RSA ) signature verification (signing)
- Generation/derivation of key
KMS uses services of a secure element, such as STSAFE-A110 to protect the key storage hierarchy. Not every STM32 capable of SBSFU can manage to support KMS, mainly due to memory size limitations.
3. Getting started with STM32 and SBSFU
The SBSFU is no simple topic and there is no easy start. There are however some advice to be given.
- Download the latest SBSFU package from ST website.
- X-CUBE-SBSFU[1]
- The package includes all existing SBSFU for ARM-v6 and ARM-v7.
- This doesn't mean all are covered, but it's always possible to pick similar product and make some adjustments.
- Choose a supported board to start with
- Preferably a Nucleo based on general purpose MCU (like for example STM32G071 or STM32G474)
- If not sure pick one where both 1-slot and 2-slot examples are available.
- Get it working.
- Follow steps in the readme file of the selected project.
- Configure settings in app_sfu.h for lower security for easier start
- Familiarize yourself with the SBSFU
- Learn how to configure different security settings.
- Learn how to change the memory mapping.
- Use the knowledge to your benefit.
3.1. Build
The SBSFU project supports choice of the development tools, either MDK Keil, IAR EWARM or CubeIDE.
Either way it's necessary to build SECoreBin first, SBSFU project next and the UserApp concludes the image creating process, all assisted with the batches and scrips that concatenate the binaries and create the update image.
It's possible to start the build right away, but it may be worthwhile to see where the permanent keys in the image built are inserted to the final image. Key values are prepared in the "Binary" subfolder of the SECoreBin project.
What keys are used (and which of the available cryptography schemes) is then configured in the header file se_crypto_config.h. Based on these settings, changes are made in rest of the project to harmonize the crypto scheme by actions of the prebuild.bat.
Most SBSFU configuration settings are then concentrated in the app_sfu.h header file, containing mainly SBSFU security settings. By default most security countermeasures are enabled for testing and demonstration purposes, with notable exception of RDP, which is only set to level 1.
For easier debugging, modification and other development, you can disable security using #define SECBOOT_DISABLE_SECURITY_IPS (which is by default commented out in the app_sfu.h).
Finally the UserApp project is built. The postbuild action of the UserApp project is to concatenate the binaries and generate "sfu" file later used to upload a UserApp binary by the means of the SBSFU process.
3.2. Linker configuration
With three projects sharing one address space and various security settings being imposed on the memory it's imperative to manage the linker settings rigorously.
There is a central place to modify the regions and ranges for the linker in a dedicated folder, with a set of files for each supported development environment. These global settings are then included in the linker settings of the individual projects so the projects can share the same information. Settings for the MPU, WRP and eventually other security mechanism are automatically updated when the ranges and sizes of the protected regions change. But of course the algorithm updating the settings is limited and cannot pass some constraints. It's always recommended to check the settings correctness after significant change or before a validation or another development milestone.
Mind that even change of optimization level will affect the code size and subsequently may influence final code addresses.
Some may choose not to change the SBSFU (at least initially) and only develop their own UserApp. The UserApp must then be configured to:
- Run from the "Active slot" memory region
- Avoid using SRAM reserved by the SECorebin, from the start address up to
...SE_region_RAM_end... - In case of firmware encryption make arrangements to have padding for multiple of encryption block size
These settings can be reused from the included example UserApp.
SBSFU Overview - first video in the series
Playlist about STM32 security ecosystem and place of SBSFU within its context
Playlist about secure cloud connectivity using SBSFU and secure element STSAFE-A110
5. STM32 compliant with SBSFU
As of version 2.6.0, the SBSFU package includes examples for the following STM32 boards and devices:
- B-L4S5I-IOT01A
- B-L475E-IOT01A
- P-NUCLEO-WB55.Nucleo kit
- STM32F413H-Discovery
- STM32F769I-Discovery
- STM32G031K8 Nucleo
- STM32G071RB Nucleo
- STM32G474RE Nucleo
- STM32H750B-Discovery
- STM32H753ZI Nucleo
- STM32H7B3I-Discovery
- STM32L073RZ Nucleo
- STM32L152RE Nucleo
- STM32L432KC Nucleo
- STM32L476RG Nucleo
- STM32L496G-Dicovery
- STM32WB5MM-DK
Also STM32WL55JC Nucleo is supported, but the source files are within the actual device STM32Cube package.
The following series have an application called SBSFU in their respective STM32Cube packages, but this is quite different architecture, based on TrustZone and TF-M.
- STM32L5
- STM32U5
6. Resources
SBSFU user manual[2]
SBSFU integration guide[3]
SBSFU user manual for STM32WL series[4]
SBSFU integration guide for the STM32WL series[5]
SBSFU on TrustZone cabable STM32[6]