1. Introduction
The Secure Manager Access Kit (SMAK) provides an environment where users can:
- Develop nonsecure applications that use the Secure Manager services.
- Prepare the final encrypted images used for OEM secure manufacturing.
The SMAK details are described in the next chapters.
2. Architecture
2.1. Ecosytem architecture
The SMAK ecosystem is composed of:
- The Secure Manager binary, available as an encrypted image from STM32TRUSTEE-SM[1].
- The image is delivered with the software license agreement SLA0048[2].
- It can be used for production purposes.
- The STM32Cube embedded firmware package available from STM32CubeH5 [3], containing:
- Scripts to configure and install Secure Manager, relying on STM32TrustedPackageCreator and STM32CubeProgrammer tools.
- Template and example projects (for STM32CubeIDE [4], KEIL[5] and IAR[6]) to develop nonsecure application using Secure Manager services. They contain pre-integrated prebuild and postbuild scripts relying on STM32TrustedPackageCreator to generate a signed and encrypted image, and download scripts relying on STM32CubeProgrammer to flash nonsecure application image.
- STM32TrustedPackageCreator and STM32CubeProgrammer[7], for above needs.
- STM32CubeMX[8], to generate nonsecure application projects for Secure Manager.
- IDEs (STM32CubeIDE[4], IAR[6] or KEIL[5])
The following diagram presents the SMAK ecosystem architecture.
2.2. Software architecture
Secure Manager is executed in a secure processing environment (SPE).
It is composed of STiRoT and STuRoT, in addition to the Secure Manager.
It is responsible for Secure Boot and Secure Firmware Update, and it provides secure services to nonsecure (NS) applications at runtime.
Secure Manager is composed of:
- A 2-level Root of Trust
- An immutable Root of Trust (STiRoT)
- An updatable Root of Trust (STuRoT)
- The Secure Manager Core
- Secure Services such as
- Cryptography
- Initial attestation
- Trusted storage
- Firmware update
Additionally, trusted applications, also called Secure Modules, can be added by the user, but are not part of the Secure Manager.
The following figure describes the Secure Manager software architecture.
For more information about the Secure Manager components (STuRoT, Secure Manager Core...), refer to Secure Manager components.
3. Security model
3.1. Stakeholders
The stakeholders involved in the security model are:
- STMicroelectronics, who owns the Secure Manager.
- The OEM who owns the nonsecure application and possibly Secure Modules, and is responsible for the system integration.
- Optionally, third-party Secure Module owners who own Secure Modules.
3.2. Asset confidentiality
The Secure Manager ensures stakeholders asset confidentiality by protecting:
- Secure Manager assets against the Secure Modules and nonsecure application.
- Secure Module assets against the nonsecure application and other Secure Modules.
- Nonsecure application assets against Secure Modules using the internal trusted storage (ITS) service.
3.3. Multi-tenant IP protection
The Secure Manager supports multi-tenant IP protection, meaning that each Secure Module (from the OEM or third-party) is isolated from the others by using sandboxes.
3.4. PSA level 3 isolation
The security model is based on PSA level 3 isolation, ensuring that the secure domain is isolated from nonsecure domain. This means that the Secure Manager and Secure Modules are protected from access by any nonsecure applications (hardware and software).
This isolation also ensures that privileged secure domain is separated from unprivileged secure domain, meaning that the Secure Manager Core is protected from access by secure services and Secure Modules.
Additionally, it ensures that the secure partitions are fully isolated. This means that each secure partition (secure services and Secure Modules) is sandboxed and can only access its own resources. This protects each secure partition from access by other secure partitions, and it provides protection for the Secure Manager Core.
3.5. Type of assets
The following table describes which types of assets are protected.
| Code asset | Volatile data asset | Nonvolatile data asset | ITS data | Peripherals | |
|---|---|---|---|---|---|
| Secure Manager | Yes | Yes | Yes | Yes | Yes |
| Secure Module | Yes | Yes | Yes | Yes | Yes |
| Nonsecure application | Yes | Yes | Yes | Yes | Partially (see note below) |
4. Feature overview and secure services
The Secure Manager is responsible for supplying secure services at boot-time and runtime.
The boot-time services are available after a power-on or system reset and are responsible of secure boot and secure firmware update.
The runtime secure services can be used by nonsecure applications running on nonsecure domain, as well as other secure modules running on secure domain. These services are defined by the PSA standard.
The following services are supported:
- PSA cryptography: supplies cryptographic services, such as authentication or encryption, based on hardware cryptographic acceleration with side-channel resistance.
- PSA internal trusted storage (ITS): supplies services for storing the most important assets (such as keys and data) in the internal flash memory, ensuring integrity, and confidentiality. Be aware that ITS file system is encrypted.
- PSA attestation: supplies services to authenticate a device. To do this, a unique signed token is generated for each device, which can be later authenticated by a server.
- PSA firmware update: supplies services to download new firmware images and perform image updates.
The Secure Manager also supports firmware installations and updates, based on direct image download in the download slot (this feature must be enabled using OEM Secure Manager configuration parameter) instead of PSA firmware update API. To have more information on the Secure Manager feature, please check the UM3234
5. Secure modules
The Secure Manager can execute secure modules (see Software architecture) in secure partitions sandboxed by the Secure Manager Core.
The OEM can develop their own secure functions in a Secure Module or can add third-party Secure Module.
To get information about secure module development, refer to SMDK for STM32H5.
The OEM must select a Secure Manager memory configuration compatible with the integrated module number and size.
Several types of secure module can be integrated in Secure Manager:
- Module developed by OEM (OEM module): encrypted and signed with OEM keys (see Secure Manager keys).
- Module developed by third-party (third-party module): encrypted and signed with third-party key. It requires a license for installation by OEM. Two types of licenses are supported:
- global license (without installation counting)
- chip specific license (with installation counting): STM32HSM-V2 is needed.
- Module developed by third-party and signed by OEM. Same as before, except that the module image is additionally signed with OEM keys
6. Secure Manager manufacturing
As we have seen in the introduction, SMAK is used in the manufacturing preparation phase to prepare the encrypted images for the OEM secure manufacturing (SFI).
Refer to SFI for STM32H5 to see how the output of the SMAK manufacturing preparation phase is used in the SFI procedure.
7. Debug
The STM32H5 device supports the PSA Authenticated Debug Access Control (ADAC) protocol.
After the Secure Manager installation, the STM32H5 device is set at least to the TZ-Closed product state, which means that the secure domain is not accessible via JTAG. Moreover, the OEM can decide to set the device to the Closed or Locked product state, which means the nonsecure application is no longer accessible via JTAG either.
In such states, it is no longer possible to debug the installed firmware (secure or nonsecure) via JTAG.
In the TZ-Closed product state, the OEM can use the ADAC protocol to:
- Perform a full regression (moving to an Open product state). This way, the OEM can reinstall the Secure Manager, Secure Modules, and a nonsecure application.
In the Closed product state, the OEM can use the ADAC protocol to:
- Reopen the nonsecure debug (moving to a TZ-Closed product state). This way, the OEM can debug their nonsecure application.
- Perform a partial regression of the nonsecure part (moving to a TZ-Closed product state). This way, the OEM can reinstall their nonsecure application.
- Perform a full regression (moving to an Open product state). This way, the OEM can reinstall the Secure Manager, Secure Modules, and a nonsecure application.
In the Locked product state, it is definitely not possible to reopen debugging or to perform regressions.
For more information on authenticated debug access protocol, refer to Debug Authentication for STM32H5.
8. Getting started
For the Secure Manager hardware and software environment setup, installation procedure, and step-by-step execution, refer to Secure Manager STM32H5 How to Intro.
9. Further information
For more details about Secure Manager environment setup, installation procedure and execution, refer to Secure Manager STM32H5 How to Intro.
For more details about Secure Manager manufacturing, refer to SFI for STM32H5.
10. Acronyms and definitions
See Security acronyms and definitions article.
11. References