AN5447

Application note

Overview of Secure Boot and Secure Firmware Update solution

on Arm® TrustZone® STM32 microcontrollers

Introduction
This application note describes how to get a Secure Boot and Secure Firmware Update solution on Arm® TrustZone® STM32
microcontrollers based on the Arm® Cortex®‑M33 processor. It also provides a top-level comparison of this solution versus
the X-CUBE-SBSFU solution, which applies to non-TrustZone® STM32 microcontrollers based on the Arm® Cortex®‑M0,
Cortex®‑M3, Cortex®‑M4, or Cortex®‑M7 processors. It provides as well top-level integration guidelines for the Secure Boot and
Secure Firmware Update solution.
For Arm® TrustZone® STM32 microcontrollers, a Secure Boot and Secure Firmware Update solution is provided in the
corresponding STM32Cube MCU Package. Contrary to the solution proposed in the X-CUBE-SBSFU STM32Cube Expansion
Package, it is based on the open-source TF‑M (Trusted Firmware for Arm® Cortex®‑M) reference implementation.
This application note applies to all TrustZone® STM32 microcontrollers (refer to Table 1). However, in this document, the
STM32L5 Series is used as an example.
Depending on the TrustZone® STM32 microcontroller, TF‑M-based application available in the STM32Cube MCU Package may
differ. Refer to the user manual of the TFM application (complete implementation of TF‑M) of the considered Arm® TrustZone®
STM32 microcontroller (see Section 2 References) to get a precise description of the solution.
To get more information about the open-source TF‑M reference implementation, refer to [TF‑M].
Table 1. Applicable products

Type Product series

Microcontrollers STM32L5 Series, STM32U5 Series

AN5447 - Rev 3 - August 2021 www.st.com

For further information contact your local STMicroelectronics sales office.
 AN5447
General information

1 General information

Throughout this application note, the terminology X-CUBE-SBSFU refers to the Secure Boot and Secure
Firmware Update solution available in the X-CUBE-SBSFU STM32Cube Expansion Package, whereas the
terminology SBSFU refers to the Secure Boot and Secure Firmware Update solution available in the STM32Cube
MCU Packages of Arm® TrustZone® STM32 microcontrollers (STM32CubeL5 is used as an example).
Table 2 presents the definition of acronyms that are relevant for a better understanding of this document.

Table 2. List of acronyms

Acronym Definition

AEAD Authenticated encryption with associated data

AES Advanced encryption standard
CBC AES cipher block chaining
CTR AES counter mode
EAT Entity attestation token
ECDSA Elliptic curve digital signature algorithm
GCM AES Galois/counter mode
HDP Hide protection
HUK Hardware unique key
ITS Internal trusted storage
KMS Key management services
MAC Message authentication code
MPU Memory protection unit
OEM Original equipment manufacturer
OTFDEC On-the-fly decryption
PKCS Public-key cryptography standard
PSA Platform security architecture. Framework for securing devices
RDP Read protection
RoT Root of Trust
RSA Rivest–Shamir–Adleman algorithm
SBSFU Secure Boot and Secure Firmware Update
SST Secure storage service. Secure storage service provided by TF‑M

TBSA-M Trusted base system architecture for Arm® Cortex®-M

Trusted Firmware for M-class Arm® processors. TF‑M provides a reference implementation of secure
TF‑M
world software for Armv8-M
TFM Name of the TF‑M-based application with complete functionalities in the STM32Cube MCU Package

TZ TrustZone®
WRP Write protection

Note: Arm and TrustZone are registered trademarks of Arm Limited (or its subsidiaries) in the US and or elsewhere.

AN5447 - Rev 3 page 2/22

 AN5447
References

2 References

The resources presented in Table 3 and Table 4 below are public and available either on STMicroelectronics web
site at www.st.com or on third-parties websites.

Table 3. Document references

Reference Document

Application note(1):
[AN5156]
Introduction to STM32 microcontrollers security.

User manual(1):
[UM2262]
Getting started with the X-CUBE-SBSFU STM32Cube Expansion Package.

