1

ARMORY: Fully Automated and Exhaustive FaultSimulation on ARM-M Binaries

Max Hoffmann, Falk Schellenberg, Christof Paar Fellow, IEEE

Abstract—Embedded systems are ubiquitous. However, phys-ical access of users and likewise attackers makes them oftenthreatened by fault attacks: a single fault during the computationof a cryptographic primitive can lead to a total loss of systemsecurity. This can have serious consequences, e.g., in safety-critical systems, including bodily harm and catastrophic technicalfailures. However, countermeasures often focus on isolated faultmodels and high layers of abstraction. This leads to a dangeroussense of security, because exploitable faults that are only visibleat machine code level might not be covered by countermeasures.

In this work we present ARMORY, a fully automated opensource framework for exhaustive fault simulation on binaries ofthe ubiquitous ARM-M class. It allows engineers and analyststo efficiently scan a binary for potential weaknesses againstarbitrary combinations of multi-variate fault injections under alarge variety of fault models. Using ARMORY, we demonstratethe power of fully automated fault analysis and the dangerousimplications of applying countermeasures without knowledge ofphysical addresses and offsets. We exemplarily analyze two casestudies, which are highly relevant for practice: a DFA on AES(cryptographic) and a secure bootloader (non-cryptographic).

Our results show that indeed numerous exploitable faultsfound by ARMORY which occur in the actual implementationsare easily missed in manual inspection. Crucially, most faultsare only visible when taking machine code information, i.e.,addresses and offsets, into account. Surprisingly, we show thata countermeasure that protects against one type of fault canactually largely increase the vulnerability to other fault models.Our work demonstrates the need for countermeasures that, atleast in their evaluation, are not restricted to isolated fault modelsand consider low-level information during the design process.

I. INTRODUCTION

Around 1970, it was discovered that cosmic radiation can in-duce charge in microelectronics, resulting in potentially faultybehavior of unprotected microcontrollers in avionics. Sincethen, securing embedded systems against faults has been amajor interest of the safety community. In the late 1990s, faultdetection and fault prevention has also moved into the spotlightof the security community. One of the earliest and best knownexamples for such a fault attack is the Bellcore attack onCRT-RSA signatures [2]. Over the last two decades, numerousgeneric and specific fault attacks have been proposed [3] thatthreaten many if not most embedded systems. Fortunately,there exist also a multitude of countermeasures against variouskinds of faults, which are routinely implemented in security-sensitive applications.

M. Hoffmann was with the Horst Gortz Institute for IT-Security, RuhrUniversity Bochum, Germany.

M. Hoffmann, F. Schellenberg, and C. Paar were with the Max PlanckInstitute for Security and Privacy, Germany.

However, practically evaluating the resistance of a systemagainst fault attacks might become a tedious task because ofthe large parameter space: Only if physical parameters suchas fault intensity, duration, timing etc. as well as logical pa-rameters (e.g., location, clock cycle) are correct, a useful faultmight appear. This led to different approaches of assessingfault attacks on various levels of abstraction.

Evaluating faulty behavior on the lowest design levelsproduces reliable results [4], but is only possible if a detailedtransistor-, gate-level-, or RTL-description of the hardwareis available. Yet, especially for off-the-shelf microcontrollerssuch as IoT devices, a detailed low-level description is rarelyavailable. On the other end of the spectrum, there is recentwork that evaluates abstract descriptions of algorithms orimplementations with respect to some specific mathematicalfault exploitation [5], [6]. However, it is difficult to transfer thisoutcome to other types of attacks or even non-cryptographicbut still security-critical parts of the implementation. Evenmore crucial, applying and evaluating countermeasures athigh-level code or even at Assembly code with labels can leadto many faults that are missed in actual physical implementa-tions and a false sense of security. In fact, we later demonstratethe dangerous implications of neglecting low-level informationsuch as physical addresses or offsets since numerous faults areonly surfacing in machine code.

In this work, we take a trade-off between the both extremesdescribed above via hardware emulation. Focusing on theubiquitous ARM-M architecture, we introduce ARMORY, anautomated framework for fault simulation. ARMORY supportshighly customizable multi-variate fault models without beingrestricted to cryptographic applications. Working directly onmachine code, it supports all processors of the ARMv6-M andARMv7-M families, since emulation is based only on publicarchitecture information. Thus, it supports all processors ofthese families out-of-the-box and further can easily be ex-tended with profiled hardware properties of specific chips. Weuse our framework to explore the impact of various designparameters and security approaches on fault vulnerability anduncover numerous faults that are easily missed in manualinspection.

a) Contributions: This work provides four major contri-butions:

• We present M-ulator, an efficient emulator for theARMv6-M and ARMv7-M architectures, outperformingcurrent state-of-the-art emulators, and designed with faultinjection in mind. M-ulator can be restricted to a specificinstruction set/architecture and correctly handles faulty

arX

iv:2

105.

1376

9v1

[cs

.CR

] 2

8 M

ay 2

021

2

Assembly, both are features that no other existing emu-lator provides.

• We present ARMORY, a fully automated fault simulatorfor ARM-M binaries. Based on M-ulator, it exhaustivelysimulates arbitrary combinations of a variety of customiz-able fault models on a given binary, including higher-order faults.

• In five analyses we use ARMORY to explore the impactof several parameters, i.e., compiler optimization, codepositioning, well-known countermeasures, higher-orderfault injection, and knowledge of undefined behavior onexploitability. All analyses are carried out on two casestudies that are relevant in practice, one being crypto-graphic (a DFA on AES) and one non-cryptographic (asecure bootloader). Our results highlight the versatilityof ARMORY and demonstrate that numerous exploitablefaults are outside of the engineers control, easily missedin manual inspection, and cannot be easily preventedthrough countermeasures. Crucially, many of these faultsare completetely invisible on higher level of abstraction,i.e., C code or even Assembly with labels.

• We demonstrate that the application of a countermeasureagainst faults of a certain model can actually severely in-crease vulnerability against other fault models. One mightbe easily tempted to think that applying a countermeasureat least does not influence vulnerability or even benefitsagainst other attacks. Using ARMORY, this effect can beeasily analyzed in any application.

AVAILABILITY

The latest version of M-ulator and ARMORY are availableopen source at https://github.com/emsec/arm-fault-simulator.Our results and visualizations as well as the code of our casestudies for full reproducibility are available at https://github.com/emsec/arm-fault-simulator-paper-results.

II. BACKGROUND

A. Fault Injection, Evaluation, and Countermeasures

Since its first introduction by Lenstra and Boneh et al. [7],[2], both scientific and industrial interest in fault injection areconstantly rising. Numerous physical methods to induce a faultwere found, e.g., fault injection through voltage [8] or clockglitches [9] and via electromagnetic radiation [10]. Further,laser fault injection was first introduced by Skorobogatovet al. [11] and can be seen as one of the most precisetechniques, allowing to target individual transistors. Likewise,beyond Differential Fault Analysis (DFA) [2], numerous ad-vanced mathematical attacks were proposed – its latest promi-nent variant being Statistical Ineffective Fault Attacks [12].The sheer amount of different types and classes of fault attackshas repeatedly lead to classification works [13], [3], [14].The most widely used fault types are single bit set, reset, orflip faults as well as faults targeting entire registers, bytes,words, or variables. Other properties include the distributionof the resulting faulty values (e.g., biased or uniform), thetemporal precision, the duration, the abstraction level targetingtransistors or values during a protocol etc.

Recently, injecting multiple useful faults at once has beenpractically proven using a double spot laser station [15].Injecting multiple faults during a single program executionis often referred to as a multivariate fault or a higher-orderfault. Throughout this work, we will use the term higher-orderfault to precisely indicate the number of injected faults, i.e.,an n-th order fault is comprised of n individual faults. Toavoid confusion with the overarching term fault we sometimesemploy fault combination to capture all individual faults in ahigher-order fault where disambiguation would be difficult.

Considering countermeasures, one option is to address thephysical effect itself, either through shielding (e.g., generatingthe clock internally, metal shielding to hinder EM pulses etc.)or by deploying sensors, e.g., to detect voltage or laser pulses.However, those usually only counters a limited number offaulting methods. Instead, fault detection or correction can beeasily achieved by introducing some form of redundancy. Forexample, one could verify after creating signature to counterfault attacks on RSA-CRT [16]. For symmetric ciphers, thistranslates to decrypting after encrypting, comparing the resultto the original plaintext. Another option is two encrypt twiceand comparing the result. This can be done either in parallel(in hardware) or successively, storing the result of the first iter-ation. Randomizing a delay between the two iterations alreadyleads to a very effective countermeasure as it is unlikely thatan identical fault can be injection twice with the correct timing(without triggering fault counters before). Instead of checkingfor consistency only once at the end, so-called ConcurrentError Detection (CED) schemes check at certain points duringthe encryption, e.g., after each round (cf. [17], [18]). Moreadvanced schemes deploy coding techniques to achieve a cer-tain n-bit fault resistance at a lower cost [19]. This, however,also leads to the question of what to do if indeed an erroris detected. One approach is counting the number of faultsand deleting secret keys when a certain threshold is reached.Simply omitting the output might not be enough when dealingwith ineffective fault analysis [20] or safe-error attacks [21]. Itslatest variant, Statistical Ineffective Fault Analysis (SIFA) [22],requires even more sophisticated countermeasures if deletingthe key is unwanted [23], [24]. An orthogonal approach isInfective Computation[21], where a fault will randomize theinternal state so that the faulty ciphertext is random as well.Unfortunately, such countermeasures at least for symmetricschemes did not receive much trust as those were brokenrepeatedly [25].

B. Fault Simulation and Assessment

From an attacker’s perspective, a useful fault might onlyappear if all involved parameters are correct. Finding workingconfigurations exhaustively, e.g., for location, timing, intensity,etc., might be impossible due to the immense individualparameter space. This already led to various approaches toimprove the search for suitable parameters [26], [27]. Insteadof trying different parameter sets, simulation techniques wereleveraged to speed up fault analysis. Ironically, laser faultinjection itself was originally introduced to simulate heavyion strikes in electronics that would happen in avionics.

3

