Security features on STM32H7RS MCUs

This article contains an overview of the security features 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 allows 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)
- nonvolatile version is stored in external memory encrypted with a unique key per device only known by STiRoT itself.
- nonvolatile 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.
- can be the final application ==> in that case limited to SRAM available size.
- can 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 supposed to manage the Secure boot and secure firmware update for the application
The below diagram shows different possible boot path.

STM32H7RS boot path

1.2. Boot sequences

The below figure shows the expected execution sequence considering the 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

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

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:

1. Level 0 - Level reserved to system purpose.
2. Level 1 - Level used to implement the immutable root of trust of the system (iROT) ==> STiRoT, OEMiROT.
   
3. Level 2 - Level used by the later stages of the immutable root of trust. Typically what we call uRoT for updatable Root of Trust.
   
4. 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. To increase the level, the system service 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) 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 integrates 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 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 the external memory is 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 markets, 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 and AN5054.
Useful links:

• SFI
• SFI for STM32H7RS

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:

1. Provision the H7RS itself (User Flash + OBKeys + Option Bytes).
2. 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 and 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 the 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. Their access is 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 a 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(). They 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.
    

Combining both access control and encryption using SAES (with DHUK or AHK) brings a really high level of security that we call Secure Storage.