User manual(1):
[UM2671]
Getting started with STM32CubeL5 TFM application.

User manual(1):
[UM2851]
Getting started with STM32CubeU5 TFM application.
PSA developer APIs:
[PSA_API] developer.arm.com/architectures/security-architectures/platform-security-architecture#implement
(2)

1. Available on www.st.com. Contact STMicroelectronics when more information is needed.

2. This URL belongs to a third party. It is active at document publication, however STMicroelectronics shall not be liable for any
change, move or inactivation of the URL or the referenced material.

Table 4. Open-source software resources

Reference Open-source software resource

TF‑M (Trusted Firmware‑M) Arm Limited driven open-source software framework:

[TF‑M]
www.trustedfirmware.org/(1)
MCUboot open-source software:
[MCUboot]
mcuboot.com(1)
mbed-crypto open-source software:
[mbed-crypto]
github.com/ARMmbed/mbed-crypto(1)
PSA certification website:
[PSA]
www.psacertified.org(1)

1. This URL belongs to a third party. It is active at document publication, however STMicroelectronics shall not be liable for any
change, move or inactivation of the URL or the referenced material.

Note: Mbed is a trademark of Arm Limited (or its subsidiaries) in the US and or elsewhere.

AN5447 - Rev 3 page 3/22

 AN5447
Arm® Trusted Firmware‑M (TF‑M) introduction

3 Arm® Trusted Firmware‑M (TF‑M) introduction

TF‑M (refer to [TF‑M]) is an Arm Limited driven open-source software framework providing a reference
implementation of the PSA standard on the Arm® Cortex®-M33 (TrustZone®) processor:
• PSA immutable RoT (Root of Trust): immutable “Secure Boot and Secure Firmware Update” application
executed after any reset. This application is based on MCUboot open source software (refer to [MCUboot]).
• PSA updatable RoT: “secure” application implementing a set of secure services isolated in the secure/
privileged environment that can be called by the non-secure application at non-secure application run-time
via the PSA APIs (refer to [PSA_API]):
– Secure storage service: TF‑M secure storage (SST) service implements PSA protected storage APIs
allowing data encryption and writing the result in a possibly untrusted storage. The SST service
implements an AES-GCM based AEAD encryption policy, as a reference, to protect data integrity and
authenticity.
– Internal trusted storage service: TF‑M internal trusted storage (ITS) service implements PSA internal
trusted storage APIs allowing the writing of data in a microcontroller built-in Flash memory region that
will be isolated from non-secure or from unprivileged applications by means of the hardware security
protection mechanisms.
– Cryptography service: the TF‑M crypto service implements the PSA Crypto APIs that allow an
application to use cryptography primitives such as symmetric and asymmetric ciphers, hash, message
authentication codes (MACs), and authenticated encryption with associated data (AEAD). It is based
on the mbed-crypto open-source software (refer to [mbed-crypto]).
– Initial attestation service: the TF‑M initial attestation service allows the application to prove the device
identity during an authentication process to a verification entity. The initial attestation service can create
a token on request, which contains a fix set of device specific data.
• Application updatable RoT: third-party secure services that are isolated in the secure/unprivileged
environment and that can be called by the non-secure application at non-secure application run-time.

Figure 1. TF‑M overview

Isolation Isolation
secure / non-secure privileged / unprivileged
Non-secure Secure
(such as Crypto, NONCE, RNG)
Internal trusted storage

Apps
Initial attestation

Platform drivers
Secure storage

Cryptography
3rd party
PSA API

Network Middleware

OS
TF-M Core (IPC, SPM, interrupt handling) MCU boot

TBSA-M Hardware (SoC)

Application updatable RoT PSA updatable RoT PSA immutable RoT TF-M Isolation boundary

AN5447 - Rev 3 page 4/22

 AN5447
X-CUBE-SBSFU vs. TF‑M comparison

4 X-CUBE-SBSFU vs. TF‑M comparison