Nowadays, various approaches aim to entirely simulate theeffects of targeted faults [4], [28], [29], [30]. Here, one ormultiple injections are simulated either on the RTL level ordown at the transistor level using SPICE. For the latter, theresulting faulty behavior is again evaluated solely digital oncethe fault is latched. In [29], the authors even evaluate layoutinformation with respect to the size of the laser spot. Thisall, of course, necessitates many implementation details of thedevice under test. Although desired, in the security contextsuch a detailed description is often not available, e.g., insmartcards or multipurpose microcontrollers such as the ARM-platform targeted here.

On the other hand, there are various approaches that try tofind an actual mathematical attack based on some descriptionof a cipher, e.g., using algebraic fault attacks [31] or classicalDFA [5] (cf. [32] for an overview). However, these works aretailored to specific types of mathematical fault analysis andthe results usually cannot be transferred to other fault attacks.Even further, those are only applicable to the cryptographicoperation itself and not to other security-critical parts ofthe code. For example [5] searches for vulnerable spots forDFA based on a data flow graph extracted from Assembly.A similar approach is presented in [33], but instead, theextracted set of equations is fed to an SMT solver to finda distinguisher. Abstracting further, [6], [34] operate on amathematical description of a cryptographic operation to finda possible attack in the first place. As we highlight later, thismight be a good early indication, but its actual implementationadds numerous additional potential faults that are invisible ata high abstraction level. Riscure sketches with FiSim [35], aproprietary closed-source tool for ARM fault simulation. Yet,it only focuses on first order attacks and is based on Unicorn(which is inadequate for fault simulation as we discuss inSection IV). A similar but bottom-up approach is taken in [36],although only limited to memory faults, closed source, andagain restricted to single faults.

The authors of [1] use bounded model checking to automati-cally verify whether tailored assertions also hold on a modifiedbinary. To this end, the assertions are added in the sourcecode to be compiled alongside. The binary is then modifiedaccording to the fault model. Both the genuine and the faultybinary are transferred back to LLVM-IR to be able to checkwhether the assertions hold. Unfortunately, this approach hassome large performance penalty (2 hours for verifying single-bit opcode faults for code that checks a PIN in a loop). Further,formulating assertions on source level that should also coverpossible vulnerabilities on assembly level is hard and error-prone.

III. MOTIVATION

While fault simulation on hardware models would be themost accurate approach, it is very difficult if not impossibleto get the hardware models of off-the-shelf processors foranalysis. Thus, we consider fault simulation on the binarylevel, which provides a good trade-off between coverage andaccessibility. More concretely, we focus on binary-level faultsimulation of ARM-M processors, i.e., we simulate faults on

the final machine code that is flashed into the processor. WithARM being the market leader in embedded systems and theubiquity of ARM-M processors, especially in IoT products,this platform is one of the most relevant for fault attacks.The specifications of the ARM-M instruction set architecturesARMv6-M and ARMv7-M are public, so covering the speci-fications means covering all Integrated Circuits (ICs) of saidarchitecture regardless of vendor/manufacturer.

From a research perspective, we want to demonstrate acrucial problem of current software countermeasures againstfault injection: they mainly operate on a high level of ab-straction, e.g., on C-code. Since faults are eventually affectingthe final machine code, restricting the analysis to high-levelcode can result in exploitable faults that are easily missed inboth automated and manual inspection. We show that even acomparatively low-level description like Assembly with labelsstill hides many exploitable faults, since physical addressesand offsets are still not available. Our results demonstrate theneed for fault detection schemes that take the final machinecode into account. The tools presented here, M-ulator andARMORY, provide a comprehensive framework that, webelieve, can substantially support both scientific research andevaluation of real-world implementations.

IV. M-ULATOR

In order to simulate faults on a binary in software, thebinary has to be run in an emulator. For the ARM architecture,several emulators exist, including VisUAL1, thumbulator2,and state-of-the-art QEMU-based Unicorn3. However, purelygraphical emulators such as VisUAL are not suitable forautomated tools. Unfortunately, the other existing emulatorsshare a crucial property that make them unsuitable for faultsimulation: they do not correctly handle faulty Assembly andare not architecture-restrictable.

These emulators were built to emulate valid ARM Assem-bly and perfectly provide this functionality. Developers tookshortcuts to optimize efficiency and neglected invalid operandcombinations, which is perfectly reasonable for assembler-generated machine code. However, when faced with invalidmachine code as common in the case of faults, these emulatorsbehave incorrectly or simply crash. For example, a 32-bitinstruction may be faulted and now represents two 16-bitinstructions. If dynamically injected at the time of execution,available emulators execute the first 16-bit instruction butskip over the second one since they originally hit a 32-bitinstruction. More subtly, when analyzing an ARMv6-M basedprocessor and an instruction is faulted into a valid ARMv7-M-only instruction, existing emulators will simply execute thefunction, even though the analyzed processor is not capableof doing so. This potentially leads to false positives.

In total, for correct fault simulation, an emulator is neededthat is correct in the presence of faults and architecture aware.Therefore, we present M-ulator (pronounced [’εm /ulator/]),our own emulator for ARMv6-M and ARMv7-M binaries

1https://salmanarif.bitbucket.io/visual/index.html2https://github.com/dwelch67/thumbulator3https://www.unicorn-engine.org/

4

that features both desired properties. Written from scratch inC++17, it provides a simple but powerful user interface andfull control over all simulated aspects of the processor. Everyaccess to registers or memory can be hooked with customfunctions, both before and after access. Likewise, instructionexecution can be hooked before fetch, after decode, and afterexecute. This is particularly useful for fault injection since theemulator respects all changes made during the hook functions.For example, a hook before instruction decode can be used toemulate a fault, e.g., on the instruction fetch register or onthe memory bus. This results in a different (and potentiallymalformed) instruction being executed.

The architecture of M-ulator is held simple for maintainabil-ity and clarity, consisting mainly of two parts: the instructiondecoder and the execution unit. The instruction decoder isimplemented as a large if/else tree based on ARMs machinereadable instruction set description, i.e., it precisely mirrorsthe public specification. While this results in a lot of code,every instruction decoding has its dedicated place and caneasily be located, read, debugged, or tweaked. The executionunit takes a decoded instruction and updates registers/memoryaccordingly, firing all registered hooks in the process. Forfunctional correctness we tested M-ulator against state-of-the-art emulator Unicorn by comparing CPU and memory statesafter executing all supported instructions.

In terms of efficiency, M-ulator outperforms Unicorn. Wecompiled both emulators with the same GCC version 7.4.0and their default release options and let them emulate the sameARMv7-M binary on the same PC. For a binary that computesan AES-128 key schedule followed by 100 encryptions M-ulator took 155 ms and Unicorn took 333 ms. For 100SHA256 computations M-ulator took 271 ms and Unicorntook 574 ms on the same binary. The above times wereaveraged over 50 executions to account for OS scheduling,caches etc. In total, M-ulator finished these small-scale testsroughly 2.1 times as fast as Unicorn.

Naturally, an emulator is only an abstraction or approx-imation of the real hardware. However, we will show inSection VII-E that M-ulator can easily be extended withprofiling data of a real chip in order to be even more accuratefor specific hardware.

V. ARMORYIn this section we present ARMORY, our automated fault

injection tool. ARMORY is built on M-ulator and is capableof exhaustively injecting arbitrary combinations of arbitraryfault models. The general workflow is illustrated in Figure 1.For the moment we focus on explaining the inputs andgeneral functionality. We dive into the inner workings later inSection V-E. In the end, in Section V-G, we provide a detaileddiscussion on applying ARMORY in real-world scenarios.

A. Terminology

As described in Section IV, M-ulator is a instruction-accurate emulator, i.e., it is not cycle accurate. This is dueto different pipeline architectures across the ARMv6-M andARMv7-M families and a lack of cycle descriptions in the

FaultModels

M-ulatorInstance

ExploitabilityModel

HaltingPoints

ARMORY

List Injection Points

Advance to Next Injection Point

Apply Current Fault Model

Run Mulator

Recursively Start With Next Fault Model

Found Exploitable Fault

Halting Point HitNo Halting Point Hit

EvaluateExploitability

Model

no more remaining

Figure 1: Simplified workflow of ARMORY

official documentation. Hence, ARMORY provides detailson the timing of fault injection down to instruction-levelgranularity. Therefore we use the index of an instruction inthe instruction sequence of the program as our notion of time,i.e., if a fault has to be injected at time 5 this means it has tobe injected on the 5th executed instruction.

ARMORY exhaustively simulates faults on a binary, i.e.,it applies the given fault models to every possible “position”or “location”. For instance, a instruction bit flip fault will beapplied to all 16 or 32 bits of each instruction and the resultingeffects are observed. A register byte fault would be applied toall four bytes of each 32-bit register every time it is used.In the following we collectively refer to these points where afault model is applied as injection points. We again would liketo stress that ARMORY will exhaustively simulate the effectsof faults on all possible injection points in the whole binary.

Eventually, ARMORY has to decide whether a fault isexploitable. This is covered via an exploitability model. Sucha model can cover simple cases such as “incorrect outputobserved”, but also supports way more complex cases, e.g., acritical function was executed or a specific algebraic relationbetween output bytes is met.

B. Inputs

A user has to provide four inputs to ARMORY: (1) anM-ulator instance, (2) a set of fault models to inject, (3) anexploitability model, and (4) a set of addresses at which theexploitability shall be evaluated, so called halting points.

The first input is an M-ulator instance, loaded with thebinary to test. The user can prepare the instance with arbitraryhooks and emulate as many instructions as he wants in orderto bring the emulator into the desired initial state. Of course,all instructions executed until this point are fault-free.

The second input is a set of fault models for ARMORY totest. Details on the supported fault models will be given inthe Section V-D. To the best of our knowledge, we supportthe largest set of fault models found in literature among all

5

simulation-based approaches. More fault models can be addedeasily without the need to change ARMORY.

The third input is an exploitability model, since, eventually,ARMORY has to decide whether a fault injection led toexploitable behavior. While prior work oftentimes simplyregards incorrect output as exploitable, depending on theapplication this may be oversimplified or does not capturean adversary’s objective. Hence, the user has to provide anexploitability model, i.e., a set of conditions which, whenmet by injecting a fault, regards the fault as exploitable. Suchan exploitability model enables far more flexible vulnerabilityassessment than in previous simulation-based approaches, as itcan cover everything from simple output mismatch tests, overmore complex arithmetic checks, to even functionality-checks,e.g., whether specific (sensitive) code was executed.

