PaperlayerView exact revision on arXiv

Source-linked AI summary

GlitchLab: A Hardware-in-the-Loop Optimizer for Physical Fault Injection

Tanvir Hossain, Abhinav Mahadevan, Jasper Van Woudenberg, Rajesh Velegalati, Arindam Bhattacharyya

arXiv:2609.00502v1cs.CR

TL;DR

Effective physical fault-injection settings are difficult to find because the search space is large, successful regions are sparse, and individual hardware attempts provide limited feedback. GlitchLab uses online hardware-in-the-loop search with structured outcomes, and both policies find target faults in every campaign while excelling at different post-discovery objectives.

  • Problem

    Physical fault injection requires searching a large, sparse parameter space while distinguishing target outcomes from other hardware responses using limited feedback.

  • Method

    GlitchLab assigns delay, voltage, and pulse length distinct search roles and uses structured hardware outcomes with RL-Q for discovery and SOBAS for fault reproduction.

  • Results

    Both policies find a target fault in every campaign; SOBAS reproduces target faults 7.3–21× more often, while RL-Q covers 30% more AES fault settings at equal yield.

  • Takeaways & Limitations

    Discovery, reproduction, and characterization favor different policies, so fault-injection evaluations should report these objectives separately.

  • Takeaways & Limitations

    Evaluation uses three same-model boards, three programs, and one voltage-injection path, so transfer across models, architectures, firmware, or modalities is not established.

Abstract

from arXiv · show

Physical fault injection can turn brief hardware disturbances into security failures such as key recovery, authentication bypass, and unintended control flow. Finding effective faults is difficult because many interacting parameters create a large search space, successful settings are sparse and target-dependent, and each hardware attempt provides limited feedback. Under fixed testing time, efficient search is therefore critical for assessing fault sensitivity. We present GlitchLab, an online hardware-in-the-loop platform that treats delay as a timing gate, voltage and pulse duration as severity controls, and hardware outcomes as structured feedback. It implements RL-Q (Q-learning-based reinforcement learning), a structured bandit for discovery, and Structured-Outcome-Based Adaptive Search (SOBAS), a model-based policy for fault reproduction. Both policies find a target fault in every AES, password, and control-flow campaign. On AES and control flow, they require 2-85x fewer attempts and 26-1,237x less time than the baselines; on password, both succeed while the baselines fail within 5,000 attempts. After discovery, SOBAS reproduces faults 7.3-21x more often, while RL-Q identifies 30% more distinct AES settings.

1 Introduction

GlitchLab frames physical fault injection as an online search problem and uses parameter roles plus structured hardware outcomes to guide adaptive campaigns. RL-Q and SOBAS complement each other: both discover target faults reliably, while their post-discovery strengths differ by objective.

  • Motivation: Physical fault injection can corrupt security-critical computations without software vulnerabilities, but effective configurations must align timing and perturbation strength with vulnerable operations.Consequences include key recovery, control-flow redirection, privilege escalation, and integrity violations.
  • Results: 2–85× fewer hardware attempts let both policies find target faults in every campaign, while BO-GP and BO-SMAC exhaust the authentication budget.The evaluation spans cryptographic, authentication, and control-flow programs on three physical units of the same Pinata model.
  • Approach: GlitchLab treats delay as a timing gate and voltage and pulse duration as severity controls, using five-class hardware responses instead of binary success.This separates first-target discovery, fault reproduction, and vulnerable-region characterization as distinct campaign objectives.
  • Policies: RL-Q localizes delay, allocates attempts across regions, and brackets pulse length, whereas SOBAS learns categorical outcome models without explicit fault-boundary geometry.Both policies run through GlitchLab’s common instrument, oracle, recovery, and logging interfaces.
  • Results: After discovery, SOBAS reproduces target faults 7.3–21× more often, whereas RL-Q covers 30% more AES fault settings at equal yield.The rankings therefore depend on whether the campaign prioritizes reproduction or characterization.
  • Security outcomes: The located faults produce AES ciphertext differences, incorrect-password acceptance, and premature loop termination.These outcomes connect the search objectives to cryptographic, authentication, and control-flow security failures.

2 Background and Related Work