4.1 Overview
X-CUBE-SBSFU provides an STMicroelectronics implementation of Secure Boot and Secure Firmware Update,
and optionally for some STM32 series only, secure KMS (key management services) service available at run-time
for the user application.
The TF‑M reference implementation provides Secure Boot and Secure Firmware Update services based on
open-source MCU boot, and a set of secure services available at run-time for the user application.
The high-level comparison between X-CUBE-SBSFU and TF‑M is shown in Figure 2.

Figure 2. X-CUBE-SBSFU vs. TF‑M overview

X-CUBE-SBSFU TF-M

Secure Boot
SBSFU MCU boot
Secure Firmware Update

KMS*

(**) Each crypto algorithm can

be independently deactivated
(key management services)

Initial attestation

Initial trusted storage

Secure storage
TFM-core
Secure application
with secure services
available at run-time

(*): Deployed only on the

STM32L4 Series and STM32L4+ Series
Secure crypto**
: Modularity

The MCU boot part of the TF‑M can be compared to X-CUBE-SBSFU (without KMS): it offers similar services.
X-CUBE-SBSFU KMS supports similar services as TF‑M secure crypto services but the lists of cryptographic
algorithms or features are not the same and APIs are different even if both are based on an opaque
key API concept. Refer to the X-CUBE-SBSFU and TF‑M APIs documents referenced in the related user
manuals ([UM2262] and TFM user manual of the concerned Arm® TrustZone® STM32Cube MCU Package; see
Section 2 References) to get more details about the supported features.

AN5447 - Rev 3 page 5/22

 AN5447
Top-level features

4.2 Top-level features

Even if X-CUBE-SBSFU and TF‑M propose similar services, the features of both solutions are not exactly the
same. Table 5 summarizes the differences between X-CUBE-SBSFU in X-CUBE-SBSFU V2.4.0 and TF‑M-based
applications in STM32CubeL5 V1.4.0 as an example.

Table 5. X-CUBE-SBSFU vs. TF‑M top-level features

Security
X-CUBE-SBSFU in X-CUBE-SBSFU V2.4.0(1) TF‑M in STM32CubeL5 V1.4.0(1)
topic

1 or 2 slots per image. 1 or 2 slots per image.

New image via local loader or USER APP. New image via local loader or USER APP.
Encrypted image execution in external Flash memory. Encrypted image execution in external Flash memory.
Single firmware image or multiple (2) firmware images
SBSFU

Single firmware image.

(secure and non-secure).
Full or partial update.
Full update only.
Symmetric crypto scheme.
Asymmetric crypto scheme (RSA or ECDSA) with or
Asymmetric crypto scheme (ECDSA) or symmetric without firmware encryption.
crypto scheme, with or without firmware encryption.
Secure services Secure services
• 1 level of isolation • 2 levels of isolation
Run-time secure services

• Non-secure interruption managed (STM32L4+ • Non-secure interruption managed

Series only) • Complete crypto services (full SW or mixed
• Main crypto services (STM32L4 Series and SW&HW)
STM32L4+ Series only) • Initial attestation
• Secure Storage (data encryption/integrity)
• Internal trusted storage (data integrity)
• Architecture ready to integrate unprivileged
application services

1. Differences are highlighted in bold.

To get an up-to-date view of the feature differences between X-CUBE-SBSFU and TF‑M-based applications for
Arm® TrustZone® STM32 microcontrollers, refer to the latest version of [UM2262] and of the TFM user manual of
the concerned Arm® TrustZone® STM32Cube MCU Package (see Section 2 References).

AN5447 - Rev 3 page 6/22

 AN5447
Hardware security

4.3 Hardware security

The security strategy of the TF‑M-based applications is relying on TrustZone® and STM32 microcontroller
hardware security features.
Figure 3 shows the comparison of this security strategy (for the STM32L5 Series as an example) with the SBSFU
security strategy in X-CUBE-SBSFU (for the STM32L4 Series as example).

Figure 3. X-CUBE-SBSFU (STM32L4 Series) and TF‑M (STM32L5 Series) security strategy overview

Secure functions