The fourth and final input is a set of halting points. Since ex-ploitability typically surfaces only after numerous instructionshave been executed, e.g., after a ciphertext is output, it wouldbe unreasonable and inefficient to verify the exploitabilitymodel after each instruction. Hence, these halting points defineaddresses of instructions where the exploitability model isevaluated.

The user can also set the maximum number of fault modelsapplied at the same time, set the maximum number of utilizedCPU cores, specify address ranges in which no fault should beapplied, and give a timeout in form of the maximum numberof executed instructions to avoid infinite loops. For the sakeof simplicity these features were not shown in Figure 1.

C. Outputs

Given its inputs, ARMORY exhaustively simulates all sup-plied models in all possible combinations on all availableinstructions/registers without further user interaction and re-ports all exploitable fault combinations. The reported faultcombinations contain all information necessary to understandand replicate the faulty behavior, i.e., injection time, affectedinstruction or register, affected bit/byte, etc.

ARMORY also comes with a fault tracer, which allows toverify a specific fault combination and, as the name suggests,to trace the effects of faults instruction-by-instruction.

Since the modeled behavior is purely based on publiclyavailable instruction specifications by ARM, all detected faultsare guaranteed to work on real hardware, given that theattacker is able to precisely inject the required fault models.Hence there is a guaranteed 0% false positive rate. However,note that emulation is just an abstraction of the real hardware.Therefore, ARMORY cannot capture all faults that were possi-ble on real hardware. For example, ARMORY does not knowabout internal buffer registers etc, hence it cannot simulatefaults on these entities. Yet, if such internal behavior is knownto the user, it can be added. We provide more details onapplying ARMORY in real-world scenarios in Section V-G.

D. Fault Models

As previously mentioned, ARMORY is capable of applyingarbitrary fault models to the execution. The current imple-mentation supports arbitrary faults on instructions and faults

on registers. Note that, while this selection may sound fairlylimited, instruction-level and register-level faults are sufficientto model a wide range of real-world fault effects as wedescribe in Section V-G. However, because of the modulardesign of ARMORY, other classes of fault models can beadded with ease. Every fault model is highly configurable,from its effect, over its duration, to specific filters, e.g., toskip faulting the LR register or to skip branch instructions.Note that each model may also result in multiple injectionpoints on a single instruction or register, e.g., a register byte-fault would be applied 4 times. A complete example ofa fault model would be a permanent, 4-iteration,only-on-R0, register-byte-set-fault.

We stress that ARMORY cannot decide whether a faultmodel is actually feasible in the real world. A detaileddiscussion on ARMORY in real-world scenarios is given inSection V-G.

a) Instruction Fault Specifics: Instruction faults can beeither permanent or transient. A permanent fault is injected atthe beginning of simulation and affects the instruction everytime it is executed, while a transient fault is only active fora single instruction execution. Permanent instruction faultscan be used to model, e.g., faults in the program memory,while transient instruction faults can model, e.g., faults on theinstruction decoder register or instruction bus.

b) Register Fault Specifics: Register faults can be eitherpermanent, active until overwrite, or transient. A permanentfault affects the register value at the beginning of simulationand on all subsequent writes, an until-overwrite fault affects aregister value once but subsequent (over-)writes to the registerwill remove the fault’s effect, while a transient fault is onlyactive for a single instruction execution. While register faultsmostly model laser faults on register banks, a transient registerfault can also model, e.g., a fault on the transistors that drivea register’s output wires.

E. Optimized Fault Simulation Strategy

During simulation, ARMORY exhaustively applies thegiven fault models at every possible injection point, i.e.,location or position where the fault model is applicable,cf. Section V-A. However, the numerous possibilities for faultmodels pose a challenge for simulation of higher-order faults.A single fault might completely change the control flow,thus rendering static evaluation of injection points incorrect.Therefore, injection points are determined dynamically atruntime during a single fault-free simulation. We will firstdescribe fault simulation strategy in general, before explainingthe details of higher-order fault simulation (cf. Figure 1)

a) Fault Simulation Strategy: First, ARMORY needs tofind injection points for faulting, i.e., all locations where thegiven fault models are applicable. Therefore, the emulator isran without injecting faults, i.e., a dry run, until the binaryfinishes or the supplied timeout is reached. This providesthe sequence of executed instructions and used registers. Thissequence directly holds all injection points in sorted order. Forexample, regarding instruction skip faults, every instruction ofthe sequence is a single injection point, while for a single-bit

6

register fault every register of the sequence marks 32 injectionpoints. Fault simulation is then performed as follows:

Starting from the beginning, the emulator is ran until rightbefore the next injection point and its current state is storedas backup. Now the fault model is applied and the emulatorcontinues. If an halting point is reached, the exploitabilitymodel is checked to decide whether the currently injectedfault combination is exploitable. In that case, the current faultis appended to the list of exploitable faults, otherwise thefault is regarded as not exploitable. Likewise, a fault is notexploitable if no halting point was reached until simulationstops or M-ulator encounters an invalid instruction, e.g., anundefined opcode, invalid operands, etc. The emulator’s stateis now restored to the backup right before the fault wasinjected and the emulator is advanced to the next injectionpoint This backup/restore mechanic removes the necessity ofhaving to start from the beginning for each fault, heavilyreducing emulation time (more details in Section V-F). Thenthe injection process repeats. Note that, in case a fault model isapplied multiple times to one instruction or register, M-ulatordoes not need to be advanced at all in between injections.

b) Higher-Order Fault Simulation: While the above sim-ulation technique works well for isolated first-order faults,higher-order (multivariate) faults are also of interest. However,in this scenario not only is the order of injected faultsimportant but also their immediate effects: One fault mightresult in a change in control flow which enables a whole rangeof new faults.

Intuitively, the complexity of simulating a list of faultmodels is O(nm) with n being the number of injection pointsand m being the number of fault models.

Every fault model starts with the aforementioned dry run toidentify injection points. Then, fault simulation is performedwith the current model for the current fault combination asexplained above. If the fault combination was found to beexploitable, the next iteration is analyzed as usual. However,if the fault combination is not exploitable but still producedvalid machine code, ARMORY starts recursively from thecurrent state with the next fault model. Hence, the next modelstarts with an M-ulator where a specific fault combination hasalready been applied, i.e., its subsequent dry-run captures theeffects of all previously induced faults, and then starts to injectits own faults on all newly identified injection points.

This way, the given list of fault models is applied to allpossible combinations of instructions/registers. However, theorder of fault models is also important, i.e., the outcomemight be different depending on which is injected first. Inaddition, unfiltered higher-order fault simulation results in alot of redundant results: if, e.g., a first-order fault is knownto be exploitable, adding a second fault to the execution isoftentimes exploitable as well but also a waste of computa-tion time. On the other hand, the additional faults can alsoinvalidate the exploitable effect of the first fault, e.g., bycrashing the chip or triggering other fault detection mecha-nisms. However, naturally, lower-order faults are much moresevere than higher-order faults since their attack complexity isconsiderably lower. In other words, invalidating a vulnerabilityby injecting additional faults does not fix the vulnerability,

P1N1N2

P1, P2P1, N1P1, N2P2, N1P2, N2N1, N2N2, N1

P1, P2, N1P1, P2, N2P1, N1, N2P1, N2, N1P2, N1, N2P2, N2, N1

Listing 1: Tested fault model combinations up to length 3for two permanent fault models P1 and P2 and two non-permanent models N1 and N2.

hence it is reasonable to optimize for the least-effort-requiringvulnerability. Therefore, we filter out such redundant faultsin our fault simulation workflow: ARMORY performs faultinjection simulation for all permutations of the input faultmodels while keeping already found fault combinations inmind. If at any point a fault combination would be injectedfor which a subset of included faults already was found to beexploitable, this fault combination is skipped. This saves anentire recursion every time, i.e., roughly O(n(m−i)) operationswith i being the index of the current fault model.

Since applying all fault models in all permutations is com-putationally quite complex, we applied several optimizationsto keep performance high. First, permanent faults are neverpermuted since they are all injected at the beginning. Hence,for permanent faults, it is enough to only consider all subsets,while for the non-permanent faults, indeed all subsets andtheir permutations have to be considered. On top of that, whenapplying a specific fault model multiple times, permutationsof this specific model do not matter as well. Listing 1shows an example of all tested fault model combinations fortwo different permanent fault models and two different non-permanent models when a maximum of three fault models atthe same time is set.

While the actual impact of this optimization depends onthe binary and the employed fault models, in our tests weachieved an improvement in execution time of up to two ordersof magnitude. However, since the actual saving depends on themodels used and the faults detected in the iterations, we cannotgive a better complexity expression than upper bounding thenumber of permutations pessimistically with m!.

Therefore, the overall complexity of higher-order faultanalysis is roughly O(nm · m!), although several internaloptimizations allow us to regard this as a very pessimistic.Note that this complexity results from the problem of ex-haustive simulation itself and is not due to the architectureof ARMORY. We would like to note that actual simulationtime cannot be accurately approximated by such formula sincethe eventual effects of faults on the binary play a major roleduring simulation: invalid Assembly can be regarded as notexploitable immediately, while a change in a loop counter mayresult in several hundred more instruction executions before adecision on exploitability can be made.

F. Further Optimizations

Since especially higher-order fault simulation is computa-tionally taxing, we employed several additional optimizations

7

to increase performance where possible. Note that these opti-mizations are generic strategies, tailored to our scenario, andautomatically also improve first-order fault simulation.

a) M-ulator Backups: As described in Section V-E, theemulator’s state is often saved and restored in order to reduceemulation time. This backup process includes saving/restoringall registers, CPU-state information, and RAM contents. Espe-cially the latter is a notable bottleneck if the entire memory iscopied all the time. Therefore, we went with the followingstrategy: on the initial backup, the whole RAM content iscopied. Then we make use of M-ulator’s before-memory-write hook and remember the start and end addresses ofthe memory range that will be overwritten. We specificallyremember two ranges, one near the stack pointer and one nearthe start of RAM, since these are the most common spots ofRAM access. Upon the next backup, only the modified RAM-ranges have to be updated from the emulator and likewise,when restoring a backup, only the stored ranges have to becopied back to the emulator’s memory. This optimized backupsystem again improved performance by an order of magnitude.

