This article contains an overview of the security features[1] available on STM32H7RS MCUs. The table below contains detailed information based on the different product lines.
Security features embedded on: | ![]() |
![]() |
---|---|---|
Secure Boot and Firmware Update | ||
Boot sequence with OEMiRoT | NO | YES |
Boot sequence with STiRoT | NO | YES |
Isolation | ||
Temporal isolation | YES | YES |
Cryptography | ||
ST crypto lib | YES | YES |
Silicon device life cycle | ||
Product State | YES | YES |
Debug authentication | YES | YES |
Secure manufacturing | ||
SFI | YES | YES |
SFIx | NO | NO |
Provisioning | YES | YES |
Secure storage | ||
OBKeys | YES | YES |
Using SAES for secure storage | NO | YES |
1. Secure Boot and Firmware Update
As soon as the code embedded by a product has to be secured, it requires to embed a root of trust (RoT).
This RoT has to take care of next stage security ensuring almost its integrity and authenticity.
By definition, a RoT must be based on an immutable code handling the reset of the platform (iRoT).
The RoT is the foundation to build a secure product.
1.1. Introduction
STM32H7R and STM32H7S allow the development of the Root of Trust based on boot lock and HDP features allowing to implement a proprietary solution. This solution is called OEMiRoT.
The STM32H7S versions of the platform brings full cryptography configuration and also embed a ready to use immutable RoT (STiRoT) providing natively a root of trust. The STiRoT covers Secure Boot and Secure Firmware Update for its next updatable boot stage level.
When STiRoT is selected (only available on STM32H7S), its next boot stage (OEMuRoT or Application)
- non volatile version is stored in external memory encrypted with a unique key per device only known by STiRoT itself
- non volatile version is loaded in SRAM by a code present in the UserFlash (iLoader + Ext mem manager).
- is verified on each boot using OEM specific keys
- is authenticated at update time using OEM specific keys
- could be the final application ==>in that case limited to SRAM available size
- could be an intermediate boot stage (for large applications), to help managing the application secure boot and secure firmware update
When an intermediate boot stage is used (OEMuRoT), it is suppose to manage the Secure boot and secure firmware update for the application
The below diagram shows different possible boot path.
1.2. Boot sequences
The below figure shows the expected execution sequence considering deployed products (with a PRODUCT_STATE different than Open)
- On each reset, the first executed code is the RSS (Root Secure Services).
- RSS reads iROT_SELECT option byte to select between STiRoT and OEMiRoT. It will then launch the User Flash in case OEMiRoT is selected or launch the STiRoT from system memory.
1.3. Boot sequence with OEMiRoT
Wording: STiRoT or OEMiRoT cover the SBSFU (Secure Boot & Secure Firmware Update) features of the platform.
The OEMiRoT and OEMuRoT can be generated from the CubeFW. The source code is based on mcuboot from TrustedFirmware.org.
More details on OEMiRoT or OEMuRoT can be read from here: OEMiRoT, OEMuRoT on H7S [2]
1.4. Boot sequence with STiRoT
The STiRoT offered with secure services STM32H7S is based on mcuboot from TrustedFirmware.org.
Only the version STM32H7S (crypto parts version) support the STiRoT.
In case of STM32H7S, RSS evaluates the iROT_SELECT option byte setting, to determine whether STiRoT is the selected boot option.
STiRoT manages the uRoT lifecycle thanks to iLoader+Ext Mem Mgr elements that are hosted in User Flash to manage the different board configuration.
More details on STiRoT for H7S, can be read from here: STiRoT for STM32H7S[3]
2. Isolation
To protect the RoT assets, the platform provides Temporal isolation mechanism to the boot levels.
2.1. Temporal isolation
The temporal isolation feature (HDP) has significantly evolved in STM32H7RS MCUs.
Its usability is now extended to 4 levels thanks to a monotonic counter, we are talking on HDPLx (HDPL0, 1, 2, 3).
The HDP is now linked to a monotonic counter allowing to manage Secure boot chain isolation of the different levels.
It is used to isolate boot assets during boot sequence. Hereafter is a typical association of HDPL with different boot levels.
The HDPL (Levels) are:
- Level 0 - Level reserved to system purpose.
- Level 1 - Level used to implement the immutable root of trust of the system (iROT) ==> STiRoT, OEMiROT .
- Level 2 - Level used by the later stages of the immutable root of trust. Typically what we call uRoT for updatable Root of Trust.
- Level 3 - Final level in which the product will end up once the Secure Boot phase is concluded.
Locking out the lower levels is under the control of the hardware (SBS), maintaining monotonic counter preventing lowering the level without proper reset. Option bytes help defining the start and the end of the HDP reserved areas, with sector granularity (on User Flash).
Accessible part of the system flash memory contains a callable function that facilitates the transition.
The system service to increase the level increases the monotonic level counter and jump to the desired address in the next Level area.
3. Cryptography
Means of performing cryptography depends on the STM32H7RS product line.
Typically, the STM32H7R line does not propose all the crypto hardware accelerators (only HASH and PKA Verification for ECDSA).
Software libraries are available to allow most of crypto operations.
Hardware cryptographic accelerators are available for both symmetric and asymmetric cryptography.
STM32Cube HAL can be used to work with the crypto IP.
3.1. ST crypto lib
ST crypto library v4 (x-cube-cryptolib)[4] is available for the STM32H7RS MCUs. ST crypto library is closed-source, but it can be added to the project easily, and it is downloadable together with many examples.
4. Silicon device life cycle
STM32H7RS MCUs have deeply changed the device life cycle management.
4.1. Product State
STM32H7RS lifecycle is implemented on product state similar to STM32H5 new families.
This lifecycle integrate the support of the Debug Authentication feature.
The basic progression now looks like this:
Product state | Description | Transitions possible |
---|---|---|
Open | State intended for unrestricted development. HUK is hidden, user is free to experiment, debugger is opened | Provisioning |
Provisioning | States intended to provision keys, secure firmware and set the Option Bytes | Closed, Locked, Regression |
Closed | Final product delivery state - allowing Debug Authentication (debug reopening or regression) | Regression |
Locked | Final product delivery state - No Debug authentication possible. | None |
Regression | Process of decommissioning to allow full debug | Open |
720px|thumb|center|Product state transitions - simplified
STMicroelectronics delivers the microcontroller in the Open state. It is possible to freely manipulate option bytes, including the debug to simplify development and testing, down to HDP level 1.
The provisioning is used to secure the product (debug only allowed for HDPL3) and manage control over the security. Among other settings, the debug authentication means are established in this step (or in Open for non-crypto parts).
Provisioning credentials will allow to:
- regress back to the Open state.
- temporarily allow debug at limited HDPL level (only with certificate method).
4.2. Debug authentication
STM32H7RS devices are delivered as Open with all security deactivated. Debug authentication[5] allows the developer to establish cryptographic means to control the product state. Without diving into the technical details, the paragraph below describes the possibilities of the Debug authentication mechanism.
Before locking the product, the developer chooses the maximum extent of future possible reopening and provisions the product with this information. Along with this setting, cryptographic authentication means are established. The developer can then perform either a product state regression, a temporary debug reopening of the product or launch the bootloader (useful when external memory corrupted), when authenticated successfully.
It is also possible to delegate the debug or regression rights using generated certificates. When generating the certificate, the delegated rights may be any subset of the original settings. For example, this way it is possible to create separate certificates for temporary debug access and for regression to Open (blank) state and provide them to different teams, according to their roles. If allowed, the teams may also delegate further, within their set limits.
In case of regression to Open state, the Debug authentication must be renewed on provisioning.
4.2.1. Debug reopening
Debug reopening is a temporary state in which the debug is permitted on a Closed state product, after successful debug authentication control. Debug reopening is possible for HDPL1, HDPL2, HDPL3 depending on platform configuration and certificate chain available.
4.2.2. Regression
Regression allows regressing the product, by changing the Product State to Open and as a consequence removing all contents (User Flash, OKBeys removed, EPOCH incremented, reset all AHK).
5. Secure manufacturing
Mass production of devices is often outsourced and sometimes the contractual manufacturer cannot be fully trusted with sensitive provisioning data or binaries. They may produce copies of the original product for alternative market, compromise the devices or simply not prevent the data from leaking outside. STMicroelectronics provides tools to prevent such situation and protect OEM IP.
5.1. SFI
Secure Firmware Install (SFI) uses the STM32 Trusted Package Creator tool and a HSM (hardware secure machine) to encrypt the install package, authenticate the genuine STM32 device for installation and limit the installation number to a planned number.
For further details, refer to UM2238[6] and AN5054[7].
Useful links:
5.2. SFIx
SFIx extension is not supported in STM32H7RS. The proposed way of working to provision product including external memories in non-trusted environment is to consider 2 steps: one step to provision the H7RS itself (User Flash + OBKeys + Option Bytes) and provision the external memories with pre-encrypted images for parts requiring this protection with global keys.
5.3. Provisioning
Provisioning is the process of installing the device, with its firmware, with corresponding configuration (keys, certificates,...) and settings to the product to a state to protect what has been provisioned. Firmware and configurations are written either to the user flash (code and data), or OTP (data) memory or to the OBK storage (data), if available. OBK storage provisioning can be done using the SFI or RSS_Lib->DataProvisioning() interface.
6. Secure storage
6.1. OBKeys
Secure storage is based on a sector of nonvolatile memory with special access rules:
- It is based on a flash area that can be used for keys and data storage.
- One part of it is reserved for system security management. One part is open to the user.
- Access to the secure storage is under the control of the Flash memory, based on the temporal isolation levels.
The dedicated flash area called OBKeys is available on both STM32H7R and STM32H7S lines.
It offers to user 2 areas related to HDPL1 and HDPL2. The goal is to use them to protect Root of Trust keys and data. Typically, this allows to have application being executed in HDPL3 not able to access HDPL1 and HDPL2 Root of Trust information.
Access to OBKeys is done through registers, Read registers + Write registers. There access are controlled using indexes (0 to 31), where indexes 0 to 7 are reserved for HW keys and indexes 8 to 31 for SW keys. - HW keys: can only be written. They can be directly injected to the SAES. This is used for our AHK implementation. - SW Keys: keys are used by the SW.
OBKeys can be provisioned thanks to RSSLib->DataProvisioning() API described in the reference manual.
6.2. Using SAES for secure storage
For crypto part version of the product (STM32H7S) the keys and data can be encrypted/decrypted using DHUK or AHK corresponding to selected HDPL.
This is particularly true considering the usage of:
- The SAES which is an hardware accelerated AES engine that prevents Side Channel leakages ensuring better security robustness.
- The DHUK or AHK corresponding to hardware unique keys for the targeted HDPL level.
- AHK must be used as soon as OBKeys are provisioned through the RSS_Lib->DataProvisioning() interface and for Debug Authentication configuration. AHK are random keys generated on first call to RSS_Lib->Data_Provisioning(). Thet are stored in HW Keys index of the OBKeys (index from 0 to 7).
- DHUK is for Derived Hardware Unique Key. It is derived from RHUK taking HDPL and EPOCH into account. EPOCH is a monotonic counter incremented on each regressions.
- AHK must be used as soon as OBKeys are provisioned through the RSS_Lib->DataProvisioning() interface and for Debug Authentication configuration. AHK are random keys generated on first call to RSS_Lib->Data_Provisioning(). Thet are stored in HW Keys index of the OBKeys (index from 0 to 7).
Combining both access control and encryption using SAES (with DHUK or AHK) brings a really high level of security that we call Secure Storage.
7. References