FaultFinder: from Faulty Output to Fault Model - an Automated Approach

School of Computer Science
University of Birmingham


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:

People Involved: