ST STM32C0 Series Installation and operating instructions

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
Microcontrollers
STM32C0 Series, STM32F0 Series, STM32F1 Series, STM32F2 Series, STM32F3 Series, STM32F4 Series,
STM32F7 Series, STM32G0 Series, STM32G4 Series, STM32H5 Series, STM32H7 Series, STM32L0 Series,
STM32L1 Series, STM32L4 Series, STM32L4+ Series, STM32L5 Series, STM32U5 Series, STM32WB Series,
STM32WL Series
Introduction to STM32 microcontrollers security
AN5156
Application note
AN5156 - Rev 8 - March 2023
For further information contact your local STMicroelectronics sales office.
www.st.com

1General information
This document applies to STM32 Arm® Cortex®-core based microcontrollers.
Note: Arm is a registered trademark of Arm limited (or its subsidiaries) in the US and/or elsewhere.
The table below presents a nonexhaustive 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)
DRNG Deterministic random number generator: generates pseudo-random number from input value
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 Nonsecure callable
NVM Nonvolatile 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
AN5156
General information
AN5156 - Rev 8 page 2/56

Term Definition
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
SAU Security attribution unit
SB Secure boot
SCA Side channel attack
SDRAM Synchronous dynamic random access memory
SECDED ECC mode of operation: single error correct, double error detect
SFI Secure firmware installation
SFU Secure firmware update
SPA Simple power analysis
SPE Secure processing environment
SRAM Static random access memory (volatile)
SST Secure storage
STSAFE Secure element product from STMicroelectronics portfolio
SWD Serial-wire debug
TF-M Trusted firmware-M
WRP Write protection
AN5156
General information
AN5156 - Rev 8 page 3/56

Documentation references
The reference manual of each device gives details on the availability of security features. It also informs about
memory protections implementation.
A programming manual is also available for each Arm® Cortex® version and can be used for an 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:
Ref. Doc
number Title Comment
[1] AN4246 Proprietary code readout protection on
STM32L1 series MCUs
Explains how to set up and work with PCROP firmware for the
specified MCUs, provided with the X‑CUBE‑PCROP expansion
package.
[2] AN4701 Proprietary code readout protection on
STM32F4 series MCUs
[3] AN4758
Proprietary code readout protection
on STM32L4, STM32L4+, STM32G4,
and STM32WB series MCUs
[4] AN4968 Proprietary code readout protection on
STM32F72/F73xx MCUs
[5] AN4838 Managing memory protection unit
(MPU) in STM32 MCUs Describes how to manage the MPU in the STM32 products.
[6] AN5185 STMicroelectronics firmware upgrade
services for STM32WB series -
[7] AN5447
Overview of secure boot and secure
firmware update solution on Arm®
TrustZone® STM32 MCUs
-
[8] UM1924 Legacy STM32 crypto library Describes the API of the STM32 crypto library; provided with the
X‑CUBE‑CRYPTOLIB expansion package.
[9] UM2262
Getting started with the X-CUBE-
SBSFU STM32Cube expansion
package
Presents the SB (secure boot) and SFU (secure firmware update)
STMicroelectronics solutions; provided with the X‑CUBE‑SBSFU
expansion package.
[10] AN4730 Using the firewall embedded in
STM32L0/L4/L4+ series MCUs
Describes how to access securely sensitive parts of code and
data
AN5156
General information
AN5156 - Rev 8 page 4/56

2Overview
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 greatest in the case of cryptographic keys or personal data.
The firmware code is also an important asset. If an attacker gains access to the binary, they 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 the case of 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
environmental: 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,
systems built around microcontrollers become potential targets for more and more skilled attackers who expect
financial gains. These gains can be very high, especially if the attack can be propagated to a large scale, as in the
context of the IoT. Even if no system is completely secure, it is possible to make the attack more expensive.
Indeed IoT, or smart devices, have increased 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 the 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
DT50942V1
Unsecure
Device
Unsecure
Device
Device
Device
Device
Device
Device
Device
Services provider
Corrupted system Attack propagation
AN5156
Overview
AN5156 - Rev 8 page 5/56

What must be protected
Security cannot be limited to a certain target or asset. It is difficult to protect data if the code binary is exposed.
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
Data
Sensor data (such as healthcare data or log of positions)
User data (such as ID, PIN, password or accounts)
Transactions logs
Cryptographic keys
Unauthorized sale of personal data
Usurpation
Spying
Blackmail
Control of device (bootloader,
malicious application)
Device correct functionality
Device/user identity
Denial of service
Attacks on service providers
Fraudulent access to service (cloud)
User code
Device hardware architecture/design
Software patent/architecture
Technology patents
Device counterfeit
Software counterfeit
Software modification
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
Security purpose
AN5156 - Rev 8 page 6/56