b) Efficient Multicore Support: ARMORY can automati-cally utilize all available cores by splitting the workload of thefirst fault model over all available CPU cores. Therefore, aslong as the list of injection points for the first fault model hasmore entries than cores are available, efficiency scales linearlywith available CPU cores. However, work is not simply split inequal parts, but rather processed in a queue that every threadfetches from. Simulation time varies heavily depending on theeffect of a specific fault, especially if multiple models are to betested. For instance, while one fault might immediately resultin invalid Assembly, another fault might result in an infiniteloop which would be simulated until reaching the timeout.Thus, a simple split of the work in equal parts would resultin some threads finishing way faster than others. In turn thiswould not utilize all CPU cores optimally. The queue solutionresults in every core processing the next injection point that isavailable until, in total, all injection points are processed. Thisway, cores will only idle when all injection points have alreadybeen processed or are currently assigned to other cores.

We noted in Section V-E that the order of permanent faultmodels does not matter. However, permanent register faultscan only be applied to the 17 available registers in ARM (R0-R15 and xPSR). Hence, if a permanent register fault modelis the first in the list of fault models, only a maximum of 17cores can be utilized. Therefore, the permanent fault modelsare automatically sorted to apply instruction faults first, ifavailable. Note that this has no impact on the output, butbenefits multithreading.

G. Applying ARMORY in Real-World Scenarios

ARMORY has several useful applications, however themain focus is always on automating parts of the processof an analyst. The analyst can, for example, be part of anevaluation lab’s certification team that analyzes an externalproduct or an in-house security engineer that tries to detectvulnerabilities in a product. In a typical application, an analystwould first gather fault models which he regards as realistic or

applicable, given the device under inspection, and then invokeARMORY to test (parts of) the binary for vulnerability withrespect to application-specific criteria which he formalizes inthe exploitability model.

a) Injecting Detected Faults into Real-World ICs: Notethat ARMORY does not decide whether a fault model isactually feasible in the real world. As for all simulation-based approaches, an analyst has to decide, based on hisown equipment or known state-of-the-art, which fault modelsseem reasonable. Likewise, because of its abstraction level,ARMORY does not take noise during fault injection intoaccount. However, this is strictly in line with previous workon fault injection simulation: only the effects of faults areanalyzed via fault models, the actual physical injection is notin scope of binary-level simulators.

b) Supported Fault Effects: For our analyses, we use anexemplary set of models that are commonly found in literature.Since our fault models are based on instruction-level andregister-level faults, it might seem that they are insufficientto model a lot of real-world fault effects. However, in thefollowing we exemplarily outline that our fault models indeedcover a wide variety of common real-world fault effects:

• Instruction skipping: by replacing the current instruc-tion with a NOP, instruction skip faults can be modeled.

• Faults on flash (program memory): any fault on pro-gram memory is equivalent to faulting instructions loadedfrom specific addresses.

• Faults on RAM (data memory): any fault on datamemory can be modeled via a register fault after loadingor before storing.

• Faulting operand registers: bit/byte faults on instruc-tions easily change the used registers of an instruction.More targeted modification is possible as well.

• Faulting addresses: faults on the immediate offsets ofinstructions or register faults on address registers canchange the source/destination of a memory access.

• Diverting control flow: faults on instructions can turnmany of them into branches, change the used branch con-dition, or simply change the branch offset. Register faultson the status register(s) can also change the outcome of aprevious condition evaluation and by faulting the programcounter register, the processor immediately branches to adifferent location in the binary.

• Instruction replacement: direct replacements of specificinstructions or instruction types is supported via the in-struction fault models. Note that, e.g., single-bit faults oninstructions also commonly result in different instructionsif the opcode encoding is faulted.

All above real-world fault effects are covered by ARMORY.Note that this list is not exhaustive, there are many moreeffects that our current fault models can represent. However,this list shows that ARMORY is indeed not restricted in itsworkings.

During physical fault injection and simulation alike, invalidinstructions may be loaded by the processor, e.g., invalidregister operands or undefined operations. This is caught by M-ulator, since it correctly reports cases of undefined behavioretc. ARMORY can then mark the currently tested fault as

8

not exploitable as a real chip would either crash/reset orexecute undefined behavior which is beyond the scope ofgeneral simulation. However, we show in our fifth experimentin Section VII-E, that M-ulator can be easily extended withprofiled behavior of a specific chip to even handle caseswhere simulation would otherwise have to be aborted due toundefined behavior.

c) Guaranteed Correctness: Since M-ulator is basedsolely on public architectural information and skips any casesof uncertainty, e.g., whenever undefined behavior is encoun-tered, ARMORY will never generate false positives. However,while ARMORY can simulate all kinds of instruction andregister faults, it is up to the analyst to decide which faultmodels are realistic on the target platform. In other words, ifone is able to reliably inject a given fault model, all exploitablefaults that ARMORY reports for this model are guaranteed towork on real hardware.

d) Timing Information: A major difficulty in fault anal-ysis is finding the point in time when a specific fault hasto be applied. While M-ulator is not cycle-accurate as thisinformation is implementation dependent (cf. Section V-A),every reported fault contains timing information as the exactposition in the sequence of executed instructions. This helpsanalysts to vastly narrow down the search space in time for ap-plying a specific fault. Note that this is also helpful when onlyrather imprecise faults are possible in practice: If ARMORYindicates numerous exploitable faults at a certain period intime, fault injection in general seems to be more successful inthat period. This information can then be leveraged by analyststo run a constrained brute-force attack instead of faulting overthe whole program execution.

e) Downsides of Abstraction: As mentioned in Sec-tion IV, emulation is always an abstraction. Hence, ARMORYcan miss exploitable faults that, for example, are enabled byinternal registers or a platform’s specific handling of undefinedbehavior. Commonly detailed design descriptions of the deviceunder inspection is not available, hence the employed levelof abstraction is still the most detailed representation that isgenerically available.

Note that ARMORY is specifically engineered and opti-mized for this scenario. If for a specific design hardware in-ternals are known, integrating this knowledge into ARMORYis not straightforward and would require changes to severaldistinct parts of ARMORY and M-ulator.

Furthermore, given that an analyst provides an incorrectexploitability mode, i.e., a model that does not capture all con-ditions under which an adversary could compromise security,ARMORY will not detect these vulnerabilities. However, thisis a general issue of fault assessment techniques. As a miti-gation, the analyst could employ highly generic exploitabilitymodels such as “unexpected output observed”, but this mightresult in many faults being reported as exploitable, whichwould not yield any useful information to an adversary.

VI. CASE STUDIES

In order to demonstrate that not taking final machine codeinto account leaves exploitable faults that are easily missedin manual analysis (cf. Section III), we apply ARMORYto two case studies in various settings. The first case studyfocuses on the non-cryptographic scenario of secure bootwhile the second case study targets DFA on AES. These aretwo well known scenarios in research on fault attacks andalso relevant in practice. Both case studies are used in fiveanalyses, each exploring a different setting. Our analyses alsohighlight the applicability and versatility of ARMORY forboth cryptographic and non-cryptographic scenarios.

In this section we describe the setup of the two case studies.The code of all case studies, the complete outputs of ourexperiments, and all additional data are available on GitHub.We implemented both case studies in C and compiled them toARM Assembly using ARM-GCC v6.3.1.

A. Case Study: Secure Boot

Many embedded systems feature an update mechanismin order to deliver improved firmware to already deployeddevices. However, especially in the Internet of Things (IoT),developers want to ensure that only their own firmware canbe executed on the device. Therefore, developers employ asecure boot mechanism [35]: The device is equipped with asmall ROM that contains a fixed bootloader that is burned-induring production. Upon startup, this bootloader fetches thecurrent firmware from an external memory and verifies that itstems from an authorized source. If the firmware is authorized,it is copied to RAM and executed, otherwise the system isshut down. The verification process is typically implementedvia cryptographic signatures and can also be implemented inseveral layers.

a) Attacker Target: If an attacker manages to skip or trickfirmware verification, he can execute arbitrary code on thedevice, potentially reading out sensitive data. Thus, the goalof the attacker is to introduce faults such that the bootloaderexecutes an unauthorized firmware. Note that we explicitly donot try to break the employed cryptographic mechanism, henceclassify this scenario as non-cryptographic.

b) Case Study Implementation: For the sake of simplic-ity, we implemented the firmware verification by computing anunpadded SHA256 checksum and comparing it to an expectedvalue. The firmware in our case study has exactly 128 bytes(externally supplied, unknown to the compiler), i.e., the SHAwill process the firmware in two blocks internally. Note thatthese simplifications do not make our results less represen-tative, since we never target the cryptographic computationsthemselves. Still, we uncover interesting exploitable faults thatare independent of the concrete verification mechanism asvisible in our results. During fault simulation, the suppliedfirmware never matches the expected SHA value, i.e., withoutexploitable faults the bootloader will always abort. The overallfunctionality can be summarized by the following pythonicpseudocode:

9

def main(firmware, expected_hash):hash = sha256(firmware)for i from 0 to 31:

if hash[i] != expected_hash[i]:report_error()return

execute_firmware()

The code of the sha256 function is part of the binary.c) Exploitability Model: A fault combination is re-

garded as exploitable if it leads to execution of theexecute_firmware() function although the hash valuesdo not match. Hence, exploitability in this case study is highlycontrol-flow-dependent.

B. Case Study: AES

Our second case study focuses on DFA of the AES cipher.Note that several variants of DFA on AES exist, dependingon the type of fault and faulting precision. W.l.o.g., we focuson a specific byte-fault: If an attacker is able to obtainfaulty ciphertexts where a fault affects a single byte afterthe MixColumns operation of round 7 and before the finalSubBytes operation, he is able to drastically reduce the searchspace of the key. Typically, only two ciphertext-faultytext-pairsper key byte are required to recover the whole key. For moredetails on DFA of AES we refer to [37], [38].

a) Attacker Target: Following the above description, theattacker’s goal is to inject faults which affect a single byteof the AES state in the specified period. Note that it is notrequired to control the exact outcome of the fault, it is onlyrequired to affect a single byte.

b) Case Study Implementation: As the base of our im-plementation we chose the well-known open-source “Tiny-AES”4, a full AES implementation for embedded deviceswhich is optimized for small code size. The overall functional-ity can be summarized by the following pythonic pseudocode:

def main(plaintxt, masterkey):rkeys = key_schedule(masterkey)ciphertext = encrypt(plaintxt, rkeys)report_done()

Since faults that apply before MixColumns of round 7 are notexploitable in the discussed DFA variant, ARMORY is invokedwith an M-ulator instance which has already been run untilthat point.

