Clock Glitching to Skip a Security Check

Clock glitching an embedded processor to skip a single security check by inserting a fast clock edge

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 in One Sentence

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. If the step it corrupts happens to be the comparison that decides whether a signature is valid, or whether a password matched, the chip can be made to act on a wrong answer. Fault injection is the art of landing that corruption on the one instruction that matters.

How It Works at the Logic Level

Inside the chip, an instruction’s result has to propagate through gates before the next clock edge captures it. The clock period is sized so that even the slowest path settles in time. A glitch edge arrives early, before a path has settled, so the latch captures an intermediate value: a register that did not finish updating, a comparison that did not complete, a branch that takes the wrong direction.

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. The precision is what makes it both hard and powerful.

Clock Glitching Versus Voltage Glitching

The two techniques achieve the same end through different means. Clock glitching manipulates the clock line directly, so it suits devices that run from an external clock you can reach and interrupt. Voltage glitching disturbs the power rail and works even on parts with an internal oscillator, where the clock line is not exposed.

Attackers pick whichever the target hands them. A board with an external crystal or oscillator 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)

Example output

... 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 a well-placed glitch makes the chip continue as if the check had succeeded.

That is why a boot check that reduces to one comparison is fragile by design. The cryptography behind it might be flawless, but if the verdict it produces is acted on by a single branch, a glitch that corrupts that branch bypasses all of it. The attack does not break the math, it skips the step that was supposed to enforce the math.

A Concrete Target

The classic vulnerable shape is a verify-then-branch where the branch is a single conditional. The glitch aims at the moment the branch is evaluated, flipping a taken into a not-taken or corrupting the comparison’s result so the failure path is never reached.

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

Hardening: Internal Clocks

The first defense is to deny the attacker the clock line. Running the CPU from an internal oscillator or PLL, rather than an exposed external clock, removes the direct target that clock glitching needs. It does not stop voltage glitching, but it closes the easier of the two doors.

Many parts also include a clock security system that detects an absent or out-of-range external clock and switches to a safe internal source. Enabling it means an attacker who cuts or manipulates the external clock trips a fault response instead of getting a clean glitch, which raises the effort substantially.

Hardening: Detect Abnormal Edges

Beyond the clock source, some designs add a clock integrity monitor that watches for edges arriving faster than the configured frequency allows and raises a fault when it sees one. A glitch edge, by definition too early, is exactly what such a monitor is built to catch.

A monitor does not make glitching impossible, but it turns many glitch attempts into detected faults that reset the chip rather than silent instruction corruption. Combined with an internal clock, it forces the attacker toward voltage glitching and a harder search, which is real value even though it is not absolute.

Hardening: Redundant Checks

The most portable defense lives in firmware: do not let one corrupted instruction decide anything important. Verify critical conditions more than once, ideally in different code so a glitch tuned to one check does not skip the others, and require several independent confirmations before taking a permissive action.

// 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. This pattern, plus failing closed so a skipped check leaves the device locked, is what makes firmware survive a fault it cannot prevent.

Designing Against It

No single measure makes clock glitching impossible, and a capable attacker with the right rig will keep trying. The realistic goal is to make one successful glitch insufficient to flip a security decision, by combining an internal clock source, a clock integrity monitor, and redundant fail-closed checks so the attacker needs several precise faults at once.

For a defender, the practical step is to walk the firmware and find every place where one comparison decides something important, then 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.

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. Identifying the clock source is the first and most informative step, because it tells you which fault-injection technique an attacker would even reach for.

From there the countermeasures mirror those for voltage faults, and the mindset is the same: assume the attacker can inject one fault and design so that one fault is not enough. The chips give you internal clocks and monitors; the firmware gives you redundant, fail-closed checks. Used together, they turn a single corrupted instruction from a bypass into a caught and harmless event.

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.