Unique boot entry RDP L2 Boot lock + RDP L1*

Secure Boot Root of Trust RDP L2 + WRP + MPU

Secure FW Update SFU keys Firewall + PCROP TZ + WRP + MPU + HDP + RDP L1*

SFU crypto operations Firewall

Run-time
Isolation Firewall (2 domains) TZ + MPU (3 domains)
secure services

KMS TFM secure services (secure/privileged)

Secure services
+ OEM specific functions + OEM specific functions (secure/unprivileged)

JTAG disconnection RDP L2 RDP L1*

External
Anti-tamper Static tamper pin Static tamper pin
access protection
Not used in the security examples
delivered in STM32CubeL5 V1.4.0

External Flash memory

OTFDEC
protection

(*) RDP L1 is the minimum for PSA L2 certification

TZ: Arm® TrustZone® STM32L4 Series STM32L5 Series

For more details on security strategy with TF‑M, refer to the TFM user manual of the concerned Arm® TrustZone®
STM32Cube MCU Package (see Section 2 References).

AN5447 - Rev 3 page 7/22

 AN5447
TF‑M-based applications

5 TF‑M-based applications

This chapter presents the TF‑M-based applications in the STM32Cube MCU Packages of Arm® TrustZone®
STM32 microcontrollers.
The Arm® TrustZone® STM32Cube MCU Packages propose two different applications based on the TF‑M
reference implementation, ported onto the Arm® TrustZone® STM32 microcontrollers to take benefit of the
hardware security features.
• SBSFU: it consists of the “Secure Boot and Secure Firmware Update” application (named SBSFU_Boot)
and simple user application example (named SBSFU_Appli). A local loader application example (named
SBSFU_Loader) is also included.
• TFM: it consists of the “Secure Boot and Secure Firmware Update” application (named TFM_SBSFU_Boot)
and user application with TFM secure services at run-time (named TFM_Appli). A local loader application
example (named TFM_Loader) is also included.
Users of X-CUBE-SBSFU without KMS are advised to consider the migration to the SBSFU application in the
Arm® TrustZone® STM32Cube MCU Package of interest. Users of X-CUBE-SBSFU with KMS are advised to
consider the migration to the TFM application in the Arm® TrustZone® STM32Cube MCU Package of interest
(possibly removing some secure services or cryptographic algorithms to fit the application needs).

Figure 4. STM32CubeL5 applications based on TF‑M

Secure Boot and Secure Firmware Update

Starting example when adapting a standard X-CUBE-SBSFU
example.

Secure Boot and Secure Firmware Update + TF-M secure services.

For each application, the memory footprint depends on the configuration (refer to the Memory layout section in the
TFM user manual of the concerned Arm® TrustZone® STM32Cube MCU Package; see Section 2 References).

AN5447 - Rev 3 page 8/22

 AN5447
TF‑M-based applications

By removing the TF‑M secure services at run-time and by proposing one firmware image configuration combined
with primary slot only configuration, the SBSFU application in the Arm® TrustZone® STM32Cube MCU Package
of interest maximizes the amount of internal Flash memory available for the user application as illustrated in
Figure 5.

Figure 5. Memory footprint example of STM32CubeL5 applications based on TF‑M

Local loader Local loader (24 Kbytes)

Local loader (32 Kbytes) (optional)

Unused (8 Kbytes)

Non-secure image secondary slot

Download slots area 3
(56 Kbytes)

Secure image secondary slot

Internal user Flash (512 Kbytes)

area 2
(144 Kbytes)

Non-secure image primary slot Non-secure image primary slot

(including minimal secure app.) User application area 1
area 0 (56 Kbytes)
(428 Kbytes)
Secure image primary slot
Secure services
area 0
application
(144 Kbytes)

ITS area (8 Kbytes)

Secure services
SST area (8 Kbytes)
NV data
NV COUNTER (4 Kbytes)
HDP activation code HDP activation code

SBSFU_Boot MCU boot TFM_SBSFU_Boot

(46 Kbytes) (53.8 Kbytes)

