Practical Software Countermeasures 4 Hardware Glitch Attacks- Arshid & Chinmay

Practical Software Countermeasures 4 Hardware Glitch Attacks

Speakers: Arshid, Hardware Security & Cloud Security Engineer, Siemens Technology; Chinmay, Master's Student, IIIT Bangalore

Conference: Nullcon

YouTube: https://www.youtube.com/watch?v=lGY7x0T5YCo

Overview

In an era where software vulnerabilities often dominate security discussions, the realm of hardware security presents a distinct and increasingly critical challenge. This talk, "Practical Software Countermeasures 4 Hardware Glitch Attacks," delivered by Arshid and Chinmay, delves into the often-overlooked threat posed by physical attacks on embedded systems. Specifically, it focuses on fault injection attacks, where an attacker manipulates the physical environment of a device—such as its power supply or clock signal—to induce transient errors in its operation, thereby bypassing security mechanisms like password checks or secure boot.

The speakers highlight the growing importance of understanding and mitigating these hardware-level threats, particularly given the pervasive nature of embedded systems in critical infrastructure, IoT devices, and consumer electronics. While hardware-based countermeasures exist, they often entail significant redesign costs and are impractical for devices already deployed in the field. This presentation champions the exploration of software countermeasures, demonstrating how strategic modifications to firmware can significantly bolster a device's resilience against sophisticated glitch attacks without necessitating costly hardware revisions.

The talk is particularly relevant for embedded system developers, security architects, and anyone involved in securing hardware-dependent applications. It provides practical insights into how even minimal, well-placed software changes can drastically reduce the success rate of fault injection attempts, offering a cost-effective and adaptable approach to enhancing the security posture of existing and future embedded products.

Background

▶ Watch: Introduction to software countermeasures for hardware glitch attacks (0:00)

Hardware glitch attacks represent a class of physical attacks that aim to subvert the intended behavior of a system by manipulating its operational environment. Unlike software exploits that target logical flaws, glitch attacks exploit the physical characteristics of integrated circuits. The core principle involves inducing a transient fault that causes the processor to misexecute an instruction or corrupt data, leading to a bypass of security controls.

The speakers primarily focus on voltage glitching, a common and relatively accessible fault injection technique. This method involves briefly dropping the supply voltage to a device for a very short duration. The challenge lies in applying a glitch that is long enough to induce a fault but short enough not to cause permanent damage or trigger a system reset. Precision in timing is paramount, as the glitch must coincide with a critical operation within the processor's pipeline. Advanced glitching techniques also include clock glitching (manipulating the clock signal), optical injection (using lasers to induce faults), and electromagnetic fault injection (EMFI).

To understand the operational boundaries for glitching, the concept of a Shmoo plot is introduced. This plot maps a device's operating voltage against its frequency, delineating regions of safe operation (green), potential damage/reset (red), and the critical "yellow" region where glitches can be successfully induced without permanent damage. Within this yellow region, a brief voltage drop (e.g., from 3.2V to 0.8V) can cause a processor to deviate from its intended execution.

The impact of a glitch on a processor, such as the widely used Cortex-M4, can occur at various stages of its pipeline:

• Instruction Fetch: The instruction itself might not be fetched correctly.
• Instruction Decode: The fetched instruction might be misinterpreted.
• Instruction Execution: During execution, registers might be read incorrectly, or data on the memory bus might be corrupted. This can lead to instruction skipping, where a critical instruction (e.g., a conditional branch for a security check) is effectively ignored.

The speakers utilized a fault injector kit for their study, specifically the ChipWhisperer-Lite with an STM32 F3 microcontroller as the target. This setup allows for repeatable and precise fault injection experiments, simplifying the process compared to manually modifying device components (e.g., removing decoupling capacitors on an Arduino board, as shown in a demonstration). The workflow involves the target firmware sending a trigger signal to the fault injector, which then applies the glitch at the precise moment.

A common target for glitch attacks is bypassing authentication. The talk illustrates this with a simple C code example for a password check. At the assembly level, a glitch can skip the conditional branch that verifies the password. By doing so, an attacker can trick the system into believing a correct password was entered, granting unauthorized access. The demonstration video shows this in action: an Arduino board, glitched by a ChipWhisperer, repeatedly fails password attempts until a successful glitch allows "Logged In" status without the correct password.