c) Exploitability Model: A fault combination is regardedas exploitable if the report_done() function is executedand the resulting ciphertext has exactly a single faulty byte inthe state somewhere after MixColumns of round 7 and beforethe final SubBytes operation. In ARMORY this is checked bycomputing the AES backwards on the resulting ciphertext andcomparing the intermediate state with the known intermediatevalues of a fault-free encryption. Exploitability in this casestudy is highly data-dependent.

Note that this model is a DFA-tailored version of the simple“wrong output is received” model, which would report a largeamount of false positives that cannot be exploited in a DFA.

4Tiny-AES on GitHub: https://github.com/kokke/tiny-AES-c

Instruction Faults

Model #

Perm

anen

t Skip 1Byte-Set 2

Byte-Clear 3Bit-Flip 4

Tran

sien

t Skip 5Byte-Set 6

Byte-Clear 7Bit-Flip 8

Register Faults

Model #

Perm

anen

t

Clear 9Fill 10

Byte-Set 11Byte-Clear 12

Bit-Set 13Bit-Clear 14

Register Faults

Model #

Unt

ilO

verw

r. Clear 15Fill 16

Byte-Set 17Byte-Clear 18

Bit-Flip 19

Tran

sien

t Clear 20Fill 21

Byte-Set 22Byte-Clear 23

Bit-Flip 24

Table I: Fault models used in the analyses

VII. OVERVIEW ON PERFORMED ANALYSES

The initial motivation of our work is that several exploitablefaults are easily missed in both automated and manual in-spection, if low-level information, e.g., physical addresses andoffsets, are neglected in the analysis (cf. Section III). We useARMORY to perform five analyses of our two case studies todemonstrate the severity and truth of that statement.

In the following we present the parameters and approacheswe analyze. The results are discussed subsequently in Sec-tion VIII. If not stated otherwise, all analyses were performedon the compiler-generated ARMv7-M Assembly code of ourtwo case studies for multiple optimization targets. In order tocompactly describe a specific test case, we use square brackets,e.g., [AES-DFA, no countermeasure, O3].

We configured the 24 fault models shown in Table I forARMORY. In the following we refer to the fault models bytheir number. Note that, while reliable targeted bit flips havenever been reported through physical fault injection, the faultmodel is still reasonable for faults that are only applied toa static value, i.e., they capture the isolated change of a bit.Thus, for the permanent register faults, we had to split the bit-flip model into bit-set and bit-clear since the register valuesare faulted anytime they change. Register fault models wereconfigured to be applied to registers R0–R12, LR and xPSR.

A. Analysis I – Influence of Compiler Optimization

Our first analysis forms the base for all other analyses.We investigate the general fault-exploitability of the two casestudies and take a look at the impact of different compileroptimization levels.

We compiled both case studies using the four optimizationtargets O1, O2, O3, and Os and ran ARMORY on thecompiler-generated assembly code. ARMORY tested all 24fault models in first order, i.e., injecting a single fault in oneexecution, for a total of 192 tested combinations.

B. Analysis II – Influence of Code Positioning

In our second analysis, we examine the impact of relativecode positioning. Note that the relative position of code blocksis not necessarily visible in high-level languages. We showthat especially control flow-related faults heavily depend on

10

the position within the binary, i.e., whether a certain addresscan be reached through a fault.

Again we analyzed both case studies with the four compileroptimization levels from Analysis I. There, the SHA256 codeand the AES key schedule were located at the lowest addresses(starting at 0x8000 in our case) followed by the remainingcode of the respective case study. For this analysis we swappedthese code blocks, leaving the SHA256 or the AES keyschedule at higher address spaces. In both cases, ARMORYapplied all 24 fault models as first order faults

C. Analysis III – Influence of Countermeasures

Our third analysis focuses on the impact of basic counter-measures on the overall number of exploitable faults. Specificcountermeasures mostly target a single class of faults and areevaluated by their success in detecting or preventing faultsof this specific fault class. However, the overall impact onexploitability, i.e., including faults of other models, is oftenunknown.

We selected two straightforward countermeasures, namely(1) instruction replacement [39] and (2) control flow checkingthrough signatures [40]. These are two well known principaltechniques on which many follow-up countermeasures arebased. They can also be jointly applied without mutuallyinterfering.

a) Instruction Replacement: Instruction replacement is afault prevention technique and aims at protecting against in-struction skip faults by duplicating all instructions or splittingthem into an equivalent set of instructions if direct duplicationis not possible. The technique was thoroughly analyzed andformally proven to protect against first-order instruction skipfaults by Moro et al. [39]. We implemented the countermeasurefollowing their descriptions.

b) Control Flow Check: Control flow checking throughsignatures is a fault detection technique by Oh et al. [40] andaims at protecting control flow, i.e., it aims to ensure that basicblocks are executed in the intended order. It reserves a registeras the Global Signature Register (GSR) and assigns a randomunique signature to each basic block. The general premise isthat a basic block can verify its predecessor through the GSR.When transitioning from basic block A to basic block B, theGSR is updated as GSR := GSR xor (IDA xor IDB), andthen compared to the expected IDB . If the results match, thecontrol flow was correct, and the GSR now holds the ID of thenew basic block. Otherwise, a fault was detected. The authorsacknowledge that several kinds of control flow faults stillcannot be detected by their technique, e.g., branches withina basic block.

c) Test Cases: We ran ARMORY on the compiler-generated Assembly code of both case studies for all opti-mization targets from Analysis I, first without any protection,then with each technique in isolation, and finally with bothtechniques combined. This leaves us with 32 combinationswhich were tested for exploitable faults. We applied all 24fault models in first order.

D. Analysis IV – Injecting Higher-Order Faults

In the fourth analysis, we examine higher-order fault in-jection. Most countermeasures are dedicated to first-orderfaults, i.e., a single fault in the whole computation. However,depending on the physical setup, an attacker may be able toinject more than just one fault, i.e., at multiple positions intime and/or at different positions on the device.

We selected all configurations of the AES-DFA case studyfrom Analysis III, i.e., with and without countermeasures usingthe four optimization options. The secure boot case studywas only analyzed without countermeasures, since the codewas too large to exhaustively simulate higher-order faults in areasonable timeframe.

Fault simulation was performed up to the second order withall fault models that did not target single bits.

E. Analysis V – Profiling Undefined Behavior

In the last analysis, we focus on the abstraction penaltythrough emulation. Naturally, an emulator will not be ableto find all faults that are possible in a real-world attack. Forexample, whenever M-ulator hits an encoding or a parametercombination which is specified as undefined or unpredictable,it has to abort emulation. However, by profiling a specificprocessor and implementing the actual behavior of thesecases into M-ulator, ARMORY can assess the real processormore accurately. We will collectively address all undefined,unpredictable, etc. cases as undefined behavior in this context.

We selected two platforms, namely (1) the Infineon XMC2Go featuring the ARM Cortex-M0 based XMC1100 pro-cessor (ARMv6-M) and (2) the STM32F4 Discovery boardfeaturing the ARM Cortex-M4 based STM32F4VGT processor(ARMv7-M). For the small ARMv6-M architecture, onlyeight instructions can actually trigger undefined behavior. Weprofiled all of them by manually manipulating a compiledtest binary and observing chip behavior with a hardwaredebugger on-chip. For the ARMv7-M architecture, the numberof undefined cases is too large to check manually, so wefocused on the same instructions as in the ARMv6-M setting.

VIII. RESULTS

In this section we present the results of the five studiesdescribed above and discuss their implications.

A. Results of Analysis I – Influence of Compiler Optimization

ARMORY took between 0.5 and 22 seconds for eachconfiguration on a single PC utilizing 56 cores. Table II showsthe combined results of this analysis and Analysis III. Foreach case study and each configuration, we list the time (innumber of executed instructions) from the start of the casestudy until the bootloader detects the modified firmware orthe AES returns its ciphertext, followed by the number ofexploitable faults for all 24 fault models. Note that executiontimes for the AES-DFA case study are relatively low since westart fault simulation after the MixColumns step of the seventhround. We focus on the results of Analysis I in this section.

11

Opt. Time Instruction Fault Models Register Fault Models

Permanent Transient Permanent Until Overwrite Transient1 2 3 4 5 6 7 8 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Analysis I: Secure Boot

O1 10489 0 0 0 2 0 0 0 15 1 0 2 1 0 0 0 0 2 0 0 0 0 2O2 10742 1 1 0 7 1 0 0 4 1 0 2 0 0 0 0 0 2 0 0 0 0 2O3 6892 1 1 0 8 1 0 0 6 1 0 1 0 0 0 0 0 1 0 0 0 0 1Os 10825 1 1 0 2 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0

Analysis III: Secure Boot with Instruction Replacement Countermeasure

O1 31261 0 +1 0 +6 0 +1 0 +247 0 0 -1 -1 0 0 0 0 -2 0 0 0 0 -2O2 29328 -1 +1 0 +12 -1 +1 0 +83 0 0 -1 0 0 0 0 0 -2 0 0 0 0 -2O3 19255 -1 +2 0 +21 -1 +2 0 +363 0 0 0 0 0 0 0 +2 -1 0 0 0 0 -1Os 33267 -1 +2 0 +10 0 +2 0 +212 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Analysis III: Secure Boot with Control Flow Checking Countermeasure

O1 22258 0 0 0 -2 0 0 0 -15 0 0 -1 -1 0 0 0 0 -2 0 0 0 0 -2O2 29476 -1 -1 0 -4 -1 0 0 -4 0 0 -1 0 0 0 0 0 -2 0 0 0 0 -2O3 10155 -1 -1 0 -5 -1 0 0 -6 0 0 0 0 0 0 0 0 -1 0 0 0 0 -1Os 21737 0 -1 0 -1 0 0 0 -1 0 -1 0 0 0 0 0 0 0 0 0 0 0 0

Analysis III: Secure Boot with both Countermeasures

O1 58245 0 0 0 -2 0 0 0 -15 0 0 -1 -1 0 0 0 0 -2 0 0 0 0 -2O2 74632 -1 -1 0 -7 -1 0 0 -4 0 0 -1 0 0 0 0 0 -2 0 0 0 0 -2O3 27615 -1 -1 0 -8 -1 0 0 -6 0 0 0 0 0 0 0 0 -1 0 0 0 0 -1Os 57313 -1 -1 0 -2 0 0 0 -1 0 -1 0 0 0 0 0 0 0 0 0 0 0 0