Voltage fault injection searches bounded configurations that jointly control timing alignment and perturbation severity, with sparse target regions and structured hardware feedback. Adaptive methods use these observations to reduce non-adaptive search costs and support discovery, reproduction, or region characterization.

  • Physical fault injection: Voltage fault injection perturbs a supply rail using glitch voltage v, trigger-relative delay d, and pulse duration ℓ.The configuration is x = (v,d,ℓ); v controls strength, d aligns the perturbation, and ℓ controls duration.
  • Physical fault injection: The three parameters act jointly through electrical and timing behavior: delay selects the active operation, while voltage and duration determine whether timing margin is exceeded.A sufficiently strong transient can cause an incorrect or unstable state to be captured at a clock edge.
  • Campaign model: Each hardware attempt incurs DUT execution, response classification, and possible reset and recovery, making hardware attempts the primary campaign resource.Candidates are sampled within bounded voltage, delay, and duration ranges.
  • Campaign feedback: Hardware responses form five classes: normal execution, crash or reset, non-target fault, target fault, and missing trigger.These classes are color-coded Green, Yellow, Magenta, RED, and Pink, respectively.
  • Search challenge: Target regions can be narrow, disconnected, and dependent on device, firmware, operating conditions, and trigger alignment, making blind enumeration expensive.A program-specific oracle distinguishes target conditions from other execution outcomes.
  • Campaign objectives: First-target iteration measures discovery cost, while target-fault yield measures recurrence after discovery; neither quantity alone characterizes a search procedure.The first-target measure is right-censored when no target appears within the attempt budget.
  • Adaptive search: Online policies use observed outcomes to focus subsequent attempts, gaining feedback before the rare target fault appears.Categorical outcomes provide denser cold-start feedback than binary labels.
  • Related work: Q-learning estimates action values from observed transitions, while prior adaptive methods include evolutionary search, Bayesian optimization, and random-forest configurators.These approaches motivate adaptive search but differ in objectives and outcome representations.

3 Threat Model

GlitchLab models board-level voltage fault injection for analysts and physical attackers who select bounded glitch configurations, invoke and reset the target, and observe externally classified outcomes. Campaign objectives distinguish finding the first target fault from measuring reproducibility and vulnerable-region coverage.

  • Physical access and capabilities: Both analysts and attackers apply board-level voltage glitches through an accessible processor supply rail, controlling voltage, trigger-relative delay, and pulse duration.The optimizer operates without invasive processor-die access.
  • Scope boundary: The study assumes a viable voltage-injection path and repeatable target invocation, while excluding engineering the path and invasive die-level techniques.When a successful fault region exists, the scope is efficient discovery and characterization within the available parameter space.
  • Knowledge assumptions: The model supports white-box to black-box knowledge settings without requiring a prior parameter–outcome map or pretrained target-specific model.Source, firmware, traces, or protocol timing may narrow the search, but the policy learns from current-device observations.
  • Outcome observation: Each attempt is assigned a semantic outcome class by a program-specific oracle, and the policy receives the tested configuration plus that class.Classes include normal execution, malformed or missing response, non-target fault, target fault, and synchronization failure.
  • Objectives and success criteria: Attackers may prioritize the first security-relevant target fault, whereas analysts typically continue to measure repeatability and map the vulnerable region.The paper distinguishes first-target iteration, target-fault yield, and occupied parameter-space cells as separate campaign quantities.

4 Proposed Search Methods and GlitchLab Framework

GlitchLab compares two policies that exploit distinct roles for delay, voltage, and pulse length while using structured hardware outcomes. RL-Q uses explicit geometric structure and region allocation; SOBAS learns categorical outcome probabilities with fewer geometric assumptions.

  • Policy design: SOBAS learns categorical outcome probabilities without an explicit physical threshold, while both policies use the same semantic outcome classes.Random-forest classifiers estimate outcome probabilities, and the acquisition policy changes after the first target fault.
  • Policy design: RL-Q treats delay as a timing gate and voltage and pulse length as severity controls, rather than searching three equivalent coordinates.A useful fault requires d ∈W and |δ(v,ℓ)| ≤β, motivating separate mechanisms for timing and severity.
  • Delay-window refinement: RL-Q anchors delay to a DUT hardware edge and begins from D0, then refines target-producing segments while preserving exploration until the timing-resolution floor.Target-producing segments are subdivided; segments producing only non-target faults are not, and refinement stops at wd.
  • Amplitude–length model: The quadratic strength–duration model is an empirical, device- and path-specific approximation, so each region retains an independent local bracket and estimate.The fit uses a rolling window and does not transfer between benches; signed offset values indicate below-threshold, transitional, or increasingly severe conditions.
  • Outcome feedback and adaptation: RL-Q updates region utility and local transition estimates from structured outcomes, using reset-based one-step value updates rather than long-horizon bootstrapping.With γ = 0, the method is explicitly a structured bandit; every attempt starts from reset and prior outcomes update the relevant estimates.
  • Online search and allocation: RL-Q allocates attempts across amplitude–delay regions with UCB, while each selected region brackets pulse length using ordered outcome feedback.The amplitude table selects the region; its local bracket selects pulse length, and optimistic initialization preserves coverage of unexplored regions.
  • Limitations: RL-Q’s pulse-length bracketing assumes roughly monotone outcomes at fixed amplitude; when that assumption fails, widening and re-exploration are needed.UCB guarantees additionally assume stationary rewards, while the method uses annealing and decay.
  • SOBAS acquisition: SOBAS suppresses crash and missing-trigger candidates while retaining uncertainty-driven exploration, but its acquisition factors are operational constraints rather than a formal safe-optimization guarantee.The policy uses ε to keep confident points revisitable.