Key Findings

▶ Watch: Schmoo plot explains safe vs. glitching operating regions (4:00)

The talk meticulously explores the dichotomy between hardware and software countermeasures for glitch attacks, ultimately advocating for a strong focus on the latter due to practical constraints. While hardware-based countermeasures such as brownout detection circuitry, clock and power integrity checks, shadow registers, and hardware-based pointer authentication offer robust protection, they come with significant drawbacks. These include long redesign lead times, high implementation costs, and, crucially, the inability to apply them to products already deployed in the market. This makes hardware modifications largely unsuitable for "brownfield" projects or post-deployment security enhancements.

The core finding is that software countermeasures, despite addressing a physical attack vector, can be remarkably effective and offer a more agile, cost-efficient solution. The speakers categorize these into several approaches:

• Redundant Computation: Performing critical checks multiple times to ensure that if one instance is glitched, another catches the anomaly.
• Timing Randomization: Introducing variability in the execution timing of critical code sections, making it harder for an attacker to precisely time their glitches.
• Control Flow Integrity (CFI): Implementing checks to ensure the program's execution flow remains as intended, halting operations if instruction skipping or unexpected jumps are detected.
• Runtime Integrity Checks: Verifying the integrity of variables or code segments during execution.

The research presented primarily falls under the umbrella of redundant computation and careful code structuring. The key discovery is that even subtle changes in how firmware is written can dramatically alter its resilience to glitch attacks. The study demonstrates that simple, targeted modifications—often involving just a few lines of code or a single keyword—can reduce glitch success rates from over 80% to near zero. Conversely, seemingly logical code changes, if not carefully considered from a fault injection perspective, can inadvertently make a system more vulnerable, as evidenced by the "negation of logic" example which amplified attack success rates by orders of magnitude. This underscores the critical importance of understanding how compilers and hardware interact with high-level code when designing glitch-resistant firmware.

Technical Deep Dive

▶ Watch: Glitches corrupt Cortex M4 instruction fetch, decode, execute (6:00)

The technical deep dive into software countermeasures commenced with an analysis of a standard, vulnerable password checking function in C, designed for an embedded system. The function compares an input password character by character against a stored password ("touch" in this case) within a for loop. If any character mismatch is found, a pass_ok flag is set to zero, and the loop breaks. The critical section for glitching is the conditional branch where password[CNT] is compared to input_password[CNT]. A successful glitch here, particularly during the final iteration, could skip the comparison or corrupt the pass_ok flag, leading to unauthorized access. The baseline tests showed high glitch success rates, with the attacker gaining access 221 times within a 10-minute test period.

The speakers then presented several software modifications and their impact on glitch success:

1. Volatile Keyword:

• Change: The loop counter variable CNT was changed from int CNT to volatile int CNT.
• Mechanism: The volatile keyword instructs the compiler (e.g., GCC) not to optimize access to this variable. Normally, a compiler might optimize loop counters by keeping them in a CPU register for faster access. By declaring CNT as volatile, the compiler is forced to load CNT from main memory (e.g., RAM) in each iteration.
• Impact: Loading from main memory is inherently slower and introduces more variable timing due to factors like bus interconnects and memory access latency. This increased timing variability makes it significantly harder for an attacker to precisely time a glitch to affect the specific instruction related to CNT or the subsequent comparison.
• Result: Glitch success rates dropped dramatically, showing 1, 0, and 0 successful bypasses in subsequent tests, a substantial improvement from the baseline.

1. Duplication:

• Change: The original stored password was duplicated into a second variable, pw1. An additional strcmp was added at the beginning of the critical section to compare the original password with its duplicate pw1.
• Mechanism: This introduces redundant computation. If a glitch occurs during the loading or comparison of these two identical passwords, it's highly probable that one of them will be corrupted. If this initial strcmp fails, the system immediately knows a fault has occurred and can prevent entry into the main password verification logic. This "clutter" around the critical section increases the chances of a glitch hitting a non-critical instruction or corrupting data before the actual bypass attempt.
• Result: This method also showed a tremendous reduction in glitch success rates (e.g., 1, 0, and 0 bypasses).