Analysis I: AES-DFA

O1 1320 24 15 25 282 568 136 948 8082 0 0 0 0 610 636 812 648 7452 621 717 2090 943 18010O2 1311 24 24 24 215 566 138 959 7002 0 0 1 0 570 619 705 608 6656 633 729 2112 922 17990O3 874 73 31 120 920 503 116 971 6311 0 0 1 40 568 597 751 618 8899 533 559 1279 695 12887Os 1382 24 16 24 240 590 163 1096 7908 0 0 0 0 610 636 908 678 7997 629 724 2298 938 18283

Analysis III: AES-DFA with Instruction Replacement Countermeasure

O1 3848 -24 +5 +1 +34 -568 +263 +464 +2978 0 0 0 0 +1048 +1130 +1453 +1232 +13398 +256 +214 -718 +317 -4550O2 3877 -24 -4 +30 +90 -566 +291 +595 +4024 0 0 0 0 +1008 +1113 +1693 +1254 +14297 +256 +214 -779 +334 -4713O3 2291 -73 -7 +46 +233 -503 +124 +475 +4848 0 0 -1 -2 +949 +1008 +1393 +1013 +15240 +192 +229 -298 +207 -2403Os 4007 -24 -15 +2 +80 -590 +212 +430 +2691 0 0 0 0 +1080 +1162 +1439 +1292 +14563 +264 +223 -891 +338 -4656

Analysis III: AES-DFA with Control Flow Checking Countermeasure

O1 3074 0 +21 +39 +215 +4 +139 +269 +1103 0 0 0 0 0 0 +82 +32 +704 0 0 -11 -9 +104O2 3054 0 +12 +37 +262 +1 +1 +268 +1197 0 0 -1 +1 0 -1 +107 +34 +727 0 0 0 +6 -92O3 1060 +6 +9 -2 +78 +111 +14 +232 +1166 0 0 +8 +3 +28 +38 +80 0 +698 +36 +32 +140 +59 +1290Os 3114 0 -16 +1 -49 +38 -46 +56 +413 0 0 0 0 +14 +17 -6 +14 +650 +10 +7 -106 -8 +814

Analysis III: AES-DFA with both Countermeasures

O1 7963 -24 -3 +25 +112 -568 +254 +368 +3440 0 0 0 0 +1048 +1130 +1637 +1294 +14770 +256 +214 -729 +317 -4550O2 7899 -24 -12 +26 +204 -566 +229 +557 +3913 0 0 -1 +1 +1008 +1111 +1863 +1258 +14449 +256 +213 -759 +334 -4697O3 2638 -73 +1 +52 +306 -503 +125 +1021 +4917 0 0 +8 +8 +975 +1064 +1593 +969 +15719 +206 +252 -255 +221 -2118Os 8073 -24 -16 +1 +18 -590 +237 +401 +3044 0 0 0 0 +1104 +1196 +1749 +1316 +15525 +278 +239 -861 +352 -4415

Table II: Results of Analyses I and III: Number of exploitable faults by fault model (cf. Table I). Models 9 and 10 are excludedsince they never resulted in exploitable faults. Colored values show the increase of exploitable faults relative to the respectiveunprotected base case.

The first thing to notice is that the AES-DFA case studyshows much more exploitable faults than the secure boot casestudy. This originates from the type of faults that are requiredfor a “successful” exploitation for the two case studies (cf.Section VI): Exploitability of the secure boot case study iscontrol-flow-dependent and faults that meaningfully changethe control flow to circumvent checksum verification are rare.On the other hand, exploitability of the AES-DFA case studyis data-dependent with few constraints. This enables almostany fault that has a very localized effect to be exploitable.Notably, permanent register faults (models 9-14) seem to havevery little effect in the AES-DFA case study in general. This isreasonable, since the chosen variant of DFA relies on localizeddata faults, while permanent register faults may affect theprocessed data multiple times. However, for the secure bootcase study, exploitability with these faults is comparable to theother models. Depending on how the final hash comparison isimplemented, a permanent fault on a register may set all resultsto “equals”, effectively circumventing the verification process.In general, most exploitable faults in the secure boot case studychanged a branch target address or turned an instruction intoa branch.

a) General Observations: The degree of freedom for asuccessful attack and the type of exploitability, i.e., data-drivenor control-flow-driven, of a case study have a major impacton fault-vulnerability. While naturally with a higher degreeof freedom an attacker has more space to work with, it isinteresting to see the huge difference in our two case studies.In terms of compiler optimizations, they definitely have anoticeable impact on exploitability. However, in our casestudies, no consistent “best optimization” can be made out,i.e., an engineer cannot simply select a specific optimizationlevel and expect better fault resistance.

B. Results of Analysis II – Influence of Code Positioning

Since the size and register usage of the analyzed binaries didnot notably change, execution times are similar to Analysis I.Table III shows the results in a condensed form. The impact ofmoving code around is visible in both case studies, althoughthe changes in the number of exploitable faults are of differentseverity in each case study.

For the secure boot case study, the impact is quite signifi-cant, since for O3, the number of exploitable faults increases

12

Opt. Instruction Fault Models Register Fault Models

Permanent Transient Permanent Until Overwrite Transient1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Analysis II: Secure Boot

O1 0 0 0 0 0 0 0 -13 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0O2 0 0 +1 +4 0 0 +1 +4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0O3 0 0 +1 +3 0 0 +1 +2 0 0 0 0 +1 0 0 0 0 0 +1 0 0 0 0 +1Os 0 0 0 0 0 0 0 0 0 0 0 0 0 +1 0 0 0 0 +1 0 0 0 0 +1

Analysis II: AES-DFA

O1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0O2 0 0 0 0 0 0 0 +1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1O3 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 -1 0 0 -1 0 -1 0 0 -1Os 0 0 0 0 0 0 0 -6 0 0 0 0 0 0 0 0 0 +1 0 0 0 0 +1 0

Table III: Results of Analysis II: Change in exploitable faults by swapping parts of the code in their address spaces.

from 17 to 27. This is due to the exploitability condition:as soon as the firmware is executed, the fault is regarded asexploitable. By moving the code around, physical addresseschange, which affects how faults can modify control flow.It is instructive to look at a concrete example from [SecureBoot, O1]: placing the SHA code in a higher address spacethan the verification code enables a single-bit instruction fault(fault model 8), which affects the relative offset of a branchinstruction. The new offset happens to point to the very end ofthe verification code, right where firmware execution is started.Note that this fault was not introduced by actually changingcode, but rather by its final location in the binary. Typically,a software engineer only specifies the general memory regionfor all code and the final position of code blocks is managed bythe linker. Hence, this positioning of code blocks is outside ofthe software engineer’s direct scope or control. Crucially, theresulting change in analyzing physical addresses and offsetscan result in new vulnerability that would go unnoticed.

For the AES case study, the largest impact occurs for Oswhere only 8 faults are affected. This is a rather insignificantdifference, with total values ranging in the thousands. Thesmall impact despite already large numbers originates from thedata-dependent exploitability, which naturally excludes faultsthat result in major control flow changes. Since this casestudy is very sensitive to faults on registers and arithmeticinstructions, the physical addresses of instructions are lessrelevant.

a) General Observations: The position of code doeshave an impact on exploitability. The change in vulnerabilitywas introduced invisible to the software engineer when branchtargets could suddenly be diverted to another useful address.Notably, this impact can neither be analyzed nor can coun-termeasures incorporate this information at any layer abovemachine code, since physical addresses and offsets are notavailable at those stages.

Systems where faults are exploitable if data is corrupted aremuch less affected through positioning than systems where theattacker targets control flow.

C. Results of Analysis III – Influence of Countermeasures

ARMORY took between 1 and 6 minutes (secure boot) andbetween 3 and 9 seconds (AES-DFA) for each configurationon a single machine utilizing 56 cores. Table II shows the

results of our analysis as the relative increase in exploitablefaults compared to the setting without countermeasures fromAnalysis I. We verified that both countermeasures success-fully defend against the intended attacker models. This isalso reflected in the exploitable faults: with the instructionreplacement technique, there were no exploitable instructionskip faults and with control flow checking, most faults thatresulted in illegal branches were detected.

In the secure boot case study, the combination of both coun-termeasures eliminates almost all exploitable faults. However,applying instruction replacement alone actually increases thenumber of exploitable faults by 428% - 2812% comparedto the unprotected setting. More crucially, in the AES-DFAcase study, the total number of exploitable faults alarminglyincreased by any combination of countermeasures. To betteranalyze the issue, we visualized the faults using heatmapsby aggregating the execution time in 200 bins. Two of theseheatmaps are shown in Figure 2. The heatmap visualizationsfor all configurations are available on GitHub.

The visualization for [Secure Boot, instruction replacement,O2] is shown in Figure 2a. Interestingly, exploitable faultswithin the SHA computation exist in this and a few otherconfigurations. Taking a closer look at the numerous faults atthe start and middle of the SHA computation, they are mostlysimilar: a transient single-bit fault on a branch instructionchanges the branch target. Interestingly, this target now pointsto the second half of another 32-bit instruction, i.e., its 16lower bits. In our case, these 16 bits happen to also be a validencoding of a 16-bit shift instruction. Therefore, executioncontinues and since the faulted branch target is after hashverification, an unauthorized firmware is executed.

For the AES-DFA case study, exploitability increased heav-ily. However, there is no direct correlation between codesize/execution length and exploitability. Figure 2b shows aheatmap for the O1-optimized code with both countermeasurescombined. For all configurations of the AES-DFA case study,there seems to be a correlation between the success of differentfault models: Whenever numerous single-bit register faults areexploitable (models 19 and 24) the number of register faultsof the same type that target larger groups of bits also increases.The same effect is also slightly visible between the number ofinstruction bit flips (model 8) and related byte-level faults.

a) General Observations: Both countermeasures per-form perfectly fine within their constrained attacker models.

13

(a) [Secure Boot, instruction replacement, O2]

(b) [AES-DFA, both countermeasures, O1]

Figure 2: Visualization of non-permanent faults using heatmaps. Whitespace indicates no exploitable faults.

