Clock Glitching to Skip a Security Check
Clock glitching is fault injection’s other classic technique. Instead of disturbing the power supply, it feeds the chip a deliberately malformed clock, inserting an edge too fast for the logic to settle. The result is the same as a voltage glitch: a corrupted or skipped instruction, and sometimes a security decision that flips the wrong way.
The Idea, and the Logic Underneath
A processor advances one step per clock edge, and it trusts that each edge leaves enough time for the combinational logic to settle to a correct value before it is latched. Clock glitching breaks that trust by slipping in an extra edge too soon, so the chip latches a half-finished, wrong result and carries it forward as if it were correct. That single corrupted step is the whole attack.
Because the effect depends on exactly when the early edge lands relative to the instruction being executed, the attack is a timing problem. Land the glitch on a NOP and nothing useful happens; land it on the conditional branch after a signature check and the chip may take the success path despite a failed check. Fault injection is the art of landing that corruption on the one instruction that matters.
Clock Glitching Versus Voltage Glitching
The two techniques achieve the same end through different means, and which one a device is exposed to comes down to its clock:
| Clock glitching | Voltage glitching | |
|---|---|---|
| What it manipulates | The clock line directly | The power rail |
| Works on | Parts with an external clock you can reach | Any part, including internal oscillators |
| The tell | An external crystal or clock chip into the CPU | The clock line is not exposed |
| Main defense | Internal clock and a clock-integrity monitor | Voltage monitors and redundant checks |
Attackers pick whichever the target hands them. A board with an external crystal feeding the CPU invites clock glitching, because the clock is right there to manipulate; a part with an internal PLL forces the move to voltage glitching. Knowing which clock source a device uses tells you immediately which technique it is exposed to.
Identify the Clock Source First
Before attempting anything, determine where the processor gets its clock, which the datasheet and the board together reveal. An external crystal or a clock chip with a trace into the CPU is the signature of a clock-glitching target.
# from the board + datasheet: what drives the CPU clock?
- external crystal Y1 (8 MHz) into OSC_IN/OSC_OUT -> external clock, glitchable
- or: internal RC/PLL, no external clock pin -> use voltage glitching instead Finding an external clock feeding the CPU means the clock line can be cut and replaced with a glitched signal; finding only an internal oscillator means there is nothing external to manipulate, and the attacker reaches for a voltage glitch instead. That one observation decides the approach.
Building the Glitch
A glitch platform like the ChipWhisperer generates the malformed clock: a normal clock with one extra edge inserted at a controlled offset after a trigger, usually reset or a recognizable point in execution. The parameters are the offset to the target instruction and the width of the inserted edge.
# chipwhisperer: clock glitch, one early edge a fixed offset after the trigger
scope.glitch.clk_src = 'clkgen'
scope.glitch.trigger_src = 'ext_single'
scope.glitch.width = 8 # how early the extra edge arrives
scope.glitch.ext_offset = 2200 # cycles after trigger -> the target instruction
scope.io.hs2 = 'glitch' # route the glitched clock to the target The whole game is the offset and the width. The offset has to place the bad edge on the handful of cycles where the chip executes the security-critical instruction, and the width has to be just enough to cause a fault without resetting the chip. Both are found by searching.
Finding the Window by Sweeping
You rarely know the exact target cycle up front, so you sweep the offset across the plausible window and test the outcome on each attempt. A result that should be impossible, an accepted bad signature, an unlocked state, marks a successful glitch and the offset that produced it.
# sweep the glitch offset and watch for the check to be skipped
for off in range(2100, 2400, 2):
scope.glitch.ext_offset = off
target.reset(); arm_and_send_bad_input()
if target_accepted(): # the check was skipped
print("WIN at offset", off)... offset 2206: rejected (check held) WIN at offset 2208 ... offset 2210: reset # offset 2208 reliably skips the comparison
When one offset starts producing the impossible outcome, the window is found and the glitch becomes repeatable. The search can take many attempts, but once tuned for a chip and firmware, the same offset works on every unit of that build, which is why a single success scales.
What It Defeats
The prize, as with voltage glitching, is a single security decision. A signature check, a debug-lock read, a password comparison, a secure-boot verdict, any of these can come down to one branch instruction, and the classic vulnerable shape is a verify-then-branch where one conditional decides everything:
// fragile: one comparison, one branch decides everything
if (verify_signature(img) != OK) // glitch the compare or the branch...
halt(); // ...and this never executes
run(img); // attacker's unsigned image runs A single glitch that skips the comparison or the branch to halt drops the chip straight into running the unsigned image. The verification function may have worked perfectly; it did not matter, because the one instruction that acted on its result was corrupted. The attack does not break the math, it skips the step that was supposed to enforce it.
Hardening against It
No single measure makes clock glitching impossible, so the goal is to make one successful glitch insufficient, by combining a few defenses:
- Run from an internal clock. An internal oscillator or PLL removes the external clock line clock glitching needs; it does not stop voltage glitching but closes the easier door.
- Enable the clock security system. Many parts detect an absent or out-of-range external clock and switch to a safe source, so a cut or manipulated clock trips a fault response instead of a clean glitch.
- Detect abnormal edges. A clock-integrity monitor that flags edges arriving faster than the configured frequency turns many glitch attempts into detected resets rather than silent corruption.
- Use redundant, fail-closed checks. The most portable defense lives in firmware: verify critical conditions more than once, in separated code, so one glitch skips at most one of them.
// resilient: check twice, in separated code, and fail closed if (verify_signature(img) != OK) halt(); do_other_work(); // separation in time if (verify_signature(img) != OK) halt(); // a single glitch skips only one run(img);
A single value that says authorized is fragile; several independent confirmations separated in time are not, because one glitch lands on at most one of them. That pattern, plus failing closed so a skipped check leaves the device locked, is what makes firmware survive a fault it cannot prevent.
Knowing Your Exposure
Whether clock glitching applies at all comes down to the hardware: it needs access to the clock the processor runs from, so a device driven by an external crystal is exposed in a way an internally clocked part is not. The defender’s practical step is to walk the firmware, find every place where one comparison decides something important, and ask what happens if that one instruction is skipped; if the answer is the device unlocks, runs unsigned code, or exposes a secret, that decision needs the redundant, fail-closed treatment before the product ships. Assume the attacker can inject one fault, and design so that one fault is not enough.
Where This Fits
Assessing a device’s exposure to fault injection, and whether its critical checks survive a glitch, is part of a thorough hardware penetration test. If you want your clocking and your security-critical checks reviewed the way an attacker would test them, that is the kind of work we do at Berkner Tech.
