Secure Manager STM32H5 How to Intro

1. Introduction

The purpose of this article is to provide the background needed to understand and execute the related:

• How to start with Secure Manager default configuration on STM32H5 series.
  
• How to start with Secure Manager customized configuration on STM32H5 series.
  

Before starting with this article, it is recommended to read the following articles:

• Secure Manager introduction
  
• Secure Manager for STM32H5

Secure Manager (SM) has been developped to provide an easy-to-use security solution for every customer.
It provides a complete security framework with ready-to-use security services.
The getting started article shows through a practical example that the Secure Manager simplifies and reduces the time for developments involving security features.

For the getting started articles related to other STM32H5 security solutions, refer to the article Getting started with STM32H5 security.

2. Secure Manager Access Kit (SMAK)

As reminder: the SMAK is the framework to develop non-secure application using the Secure Manager services.
The How to start with Secure Manager (customized configuration) on STM32H5 article explains step by step how to use the SMAK Ecosystem provided by ST.

Note: The secure module development is not covered in this getting started. (for explanations about SMDK refer to the links included at the beginning of this article).

3. SMAK delivery format

The following three packages need to be downloaded from the STM32H5 web page

• STM32Cube_FW_H5_V1.1.0
• STM32Cube_FW_H5_V1.1.1 patch delivery to be copied into STM32Cube_FW_H5_V1.1.0

Figure 1 STM32Cube_FW_H5

• X-CUBE-SEC-M-H5_V1.0.0 (or later version) contains the encrypted binary of the Secure Manager provided by ST and available on STM32trustee-SM

Figure 2 Secure Manager binary file

More details about the STM32CubeFW are available in the How to start with Secure Manager (customized configuration) on STM32H5 article.

Note:

• For futur STM32Cube_FW_H5 releases, it will not be necessary anymore to download two different STM32Cube_FW_H5_Vx.x.x (all will be combined in a single FW delivery)
• On the other hand the Secure Manager encrypted binary file will still be delivered in futur in a separate X-Cube.
• In the meantime, the following steps need to be done
  • Copy the STM32Cube_FW_H5_V1.1.1 into the STM32Cube_FW_H5_V1.1.0.
  • Copy the X-Cube-SEC-M_H5_v1.0.0 files into the STM32Cube_FW_H5_V1.1.0.
    

The Secure Manager Package binary and the version.bat are added in the directory \Projects\STM32H573I-DK\ROT_Provisioning\SM\Binary of the STM32Cube_FW_H5 (see figure above).

4. Secure Manager installation (provisioning)

This section explains the principle of the installation, the practical steps are shown in the How to start with Secure Manager (customized configuration) on STM32H5 article.
The Secure Manager installation is done using one of the two provided scripts, as shown in the following figure.
The encrypted binary copied from the X-CUBE-SEC-M-H5 will be used to install the Secure Manager into the device.
Two scripts are provided, user has to chose which one to execute:

• provisioning_auto.bat : default configuration (very easy way to install the secure manager when no personalization is needed)
• provisioning.bat : for a customized configuration (personalized memory configuration, keys, clock configuration etc ...)

Figure 3 Secure Manager Installatation"

5. Non-Secure application development

The development of a Non-Secure application is done as you normally proceed when developping an application without Secure Manager.
An example of Non-Secure application (SMAK_Appli) is provided in the STM32CubeFW_H5 for IAR, STM32CubeIDE and Keil IDEs.

As shown in the figure below, to use the provided example, simply open it with the IDE of your choice and launch the download and debug.

Figure 4 Non-Secure application development

The figure shows the example using IAR, but the three mentioned IDE are supported.

6. Firmware Update

A firmware update is done through the following steps:
( A practical example is shown in the How to start with Secure Manager article)

• The new firmware is developped using the IDE of you choice.
• The new firmware is compiled and through the postbuild command integrated in the IDE, the binary is encrypted and signed.
• The encrypted and signed file is transfered into the device in a download area of the user flash.
• At next reset it is automatically detected that a new firmware is available to be installed.
• This new firmware is decrypted and authenticated and installed.
• As shown in the figure below, the new firmware is swaped and become the new active one.

Figure 5 Firmware Update of User Application

Some additional informations:

• At compilation using your chosen IDE, two scripts are automatically called:
  • A prebuild script that updates the memory configuration according to the Secure Manager general configuration (see appendix, SM_Config_General.xml )
  • A postbuild script calls automatically STM32 Trusted Package Creator to encrypt and sign the new firmware image. The encryption and authentication keys can be regenerated, but default woking keys are provided in the STM32Cube_FW_H5 (see appendix, SM_Config_Keys.xml).
• A tool (Tera Term in ST Ecosystem) is needed to transfer the new firmware image (encrypted and signed) into the download area.

7. Regression

A regression is a reinitialization (back to virgin state) of the device erasing the user flash and the Secure Storage.

• The Secure Manager package and the Non-Secure application are removed.
  
• The product state is set back to Open.
  
• The Option Bytes are set back to their default value.
  

Figure 6 Regression of the device

Note:
What is not visible during the execution of the regression script, is how the rights are handle to allow to perform a regression.
At the very beginning when the provisioning script is executed to install the Secure Manager, there is a step called DA configuration. It is the Debug Authentication configuration, refer to article Debug Authentication for STM32H5 for more explanations.
When a device is set in a different state than OPEN, it is mandatory to have provisioned certificate and key to be able to reopen the debugger or to make a regression.

8. Appendix

8.1. Debug Authentication and permission mask

A default working setting is proposed in the STM32Cube_FW_H5.
Important to note: when installing the Secure Manager, debug in secure domain is not allowed and that it can't be changed by the user (see figure below and related explanations.

To protect a commercial product, obviously the default keys of the CubeFW must not be used. The key(s) must be regenerated using STM32TrustedPackageCreator.
It can be only the rootkey or the different keys for a certificate chain (for more details refer to Debug Authentication for STM32H5 ).
The maximum allowed permissions are configured through the SOC mask that is stored in the device during the provisioning.
The figure below shows the maximum possible permissions for a Secure Manager use case.

Figure 7 Permission Mask for Secure Manager

Only the three light blue bits can be changed by a user.
The other are reserved or made uneffective by the Secure Manager reducing the possible SOC mask configurations to:

• Regression
  • Possible to not allow any regression
  • Partial regression (removes the Non-Secure code and data)
  • Full regression (as shown in the regression section above)
• Intrusive Debug
  • NS-application executed in HDPL3 (open the debugger to access to the NS-application code)