Regarding secure boot, applying both countermeasures actu-ally results in an almost-secure implementation. However, inthe AES-DFA case study, all countermeasure combinationsincreased the overall exploitability. We emphasize that thisis not an oversight in the respective countermeasures andthat we do not aim to evaluate their strengths or suitability.Especially since the countermeasures do not aim to protectagainst data faults, which the AES-DFA case study is highlysensitive to. Instead, we highlight a major pitfall when apply-ing countermeasures in general by these examples: throughthe inclusion of additional instructions, presumably unrelatedfault models may substantially gain attack surface. While theeffect of a countermeasure might be verifiable within its targetfault model, the effect when faced with other fault models ishard to predict in general and has to be evaluated for eachapplication on a case-by-case basis.

D. Results of Analysis IV – Injecting Higher-Order Faults

Exhaustive fault simulation for the no countermeasuresconfigurations of the secure boot case study took from 8hours (O3) up to 24 hours (O2). For the AES-DFA casestudy where all configurations were tested, ARMORY tookfrom 24 seconds (no countermeasure, O3) up to 3.5 hours(both countermeasures combined, O3). Figure 3 visualizes theresults for two selected configurations, namely (a) [SecureBoot, no countermeasures, O2] and (b) [AES-DFA, no coun-termeasures, O2]. Every dot resembles an exploitable second-order fault. While isolated dots require precise fault injectionto exploit, it is interesting to see that both Figures 3a and3b contain horizontal or vertical lines. These lines indicatethat, while one fault has to be at a very precise point intime, a second fault within a quite large time range results

in exploitable behavior. This behavior is caused mainly byrecurring instructions where the first fault sets a preconditionand the second fault causes exploitation (vertical line) or viceversa (horizontal line). A diagonal line indicates that a faultcombination always targets the same instructions/registers butis exploitable at multiple loop iterations, advancing the point intime for both faults each loop. Interestingly the visualizationsdirectly show where the two SHA blocks are processed orAES rounds are performed.

Looking at the results in detail, we identified multiple unex-pected but critical faults. For example, two transient instructionbyte-set faults (model 6) resulted in the following two changes:First, a MOV R2, SP was faulted to MOV PC, PC which inARM effectively is a “skip the next instruction”, since thePC always returns its internal value plus four when read.This effectively skipped the call to the SHA256 function.Yet, this fault alone is not exploitable, since the empty, i.e.,zero initialized, SHA-output-array would be compared to thearray holding the expected hash. The second fault affects theload of the first byte of the correct hash value, changingLDRB R1, [R2, #1]! to LDRB R1, [R2, #0xff]!.Simplified, this permanently changes the pointer of the correcthash value to an area of RAM that happens to contain onlyzeroes before the first value is loaded. Now, the verificationcode effectively compares two all-zero arrays and thus acceptsthe unauthorized firmware. Clearly, such a behavior wouldbe hard to identify, even in a manual inspection of thedisassembled machine code.

a) General Observations: Exhaustive higher-order faultsimulation is a problem limited by its own size. With anexponentially growing search space the analyst either has tolimit the used fault models or invest more computation power

14

(a) Secure boot case study configuration [no countermeasures, O2] (b) AES-DFA case study configuration [no countermeasures, O2]

Figure 3: Visualization of selected results of Analysis IV. Each dot is an exploitable second-order fault, the x-coordinate isthe time of the first fault and the y-coordinate the time of the second fault. A stronger color indicates more exploitable faultsat that location.

and time. Yet, our results show that an adversary often hasa large degree of freedom where to inject his two faults aslong as he manages to precisely inject one of them. Thismight be especially relevant for jitter- or random-delay-basedcountermeasures that leverage the assumption that high preci-sion for multiple faults is always required. We demonstratedthat ARMORY is capable of uncovering higher-order faultcombinations which are highly unlikely to be found by manualinspection, cf. the discussed example.

E. Results of Analysis V – Profiling Undefined Behavior

In the following, we briefly explain the profiled behavior ofthe two processors and present the results of using ARMORYwith a profiling-enhanced M-ulator.

a) XMC1100 Profiling: Profiling showed that some in-structions behave as expected, even in cases of presumablyundefined behavior, while others completely change theirfunctionality or simply result in a hard fault. Table IVacontains the detailed profiling results for the XMC1000 of allARMv6-M instructions that can potentially result in undefinedbehavior. Especially interesting behavior was profiled for thePUSH/POP and LDM/STM instructions if the given register listis empty:

In that case, POP reads the top of the stack into LR withoutchanging the stack pointer. Analogously, PUSH overrides thetop of the stack with the value in LR without changing thestack pointer.LDM reads the value addressed by the base register into the

link register LR. Interestingly though, STM not only overridesthe value addressed by the base register with the value in LR,but also increments the value in the base register by 4.

The unintuitive behavior of all 4 instructions and theirvariants may definitely lead to additional exploitable faults,depending on the concrete application. However, for bothcase studies (no countermeasures were applied to ARMv6-M(thumb1) code), the number of first-order exploitable faults didnot change when implementing this behavior in M-ulator. Thisresults mostly from the given Assembly code: the used registerlists for PUSH/POP/STM/LDM could most of the time simplynot be faulted to be empty with the employed fault models.

The few remaining cases where an empty register list couldbe provoked, did not lead to exploitable behavior in our code.

b) STM32F4VGT Profiling: Table IVb contains the pro-filing results of the same instructions that were profiled on theXMC1000. Interestingly some behavior changed: PUSH, POP,LDM, and STM now simply behave like a NOP in the cases ofundefined behavior.

Running ARMORY with a modified M-ulator that imple-ments the profiled behavior resulted in the detection of afew additional exploitable faults. We compared the numberof exploitable faults for both case studies and all counter-measure combinations as in Analysis III for first-order faults.In the AES-DFA case study, the number of exploitable faultsincreased by up to 39 faults in 12 of the 16 configurations.In the secure boot case study only [instruction replacement,Os] saw an increase of 6 faults. However, especially these newfaults were very interesting since they did not target any of theprofiled instructions directly but rather were found since M-ulator did not have to abort because of undefined behavior. Weused ARMORY’s fault tracer to inspect said faults in detail:All 6 faults are instruction bit-flip faults and manipulated aninstruction within the SHA to become a branch instruction.Interestingly, this branch jumps behind the end of our code –into the literal pool where the constants are stored that are usedin SHA. These constants are now interpreted as instructionencodings and are executed like code. While the generic M-ulator quickly reported undefined behavior and exited, theprofiled variant was able to continue as it hit one of the profilededge cases. Eventually, a part of another SHA constant wasdecoded as a valid branch, jumping right behind the hashcomparison loop and eventually executing the unauthorizedfirmware. Again, this is a fault that we are sure would havebeen missed in manual analysis and could not have beenanalyzed without physical addresses and a profiled emulator.

c) General Observations: While the change in ex-ploitable faults is small in our case studies, this cannot begeneralized to other implementations or platforms. Especiallyfor the STM32F4VGT we only scratched the surface byprofiling only a small subset of all potential instructions.Still, our results show that emulation-based fault simulation

15

Instruction Undefined Behavior Condition Profiled Behavior

ADD Rdn, Rm Rdn == Rm == 15 (PC) hard fault ×

CMP Rn, Rm (not both from R0-R7) Rn and Rm both from R0-R7 compares both registers �

{BX/BLX} RmRm == 15 (PC) branches to the value of the PC register �

last three instruction bits are not 0 clears the T bit (thumb mode bit) in EPSR �

POP <register list> register list empty equivalent to LDR LR, [SP], SP unchanged �

PUSH <register list> register list empty equivalent to STR LR, [SP], SP unchanged �

LDM Rn! <register list> register list empty equivalent to LDR LR, [Rn], Rn unchanged �

STM Rn! <register list>register list empty equivalent to STR LR, [Rn], #4 �

Rn in register list but not lowest correctly stores current value of Rn �register in register list and updates Rn in the end

(a) Profiled undefined behavior of the XMC1100 processor on the Infineon XMC 2Go.

Instruction Undefined Behavior Condition Profiled Behavior

ADD Rdn, Rm Rdn == Rm == 15 (PC) hard fault ×

CMP Rn, Rm (not both from R0-R7) Rn and Rm both from R0-R7 correctly compares both registers �

{BX/BLX} RmRm == 15 (PC) hard fault ×

last three instruction bits are not 0 correctly executes branch �

{PUSH/POP} <register list> register list empty equivalent to NOP �

LDM Rn! <register list> register list empty equivalent to NOP �

STM Rn! <register list>register list empty equivalent to NOP �

Rn in register list but not lowest correctly stores current value of Rn �register in register list and updates Rn in the end

(b) Profiled undefined behavior of the STM32F407VGT processor.

Table IV: Profiling results of Analysis V. Cases which stop execution do not lead to new faults and, thus, are marked with ×.Those which allow to simply continue emulation in a way that may be anticipated, may surface new faults and are marked with�. Cases which notably change instruction behavior are marked with �, since their effects cannot be anticipated by engineersand analysts without profiling.

definitely misses some faults which can be crucial in real-world applications. On the other hand, it also demonstratesthat M-ulator can be easily adjusted to incorporate profiledbehavior. Looking at individual examples, ARMORY againuncovered faults that are almost impossible to detect in manualanalysis and that are invisible when analyzing only high-levelinformation.

F. Discussion

We analyzed the impact of various parameters and ap-proaches on exploitability through fault attacks. Regardlessof the specific aspects that were targeted by an individualanalysis, a common issue was exploitable faults that stemfrom the modification of addresses or offsets. Note that saidmodifications were induced by all kinds of fault effects, e.g.,faults on instructions, operands, immediates, or register values.We noted several times that the necessary information toanalyze such potential vulnerabilities is only available in thefinal machine code. Hence, countermeasures applied at anyhigher code-layer cannot incorporate this data. Our analy-ses that involved countermeasures also showed that, while

countermeasures may reduce faults in their target domain, theopposite can happen for other fault models – an increase invulnerability.

A solution might be to apply countermeasures on the finalmachine code. However, modifying the final binary in orderto prevent such faults is difficult as well, since insertinginstructions at this stage results in a change of numerousaddress offsets for other instructions, potentially introducingnew vulnerabilities, resulting in a vicious cycle. Therefore,the development of new countermeasures that take machinecode information into account is an interesting and importantresearch challenge.

IX. CONCLUSION

In this work, we presented ARMORY as a powerful andaccessible tool for automated exhaustive fault simulation. Itutilizes M-ulator as its underlying emulator that we developedspecifically with fault injection in mind. The fault simulatoritself is capable to check a large variety of user-defined faultmodels even at higher orders – while at the same time keepingthe complexity under control through clever shortcuts.