1. Inversion:

• Change: Instead of direct duplication, the password was stored in an inverted form (e.g., bitwise NOT or character-wise inversion) in a separate variable. An initial check would then verify the integrity of the original and inverted passwords.
• Mechanism: Similar to duplication, this adds redundancy and complexity. If the original password is touch, the inverted version would be ~touch. A fault affecting one of these values would likely make them inconsistent, triggering an early failure. This significantly increases the required precision for a successful multi-glitch attack to bypass both the inversion check and the main password comparison.
• Result: Zero successful glitches were observed across all three attempts.

1. Masking:

• Change: The password was "masked" by multiplying it with a constant (e.g., 5) and stored. Before comparison, the inverse operation (division by 5) would be performed to retrieve the original password.
• Mechanism: This is another form of redundant computation and data obfuscation. A glitch could corrupt the masked value or the constant, making the unmasking operation fail or produce an incorrect password, leading to an early detection of a fault.
• Result: This method also proved to be very glitch resistant, showing zero successful bypasses.

The Catastrophic Case: Negation of Logic

A crucial part of the deep dive was demonstrating how seemingly benign code changes can severely compromise security.

• Original Vulnerable Logic:

• Negated Logic (Highly Vulnerable):

In the negated logic, an attacker who doesn't know the password will always enter the else case, setting pass_ok = 0 and then breaking. If a glitch occurs specifically when pass_ok = 0 is being written to memory, and it flips just one bit, pass_ok could become 1. Since the loop then immediately breaks, the system would proceed as if the password was correct.

• Explanation: This vulnerability stems from two factors: the single point of failure (a single bit flip on pass_ok) and the early termination via break. The lack of strong failure handling (e.g., re-checking pass_ok after the loop) and the ability to exploit a single fault made this version catastrophically insecure.
• Result: This negated logic made it tremendously easier for attackers, resulting in an astounding 7,172 successful bypasses in just 10 minutes, far exceeding the baseline's 221 attempts.

The comparative results clearly illustrated that while simple software changes can yield significant gains in glitch resistance, the way these changes are implemented and the underlying logic are paramount. The summary table provided a stark comparison:

• Negation of Logic: 7,172 successes
• Simple Password Checker (Baseline): 221 successes
• Volatile: 1 success
• Duplication: 0 successes
• Inversion: 0 successes
• Masking: 0 successes

These results underscore that secure coding practices, when applied with an understanding of hardware fault injection, can provide robust and practical defenses.

Demo / Proof of Concept

▶ Watch: Fault injector kits simplify hardware glitch attack testing (8:00)

The talk included a compelling video demonstration illustrating a basic password bypass using voltage glitching against an embedded system. The setup comprised an Arduino board, a ChipWhisperer-Lite fault injector, and a breadboard. The speakers explained the necessity of carefully preparing the target device: the microcontroller IC was removed from its original Arduino board and placed on a breadboard. This modification was crucial because the decoupling capacitors typically present on the Arduino board would interfere with the precise voltage drops required for effective glitching.

The demonstration code running on the Arduino was a simple password authentication routine. Before the critical section of the code responsible for comparing the input password with the stored one, an external trigger signal was sent from the Arduino to the ChipWhisperer. This trigger precisely informed the fault injector when to apply a voltage glitch.

In the video, the attacker (Chinmay) attempts to log in with an incorrect password. Initially, the serial output repeatedly displays "Invalid password," indicating the system's normal, secure operation. The ChipWhisperer then initiates a series of voltage glitches, attempting to disrupt the microcontroller's execution at the critical authentication check. After numerous "Invalid password" attempts, a successful glitch eventually occurs. The system's output then unexpectedly displays "Logged In," demonstrating that the password check was bypassed without the correct credentials. This practical proof of concept vividly illustrated how a well-timed hardware fault could subvert software-based security, setting the stage for the subsequent discussion on software countermeasures.

Defensive Implications

▶ Watch: ChipWhisperer-Lite setup and glitching assembly instructions (10:00)

The findings presented in this talk have profound implications for defenders of embedded systems. The primary takeaway is that software countermeasures are not merely academic concepts but highly practical and often essential tools in the fight against hardware glitch attacks. Given the economic and logistical challenges associated with hardware redesigns (long lead times, high costs, and impossibility for deployed products), software-based mitigations offer a flexible and potent alternative.