5 Implementation and Experimental Setup

GlitchLab uses a controlled hardware-in-the-loop bench and common campaign protocol to compare adaptive policies with reference configurations. The setup drives voltage glitches, classifies target responses, and accounts for attempt costs across three same-model boards.

  • The protocol keeps hardware execution, outcome classification, and attempt accounting consistent across policies for controlled comparison.
  • The bench drives the target rail on a hardware trigger, while UART responses and oscilloscope traces support outcome classification and localization.
  • Three same-model Pinata boards provide cross-unit evaluation under one injection path.The boards run the same target platform and test repeatability across physical units.
  • Each campaign selects glitch voltage v, trigger-relative delay d, and pulse duration ℓ within shared bounds and a 5,000-attempt budget.
  • Figure 5 measures first-target cost using median wall-clock time and median attempt index, with interquartile-range whiskers across campaigns.Localization is excluded, and > 5,000 denotes no target fault within the common budget.
  • RL-Q and SOBAS retain semantic outcome classes, whereas BO-GP and BO-SMAC receive scalar reductions and search the cold delay span.

6 Evaluation

Evaluation shows that GlitchLab’s policies discover target faults efficiently, but their rankings depend on whether a campaign values discovery, reproduction, or region coverage. Localization and structured outcome modeling support the search, while RL-Q and SOBAS exhibit complementary strengths.

  • Evaluation: The apparent leader depends on whether the campaign prioritizes discovery, reproduction, or characterization rather than first-fault cost alone.
  • 6.1 First-Target Discovery: 1,237× and 642× speedups are achieved on AES, while loop speedups are 49× and 26× for RL-Q and SOBAS, respectively, relative to SMAC.
  • 6.1 First-Target Discovery: On password, RL-Q succeeds in 698 attempts/34 s and SOBAS in 3,188 attempts/142 s, while neither reference policy succeeds within 5,000 attempts.
  • 6.2 Localization: Localization narrows each target’s timing window by one to two orders of magnitude relative to its cold span.
  • 6.3 Geometry: RL-Q’s pulse-length bracket exploits the measured strength–duration ordering, while SOBAS learns categorical outcome probabilities without explicit fault-boundary geometry.
  • 6.4 Repeatable Faults After Discovery: SOBAS reproduces target faults 7.3–21× more often, whereas RL-Q covers more AES voltage–length cells at equal yield.
  • 6.5 Fault-Region Coverage: The first-fault leader, reproduction leader, and coverage leader need not be the same policy, so campaign metrics must match the objective.

7 Security Impact of the Demonstrated Faults

The demonstrated target faults correspond to three security-relevant effects: cryptographic corruption, authentication bypass, and control-flow violation. These effects illustrate attack primitives, while complete end-to-end exploitation is outside the evaluation scope.

  • The three targets represent cryptographic corruption, authentication bypass, and control-flow violation rather than complete end-to-end exploits.
  • Authentication bypass: Both proposed policies produce incorrect-password acceptance in every campaign, whereas BO-GP and BO-SMAC do not within the shared budget.
  • Authentication bypass: Incorrect-password acceptance is a direct failure of the authentication decision and can expose functionality protected by an access check.
  • Control-flow violation: The finite loop terminates early while returning a parseable response with inconsistent counters, violating its intended control-flow guarantee.
  • AES key recovery: The AES oracle targets four-byte ciphertext corruption matching the geometry required for last-round differential fault analysis.
  • AES key recovery: Showing differential fault analysis is out of scope; the paper evaluates acquisition of suitable ciphertext pairs and relies on established recovery methods afterward.

8 Discussion and Limitations

GlitchLab separates discovery, reproduction, and characterization as distinct campaign objectives and recommends reporting complementary metrics. Its evidence is limited to a small, voltage-injection evaluation, although the policies learn online without prior fault maps.

  • RL-Q favors discovery and coverage, whereas SOBAS favors reproduction, so these objectives should be reported separately.
  • Reporting FI campaigns: A complete campaign report should include discovery cost in hardware attempts and wall-clock time, post-discovery reproduction rate, and region coverage at controlled yield.
  • Reporting FI campaigns: Discovery cost alone cannot distinguish a repeatable vulnerability from an isolated event, while reproduction rate alone cannot distinguish broad coverage from a narrow productive setting.
  • Accounting for localization: Timing localization removes one to two orders of magnitude of inactive delay space but incurs route-specific costs such as instrumentation and trace acquisition.
  • Scope and limitations: The evaluation covers three same-model Pinata boards, three programs, and one voltage-injection path, so transfer across models, architectures, firmware, and modalities is not established.
  • Scope and limitations: Neither policy requires a precomputed fault map or observations from another device, but validating transfer to new platforms and programs remains future work.
  • Future modalities: Future extensions to clock, electromagnetic, and laser injection require modality-specific constraints and experimental validation.

