AN5156

Application note

Introduction to STM32 microcontrollers security

Introduction
This application note presents the basics of security in STM32 microcontrollers.
Security in microcontrollers encompasses several aspects including protection of firmware intellectual property, protection of
private data in the device, and guarantee of a service execution.
The context of IoT has made security even more important. The huge number of connected devices makes them an attractive
target for attackers and several remote attacks have shown the vulnerabilities of device communication channels. With IoT,
the security extends the requirements for confidentiality and authentication to communication channels, which often require
encryption.
This document is intended to help the building of a secure system by applying countermeasures to different types of attack.
In the first part, after a quick overview of different types of threats, examples of typical attacks are presented to show how
attackers exploit the different vulnerabilities in an embedded system.
The subsequent sections focus on the set of hardware and software protections that defend the system from these attacks.
The last sections list all security features available in the STM32 Series, and guidelines are given to build a secure system.

Table 1. Applicable products

Type Product Series

STM32F0 Series, STM32F1 Series, STM32F2 Series, STM32F3 Series, STM32F4 Series, STM32F7 Series,
Microcontrollers STM32G0 Series, STM32G4 Series, STM32H7 Series, STM32L0 Series, STM32L1 Series, STM32L4 Series,
STM32L4+ Series, STM32L5 Series, STM32U5 Series, STM32WB Series, STM32WL Series

AN5156 - Rev 6 - July 2021 www.st.com

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

1 General information
The table below presents a non-exhaustive list of the acronyms used in this document and their definitions.

Table 2. Glossary

Term Definition

AES Advanced encryption standard

CCM Core-coupled memory (SRAM)
CPU Central processing unit – core of the microcontroller
CSS Clock security system
DoS Denial of service (attack)
DPA Differential power analysis
ECC Error code correction
FIA Fault injection attack
FIB Focused ion beam

GTZC Global TrustZone® controller

HDP Secure hide protection
HUK Hardware unique key
IAP In-application-programming
IAT Initial attestation token
IoT Internet of things
IV Initialization vector (cryptographic algorithms)
IWDG Independent watchdog
MAC Message authentication code

MCU Microcontroller unit (STM32 Arm® Cortex®-M based devices)

MPCBB Memory protection block-based controller
MPCWM Memory protection watermark-based controller
MPU Memory protection unit
NSC Non-secure callable
NVM Non-volatile memory
OTFDEC On-the-fly decryption
OTP One-time programmable
PCROP Proprietary code readout protection
PKA Public key algorithm (also named aka asymmetric algorithm)
PSA Platform security architecture
PVD Programmable voltage detector
PWR Power control
ROM Read only memory – system Flash memory in STM32
RoT Root of trust
RDP Read protection
RSS Root secure services
RTC Real-time clock

AN5156 - Rev 6 page 2/55

 AN5156
General information

Term Definition

SAU Security attribution unit

SB Secure boot
SCA Side channel attack
SDRAM Synchronous dynamic random access memory
SFU Secure firmware update
SPA Simple power analysis
SPE Secure processing environment
SRAM Static random access memory (volatile)
SST Secure storage
SWD Serial-wire debug
TF-M Trusted Firmware-M
WRP Write protection

Documentation references
The reference manual of each device gives details on availability of security features and on memory protections
implementation.
A programming manual is also available for each Arm® Cortex® version and can be used for MPU (memory
protection unit) description:
• STM32 Cortex®-M33 MCUs programming manual (PM0264)
• STM32F7 Series and STM32H7 Series Cortex®-M7 processor programming manual (PM0253)
• STM32 Cortex®-M4 MCUs and MPUs programming manual (PM0214)
• STM32F10xxx/20xxx/21xxx/L1xxxx Cortex®-M3 programming manual (PM0056)
• Cortex®-M0+ programming manual for STM32L0, STM32G0, STM32WL and STM32WB Series (PM0223)
Refer to the following set of user manuals and application notes (available on www.st.com) for detailed
description of security features:
• user manual STM32 crypto library (UM1924): describes the API of the STM32 crypto library; provided with
the X‑CUBE‑CRYPTOLIB Expansion Package.
• user manual Getting started with the X-CUBE-SBSFU STM32Cube Expansion Package (UM2262): presents
the SB (secure boot) and SFU (secure firmware update) ST solutions; provided with the X‑CUBE‑SBSFU
Expansion Package.
• application notes Proprietary Code Read Out Protection on STM32xx microcontrollers (AN4246, AN4701,
AN4758, AN4968): explain how to set up and work with PCROP firmware for the respective STM32L1, F4,
L4 and F7 Series; provided with the X‑CUBE‑PCROP Expansion Package.
• application note Managing memory protection unit (MPU) in STM32 MCUs (AN4838): describes how to
manage the MPU in the STM32 products.
• application note STM32WB ST firmware upgrade services (AN5185)
Note: Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

AN5156 - Rev 6 page 3/55

 AN5156
Overview

2 Overview

2.1 Security purpose

Why protection is needed
Security in microcontrollers means protecting embedded firmware, data and the system functionality. The need for
data protection is the most important in case of cryptographic keys or personal data.
The firmware code is also an important asset. If an attacker gains access to the binary, he can reverse-engineer
the program in an attempt to find further vulnerabilities, bypass licensing and software restrictions. The attacker
can copy any custom algorithms or even use it to flash a clone of the hardware. Even in case of an open source
software, it makes sense to attest that the code is authentic and not replaced by malicious firmware..
Denial-of-service attack (DoS attack) is another major threat when considering protection systems (such as
environment: gas, fire or intrusion), detection alarms or surveillance cameras. The system functionality must be
robust and reliable.
The requirement for security must not be underestimated even if it adds more complexity to the system. Today,
the systems built around microcontrollers become potential targets for more and more skilled attackers, that
expect financial gains. These gains can be very high, especially if the attack can be propagated to a large scale
like in the context of the IoT. Even if no system is completely secure, it is possible to make the attack more
expensive.
Indeed the IoT, or smart devices, have raised the requirement for security. Connected devices are very attractive
for hackers because they are remotely accessible. The connectivity offers an angle of attack through protocol
vulnerabilities. In case of a successful attack, a single compromised device can jeopardize the integrity of an
entire network (see the figure below).

Figure 1. Corrupted connected device threat

Services provider

Device

Unsecure Device
Device

Device
Corrupted system Attack propagation

AN5156 - Rev 6 page 4/55

 AN5156
Security purpose

What should be protected

Security cannot be limited to a certain target or asset. It is difficult to protect data if the code binary is exposed
and both the attacks and the protection mechanisms often do not make difference. However it is still useful to
summarize the assets and risks.
The table below presents a non-exhaustive list of assets targeted by attackers.

Table 3. Assets to be protected

Target Assets Risks

Sensor data (such as healthcare data or log of positions) Unauthorized sale of personal data
User data (such as ID, PIN, password or accounts) Usurpation
Data
Transactions logs Spying
Cryptographic keys Blackmail
Denial of service
Control of device (bootloader, Device correct functionality
Attacks on service providers
malicious application) Device/user identity
Fraudulent access to service (cloud)
Device counterfeit
Device hardware architecture/design
Software counterfeit
User code Software patent/architecture
Software modification
Technology patents
Access to secure areas

Vulnerability, threat and attack

Protection mechanisms have to deal with different threats. The objective is to remove vulnerabilities that could be
exploited in an attack. An overview of main attack types are presented in Section 3 Attack types, from the basic
ones to the most advanced ones.
The following specific wording is used around security:
• Asset: what needs to be protected
• Threat: what the device/user need to be protected against
• Vulnerability: weakness or gap in a protection mechanism
In summary, an attack is the realization of a threat that exploits a system vulnerability in order to access an asset.

AN5156 - Rev 6 page 5/55

 AN5156
Attack types

3 Attack types
This section presents the different types of attack that a microcontroller may have to face, from the most basic
ones to very sophisticated and expensive ones. The last part presents typical examples of attacks targeting an
IoT system.
Attacks on microcontroller are classified in one of the following types:
• Software attack: exploits software vulnerabilities (such as bug or protocol weaknesses).
• Hardware non-invasive attack: focuses on MCU interfaces and environment information.
• Hardware invasive attack: destructive attack with direct access to silicon

3.1 Introduction to attack types

A key rule in security is that a successful attack is always possible.
First, there is no absolute protection against unexpected attack. Whatever the security measures taken to
protect a system, it is possible that a security breach is found and exploited during the device lifetime. This
last point makes necessary to consider how the device firmware is updated to increase its security (see
Section 5.2.2 Secure firmware update (SFU)).
Secondly, in laboratory conditions with proper equipment, it is possible to retrieve microcontroller content or even
design architecture details. These techniques are briefly presented in Section 3.3 Hardware attacks.
From an attacker point of view, an attack is profitable if the ratio expected revenue/attack cost is as high as
possible. The revenue depends on the stolen asset value and on the repeatability of the attack. The cost depends
on time, on the acquisition of the necessary skills of the attacker and on money (equipment) spent to succeed.
Attack types
While there are more detailed groups and categories of attack, the basic categories are the following ones:
• Software attacks are carried by exploiting bugs, protocol weaknesses or untrusted pieces of code among
others. Attacks on communication channels (interception or usurpation) are part of this category. The
software attacks represent the vast majority of cases. Their cost may be very low. They can be widely
spread and repeated with huge damage. It is not necessary to have a physical access to the device, the
attack can be executed remotely.
• Hardware attacks need physical access to the device. The most obvious one exploits the debug port, if it
is not protected. But in general, hardware attacks are sophisticated and can be very expensive. They are
carried out with specific materials and require electronics engineering skills. A distinction is made between
non-invasive attacks, carried out at board level or chip level without device destruction, and invasive attacks,
carried out at device silicon level with package destruction. In most cases, such an attack is only profitable if
it reveals information that leads to new and widely applicable remote attack.

AN5156 - Rev 6 page 6/55

 AN5156
Software attacks

The table below gives an overview of the cost and techniques used for each types of attack.

Table 4. Attacks types and costs

Attacks
Software Hardware non–invasive Hardware invasive
types

Scope Remote or local Local board and device level Local device level
Software bugs Debug port Probing
Protocol weaknesses Power Glitches Laser
Techniques
Trojan horse Fault injection FIB
Eavesdropping Side-channels analysis Reverse engineering
From very low to high, Quite low cost. Need only moderately
Cost/ Very expensive. Need dedicated
depending on the security sophisticated equipment and knowledge to
expertise equipment and very specific skills.
failure targeted implement.
Access to confidential assets Reverse engineering of the device
(code and data). (silicon intellectual property)
Access to secret data or device internal
Objectives
Usurpation behavior (algorithm). Access to hidden hardware and
Denial of service software secrets (Flash access )

3.2 Software attacks

Software attacks are carried out on the system by executing a piece of code, named a malware, by the CPU. The
malware is intended to take control of the device in order to get access to any resources of the system (such as
ID, RAM and Flash memory content or peripheral registers) or to modify its functionality.
This type of attack represents most of device threats for the following reasons:
• The attack cost is low since it does not need specific equipment but a personal computer.
• Many hackers can put their effort together, sharing their expertise and tricks, so that a successful attack is
likely to happen if a security breach exists. Furthermore, in case of success, the attack protocol may spread
very quickly through the web
The malware can be injected into the device or can already be present (insider threat) in main application
firmware through a non-verified or untrustworthy library for example.
Malwares are of many types and they can be very small and easy to hide.
Here are examples of what a malware can do:
• Modify device configuration (such as option bytes or memory attributes).
• Disable protections.
• Read memory and dump its content for firmware and data cloning.
• Trace or log device data.
• Access to cryptographic items.
• Open communication channel/interface.
• Modify or block the device functionality.
Unless user application is fully trusted, bug-free and isolated, without any means to communicate with external
world, software attacks must be considered.

AN5156 - Rev 6 page 7/55

 AN5156
Software attacks

