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:
- Introduction theoretical article: Secure Manager
- Specific STM32H5 Secure manager article: Secure Manager for STM32H5
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
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)
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.
The figure shows the example using IAR, but the three mentioned IDE are supported.
6. Firmware Update
7. Appendix
7.1. SMAK customization
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
7.2. 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.
7.3. 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. Architecture overview
The SM cannot be installed as standalone library, only as a part of the certified configuration consisting of ST-supplied secure boot chain. Secure boot principles are introduced in the following article: Secure Boot on STM32H5 introduction
8.1. Secure boot dependency
To install the SM, the STM32H573 must have the ST-iRoT (immutable root of trust fixed in system flash) activated as the stage 1 unique boot option. More information about he ST-iRoT is here: Introduction to ST-iROT for STM32H5
The secure boot chain must then continue with stage 2, the ST-uRoT (updatable root of trust, installed to the user flash). The final step in the secure boot process is the SM. For the sake of simplicity the ST-uRoT and the SM are installed in one step as the Secure Manager Package. While the ST-uRoT may be used without the SM, opposite is not possible.
8.2. Structure
The flash memory of the STM32H573 is partitioned to facilitate the resource isolation required by the security goals. The situation is illustrated by the following diagram (rectangles are not in scale to actual memory size).
Lowest part is the system flash where the ST-iRoT is active. The entire secure partition is taken by the Secure Manager Package contents plus optional Modules. Both RoT are only used in the boot phase and are not available when the application is running.
The application (or the OS, if present) will use the API to call the SM. The SM-Core will dispatch the request to one of the installed, mutually isolated, secure services. Basis for the API is the ARM PSA of the version supported in the present SM. Any API extensions present are documented in the SM user manual or in the Module documentation, if a Module is installed.
To read more about the Secure Manager architecture continue reading about the Secure Manager components.
9. 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.
10. SMAK and SMDK packages
The Secure Manages comes in 2 tiers, one publicly available, other more restrictive, but allowing deeper integration of user/OEM code. Additional details can be found at Secure Manager package ecosystem description.
10.1. SMAK
In it's base form, the Secure Manager Application Kit, is quite straightforward. All the security services are under control of the SM and the user application uses the certified functionality of the SM to get services in cryptography, secure storage, attestation an firmware upgrade. Since the whole secure part, which is the target of PSA evaluation, is fixed, the whole solution is PSA level 3 secure, regardless of what's the non-secure code executed on top of it.
It's always better if the application takes the advantage of secure services provided by the PSA API, because otherwise the whole exercise makes little sense, but it's not mandatory to do so. As long as the non-secure user code relies on the Secure Manager services with all the sensitive actions, the whole system is secure.
To learn more about the topic, read the dedicated SMAK article.
10.1.1. Availablility
The SMAK is distributed as an integral part of the STM32CubeH5 package.
Download at the STM32Cube MCU Package.
Inside the package, the path is
Projects\STM32H573I-DK\ROT_Provisioning\SMAK
The API is available under
Middlewares\ST\secure_manager_api
10.1.2. Configuration
The SM binary is fixed at certification, but the functionality is configurable, using configuration files in the package and the STM32 Trusted Package Creator.
SM integrator should customize:
- Keys for authentication and encryption
- Memory sizes
- Flash - modules and application size
- SRAM - areas reserved for modules and application
- DA configuration - normal provisioning
10.2. SMDK
The SMDK allows the developer to add secure code to the SM in form of Modules. The modules would have their own API and work side by side with the PSA API modules of the SM.
Such installable module is then used to provide additional secure services to the non-secure application. It may be adding new cryptographic services, serve as secure OS kernel or anything that is justified in being further isolated from normal operation.
The SMDK package is not available for mass market development. It requires a dedicated contract license, which shall be discussed with ST organization, and its attribution will be based on involved business.