16

Using ARMORY we demonstrated the necessity to in-corporate machine code information into analysis and coun-termeasures. Fully automated, ARMORY detected numerousfaults that would have been highly unlikely to be found inmanual analysis. Therefore, we highlight the developmentof countermeasures against fault injection attacks that takelow-level information from machine code into account as animportant direction for future research. With M-ulator andARMORY available as open-source, analysts and researcherscan develop new techniques and automatically verify theireffectiveness against a large variety of fault models. Since ourapproach is not restricted to security applications but can alsobe used, e.g., for safety critical code, we regard our resultsand ARMORY as a helpful tool to advance the state of theart.

ACKNOWLEDGMENTS

We would like to thank Felix Wegener, Benjamin Kollenda,Phillip Koppe, Marc Fyrbiak, and Bastian Richter for helpfultechnical discussions. This work was supported in part by DFGExcellence Strategy grant 39078197 (EXC 2092, CASA) andthrough ERC grant 695022.

REFERENCES

[1] T. Given-Wilson, N. Jafri, J. Lanet, and A. Legay, “An AutomatedFormal Process for Detecting Fault Injection Vulnerabilities in Binariesand Case Study on PRESENT,” in TrustCom/BigDataSE/ICESS. IEEEComputer Society, 2017, pp. 293–300.

[2] D. Boneh, R. A. DeMillo, and R. J. Lipton, “On the Importance ofChecking Cryptographic Protocols for Faults (Extended Abstract),” inEUROCRYPT. Springer, 1997, pp. 37–51.

[3] I. Verbauwhede, D. Karaklajic, and J. Schmidt, “The fault attack jungle- A classification model to guide you,” in FDTC. IEEE, 2011, pp. 3–8.

[4] F. Lu, G. D. Natale, M. Flottes, and B. Rouzeyre, “Laser-induced faultsimulation,” in DSD. IEEE, 2013, pp. 609–614.

[5] J. Breier, X. Hou, and Y. Liu, “Fault Attacks Made Easy: DifferentialFault Analysis Automation on Assembly Code,” IACR TCHES, vol.2018, no. 2, pp. 96–122, 2018.

[6] S. Saha, D. Mukhopadhyay, and P. Dasgupta, “ExpFault: An AutomatedFramework for Exploitable Fault Characterization in Block Ciphers,”IACR TCHES, vol. 2018, no. 2, pp. 242–276, 2018.

[7] A. K. Lenstra, “Memo on RSA signature generation in thepresence of faults,” 1996, manuscript. [Online]. Available: http://infoscience.epfl.ch/record/164524

[8] C. Aumuller, P. Bier, W. Fischer, P. Hofreiter, and J. Seifert, “FaultAttacks on RSA with CRT: Concrete Results and Practical Counter-measures,” in CHES. Springer, 2002, pp. 260–275.

[9] M. Agoyan, J. Dutertre, D. Naccache, B. Robisson, and A. Tria, “WhenClocks Fail: On Critical Paths and Clock Faults,” in CARDIS. Springer,2010, pp. 182–193.

[10] J.-J. Quisquater, “Eddy current for magnetic analysis with active sensor,”Proceedings of Esmart, 2002, pp. 185–194, 2002.

[11] S. P. Skorobogatov and R. J. Anderson, “Optical Fault InductionAttacks,” in CHES. Springer, 2002, pp. 2–12.

[12] C. Dobraunig, M. Eichlseder, T. Korak, S. Mangard, F. Mendel, andR. Primas, “SIFA: Exploiting Ineffective Fault Inductions on SymmetricCryptography,” IACR TCHES, vol. 2018, no. 3, pp. 547–572, 2018.

[13] H. Bar-El, H. Choukri, D. Naccache, M. Tunstall, and C. Whelan, “Thesorcerer’s apprentice guide to fault attacks,” Proceedings of the IEEE,vol. 94, no. 2, pp. 370–382, 2006.

[14] D. Karaklajic, J. Schmidt, and I. Verbauwhede, “Hardware Designer’sGuide to Fault Attacks,” IEEE Trans. Very Large Scale Integr. Syst.,vol. 21, no. 12, pp. 2295–2306, 2013.

[15] B. Selmke, J. Heyszl, and G. Sigl, “Attack on a DFA Protected AES bySimultaneous Laser Fault Injections,” in FDTC. IEEE, 2016.

[16] D. Boneh, R. A. DeMillo, and R. J. Lipton, “On the Importanceof Eliminating Errors in Cryptographic Computations,” J. Cryptology,vol. 14, no. 2, pp. 101–119, 2001.

[17] A. Barenghi, L. Breveglieri, I. Koren, and D. Naccache, “Fault InjectionAttacks on Cryptographic Devices: Theory, Practice, and Countermea-sures,” Proceedings of the IEEE, vol. 100, no. 11, pp. 3056–3076, 2012.

[18] X. Guo, D. Mukhopadhyay, C. Jin, and R. Karri, “Security analysis ofconcurrent error detection against differential fault analysis,” J. Cryptogr.Eng., vol. 5, no. 3, pp. 153–169, 2015.

[19] A. Aghaie, A. Moradi, S. Rasoolzadeh, A. R. Shahmirzadi, F. Schellen-berg, and T. Schneider, “Impeccable Circuits,” IEEE Trans. Computers,vol. 69, no. 3, pp. 361–376, 2020.

[20] C. Clavier, “Secret external encodings do not prevent transient faultanalysis,” in CHES, ser. Lecture Notes in Computer Science, vol. 4727.Springer, 2007, pp. 181–194.

[21] S. Yen and M. Joye, “Checking Before Output May Not Be EnoughAgainst Fault-Based Cryptanalysis,” IEEE Trans. Computers, vol. 49,no. 9, pp. 967–970, 2000.

[22] C. Dobraunig, M. Eichlseder, T. Korak, S. Mangard, F. Mendel, andR. Primas, “SIFA: Exploiting Ineffective Fault Inductions on SymmetricCryptography,” IACR Trans. Cryptogr. Hardw. Embed. Syst., vol. 2018,no. 3, pp. 547–572, 2018.

[23] J. Breier, M. Khairallah, X. Hou, and Y. Liu, “A Countermeasure AgainstStatistical Ineffective Fault Analysis,” IACR Cryptol. ePrint Arch., vol.2019, p. 515, 2019.

[24] J. Daemen, C. Dobraunig, M. Eichlseder, H. Groß, F. Mendel, andR. Primas, “Protecting against Statistical Ineffective Fault Attacks,”IACR Trans. Cryptogr. Hardw. Embed. Syst., vol. 2020, no. 3, pp. 508–543, 2020.

[25] A. Battistello and C. Giraud, “Fault Analysis of Infective AES Compu-tations,” in FDTC. IEEE Computer Society, 2013, pp. 101–107.

[26] R. B. Carpi, S. Picek, L. Batina, F. Menarini, D. Jakobovic, andM. Golub, “Glitch It If You Can: Parameter Search Strategies forSuccessful Fault Injection,” in CARDIS. Springer, 2013, pp. 236–252.

[27] F. Schellenberg, M. Finkeldey, B. Richter, M. Schapers, N. Gerhardt,M. Hofmann, and C. Paar, “On the Complexity Reduction of Laser FaultInjection Campaigns Using OBIC Measurements,” in FDTC. IEEE,2015, pp. 14–27.

[28] A. Papadimitriou, D. Hely, V. Beroulle, P. Maistri, and R. Leveugle,“Analysis of laser-induced errors: RTL fault models versus layoutlocality characteristics,” Microprocess. Microsystems, vol. 47, pp. 64–73, 2016.

[29] A. Papadimitriou, M. Tampas, D. Hely, V. Beroulle, P. Maistri, andR. Leveugle, “Validation of RTL laser fault injection model with respectto layout information,” in HOST. IEEE, 2015, pp. 78–81.

[30] A. Papadimitriou, D. Hely, V. Beroulle, P. Maistri, and R. Leveugle, “Amultiple fault injection methodology based on cone partitioning towardsRTL modeling of laser attacks,” in DATE, 2014, pp. 1–4.

[31] M. Gay, T. Paxian, D. Upadhyaya, B. Becker, and I. Polian, “Hardware-Oriented Algebraic Fault Attack Framework with Multiple Fault Injec-tion Support,” in FDTC. IEEE, 2019, pp. 25–32.

[32] J. Breier, X. Hou, and S. Bhasin, Eds., Automated Methods in Crypto-graphic Fault Analysis. Springer, 2019.

[33] L. Goubet, K. Heydemann, E. Encrenaz, and R. D. Keulenaer, “EfficientDesign and Evaluation of Countermeasures against Fault Attacks UsingFormal Verification,” in CARDIS. Springer, 2015.

[34] P. Khanna, C. Rebeiro, and A. Hazra, “XFC: A Framework for eX-ploitable Fault Characterization in Block Ciphers,” in DAC. ACM,2017, pp. 8:1–8:6.

[35] M. Bogaard and N. Timmers, “Secure Boot Under Attack:Simulation to Enhance Fault Injection & Defenses,” 2018, blackHat. [Online]. Available: https://www.riscure.com/uploads/2019/06/Riscure Secure-Boot-Under-Attack-Simulation.pdf

[36] L. Dureuil, M. Potet, P. de Choudens, C. Dumas, and J. Clediere, “FromCode Review to Fault Injection Attacks: Filling the Gap Using FaultModel Inference,” in CARDIS. Springer, 2015, pp. 107–124.

[37] P. Dusart, G. Letourneux, and O. Vivolo, “Differential fault analysis onAES,” in ACNS. Springer, 2003, pp. 293–306.

[38] G. Piret and J.-J. Quisquater, “A differential fault attack techniqueagainst SPN structures, with application to the AES and KHAZAD,”in CHES. Springer, 2003, pp. 77–88.

[39] N. Moro, K. Heydemann, E. Encrenaz, and B. Robisson, “FormalVerification of a Software Countermeasure Against Instruction SkipAttacks,” J. Cryptographic Engineering, vol. 4, no. 3, pp. 145–156,2014.

[40] N. Oh, P. P. Shirvani, and E. J. McCluskey, “Control-Flow Checking bySoftware Signatures,” IEEE transactions on Reliability, vol. 51, no. 1,pp. 111–122, 2002.