FaultFinder: from Faulty Output to Fault Model - an Automated Approach
Fault attacks allow an adversary to break mathematically sound cryptography (e.g. AES, RSA, or ECC) and other security-relevant algorithms (e.g. PIN checks) by injecting a fault during the computation on a physical device. As a result, the target device computes and returns a faulty result, which can be used to recover cryptographic secrets and other sensitive information very quickly. Techniques to inject faults are manifold and range from glitches in the supply voltage over strong electro-magnetic fields to exposure of a chip to laser or UV light.
Fault attacks represent a major threat for IoT and in general embedded devices, where the adversary usually has physical access to the processors in the device. In the context of autonomous vehicles, faults attacks will also represent a major threat, as car tuners will be highly motivated to bypass security mechanisms and modify the firmware of the vehicle in order to get the car to drive faster, ignore certain traffic rules, etc.
As of today, evaluating to which extent a device is susceptible to fault injection is a mostly manual process, requiring significant expert knowledge and often expensive, complex lab equipment. In addition, even if a fault can be induced, it is often unclear which effect caused the incorrect output. For instance, in an AES software implementation, a bit flip in a register in an inner round will randomise the complete output. The evaluator only observes a faulty output and faces the difficult task of understanding which effect at which position in the code caused the error.This studentship aims at replacing part of the art by science, such that fault injection testing can be carried out by industry as part of a standard security evaluation process. To this end, we will develop tools that give an embedded designer deep insights into the effects of fault injection. Starting from the machine code of the algorithm to be analysed (e.g. for ARM architectures), we propose the following methodology:
- To support the physical fault injection, we will develop a testbed based on the GIAnT toolkit. The testbed allows to inject a range of fault types into an ARM microcontroller (e.g. Cortex M0 or M3), for example clock and power glitches, exposure to flash/UV light, and high/low temperature.
- The target algorithm is repeatedly run on the microcontroller integrated in the testbed. For each input, faults are injected, and both the correct and the faulty outputs are recorded. This process is repeated automatically for different fault types and location.
- In stage 1 of the evaluation phase, the machine code of the target algorithm is run in an emulator for the used microcontroller architecture. By applying a large selection of possible fault models at each clock cycle and backtracking from the output state, the correct fault model is determined.
- This (rather naive) method is then be improved in stage 2 of the evaluation phase by writing the post- fault program code as an equation, and solving for the modified state.
- Finally, we also consider side-channel leakage as a potential means of understanding the effect of a fault.