AN5156 · Application noteIntroduction to security for STM32 MCUs
Download .pdfOpen in the full document

Hardware attacks

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.

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.

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 protocols 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.

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 checking 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 examples 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, STM32N6, STM32H7S, STM32WBA, STM32U3, and STM32U5 devices and CCB where featured, the hardware protection in limited in general-purpose microcontrollers. The protection level is reflected by the certification level achieved by the device. See Product certifications for more details).

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.

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.

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® LE or, LoRa®) and sensors and/or actuators (see the Figure 2 IoT system). 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

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.

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.

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 peripheral 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)).
  • Debug authentication (DA)

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

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 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. A 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)