ST STM32C0 Series Istruzioni per l'installazione e il funzionamento

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

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

Altri manuali per STM32C0 Series

Questo manuale è adatto per i seguenti modelli

Indice

Altri manuali ST Microcontrollore

ST B-L462E-CELL1 Manuale utente

ST UM2966 Manuale utente

ST STM32F401 Discovery Manuale utente

ST UM2975 Manuale utente

ST UM2708 Manuale utente

ST STM32H7B3I-DK Manuale utente

ST STM32F4 Series Manuale utente

ST STM32Cube Manuale utente

ST STM32WL5 Series Manuale utente

ST STM32F410 Manuale utente

ST STM32H74xI/G Manuale utente

ST Flash ST7 Manuale di servizio

ST UM0250 Manuale utente

ST X-NUCLEO-53L4A1 Manuale utente

ST EVLKST8500GH868 Manuale utente

ST STEVAL-MKSBOX1V1 Manuale utente

ST Sound Terminal STA333W Manuale utente

ST STM32F0 Series Istruzioni per l'installazione e il funzionamento

ST STM32F205 series Manuale utente

ST STM32F2 Series Manuale utente

ST UM2140 Manuale utente

ST STEVAL-BFA001V1B Manuale utente

ST ST624 B-EMU2 Series Manuale utente

Manuali Microcontrollore popolari di altre marche

AMS

AMS AS7261 Demo Kit Manuale utente

Novatek

Novatek NT6861 Manuale utente

Espressif Systems

Espressif Systems ESP8266 SDK Guida all'installazione

Nuvoton

Nuvoton ISD61S00 ChipCorder Guida

STMicrolectronics

STMicrolectronics ST7 Assembler Linker Manuale utente

Texas Instruments

Texas Instruments Chipcon CC2420DK Manuale utente

Lantronix

Lantronix Intrinsyc Open-Q 865XR SOM Manuale utente

NEC

NEC 78GK0S/K 1+ Series Istruzioni per l'installazione e il funzionamento

Mikroe

Mikroe SEMITECH N-PLC Click Istruzioni per l'installazione e il funzionamento

Intel

Intel Agilex Manuale utente

Cypress

Cypress CY4607 HX2VL Manuale utente

DIGITAL-LOGIC

DIGITAL-LOGIC MICROSPACE Manuale utente

Texas Instruments

Texas Instruments TMS320F2837 D Series Manuale utente

CYPRES

CYPRES CY14NVSRAMKIT-001 Manuale utente

Texas Instruments

Texas Instruments INA-DUAL-2AMP-EVM Manuale utente

Espressif Systems

Espressif Systems ESP8266EX Istruzioni operative

Abov

Abov AC33M8128L Manuale utente

Laird

Laird BL654PA Manuale utente