3Attack 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 it necessary to consider how the device firmware is updated to increase its security
(see Section 5.3.2 Secure firmware update (SFU)).
Secondly, in laboratory conditions with proper equipment, it is possible to retrieve microcontroller content, or even
its design architecture details. These techniques are briefly presented in Section 3.3 Hardware attacks.
From an attacker's point of view, an attack is most 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, the acquisition of the necessary skills by 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. 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. However, 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 noninvasive attacks (carried out at board 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 a new and widely applicable remote attack.
AN5156
Attack types
AN5156 - Rev 8 page 7/56

The table below gives an overview of the cost and techniques used for each type of attack.
Table 4. Attacks types and costs
Attacks
types Software Hardware non–invasive Hardware invasive
-
Scope Remote or local Local board and device level Local device level
Techniques
Software bugs
Protocol weaknesses
Trojan horse
Eavesdropping
Debug port
Power glitches
Fault injection
Side-channels analysis
Probing
Laser
FIB
Reverse engineering
Cost/
expertise
From very low to high,
depending on the security
failure targeted
Quite low cost. Need only moderately
sophisticated equipment and knowledge to
implement.
Very expensive. Need dedicated
equipment and very specific skills.
Objectives
Access to confidential assets
(code and data).
Usurpation
Denial of service
Access to secret data or device internal
behavior (algorithm).
Reverse engineering of the device
(silicon intellectual property)
Access to hidden hardware and
software secrets (flash memory
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 takes 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 nonverified 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
Software attacks
AN5156 - Rev 8 page 8/56

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 to 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 circumvent. 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.
3.3 Hardware attacks
Hardware attacks require a physical access to the device or, often, to several devices in parallel.
The two following types of attacks 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 the protection technology
itself.
AN5156
Hardware attacks
AN5156 - Rev 8 page 9/56

General-purpose microcontrollers are not the best candidates to counter the most advanced physical attacks.
If a highest protection level is required, 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.
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)
• Life-cycle management using product state (where this technology succeeded the RDP)
Serial port 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.
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.
AN5156
Hardware attacks
AN5156 - Rev 8 page 10/56

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 in STM32H5 and STM32U5 devices, the hardware protection in limited in general-purpose
microcontrollers. The protection level is reflected by the certification level achieved by the device.
See Section 5.5 Product certifications for more details).
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-packaging
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).
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.
AN5156
Hardware attacks
AN5156 - Rev 8 page 11/56

Reading the data
When 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
DT50946V1
STM32
Connectivity
Sensors Actuators
AN5156
IoT system attack examples
AN5156 - Rev 8 page 12/56

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 Section 6.2 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
List of attack targets
AN5156 - Rev 8 page 13/56

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 Section 6.2 Readout protection (RDP)).
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
List of attack targets
AN5156 - Rev 8 page 14/56

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 entropy source, or
weaken the statistic randomness of the output.
A robust random generator depends on both the quality of the entropy source (analog) and the subsequent
processing in digital.
•Risk: reduced security of cryptographic protocols
•Countermeasure:
– Use true hardware entropy generator.
– Use tests on the RNG output, and verify statistic properties of produced random numbers.
– Take full advantage of the error detection and heath check mechanisms available on the device RNG.
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 of cryptographic version of the communication stack (like TLS for Ethernet)
AN5156
List of attack targets
AN5156 - Rev 8 page 15/56

