Secure Manager STM32H5 How to Intro

Revision as of 17:20, 16 August 2023 by Registered User

Target description

The purpose of this article is to provide the background needed to understand and execute the related How_to_start_with_Secure_Manager_on_STM32H573.
This article reviews some technical notions related to this topic, more detailed explanations are available in the two following articles:


1. Introduction

The Secure Manager (SM) has been developped to provide a security solution easy to use for every customer.
It provides a complete security frame work with ready to be used security services.
The getting started is showing through a practical example that the Secure Manager is simplifying and reducing the time for developments using security features.

For the getting started articles related to other STM32H5 security solution please refer to the Getting_started_with_STM32H5_security article.

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_on_STM32H573 article explains step by step how to use the SMAK 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 packages needs to be donwloaded from the ST.com STM32CubeH5

  • STM32Cube_FW_H5_V1.1.0
  • STM32Cube_FW_H5_V1.1.1 patch delivery to be copied into STM32Cube_FW_H5_V1.1.0
  • X-CUBE-SEC-M-H5_V1.0.0 (or later version) contains the Secure Manager binary example of ST available on STM32trustee-SM


Figure 1 Secure Manager binary file

More details about the STM32CubeFW are available in the How_to_start_with_Secure_Manager article.

Note:

  • In futur the STM32STM32Cube_FW_H5 will be provided with Secure Manager embedded.
  • 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 article.
The Secure Manager installation is done using one of the two provided script, as shown in the following figure.
The 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 : to use the default configuration
  • provisioning.bat : for a customized configuration (see related appendix chapter)


Figure 2 Secure Manager Installatation"

As shown in the figure above, the bootpath is configured to start from STiRoT.
For more explanations about bootpaths refer to Secure_Boot_for_STM32H5 and STiROT_for_STM32H5 articles.

Note: the scripts mentioned above are also installing a default Non-Secure Use Case code example.

5. Non-Secure application development

The development of a Non-Secure application is done as you normally proceed.
An example of Non-Secure application 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 3 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 4 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 is needed to transfer the new firmware image (encrypted and signed) into the download area.
    • As mentioned in the above figure, the Ymodem protocol is included in the SMAK_Appli example (see ymodem.c).

7. Regression

A regression is a reinitialisation (back to virgin state) of the device erasing the user flash and the Secure Storages (OBKeys, see article Secure Storage article).

  • The Secure Manger 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 5 Regression of the device

8. Appendix

8.1. SMAK customization

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

8.2. Secure Manager Features

Using the Secure Manager the customer gets a complete level 3 solution with no extra cost or effort.
The idea is simple:

  • All secure services are provided using the PSA API and certified, offering high level of confidence.
  • Application development proceeds on TZ-Closed product state.
  • The application relies on the secure API for authentication, confidentiality, firmware update, secure storage etc.
  • Product is then shipped in Closed state, applications are protected by the Secure Manager services.
  • Attestation services are included to provide report about the platform security state.
  • Regression is only possible in conditions set during the provisioning.
  • Certification is greatly simplified.


Other stand out advantages of the Secure Manger include:

  • LTS - long term support is the goal from the beginning
  • Full secure firmware update - using the ST-iRoT services the whole package can be updated without breaking the existing functionality
  • Multiple profiles - it's possible to maintain mutually isolated services in the application space.
  • Development advantages - not only porting another PSA-based application is easy, development with SM installed is too.
  • Connectivity - handles registration with clouds and servers using pre-provisioned keys and certificates.
  • IP protection - even multi-tenant IP protection using secure modules, including protected development flow.

To learn more about the Secure Manager functionality read the general Secure Manager functions article.

8.3. Note about certification

PSA is associated with an security certification scheme ( https://www.psacertified.org/ ), and it is not limited to ARM architecture, with open source implementation available. Using the open source implementation grants API compatibility with the standard, but no security certification. Anybody can use the source code to improve security of their IoT application, but only the certification can holds a proof to the outside world that the security is implemented correctly.
The certification is available in 3 tiers. There are many certified PSA implementations, but only few are certified to the highest mark - level 3. Level 3 PSA certification evaluates API conformance, resistance to software attacks and also complete hardware protection of the security functions. This is the Secure Manager running on the STM32H573 MCU.

8.4. Note about licensing

The SM is provided under the same SLA license as most parts of the STM32Cube software ecosystem. In case of the SM the source code is not published only the binary is available, the API is work of ARM and their rights must be respected. However the binary can be installed in any STM32H573 device with no additional fee, regardless of the devices final use.
The license is planned to be kept free for future upgrades of the SM, which will update the services for compliance with future versions of the TF-M (PSA) specification in a long term support plan. The update is of course going to be optional for SM users.