Four techniques account for most practical attacks. Voltage glitching briefly lowers or raises the supply so that a critical path misses timing; the shape of the glitch matters as well as its width and delay, as Bozzato et al. (2019) showed with arbitrary waveforms. Clock glitching inserts a shortened cycle and applies where the attacker controls an external clock. Electromagnetic fault injection induces currents with a pulsed coil near the package and adds spatial selectivity without decapsulation (Moro et al., 2013). Optical injection with a laser or flash on an exposed die is the most precise and the most demanding in preparation (Skorobogatov and Anderson, 2003). Open hardware such as ChipWhisperer has brought the first three within reach of an ordinary laboratory (O'Flynn and Chen, 2014).

The effect most often exploited is the skipped or replaced instruction. Moro et al. (2013) traced electromagnetic faults on a 32-bit microcontroller to corruption of the instruction as it is fetched, which at the software level looks like one instruction being replaced by another. More powerful effects are possible: Timmers et al. (2016) showed that a fault during a load can place attacker-controlled data in the program counter on a 32-bit Arm core. The survey by Yuce et al. (2018) connects such physical effects to their consequences for embedded software and to the design of countermeasures, among them instruction duplication schemes whose correctness against single skips has been formally verified (Moro et al., 2014).

RISC-V targets differ from closed cores in ways that affect an evaluation. Many are available as register-transfer level source, so a fault observed on silicon or on a field-programmable gate array can be compared with simulation of the same design. Laurent et al. (2019) used that access to show that faults in registers hidden from the programmer, such as pipeline and forwarding registers, produce behaviours that an instruction-level model does not predict. The instruction encoding matters too. Where the compressed extension is enabled, 16-bit and 32-bit instructions are mixed, and a corrupted word may be decoded as a different sequence altogether. Privilege is managed through machine mode and physical memory protection as defined in the privileged specification (Waterman et al., 2021), and the configuration of those registers during boot is itself a target.

The threat model states whether the attacker has unlimited physical access, how many devices may be consumed, and which class of equipment is assumed. It also defines success. For secure boot the usual criteria are execution of an unauthenticated image, re-enabling of a locked debug interface, and disclosure of key material. Calibration then checks that the bench does what the script believes: the glitch is observed at the target pin and not at the generator, and the spread of the trigger delay is measured, because jitter larger than one clock period blurs every later result.

Characterisation runs on firmware written for the purpose. A typical test program raises the trigger, executes a counted loop or a sequence of register moves with known results, and prints the final state. The controller sweeps glitch delay, width and, for electromagnetic injection, probe position and pulse amplitude. Each attempt falls into one of four classes: no effect, reset or mute, crash with an exception, or a wrong result with continued execution. The last class is the useful one. Inspecting the wrong results shows whether instructions are being skipped, operands corrupted or loads disturbed, and the parameter region in which this happens most reliably becomes the starting point for the campaign. Test collections designed for fault analysis can supply the instrumented code.

Figure 1 pairs the stages of a generic boot chain with the operations in each that a fault might usefully disturb. Locating those operations in time is the task of the fourth phase. Reading the image from flash produces visible bus activity, the digest computation has a regular power signature whose length scales with the image, and the signature verification follows it. The windows of interest are short: the comparison of the computed and expected values, the branch on its result, and the write that records the verdict. Where source or a disassembly of the boot code is available, the windows can be predicted by cycle counting and then confirmed against the traces.

The campaign applies the characterised parameters to each candidate window with an unsigned or tampered image in place. The outcome classes are extended with the success criteria fixed in the first phase. Every attempt is logged with its parameters, since a single success needs to be reproducible to count. Results are reported per window as the number of successes among the attempts made, together with a confidence interval for the underlying rate. The score interval of Wilson (1927) behaves well for the small proportions typical of this work. A window with no success after many attempts supports only an upper bound on the success rate, and the report should say so in those terms.

Software hardening of boot code commonly includes repeating the verification, encoding the verdict in constants with a large Hamming distance in place of zero and one, checking that execution arrived by the expected path, and inserting random delays. Hardware adds glitch detectors and redundant logic. The final phase repeats the campaign with these measures enabled. Because duplicated checks can be defeated by two well-timed faults, the bench should support multiple glitches per boot. The comparison of success rates before and after hardening, under an unchanged injection set-up, is the main product of the evaluation.