Personalized
Integrator perso data (2 Kbytes) Integrator perso data (2.2 Kbytes)
keys / data
BL2 NVCNT (4 Kbytes) BL2 NVCNT (4 Kbytes)

STM32CubeL5 SBSFU STM32CubeL5 TFM

(internal Flash memory
configuration)

For more details on memory mapping, refer to the Memory layout section in the TFM user manual of the
concerned Arm® TrustZone® STM32Cube MCU Package (see Section 2 References).

AN5447 - Rev 3 page 9/22

 AN5447
SBSFU application

6 SBSFU application

This chapter presents the SBSFU application in the STM32Cube MCU Packages of Arm® TrustZone® STM32
microcontrollers.

6.1 User application integration

When migrating from the X-CUBE-SBSFU application to the SBSFU application in an Arm® TrustZone®
STM32Cube MCU Package, the user application must be integrated into the SBSFU/SBSFU_Appli/NonSec
ure folder as shown in Figure 6.
This folder contains a simple user application example.

Figure 6. User application integration

Location to integrate user application

AN5447 - Rev 3 page 10/22

 AN5447
OEM secure services integration

6.2 OEM secure services integration

If OEM own secure services are also implemented in X-CUBE-SBSFU, these OEM secure services must
be integrated into the SBSFU/SBSFU_Appli/Secure and SBSFU/SBSFU_Appli/Secure_ncslib folders,
following TrustZone® HAL examples in STM32Cube MCU Packages, as shown in Figure 7.
These folders contain a simple example of OEM secure service: “Secure GPIO Toggle”.

Figure 7. OEM secure services integration (SBSFU)

Location to integrate OEM secure services

AN5447 - Rev 3 page 11/22

 AN5447
Keys personalization

6.3 Keys personalization

In X-CUBE-SBSFU, the personalization data are cryptographic keys:
• ECDSA asymmetric key: for firmware image signature
• AES symmetric key (CBC or GCM): for firmware image encryption
In SBSFU in STM32CubeL5 V1.4.0, for firmware image signature, there are two RSA or ECDSA asymmetric
keys (one for secure image, and one for non-secure image) to personalize, compared to one ECDSA asymmetric
key in X-CUBE-SBSFU. It must be noticed that contrary to X-CUBE-SBSFU, the public asymmetric keys are not
automatically generated during the build process of STM32CubeL5 SBSFU but need to be provided by the user
together with the private asymmetric keys (refer to Figure 8).
SBSFU in STM32CubeL5 V1.4.0 supports firmware encryption with AES-CTR cryptography. Compared to X-
CUBE-SBSFU, the AES-CTR key is not present in the personalized data, but is randomly generated during
each build process, is encrypted (RSA-OAEP or ECIES-P256) and provided in the firmware image itself. The
asymmetric key (RSA or ECDSA) used to encrypt the AES-CTR key is distinct from the asymmetric signature
keys. Both public and private asymmetric keys for AES-CTR key encryption must be provided by the user (refer to
Figure 8).

Figure 8. Firmware image keys personalization

Build Public ECDSA

process asymmetric key Public asymmetric keys
for AES key (CTR)
encryption

Private asymmetric keys

for AES key (CTR)
Private ECDSA
encryption
asymmetric key
Public asymmetric keys
for secure and non-secure
image signature

Private asymmetric keys

for secure and non-secure
image signature

AES symmetric key (CTR)

AES symmetric key
randomly generated during
(CBC or GCM)
the build process

The two private RSA or ECDSA asymmetric keys used to sign the secure and non-secure firmware images are
not embedded in the Flash memory, whereas the two associated public RSA or ECDSA asymmetric keys are
present in the build output of the SBSFU_Boot project. They are embedded in a dedicated immutable Flash
region (personalization data area) as shown in Figure 9.

AN5447 - Rev 3 page 12/22

 AN5447
Keys personalization

The public RSA or ECDSA asymmetric key used to encrypt the AES-CTR key is not embedded in the Flash
memory, whereas the associated private RSA or ECDSA asymmetric key is present in the build output of
SBSFU_Boot project, in the personalization data area as well, as shown in Figure 9.