Malware injection
There are various methods to inject a piece of code inside the system. The size of the malware depends on the
target but may be very small (few tens of bytes). To be executed, the malware must be injected in the device
memory (RAM or Flash memory). Once injected, the challenge is to have it executed by the CPU, which means
that the PC (program counter) must branch to it.
Methods of injecting malware can be categorized as follows:
• Basics device access/"open doors”:
– Debug port: JTAG or SWD interface
– Bootloader: if accessible, can be used to read/write memory content through any available interface.
– Execution from external memory
These malware injections are easy to counter with simple hardware mechanisms that are described in
Section 4 Device protections .
• Application download:
– Firmware update procedure: a malware can be transferred instead of a new FW.
– OS with capability to download new applications.
This category countermeasure is based on authentication between the device and the server or directly with
code authentication. Authentication relies on cryptography algorithms.
• Weaknesses of communication ports and bugs exploitation:
– Execution of data. Sometimes it is possible to sneak the malware in as data and exploit incorrect
boundary check to execute it.
– Stack-based buffer overflows, heap-based buffer overflows, jump-to-libc attacks and data-only attacks
This third category is by definition difficult to avoid. Most embedded system applications are coded using
low-level languages such as C/C++. These languages are considered unsafe because they can lead to
memory management errors leveraged by attackers (such as stack, heap or buffers overflow). The general
idea is to reduce as much as possible what is called the attack surface, by minimizing the untrusted or
unverified part of firmware. One solution consists in isolating the execution and the resources of the different
processes. For example, the TF-M includes such a mechanism.
• Use of untrusted libraries with device back door
This last category is an intentional malware introduction that facilitates device corruption. Today, lot of
firmware developments rely on software shared on the web and complex ones can hide Trojan horses. As
in previous category, the way to countermeasure this threat is to reduce the surface attack by isolating as
much as possible the process execution and protecting the critical code and data.

Brute forcing
This type of attack targets the authentication based on a shared secret. A secure device may require a session
authentication before accessing services (in the cloud for example) and a human-machine interface (HMI) can be
exploited with an automatic process in order to try successive passwords exhaustively.
Interesting countermeasures are listed below:
• Limit the number of login trials with a monotonic counter (implemented with a timer, or if possible, with a
backup domain).
• Increase the delay between consecutive login attempts.
• Add a challenge-response mechanism to break automatic trials.

AN5156 - Rev 6 page 8/55

 AN5156
Hardware attacks

3.3 Hardware attacks

Hardware attacks require a physical access to the device or, often, to several devices in parallel.
A distinction is made between two types of attacks, that differ in cost, time and necessary expertise:
• Non-invasive attacks have only external access to the device (board-level attack) and are moderately
expensive (thousands to tens of thousands US dollars in equipment).
• Invasive attacks have direct access to device silicon (after de-packing). They are carried out with advanced
equipment often found in specialized laboratories. They are very expensive (more than 100k dollars, and
often in the range of millions) and target very valuable data (Keys or IDs) or even technological patents.
General-purpose microcontrollers are not the best candidates to counter the most advanced physical attacks. If
highest protection level is required, it is advised to consider pairing a secure element with the general-purpose
microcontroller. Secure elements are dedicated microcontrollers certified as per the latest security standards with
specific hardware.
Refer to ST secure microcontrollers web page (www.st.com/en/secure-mcus.html).

3.3.1 Non-invasive attacks

Non-invasive, or board-level attacks try to bypass the protection without physical damage (device kept functional).
Only accessible interfaces and device environment are used. These attacks require moderately sophisticated
equipment and engineering skills (such as signal processing).

Debug port access

This is the most basic attack that can be carried out on a device. Disabling debug capability must be the first
protection level to consider. Indeed, accessing to debug port or scan chain through JTAG or SWD protocol allows
accessing the full internal resources of the device: CPU registers, embedded Flash memory, RAM and peripheral
registers.
Countermeasure:
• Debug port deactivation or fuse through Readout protection (RDP)

Serial ports access

Access to communication ports (such as I2C or SPI) may hide a weakness that can be exploited. Communication
ports can be spied or used as a device entry point. Depending on how the associated protocol are implemented
(such as memory address access range, targeted peripherals or read/write operations), an attacker can
potentially gain access to the device resources.
Countermeasures:
• Software:
– Associated protocol operations must be limited by the firmware level, so that no sensitive resources
can be read or written.
– Isolate communication stack from sensitive data.
– Length of data transfer must be checked to avoid buffer overflows.
– Communication can be encrypted with a shared key between the device and the target.
• Hardware:
– Physical communication port can be buried in multi-layer boards to make it more difficult to access.
– Unused interface port must be deactivated.

AN5156 - Rev 6 page 9/55

 AN5156
Hardware attacks

Fault injection: clock and power disturbance/glitch attacks

Fault injection consists in using the device outside the parameters defined in the datasheet to generate
malfunctions in the system. A successful attack can modify the program behavior in different ways such as
corrupting program state, corrupting memory content, stopping process execution (“stuck-at fault”), skipping
instruction, modifying conditional jump or providing unauthorized access.
The typical threats involve tampering with clock (freezing or glitch) and power (under/over voltage or glitch).
Since fault may be non‑intentional, countermeasures are the same as the one used for safety: redundancy, error
detection and monitoring.
Countermeasures:
• Software:
– Check function return values.
– Use strict comparisons when branching.
– Make sure that no code was skipped in critical parts by incrementing a dedicated variable in each
branch with prime number and check for the expected value.
– Use non-trivial values as true and false (avoid comparing to 0 or -1, try complex values with high
mutual Hamming distance).
• Hardware:
– Use Clock security system (CSS) if available.
– Use internal clock sources.
– Use internal voltage regulators.
– Use memory error detection (ECC and parity).

Side-channel attacks (SCA)

When a firmware is executed, an attacker can observe the device running characteristics (such as power
consumption, electromagnetic radiations, temperature or activity time). This observation can bring enough
information to retrieve secret assets such as data values and/or algorithms implementation. Side-channel based
attacks are powerful against cryptographic devices in order to reveal the keys used by the system. SPA (simple
power analysis) and DPA (differential power analysis) are typical example of side-channel attack exploiting power
consumption.
Countermeasures:
• Software:
– Limit key usage: use session random keys when possible.
– Use protected cryptographic libraries with behavioral randomization (such as delays or fake
instructions).
• Hardware:
– Shields against monitoring can be found in secure elements (STSAFE), but there is usually no
efficient hardware countermeasure embedded in general-purpose microcontrollers (except for the
SAES example in the STM32U5 Series).

3.3.2 Silicon invasive attacks

The cost of such attacks is very high; all means are considered to extract information of the device that is
destroyed during the process. The attacker needs to obtain a substantial quantity of devices to be successful.
Carried out with expensive equipments often found in specialized laboratories, they require a high level of skills
and knowledge, as well as time.
Invasive attacks start with the removal of the device package. An initial analysis can be done without eliminating
the passivation layer, however investigations with device interaction (probing) require its removal. De-packing can
be done by chemical etching, drilling or by a laser cutter. Once the device is opened, it is possible to perform
probing or modification attacks.
Several ST microcontrollers dedicated to security offer robustness against such kind of treatments. These are
not part of the STM32 family and are out of scope of this document. Refer to ST secure hardware platforms
(www.st.com/en/secure-mcus.html).

AN5156 - Rev 6 page 10/55

 AN5156
IoT system attack examples

Reverse engineering
The goal is to understand the inner structure of the device and analyze its functionality. This is quite a challenging
task with modern devices featuring millions of gates.
The first step is to create a map of the microcontroller. It can be done by using an optical microscope to produce a
high-resolution photograph of the device surface. Deeper layers can then be analyzed in a second step, after the
metal layers have been stripped off by etching the device.
Reading the data
Using the electron microscope, the data, represented by an electric charge, becomes visible. It is possible to read
the whole device memory.
Micro probing and internal fault injection
Micro probing consists in interacting with the device at metal layer level. Thin electrodes are used to establish an
electrical contact directly with the surface of the device so that the attacker can observe, manipulate, and interfere
with it while the device is running.
Device modification
More sophisticated tools can be used to perform attacks. FIB (focused ion beam) workstations, for example,
simplify the manual probing of deep metal and polysilicon lines. They also can be used to modify the device
structure by cutting existing or creating new interconnection lines and even new transistors.

3.4 IoT system attack examples

This section presents typical examples of attacks on an IoT system. Fortunately, most of these attacks can be
countered by enabling security feature (hardware countermeasures) and secure application architecture (software
countermeasures). The countermeasures are detailed in the next sections.
An IoT system is built around a STM32 microcontroller with connectivity systems (such as Ethernet, Wi-Fi®,
Bluetooth® Low Energy or LoRa®) and sensors and/or actuators (see the figure below). The microcontroller
handles the application, data acquisition and communications with a cloud service. The microcontroller may also
be responsible for the system maintenance through firmware update and integrity check.

Figure 2. IoT system

Connectivity

STM32
Sensors Actuators

AN5156 - Rev 6 page 11/55

 AN5156
List of attack targets

3.5 List of attack targets

The following sections list the possible attack targets:

Initial provisioning
The cryptographic data for root of trust for the chain of security must be injected to the SoC in a controlled
trusted way. Whether it is a key, a certificate or a hash initial value, it must remain immutable and/or secret. Once
programmed inside the device, the data protection mechanism must be enabled and only authorized process
must have access to it.
• Risks: firmware corruption or usurpation
• Countermeasures:
– Trusted manufacturer environment
– Use of secure data provisioning services (SFI)
– Data protection mechanisms
– Secure application isolation
– Use of OTP memory

Boot modification
The purpose of this attack is to use the bootloader to access to device content. The attack aims at modifying the
boot mode and/or the boot address to preempt the user application and to take control of the CPU through the
bootloader (via USB DFU, I2C or SPI), the debug port or through a firmware injected in RAM. The boot mode and
the address are controlled by device configuration and/or input pin and must be protected.
• Risks: full access of the microcontroller content
• Countermeasures:
– Unique boot entry
– Bootloader and debug disabled (see Readout protection (RDP))

Secure boot (SB) or Trusted Firmware-M (TF-M)

Robust systems rely on initial firmware integrity and authenticity check before starting the main application. As the
root of trust of a device, this part of user firmware must be immutable and impossible to bypass.
A successful attack consists in executing a non-trusted application by bypassing the verification and by jumping
directly to the malware. It can be done by hardware techniques such as fault-injection. It can also be done by
replacing the expected hash value by the hash value of the malware (refer to the Initial provisioning section at the
beginning of this chapter).
• Risks: device spoofing or application modification
• Countermeasures:
– Unique boot entry point to avoid verification bypass
– "Immutable code" to avoid SB code modification
– Secure storage of firmware signature and/or tag value
– Environment event detection (such as power supply glitch, temperature or clock speed)

Firmware update
The firmware update procedure allows a product owner to propose corrected version of the firmware to ensure
the best user experience during device lifetime. However, a firmware update gives an attacker an opportunity to
enter the device with its own firmware or a corrupted version of the existing firmware.
The process must be secured with firmware authentication and integrity verification. A successful attack requires
an access to the cryptographic procedure and keys (refer to the Initial provisioning section at the beginning of this
chapter).
• Risk: device firmware corruption
• Countermeasure: SFU application with authentication and integrity checks. Confidentiality can also be added
by encrypting the firmware in addition to signature.

AN5156 - Rev 6 page 12/55

 AN5156
List of attack targets

Communication interfaces
Serial interfaces (such as SPI, I2C or USART) are used either by the bootloader or by applications to exchange
data and/or commands with the device. The interception of a communication allows an attacker to use the
interface as a device entry point. The firmware protocol can also be prone for bugs (like overflow).
• Risk: Access to device content
• Countermeasures:
– Make physical bus hard to reach on board.
– Isolate software communication stacks to prevent them from accessing critical data and operations.
– Use cryptography for data exchange.
– Disable I/F ports when not needed.
– Check inputs carefully

Debug port
The debug port provides access to the full content of the device: core and peripherals registers, Flash memory
and SRAM content. Used for application development, it may be tempting to keep it alive for investigating future
bugs. This is the first breach tried by an attacker with physical access to the device.
• Risk: full access to the device
• Countermeasure: Disable device debug capabilities (see Readout protection (RDP) feature).

External peripheral access

An IoT device controls sensors and actuators depending on the global application. An attacker can divert the
system by modifying data coming from sensors or by shunting output data going to actuators.
• Risk: incorrect system behavior.
• Countermeasure: anti-tamper to detect system intrusion at board level

Sensitive firmware and data

