Watch Your (Lock)Step: Glitching into Automotive Processors

## Overview Modern vehicles contain numerous interconnected electronic control units (ECUs), ranging from infotainment systems to critical components such as engine control units, brake-by-wire modules, and steering column controllers. Failures or bit flips in these safety-critical systems can cause life-threatening outcomes (e.g., unintended acceleration or steering loss). Under ISO 26262 Automotive Safety Integrity Level (ASIL) D, hardware must detect or mitigate random faults within a defined fault-tolerant time interval (such as within a millisecond). Because harsh automotive environments—including 120V alternator load dumps, 25,000V spark plug ignition pulses (around 100 per second on a V6), and starter solenoid noise—frequently induce single event upsets (SEUs), automotive microcontrollers rely on hardware safety mechanisms like lockstep to maintain operational integrity.

## Mechanics of Lockstep Execution Lockstep is primarily designed as a functional safety feature rather than an intentional hardware security control. - **Operation:** The core ALU logic is duplicated. A primary core and a secondary checker core receive identical instruction streams and operands. - **Cycle Delay:** Execution on the secondary core is intentionally offset (for example, delayed by roughly two clock cycles on Infineon TriCore processors). - **Comparison & Fault Handling:** After completion, comparison logic inspects register states, inputs, and outputs across both cores. If divergence is observed—the assumption being that an environmental transient hit only one core—the processor triggers an error-handling routine. - **Architectural Scope:** Lockstep duplicates the CPU execution core/ALU, leaving external peripheral paths, instruction fetches, and memory buses separate.

## Target Hardware and Test Setup To evaluate the resistance of lockstep systems against intentional fault injection (glitching), the research examined automotive microcontrollers: - **Target Microcontrollers:** Infineon TriCore family (specifically the TC200/TC275 series, alongside notes on the TC300 and TC400 series), which power approximately half of global ECUs and feature custom instruction set architectures with hardware lockstep and ECC. - **Test Firmware:** A sensitive benchmark loop (adapted from Colin O'Flynn) utilizing three incremented integers inside nested loops. Any skipped execution cycles or corrupted variable writes trigger an altered output state (`X` for glitch success vs. `N` for normal run). - **Hardware Modifications:** On the TC275 development board, decoupling capacitors on the core voltage supply rail regulator were removed to ensure sharp, fast voltage drop edges. - **Glitching Tooling:** The setup paired a Raspberry Pi Pico driving a MOSFET (the open-source *Faulter* board) or a ChipWhisperer for voltage fault injection, controlled by a Python/Jupyter automation harness to sweep delay intervals and pulse widths.

## Key Findings and Observations - **Vulnerability Under Full Safety Configurations:** Even with lockstep, ECC, and hardware safety monitors fully active, the TriCore processor was successfully glitched via voltage fault injection, yielding corrupt loop outcomes without triggering lockstep-induced halts. - **Safety vs. Security Distinction:** Lockstep is engineered around the premise of accidental, transient single event upsets in the ALU. Because surrounding subsystems (such as bus interfaces and memory writes) are not mirrored in the same lockstep domain, targeted physical attacks can bypass the comparator mechanism. - **Electromagnetic Fault Injection (EMFI):** Beyond voltage glitching, EMFI techniques (using a ChipSHOUTER and localized coils over an automated XYZ stage) demonstrate that spatial and timing brute-force exploration can induce targeted faults in automotive MCUs without core parity logic preventing the exploit.