Embedded-systems designers regularly need to store sensitive information, such as cryptographic keys, user data, proprietary algorithms, and other forms of intellectual property within firmware. To prevent the malicious extraction of sensitive information stored within microcontrollers (MCUs), many MCUs implement functionality known as readback protection or readout protection. This restricts the reading of internal storage through debug or programming interfaces.
However, these features aren’t infallible—lots of MCUs contain design flaws that allow for the bypassing of readback protection. Embedded developers also commonly misconfigure readback protection, misunderstand vendor documentation, or undermine readback protection through unintentionally permissive firmware functionality. Furthermore, even when correctly implemented and configured, readback protection can often be defeated by techniques such as fault injection and invasive silicon attacks. It’s important for designers to be aware of these limitations to accurately evaluate business risk.
One common mistake is not selecting a microcontroller that provides sufficient security to meet design requirements. This generally arises due to misunderstanding the security features offered by a MCU, being unaware of flaws in an MCU’s security features, or not adequately defining security requirements during the component selection phase.
Attempts to implement readback protection on microcontrollers not designed to provide such protections are bound to fail. They usually involve trying to disable debugging interfaces (such as JTAG or SWD) through pin reassignment or disconnection of pins at the circuit-board level. Generally, these approaches don’t work.
Flawed Security Features
When debugging interfaces are restricted rather than disabled altogether on ever-more complex modern MCUs, there are countless ways for microcontroller vendors to inadvertently introduce logical holes that enable readback protection to be bypassed. Every year, new attacks allow for bypassing of flawed readback-protection implementations on microcontrollers. Usually, these attacks are only made possible by debugging interfaces being partially restricted rather than disabled altogether.
One such case involves the PALL (Protect All) feature of the popular Nordic nRF51 series of wireless communications MCUs. When this feature is enabled, it prevents debugger access to the memory addresses of flash and RAM. However, it doesn’t restrict CPU register access. Readback protection can be defeated by observing changes to register values while forcing the repeated execution of load instructions, where the address being read is a CPU register.
Another high-profile flaw published by Johannes Obermaier and Stefan Tatschner involves the STM32F0 series microcontrollers in RDP (ReaDout Protection) Level 1. In this mode, access to specific memory ranges is blocked, but the debug interface remains active. Debugger access restrictions only become active after two system bus clock cycles following the start of the first bus access by the debugger, which introduces a race condition.
In times of low system bus load, one word of data can be read through the debugging interface before restrictions take effect. By repeatedly resetting the processor and reading one word at a time, it’s possible to read out the entire memory contents of the microcontroller.
Similar flaws are routinely found for all major microcontroller brands. When selecting components and evaluating the effectiveness of readout protection measures, it’s important to research attacks that have been published against the microcontroller. Most published logical attacks can be thwarted by a complete disablement of the debugging interface, if permitted by the MCU. Even when vulnerabilities haven’t yet been published against a specific MCU, it’s best to disable debugging interfaces altogether for defense-in-depth, in case logical flaws are discovered in the future.
On many embedded systems, readback protection is undermined by insecure firmware or bootloader functionality. In some cases, this is caused by intentional functionality with poorly considered consequences; in other cases, it’s defeated by exploiting a memory safety vulnerability in code.
Bootloaders and firmware often include diagnostic functionality to facilitate development, device testing, and repair. Examples of such functionality include commands to read and write RAM, flash, and registers; commands to view and alter device configuration; commands to run hardware self-tests; and commands to execute arbitrary code. While this can be helpful for development, testing, and repair, it can also be used to bypass readback protection.
Bootloaders and firmware typically restrict such diagnostic functionality while providing a “backdoor” mechanism to re-enable it for failure analysis and repair. This represents another common weakness. Shared fixed passwords should not be used as authentication to re-enable diagnostic functionality—they are a single point of failure if exposed, and in some cases also violate laws on IoT device security. Even when unique passwords or challenge-response authentication is used, it may be possible to conduct brute-force attacks through precise processor resets, or obtain information through side-channel leakage, such as current consumption or response timing.
Bootloaders and firmware with memory safety vulnerabilities are also commonly exploited and can be used to defeat readback protection. Many embedded systems perform complex parsing and processing of external inputs using non-memory-safe languages, most commonly C. Flaws in parsing and processing logic can introduce bugs that allow memory disclosure or memory corruption. Memory corruption may be exploitable to obtain arbitrary code execution, which can then be used to exfiltrate memory contents.
Advanced Attack Techniques
Even without hardware or software flaws, it’s possible to defeat readback protection on any microcontroller. No matter how well readback protection is implemented, systems designers must be aware that memory contents can be read by a capable and well-funded attacker. However, some MCUs can provide higher levels of resistance to advanced attack techniques.
Fault injection is a simple and cost-effective technique that can be employed to defeat readback protection on many microcontrollers. The goal is to induce the skipping or improper evaluation of a security-critical CPU instruction. Many MCUs contain a boot ROM that reads configuration from flash and configures security features prior to the execution of the reset vector in user code. Skipping instructions in the boot ROM can re-enable debug interfaces that were configured to be restricted or disabled. Also, fault injection can be used to skip security-critical CPU instructions in bootloaders and firmware.
There are several forms of fault injection, including voltage glitching, clock glitching, electromagnetic fault injection, and optical fault injection. In a voltage-glitching attack, the most popular tactic, the supply voltage to a microcontroller is momentarily lowered during a target instruction. This may cause instruction fetch to fail and lead to incorrect output from the CPU’s arithmetic logic unit (ALU). Voltage glitching attacks can be carried out with low-cost equipment, even under $10, such as another MCU together with a MOSFET and a few resistors.
Purpose-built and high-security MCUs, such as those used in secure elements and smart cards, often include countermeasures against fault injection. They often have precise and fast-reacting voltage monitoring to detect voltage glitching and force a CPU reset. They also typically include internal clock generation to prevent clock glitching. However, the more advanced techniques of electromagnetic and optical fault injection may still be effective against such microcontrollers.
The most powerful attacks against MCUs use invasive methods. These directly attack the silicon in MCUs, after decapsulation through the mechanical removal or dissolution of chip packaging. Invasive attacks can use a focused ion beam (FIB) to alter the behavior of processors by depositing or removing lines, and such techniques can be employed to forcibly re-enable debug interfaces or disable readback protection. However, the costs to conduct invasive attacks with a FIB are much higher than attacking logical hardware flaws or exploiting software vulnerabilities. (Semi-invasive optical attacks are also possible after decapsulation.)
Conclusions
All microcontroller readback protection mechanisms can be defeated with sufficient resources and effort. However, careful component selection, configuration, and firmware development may raise the cost of attack to prohibitive levels. While no MCU can fully resist invasive attacks, specially designed high-security MCUs offer mechanisms to fully disable debugging interfaces and prevent fault injection attempts.
Even when a secure MCU is used, it’s still important to prevent readback protection from being undermined by poorly designed firmware or bootloader functionality. An external audit of component selection, configuration, and firmware can identify weaknesses in your embedded devices and provide guidance to improve the effectiveness of readback protection.
For more information on attacks against readback protection, and guidance to defend against these attacks, see the NCC Group white paper at https://research.nccgroup.com/wp-content/uploads/2020/02/NCC-Group-Whitepaper-Microcontroller-Readback-Protection-1.pdf
Sultan Qasim Khan is Senior Security Consultant at NCC Group.