Some parts of the firmware need special protection: for example the cryptographic algorithm or a third-party
library. In addition, selected data may need enhanced protection if they are considered as valuable assets
(cryptographic keys).
The internal memory content must be protected against external accesses (such as communication interfaces)
and internal accesses (other software processes). The memory attributes and the firewall are the main protections
for process and data isolation.
• Risks: sensitive firmware copy or data theft
• Countermeasures:
– Execute-only access right (XO).
– Firewall
– Memory protection unit
– Secure area
– Encryption of external memory

AN5156 - Rev 6 page 13/55

 AN5156
List of attack targets

SRAM
The SRAM is the device running memory. It embeds runtime buffers and variables (such as stack or heap) and
can embed firmware and keys. While in the non-volatile memory, the secrets may be stored as encrypted, when
loaded to the SRAM, they need to be present in plain view to be used. In the same time, the SRAM usually holds
communication buffers. For these two reasons, an attacker may be tempted to focus his effort on the SRAM.
At least three types of attack can be raised against this memory: code (malware) injection, memory corruption
through buffer overflow and retrieval of secrets through temporary stored variables.
• Risks: buffer overflow, data theft or device control
• Countermeasures:
– Firewall
– Memory protection unit
– Secure area

Random number generation

Random numbers are often used in cryptography for session key, cryptographic nonce or initialization vector (IV)
generation. Weak random generator may make any secure protocol vulnerable.
A software attack tries to exploit an hidden periodicity or structures of a random sequence to guess the secret
key and break into communication confidentiality. An hardware attack attempts to disable the RNG, or weaken the
statistic randomness of the output.
A robust random generator depends on the quality of the entropy source (analog).
• Risk: reduced security of cryptographic protocols
• Countermeasure:
– use true hardware entropy generator
– use tests on the RNG output, verify statistic properties of produced random numbers.

Communication stack
Connectivity protocols (such as Bluetooth, Ethernet, Wi-Fi or LoRa) have complex communication firmware
stacks. These stacks, often available in open source, must not always be considered as trusted. A potential
weakness can be massively exploited.
• Risk: device access (content, control) through network
• Countermeasures:
– Communication process isolation
– Server authentication
– Secure firmware update to patch bugs

Communication eavesdrop
Data exchanges between a device and an IoT service can be eavesdropped, either directly by a compatible RF
device or through the network. An hacker may seek for retrieving data, getting device IDs or accessing services.
Cryptography can be adopted by all communication protocols. Several encryption steps are often considered to
protect the communication between all the different layers (device, gateway, applications).
• Risk: observation and spoofing of network traffic.
• Countermeasure: use cryptography version of communication stack (like TLS for Ethernet)

AN5156 - Rev 6 page 14/55

 AN5156
Device protections

4 Device protections
Security protections described in this section are controlled by hardware mechanisms. They are set either by
configuring the device through option bytes, or dynamically by hardware component settings:
• Memory protection: main security feature as it is used to protect code and data from internal (software) and
external attacks
• Software isolation: inter-processes protection to avoid internal attacks
• Interface protection: allows to protect device entry points like serial or debug ports
• System monitoring: detects device external tampering attempts or abnormal behaviors

4.1 TrustZone® for Armv8-M architecture

Microcontrollers based on Armv6 or Armv7 architecture (Cortex-M0, M3, M4 and M7) rely mostly on software
implementations for firmware and resources isolation. These mechanisms, described later in the document,
are robust but not that flexible to allow the concurrent execution of secure firmware together with non-secure
firmware.
The Armv8-M architecture brings a new security paradigm in Arm microcontrollers. It implements the TrustZone
technology at microcontroller system level, allowing the development of trusted firmware through a robust
isolation at runtime.
The TrustZone technology relies on a processor (Cortex-M23 or Cortex-M33) with dual registers banks for secure
and non-secure domains and on a bus infrastructure (AHB5) propagating secure attribute throughout the whole
system (peripherals and memories).
The TrustZone is made for robust and flexible security control at runtime. Switching from secure to non-secure
domain and vice-versa is straightforward with few cycle penalty. No need for an hypervisor as in TrustZone for
application processors Cortex‑A.
Secure modes are orthogonal to the existing modes, Thread and Handler. Thus, there can be a Thread or
Handler mode in each secure mode (see the figure below).

Figure 3. Armv8-M TrustZone execution modes

Arm TrustZone system security

Armv8-M
Armv6-M/Armv7-M
Secure Non-secure

Handler mode Handler mode Handler mode

Thread mode Thread mode Thread mode

On typical firmware architecture running on Armv8 TrustZone, the non-secure domain executes the application
and the OS tasks, while the secure domain executes the secure application and the system root-of-trust
mechanisms.

4.2 Dual-core security

In dual-core products, one core can act as secure while the other is non-secure. Some products, such as dual-
core STM32WL devices in particular, feature a hardware support to propagate the secure attribute to memory and
peripherals, ensuring that robust run-time isolation implementation is possible.
A dedicated security controller is added to the dual-core STM32WL devices to facilitate the isolation.
Instead of using attribution units, the secure NV memory dedicated to securable CPU2 is defined in the Flash
memory interface configuration. Key peripherals such as DMA must convey the secure context (refer to UM2643
Getting started with STM32CubeWL for STM32WL Series, for details about usage of this hybrid architecture).

AN5156 - Rev 6 page 15/55

 AN5156
Memory protections

Figure 4. Simplified diagram of dual-core system architecture

CPU1 CPU2
non-secure secure DMA
MPU MPU

AHB

Security
Flash interface AHB/APB bridge
controller

SRAM
Bus masters Slaves

4.3 Memory protections

Memory protections are of the highest importance when considering systems security. Storage containing
sensitive code and data must not be accessible from any unexpected interface (debugging port) or an
unauthorized process (internal threat).
Depending on the asset to be protected (code or data), various mechanisms can be set to establish protections
at the source of the unauthorized access (external port, internal process) or on the memory type to be protected
(Flash, SRAM or external memory).
Part of the access filtering can be performed by the memory interfaces (like Flash controller), the bus controller
IP (firewall) or through the core MPU if it is available. Details on proprietary protections (secure hide protection,
PCROP, WRP, RDP) can be found in Section 6 STM32 security features.
Embedded Flash memory, embedded SRAM and external memories are designed for different purposes. Their
respective protections mechanisms reflect these differences.

AN5156 - Rev 6 page 16/55

 AN5156
Memory protections

The figure below provides a simple view of memories access architecture in a microcontroller.

Figure 5. Memory types

System Flash System Flash

memory memory
Flash controller

Flash Flash
user memory user memory
Bus masters (such as CPU or DMA)

OTP

Bank 1 Bank 2

SRAM
STM32
microcontroller

NOR/NAND Flash
FMC

SDRAM
Octo- or Quad-SPI
OTFDEC

Octo- or
Quad-SPI Flash

AN5156 - Rev 6 page 17/55

 AN5156
Memory protections

The table below summarizes the particularities of each type of memories and typical protection features.

Table 5. Memory types and associated protection

Memory Types Description Protections

. Internal
System Flash ROM part of the Flash memory. Embeds Cannot be updated (erase/written).
. NVM
memory device bootloader and other ST services. A part may also be unreadable.
. ROM
. Internal Internal protections:
User Flash memory Flash memory for user application
. NVM • RDP
• WRP (not for SRAM)
• TrustZone
Working memory for Stack, heap or buffers. • PCROP (not for SRAM)
. Internal Can be used to execute the firmware
SRAM • OTP (not in SRAM)
. Volatile downloaded from internal or external non-
• Firewall
volatile memories.
• Secure hide protection (not for SRAM)
• MPU
Cryptography
NAND, NOR, Octo- . External
Additional memory for applications or data
or Quad-SPI Flash Write protection (on Flash device)
. NVM storage
memory
TrustZone
. External
SDRAM Additional RAM for application execution Cryptography
. Volatile

4.3.1 System Flash memory

In STM32 MCUs, the system memory is a read-only part (ROM) of the embedded Flash memory. It is dedicated
to the ST bootloader. Some devices may include additional secure services (RSS) in this area. This part cannot
be modified to guarantee its authenticity and integrity. The bootloader is readable since it does not contain any
sensitive algorithm. Some parts of the RSS are hidden and cannot be read by the user.
Protection attribute on the system Flash memory cannot be modified.

4.3.2 User Flash memory

This is the main user memory, used to store firmware and non-volatile data. It is part of the embedded Flash
memory and can be protected by a set of memory protection features available on all STM32 MCUs.
External attacks
The embedded Flash memory is easy to protect against external attacks, unlike external Flash memories.
Disabling the debugging port access with RDP and the controlled access of connectivity interface provide
sufficient isolation from outside.
Associated protection: RDP to disable debug access
Internal attacks
An internal read or write access to the memory can come from a malware injected either in the device SRAM or
inside an untrusted library, so that the critical code and data must only be accessible by authorized processes.
Associated protections: PCROP, MPU, firewall, secure hide protection or TrustZone
Protecting unused memory
Write protection must always be set by default on the Flash memory, even on unused area, to prevent either
code modification or injection. A good practice also is to fill unused memory with known values such as software
interrupt (SWI) op-codes, illegal op-codes, or NOPs.
Associated protections: MPU or WRP
Error code correction (ECC)
The Flash memory may feature ECC that allows error detection and correction (up to 2-bits error detection and
1-bit error correction). More considered as a safety feature, it also works as a complementary protection against
fault injection.

AN5156 - Rev 6 page 18/55

 AN5156
Memory protections

4.3.3 Embedded SRAM

