|
Coming soon |
Target description
The purpose of this article is to provide the background needed to understand and execute the related "how to start".
This introduction article reviews some technical notions related to this topic, more detailed explanations are available in the two following articles:
- Introduction theoretical article: TBD
- Specific STM32H5 Secure manager article: TBD
1. Introduction
In the world of microcontroller security necessitated by the requirements of an IoT application, the PSA (platform security architecture - https://arm-software.github.io/psa-api/ ) defined under leadership of ARM emerged. Secure Manager (SM) is a proprietary implementation of the PSA API. The goal was to pave customers the way to a dependable secure MCU solution with minimal learning efforts on the user side. It's a matter of installing, configuring and using services, without the necessity to understand how the PSA works internally.
1.1. 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 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.
1.2. Features
Using the SM 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.
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.
2. 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
2.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.
2.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.
3. 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.
4. 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.
4.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.
4.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
4.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
4.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.