IoT Security
STM32 Security
PV285
Václav Oujezský, Karel Slavíček, Tomáš Pitner
Introduction
̶ Protection of firmware
̶ Protection of private data in the device
̶ Guarantee of a service execution
With IoT, the security extends the requirements for confidentiality
and authentication to communication channels, which often require
encryption.
Why protection is needed
̶ Reverse-engineering
̶ Copy custom algorithms
̶ Flashing or cloning hardware
̶ Denial of service
̶ IoT connected devices build around microcontrollers are very
attractive for hackers
Why protection is needed
̶ A single compromised device can corrupts the integrity of an
entire network!
What must be protected
Attack types
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
Attack types
Software attacks
̶ Malware, takes control of the device or modifies its functionoality
̶ Insider thread: firmware
̶ Must be injected (RAM, flash) and executed by the CPU
̶ Open doors are debug ports (JTAG, SWD), bootloader, external
memory, firmware updates, communication ports.
̶ Buffer overflow or data attacks
̶ Low level languages such as C/C++ are unsafe, can lead to
memory leaks
Brute forcing
̶ Authentication based attacks on a human machine interface
(HMI)
Hardware attacks
Physical access to the device
̶ Invasive attacks: very expensive, direct access to device
silicon (silicon invasive attacks)
̶ Non-invasive attacks (next slides)
Non-invasive attacks
̶ Debug port access or scan chain via JTAG, SWD deactivation
by Readout protection (RDP)
̶ Serial port access (I2C, SPI): software level secure by
encryption, isolation of sensitive data, check the data transfer to
avoid buffer overflow
̶ Fault injection: clock and power disturbance/glitch attacks,
using the device outside the parameters defined in the
datasheet to generate malfunctions in the system.
Fault injection - continue
Countermeasures:
Return values checks, strict branching, using non-trivial values as
true or false and not 0 or -1, for example mutual Hamming distance
If available, use Clock security system (CSS), internal clock, internal
voltage, memory error detection
Non-invasive attacks
Side-channel attacks (SCA)
̶ Observing the device running characteristics such as power consumption,
radiations, temperature, activity time, etc.
̶ Typical attacks are Simple power analysis (SPA) and Differential power
analysis (DPA)
̶ Protecting by session random keys or cryptographic libraries with behavioral
randomization
̶ Hardware protection is reflected by the certification level (product certification)
Device protections
̶ 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
Configuration protection
Persistent security configuration is stored in a dedicated area of the
non-volatile memory, called option bytes (OB).
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 case of an error detected in OB
loading, 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.
RDP
The STM32F0 and STM32F1 microcontroller series from STMicroelectronics incorporate different
security features to protect their firmware, reflecting an evolution in approaches to securing embedded
systems.
̶ STM32F0: This series permanently disables the debug interface to prevent unauthorized access
through debugging tools. This method provides a straightforward way to secure the chip from
firmware extraction or manipulation through standard debug protocols like JTAG or SWD (Serial
Wire Debug).
̶ STM32F1: Unlike the F0, the F1 series retains an enabled debug interface, which is often crucial
for legitimate development and troubleshooting purposes. To safeguard the firmware, STM32F1
uses flash memory read-out protection (RDP). This protection mechanism is designed to prevent
external devices from reading the flash contents. However, this method has vulnerabilities.
Dual-core architecture
In systems like the STM32WL, one core can operate in a secure mode, while the other
operates in a non-secure mode. This separation allows sensitive tasks and data to be handled
by the secure core, isolating them from less critical operations that the non-secure core
handles.
Memory protection
̶ Firewall
̶ Flash controller
̶ PCROP - proprietary code
read-out protection feature
̶ WRP - write protection
̶ RDP
https://www.st.com/en/embedde
d-software/x-cube-pcrop.html
Debug port and interface protection
STM32 features:
̶ read protection (RDP)
̶ disable of unused ports
̶ bootloader access forbidden (configured by RDP in STM32
devices)
Boot protection
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).
STM32 features:
̶ read protection (RDP)
̶ unique boot entry
̶ secure hide protection (HDP)
̶ TrustZone
Security features
Readout protection (RDP) in detail
It 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.
The RDP applies to all STM32 devices for:
̶ the main flash memory
̶ the option bytes (level 2 only)
Depending on the STM32 device, additional protections are available, including:
̶ backup registers for real-time clock (RTC)
̶ backup SRAM
̶ nonvolatile memories
Readout protection (RDP) in detail
̶ Level 0 (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: 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.
RDP level regression
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 nonsecure part is erased.
̶ Regression from 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, with exception of preconfigured OEM keys in STM32Ux series, no
regression is possible.
RDP protection
LAB RDP
LAB: RDP https://stm32world.com/wiki/STM32_Readout_Protection_(RDP)
̶ Review STM32 RDP levels and their impact on access to memory.
̶ Use STM32CubeProgrammer to apply different RDP levels to an
STM32 microcontroller and observe the outcomes.
̶ Discuss the process and implications of changing from RDP Level
1 to Level 0, emphasizing the data loss that occurs