The embedded SRAM is the device working memory. It is used for stack, heap, global buffers and variables at
runtime. The SRAM can be accessed as bytes, half-words (16 bits) or full words (32 bits), at maximum system
clock frequency without wait state.
Code execution
The part of the firmware that requires faster performances can be downloaded from the user or the external Flash
memory and executed from the SRAM. Another reason to execute code from SRAM is when using encrypted
external Flash memory on devices without on the fly decryption: the code is decrypted inside the SRAM before its
execution. Appropriate memory protections should then be enabled on the SRAM address range containing the
code. When no code must be executed in the SRAM, it is advised to prevent any malware execution by setting
the appropriate attribute (execute never) with the MPU.
Associated protections: MPU or firewall
SRAM cleaning
The SRAM may contain sensitive data or temporary values allowing some secrets retrieving. A typical example
is the transfer of a secret cryptographic key from protected Flash memory area in clear text, inside the SRAM. It
is highly recommended to clean explicitly the working buffers and variables immeditately after the processing of
functions manipulating sensitive data.
Note: In case of reset, the STM32 MCUs allow the automatic erase of the SRAM (refer to each device reference
manual). For some products, part of the SRAM is protected against external access or untrusted boot (SRAM
boot) when the RDP is set.
Write protection
The write protection can be used to isolate part of the area from being corrupted by another process or by
preventing an overflow attack. An overflow attack consists in writing more data than the targeted buffer size
(during a data transfer through interface ports for example). If no boundary checks are performed, the memory
address above the buffer is corrupted and a malware can be injected this way. This protection is only featured
by the SRAM regions which are used primarily for code execution (this protection is not practical for data). The
SRAM write protection is available for SRAM2 region on some STM32 series only (refer to Section 6.1 Security
features overview and to product's reference manual).
Associated protections: MPU, TrustZone or SRAM write protection (available on some STM32 series only)
Parity check and ECC
The parity check on the SRAM allows the control of potential errors word-by-word (32 bits). One extra bit per byte
is added to the memory content (data bus width is 36 bits) to increase its robustness, as required for instance
by Class B or SIL norms. ECC is more sophisticated, with SECDED functionality, but only available for SRAM on
certain MCU lines. They cannot be disabled and by default improve fault protection.

4.3.4 External Flash memories

The external Flash memories are connected to the microcontroller through dedicated interfaces (NAND, NOR,
Octo- or Quad-SPI). As the embedded Flash memory, the external ones contain code and data, but the external
storage raises the problem of confidentiality (content protection) and authentication (device protection). The
hardware protection is limited to a write lock, to avoid content erasing or modification. Further protection is
brought by cryptography algorithms. The content must be at least signed to avoid execution of unauthenticated
firmware. Encryption is required only if the content is confidential.
The embedded code can be either executed in-place or loaded into the SRAM before execution. Execution
in-place of encrypted firmware is possible only if the device has on-the-fly decryption capabilities. In the other
case, the firmware must be decrypted when loaded into SRAM. If the decrypted code or parts of it are not
protected from readout (RDP2), then the confidentiality of the code is violated. It is also recommended to combine
encryption with integrity protection.
Associated protection: OTFDEC

AN5156 - Rev 6 page 19/55

 AN5156
Software isolation

4.3.5 STM32 memory protections overview

Several STM32 features are available to cover the various cases considered. They are listed in the table below
with their respective scope and described in Section 6 STM32 security features.

Table 6. Scope of STM32 embedded memories protection features

External attack Internal attack

Feature Flash memory SRAM
protection protection

RDP Yes No Yes Yes

Firewall No Yes Yes Yes
MPU No Yes Yes Yes
PCROP Yes Yes (read/write) Yes No

WRP(1) Yes Yes Yes No

HDP Yes Yes Yes Yes (for execution)(2)

TrustZone Yes Yes Yes Yes

1. Write protection can be unset when RDP level ≠ 2.

2. The SRAM is protected by a secure area only at secure code execution. It must be cleaned before leaving the secure area.

4.4 Software isolation

The software isolation refers to a runtime mechanism protecting different processes from each other (inter-
process protection). These processes can be executed sequentially or concurrently (for example tasks of
operating system). The software isolation in SRAM ensures that respective stack and working data of each
process cannot be accessed by the other processes. This inter-process protection can be extended to the code in
the Flash memory and non-volatile data as well.
Goals of the software isolation:
• Prevent a process to spy the execution of another sensitive process.
• Protect a process execution against a stack corruption due to memory leaks or overflow (incorrect memory
management implementation).
This memory protection may be achieved through different mechanisms listed in the table below and detailed in
Section 6 STM32 security features .

Table 7. Software isolation mechanism

Protection Type Isolation

MPU Dynamic By privilege attribute (1)

Firewall Static By bus address hardware control

Secure hide protection Static Process preemption at reset

Dual core Static By core ID(2)

TrustZone Static and dynamic By secure attribute propagated from the core to all resources

1. The attribute protection is only for CPU access and is not taken into account for other bus master (such as DMA).
2. Reading the CPUID indicates which CPU is currently executing code. An example can be found in the
HAL_GetCurrentCPUID function.

4.5 Debug port and other interfaces protection

The debug ports provide access to the internal resources (core, memories and registers) and must be disabled in
the final product. It is the most basic external attack that is easily avoided by deactivating JTAG (or SWD) ports
by a secure and immutable firmware (refer to Section 5.2.1 Secure boot (SB) ), or preferably by permanently
disabling the functionality (JTAG fuse in RDP2).

AN5156 - Rev 6 page 20/55

 AN5156
Boot protection

Other serial interfaces can also be used. If the bootloader is available, the device content can be accessed
through I2C, SPI, USART or USB‑DFU. If the interface is open during the runtime, the application transfer
protocol must limit its access capabilities (such as operation mode or address access range).
Associated STM32 features:
• Read protection (RDP)
• Disable of unused ports.
• Forbid bootloader access (configured by RDP in STM32 devices).

4.6 Boot protection

The boot protection secures the very first software instructions in a system. If an attacker succeeds in modifying
the device boot address, he may be able to execute his own code, to bypass initial dynamic protections
configuration or to access unsecured bootloader applications that give access to the device memory.
A microcontroller usually allows the boot configuration in order to choose between starting at user application, at
bootloader application or at the SRAM located firmware. The boot protection relies on a single entry point to a
trusted code that can be the user application or a secure service area if available (RSS).
Associated STM32 features:
• Read protection (RDP)
• Unique boot entry
• Secure hide protection (HDP)
• TrustZone

4.7 System monitoring

The monitoring of the device power supply and environment can be set to avoid malfunction and to take
corresponding countermeasures. Some mechanisms, like tamper detection, are dedicated to security. Other
mechanisms are primarily used for safety reason but can serve security as well. For example, the detection
of a power down or external clock disconnection may be unintentional (safety) but may also reveal an attack
(security).
Tamper detection is used to detect system/board level intrusions. The opening of a consumer product enclosure
can be detected on an MCU pin and trigger appropriate actions. Internal tamper sensors are capable of detecting
irregular voltage, temperature, or other parameters.
Clock security system is used to protect against external oscillator failures. If a failure is detected on the
external clock, the microcontroller switches to the internal clock in order to safely execute. The interrupt signal
allows the firmware to react to the clock failure event.
Power supply and voltage level can be monitored to detect abnormally-low voltage level. Below a certain voltage
value, the normal behavior cannot be guaranteed and it may be the sign of a fault injection attack.
Device temperature can be measured with an internal sensor. The information is feedbacked to the device
through an internal ADC channel. A monitoring application can take appropriate actions according to the
temperature range. Increased temperature may be part of a fault injection attack scheme.
Associated STM32 features:
• Tamper protection (with RTC component)
• Clock security system
• Power supply supervision
• Temperature sensor

AN5156 - Rev 6 page 21/55

 AN5156
Secure applications

5 Secure applications
In order to create a secure system, the hardware features must be used in a secure firmware architecture
implementation. An industry standard solution is the PSA, proposed by Arm for the IoT ecosystem. The ST
proprietary solution is Secure boot (SB) and Secure firmware update (SFU).
This section defines the root and chain of trust concept before presenting the following typical secure
applications implementing the features listed below:
• Secure boot .
• Secure firmware update (SFU)
• Secure storage
• Cryptographic services
These applications have a close link with cryptography. All cryptographic schemes are based on the three
concepts of secret key, public key and hashing. Basics of cryptography are explained in Appendix A.
Cryptography - Main concepts.
Note: • The user manual Getting started with the X-CUBE-SBSFU STM32Cube Expansion Package (UM2262)
provides an implementation example of SB and SFU (www.st.com/en/product/x-cube-sbsfu).
• The user manual Getting started with STM32CubeL5 TF-M application (UM2671) describes an example of
TF-M implementation with the STM32L5 Series MCU.
• The user manual Getting started with STM32CubeU5 TF-M application (UM2851) describes an example of
TF-M implementation with the STM32U5 Series MCU.

5.1 Root and chain of trust

The principle of root and chain of trust is common to many, if not almost all, secure systems. It is obviously
scalable ad libitum, inherently efficient and also flexible.
A chain of trust is built as a set of applicative components in which the security of each component is guaranteed
by another component. The root of trust is the anchor at the beginning of the chain on which the overall security
depends.
The secure boot implementation must be the single entry point to the device, start after reset with immutable code
in secure mode. It then authenticates a subsequent functionality and executes the next part of the firmware that
enables the additional functionality required to securely attest the following chain link. For example, it configures
volatile memory protection so that a secure storage service may use it.

5.2 ST proprietary SBSFU solution

5.2.1 Secure boot (SB)

The SB application is executed at reset before the user application. It provides first stages of security and is then
responsible for ensuring the global chain of trust of the system.
SB main functionalities:
• Check the STM32 security configuration and set up runtime protections.
• Assert the integrity and authenticity of the user application images that are executed (see the figure below).

AN5156 - Rev 6 page 22/55

 AN5156
ST proprietary SBSFU solution

Figure 6. Secure boot FSM

Reset

Check device security configuration

(option bytes)

X
Set security peripheral configuration
Secure boot
(MPU, firewall or IWDG)

Compute and check the

user application firmware signature

User application

Checking device security

This part of the SB application checks if static configurations are correct and sets the dynamic ones. Static secure
configurations are defined by option bytes (RDP, PCROP, WRP and secure hide protection). Dynamic protections
must be programmed (firewall, MPU, tamper detection and IWDG).
Integrity and authenticity check
The firmware integrity is performed by hashing the application image (with MD5, SHA1 or SHA256 hash
algorithms) and comparing the digest with the expected one. This way, the application firmware is considered
error-free.
An authenticity check is added if the expected tag is encrypted with a key shared between the firmware owner
and the device. This key is stored in a protected area of the device.
Protection attributes
The SB firmware must have the following attributes to fulfill its role:
• It must be the device-unique entry point (no bypass).
• Its code must be immutable.
• It must have access to sensitive data (such as certificates or application signatures).
The most sensitive SB part takes benefit from process and data isolation features, like firewall, MPU or secure
hide protection. the implementation depends on STM32 series available features.

5.2.2 Secure firmware update (SFU)

The SFU provides a secure implementation of in-field firmware updates, enabling the download of new firmware
images to a device.
The firmware update is a sensitive operation that must protect two parties:
• the device owner: the goal is to avoid loading a corrupted firmware (intentionally or not) that may damage
the device.
• the application owner (OEM): needs to protect his firmware from being cloned or loaded into an
unauthorized device.

AN5156 - Rev 6 page 23/55

 AN5156
Arm TF-M solution

Architecture
An SFU transfer involves two entities: the firmware owner (OEM) and the device to be updated (see the figure
below). As the communication channel is generally considered as non-secure since it is subject to eavesdropping,
the overall security responsibility is shared between the sender (firmware owner server) and the receiver (the
device).

Figure 7. Secure server/device SFU architecture

Secure server/HSM Device

STM32STM32xx
MCU
Communication
SFU control software SFU firmware
channel

Encrypted and signed Current firmware

new firmware
New firmware

Application
From OEM side, a secure server is maintained that is responsible for sending the encrypted (if confidentiality is
required) and signed firmware to an authenticated device.
The SFU application running on device is in charge of the following:
• authentication and integrity checking of the loaded image before installing it
• decrypting the new firmware if confidentiality is required
• checking the new firmware version (anti-rollback mechanism)

5.3 Arm TF-M solution

Arm trusted firmware was around for some time, when the secure Cortex M-33 core was introduced with Armv8-M
architecture. A more compact TF-M open source implementation of PSA standard was provided as a reference
secure firmware framework.
For ST MCUs that take advantage of the ARMv8 architecture, such as the STM32L5 device, the SBSFU is
replaced with the TF-M solution.
For a documentation on TF-M itself, use Arm resources as well as the code comments.
For guidance on TF-M integration on the STM32L5 Series MCU, refer to the firmware example user manual.
Users migrating from SBSFU to TF-M may find a useful quick comparison table, comparing some of the
differences in basic features:

Table 8. Basic feature differences

Feature SBSFU v2.3.1 TF-M on STM32L5

HUK and attestation information

RoT services Propagation of Trust
management
Bootloader Yes No
FW image encryption Several options, including OTFDEC Not included
Cryptographic key management Keys in NMV, static code Volatile keys, updatable code
Secure storage Key management Yes, based on HUK
Initial attestation No Yes
Secure element support STSAFE-A110 No

AN5156 - Rev 6 page 24/55

 AN5156
Product certifications

Both solutions had different requirements and differ in architectures. They are not meant to be interchangeable, or
compete.
More details about building on TF-M on STM32 devices is available in the STM32 TF-M User Manual (UM2671).
A detailed comparison is available in the AN5447 application note (section X-CUBE-SBSFU vs. TF‑M
comparison).

5.4 Product certifications

Different secure applications often require certain certifications, proving their capability to perform in secure
manner. Independent or government agencies grant the certification status to either a MCU or a system based on
a MCU based on evaluation and/or testing.
The certifications and evaluations related to STM32 microcontrollers include, but are not limited to:
• PSA - Platform security architecture - governed by Arm, focused on IoT security, MCU certification, three
levels of assessment
– STM32L4 Series are certified Level 1, STM32L5 Series with TF-M are Level 2 and STM32U5 Series
with TF-M are Level 3
– To achieve Arm PSA certifiable security level refer to the user manual "STM32U585 security guidance
for PSA Certified™ Level 3 with SESIP Profil" (UM2852).
• SESIP - Security evaluation standard for IoT platforms - international methodology adopted by several major
security evaluation labs, five levels
– Systems using SBSFU or TF-M are compliant to Level 3 with STM32L4, L4+, L5 and U5 Series
devices
• PCI - Payment card information - important security standard focusing on point of sale (POS) applications
– Good record of successful evaluation of systems using for example STM32L4 Series devices
• CC - Common criteria - universal certification standard requires high standards of development, testing and
documentation quality.

AN5156 - Rev 6 page 25/55

 AN5156
STM32 security features

6 STM32 security features

This section presents all the STM32 features that can be gathered to meet the different security concepts
presented in previous sections and to achieve a high level of security.

6.1 Security features overview

Static and dynamic protections
A distinction can be made depending on whether protection features are static or dynamic:
• Static protections refer to features that are set with option bytes. Their configuration is retained at power off.
Static protections are RDP, PCROP, WRP, BOR, OTP and secure hide protection (when available).
• Dynamic (or run time) protections do not retain their status at reset. They have to be configured at each
boot (for example during Secure boot (SB) ).
Dynamic protections provided by STM32 are MPU, tamper detection and firewall.
Other dynamic protections are related to both security and safety. An abnormal environment behavior may
be accidental (safety) or intentional, in order to carry out an attack. These protections include clock and
power monitoring systems, memory integrity bits and independent watchdog (IWDG).

Security features by STM32 series

The tables below list the available features according to STM32 series.

AN5156 - Rev 6 page 26/55

 AN5156
Security features overview

Table 9. Security features for STM32Fx Series

Feature STM32F0 STM32F1 STM32F2 STM32F3 STM32F4 STM32F7

Cortex core M0 M3 M3 M4 M4 M7

RDP additional + backup 2 level RDP + backup

+ backup SRAM + backup SRAM + backup SRAM
protection registers only (1) registers

By sectors By sectors By sectors (16 K,

By sectors By pages (4 K By sectors
Flash WRP (16 K, 64 K or (16 K, 64 K or 64 K, 128 K or
(4 Kbytes) or 8 Kbytes) (4 Kbytes)
128 Kbytes) 128 Kbytes) 256 Kbytes)
SRAM WRP No No No No No No
PCROP No No No No By sectors By sectors
HDP No No No No No No
Firewall No No No No No No

MPU No Yes(2) Yes Yes Yes Yes

OTP No No Yes Yes 512 bytes 528 - 1040 bytes

OTFDEC No No No No No No
Unique boot
No No No No No No
entry(3)
Secure boot:
No No No No No No
system Flash
Internal tamper
No No No No No No
detection
Hardware crypto:
No No AES, HASH No AES, HASH AES, HASH
accelerators
Hardware crypto:
NA NA SP800-90-A NA SP800-90-A SP800-90-A
TRNG
Secure software:
secure firmware No No No No No No
install
Secure software:
No No No No Yes Yes
SBSFU
Secure software:
No No No No No No
TF-M
Secure software:
No No No No No No
KMS

1. The RDP in STM32F1 Series is only for Flash memory protection. RDP is set (RDP1) or unset (RDP0). RDP Level 2 is not
implemented.
2. Only XL density parts feature the MPU.
3. No UBE means that the boot only relies on RDP level 2. UBE in Yes means that a dedicated boot lock service exists.

AN5156 - Rev 6 page 27/55

 AN5156
Security features overview

Table 10. Security features for STM32Lx and STM32Ux Series

STM32L4
Feature STM32L0 STM32L1 STM32L5 STM32U5
STM32L4+

M33 with M33 with

Cortex core M0 M3 M4
TrustZone TrustZone

+ backup RDP four levels RDP four levels

RDP additional protection + EEPROM + EEPROM registers + backup registers + backup registers
+ SRAM2 + SRAM2 + SRAM2
By area with 2 Up to four
Kbytes granularity 2 areas per bank,
By sectors By sectors protected areas
Flash WRP defined by page
(4 Kbytes) (4 Kbytes) One area per with 2 or 4 Kbytes
range
bank granularity

By area with
8‑byte granularity
PCROP By sectors By sectors No No
One area per
bank
Up to two One secure hide
secure hide areas areas (HDP) per
HDP(1) No No No (HDP) inside the bank, inside the
TrustZone secure TrustZone secure
domain domain
Firewall Yes No Yes TrustZone based TrustZone based
MPU Yes Yes Yes Yes Yes

Unique boot entry(2) No No No Yes Yes

Internal tamper detection No No No Yes Yes

IWDG Yes Yes Yes Yes Yes
Device ID (96 bits) Yes Yes Yes Yes Yes
AES, secure AES,
Symmetric AES AES AES AES, OTFDEC
OTFDEC
Hardware crypto
accelerators Asymmetric No No No PKA PKA
Support No No HASH, TRNG HASH, TRNG HASH, TRNG
SRAM2 with 1- SRAM2 with 1- SRAM2 with 1-
RAM with protection No No
Kbyte granularity Kbyte granularity Kbyte granularity

1. HDP is known as secure user memory, sticky area or securable memory depending on the product.
2. No UBE means that the boot only relies on RDP level 2. UBE in Yes means that a dedicated boot lock service exists.

AN5156 - Rev 6 page 28/55

 AN5156
Security features overview

Table 11. Security features for STM32H7, STM32G0, STM32G4, STM32WB and STM32WL Series

STM32H7 Series
Feature STM32H72x/ STM32H74x/ STM32H7Ax/ STM32G0 STM32G4 STM32WB STM32WL
73x 75x Bx

M4 and M4 and
Cortex core M7 M0+ M4
M0+ M0+(1)
+ backup + backup
SRAM + backup SRAM + backup
+ backup + backup
RDP additional SRAM + backup registers
+ backup + backup registers registers
protection (2) + backup registers + CCM-
registers registers + SRAM2 + SRAM2
registers SRAM
+ OTFDEC + OTFDEC
By area By area By area
with By page with 4- with
By group of 2‑Kbyte Kbyte 2‑Kbyte
(2 Kbytes
WRP By sectors (128 Kbytes) x4 8-Kbyte granularity granularity granularity
or
sectors
Two areas 4 Kbytes) Two areas Two areas
available available available
By area
By area By area By area
with 64‑bit
with with with
By area with By area with 256‑byte or 128‑bit
512‑byte 2‑Kbyte 1‑Kbyte
PCROP 256‑byte granularity granularity
granularity granularity granularity
granularity One area per bank Up to two
Two areas Up to two Two areas
areas
available (3) areas available

Yes
Yes Yes
(dedicated
Yes (secure user memory, with 256‑byte (securable (securable
HDP(4) to CM0+ Yes
granularity) memory memory
firmware
area) area)
only)
Firewall No No No No Yes
MPU Yes Yes Yes Yes (CM4) Yes
Yes (boot Yes (boot
Unique boot entry(5) Yes (unique entry point in secure access) lock Yes No lock
feature) feature)
Internal tamper
Yes Yes Yes No Yes
detection
IWDG Yes Yes Yes Yes Yes
Device ID (96 bits) Yes Yes Yes Yes Yes
Symmetric AES, AES AES AES AES
Hardware
Asymmetric No No No PKA PKA
crypto (2)
Support HASH, TRNG TRNG TRNG TRNG TRNG
CCM SRAM2, SRAM2,
SRAM with with 1- with 1-
SRAM write protection No No
A-Kbyte Kbyte Kbyte
granularity granularity granularity

1. M0+ core is not available in all STM32WL devices.

2. Depends on device part number.
3. The number of area depends on device category and dual/single bank configuration.
4. HDP is know as secure user memory, sticky area or securable memory depending on the product.
5. No UBE means that the boot only relies on RDP level 2. UBE in Yes means that a dedicated boot lock service exists.

AN5156 - Rev 6 page 29/55

 AN5156
Readout protection (RDP)

6.2 Readout protection (RDP)

Readout protection is a global Flash memory protection allowing the embedded firmware code to be protected
against copy, reverse engineering, dumping, using debug tools or code injection in SRAM. The user must set this
protection after the binary code is loaded to the embedded Flash memory.
Readout protection applies to all STM32 series for:
• the main Flash memory
• the option bytes (level 2 only)
Depending on the STM32 series, additional protections may be available including:
• backup registers for real-time clock (RTC)
• backup SRAM
• EEPROM

Figure 8. Example of RDP protections (STM32L4 Series)

Debug port
registers
Backup

Backup

Backup
FLASH FLASH FLASH
Reg

Reg
SRAM1 SRAM SRAM
SRAM2 SRAM1 SRAM

Level 0 Level 1 Level 2

The RDP levels (0, 1 and 2) are defined as follows:

• Level 0: this is the default RDP level. The Flash memory is fully open and all memory operations are
possible in all boot configurations (debug features, boot from RAM, boot from system memory bootloader,
boot from Flash memory). There is no protection in this configuration mode that is appropriate only for
development and debug.
• Level 1: Flash memory accesses (read, erase, program) or SRAM2 accesses via debug features (such as
serial-wire or JTAG) are forbidden, even while booting from SRAM or system memory bootloader. In these
cases, any read request to the protected region generates a bus error.
However, when booting from Flash memory, accesses to both Flash memory and to SRAM2 (from user
code) are allowed.
• Level 2: When RDP Level 2 is activated, all protections provided in Level 1 are active and the MCU is fully
protected. The RDP option byte and all other option bytes are frozen and can no longer be modified. The
JTAG, SWV (single-wire viewer), ETM, and boundary scan are all disabled.
On devices built on ARMv8 architecture, a fourth RDP level is available:
• Level 0.5: non-secure debug only. All read and write operations (if no write protection is set) from/to the
non-secure Flash memory are possible. The debug access to secure area is prohibited. Debug access to
non-secure area remains possible.

AN5156 - Rev 6 page 30/55

 AN5156
Readout protection (RDP)

RDP level regression

RDP can always be leveled up. A level regression is possible with the following consequences:
• Regression from RDP Level 1 to RDP Level 0 leads to a Flash memory mass erase and the erase of
SRAM2 and backup registers.
• Regression from RDP Level 1 to RDP Level 0.5 leads to a partial Flash memory erase: only the non-secure
part is erased.
• Regression form RDP Level 0.5 to RDP Level 0 leads to a Flash memory mass erase and the erase of
SRAM2 and backup registers.
In RDP level 2, no regression is possible.

Internal Flash memory content updating on an RDP protected STM32 microcontroller

In RDP Level 1 or 2, the Flash memory content can no longer be modified with an external access (bootloader
or booting from SRAM). However, modifications by an internal application are always possible. This can be
performed through a SFU application or (even if it is not advised from a security point of view) from a simple
in-application-programming process (IAP).
The table below summarizes the RDP protections.

Table 12. RDP protections

RDP Boot from user Flash Debug or boot from SRAM or from bootloader
Area
Level Read Write Erase Read Write Erase

0 Yes Yes Yes Yes Yes Yes

Flash main memory 1 Yes Yes Yes No No No
2 Yes Yes Yes N/A N/A N/A
0 Yes No No Yes No No
System memory 1 Yes No No No No No
2 Yes No No N/A N/A N/A
0 Yes Yes Yes Yes Yes Yes
Option bytes 1 Yes Yes Yes Yes Yes Yes
2 Yes No No N/A N/A N/A
0 Yes Yes Yes Yes Yes Yes
Other protected assets
(1) 1 Yes Yes N/A No No No
2 Yes Yes N/A N/A N/A N/A

1. Backup registers/SRAM

When should RDP be used

On a consumer product, RDP must always be set at least at Level 1. This prevents basic attacks through the
debug port or through the bootloader. However, in RDP Level 1, there is a risk of service denial caused by a Flash
memory mass erase, following a return to RDP Level 0.
The RDP Level 2 is mandatory to implement an application with higher security level (such as immutable code).
The disadvantage is that the RDP Level 2 can prevent a device configuration update, for instance after a
customer return.
A new RDP level 0.5 is available on products with ARMv8. It is used to debug a non-secure application while
protecting contents within secure area boundaries from debug access. More information about this protection is
available in the application note AN5347 (section 10 Development recommendations using TrustZone®).
Note: RDP is available on all STM32 series.

AN5156 - Rev 6 page 31/55

 AN5156
One-time programmable (OTP)

6.3 One-time programmable (OTP)

OTP is a dedicated, isolated area in the Flash memory, which can be only written on or locked out, preventing any
modification. Usually OTP is a smaller area compared to the size of the user Flash memory.
This feature is very useful for life-cycle management, provisioning, personalization or configuration. Once the
OTP is written, there is no method of erasing the data without physically damaging the chip. No restriction is
implicitly put on reading the written data.
Note: OTP is available on most STM32 series, refer to Section 2 Overview for more details.

6.4 TrustZone
The following section describes the main features of the TrustZone architecture. For further information, refer to
the application note STM32L5 Series TrustZone® features (AN5347) and to the reference manual STM32L552xx
and STM32L562xx advanced Arm®-based 32-bit MCUs (RM0438).
The ARMV8-M TrustZone architecture defines two domains at system level: secure and non-secure. The full
memory-map space is split into secure and non-secure areas. This includes all memory types (Flash, SRAM
and external memories), as well as all peripherals that can be shared (with specific context for each domain) or
dedicated to one domain or the other.
At system level, the isolation between secure and non-secure domains relies on the following hardware
mechanisms (see the figure below).
• specific core architecture (ARMV8-M Cortex-M33) with a dual-bank register for secure and non-secure
domains, and a secure attribution unit (SAU) to assert address range security status.
• implementation defined attribution unit (IDAU) which is complementary to the SAU.
• bus infrastructure that propagates the secure and privilege attributes of any transaction (AHB5)
• dedicated hardware blocks managing the split between the two domains (GTZC to define security attribute
for internal SRAMs and external FSMC/OCTOSPI memories, and peripherals)

Figure 9. TrustZone implementation at system level

ARMv8-M
Cortex-M33
AHB master
SAU/MPU

AHB5

AHB peripherals MPCBB Secure

GTZC watermarks and
MPCWM block based
AHB/APB
bridge Flash
memory
APB

APB
peripheral Internal External
SRAM memory
TrustZone specific implementation

6.4.1 Core state

The core state depends on the region of the current running code. When the code runs from a secure region, the
core is in secure state. Otherwise, the core is in non-secure state.

AN5156 - Rev 6 page 32/55

 AN5156
Flash memory write protection (WRP)

6.4.2 Secure attribution unit (SAU)

The SAU is a hardware unit coupled to the core (as the MPU). The SAU is responsible for setting the security
attribute of the AHB5 transaction. The security attribute of a transaction is fixed by the targeted address of a
memory-mapped resource (memory areas or peripherals). Depending on the SAU configuration, an address is
tagged as secure, non-secure callable (NSC), or non‑secure. The NSC is a sub-domain of the secure domain,
that allows a gateway to be defined for non-secure code to access the secure domain at a specific entry point.
The SAU is configurable by secure firmware. It can be configured at boot for a fixed configuration or can be
dynamically modified by a secure firmware.
Note: A security attribute cannot be modified to be less secure (by security order: secure > NSC > non-secure)
than a default attribute set by hardware through an IDAU (implementation defined secure attribute). Refer to
implementation details of each device in reference manual.
Address aliasing
The security attribute is set depending on the fixed resource address. However, a memory‑mapped resource can
be set either as secure or non-secure, depending on the application. To overcome this apparent contradiction, two
addresses are assigned to each memory-mapped resources: one used when the resource must be accessed in
secure mode, one used in non-secure mode. This mechanism is called address aliasing.
The address aliasing allows also all peripherals access to be grouped in only two regions instead of multiple
scattered regions. Finally, the IDAU splits the memory-mapped resources in the following regions:
• Peripherals secure/non-secure regions
• Flash memory secure/non-secure regions
• SRAM secure/non-secure regions
Refer to device reference manual for the detailed configuration.

6.4.3 Memories and peripherals protections

The SAU defines the transaction security attribute and the bus infrastructure propagates this attribute towards
the targets. The targets (memories and peripherals) are protected by hardware mechanisms that filter the access
depending on the secure and privilege attributes.
There are two types of peripherals in the TrustZone system architecture:
• TrustZone-aware peripherals: connected directly to the AHB or APB bus, with a specific TrustZone behavior
such as a subset of secure registers. The access filtering control is included in these peripherals
• Securable peripherals: protected by an AHB/APB firewall gate controlled by the GTZC to define security
properties
TrustZone-aware peripherals are the ones with a bus master role (DMAs), the GTZC, the Flash memory controller
and others peripherals with a fundamental role within the system: PWR, RTC and system configuration block. The
remaining system peripherals are securable.
GTZC
The GTZC defines the access state of securable peripherals, embedded SRAM and external memories:
• Peripherals can be set as secure or non-secure (exclusively), privileged or non-privileged using TZSC.
• Embedded SRAM is protected by blocks of 256 bytes through the MPCBB block.
• External memories are protected by regions (watermark: start and length). The number of protected regions
depends on the memory types (NAND, NOR or OCTOSPI).
• Illegal access events lead to secure interrupts generated by TZIC.
Note: The Flash memory security attribute is defined through secure watermark option bytes and/or Flash interface
block-based registers.

6.5 Flash memory write protection (WRP)

The write protection feature is used to protect the content of specified memory area against erase or update.
For Flash memory technology, an update must be considered as filling with zeros.
For instance, the write protection can be set on a page or a sector of a Flash memory to prevent its alteration
during a firmware or data update. It can also be set by default on the unused memory area to prevent any
malware injection. Its granularity is linked to the page or sector size.

AN5156 - Rev 6 page 33/55

 AN5156
Execute-only firmware (PCROP)

When should WRP be used

This protection must be used, in particular when write operations are foreseen within the application. This is the
case if data storage or code update operations are expected. WRP prevents wrong accesses due to unsafe
functions causing unexpected overflows.
Note: Write protection is available on all STM32 series.

6.6 Execute-only firmware (PCROP)

Part of the STM32 Flash memory can be configured with an 'execute-only' attribute. The firmware stored in
such configured area can only be fetched by the CPU instruction bus. Any attempt to read or write this area
is forbidden. The protection applies against both internal (firmware) accesses as well as external (debug port)
accesses. In STM32, this feature is named proprietary code readout protection (PCROP).
The PCROP is a static protection set by option bytes. The number of protected areas and their granularity
depends on the STM32 series (see Table 9, Table 10 and Table 11). When PCROP is in use, care must be taken
to compile the firmware with the execute-only attribute (refer to user compiler options).
When should PCROP be used
PCROP is used to protect third-party firmware (intellectual property) as well as the most sensitive parts of the
user firmware.
Note: PCROP is available on all STM32 Series listed in Table 1, except on TrustZone-enabled devices, where it is
superseded by another protection mechanism.

6.7 Secure hide protection (HDP)

Some STM32 devices supports the HDP memory concept. The HDP, named secure hide protection on STM32L5
Series, is also known as secure user memory on STM32H7 Series, or securable memory on STM32G0 Series.
An HDP area is a part of the Flash memory that can be accessed only once, just after a device reset. The HDP
targets sensitive applications that embed or manipulate confidential data and that must be securely executed at
boot. Once the application is executed, the HDP area is closed and cannot be accessed anymore by any mean
(see the figure below).

Figure 10. HDP protected firmware access

Reset

Flash memory

Secure firmware execution R/W/E

HDP area
HDP area access enabled access allowed
ss
a cce
No
Main application execution
HDP area access disabled

The HDP is a static protection configured by option bytes. Once set, the CPU boots on the firmware embedded in
this area, whatever the boot configuration set by boot pin or boot address.
When should HDP be used
The HDP is suited for a code that must only be executed after reset, like secure boot for root of trust.
This protection is available in STM32H7, STM32G0, STM32G4 and STM32L5 Series with slights differences in its
implementation and name (refer to dedicated reference manuals for details).

AN5156 - Rev 6 page 34/55

 AN5156
Firewall

6.8 Firewall
The firewall is a hardware protection peripheral controlling the bus transactions and filtering accesses to three
particular area: a code area (Flash memory), a volatile data area (SRAM) and a non-volatile data area (Flash
memory). The protected code is accessible through a single entry point (the call-gate mechanism explained
below). Any attempt to jump and try to execute any of the functions included in the code section without passing
through the entry point, generates a system reset.
The firewall is part of the dynamic protections. It must be set at startup (for example by a SB application).
Call gate mechanism
The firewall is opened by calling a 'call-gate' mechanism: a single entry point that must be used to open the gate
and to execute the code protected by the firewall. If the protected code is accessed without passing through the
call gate mechanism, then a system reset is generated. If any instruction is fetched outside the protected area,
the firewall is closed (see the figure below).

Figure 11. Firewall FSM

IDLE
Firewall
enabled Reset
Reset

Call gate
CLOSED OPEN
Instruction fetch
out of prot. area

Since the only way to respect the call gate sequence is to pass through the single call gate entry point, a
mechanism must be provided in order to support application calling multiple firewall-protected functions from
unprotected code area (such as encrypt and decrypt functions). A parameter can be used to specify which
function to execute (such as CallGate(F1_ID) or CallGate(F2_ID)). According to the parameter, the right
function is internally called.

AN5156 - Rev 6 page 35/55

 AN5156
Memory protection unit (MPU)

This mechanism is represented in the figure below.

Figure 12. Firewall application example

unprotected_code.c

Function ID f1()

f1a()
Call gate single entry point
f1b()

f2()

f2a()

f2b()

f3()

f3a()

f3b()
Firewall code section

When should firewall be used

The firewall protects both code and data. The protected code can always be called as long as a call-gate
mechanism is respected.
Note: A firewall is available on STM32L0 and STM32L4 Series only.
Note: Refer to STM32L0/L4 FIREWALL overview application note (AN4729) for more details on firewall.

6.9 Memory protection unit (MPU)

The MPU is a memory protection mechanism that allows specific access rights to be defined for any memory-
mapped resource of the device: Flash memory, SRAM and peripheral registers. This protection is dynamically
managed at runtime.
Note: MPU attributes are only set for CPU access. Other bus masters requests (such as DMA) are not filtered by the
MPU and must be deactivated if they are not needed.

Region access attributes

The MPU splits the memory map into several regions, each having its own access attribute. Access right can be
set as Executable, Not executable(XN), Read-Write (RW), Read Only (RO) or No Access.
Note: There are other attributes set by the MPU for each region: shareable, cacheable and bufferable. This application
note does not cover the whole complexity of MPU and this chapter serves as a mere introduction and high
level overview. Refer to applicable device programming manual or to the application note Managing memory
protection unit (MPU) in STM32 MCUs (AN4838).

Privileged and unprivileged modes

On top of the access attribute, the Arm Cortex-M architecture defines two execution modes, allowing a process to
run in either privileged or unprivileged mode. For each region, the access attribute can be set independently for
each mode.

AN5156 - Rev 6 page 36/55

 AN5156
Customer key storage (CKS)

The table below shows the different cases supported by mixing modes and access attributes.

Table 13. Attributes and access permission managed by MPU

Privileged mode attribute Unprivileged mode attribute Description

Execute Never (XN)(1) Code execution attribute

No access No access All accesses generate a permission fault.

RW No access Access from a privileged software only
RW RO Written by an unprivileged software generate a permission fault .
RW RW Full access
RO No access Read by a privileged software only
RO RO Read only, by privileged or unprivileged software

1. Execute Never (XN) attribute is set by region and is valid for both modes. It can be used to avoid SRAM code injection for
example.

The code executed in privileged mode can access additional specific instructions (MRS) and can also access Arm
core peripheral registers (such as NVIC, DWT or SBC). This is useful for OS kernels or pieces of secure code that
require access to sensitive resources that are otherwise inaccessible to unprivileged firmware.

Secure process isolation strategy

At reset, the privilege mode is the default one for any process. Therefore the SB application is executed in
privileged mode. Then the idea is to isolate secure processes (such as SB, OS kernel, Key manager or SFU) from
unsecured or untrusted processes (user applications).

Table 14. Process isolation

Firmware type Mode Resources access

Secure firmware (such as SB or OS kernel) Privileged Full access

All remaining firmware Unprivileged MPU controlled access: No access, RO, RW

An OS kernel can manipulate MPU attributes dynamically to grant access to specific resources depending on the
currently running task. Access right may be updated each time the OS switches from one task to another.

When should MPU be used

The MPU is used at runtime to isolate sensitive code and/or to manage access to resources depending on the
process currently executed by the device. This feature is useful especially for advanced embedded operating
systems that incorporate security in their design.
Note: The MPU is available on all STM32 series, except the STM32F0 Series (see the various programming manuals
for more details).

6.10 Customer key storage (CKS)

The STM32WB Series are dual-core devices with one core (CPU1) for user application and another core (CPU2)
dedicated to the wireless real-time aspect execution (either Bluetooth Low Energy or thread protocols). The Flash
memory used by CPU2 is secured from CPU1 or external access. Communication between the two cores is
ensured by a mailbox and an inter‑process channel control hardware block (IPCC).
In addition to the wireless stack execution, CPU2 offers a secure storage service for cryptographic keys used with
a dedicated AES hardware block (refer to the figure below). The key register of this block is accessible only to
CPU2, preventing access to the key by an untrusted process running on CPU1 or by the debug port.

AN5156 - Rev 6 page 37/55

 AN5156
Anti-tamper (TAMP)/Backup registers (BKP)

After keys have been provisioned inside the secure area, the user application can use them by calling a secure
load service with an index referencing the key and no more the key itself.

Figure 13. Dual-core architecture with CKS service

CKS
Key 0
Wireless stack Key 1
CPU2 Key n
AES hardware
block
Secure key
register
IPCC and mailbox
Data register

CPU1
User application

When should CKS be used

CKS must be used when a user application relies on AES encryption or decryption. Provisioned keys can be
stored in a secure area, so that no other internal process or external access can read their value.
Note: CKS is available on STM32WB Series only.

6.11 Anti-tamper (TAMP)/Backup registers (BKP)

The anti-tamper is a system level protection, used to detect physical tampering attempts on the system. An
external tamper event is detected by a level transition on dedicated device pins. Internal tamper sensors can
check voltage, temperature or clock. This event can be used to wake up the core in order to take appropriate
actions (such as memory erase or alarm).
This peripheral includes backup registers with contents preserved by VBAT, along with the real-time clock (RTC).
These registers may be reset if a tamper attempt is detected.
On less recent devices, this peripheral is known as Backup registers (BKP). On recent devices, it has evolved
with additional features, such as monotonic counter or secure section for TrustZone secure area.
When should anti-tamper be used
It must be used for system intrusion detection (in consumer products sealed enclosures for example). The
monotonic counter is a countermeasure against tampering with RTC.
Note: The external tamper detection is available on all STM32 series.

6.12 Clock security system (CSS)

The CSS is designed to detect a failure of an external clock source (a crystal for example). A loss of clock source
may or may not be intentional. In any case, the device must take an appropriate actions to recover. The CSS
triggers an interrupt to the core in such event.
In case the external clock source drives the main system clock, the CSS switches the system to an internal clock
source.
When should CSS be used:
The CSS must be used when an external clock is used.
Note: The CSS is available on all STM32 series.

6.13 Power monitoring

Some attacks may target the microcontroller power supply in order to cause errors that may lead to a failure of
security countermeasures. A loss of power supply may also denote an attempt to freeze the device state in order
to access the internal memory content.

AN5156 - Rev 6 page 38/55

 AN5156
Memory integrity hardware check

The STM32 devices embed a programmable voltage detector (PVD) that can detect a drop of power. The PVD
allows the configuration of a minimum voltage threshold, below which an interrupt is generated so that the
appropriate actions may be implemented.
When should PVD be used
the PVD must be used as soon as a sensitive application is running and is likely to leave some confidential data in
the working memory (SRAM). A memory cleaning can be launched in case of power down detection.
Note: The PVD is available on all STM32 series.

6.14 Memory integrity hardware check

The error code correction (ECC) and parity checks are safety bits associated to the memory content. The ECC
is associated to the memory words and allows recovering from a single bit error or detecting up to two erroneous
bits on each Flash or SRAM memory word which may be a 32-bit to 256-bit word depending on the memory
type. A simple parity check allows the detection of a single error bit on the SRAM words where ECC is not
implemented. Further details on ECC are available for example in the AN5342 application note.
When should ECC and parity bits be used
ECC and parity checks are mostly used for safety reasons. The ECC can also be used to prevent some invasive
hardware attacks.

6.15 Independent watchdog (IWDG)

The IDWG is a free running down counter that can be used to trigger a system reset when the counter reaches
a given timeout value. The IDWG can be used to provide a solution in case of malfunctions or deadlock in the
running code. the IDWG is clocked by its own independent low-speed clock (LSI), so that it stays active even in
the event of a main clock failure.
When should IWDG be used
IWDG can be used in order to break deadlocks. It can also be used to control execution time of critical code (such
as decryption or Flash programming).
Note: The IDWG is available on all STM32 series.

6.16 Device ID
Each STM32 device has a unique 96-bit identifier providing an individual reference for any device in any context.
These bits can never be altered by the user.
The unique device identifier can be used for direct device authentication or used, for instance, to derive a unique
key from a master OEM key.

6.17 Cryptography
As described in Section 5 , cryptography algorithms are essential to secure an embedded system. The
cryptography ensures confidentiality, integrity and authentication of data or code. For efficiently supporting these
functions, most STM32 series offer microcontroller options with embedded hardware cryptography peripherals.
These hardware blocks allow the cryptographic computations (such as hashing or symmetric algorithms) to be
accelerated. For devices with no such specific hardware acceleration, the STM32 cryptographic firmware library
(CryptoLib) provides a software implementation of a large set of cryptographic algorithms.

AN5156 - Rev 6 page 39/55

 AN5156
On-the-fly decryption engine (OTFDEC)

6.17.1 Hardware accelerators

The following cryptographic hardware peripherals are available in STM32 devices:
• True random generator
– Hardware-based peripheral providing a physical noise source. Used to generate strong session keys.
Note: For details about the TRNG validation refer to application note STM32 microcontroller random number
generation validation using the NIST statistical test suite (AN4230).
• AES accelerator
– Encryption/decryption
– 128- or 256‑bit keys
– Several chaining modes (such as ECB, CBC, CTR or GCM)
– DMA support
• PKA accelerator
– Acceleration of RSA, DH and ECC over GF(p) operations, based on the Montgomery method for fast
modular multiplications
– Built-in Montgomery domain inward and outward transformation
• HASH accelerator
– MD5, SHA1, SHA224, SHA256
– FIPS compliant (FIPS Pub 180-2)
– DMA support
Note: In case the AES block is used for encryption or decryption, the access to its registers containing the key must be
protected and cleaned after usage (MPU).

6.17.2 CryptoLib software library

The STM32 X-CUBE-CRYPTOLIB is the software library running on all STM32 devices. It is available for free
download at www.st.com/en/product/x-cube-cryptolib. The STM32 X-CUBE-CRYPTOLIB V3.1.5 is available with
full firmware implementation, compiled for Cortex-M0, M0+, M3, M33, M4, and M7 cores.
The X-CUBE-CRYPTOLIB supports the following algorithms:
• DES, 3DES with ECB and CBC
• AES with ECB, CBC, OFB, CCM, GCM, CMAC, KEY wrap, XTS
• Hash functions: MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
• Other: ARC4, ChaCha20, Poly1305, Chacha20-Poly1305
• RSA signature with PKCS#1v1.5
• ECC with Key generation, Scalar multiplication (basis of ECDH) & ECDSA + ED25519 and Curve 25519
Note: The X-CUBE-CRYPTOLIB V3.1.5 supports all STM32 series.

6.18 On-the-fly decryption engine (OTFDEC)

The external memory content (code and data) cannot be protected with traditional read/write protections. The way
to protect the content is to encrypt it and to decrypt it inside the device before its usage.
One way consists in downloading the external memory content inside the SRAM, decrypting it and executing the
code and/or using the data. There are two drawbacks with this method: it introduces a delay that may not be
acceptable, and it may use a large amount of SRAM, depending on the content.

AN5156 - Rev 6 page 40/55

 AN5156
On-the-fly decryption engine (OTFDEC)

The OTFDEC offers the possibility to decrypt the content directly with a low latency penalty and without the need
for SRAM allocation. The OTFDEC is a hardware block that decrypt on-the-fly bus (AHB) traffic based on the
read-request address information. It is used with Octo-SPI interface (see the figure below).

Figure 14. Typical OTFDEC usage in a SoC

Instruction data/system
cache cache

OTFDEC
OCTOSPI

SPI bus
SoC boundary

SPI NOR
Flash

The OTFDEC uses the AES-128 in counter mode, with a 128-bit key to achieve a latency below 12 AHB cycles.
Up to four independent and non-overlapping, encrypted regions can be defined (4-Kbyte granularity), each with its
own key.
When OTFDEC should be used
The OTFDEC is used when an external memory is used by the system. In the case of a TrustZone capable MCU,
the decryption keys can only be made accessible through the secure mode. See AN5281 for more details.
Note: The OTFDEC is available on STM32L5 Series and STM32H7 Series only.

AN5156 - Rev 6 page 41/55

 AN5156
Guidelines

7 Guidelines
Secure systems may take advantage of many security supporting hardware feature. Some are useful for any
system, and need little change in the application code to be activated and fully functional. It is the case of the
RDP feature, that prevents basic access to the Flash memory by disabling the debug port. Other features must be
selected depending on user application and the required security level.
This section helps defining the adapted set of security features, depending on the system use-cases.
Use-cases are gathered in four main groups: protection against external (1) and internal (2) threats, security
maintenance (3) and other use-cases related to cryptography (4) (see the table below).

Table 15. Security use cases

1 Device protection against external threats: RDP protection, tamper detection, device monitoring
1.1 Device configuration (option bytes, not supposed to be modified ever)
• Use RDP Level 2. This closes the device from any external access.
1.2 Remove debug capability for the device.
• Use RDP Level 2 for permanently disabling the debug.
1.3 Protect a device against a loss of external clock source (crystal).
• Enable clock security system (CSS).
-
1.4 Detect a system-level intrusion.
• Use tamper detection capability of the RTC peripheral.
1.5 Protect a device from code injection.
• Use RDP.
• Isolate communication port protocol with MPU, firewall or HDP.
• Limit communication port protocol access range.
• Use write protection on empty memory areas (Flash memory and SRAM).
2. Code protection against internal threats: TrustZone, PCROP, MPU, firewall and HDP
2.1 Protect the code against cloning.
• Use RDP Level 1 or 2 against external access.
• Use PCROP on most sensitive parts of the code against internal access.
• Use OTFDEC to secure code stored in the external memory.
2.2 How to protect secret data from other processes
• Use firewall to protect both code and data.
• Use MPU to protect secret data area from being read.
- • Use HDP in case data must only be used at reset.
• Use secure domain of TrustZone if available.
2.3 Protect code and data when not fully verified or trusted libraries are used.
• Use PCROP to protect user most sensitive code.
• Use firewall to protect user sensitive application (code, data and execution).
• Use MPU and de-privilege the untrusted library.
• Use IWDG to avoid any deadlock.
• Use secure domain of TrustZone if available.
3. Device security check and maintenance: integrity checks, SB, SFU
3.1 Check code integrity.
• Hash firmware code at reset and compare to expected value.
• Enable ECC on the Flash memory and parity check on the SRAM.
-
3.2 Security checks or embedded firmware authentication
• Implement SB application with cryptography.
• Protect SB application secret data (refer to previous sections).

AN5156 - Rev 6 page 42/55

 AN5156
Guidelines

• Guarantee unique boot entry on SB application:

– Use HDP if available.
– Use RDP Level 2 and disable boot pin selection.
-
3.3 Securely update the firmware in the field.
• Implement a SFU application with cryptography.
• Apply relevant secure memory protection around the SFU secret data (refer to previous sections).
4. Communication and authentication: cryptography
4.1 Communicate securely.
• Use or implement secure communication stacks relying on cryptography for confidentiality and authentication
(such as TLS for Ethernet).
4.2 Use the ST AES/DES/SHA cryptographic functions with STM32 devices.
• Use only official software implementation by ST with STM32 X-CUBE-CRYPTOLIB.
4.3 Accelerate AES/DES/SHA cryptographic functions.
• Use device with cryptographic hardware peripheral together with official STM32 X-CUBE-CRYPTOLIB.
• Use OTFDEC to access AES-ciphered code in the external memory without latency penalty.
4.4 Generate true random data.

- • Use hardware true random generator embedded in the STM32 devices.

4.5 Uniquely identify ST microcontrollers.
• Use STM32 microcontrollers 96-bits UID.
4.6 Authenticate a product device.
• Embed a shared encryption key in the device and exchange encrypted message.
4.7 Uniquely authenticate a product device.
• Embed a device private key and its certificate in the device and exchange encrypted message.
4.8 Authenticate communication servers.
• Embed a shared encryption key in the device and exchange encrypted message.
• Embed server public key in the device and exchange encrypted message.

AN5156 - Rev 6 page 43/55

 AN5156
Conclusion

8 Conclusion
No system can be made secure by simply enabling security features in the hardware. Security must be rooted in
the architecture of the complete solution.
The threats must be identified, the countermeasures correctly designed and implemented in synergy with other
security features.
As security demands considerable resources, it is important to correctly evaluate the risks and spend the
resources efficiently, keeping in mind the cost of attack and the value of the protected asset.
The idea of root of trust is very helpful because it uses a more analytical approach, as opposed to a holistic
approach for which everything depends on everything else.
With the STM32 Series microcontrollers, the embedded and IoT security can be very cost-effective and efficient.

AN5156 - Rev 6 page 44/55

 AN5156
Cryptography - Main concepts

Appendix A Cryptography - Main concepts

Integrity, authentication and confidentiality
The objectives of cryptography are threefold:
• Confidentiality: protection of sensitive data against unauthorized read accesses
• Authentication: guarantee of the message sender identity
• Integrity: detection of any message corruption during transmission
To meet these objectives, all secure data flows rely on more or less complex combinations of the below
algorithms:
• Secret key/symmetric cryptography
• Public key/asymmetric cryptography
• Hashing
These algorithms are described in the below sections.

A.1 Secret key algorithms

This family of algorithms ensures confidentiality by ciphering a clear plain text with a secret key shared between
the transmitter and the receiver. This technique is referred to as symmetric cryptography because the same key is
used for ciphering and deciphering.

Figure 15. Symmetric cryptography

Secret key Secret key

John Doe1 John Doe2

The inherent weakness of these algorithms is the key sharing between both parties. It may not be an issue in
secure environments (such as manufacturing plants) but when both parties are distant, the key transfer becomes
a challenge.
Among all secret key algorithms, block-based algorithms are very common since they can be efficiently
accelerated by hardware or software parallel implementations. Typical AES (advanced encryption standard)
algorithms operate on clear blocks of 128 bits. They produce ciphered blocks of the same length using keys of
128, 192 or 256 bits. The different ways to chain consecutive blocks are called “mode of operations”. They include
cipher block chaining (CBC), counter mode (CTR) and Galois counter mode (GCM).
Since these algorithms are deterministic, they always mix input data with a random value, known as nonce, used
only for one session as initialization vector.

AN5156 - Rev 6 page 45/55

 AN5156
Public key algorithms (PKA)

A.2 Public key algorithms (PKA)

This class of algorithms is based on a pair of keys. One key, the private one, is never exchanged with any remote
system, while the other key, the public one, can be shared with any party. The relationship between both keys is
asymmetric (asymmetric cryptography):
• A message encrypted by the private key can be read by any party with the public key. This mechanism
ensures a strong authentication of the sender since the private key has never been shared. Digital
signatures are based on this mechanism.

Figure 16. Signature

Public key A
John Doe2

Only John Doe1 could have

John Doe1 Private key A written this

Public key A John Doe3

• A message encrypted by the public key can only be read by the private key owner.

Figure 17. PKA encryption

Public key A
John Doe2

Only John Doe1 can

John Doe1 Private key A read this

Public key A John Doe3

The main use of public key algorithms is authentication.

It is also used to resolve the “key sharing” issue of symmetric cryptography. However, this comes at the cost of
more complex operations, increased computation time and bigger memory footprint.
RSA and elliptic curve cryptography (ECC) are the most common asymmetric algorithms.
Hybrid cryptography
Common secure transfer protocols (such as Bluetooth and TLS) rely on both algorithm types. This scheme is
known as hybrid cryptography:
• Asymmetric cryptography is used first, in order to solve the symmetric key-sharing problem. A session key is
exchanged by the public key owner to the private key owner.
• Transfer confidentiality is then provided by a symmetric algorithm using the session key.

A.3 Hash algorithms

Hash algorithms guarantee the message integrity. They generate a unique fixed-length bitstream from a message
called the digest. Any difference in the input message produces a totally different digest. The digest cannot be
reversed to retrieve the input message.
Hashing can be used independently from message encryption.

AN5156 - Rev 6 page 46/55

 AN5156
MAC or signature and certificate

Figure 18. Message hashing

Message HASH

John Doe1 HASH Digest =? John Doe2

The difference with classic CRC is the robustness due to operations that are more complex and a much higher
digest length: up to 512 bits instead of 16 or 32 bits. As an example, CRC are reserved for fast integrity checks
during data transfers. Digest length makes them virtually unique and ensures that no collision occurs.
Typical algorithms are the MD5 (128-bit digest), SHA-1 (160-bit digest), SHA-2 (224-, 256-,384-, or 512-bit digest)
and SHA-3 (224-, 256-, 384-, or 512-bit digest).

A.4 MAC or signature and certificate

MAC and signature
The message authentication code (MAC) and signature add authentication to integrity by encrypting the message
hash. The difference between MAC and signature is that MAC generation uses a symmetric key algorithm
(Figure 19) while signature uses the message sender private key (Figure 20).
The signature adds non-repudiation dimension to authentication:
• A private key is not supposed to be revoked (its lifetime goes beyond the transfer operation.) while a secret
key may have a limited lifetime (limited to this transfer).
• The private key used for signature is never shared, its security is higher than a secrete key.

Figure 19. MAC generation with secrete key algorithm

Message HASH

John Doe1 HASH Digest =? John Doe2

Secret Secret
key key
MAC MAC MAC

Figure 20. Signature generation with public key algorithm

Message HASH

John Doe1 HASH Digest =? John Doe2

Private Public
key key
Signature Signature Signature

AN5156 - Rev 6 page 47/55

 AN5156
MAC or signature and certificate

Certificate
A certificate is related to public key algorithms. It authenticates the public key in an asymmetric transfer. It is used
to counteract usurpation by an attacker that could substitute the right public key by his own key. A certificate
consists in the public key signed by a certificate authority (CA) private key. This CA is considered as fully trusted.
In addition to the public key, the certificate also contains version numbers, validity period and some IDs.

AN5156 - Rev 6 page 48/55

 AN5156

Revision history

Table 16. Document revision history

Date Version Changes

17-Oct-2018 1 Initial release.

Updated:
• Table 1. Applicable products
• Section 1 General information
• Table 11. Security features for STM32H7, STM32G0, STM32G4 and
25-Feb-2019 2 STM32WB Series
• Figure 9. Example of RDP protections (STM32L4 Series)
• Section 6.6 Firewall
Added:
• Section 6.8 Cryptographic key storage (CKS)
Updated:
• Table 1. Applicable products
• Section "Introduction" renamed "Overview"
• Table 2. Glossary
• Section "Hardware protections" renamed "Device protections"
• Figure 4. Memory types
• Table 5. Memory types and associated protection
• Section 4.2.4 External Flash memories
• Table 6. Scope of STM32 embedded memories protection features
• Table 7. Software isolation mechanism
7-Oct-2019 3 • Section 4.5 Boot protection
• Section 5 Secure applications: Table 9, Table 10 and Table 11
• Section 6.2 Readout protection (RDP)
• Section 6.7 Secure hide protection (HDP)
• Section 6.17 Cryptography
• Section 7 Guidelines
• Some colors removed on all figures
Added:
• Section 4.1 TrustZone® for Armv8-M architecture
• Section 6.4 TrustZone
• Section 6.18 On-the-fly decryption engine (OTFDEC)
• Updated Section Introduction
• Added acronyms in Table 2. Glossary
• Updated Section 2 Overview and Section 3 Attack types
• Restructured Section 3.4 IoT system attack examples (added Section
3.5 List of attack targets)
21-Feb-2020 4
• Updated Section 4 Device protections
• Updated and restructured Section 5 Secure applications
• Added Section 5.3 Arm TF-M solution
• Updated Section 6 STM32 security features, Section 7 Guidelines and
Section 8 Conclusion
Updated:
• Document's scope to add STM32WL Series
• Table 1. Applicable products
06-Nov-2020 5 • Section 1 General information
• Section 3.1 Introduction to attack types
• Section 3.2 Software attacks
• Section 3.3.1 Non-invasive attacks

AN5156 - Rev 6 page 49/55

 AN5156

Date Version Changes

• Section 3.3.2 Silicon invasive attacks
• Section 4.1 TrustZone® for Armv8-M architecture
• Table 5. Memory types and associated protection
• Section 5.3 Arm TF-M solution
• Table 8. Basic feature differences
• Section 6.1 Security features overview including updates in all the
tables
• Section 6.2 Readout protection (RDP)
• Section 6.4 TrustZone
Added:
• Section 4.2 Dual-core security
• Section 6.3 One-time programmable (OTP)
Updated:
• Document's scope to add STM32U5 Series
• Table 1. Applicable products
• Section 3.3.1 Non-invasive attacks
• Section 4.3.3 Embedded SRAM
• Section 4.3.4 External Flash memories
• Section 5 Secure applications
• Table 9. Security features for STM32Fx Series
• Table 10. Security features for STM32Lx and STM32Ux Series
• Table 11. Security features for STM32H7, STM32G0, STM32G4,
07-Jul-2021 6 STM32WB and STM32WL Series
• Section 6.3 One-time programmable (OTP)
• Section 6.6 Execute-only firmware (PCROP)
• Section 6.8 Firewall
• Section 6.9 Memory protection unit (MPU)
• Section 6.17 Cryptography
• Section 6.17.1 Hardware accelerators
• Section 6.17.2 CryptoLib software library
Added:
• Section 5.4 Product certifications

AN5156 - Rev 6 page 50/55

 AN5156
Contents

Contents
1 General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
2.1 Security purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Attack types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
3.1 Introduction to attack types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Software attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Hardware attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1 Non-invasive attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2 Silicon invasive attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 IoT system attack examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5 List of attack targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Device protections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
4.1 TrustZone® for Armv8-M architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Dual-core security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Memory protections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1 System Flash memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.2 User Flash memory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.3 Embedded SRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.4 External Flash memories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.5 STM32 memory protections overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Software isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Debug port and other interfaces protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6 Boot protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.7 System monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Secure applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
5.1 Root and chain of trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 ST proprietary SBSFU solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.1 Secure boot (SB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.2 Secure firmware update (SFU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3 Arm TF-M solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4 Product certifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 STM32 security features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
6.1 Security features overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Readout protection (RDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

AN5156 - Rev 6 page 51/55

 AN5156
Contents

6.3 One-time programmable (OTP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.4 TrustZone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4.1 Core state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4.2 Secure attribution unit (SAU). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.4.3 Memories and peripherals protections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.5 Flash memory write protection (WRP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.6 Execute-only firmware (PCROP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.7 Secure hide protection (HDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.8 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.9 Memory protection unit (MPU). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.10 Customer key storage (CKS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.11 Anti-tamper (TAMP)/Backup registers (BKP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.12 Clock security system (CSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.13 Power monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.14 Memory integrity hardware check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.15 Independent watchdog (IWDG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.16 Device ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.17 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.17.1 Hardware accelerators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.17.2 CryptoLib software library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.18 On-the-fly decryption engine (OTFDEC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7 Guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Appendix A Cryptography - Main concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
A.1 Secret key algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.2 Public key algorithms (PKA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.3 Hash algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.4 MAC or signature and certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

AN5156 - Rev 6 page 52/55

 AN5156
List of tables

List of tables
Table 1. Applicable products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Table 3. Assets to be protected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Table 4. Attacks types and costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 5. Memory types and associated protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Table 6. Scope of STM32 embedded memories protection features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Table 7. Software isolation mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Table 8. Basic feature differences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Table 9. Security features for STM32Fx Series. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Table 10. Security features for STM32Lx and STM32Ux Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Table 11. Security features for STM32H7, STM32G0, STM32G4, STM32WB and STM32WL Series . . . . . . . . . . . . . . . . 29
Table 12. RDP protections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 13. Attributes and access permission managed by MPU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Table 14. Process isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Table 15. Security use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Table 16. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

AN5156 - Rev 6 page 53/55

 AN5156
List of figures

List of figures
Figure 1. Corrupted connected device threat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Figure 2. IoT system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 3. Armv8-M TrustZone execution modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 4. Simplified diagram of dual-core system architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 5. Memory types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 6. Secure boot FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 7. Secure server/device SFU architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 8. Example of RDP protections (STM32L4 Series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 9. TrustZone implementation at system level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 10. HDP protected firmware access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 11. Firewall FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 12. Firewall application example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 13. Dual-core architecture with CKS service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 14. Typical OTFDEC usage in a SoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 15. Symmetric cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 16. Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 17. PKA encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 18. Message hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 19. MAC generation with secrete key algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 20. Signature generation with public key algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

AN5156 - Rev 6 page 54/55

 AN5156

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

AN5156 - Rev 6 page 55/55