Figure 9. Integrator personalized data area in STM32CubeL5 SBSFU

Local loader

Non-secure image primary slot

(including minimal secure app.)
area 0

HDP activation code

SBSFU_Boot
Public RSA or ECDSA asymmetric key for secure image signature
Public RSA or ECDSA asymmetric key for non-secure image signature
Integrator perso data Private RSA or ECDSA asymmetric key for AES-CTR key decryption
BL2 NVCNT

STM32CubeL5 SBSFU

AN5447 - Rev 3 page 13/22

 AN5447
TFM application

7 TFM application

This chapter presents the TFM application in the STM32Cube MCU Packages of Arm® TrustZone® STM32
microcontrollers.
The top-level integration guidelines provided in Section 6 SBSFU application are applicable to the TFM
application in STM32Cube MCU Packages. In this section, additional top-level integration guidelines, specific
to the TFM application in STM32Cube MCU Packages, are provided.
To get more information on the TFM application in STM32Cube MCU Packages, refer to the TFM user manual of
the concerned Arm® TrustZone® STM32Cube MCU Package (see Section 2 References).

7.1 Cryptographic secure services at run-time

In X-CUBE-SBSFU, the KMS services are provided to the user application through PKCS#11 APIs. In the TFM
application in STM32Cube MCU Packages, the secure cryptography services are provided to the user application
through PSA cryptographic APIs. Both are based on an opaque key APIs concept.
Figure 10 shows an example of API usage difference for AES encryption.

Figure 10. PSA API migration example

/* Configure session to encrypt message with settings included into the mechanism */
rv = C_EncryptInit(hSession, &mechanism, hKey);
…
/* Encrypt clear message */
rv = C_EncryptUpdate(hSession, &data[0], firstPieceLen, &encryptedData[0],
&ulEncryptedData1Len); PKCS#11 API
…
/* Finalize message encryption */
rv = C_EncryptFinal(hSession, &encryptedData[output_length], &ulEncryptedData3Len);
…

Opaque key ID

/* Setup the encryption object */

rv = psa_cipher_encrypt_setup(&handle, key_handle, alg);
…
/* Set the IV */
rv = psa_cipher_set_iv(&handle, iv, iv_length);
…
/* Encrypt one chunk of information */
PSA API rv = psa_cipher_update(&handle, plain_text, BYTE_SIZE_CHUNK, encrypted_data,
ENC_DEC_BUFFER_SIZE, &output_length);
…
/* Finalise the cipher operation */
rv = psa_cipher_finish(&handle, &encrypted_data[output_length],
ENC_DEC_BUFFER_SIZE - output_length, &output_length);
…

For more information on PSA APIs, refer to TFM user application example and [PSA_API].

AN5447 - Rev 3 page 14/22

 AN5447
OEM secure services integration

7.2 OEM secure services integration

As shown in Figure 11, the OEM secure services must be integrated as third-party secure services in the secure/
unprivileged part of the secure application (referred to as “Application RoT from TFM framework”). For more
information on “Application RoT from TFM framework”, refer to the TFM user manual of the concerned Arm®
TrustZone® STM32Cube MCU Package (see Section 2 References).

Figure 11. 3rd party secure services in TF-M

Non-secure Secure

(such as Crypto, NONCE, RNG)

Internal trusted storage
Apps

Initial attestation

Platform drivers
Secure storage

Cryptography
3rd party
PSA API

Network Middleware

OS
TF-M Core (IPC, SPM, interrupt handling) MCU boot

TBSA-M Hardware (SoC)

Application updatable RoT PSA updatable RoT PSA immutable RoT TF-M Isolation boundary

AN5447 - Rev 3 page 15/22

 AN5447
OEM secure services integration

These services must be integrated in the Middlewares/trustedfirmware folder as shown in Figure 12. For
more information, refer to [TF‑M].

Figure 12. OEM secure services integration (TFM)

Location to integrate
OEM secure services

