Introduction
- If you have already selected the STM32H7RS security solution you need or if you want to try out the different proposed solutions, please refer to chapter1.
- STM32H7RS provide different options to implement your application. In chapter2 we are proposing some criteria to select the security configuration most suitable for your need.
1. Reference examples
A set of practical examples is proposed to get an overview of and to understand the STM32H7RS security solutions.
These practical examples are based on the boards, tools and code examples provided by ST.
For a self-designed board, all the examples are valid as long as the same external flash and pin mapping as for the Discovery or the Nucleo board have been defined. If it's not the case the examples need to be adapted (external memory flasher, external memory and pin mapping).
More information about the product, including the related tools and software, can be found on the official ST.com pages: STM32H7R3/7S3 and STM32H7R7/7S7
For the examples listed below, each step is described in detail.
It is advised to start with these examples before making your own trials or using other security related examples available in the STM32CubeH7RS.
Product Series | ![]() |
![]() |
Prerequisite | Introduction article | ||
---|---|---|---|---|---|---|
Development Boards | NUCLEO H7S3L8 (MB1737) | DISCOVERY H7S78 (MB1167) | - | - | ||
Embedded flash size | 64k | 64k | - | - | ||
On board external flash size | 256-Mbit | 1-Gbit | - | - | ||
Debug Authentication | ||||||
Debug Authentication and Firmware update example | Link to How To | Link to How To | STM32CubeH7RS | Link | ||
Code Confidentiality | ||||||
Code confidentiality on external flash example | ^ | Link to How To | STM32CubeH7RS | Link | ||
Immutable Root of Trust (iRoT) | ||||||
STiRoT example | * | Link to How To | STM32CubeH7RS | Link | ||
STM32CubeMX STiRoT example | ^ | Link to How To | STM32CubeMx_V6.11.0 or later | Link | ||
STiRoT-OEMuRoT example | * | Link to How To | STM32CubeH7RS | Link | ||
OEMiRoT example | * | Link to How To | STM32CubeH7RS | Link |
- Note:
- ^ : supported but no dedicated wiki article example available
- * : supported for STM32Cube_FW_H7RS_V1.1.0 or later version. The examples provided for the Discovery board needs to be adapted for a Nucleo board, refer to the readme available in \Projects\NUCLEO-H7S3L8\Applications\ROT
1.1. Secure Boot
The secure boot and related root of trust is implicitly used in all the proposed " How to start" step by step examples.
The Security features on STM32H7RS MCUs wiki article also gives technical explanations about the possible boot paths.
The Secure Boot STM32H7RS How to Introduction wiki article gives details about the boot paths used in the different provided getting started examples.
Using STM32CubeMx, a project can be generated from scratch for a chosen boot path.
The table above indicates which example is available to show how to proceed.
1.2. Debug Authentication
It is key to understand how to set the Debug Authentication (DA) in order to define the appropriate rights to reopen the debugger once closed.
- It is strongly advised to read the Debug Authentication for STM32H7RS wiki article.
- The Debug Authentication on STM32H7RS how to Introduction wiki article summarizes all the technical know-how to be read before executing the getting started.
- The How to start with DA access on STM32H7RS wiki article explains step by step how to perform a Debug opening and a Firmware Update.
- Two examples are described in this article
- The first example, starting with a device provisioned using the STiRoT example provided in the STM32CubeFW.
- The second example, starting with a device provisioned using the OEMiRoT example provided in the STM32CubeFW.
- Two examples are described in this article
1.3. OEMiRoT
An OEM can develop its own customized Immutable Root Of Trust (OEMiRoT).
It is advised to read the Security features on STM32H7RS MCUs wiki article to understand the different possible Root of Trust.
- The OEMiRoT STM32H7S How to Introduction wiki article gives a short technical introduction to read before executing the getting started.
- The How to start with OEMiRoT on STM32H7S wiki article provides a step by step example based on the STM32CubeH7RS.
1.4. STiRoT
An immutable root of trust defined by ST is included for the STM32H7S series.
It is an embedded firmware stored in the system flash and it cannot be modified.
It is advised to read the Security features on STM32H7RS MCUs wiki article to understand the different possible Root of Trust.
- The STiRoT STM32H7S How to Intro wiki article gives a short technical introduction to read before executing the getting started.
- Two getting started examples are proposed.
- The How to start with STiRoT on STM32H7S wiki article provides a step by step example based on the STM32CubeH7RS.
- The How to start with STiRoT-OEMuRoT on STM32H7S wiki article provides an example for two secure boot stages based on the STM32CubeH7RS.
2. How to choose the security solution you need?
For a product embedding STM32H7RS, very different security solution is required depending on what needs to be protected at which level and which regulation or certification this product has to be complaint to.
The requested security level can be categorized into several profiles:
- Without security at all
- Confidentiality of the developed application
- Debugger access control
- Security for IOT products (Internet of Things)
- Note: It is advised to read the application note: Introduction to security for STM32 MCUs, AN5156.
- Note: The available security features of the STM32H7RS devices are described in the article: link
2.1. Without security at all
- It could be valid for development phases or demonstrators.
- But obviously, the know-how of the developed code and the integrity of the product are not protected.
- Furthermore, the product hardware can be reused to execute any code.
- Of course, it is not advised for a commercial product
2.2. Confidentiality of the developed application
Confidentiality is the protection of sensitive information from being disclosed to unauthorized parties.
- When the product is configured, only authorized people should be able to access to the developed code content or any sensitive assets.
- On the other hand, confidentiality alone don't protect against different types of attacks, for instance:
- Don't protect against unauthorized code to be executed (e.g. malware injection)
- Don't protect against reinstallation of previous code revision (rollback)
- Don't protect against damages blocking the product to operate correctly (DOS: Denial Of Service)
- Don't protect the reuse of the product for other usages
- Don't protect the product against side channel attacks
- For an example with code confidentiality on external flash:
- Refer to chapter1
- Or use the direct link to the step by step example Link to How To
2.3. Debugger access control
The most obvious access to the device and content is through the debugger (e.g. JTAG/SWD).
The PCB design can be done so that the physical access to the debugger is very difficult.
But depending on the product it could be necessary to keep a solution to access to the debugger.
In any situation, the possibility to close the debugger and allow the reopening only in a very good controlled way is key for the product security.
For the STM32H7RS this feature is provided through the debug authentication.
Refer to the table ... for link to more explanations.
2.4. Security for IOT products (Internet of Things)
Security should be considered for any digital device but is mandatory when the device embeds sensitive data (e.g. people information), is used in a critical environment (e.g. motor control) or can disturb other connected devices.
Connected devices are obviously more subject to attacks.
Attacks on unprotected of not well protected devices can also impact other connected devices even if well protected.
(for instance, DOS (Deny Of Service) attacks on servers).
To limit the risks, regulations are introduced to ensure security for all new IOT devices.
In Europe Radio Equipment Directive (RED) and Cyber Resilience Act (CRA) regulations are coming soon.
- The recent STM32 products are designed to be ready to fulfil the security regulations.
- Mandatory features are a Secure Boot and a Secure Firmware Update.
- The Secure Boot ensures that only unmodified and allowed codes are executed.
- The Secure Firmware Update ensures that only new unmodified codes are installed (with or without version control). A new code can be needed for firmware evolution but also if applicable to fix a vulnerability.
- Mandatory features are a Secure Boot and a Secure Firmware Update.
- For STM32H7RS two options are proposed to support Secure Boot (SB) & Secure Firmware Update (SFU).
- The STiRoT (ST Immutable Root of Trust) is a SB & SFU solution embedded in all STM32H7S devices (H7S are devices supporting embedded hardware accelerator).
- It targets SESIP level 3 certification.
- STiRoT is natively embedded in the device and can't be modified (immutable).
- The ST provided solution is using the best of the HW solution and is ready to be used reducing the development cost & effort.
- A customer can build his own security solution at the top of the STiRoT. To obtain the SESIP level 3 certification, only the added code and data needs to be certified.
- To certify a product, the significant costs need to be considered: certification lab costs, platform preparation with security expertise (not present in all companies), evaluation target documentation to provide. The STiRoT reduces drastically such costs.
- The OEMiRoT is a SB & SFU solution developed by a customer or an OEM.
- For STM32H7RS, ST is providing an OEMiRoT source code example (STM32CubeFW) that can be modified for own requirements.
- This code must fit in the 64kB user Flash of the STM32H7RS.
- OEMiRoT is installed in user flash and when protections are set becomes an immutable customized Root of Trust.
- The STM32H7RS hardware is built to reach SESIP Level 3 certification also with an OEMiRoT security solution. But since OEMiRoT is a customized solution, it's the customer's responsibility to design a solution for his targeted security level and if applicable certification level.
- The STiRoT (ST Immutable Root of Trust) is a SB & SFU solution embedded in all STM32H7S devices (H7S are devices supporting embedded hardware accelerator).
- Note: STM32H7RS embeds an Arm Cortex-M7 that doesn't support TrustZone. Other ST products based for instance on an Arm Corte-M33 benefit of this additional isolation between two separate running application code.
2.5. Security criteria table
The following table can also help to define which security solution is needed for a defined customer product.
Security Criteria | Comment | Security solution | DA | STiRoT | OEMiRoT/uRoT | Practical example |
---|---|---|---|---|---|---|
Confidentiality | Code know-how and sensitive data protection | Encryption | - | - | - | Link to How To |
Hardware hijack | Prevent reuse of HW to run other application | Debug Authentication | Introduction article / Practical example | - | - | |
Debugger (SWD/JTAG) closure | Prevent attacks using the debugger | - | - | |||
Debugger opening to allow regression | The owner of the password can perform a full re-initialization (regression) | - | - | Example1 / Example2 | ||
Debugger opening to allow regression or debug | Code debug and step by step execution by the owner of the key and certificate | - | - | Example1 / Example2 | ||
Give debug opening permission to OEM or in the field | Give specific authorization using a dedicated certificate | - | - | *Example | ||
Anti-rollback | Prevent re-install of old FW version | Root of Trust Bootpath introduction | - | - | - | *Example |
Only authorized code execution | Malware protection (code confidentiality included) | - | Introduction | Introduction | STiRoT_CubeMx / STiRoT / OEMiRoT | |
Secure Boot one stage | Secure Boot and encrypted application execution after authentication and integrity verification | - | Introduction | Introduction | STiRoT_CubeMx / STiRoT / OEMiRoT | |
Secure Boot two stages | Additional second customized secure bootstage | - | - | - | Example | |
Secure Firmware Update | Encrypted FW is only installed after authenticity and integrity verification | - | - | - | Example1 / Example2 | |
Secure Firmware Install | Installation of defined amount of devices in an unsecure environment, controlled through HSM license | SFI | - | - | - |
- Note: * Example provided for another STM32 family product but also valid for STM32H7RS.
- Note: HSM stays for Hardware Security Module, for more details refer to https://www.st.com/en/development-tools/stm32hsm-v2.html