9 Conclusions

GlitchLab closes an online voltage-fault-injection loop by preserving structured outcomes and supporting policies with complementary assumptions. Across campaigns, both policies found target faults, while reproduction and vulnerable-region coverage favored different policies.

  • Both policies find a target fault in every campaign across three same-model units.
  • SOBAS reproduces target faults more frequently after discovery, whereas RL-Q covers more of the vulnerable region at equal yield.
  • The resulting faults bypass authentication, violate intended control flow, and provide ciphertext differences for AES differential fault analysis.
  • The closed-loop formulation can extend beyond voltage injection when other modalities provide modality-specific controls and informative outcome feedback.

A Reproducibility and Experimental Details

The appendix specifies measured voltage-fault-injection campaigns from shared experimental definitions through policy execution, physical measurement, outcome classification, and logging. Its fixed values support reproduction of reported distributions without access to the implementation.

  • The appendix follows each campaign from shared experimental definition through policy instantiation, execution, classification, and logging.
  • Parameters fixed across policies are separated from parameters intentionally distinguishing the search methods.
  • The reported values describe measured voltage-fault-injection campaigns rather than simulations.

A.1 LLM-Assisted Delay Localization

GlitchLab uses a frozen LLM prompt to rank candidate delay windows from measured TVLA output before hardware validation. The resulting rankings reduce AES validation effort, while online refinement and complementary routes remain useful for password and loop targets.

  • Grok 4.6 ranks candidate delay windows using only the measured TVLA curve, its statistical summary, and a fixed window width.
  • 2.4–7.2× reduction: AES validation falls from 129 and 205 attempts under magnitude-only TVLA ranking to 18 and 84 attempts.
  • On password set 1, the Grok-ranked first window produces a target in 164 attempts, while magnitude ranking and full-span online search exhaust 2,500 and 5,000 attempts.
  • RL-Q finds the password interval missed by both trace rankings, while magnitude ranking finds the loop fastest.
  • Candidate windows may be shorter than the nominal 40 ns near the capture boundary because they are edge-clipped.
  • The component checks show complete RL-Q succeeds on password at attempt 115, while binary feedback finds no target within 1,500 attempts.

A.2 Campaign Protocol and Shared Search Space

The campaign protocol reinitializes policy state and models for each complete campaign while holding the target and experimental conditions fixed for controlled comparisons. RL-Q adapts outcome utilities over an initial attempt schedule.

  • Each reproduction campaign selects a target and delay interval, initializes a policy without retained history, executes the fixed controller, and derives metrics from the attempt log.
  • The RL-Q–SOBAS comparison keeps firmware, bounds, oracle, recovery path, and budget identical.
  • BO-GP and SMAC use cold delay spans, so comparisons evaluate complete campaign configurations rather than candidate selection alone.
  • RL-Q anneals non-target utility linearly over the first T_M attempts.

A.3 Policy Instantiations

The appendix instantiates RL-Q, SOBAS, and baseline interfaces with explicit parameter handling, candidate generation, outcome modeling, and hardware-control procedures. It also specifies target oracles, campaign sequencing, logging, and reproducibility details.

  • RL-Q: RL-Q stores running mean utility per allocation cell and supports joint or factored parameterizations for delay refinement.With γ = 0 and αt = 1/Njk, cells store running mean utility rather than discounted returns.
  • SOBAS: SOBAS normalizes inputs, fits separate multi-class outcome and binary target forests, and executes quantized, deduplicated candidates sequentially.The supplied implementation description specifies these model-fitting and candidate-execution choices.
  • Candidate selection: The warm-up uses a scrambled Sobol design, while tree-wise standard deviation ranks candidates without being treated as a calibrated posterior interval.At the history cap, recent observations are retained and older observations are sampled uniformly.
  • Baseline interface: BO-GP and BO-SMAC receive a scalar reduction, while RL-Q and SOBAS retain semantic outcome classes.The scalar score grades only the non-target-fault row using corrupted-byte count; the named baselines share the same controller-to-policy interface.
  • Campaign execution: Each hardware attempt is classified from instrument completion and parsed response, then fully logged and followed by reset after faulty or failed responses.The sequence distinguishes missing triggers from target-link timeouts and preserves records for recomputing reported metrics.
Loading 2609.00502v1…