AN5447 - Rev 3 page 16/22

 AN5447
Data personalization

7.3 Data personalization

In addition to the firmware image authentication keys, additional data requires personalization for the TFM
application: EAT key, HUK, and Instance ID. These data are required for TF‑M initial attestation service. They
are product-specific (unique per device). These data, together with the asymmetric keys for images signature and
AES CTR key decryption (refer to Section 6.3 Keys personalization), are grouped in the dedicated immutable
Flash region (personalization data area), which must be personalized for each device in production, before
activating the final security configuration.

Figure 13. Personalization data region

Local loader

Non-secure image secondary slot

area 3

Secure image secondary slot

area 2

Non-secure image primary slot

area 1

Secure image primary slot

area 0

ITS area

SST area

NV COUNTER
HDP activation code Public RSA or ECDSA asymmetric key for secure image signature
Public RSA or ECDSA asymmetric key for non-secure image signature
TFM_SBSFU_Boot Private RSA or ECDSA asymmetric key for AES-CTR key decryption
EAT key*
HUK*
Integrator perso data Instance ID*

BL2 NVCNT (*) Unique per device.

STM32CubeL5 TFM

For more details on personalization data, refer to section Integrator role description in the TFM user manual of the
concerned Arm® TrustZone® STM32Cube MCU Package (see Section 2 References).

AN5447 - Rev 3 page 17/22

 AN5447

Revision history

Table 6. Document revision history

Date Revision Changes

20-Feb-2020 1 Initial release.

Updated the entire document for STM32CubeL5 firmware V1.3.0 release.
New features in SBSFU_Boot: image encryption, external Flash memory
24-Jul-2020 2 support with OTFDEC, configurable crypto schemes, configurable image
number mode, configurable slot mode, and RSA hardware accelerator. Local
loader introduced.

Made the document generic to cover all applicable Arm® TrustZone® STM32
microcontrollers and the related STM32Cube MCU Packages, keeping the
STM32CubeL5 MCU Package as an example:
• Updated the document title
16-Aug-2021 3
• Added Table 1. Applicable products and updated Table 3. Document
references
• Updated Section 4.2 Top-level features and Section 6.3 Keys
personalization

AN5447 - Rev 3 page 18/22

 AN5447
Contents

Contents
1 General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

3 Arm® Trusted Firmware‑M (TF‑M) introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4 X-CUBE-SBSFU vs. TF‑M comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Top-level features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Hardware security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5 TF‑M-based applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6 SBSFU application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
6.1 User application integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2 OEM secure services integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3 Keys personalization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7 TFM application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

7.1 Cryptographic secure services at run-time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2 OEM secure services integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.3 Data personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
List of figures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

AN5447 - Rev 3 page 19/22

 AN5447
List of tables

List of tables
Table 1. Applicable products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table 2. List of acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Table 3. Document references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Table 4. Open-source software resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Table 5. X-CUBE-SBSFU vs. TF‑M top-level features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Table 6. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

AN5447 - Rev 3 page 20/22

 AN5447
List of figures

List of figures
Figure 1. TF‑M overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Figure 2. X-CUBE-SBSFU vs. TF‑M overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Figure 3. X-CUBE-SBSFU (STM32L4 Series) and TF‑M (STM32L5 Series) security strategy overview . . . . . . . . . . . . . . 7
Figure 4. STM32CubeL5 applications based on TF‑M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 5. Memory footprint example of STM32CubeL5 applications based on TF‑M . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 6. User application integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 7. OEM secure services integration (SBSFU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 8. Firmware image keys personalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 9. Integrator personalized data area in STM32CubeL5 SBSFU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 10. PSA API migration example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 11. 3rd party secure services in TF-M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 12. OEM secure services integration (TFM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 13. Personalization data region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

AN5447 - Rev 3 page 21/22

 AN5447

IMPORTANT NOTICE – PLEASE 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 acknowledgement.
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, please 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.
© 2021 STMicroelectronics – All rights reserved

AN5447 - Rev 3 page 22/22