STMicroelectronics STM32H573VI User Manual

UM3238
User manual
STM32H573xx STM32TRUSTEE-SM security guidance for SESIP 3 Certification
Introduction
This document describes how to prepare STM32H573xx microcontrollers to make a secure system solution compliant with
SESIP Profile for PSA Level 3 using the STM32Trust TEE Secure Manager (STM32TRUSTEE-SM) for STM32H573xx.
The STM32H573I-DK board integrating the STM32H573xx microcontroller is used as the hardware vehicle to implement and
test a nonsecure application using STM32TRUSTEE-SM (also named Secure Manager in this document), but it does not bring
any additional security mechanism.
The security guidance that is described in this document applies to any boards based on the devices listed in the table below,
for die revision X.
UM3238 - Rev 1 - February 2024
For further information contact your local STMicroelectronics sales office.
www.st.com
UM3238
General information
1
General information
The STM32TRUSTEE-SM application runs on STM32H573xx 32-bit microcontrollers based on the Arm®
Cortex®‑M33 processor that implements the armv8-M architecture.
Note:
Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.
Table 1. Specific acronyms
Acronym
UM3238 - Rev 1
Description
DA
Debug Authentification
FW
Firmware
HW
Hardware
IoT
Internet of Things
ITS
Internal trusted storage
MCU
Microcontroller
NSPE
Nonsecure processing environment
SM
Secure Manager
SPE
Secure processing environment
SW
Software
TOE
Target of evaluation
page 2/49
UM3238
Reference documents
2
Reference documents
Table 2. List of reference documents
Name
Title/Description
RM0481
Reference manual STM32H563/H573 and STM32H562 Arm®-based 32-bit MCUs (RM0481)
revision 1
[Security Target]TN1475
Technical note STM32H573xx Security Target for Secure Manager Package for PSA certified
Level 3 with SESIP Profile (TN1475) revision 1
UM3065
User manual Getting started with STM32CubeH5 for STM32H5 Series (UM3065) revision 1
UM2237
User manual STM32CubeProgrammer software description (UM2237) revision 22
[PSA_ST_API]
PSA Storage API-1.0.0
[PSA_CRYPTO_API]
PSA Cryptography API-1.0.0
[PSA_ATTESTATION_API] PSA Attestation API-1.0.0
UM3238 - Rev 1
[PSA_FW_UPDATE_API]
PSA Firmware Update API 0.7 Beta
[IEE1149]
EEE 1149.1–2013
[ADI5]
Arm® Debug Interface Architecture Specification ADIv5.0 to ADIv5.2
[UKDESCRIPTOR]
ukapp_config_descriptor.h
page 3/49
UM3238
TOE preparative procedures
3
TOE preparative procedures
This chapter describes the procedures to prepare the environment and the TOE before starting to use the device
hosting the TOE, or before testing the final product:
•
•
•
Secure acceptance: Procedures to verify the device to use in the tested product.
Secure preparation of the operational environment: Procedures to set up the environment in which the final
product is managed and tested.
Secure installation: Procedure to program and configure the product that includes the TOE.
The above preparative procedures are related to the complete TOE depicted by [SecurityTarget], with an overview
given in Figure 2. TOE scope.
3.1
Secure acceptance
Secure acceptance is the process in which the Integrator securely receives the TOE, verifying the integrity and
authenticity of all its components.
The TOE is distributed as an STM32 MCU device, with a software package that can be obtained from
www.st.com. Refer to the cover page for the applicable devices.
The TOE is distributed as an MCU with the STM32TRUSTEE-SM package (X-CUBE-SEC-M-H5). While the MCU
can be obtained through the standard ST support channels, ST also provides the related software package and
tool ecosystem that must be downloaded directly from the STMicroelectronics website. Those packages are:
•
•
STM32Cube_FW_H5 contains the installation environment and a non-secure application example using
the Secure Manager.
STM32CubeProgrammer is the STMicroelectronics programmer developer tool that securely programs
software part of the TOE on the MCU. This tool cannot be used by the Integrator for manufacturing
purposes. The Integrator must use its manufacturing tool instead with the SFI RSSe delivered in
STM32CubeProgrammer V2.14.0 (or upper version)..
It is the responsibility of the Integrator to use the correct version of the TOE as specified in the [Security Target]:
•
•
The STM32H573xx MCU device hardware.
The STM32TRUSTEE-SM package (X-CUBE-SEC-M-H5).
Regarding the X-CUBE-SEC-M-H5 Expansion Package, the Integrator must select the latest version compatible
with the STM32TRUSTEE SM package (X-CUBE-SEC-M-H5) as specified in the [Security Target].
This section recommends comparing a SHA256 value computed on the BinarySecureManagerPackage_PRO
D_v1.1.1.ssfi file extracted from the X-CUBE-SEC-M-H5 V1.1.1 software package. SHA256 values are
computed using the sha256sum.exe tool available on www.sha256.org.
UM3238 - Rev 1
page 4/49
UM3238
TOE preparative procedures
How to accept an STM32H573xx device
The STM32H5 microcontroller device can be verified by reading, with STM32CubeProgrammer (for more details,
refer to UM2237) all items described hereafter.
•
•
•
Device ID: 484, meaning STM32H573xx
–
Address: 0x4402 4000
–
Type: half‑word
–
Value: 0xX484
Revision: v1.3
–
Address: 0x4402 4002
–
Type: half‑word
–
Value: 0x1007
Product configuration:
–
Address 0x4002 2428
–
Type: half‑word
–
Value:
◦
Bit 5 (PKA available): 0b0
◦
Bit 4 (AES available): 0b0
◦
Bit 1 (SAES available): 0b0
The version of the immutable firmware stored in the STM32H573xx microcontroller device can be verified by
reading all items described hereafter.
•
–
–
–
STIROT version: v2.3.0
◦
Address: 0x0BF96084
◦
Type: word
◦
Value: 0x02030000
Debug Authentication version: v2.4.0
◦
Address: 0x0BF96060
◦
Type: word
◦
Value: 0x02040000
Security library version: v2.14.0
◦
Address: 0x0BF9603C
◦
Type: word
◦
Value: 0x02140000
How to select software packages?
As software packages are part of the TOE, the recommended procedure to download and accept them is
described here below.
•
•
•
UM3238 - Rev 1
STM32CubeH5 MCU Package must be downloaded with STM32CubeH5 V1.1.0 (or greater version), from
the www.st.com website. This package provides part of the host environment the Integrator uses to
configure the TOE.
STM32CubeH5 patch software package must be downloaded with STM32CubeH5 V1.1.1 (or greater
version compatible with the STM32CubeH5 version downloaded), from the www.st.com website. This
package provides part of the host environment the Integrator uses to configure the TOE.
The STM32CubeProgrammer tool must be downloaded from the www.st.com website as
STM32CubeProgrammer V2.14.0 (or upper version). This package provides part of the host environment
the Integrator uses to configure the TOE.
page 5/49
UM3238
TOE preparative procedures
•
How to accept X-CUBE-SEC-M-H5 V1.1.1 software package: By comparing the SHA256 value of the Proj
ects\STM32H573I-DK\ROT_Provisioning\SM\BinarySecureManagerPackage_PROD_v1.1.1.s
sfi file extracted from the en.x-cube-sec-m-h5-1.1.1.zip file (corresponding to the file you get
when downloading the X-CUBE-SEC-M-H5 V1.1.1 package from the www.st.com website) with the
following value:
–
9de51cb5e8516cdf49a712a4177c84e8034ad7cf92baa738a62ba5b50a9b0f56
X-CUBE-SEC-M-H5 V1.1.1 software package contains part of the TOE.
How to check the complete TOE?
Once both hardware and software installation procedures are finished, the complete TOE can be verified using
psa_fwu_query function from [PSA_FW_UPDATE_API]:
•
The application calls first the psa_fwu_query function specifying STuROT as image ID and must get as
output parameter the expected STuROT version mentioned by [Security Target] section 1.2.
–
psa_fwu_query call code sample:
{
/*User code section1*/
psa_image_info_t sturot_info = { 0 };
psa_status = psa_fwu_query(0x1f01, &sturot_info);
/*User code section2*/
}
–
On successful psa_fwu_query return (psa_status equal to 0), sturot_info must contain
version field values equal to the STuROT version mentioned by [Security Target] section 1.2:
◦
For example:
•
[Security Target] section 1.2 specifies STuROT version vA.B.C.
then
•
•
sturot_info.version.iv_major must be equal to A.
•
sturot_info.version.iv_minor must be equal to B.
•
sturot_info.version.iv_revision must be equal to C.
Then, the application calls the psa_fwu_query function specifying the Secure Manager as a component
and must get as an output parameter the expected Secure Manager version mentioned by [Security Target]
section 1.2
–
psa_fwu_query call code sample:
{
/*User code section1*/
psa_image_info_t sm_info = { 0 };
psa_status = psa_fwu_query(0x1, &sm_info);
/*User code section2*/
}
–
On successful psa_fwu_query return (psa_status equal to 0), sm_info must contain version
field values equal to the Secure Manager version mentioned by [Security Target] section 1.2:
◦
For example:
•
[Security Target] section 1.2 specifies Secure Manager version vA.B.C.
then
UM3238 - Rev 1
•
sm_info.version.iv_major must be equal to A.
•
sm_info.version.iv_minor must be equal to B.
•
sm_info.version.iv_revision must be equal to C.
page 6/49
UM3238
TOE preparative procedures
3.2
3.2.1
Secure installation and secure preparation of the operational environment
(AGD_PRE.1.2C)
Hardware setup
To set up the hardware environment of the TOE, an STM32H573I-DK board mounted with an STM32H573xx
microcontroller device must be connected to a personal computer via a USB cable. This connection with the PC
allows the Integrator to program the STM32TRUSTEE-SM package on the board.
The Integrator selects one of the following peripherals to enable communication between the host and the
STM32H573I-DK MB1677 and to load STM32TRUSTEE-SM through this peripheral:
Table 3. List of communication peripherals
Name
USART
I2C
I3C
SPI
USB
CAN FD
JTAG
SWD
This guidance uses USB as a connection example between the STM32H573I-DK board and the
STM32CubeProgrammer. However, other peripherals mentioned in Table 3 fall within the scope of this evaluation.
3.2.2
Host integrator setup
To configure and install the TOE, the Integrator must use STM32 Trusted Package Creator and
STM32CubeProgrammer. The Integrator uses STM32 Trusted Package Creator to configure STM32TRUSTEESM then the Integrator uses STM32CubeProgrammer to load and install the STM32TRUSTEE-SM within the
STM32H573xx microcontroller.
The following subsections list the host (PC) software that acts as the host environment used by the Integrator to
configure the STM32TRUSTEE-SM and install it within the STM32H573xx MCU. The complete setup description
is also fully described.
3.2.2.1
Installation of STM32CubeH5 MCU Package
•
•
Download and install the STM32CubeH5 V1.1.0 (or upper version) MCU Package available on the
STMicroelectronics website.
Download and install the STM32CubeH5 V1.1.1 (or upper version) patch package available on the
STMicroelectronics website.
Those packages provide configuration files used to configure STM32TRUSTEE-SM using
STM32CubeProgrammer.
3.2.2.2
Installation of X-CUBE-SEC-M-H5 Expansion Package
•
•
Download X-CUBE-SEC-M-H5 V1.1.1 Expansion Package on STMicroelectronics website.
Extract package directories and copy them within the installation directory of the STM32CubeH5 software
package.
This package contains STM32TRUSTEE-SM (Secure Manager).
UM3238 - Rev 1
page 7/49
UM3238
TOE preparative procedures
3.2.2.3
Installation of software tools for programming Secure Manager package
Download and install STM32CubeProgrammer V2.14.0 (or upper version) available on the STMicroelectronics
website. Note that the STM32TrustedPackageCreator, which comes as an option when installing
STM32CubeProgrammer must be installed.
Refer to [UM2237] to get the STM32CubeProgrammer overview and details.
STM32CubeProgrammer uses an encrypted and signed library named RSSe to program securely TOE within
STM32H573xx MCU.
Be aware that STM32CubeProgrammer is not qualified for manufacturing, then the Integrator must use its own
production environment with the RSSe provided within the STM32CubeProgrammer installation directory for its
device manufacturing.
The Integrator finds the RSSe in the STM32CubeProgrammer installation directory mentioned below:
C:\STM32CubeProgrammer_Installation_path\bin\RSSe\H5\enc_signed_RSSe_SFI_STM32H5_v2
.0.0.0.bin
For more details about the STM32CubeProg tool, refer to [UM2237].
3.2.3
Integrator environment setup
Once the steps described in Section 3.2.1 and Section 3.2.2 are completed, the Integrator must install all
necessary tools to configure and install STM32TRUSTEE-SM together with the nonsecure application on the
STM32H573xx microcontroller.
The actions that the Integrator must perform to set his host environment and configure the TOE are described
below.
Copy .xml files
Before configuring TOE, the Integrator must create the Integrator's working directory.
The Integrator creates a directory WorkDir within the STM32CubeProgrammer installation directory:
C:\STM32CubeProgrammer_Installation_path\bin\WorkDir
This document refers to the above directory as the Integrator working directory.
Note that the Integrator working directory name must contain no space characters and must fit 260 characters.
Within the Integrator working directory, the Integrator must copy the following files:
C:\STM32CubeFirmware_Installation_path\Firmware\Projects\STM32H573IDK\ROT_Provisioning\SM\Binary\SecureManagerPackage_PROD_v1.0.0.ssfi
C:\STM32CubeFirmware_Installation_path\Firmware\Projects\STM32H573IDK\ROT_Provisioning\SM\Config\SM_Config_General.xml
C:\STM32CubeFirmware_Installation_path\Firmware\Projects\STM32H573IDK\ROT_Provisioning\SM\Config\SM_Config_Other.xml
C:\STM32CubeFirmware_Installation_path\Firmware\Projects\STM32H573IDK\ROT_Provisioning\SM\Config\SM_Config_Keys.xml
C:\STM32CubeFirmware_Installation_path\Firmware\Projects\STM32H573IDK\ROT_Provisioning\SM\Config\Option_Bytes.csv
C:\STM32CubeFirmware_Installation_path\Firmware\Projects\STM32H573IDK\ROT_Provisioning\SM\ST\SM_ST_Settings_1.xml
C:\STM32CubeFirmware_Installation_path\Firmware\Projects\STM32H573IDK\ROT_Provisioning\SM\ST\SM_ST_Settings_2.xml
C:\STM32CubeFirmware_Installation_path\Firmware\Projects\STM32H573IDK\ROT_Provisioning\SM\Images\SM_Module_Image_template.xml
C:\STM32CubeFirmware_Installation_path\Firmware\Projects\STM32H573IDK\ROT_Provisioning\DA\Config\DA_Config.xml
UM3238 - Rev 1
page 8/49
UM3238
TOE preparative procedures
General .xml updates
After copying the listed files above, the Integrator must update the output section of all .xml copied files as below:
<Output>
<Name>Output File</Name>
<Value>./SM_Config_General.obk</Value>
<Default>../Binary/SM_Config_General.obk</Default>
<Tooltip>Output file configuration</Tooltip>
</Output>
Within the Output section above, the Integrator must set Value markup with the XML path set to the Integrator
working directory.
Specific .xml updates
C:\STM32CubeProgrammer_Installation_path\bin\WorkDir\SM_ST_Settings_1.xml
The Integrator must edit SM_ST_Settings_1.xml and find the following Data binary input file markup:
<Param>
<Name>Data binary input file</Name>
<Value>./WorkDir/intermediate1.bin</Value>
<Type>File</Type>
<Tooltip>Select the data binary file to be processed for the image generation</Tooltip>
<Default>../Binary/intermediate1.bin</Default>
</Param>
Within the Param section above, the Integrator must set Value markup with the XML path set to the Integrator
working directory.
C:\STM32CubeProgrammer_Installation_path\bin\WorkDir\SM_ST_Settings_2.xml
The Integrator must edit SM_ST_Settings_2.xml and find the following markup Image Data 3NS:
<File>
<Name>Image Data 3NS</Name>
<Value>./WorkDir/intermediate2.bin</Value>
<Align>1</Align>
<KeyType>ecdsa-p256</KeyType>
<Type></Type>
<Hidden>1</Hidden>
<Default>../Binary/intermediate2.bin</Default>
<Tooltip>Select the data img to be put in 3NS data</Tooltip>
</File>
Within the File section above, the Integrator must set Value markup with the XML path set to the Integrator
working directory.
UM3238 - Rev 1
page 9/49
UM3238
TOE preparative procedures
3.3
Secure installation
To install an application using the TOE, the Integrator must follow two steps:
1. Integrator application creation flow: The Integrator builds a complete encrypted image containing a
personalized version of the Secure Manager with the Integrator nonsecure application. This is the Integrator
full image (IFI).
2. Integrator installation flow: Secure installation of the Integrator's full image inside the STM32H573xx product.
Figure 1. Secure manager preparation and installation flow
3.3.1
Integrator application creation flow
The Integrator application creation flow consists of personalizing the STM32TRUSTEE-SM with product
configurations and Integrator secrets according to Integrator product specificities. This procedure is done in two
steps:
1. Preparation of Secure Manager configurations and secrets: A set of STM32TRUSTEE-SM configuration files
and a set of Integrator secrets.
2. Integrator full image (IFI) creation: Build a complete image containing the personalized version of the Secure
Manager, the Integrator nonsecure application, the modules, if any, and the Integrator secrets.
More details are found in the following subsections.
UM3238 - Rev 1
page 10/49
UM3238
TOE preparative procedures
3.3.1.1
Preparation of Secure Manager configurations and secrets
This step consists of configuring parameters, which are provisioned during the Integrator full image (IFI)
installation. The Integrator uses those parameters to personalize the STM32TRUSTEE-SM.
STM32TRUSTEE-SM configuration parameters are:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Product state: The product state of the product is to be set at the end of the Integrator full image
installation.
Option bytes: The hardware product configuration to be set at the end of the Integrator full image
installation.
System clock: The system clock configuration used by the TOE once installed
Module signature: The module installation model to use in case Integrator installs TOE with any modules
Flash layout: The selection of the STMicroelectronics predefined configuration to be used by the TOE once
installed
Local loader: The TOE Root of Trust failure management mode to be used by TOE once installed
Factory internal trusted storage (ITS): The initial ITS data to be securely initialized by TOE after the TOE
installation
SRAM secure/nonsecure buffer: The size of the SRAM buffer to be used by TOE as the interface with the
nonsecure application once TOE is installed
Secure SRAM layout: The size of the SRAM to be used or managed by TOE (considering secure module
needs) when TOE is installed.
Nonsecure application image keys: The Integrator keys to be used by TOE root of trust to manage a
nonsecure application image.
Nonsecure flash reserved area: The nonsecure flash area size to reserve to nonsecure application‑specific
purpose (meaning not under TOE control)
Debug authentication keys/certificates: The Integrator asymmetric public keys to be used by TOE once
installed to control the nonsecure domain.
Debug authentication permissions: The Integrator debug authentication permissions to be configured
during the TOE installation.
Module integration: The secure modules to be installed during the TOE installation.
For more details about TOE configurations, refer to Section 4.2: Operational guidance for the integrator role.
At the end of this phase, a set of TOE configuration files is generated in the Integrator working directory:
./WorkDir/SM_Config_Other.obk
./WorkDir/SM_Config_General.ok
./WorkDir/SM_Config_Keys.obk
./WorkDir/DA_Config.obk
./WorkDir/Option_Bytes.csv
3.3.1.2
Integrator's full image generation
Once STM32TRUSTEE-SM (Secure Manager) configuration files are generated, the Integrator must build a
complete encrypted image (encrypted with the Integrator image symmetric key) which contains all items related to
the Integrator application:
•
•
•
•
•
UM3238 - Rev 1
The STM32TRUSTEE-SM (Secure Manager)
The Secure Manager TOE configuration (refer to the TOE configuration files listed above) parameters and
secrets
The nonsecure application
The modules (if any)
The factory ITS (if any): The encrypted image containing data to be used to initialize the secure storage of
the Secure Manager secure storage during the first boot of the Secure Manager
page 11/49
UM3238
TOE preparative procedures
Table 4 depicts the composition of the Integrator’s full image.
Table 4. Full image breakout
Image item
Owner
Image
input
encrypted
License
STM32TRUSTEE-SM
ST
Yes
NA
Mandatory
TOE configuration
OEM
No
NA
Mandatory
Nonsecure application
OEM
No
SFI license
Modules
OEM or
third-party
OEM: No
third-party
OEM
No
Factory ITS
License with counting
enable: Chip‑specific
license.
License without
counting disable:
Global license.
NA
Comment
Mandatory. The Integrator must generate its SFI
license.
Optional, on Integrator’s choice.
The chip‑specific license comes with HSM
delivered by the third-party.
Global license: The third-party delivers the global
license as a binary file that comes with the
module delivery pack.
Optional, on Integrator’s choice.
Once Secure Manager configurations and secrets are prepared and the Integrator's full image is built, the
Integrator must:
•
•
•
Generate its SFI license (the license contains the encrypted Integrator’s key),
Integrate modules within the Integrator full image (IFI),
Generate the Integrator full image, encrypted with the Integrator’s key.
Refer to the following subsections for details.
SFI license generation
The Integrator must forge two binary items:
1. The Integrator key:
–
File name: ./WorkDir/SFI_Encryption_Key.bin
–
This is a 16‑byte file storing the secret key that TrustedPackageCreator uses to encrypt the Integrator
full image (IFI).
The Integrator must create ./WorkDir/SFI_Encryption_Key.bin with 16 random bytes.
–
2. The SFI encryption nonce:
–
File name: ./WorkDir/SFI_Encryption_Nonce.bin
–
This is a 12‑byte file storing the nonce that TrustedPackageCreator uses to encrypt the nonsecure
application.
The Integrator must create ./WorkDir/SFI_Encryption_Nonce.bin with 12 random bytes.
–
Then, the Integrator must run the following commands:
STM32TrustedPackageCreator_CLI.exe -GenLic -lictyp SFIG -pbk ./WorkDir/ -fwk
./WorkDir/SFI_Encryption_Key.bin -vlic 0 -n ./WorkDir/SFI_Encryption_Nonce.bin -output
./WorkDir/License_Integrator.bin
OEM nonsecure application and module integration
The integrator must include a nonsecure application and modules developed by the OEM. It needs to be added to
the Integrator's full image.
The integrator uses from the developer:
•
UM3238 - Rev 1
A binary for the nonsecure application, out of compilation without any postbuild.
page 12/49
UM3238
TOE preparative procedures
The integrator must edit:
C:\STM32CubeProgrammer_Installation_path\bin\WorkDir\SM_Code_Image.xml
•
NS appli image generation: Within this section, the Integrator specifies the keys related to the
nonsecure application
<GlobalParam>
<Command>sign</Command>
<Title>NS appli image generation</Title>
<LinkedXML>./SM_Config_Keys.xml</LinkedXML>
</GlobalParam>
•
Firmware area Size: Within this section, the Integrator specifies the size of the nonsecure application
<Param>
<Name>Firmware area Size</Name>
<Value>0x92000</Value>
<Type>Data</Type>
<Command>-S</Command>
<Hidden>1</Hidden>
<Default>0x72000</Default>
</Param>
For a configuration with 1 module (0x1), the Integrator must update it to 0x72000. No change is required
for a configuration without modules (0x0).
•
Rom fixed: Within this section, the Integrator specifies the flash memory address where the nonsecure
application is stored within the STM32TRUSTEE-SM.
<Param>
<Name>Rom fixed</Name>
<Value>0x806E000</Value>
<Type>Data</Type>
<Command>--rom-fixed</Command>
<Hidden>1</Hidden>
<Default>0x808C000</Default>
</Param>
For a configuration with 1 module (0x1), the Integrator must update the value to 0x808E000. No change is
required for a configuration without modules (0x0).
•
Binary input file: Within this section, the Integrator specifies the file that hosts the module firmware.
<Param>
<Name>Binary input file</Name>
<Value>./non-secure_application.bin</Value>
<Type>File</Type>
<Tooltip>Select the binary file to be processed for the image generation</Tooltip>
<Default>appli.bin</Default>
</Param>
•
Image output file: Within this section, the Integrator specifies the nonsecure application signed by the
Integrator (OEM).
<Output>
<Name>Image output file</Name>
<Value>./non-secure_application.hex</Value>
<Default>appli_enc_sign.bin</Default>
</Output>
Once the Integrator has updated C:\STM32CubeProgrammer_Installation_path\bin\WorkDir\SM
_Image.xml, then he generates the .hex:
STM32TrustedPackageCreator_CLI.exe -pb ./WorkDir/SM_Code_Image.xml
Module integration
The Integrator can include modules within the product. In this case, modules must be added to the Integrator's full
image (IFI).
UM3238 - Rev 1
page 13/49
UM3238
TOE preparative procedures
Table 5 describes the three possible module types:
Table 5. Module type description
Module type
OEM module
Third‑party module,
counting disabled,
OEM not signed
Third‑party module,
counting disabled,
OEM signed
Description
Comment
This module, owned by the OEM, is integrated
into the encrypted and signed full image.
The OEM module comes as a .bin file. The
Integrator copies the module within its working
directory and follows the process to encrypt and
sign with the OEMModule.hex name.
A third-party owns this module. This third-party
delivers the module license as a binary file that
comes within third‑party module delivery.
The Integrator does not sign this module type.
A third-party owns this module. This third-party
delivers the module license as a binary file that
comes within third‑party module delivery.
The Integrator signs this module type. Refer to
the Integrator’s choice and privilege in
Section 4.2.1.4: Module signature.
The Integrator copies the module license within
its working directory with the
3rdPartyGlobalLicense.bin name.
The module comes as a binary file. The
Integrator copies the module within its working
directory with the 3rdPartyModule.bin
name.
In case the module comes from the OEM, the Integrator must encrypt and sign the module before adding it within
the full image.
To do so, the Integrator must edit
C:\STM32CubeProgrammer_Installation_path\bin\WorkDir\SM_Module_Image_template.xml
and update the following markups:
•
Module image generation: Within this section, the Integrator specifies the keys related to the module
<GlobalParam>
<Command>sign</Command>
<Title>Module image generation</Title>
<LinkedXML>./SM_Config_Keys.xml</LinkedXML>
</GlobalParam>
•
Within the GlobalParam section above, the Integrator must set LinkedXML markup with XML path set to
the Integrator working directory.
Firmware area size: Within this section, the Integrator specifies the size of the module.
<Param>
<Name>Firmware area Size</Name>
<Value>0x20000</Value>
<Type>Data</Type>
<Command>-S</Command>
<Hidden>1</Hidden>
<Default>0x72000</Default>
</Param>
Within the Param section above, the Integrator must set Value markup with the module size. In case the
Integrator uses only one module, its size must be set to 0x20000 (128 Kbytes). If the Integrator uses more
than one module, he must set Value to the size of the different modules.
•
ROM fixed: Within this section, the Integrator specifies the flash memory address where the module is
stored within the STM32TRUSTEE-SM.
<Param>
<Name>Rom fixed</Name>
<Value>0x0C06E000</Value>
<Type>Data</Type>
<Command>--rom-fixed</Command>
<Hidden>1</Hidden>
<Default>0x808C000</Default>
</Param>
Within the Param section above, the Integrator must set Value markup with 0x0C06E000.
UM3238 - Rev 1
page 14/49
UM3238
TOE preparative procedures
•
Firmware download area offset
<Param>
<Name>Firmware download area offset</Name>
<Value>0x08172000</Value>
<Type>Data</Type>
<Command>-x</Command>
<Hidden>1</Hidden>
<Default></Default>
</Param>
•
Binary input file: Within this section, the Integrator specifies the file that hosts the module firmware.
<Param>
<Name>Binary input file</Name>
<Value>./OEMModule.bin</Value>
<Type>File</Type>
<Tooltip>Select the binary file to be processed for the image generation</Tooltip>
<Default>dummy.bin</Default>
</Param>
•
Within the Param section above, the Integrator must set Value markup with XML path set to the Integrator
working directory and OEM module file name.
Image output file: Within this section, the Integrator specifies the module file and the module
firmware signed by the Integrator (OEM).
<Output>
<Name>Image output file</Name>
<Value>./OEMModule.hex</Value>
<Default>Module_0.hex</Default>
</Output>
Within the Output section above, the Integrator must set Value markup with XML path set to the
Integrator working directory.
Once the Integrator updated
C:\STM32CubeProgrammer_Installation_path\bin\WorkDir\SM_Module_Image_template.xml,
then he generates the .hex: STM32TrustedPackageCreator_CLI.exe -pb ./WorkDir/
SM_Module_Image_template.xml
In case the module comes from a third‑party and the Integrator chooses to not sign modules, then the Integrator
can skip reading the next subsection dedicated to explaining how to sign the module using an XML file.
In case the module comes from a third‑party and the Integrator chooses to sign modules, then the Integrator must
sign the module before adding it to the full image.
To do so, the Integrator must edit C:\STM32CubeProgrammer_Installation_path\bin\WorkDir\S
M_Module_Image_with_License_template_oem_sign.xml and update the following markups:
•
Authentication key: Within this section, the Integrator specifies the keys related to the module.
<Param>
<Name>Authentication key</Name>
<Value>./SM_Authentication.pem</Value>
<Type>File</Type>
<Command>-k</Command>
<Hidden>1</Hidden>
<Default>SM_Authentication.pem</Default>
</Param>
Within the GlobalParam section above, the Integrator must set LinkedXML markup with XML path set to
the Integrator working directory.
UM3238 - Rev 1
page 15/49
UM3238
TOE preparative procedures
•
Firmware area Size: Within this section, the Integrator specifies the module size.
<Param>
<Name>Firmware area Size</Name>
<Value>0x20000</Value>
<Type>Data</Type>
<Command>-S</Command>
<Hidden>1</Hidden>
<Default>0x72000</Default>
</Param>
In the case the Integrator uses only one module, then its size must be set to 0x20000 (128 Kbytes), and
the Integrator set Value markup to 0x20000. If the Integrator uses more than one module, then he must
set Value to the size of the different modules.
•
Binary input file: Within this section, the Integrator specifies the file that hosts the module firmware.
<Param>
<Name>Binary input file</Name>
<Value>./3rdPartyModule.smu</Value>
<Type>File</Type>
<Toolkit>Select the binary file to be processed for the image generation</Toolkit>
<Default>dummy_with_license_not_oem_sign.smu</Default>
</Param>
•
Within the Param section above, the Integrator must set Value markup with XML path set to the Integrator
working directory and third‑party module file name.
Image output file: Within this section, the Integrator specifies the module firmware signed by the
Integrator (OEM).
<Param>
<Name>Image output file</Name>
<Value>./3rdPartyModuleOEMSigned.smu</Value>
<Default>dummy_with_license_oem_sign.smu</Default>
</Param>
Within the Output section above, the Integrator must set Value markup with XML path set to the
Integrator working directory.
Once the Integrator updated
C:\STM32CubeProgrammer_Installation_path\bin\WorkDir\SM_Module_Image_with_License_t
emplate_oem_sign.xml, he generates the .smu: STM32TrustedPackageCreator_CLI.exe -pb ./
WorkDir/SM_Module_Image_with_License_template_oem_sign.xml
Whether the Integrator chooses to sign or not the third‑party modules, he must create the .\WorkDir\3rdPart
yModule.mcsv.
The content of .\WorkDir\3rdPartyModule.mcsv, which the Integrator must fill, is described below:
•
Global license, module signed by OEM
./3rdPartyModuleOEMSigned.bin, ./GlobalLicenseModule.bin, 0x08172000
•
Global license, module not signed by OEM
./3rdPartyModule.bin, ./GlobalLicenseModule.bin, 0x08172000
•
The Integrator sets the ModuleFirmwareID (provided by the module Owner) as the second field in
the .mcsv file above.
Full image generation
In the previous subsections, the Integrator builds every piece of the full image. He must now concatenate all of
them with its nonsecure application to generate the Integrator's full image (IFI), with the following
recommendations:
•
•
UM3238 - Rev 1
The nonsecure application must be formatted in the intel HEX file format (.hex).
The Integrator must copy its nonsecure application within its working directory and rename it as non-secu
re_application.hex.
page 16/49
UM3238
TOE preparative procedures
To generate the full image (Integrator_Full_image.sfi), the Integrator must select the corresponding
commands defined here.
•
Nonsecure application without module.
set device=--deviceid 0x484
set non-secure_application=--firmware ".\non-secure_application.hex"
set key=--key ".\SFI_Encryption_Key.bin"
set nonce=--nonce ".\SFI_Encryption_Nonce.bin"
set ob=--obfile ".\Option_Bytes.csv"
set obk=--ob-keys ".\DA_Config.obk" ".\SM_Config_Keys.obk" ".\SM_Config_General.obk"
".\SM_Config_Other.obk"
set ssfi=--ssfi ".\SecureManagerPackage_PROD_v1.0.0.rc1.ssfi"
set ver=--ver 0
set ramsize=--ramsize 0x20800
set hash=--hash 1
set its_factory=--firmware ".\ITS_Factory.hex"
set out=--outfile ".\Integrator_Full_Image.sfi"
STM32TrustedPackageCreator_CLI.exe -sfi %device% %non-secure_application% %its_factory%
%key% %nonce% %ob% %obk% %ssfi% %ver% %ramsize% %hash% %out%
In the commands above, the Integrator can remove its_factory if he does not use factory ITS.
•
Non-secure application with OEM module
set device=--deviceid 0x484
set non-secure_application=--firmware ".\non-secure_application.hex"
set key=--key ".\SFI_Encryption_Key.bin"
set nonce=--nonce ".\SFI_Encryption_Nonce.bin"
set ob=--obfile ".\Option_Bytes.csv"
set obk=--ob-keys ".\DA_Config.obk" ".\SM_Config_Keys.obk" ".\SM_Config_General.obk"
".\SM_Config_Other.obk"
set ssfi=--ssfi ".\SecureManagerPackage_PROD_v1.0.0.rc1.ssfi"
set ver=--ver 0
set ramsize=--ramsize 0x20800
set hash=--hash 1
set modules=--firmware ".\OEMModule.hex”
set its_factory=--firmware ".\ITS_Factory.hex"
set out=--outfile ".\Integrator_Full_Image.sfi"
STM32TrustedPackageCreator_CLI.exe -sfi %device% %modules% %non-secure_application%
%its_factory% %key% %nonce% %ob% %obk% %ssfi% %ver% %ramsize% %hash% %out%
In the commands above, the Integrator can remove its_factory if he does not use factory ITS.
•
Nonsecure application with a third‑party module
set device=--deviceid 0x484
set non-secure_application=--firmware ".\non-secure_application.hex"
set key=--key ".\SFI_Encryption_Key.bin"
set nonce=--nonce ".\SFI_Encryption_Nonce.bin"
set ob=--obfile ".\Option_Bytes.csv"
set obk=--ob-keys ".\DA_Config.obk" “.\SM_Config_Keys.obk"
".\SM_Config_General.obk"
".\SM_Config_Other.obk"
set ssfi=--ssfi ".\SecureManagerPackage_PROD_v1.0.0.rc1.ssfi"
set ver=--ver 0
set ramsize=--ramsize 0x20800
set hash=--hash 1
set modules=-mcsv ".\3rdPartyModule.mcsv"
set its_factory=--firmware ".\ITS_Factory.hex"
set out=--outfile ".\Integrator_Full_Image.sfi"
STM32TrustedPackageCreator_CLI.exe -sfi %device% %modules% %non-secure_application%
%its_factory% %key% %nonce% %ob% %obk% %ssfi% %ver% %ramsize% %hash% %out%
In the commands above, the Integrator can remove its_factory if he does not use factory ITS.
UM3238 - Rev 1
page 17/49
UM3238
TOE preparative procedures
3.3.2
Integrator installation flow
Once the Integrator full image (IFI) is created, the Integrator must apply the commands described within the code
lines below to install securely it on the STM32H573xx MCU. Note that STM32CubeProgrammer is not qualified for
production, the Integrator must use its environment instead for its device manufacturing.
•
Nonsecure application without third‑party module.
set vb=1
set connect_ur=-c port=SWD ap=1 mode=UR -vb %vb%
set connect=-c port=SWD ap=1 mode=HotPlug -vb %vb%
set sfi_binary_path=".\Integrator_Full_Image.sfi"
set license_sfi=".\License_Integrator.bin"
set rsse_binary_path=".\..\RSSe\H5\enc_signed_RSSe_SFI_STM32H5_v2.0.0.0.bin”
STM32_Programmer_CLI.exe %connect_ur% -hardRst
STM32_Programmer_CLI.exe %connect% -sfi %sfi_binary_path% %license_sfi% -rsse
%rsse_binary_path%
•
Nonsecure application with a third‑party module
set vb=1
set connect_ur=-c port=SWD ap=1 mode=UR -vb %vb%
set connect=-c port=SWD ap=1 mode=HotPlug -vb %vb%
set sfi_binary_path=".\Integrator_Full_Image.sfi"
set license_sfi=".\License_Integrator.bin"
set rsse_binary_path= ".\..\RSSe\H5\enc_signed_RSSe_SFI_STM32H5_v2.0.0.0.bin”
set modules=-mcsv ".\3rdPartyModule.mcsv"
STM32_Programmer_CLI.exe %connect_ur% -hardRst
STM32_Programmer_CLI.exe %connect% -sfi %sfi_binary_path% %license_sfi% -rsse
%rsse_binary_path% %module%
UM3238 - Rev 1
page 18/49
UM3238
Operational user guidance
4
Operational user guidance
4.1
User roles
The user role integrator, also called original equipment manufacturer (OEM), is the most relevant for this TOE.
Indeed, the Integrator is the one who receives the TOE, performs the preparative procedures as described in
Section 3: TOE preparative procedures, and installs STM32TRUSTEE-SM into an STM32H573xx MCU.
The operational guidance for this user is described in Section 4.2: Operational guidance for the integrator role.
The Integrator user has full access to:
•
•
•
The STM32H573xx MCU,
The tools needed to configure the STM32TRUSTEE-SM,
And the tools to install the STM32TRUSTEE-SM together with Integrator’s nonsecure application and
modules within STM32H573xx MCU.
4.2
Operational guidance for the integrator role
4.2.1
User‑accessible functions and privileges (AGD_OPE.1.1C)
The main task of the integrator is to configure STM32TRUSTEE-SM and install it together with the Integrator’s
nonsecure application and modules within an STM32H573xx MCU.
As pictured in Figure 2. TOE scope, the evaluated TOE scope covers all parts located in the secure domain,
except the module firmware located in the secure unprivileged domain. It is isolated from the secure privileged
domain and also services located in the secure unprivileged domain.
Figure 2. TOE scope
STM32H573xx MCU and Secure Manager package
Nonsecure processing
environment (NSPE)
Secure Manager
Module
1
PSA API
Nonsecure application
Secure processing environment (SPE)
Module
N
Service
N
Service
1
Secure Manager package
SM-core
STuRoT
Debug
Authentication
RSS
STiRoT
Security
library
Security services
TOE1
Secure hardware
Nonsecure hardware
Legend
Crypto
Isolation
Security
life cycle
Inside evaluation scope
Outside evaluation scope
Tampers
TRNG
Isolation
Protected
flash
Hardware
DT59203V1
Nonsecure bootloader
TOE
The Integrator must follow the procedures described in Secure acceptance to check if he is using the TOE
mentioned within this document. This section describes the modifications that the Integrator can do and clarifies
what is covered in the scope of the certification.
The integrator must follow the guidelines described in this section, as a failure to do so means that the TOE is not
used in the certified configuration.
UM3238 - Rev 1
page 19/49
UM3238
Operational user guidance
4.2.1.1
Product state
The integrator must configure the product state applied by the Secure Installation process depicted in
Section 3.2.3: Integrator environment setup. This product state can be either:
•
CLOSED: The Integrator grants up one or several commands through the Debug Authentication service:
–
•
Debug: The STM32H573xx MCU grants debug connection to Integrator’s nonsecure application on
credential reception.
–
Regression: The STM32H573xx MCU fully erases user flash and falls back to the OPEN product
state on credential reception.
–
Partial regression: The STM32H573xx fully erases nonsecure user flash memory (keeps
STM32TRUSTEE-SM) and falls back to product state TZ-CLOSED on credential reception.
LOCKED: The Integrator forbids all Debug Authentication services listed above. In this product state, the
user cannot leverage Debug Authentication features such as Debug reopening and regressions.
The Debug Authentication service is part of the TOE1 (the base component) referred to by the [Security Target].
The Integrator has the privilege and the flexibility to configure the CLOSED or LOCKED product states. Both
configurations fall within the scope of this evaluation and remain the certified configuration.
To specify the product state, the Integrator must edit the ./WorkDir/SM_Config_Other.xml file and find the
Minimal Product state allowed markup:
<List>
<Name>Minimal Product state allowed</Name>
<Value>0x0000C600</Value>
<Width>4</Width>
<Default>0x0000C600</Default>
<Val>0x0000C600,TZ-Closed</Val>
<Val>0x00007200,Closed</Val>
<Val>0x00005C00,Locked</Val>
<Tooltip>The boot stage will execute the application only if the product state
programmed in the option byte is equal or greater than the "Product state minimal
allowed"</Tooltip>
</List>
Within the List section above, the Integrator must set a Value markup with a value related to the chosen
product state, meaning 0x00007200 for the CLOSED product state or 0x00005C00 for the LOCKED product
state.
Once the Integrator has updated SM_Config_Other.xml, he must run the command below to generate the ./W
orkDir/SM_Config_Other.obk file:
STM32TrustedPackageCreator_CLI.exe -obk ./WorkDir/SM_Config_Other.xml
This last action updates the SM_Config_Other.obk file that the secure installation process applies.
UM3238 - Rev 1
page 20/49
UM3238
Operational user guidance
4.2.1.2
Option bytes
The Integrator must configure STM32H573xx MCU option bytes to fit its device product requirements. The
Integrator can configure the option bytes listed in Table 6 below.
Table 6. Option byte list
Register
OPTSR_PRG
OPTSR2_PRG
Bit field
Description
IWDG_STDBY
Independent watchdog counteractive in Standby mode
IWDG_STOP
Independent watchdog counteractive in Stop mode
IO_VDDIO2_HSLV
Configuration of pads below 2.7 V for VDDIO2 power rail
IO_VDD_HSLV
Configuration of pads below 2.7 V for VDD power rail
PRODUCT_STATE
Product state (refer to Section 4.2.1.1: Product state)
NRST_STDBY
Reset when entering Standby mode
NRST_STOP
Reset when entering Stop mode
IWDG_SW
Independent watchdog of hardware or software control
BORH_EN
High BOR level
BOR_LEV
Supply level threshold that activates/releases the reset
SRAM3_ECC
SRAM3 error code correction
BKPRAM_ECC
BKPRAM error code correction
SRAM1_3_RST
SRAM1 and SRAM3 erase on reset
Note that the secure installation process applies to a maximum product state between the value configured in the
current section and the one configured in the section Section 4.2.1.1: Product state, with max (CLOSED,
LOCKED) = LOCKED.
The Integrator must refer to [RM0481] to get details regarding the option bytes mentioned in Table 6.
The Integrator uses STM32TrustedPackageCreator together with the Option_Bytes.csv file to configure the
expected option bytes that the secure installation process applies.
Figure 3. STM32TrustedPackageCreator menu
UM3238 - Rev 1
page 21/49
UM3238
Operational user guidance
After configuring the expected option bytes, the Integrator must click on the button Generate OB button. This
last action updates the Option_Bytes.csv file that the secure installation process applies.
The Integrator has the privilege and the flexibility to configure the option bytes. This flexibility falls within the scope
of this evaluation and remains the certified configuration.
4.2.1.3
System clock
By default, the system clock speed during TOE initialization is 250 MHz using PLL with HSI input, until the
nonsecure application is entered. The integrator can choose to change the system clock speed during TOE
initialization to 200 MHz (using PLL with HSI input) or 64 MHz (using HSI), depending on the voltage supply level
and the range of temperature supported. The flexibility for an integrator to change the system clock speed during
STM32TRUSTEE-SM configuration without compromising the TOE security falls within the scope of this
evaluation.
To specify the system clock, the Integrator must edit the ./WorkDir/SM_Config_Other.xml file and find the
Clock configuration markup:
<List>
<Name>Clock configuration</Name>
<Value>0x02</Value>
<Width>1</Width>
<Hidden>0</Hidden>
<Default>0x01</Default>
<Val>0x00,SM initialisation @ 64Mhz</Val>
<Val>0x01,SM initialisation @ 200Mhz</Val>
<Val>0x02,SM initialisation @ 250Mhz</Val>
<Tooltip>Configured the clock during SM initialization (including boot stages)
depending on the voltage supply level and the range of temperature supported</Tooltip>
</List>
Within the List section above, the Integrator must set a Value markup with value related to the chosen system
clock, meaning:
•
0x00 for 64 MHz
•
0x01 for 200 MHz
•
0x02 for 250 MHz
Once the Integrator has updated SM_Config_Other.xml, he must run the command below to generate the ./Wor
kDir/SM_Config_Other.obk file:
STM32TrustedPackageCreator_CLI.exe -obk ./WorkDir/SM_Config_Other.xml
This last action updates the SM_Config_Other.obk file that the secure installation process applies.
The Integrator has the privilege and the flexibility to configure the system clock. All the above‑listed system clock
values fall within the scope of this evaluation and remain the certified configuration.
UM3238 - Rev 1
page 22/49
UM3238
Operational user guidance
4.2.1.4
Module signature
STM32TRUSTEE-SM (Secure Manager) support module execution allows the Integrator to integrate securely the
modules embedded inside it. A module is a firmware library running in a sandbox environment. This means that a
module cannot access resources outside its execution environment. A module can only interact with
STM32TRUSTEE-SM and other modules through dedicated APIs.
As described in Section 3.3.1.2, the STM32TRUSTEE-SM supports three module installation models. The
Integrator needs to choose one of those three models for each module in its full image.
1. The Integrator (OEM) is the module owner: The Integrator signs its module.
2. The third-party is the module owner: The Integrator signs the module.
3. The third-party is the module owner: The third-party only signs the module and not the Integrator.
All modules are delivered as encrypted and signed firmware libraries by the module owner (third-party or OEM).
To configure the module installation model, the Integrator must edit the ./WorkDir/SM_Config_General.xml
file and find the Authentication of modules with license markup:
<List>
<Name>Authentication of Modules with license</Name>
<Value>0xce</Value>
<Width>1</Width>
<Hidden>0</Hidden>
<Default>0xce</Default>
<Val>0xbd, Modules with license shall not be signed by OEM</Val>
<Val>0xce, Modules with license shall be signed by OEM</Val>
<Tooltip>Type of authentication for module with license only. Other modules are not
concerned by this setting.</Tooltip>
</List>
Within the List section above, the Integrator must set the Value markup with the value related to the chosen
module installation model, meaning:
•
0xce for module installation Model#3
•
0xbd for module installation Model#1 and Model#2
Once the Integrator has updated the SM_Config_General.xml file, he must run the command below to
generate the ./WorkDir/SM_Config_General.obk file:
STM32TrustedPackageCreator_CLI.exe -obk ./WorkDir/SM_Config_General.xml
This last action updates the SM_Config_General.obk file that the secure installation process applies.
The Integrator has the privilege and the flexibility to configure the module installation Model. All the above‑listed
module installation Model values fall within the scope of this evaluation and remain the certified configuration.
UM3238 - Rev 1
page 23/49
UM3238
Operational user guidance
4.2.1.5
Flash layout configuration
The Integrator must configure the TOE user flash layout to configuration 0 (SMAK_0), configuration 1 (SMAK_1)
… or configuration N (SMAK_N), as described below.
•
•
•
•
In flash configuration 0 (SMAK_0), the Integrator does not integrate modules.
In flash configuration 1 (SMAK_1), the Integrator does not integrate a module.
…
In flash configuration N (SMAK_N).
Figure 4 depicts flash configuration mappings for both 0 and 1 flash configurations.
Figure 4. Predefined memory mapping configurations
The selected flash layout configuration impacts nonsecure application mapping. The Integrator is responsible to
verifying that the nonsecure application is implemented according to the selected flash layout configuration.
To configure flash layout configuration, the Integrator must edit the ./WorkDir/SM_Config_General.xml file
and find Flash Layout configuration index markup:
<List>
<Name>Flash Layout configuration index</Name>
<Value>0x0</Value>
<Width>1</Width>
<Default>0x0</Default>
<Val>0x0, 0 Mod NS(584KB)</Val>
<Val>0x1, 1 Mod(128KB) NS(456KB)</Val>
…
…
<Val>0xXY, XY Mod(XKB) NS(XKB)</Val>
<Tooltip>Predefined flash layout configuration.</Tooltip>
</List>
UM3238 - Rev 1
page 24/49
UM3238
Operational user guidance
Within the List section above, the Integrator must set a Value markup with value related to the flash layout
configuration:
•
0x0 for flash layout configuration without modules
•
0x1 for flash layout configuration with one module
•
•
…
0xXY for flash layout configuration with n modules
Once the Integrator updates SM_Config_General.xml, he must run the command below to generate the ./WorkD
ir/SM_Config_General.obk file:
STM32TrustedPackageCreator_CLI.exe -obk ./WorkDir/SM_Config_General.xml
This last action updates the SM_Config_General.obk file that the secure installation process applies.
The Integrator has the privilege and the flexibility to configure the flash layout configuration with any configuration
ID listed with Val markup within the SM_Config_General.xml file. All the above‑listed flash layout
configuration values fall within the scope of this evaluation and remain the certified configuration.
4.2.1.6
Local loader
When TOE finds an invalid image right after TOE reset, it can either reset or jump to the standard bootloader
acting as a local loader. Jumping to the standard bootloader enables downloading a new valid image using the
standard bootloader with a host (PC) physically connected to the STM32H573xx. Invalid images can be either
STM32TRUSTEE-SM, nonsecure application, or module image.
The Integrator must configure TOE to select reset or standard bootloader as a response to invalid image
detection. The Integrator must configure the standard bootloader as a local loader in two cases:
•
•
STiROT (TOE1)
STuROT (item of the STM32TRUSTEE-SM)
To configure STiROT using the standard bootloader as a local loader, the Integrator must edit the ./WorkDir/SM
_Config_Other.xml file and find Jump into ST bootloader when no valid STuROT markup:
<Bool>
<Name>Jump into ST bootloader when no valid STuROT</Name>
<Value>0x01</Value>
<Width>1</Width>
<Hidden>0</Hidden>
<Default>0x01</Default>
<True>0x01</True>
<False>0x00</False>
<Tooltip>Tick the box if STiROT is allowed to jump into ST bootloader when the
authenticity and the integrity of STuROT image is not verified</Tooltip>
</Bool>
Within the Bool section above, the Integrator must set a Value markup with value related to the local loader
selection, meaning:
UM3238 - Rev 1
•
0x01: STiROT uses the standard bootloader as a local loader.
•
0x00: STiROT does not use the standard bootloader as a local loader and resets on an invalid image
identification.
page 25/49
UM3238
Operational user guidance
To configure STuROT using the standard bootloader as a local loader, the Integrator must edit the SM_Config_G
eneral.xml file and find Jump into ST bootloader when no valid SecureManager / Module /
NS application markup:
<Bool>
<Name>Jump into ST bootloader when no valid SecureManager / Module / NS application</Name
>
<Value>0x01</Value>
<Width>1</Width>
<Hidden>0</Hidden>
<Default>0x01</Default>
<True>0x01</True>
<False>0x00</False>
<Tooltip>Tick the box if STuROT is allowed to jump into ST bootloader when the
authenticity and the integrity of at least 1 image is not verified</Tooltip>
</Bool>
Within the Bool section above, the Integrator must set a Value markup with value related to the local loader
selection, meaning:
•
0x01: STuROT uses the standard bootloader as a local loader.
•
0x00: STuROT does not use the standard bootloader as a local loader and resets on an invalid image
identification.
The flexibility for an integrator to select or not the standard bootloader as a local loader falls within the scope of
this evaluation.
Once the Integrator has updated the SM_Config_General.xml and SM_Config_Other.xml files, he must
run the command below to generate the ./WorkDir/SM_Config_General.obk and ./WorkDir/SM_Confi
g_Other.obk files:
STM32TrustedPackageCreator_CLI.exe -obk ./WorkDir/SM_Config_General.xml
STM32TrustedPackageCreator_CLI.exe -obk ./WorkDir/SM_Config_General.xml
The Integrator has the privilege and the flexibility to select or not the standard bootloader as a local loader. All the
above‑listed local loader configuration values fall within the scope of this evaluation and remain the certified
configuration.
4.2.1.7
Factory internal trusted storage (ITS)
The factory ITS blob is securely provisioned in the STM32TRUSTEE-SM ITS section during the TOE secure
installation process. At runtime, STM32TRUSTEE-SM can use data and keys stored within ITS through TOE
secure ITS service via the PSA API interface.
The Integrator has the flexibility to use or not factory ITS blob.
To add its keys and data within the factory ITS blob, the Integrator must use the ITSbuilder PC application located
at:
C:\STM32CubeProgrammer_Installation_path\Utilities\PC_Software\ITSbuilder\dist\ITSb
uilder\ITSbuilder.exe
The
C:\STM32CubeProgrammer_Installation_path\Utilities\PC_Software\ITSbuilder\README.md
file depicts how to use ITSbuilder.exe.
The integrator can find an example usage of ITSbuilder.exe within the
C:\STM32CubeFirmware_Installation_path\Firmware\Projects\STM32H573IDK\ROT_Provisioning\SM\its_blob.bat file.
When the Integrator chooses to install a factory ITS blob during the TOE secure installation process, he must
store this one within its working directory C:\STM32CubeProgrammer_Installation_path\bin\WorkDir.
The Integrator has the privilege and the flexibility to use or not the factory ITS blob.
When using a factory ITS blob, the Integrator has the privilege and the flexibility to configure it. Whatever the
Integrator’s configuration, this falls within the scope of this evaluation and remains the certified configuration.
UM3238 - Rev 1
page 26/49
UM3238
Operational user guidance
4.2.1.8
SRAM secure/nonsecure interface
Nonsecure application and STM32TRUSTEE-SM use a buffer located at the end of SRAM1 to share data. This
buffer is also named NS/S shared buffer.
The minimum size for the NS/S shared buffer is 4 Kbytes with a maximum of 248 Kbytes. The size granularity is
1 Kbyte.
The Integrator must configure the size of the NS/S shared buffer. The Integrator tailors secure/nonsecure
interface size according to the input/output parameters size of secure services used by its application.
Figure 5 depicts the SRAM mapping including the NS/S shared buffer.
Figure 5. SRAM memory mapping
UM3238 - Rev 1
page 27/49
UM3238
Operational user guidance
To configure shared SRAM1 buffer size, the Integrator must edit the ./WorkDir/SM_Config_General.xml file
and find the SRAM Secure/NonSecure interface area size markup:
<Data>
<Name>SRAM Secure/NonSecure interface area size</Name>
<Value>0x10</Value>
<Width>1</Width>
<Hidden>0</Hidden>
<Default>0x10</Default>
<Tooltip>Size of Shared SRAM area between Secure and NonSecure at end of SRAM1.
The unit is 1 Kbyte. The minimum is 4 Kbytes. The maximum is 248 Kbytes.</Tooltip>
</Data>
Within the Data section above, the Integrator must set a Value markup with a value related to the shared
SRAM1 buffer size, meaning:
•
0x04 for 4 Kbytes
•
•
…
0x10 for 16 Kbytes
•
•
…
0xF8 for 248 Kbytes
Once the Integrator has updated SM_Config_General.xml, he must run the command below to generate the S
M_Config_General.obk file:
STM32TrustedPackageCreator_CLI.exe -obk ./WorkDir/SM_Config_General.xml
The Integrator has the privilege and the flexibility to change the size of the shared SRAM1 buffer reserved for
secure and nonsecure interfaces. Whatever his choice within the listed values above, this falls within the scope of
this evaluation and remains the certified configuration.
UM3238 - Rev 1
page 28/49
UM3238
Operational user guidance
4.2.1.9
Secure SRAM layout
The Integrator must configure the SRAM allocated to SPE (secure SRAM), considering that STM32TRUSTEE-SM
and modules run within SPE.
STM32TRUSTEE-SM uses 140 Kbytes of SRAM. This SRAM allocated to STM32TRUSTEE-SM starts at the
beginning of SRAM2 (0x3004 0000) and finishes at 0x3006 2FFF address.
The integrator extends the size of the secure SRAM by increasing the secure SRAM end address with a
granularity of 4 Kbytes.
When the Integrator chooses flash layout configuration 0 (without modules), he must configure the SRAM end
address to 0x3006 2FFF.
When the Integrator chooses flash layout configuration 1 (with one module), he must configure the SRAM end
address to a value that fits the needs of the module. The module provider must give this value to the Integrator.
Figure 6 depicts the SRAM mapping including the secure SRAM section.
Figure 6. SRAM memory mapping
UM3238 - Rev 1
page 29/49
UM3238
Operational user guidance
To configure the secure SRAM end address, the Integrator must edit the ./WorkDir/SM_Config_General.xm
l file and find Secure SRAM End address markup:
<List>
<Name>Secure SRAM End address</Name>
<Value>0x30068fff</Value>
<Width>4</Width>
<Hidden>0</Hidden>
<Default>0x3006afff</Default>
<Val>0x30062fff</Val>
<Val>0x30063fff</Val>
<Val>0x30064fff</Val>
<Val>0x30065fff</Val>
<Val>0x30066fff</Val>
<Val>0x30067fff</Val>
<Val>0x30068fff</Val>
<Val>0x30069fff</Val>
<Val>0x3006afff</Val>
<Val>0x3006bfff</Val>
<Val>0x3006cfff</Val>
<Val>0x3006dfff</Val>
<Val>0x3006efff</Val>
…
…
<Val>0x3009ffff</Val>
<Tooltip>End address of SRAM allocated to Secure (Secure Manager and modules).
Secure Manager only from 0x30040000 to 0x30062fff. Secure modules from 0x30063000
to this address. Remaining area for the non-secure.</Tooltip>
</List>
Within the List section above, the Integrator must set a Value markup with value related to secure SRAM end
address, meaning:
•
0x30062fff for secure SRAM end address 0x3006 2FFF.
•
•
…
0x3009ffff for secure SRAM end address 0x3009 FFFF.
Once the Integrator has updated SM_Config_General.xml, he must run the command below to generate the S
M_Config_General.obk file:
STM32TrustedPackageCreator_CLI.exe -obk ./WorkDir/SM_Config_General.xml
The Integrator has the privilege and the flexibility to extend the size of the SRAM area reserved for SPE without
compromising the TOE security. Whatever his choice within the values listed above, this falls within the scope of
this evaluation and remains the certified configuration.
UM3238 - Rev 1
page 30/49
UM3238
Operational user guidance
4.2.1.10
Secure Manager keys
The Integrator must configure the keys that STM32TRUSTEE-SM uses for authentication and encryption of the
nonsecure application and modules. More specifically:
•
•
The SM encryption key is an asymmetric ECC secp256r1 private key.
The SM authentication key is an asymmetric ECDSA secp256r1 public key.
The integrator must update the default STM32TRUSTEE-SM keys with its keys.
The SM encryption key is used in two different contexts:
•
•
STM32TRUSTEE-SM uses this key to get the nonsecure application symmetric encryption key (the
Integrator image symmetric key).
The Integrator uses this key to sign the nonsecure application. The Integrator uses this key when signing a
module that belongs to him or when he chooses to sign a third‑party module.
The Integrator uses the same SM authentication key to sign modules and the nonsecure application when
building the Integrator full image (IFI).
To configure STM32TRUSTEE-SM keys, the Integrator must edit the ./WorkDir/SM_Config_Keys.xml file
and find the following markups:
•
Encryption key markup:
<File>
<Name>Encryption key</Name>
<Value>../Keys/SM_Encryption.pem</Value>
<Align>1</Align>
<KeyType>ecdsa-p256</KeyType>
<Type>Private_Raw</Type>
<Default>../Keys/SM_Encryption.pem</Default>
<Tooltip>Select the key used to encrypt OEM images.</Tooltip>
</File>
Within the File section above, the Integrator must set a Value markup with a value related to the SM
encryption key:
–
•
Relative_path/filename.pem: Relative path and file name to the .pem file that contains the SM
encryption key.
Authentication key markup:
<File>
<Name>Authentication key</Name>
<Value>../Keys/SM_Authentication.pem</Value>
<Align>1</Align>
<KeyType>ecdsa-p256</KeyType>
<Hash></Hash>
<Type>Public</Type>
<Default>../Keys/SM_Authentication.pem</Default>
<Tooltip>Select the key used to authenticate OEM images.</Tooltip>
</File>
Within the File section above, the Integrator must set a Value markup with a value related to the SM
authentication key:
–
Relative_path/filename.pem: relative path and file name to the .pem file that contains the SM
authentication key.
Once the Integrator has updated SM_Config_Keys.xml, he must run the commands below to generate the SM_
Config_Keys.obk file:
STM32TrustedPackageCreator_CLI.exe -obk SM_ST_Config_Keys.xml
STM32TrustedPackageCreator_CLI.exe -pb SM_ST_Settings_1.xml
STM32TrustedPackageCreator_CLI.exe -obk SM_ST_Settings_2.xml
The Integrator has the privilege to configure STM32TRUSTEE-SM keys without compromising the TOE security.
This privilege falls within the scope of this evaluation and remains the certified configuration.
4.2.1.11
UM3238 - Rev 1
Nonsecure flash reserved area
The integrator might choose to configure the size of a flash‑reserved area for data dedicated to the nonsecure
application. This area has a granularity of 16 Kbytes. For example, a nonsecure application can use this area to
host a file system.
page 31/49
UM3238
Operational user guidance
This configuration impacts the size of the nonsecure application image.
To configure the reserved nonsecure flash area size, the Integrator must edit the ./WorkDir/SM_Config_Gen
eral.xml file and find NS reserved area size markup:
<List>
<Name>NS reserved area size</Name>
<Value>0x00</Value>
<Width>1</Width>
<Default>0x00</Default>
<Val>0x00,0 KB</Val>
<Val>0x02,16 KB</Val>
…
…
<Val>0x40,512 KB</Val>
<Tooltip>NonSecure reserved area size (available for NS Data, NS FileSystem,
and others). Unit is 8KB flash sectors. Reduces the nonSecure application area size by
half of the value.</Tooltip>
</List>
Within the List section above, the Integrator must set a Value markup with value related to reserved nonsecure
flash area size, as defined below:
•
0x00: The Integrator does not reserve an area for nonsecure application data.
•
0x02: The Integrator reserves an area of 16 Kbytes for nonsecure application data.
•
0x04: The Integrator reserves an area of 32 Kbytes for nonsecure application data.
•
...
•
0x40: The Integrator reserves an area of 512 Kbytes for nonsecure application data.
Once the Integrator has updated SM_Config_General.xml, he must run the command below to generate the S
M_Config_General.obk file:
STM32TrustedPackageCreator_CLI.exe -obk ./WorkDir/SM_Config_General.xml
The Integrator has the privilege and the flexibility to configure the size of the reserved nonsecure flash area, as
defined in this guidance. This choice falls within the scope of this evaluation and remains the certified
configuration.
4.2.1.12
Debug Authentication keys/certificates
The TOE uses an asymmetric public key to authenticate a genuine user with its credential (a certificate) when
reopening debug in the nonsecure domain or performing regression. The service, within TOE that deals with such
features is called Debug Authentication (DA).
Note that when the Integrator configures STM32TRUSTEE-SM with the LOCKED product state (refer to
Section 4.2.1.1: Product state), then STM32TRUSTEE-SM disables the Debug Authentication service: The
Integrator does not need to configure the Debug Authentication key and he can skip reading further this section.
When the Integrator configures STM32TRUSTEE-SM with the CLOSED product state, then STM32TRUSTEESM enables the Debug Authentication service, and the Integrator must configure the Debug Authentication keys
from its Debug Authentication certificate.
Refer to [UM2237] to get detailed information regarding DA certificate generation.
To configure the reserved DA asymmetric public key, the Integrator must edit the ./WorkDir/DA_Config_Gene
ral.xml file and find Debug Authentication root key markup:
<File>
<Name>Debug Authentication root key</Name>
<Value>../Keys/key_1_root.pem</Value>
<Align>4</Align>
<KeyType>ecdsa-p256</KeyType>
<Type>Public</Type>
<Default>../Keys/key_1_root.pem</Default>
<Tooltip>Select the key used as the root for the authentication debug
certificate chain. When this key is regenerated, all certificates must be
regenerated as well</Tooltip>
</File>
UM3238 - Rev 1
page 32/49
UM3238
Operational user guidance
Within the File section above, the Integrator must set Value markup with the path and filename that stores the
DA asymmetric public key:
•
Relative_path/filename.pem: relative path and file name to the .pem file that stores the DA
asymmetric key.
Once the Integrator has updated DA_Config_General.xml, he must run the command below to generate the D
A_Config_General.obk file:
STM32TrustedPackageCreator_CLI.exe -obk ./WorkDir/DA_Config.xml
The Integrator has the privilege and the flexibility to change the DA asymmetric public key. This privilege and
flexibility fall within the scope of this evaluation and remain the certified configuration.
4.2.1.13
Debug Authentication permissions
The TOE installation procedure restricts the Debug Authentication permission lists.
Note that when the Integrator configures STM32TRUSTEE-SM with the LOCKED product state (refer to
Section 4.2.1.1: Product state), then STM32TRUSTEE-SM disables the Debug Authentication service: The
Integrator does not need to configure the Debug Authentication permissions and he can skip reading further this
section.
The integrator might configure the permissions among:
•
•
•
Full regression
Partial regression
Nonsecure HDP Level 3 debug reopening.
To configure the reserved DA permissions, the Integrator must edit the ./WorkDir/DA_Config_General.xml
file and find Permission markup:
<Permission>
<Name>Permission</Name>
<Value>0x00005077</Value>
<Width>4</Width>
<Default>0x00005077</Default>
<Tooltip>Enter Permission</Tooltip>
</Permission>
Within the Permission section above, the Integrator must set a Value markup with a value related to DA
permission:
•
Bit 14: When setting the Integrator authorized full regression,
•
Bit 12: When setting the Integrator authorized partial regression,
•
Bit 2: When setting the Integrator authorized debug reopening in the nonsecure domain.
Once the Integrator has updated DA_Config_General.xml, he must run the command below to generate the D
A_Config_General.obk file:
STM32TrustedPackageCreator_CLI.exe -obk ./WorkDir/DA_Config.xml
The Integrator has the privilege and the flexibility to select the DA permissions. Whatever his choice among the
values listed above, this falls within the scope of this evaluation and remains the certified configuration.
4.2.1.14
UM3238 - Rev 1
Module integration
The integrator might add its secure functions in a module, or add third‑party modules inside the secure domain in
the unprivileged part, in an isolated execution domain configured by the TOE.
When using modules, the Integrator must select the flash layout configuration 1 (SMAK_1) or higher.
The Integrator has the privilege and the flexibility to add its modules or third-party ones in the SPE without
compromising the TOE security. This privilege and flexibility fall within the scope of this evaluation and remain the
certified configuration.
page 33/49
UM3238
Operational user guidance
4.2.2
Available interfaces and methods of use (AGD_OPE.1.2C and AGD_OPE.1.3C)
To exercise the functions and privileges described in Section 4.2.1, the Integrator interacts with the TOE
interfaces described in this section:
•
•
•
•
•
•
•
•
•
4.2.2.1
Physical chip interface
STuROT image secondary slot interface (also called download slot)
Secure manager image secondary slot interface (also called download slot)
Nonsecure application image secondary slot interface (also called download slot)
Module image secondary slot interface (also called download slot)
Module signature configuration
Kernel API
PSA API interface
JTAG interface
Physical chip interface
After each product power-on or reset, the platform starts to execute STiRoT, STuRoT, and the Secure Manager
that manages the secure initialization of the platform. If an STuRoT image candidate is present in the STuRoT
download slot, STiRoT installs it in the STuRoT active slot. If a Secure Manager candidate, nonsecure application,
or secure module image is present in the respective download slot, STuRoT installs it in the respective active slot.
Method of use:
•
•
Power on the system as defined in RM0481.
Reset the STM32H573xx as defined in RM0481.
Parameters:
•
Not applicable
Actions:
•
•
•
Power-on or system reset.
STiRoT is executed. STiRoT installs the STuRoT image (if required) and jumps to STuRoT after an integrity
and authenticity verification. STuRoT installs the Secure Manager, secure module, and nonsecure
application images (if required) and jumps to the Secure Manager after an integrity and authenticity
verification.
If the integrity and authenticity verification is passed, the Secure Manager jumps to the nonsecure
application. If the integrity and authenticity verification fails, the Secure Manager jumps to the system
bootloader or performs a system reset (depending on the OEM configuration).
Errors:
The platform resets in the event of any of the following errors:
•
•
•
Violation (unexpected value) of the STM32H5 option byte values related to platform security.
STiRoT or STuRoT provisioned data error (data integrity failure or wrong value).
Internal tamper event.
If the jump to system bootloader configuration is disabled (OEM configuration as defined in Preparation of
Secure Manager configurations and secrets), the platform resets in the event of any of the following errors:
•
•
•
•
The STuRoT active slot image is not controlled successfully (authenticity and integrity).
The Secure Manager active slot image is not controlled successfully (authenticity and integrity).
The nonsecure application active slot image is not controlled successfully (authenticity and integrity).
The module active slot image is not controlled successfully (authenticity and integrity).
If the jump to system bootloader configuration is enabled (TOE configuration as defined in
Section 4.2.1.6: Local loader), the platform jumps to the system bootloader in the event of any of the following
errors:
•
•
•
•
UM3238 - Rev 1
The STuRoT active slot image is not controlled successfully (authenticity and integrity).
The Secure Manager active slot image is not controlled successfully (authenticity and integrity).
The nonsecure application active slot image is not controlled successfully (authenticity and integrity).
The module active slot image is not controlled successfully (authenticity and integrity).
page 34/49
UM3238
Operational user guidance
4.2.2.2
STuROT image secondary slot interface
This interface is only available if the Integrator selects the Secure Manager configuration that enables the system
bootloader to act as the local loader for STiRoT (refer to Section 4.2.1.6: Local loader).
Method of use:
•
•
To use the STuRoT image download slot, the system bootloader must be entered. For this, at least one of
the STuRoT, Secure Manager, nonsecure applications, or secure module active slots must contain an
invalid image.
The data must then be written in the correct image format in the STuRoT image download slot, and the
16‑byte magic word must be written in the slot area end location. This magic word is used by STiRoT to
detect that an image to be processed is present in the download slot.
Parameters:
•
The STuROT image candidate to write in the STuROT image download slot
Actions:
•
•
•
System reset
The Secure Manager (STiRoT) checks if a new STuROT candidate image is present in the STuROT image
download slot. Only STMicroelectronics can generate a new valid STuROT image.
When a new valid STuROT image is detected, the STiRoT component updates the STuROT image in the
STuROT image active slot.
Errors:
The STuROT image candidate is not installed in the STuROT image active slot. It is erased from the STuROT
image download slot in the event of any of the following errors:
•
•
•
•
•
•
•
4.2.2.3
The STuROT image size is inconsistent.
Flash memory reading errors (double ECC errors).
Version check failure: the STuROT image version is lower than the previously installed image.
STuROT image integrity failure.
STuROT image signature failure (image not authentic).
The STuROT image candidate is not installed in the STuROT image active slot. The platform resets in the
event of the following error.
Flash memory writing or erasing errors are reported by the flash memory driver used to write data in the
STuROT image active slot area.
Secure Manager image secondary slot interface
This interface is only available if the integrator selects the STuROT configuration that enables the system
bootloader to act as the local loader for STuROT (refer to Section 4.2.1.6: Local loader).
Method of use:
•
•
To use the Secure Manager image download slot interface, the system bootloader must be entered. For
this, at least one of the STuROT, Secure Manager, nonsecure application, or the secure module active slot
must contain an invalid image.
The data must then be written in the correct image format in the Secure Manager image download slot, and
the 16-byte magic word must be written in the slot area end location.
Parameters:
•
The Secure Manager image candidate to write in the Secure Manager download slot.
Actions:
•
•
•
System reset
The platform (STuROT) checks if a new Secure Manager image is present in the Secure Manager image
download slot. Only STMicroelectronics can generate a new valid Secure Manager image.
When a new valid Secure Manager image is detected, the STuROT updates the Secure Manager image in
the Secure Manager image active slot.
Errors:
The Secure Manager image candidate is not installed in the Secure Manager image active slot in the event of the
following error:
•
UM3238 - Rev 1
Version dependency failure: the version of the Secure Manager image is incompatible with the version of
another image (nonsecure application or secure module image).
page 35/49
UM3238
Operational user guidance
•
The image candidate is not installed in the Secure Manager image active slot and is erased from the
Secure Manager image download slot in the event of any of the following errors:
–
–
–
–
–
The Secure Manager image size is inconsistent.
Flash memory reading errors (double ECC errors).
Version check failure: the Secure Manager image version is lower than the previously installed
image.
Secure Manager image integrity failure.
Secure Manager image signature failure (image not authentic).
The Secure Manager image candidate is not installed in the Secure Manager image active slot, and the platform
resets in the event of the following error:
•
4.2.2.4
Flash memory writing or erasing errors are reported by the flash memory driver used to write data in the
Secure Manager image active slot area.
Nonsecure application image secondary slot interface
This interface is only available if the integrator selects the STuROT configuration that enables the system
bootloader to act as the local loader for STuROT (refer to Section 4.2.1.6: Local loader).
Method of use:
•
•
•
The nonsecure application image download slot region is located according to the selected flash memory
layout configuration.
To use the nonsecure application image download slot interface, the system bootloader must be entered.
For this, at least one of the STuROT, Secure Manager, nonsecure application, or secure module active
slots must contain an invalid image.
The data must then be written in the correct image format in the nonsecure application image download
slot, and the 16‑byte magic word must be written in the slot area end location.
Parameters:
•
The nonsecure application image candidate to write in the nonsecure application download slot.
Actions:
•
•
•
System reset:
The platform (STuROT) checks if a new nonsecure application image is present in the nonsecure
application image download slot. The PC tool STM32TrustedPackageCreator and the .xml file are delivered
to the OEM for the generation of a nonsecure application binary image with the right format.
When a new nonsecure application image is detected, STuRoT updates the nonsecure application image
in the nonsecure application image active slot.
Errors:
The nonsecure application candidate image is not installed in the nonsecure application image active slot in the
event of the following error:
•
•
Version dependency failure: the version of the nonsecure application image is incompatible with the version
of another image (Secure Manager or secure module image).
The candidate image is not installed in the nonsecure application image active slot and is erased from the
nonsecure application image download slot in the event of any of the following errors:
–
–
–
–
–
The nonsecure application image size is inconsistent.
Flash memory reading errors (double ECC errors).
Version check failure: the nonsecure application image version is lower than the previously installed
image.
Nonsecure application image integrity failure.
Nonsecure application image signature failure (image not authentic).
The candidate nonsecure application image is not installed in the nonsecure application image active slot and the
platform resets in the event of the following error:
•
UM3238 - Rev 1
Flash memory writing or erasing errors are reported by the flash memory driver used to write data in the
nonsecure application image active slot area.
page 36/49
UM3238
Operational user guidance
4.2.2.5
Module image secondary slot interface
This interface is only available if the integrator selects the STuROT configuration that enables the system
bootloader to act as the local loader for STuROT (refer to Section 4.2.1.6: Local loader).
Method of use:
•
•
•
The secure module image download slot region is located according to the selected flash memory layout
configuration.
To use the secure module image download slot interface, the system bootloader must be entered. For this,
at least one of the STuROT, Secure Manager, nonsecure applications, or secure module active slots must
contain an invalid image.
The data must then be written in the correct image format in the secure module image download slot, and
the 16-byte magic word must be written in the slot area end location.
Parameters:
•
The secure module image candidate to write in the secure module download slot.
Actions:
•
•
•
System reset
The platform (STuROT) checks if a new secure module image is present in the secure module image
download slot. The PC tool STM32TrustedPackageCreator and the XML file are delivered for the
generation of a secure module binary image with the right format.
When new secure module images are detected, the STuROT updates the secure module images in the
secure module images active slot.
Errors:
The secure module image candidates are not installed in the secure module image active slot in the event of the
following error:
•
Version dependency failure: the version of the secure module image is incompatible with the version of
another image (Secure Manager or nonsecure application image).
The image candidate is not installed in the secure module image active slot. It is erased from the secure module
image download slot in the event of any of the following errors:
•
•
•
•
•
The secure module image size is inconsistent.
Flash memory reading errors (double ECC errors).
Version check failure: the secure module image version is lower than the previously installed image.
Modules application image integrity failure.
Modules application image signature failure (image not authentic).
The secure module image candidate is not installed in the secure module image active slot and the platform
resets in the event of the following error:
•
UM3238 - Rev 1
Flash memory writing or erasing errors are reported by the flash memory driver used to write data in the
secure module image active slot area.
page 37/49
UM3238
Operational user guidance
4.2.2.6
Module configuration
A module to be installed is configured using the ukapp_config_descriptor.h file.
Parameters:
The ukapp_config_descriptor.h file contains the module behavior configuration and resources that are
considered by the STM32TRUSTEE-SM (Secure Manager) at module initialization. The module owner must fill
this file before providing its module to the Integrator.
The available module configurations are listed in Table 7:
Table 7. Available module configurations
Defined name
Configuration target
Dukapp_config_UKAPP_PROFILE
Behavior of the module (reincarnation)
Dukapp_config_PRIORITY
Kernel scheduling priority
Dukapp_config_TIME_QUANTUM_systick
Kernel scheduling quantum
Dukapp_config_PrivilegedServicesAuthorizedBitMask64
Kernel service authorization
Dukapp_config_PIRQMCUIndexAuthorized
IRQ
Dukapp_config_IPCSendToAuthorizedASID
Service or module authorized to send
Dukapp_config_SharedBufferDescriptorList
Shared buffer
Dukapp_config_AddressBlockExtraDescriptorList
Nonprivileged register
Dukapp_config_MCURegisterDescriptorList
Privileged registers
Dukapp_config_DMAStreamDescriptorList
DMA stream
Dukapp_config_DebugTraceNatureFilter
Log level
A configuration example is given in [UKDESCRIPTOR].
Actions:
•
•
Power-on or system reset
Secure Manager initializes a module using the configuration file.
Errors:
The module is not instantiated (not initialized and not usable) by the Secure Manager in the event of any of the
following errors:
•
The ukapp_config_descriptor.h file is mal-formatted.
•
The ukapp_config_descriptor.h file contains a wrong value for some of the resources and module
behavior configuration items.
Some resources in the ukapp_config_descriptor.h file are already exclusively allocated to another
previously instantiated module.
•
4.2.2.7
Kernel API
The Secure Manager core exposes kernel APIs to modules running in a secure nonprivilege domain. The file
C:\STM32CubeFirmware_Installation_path\Middlewares\ST\secure_manager_api\SecureMana
gerAPI.chm lists all STM32TRUSTEE-SM kernel APIs with their complete documentation.
As an example of a kernel API, the ukAddressBlockWindowMap is illustrated here.
Method of use:
•
Call the function:
–
UM3238 - Rev 1
TukSTATUS ukAddressBlockWindowMap(TukADDRESSBLOCKWINDOW_IDX abwidx__i,
TukADDRESSBLOCK_ID abid__i);
page 38/49
UM3238
Operational user guidance
Parameters:
•
(TukADDRESSBLOCKWINDOW_IDX)abwidx__i Index of Address Block Window into which
we want to map the given Address Block.
•
(TukADDRESSBLOCK_ID)abid__i: The identifier of the address Block to be mapped.
–
The address Block identifier must be of DukADDRESSBLOCK_ID_NATURE_EXTRA_IDX or
DukADDRESSBLOCK_ID_NATURE_SHAREDBUFFER_BUNDLE_ID nature.
Actions:
This function is used to map an address block in the ukProc address space. Once the address block is mapped
in the ukProc address space, ukProc can perform direct access operations in the address range of the address
block.
Errors:
•
•
•
•
•
•
•
•
4.2.2.8
DukSTATUS_INFO_OK: No error. The mapping has been done successfully.
DukSTATUS_ERR_PARAM: The given address Block Windows index is invalid.
DukSTATUS_ERR_PARAM: The given address Block identifier is invalid.
DukSTATUS_ERR_NOT_SUPPORTED: The given address Block identifier nature is not supported.
DukSTATUS_ERR_CREDENTIALS: The current ukProc is not the managing ukProc of the referenced
address Block.
DukSTATUS_ERR_CREDENTIALS: The referenced address Block does not have at least read credentials
set for the current ukProc.
DukSTATUS_ERR_IN_USE: The referenced address Block Windows is already mapping another address
Block.
DukSTATUS_ERR_ALREADY: The referenced address Block is already mapped in this ukProc.
PSA API interface
The Integrator nonsecure application calls STM32TRUSTEE-SM and module (if any) services through the PSA
API interfaces ([PSA_ST_API], [PSA_CRYPTO_API], [PSA_ATTESTATION_API], and [PSA_FW_UPDATE_API]).
The detailed parameters, actions, and error messages are described in the PSA developer APIs [PSA_ST_API],
[PSA_CRYPTO_API], [PSA_ATTESTATION_API], and [PSA_FW_UPDATE_API].
The nonsecure application interacts with the secure application via the standard PSA APIs as explained in the
open-source documents [PSA_ST_API], [PSA_CRYPTO_API], [PSA_ATTESTATION_API], and
[PSA_FW_UPDATE_API], which describes each PSA API.
As an example, the psa_cipher_decrypt API is illustrated here:
Method of use:
Call the following function.
UM3238 - Rev 1
page 39/49
UM3238
Operational user guidance
Parameters:
Actions:
UM3238 - Rev 1
page 40/49
UM3238
Operational user guidance
Errors:
UM3238 - Rev 1
page 41/49
UM3238
Operational user guidance
4.2.2.9
JTAG interface
Standard JTAG with SWD interface allows programming data inside the TOE and allows debugging of the TOE
and Integrator application. It is used according to [IEE1149] and [ADI5].
Debug Authentication is accessed at boot when writing STDA under reset in a dedicated 32‑bit register (DBGMCU)
via JTAG. When the product state is CLOSED, JTAG is closed and only this DBGMCU register can be accessed.
According to the product state of the TOE, the Debug Authentication through JTAG can perform several actions:
•
•
•
Open HDPL3-NS nonsecure domain debug when the product state is CLOSED. This action is configurable
by the Integrator. Refer to Section 4.2.1.13: Debug Authentication permissions.
Perform a full regression (erasing all flash memory and OB keys)
Perform a partial regression (erase only nonsecure flash memory area and OB keys)
Debug Authentication protocol is based on ARM PSA ADAC, which uses a certificate chain and a
challenge‑response principle to trigger the requested action. Refer to the Arm® document on Debug
Authentication to get more details on the Debug Authentication protocol.
Method of use:
•
Write STDA in DBGMCU register under reset then inject certificates and tokens through DBGMCU to trigger an
action.
Parameters:
•
Commands can be sent to Debug Authentication to trigger actions through DBGMCU and JTAG.
•
Root and leaf certificates (containing keys and permissions) and tokens (containing the signed challenge
and the requested action). Refer to the Arm® document on Debug Authentication.
Actions:
•
•
Discovery command: Allows to know the capabilities of the Debug Authentication.
Authentication start: Triggers the beginning of the authentication procedure.
–
–
–
The first step is the generation of a random challenge by the device sent to the host.
Then the host sends certificates (root and leaf) which are verified (the root certificate is linked to the
hash of the public key stored in a 256‑bit field in HDPL1 OB keys) and sends the token.
Finally, according to the permissions defined in the device (the maximum capabilities of the Debug
Authentication are defined in a 128‑bit field in HDPL1 OB keys) and to the permissions defined in the
certificates, whether the requested action is triggered or not. The concerned actions are:
◦
◦
◦
◦
Open debug (for the different HDPLs)
Perform a full regression (erasing all flash memory and OB keys)
Perform a partial regression (erase only nonsecure flash memory area and OB keys)
Lock debug command: Allows to close the debug after it is opened by an authentication
procedure.
Errors:
The action is not executed. An error message is returned to the host in case of the following errors:
•
•
•
4.2.3
If the requested action does not match the allowed permissions or the authorized product state
If the root certificate does not match the public key stored in HDPL1 OB keys
If the signed random challenge is not the right one
Security-relevant events (AGD_OPE.1.4C)
Once configured according to Section 3.2, TOE detects any unauthorized access and any unexpected
configuration as described hereafter:
•
•
UM3238 - Rev 1
Secure Peripherals access violations from any non-secure domain masters are “transparent” (silent fail
mechanism):
–
Any read operations return “0”
–
Any write operations are ignored.
Secure Memories access violation from a non-secure domain generates a reset: non‑secure domain (CPU)
accessing secure memories (Flash or SRAM) without going through the secure domain entry point (i.e.
calling the secure callable functions exported to the non-secure domain).
page 42/49
UM3238
Operational user guidance
•
•
•
Secure peripherals access privilege violations are “transparent” (silent fail mechanism): secure unprivileged
domain (CPU) accessing the secure privilege domain (peripherals) without going through the privilege
domain entry point (i.e. calling SVC call function).
–
Any read operations return “0”
–
Any write operations are ignored.
Secure memory access privilege violation resets the product: secure unprivileged domain (CPU) accessing
the secure privilege domain (memory or peripherals) without going through the privilege domain entry point
(i.e. calling SVC call function).
Secure DMA privilege access violation:
–
•
•
•
•
•
•
◦
Any read operations return “0”
◦
Any write operations are ignored.
STiRoT/STuRoT access violation during application execution: STiRoT/STuRoT applies temporal isolation
(HDPL) and switches from HDPL1/HDPL2 to HDPL3 when jumping into the non‑secure system bootloader
or jumping into firmware image. At this point, any access attempt inside HDPL1/HDPL2 is detected and
managed following read as 0 write ignore access policy.
Images authenticity or integrity violation: in case of corrupted image authenticity or integrity (one of the
images or the 2 images), it is detected during the TOE secure boot procedure launched after any product
reset and the TOE does not start to execute the corrupted images but starts to execute the non‑secure
immutable non‑secure system bootloader. Using the non‑secure system bootloader, new valid image(s)
can be downloaded in the image(s) secondary slots. Once downloaded, these new images are verified and
installed. In case images are corrupted during the application execution, then the problem is detected at
the next product reset.
STM32H573xx option bytes values violation: in case STM32H573xx option bytes values are not correctly
configured to ensure the TOE security, the TOE secure boot procedure after reset detects the problem and
blocks the TOE secure boot procedure execution: Reset is generated. To unlock the product, a full
regression must be executed through the Debug Authentication process.
PSA API violation: Any calls to PSA APIs go through a secure/privileged fix entry point managed by the
TOE. The TOE secure/privileged entry point controls the access to the Secure Manager, from the nonsecure application or the secure/non-privileged services, by checking the validity of the parameters of any
operation requested. Any PSA API access violations (secure or privileged) result in an error code sent to
the PSA API client
JTAG access violation: Once TOE security is fully configured, the product cannot be debugged via the
JTAG interface anymore. The debug reopening is controlled through the Debug Authentication process.
Once authenticated, the permission mask configured inside the STM32H573xx MCU and the permission
masks set inside the certificate chain allow or not the debug reopening in the selected mode:
–
Debug HDPL3 Non-Secure
Tampering:
–
4.2.4
Secure DMA privilege access violation on privilege peripherals/memories from the secure
unprivileged domain are transparent (silent fail mechanism):
STM32H573xx anti‑tamper mechanisms (internal tampers) are activated in the TOE for system reset
and cryptographic IP tamper detection. In such cases, backup registers, backup SRAM, SRAM2,
caches, and cryptographic peripherals are erased. Then, the product is reset.
Security measures (AGD_OPE.1.6C)
To verify the correct version of all platform components, the following measures must be taken:
•
Follow all guidelines described in Secure acceptance.
To achieve KEY_MANAGEMENT:
•
The integrator must protect the integrity and confidentiality of the keys depicted in Section 4.2.1.10: Secure
Manager keys.
To achieve TRUSTED_USERS:
•
•
UM3238 - Rev 1
The persons responsible for the application of the procedures described in Section 3: TOE preparative
procedures and the persons involved in the delivery and protection of the product must have the required
skills and must be aware of security issues.
In the case that any part of the preparative procedures of the TOE or any part of the preparative
procedures of the integrated IoT solution is executed by a party other than the integrator, the integrator
must guarantee that sufficient guidance is provided to this party.
page 43/49
UM3238
Operational user guidance
To achieve UNIQUE_ID:
•
Using the TOE, the Integrator achieves the UNIQUE_ID security objective.
–
–
–
The TOE supports the PSA initial attestation service.
This service supplies an API to get an authenticated token.
This token contains a claim-named instance ID, which is unique per chip.
The following measures must be taken to achieve the correct usage, configuration, and installation of the TOE:
•
•
•
•
•
4.2.5
The Integrator gets its nonsecure application that strictly calls TOE services through the API depicted in
Section 4.2.2: Available interfaces and methods of use (AGD_OPE.1.2C and AGD_OPE.1.3C).
The Integrator must follow all guidelines described and referenced in Section 3.2: Secure installation and
secure preparation of the operational environment (AGD_PRE.1.2C).
The Integrator must follow all guidelines described in the section Section 3.3.1.1: Preparation of Secure
Manager configurations and secrets with the configuration items depicted in Section 4.2.1: User‑accessible
functions and privileges (AGD_OPE.1.1C) to configure the TOE.
The Integrator must follow all the guidelines in the section Section 3.3.1.2: Integrator's full image
generation to build its Integrator full image; this is the image containing the TOE, the Integrator nonsecure
application, and the modules (if any).
The Integrator must follow all guidelines in Section 3.3.2: Integrator installation flow.
Modes of operation (AGD_OPE.1.5C)
The TOE operates after the product reset by executing the TOE immutable root of trust (STiROT). The only
interfaces are the flash memory slots where new images can be downloaded (STuROT secondary slot interfaces).
•
•
In case a new image to install is available then TOE verifies it and installs it if valid.
In case there is no new image to be installed, the TOE verifies the installed STuRoT images. If the installed
images are valid, then the STiROT starts the STuROT.
–
–
–
STuROT, in turn, checks if new images are present within secondary slots (for Secure Manager,
nonsecure application, and secure modules).
If so, STuROT installs them within the primary slot. If no new images are present within the
secondary slot, it verifies the installed images (secure and nonsecure images). If those images are
valid, STuROT starts the Secure Manager.
In case there are no valid images (meaning a valid secure image and a valid nonsecure image)
installed and no new images in the nonsecure image secondary slot and/or the nonsecure image
secondary slot to be installed, then the TOE either resets or starts the standard system bootloader as
a local loader according to TOE configuration.
Once the Secure Manager is correctly initialized, it starts the nonsecure application. The nonsecure application
uses the PSA APIs exported by the TOE to request the TOE to execute secure services. The secure modules
also used PSA APIs exported by the TOE to request the TOE to execute secure services.
If the product is blocked, the only way to unblock it is to do a regression. It erases all the flash memory content
using a debug authentication procedure.
In case the STM32H5 option bytes values are not correctly configured to ensure the TOE security, the TOE
secure boot detects the problem, blocks its execution flow, and resets the STM32H573xx.
To unblock the product, the STM32H5 option bytes must be completely reprogrammed. This is performed after a
regression that erases the STM32H5 flash memories in the case of a CLOSED product state, following the
preparation procedure as described in Section 3.3.1: Integrator application creation flow.
UM3238 - Rev 1
page 44/49
UM3238
Revision history
Table 8. Document revision history
UM3238 - Rev 1
Date
Revision
20-Feb-2024
1
Changes
Initial release.
page 45/49
UM3238
Contents
Contents
1
General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2
Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3
TOE preparative procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1
Secure acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2
Secure installation and secure preparation of the operational environment
(AGD_PRE.1.2C) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3
4
3.2.1
Hardware setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2
Host integrator setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3
Integrator environment setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Secure installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1
Integrator application creation flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2
Integrator installation flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Operational user guidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
4.1
User roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2
Operational guidance for the integrator role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.1
User‑accessible functions and privileges (AGD_OPE.1.1C) . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2
Available interfaces and methods of use (AGD_OPE.1.2C and AGD_OPE.1.3C) . . . . . . . 34
4.2.3
Security-relevant events (AGD_OPE.1.4C). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.4
Security measures (AGD_OPE.1.6C) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.5
Modes of operation (AGD_OPE.1.5C) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
List of figures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
UM3238 - Rev 1
page 46/49
UM3238
List of tables
List of tables
Table 1.
Table 2.
Table 3.
Table 4.
Table 5.
Table 6.
Table 7.
Table 8.
Specific acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
List of reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
List of communication peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Full image breakout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Module type description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Option byte list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Available module configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
UM3238 - Rev 1
page 47/49
UM3238
List of figures
List of figures
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
UM3238 - Rev 1
Secure manager preparation and installation flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
TOE scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
STM32TrustedPackageCreator menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Predefined memory mapping configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
SRAM memory mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
SRAM memory mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
page 48/49
UM3238
IMPORTANT NOTICE – READ CAREFULLY
STMicroelectronics NV and its subsidiaries (“ST”) reserve the right to make changes, corrections, enhancements, modifications, and improvements to ST
products and/or to this document at any time without notice. Purchasers should obtain the latest relevant information on ST products before placing orders. ST
products are sold pursuant to ST’s terms and conditions of sale in place at the time of order acknowledgment.
Purchasers are solely responsible for the choice, selection, and use of ST products and ST assumes no liability for application assistance or the design of
purchasers’ products.
No license, express or implied, to any intellectual property right is granted by ST herein.
Resale of ST products with provisions different from the information set forth herein shall void any warranty granted by ST for such product.
ST and the ST logo are trademarks of ST. For additional information about ST trademarks, refer to www.st.com/trademarks. All other product or service names
are the property of their respective owners.
Information in this document supersedes and replaces information previously supplied in any prior versions of this document.
© 2024 STMicroelectronics – All rights reserved
UM3238 - Rev 1
page 49/49
">