4Device 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, used to protect code and data from internal (software) and
external attacks
•Software isolation: inter-processes protection to avoid internal attacks
•Interface protection: used to protect device entry points like serial or debug ports
•System monitoring: detects device external tampering attempts or abnormal behaviors
4.1 Configuration protection
Any persistent security configuration is stored in a dedicated area of the non-volatile memory, called option bytes
(OB). The option bytes are protected with redundancy, and, in case of perceived vulnerability, they are stored as a
“magic value”. Besides rules imposed by security logic (OB can only be changed under specific conditions), there
are rules to determine the default value in case of OB corruption.
Note: Magic value is a pattern of usually 8 bits that must be exactly matched for the value to be recognized as valid,
common examples are 0xB4 or 0xC3 for TRUE or FALSE.
Details about rules to modify the option bytes are detailed in each reference manual. The configuration is
generally frozen by raising the RDP level. Additional rules apply case-by-case.
Each OB value is preconfigured to a reset value in production. This value is usually the least secure, open option.
In case of an error detected in OB loading (OBL, happens on every POR or request), the configuration is set to
a default value. This default value usually sets the highest possible security level to prevent leaking information
from damaged microcontroller.
It is useful to analyze the impact of a configuration error on an application, and to plan for potential recovery.
Highest number of corrupted option bytes however result of errors in programming. If the OB are modified in
controlled environment, the threat of unintentional device locked-up is very low.
4.2 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 resource isolation. These mechanisms, described later in the document, are
robust but not that flexible to allow the concurrent execution of secure firmware together with nonsecure 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) separation for secure and
nonsecure domains and on a bus infrastructure (AMBA®) 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 nonsecure
domain and vice versa is straightforward with few cycle penalties. There is no need for a Secure monitor as in
TrustZone® for application processors Cortex‑A.
AN5156
Device protections
AN5156 - Rev 8 page 16/56

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
DT63687V1
Handler mode
Thread mode
Armv6-M/Armv7-M
Handler mode
Thread mode
Arm TrustZone system security
Armv8-M
Handler mode
Thread mode
Secure Nonsecure
On typical firmware architecture running on Armv8 TrustZone®, the nonsecure domain executes the application
and the OS tasks, while the secure domain executes the secure application and the system root-of-trust
mechanisms.
4.3 Dual-core architecture
In dual-core products, one core can act as secure while the other is nonsecure. 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 runtime 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 the DMA must convey the secure context (refer to the
user manual Getting started with STM32CubeWL for STM32WL series (UM2643) for details about this hybrid
architecture).
Figure 4. Simplified diagram of dual-core system architecture
DT67318V1
AHB
CPU1
nonsecure
MPU
CPU2
secure
MPU
DMA
Flash interface
SRAM
AHB/APB bridge
Bus masters Slaves
Security
controller
AN5156
Dual-core architecture
AN5156 - Rev 8 page 17/56

4.4 Memory protections
Memory protections are of the highest importance when considering system 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
peripheral (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.
The figure below provides a simple view of memories access architecture in a microcontroller.
Figure 5. Memory types
DT50948V1
Flash controller
FMC
NOR/NAND flash
SDRAM
System Flash
memory
Flash
user memory
Bank 1
System Flash
memory
Flash
user memory
Bank 2
Bus masters
(such as CPU or DMA)
SRAM
Octo-SPI or
Quad-SPI
Octo-SPI or
Quad-SPI flash
STM32
microcontroller
OTFDEC
OTP
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
System flash
memory
. Internal
. NVM
. ROM
ROM part of the flash memory. Embeds device
bootloader and other ST services.
Cannot be updated (erase/written).
A part may also be unreadable.
User flash memory . Internal
. NVM Flash memory for user application
Internal protections:
• RDP
• WRP (not for SRAM)
AN5156
Memory protections
AN5156 - Rev 8 page 18/56

Memory Types Description Protections
SRAM
• TrustZone
• PCROP (not for SRAM)
• OTP (not in SRAM)
• Firewall
• Secure hide protection (not for SRAM)
• MPU
. Internal
. Volatile
Working memory for Stack, heap or buffers.
Can be used to execute the firmware
downloaded from internal or external non-
volatile memories.
NAND, NOR, Octo-
or Quad-SPI flash
memory
. External
. NVM
Additional memory for applications or data
storage
Cryptography
Write protection (on Flash device)
TrustZone
SDRAM . External
. Volatile Additional RAM for application execution Cryptography
4.4.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 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.
The protection attribute on the system flash memory cannot be modified.
4.4.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 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 sometimes feature ECC that allows error detection and correction (up to 2-bit error detection
and 1-bit error correction). More considered as a safety feature, it also works as a complementary protection
against fault injection.
4.4.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.
AN5156
Memory protections
AN5156 - Rev 8 page 19/56

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 the 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 must 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 can 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 immediately 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 the reference manual). For
some devices, 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 MCUs only
(refer to Section 6.1 Overview of security features and to the reference manual).
Associated protections: MPU, TrustZone, or SRAM write protection (available on some STM32 devices 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 devices. Integrity protections based on redundancy often cannot be disabled.
4.4.4 External flash memories
The external flash memories are connected to the microcontroller through dedicated interfaces (NAND, NOR,
Octo-SPI, 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
Memory protections
AN5156 - Rev 8 page 20/56