Defenders should recognize that even minimal code changes can yield significant security gains. The examples of using the volatile keyword, duplication, inversion, and masking demonstrated how simple modifications to critical code sections can drastically reduce the success rate of fault injection attacks. This means that existing firmware can often be retrofitted with enhanced glitch resistance without requiring a complete overhaul.

However, the "negation of logic" example serves as a critical warning: the way code is written, even with seemingly logical alterations, can inadvertently introduce severe vulnerabilities. Defenders must adopt a security-conscious mindset, understanding how compiler optimizations, instruction pipelines, and fault injection techniques interact with their high-level code. This necessitates a detailed analysis of critical sections, particularly those involving authentication, authorization, and data integrity, to identify potential single points of failure that could be exploited by a single bit flip or instruction skip. Strong failure handling and avoiding early termination in security-critical loops are paramount.

For practical implementation, defenders can leverage existing open-source resources and libraries:

• ARM Trusted Firmware-M (TF-M) FIH Library: This library, part of ARM's trusted firmware project, provides examples and primitives for implementing fault injection hardening, making it easier for developers to integrate robust countermeasures.
• glitch-resistor: An open-source tool designed to help identify and mitigate glitch vulnerabilities.
• Chip Armor Library: Developed by NewAE Technology (the creators of ChipWhisperer), this library offers further support for building glitch-resistant firmware.

The adoption of glitch-resistant firmware is also gaining traction in the industry. The speakers highlighted WolfBoot, WolfSSL's bootloader, which actively advertises its glitch resistance. This indicates a growing awareness and commitment within the embedded security community to address these physical attack vectors through software. By studying such open-source implementations, developers can glean best practices and integrate similar protections into their own products.

In summary, defenders should prioritize:

1. Auditing critical code sections for susceptibility to instruction skipping or data corruption.
2. Implementing redundant checks for sensitive operations and data.
3. Using the volatile keyword for loop counters or critical variables to deter timing-based attacks.
4. Avoiding insecure coding patterns that create single-fault bypasses.
5. Leveraging established libraries and tools for fault injection hardening.
6. Considering software countermeasures as a viable and often preferred solution for both new designs and existing deployments, especially when hardware modifications are unfeasible.

Key Takeaways

• Hardware faults can be mitigated logically: Physical glitch attacks can be effectively countered through strategic software modifications, proving that defenses don't always need to be at the hardware level.
• Minimal code changes yield significant gains: Small, targeted alterations to firmware, such as using the volatile keyword or adding redundant checks, can drastically improve a system's resilience to glitch attacks.
• Code structure is paramount: The way code is written directly impacts its glitch resistance. Seemingly logical code changes can introduce severe vulnerabilities if not evaluated from a fault injection perspective (e.g., the "negation of logic" example).
• Leverage existing tools and libraries: Resources like ARM's TF-M FIH Library, glitch-resistor, and Chip Armor provide valuable starting points and examples for implementing robust software countermeasures.
• Software is ideal for brownfield projects: For deployed systems where hardware modifications are impossible or too costly, software countermeasures offer a practical and cost-effective approach to enhance security.
• Redundant computation is a key strategy: Techniques like duplication, inversion, and masking of critical variables add complexity and redundancy, making it significantly harder for an attacker to achieve a successful bypass with a single, precisely timed glitch.

About the Speaker(s)

Arshid is a Hardware Security and Cloud Security Engineer at Siemens Technology. His expertise spans critical areas of cybersecurity, having previously contributed to India's government cyber security firm, NCPC, and the Indian Space Research Organization, where he focused on secure embedded systems. His background provides a robust foundation in both theoretical and practical aspects of securing complex hardware and cloud infrastructures.

Chinmay is currently a Master's student at IIIT Bangalore. He is relatively new to the field of security, with his first experience being an internship at Siemens Technology, which explains his collaboration on this talk. His primary background is in Electronics, specializing in digital VLSI design, ASICs, and FPGAs, alongside experience in embedded systems. This blend of hardware design knowledge with a burgeoning interest in security brings a unique perspective to the challenges of securing embedded devices.