FIVER – Robust Verification of Countermeasures against Fault Injections

Abstract

Fault Injection Analysis is seen as a powerful attack against implementations of cryptographic algorithms. Over the last two decades, researchers proposed a plethora of countermeasures to secure such implementations. However, the design process and implementation are still error-prone, complex, and manual tasks which require long-standing experience in hardware design and physical security. Moreover, the validation of the claimed security is often only done by empirical testing in a very late stage of the design process. To prevent such empirical testing strategies, approaches based on formal verification are applied instead providing the designer early feedback.In this work, we present a fault verification framework to validate the security of countermeasures against fault-injection attacks designed for ICs. The verification framework works on netlist-level, parses the given digital circuit into a model based on Binary Decision Diagrams, and performs symbolic fault injections. This verification approach constitutes a novel strategy to evaluate protected hardware designs against fault injections offering new opportunities as performing full analyses under a given fault models.Eventually, we apply the proposed verification framework to real-world implementations of well-established countermeasures against fault-injection attacks. Here, we consider protected designs of the lightweight ciphers CRAFT and LED-64 as well as AES. Due to several optimization strategies, our tool is able to perform more than 90 million fault injections in a single-round CRAFT design and evaluate the security in under 50 min while the symbolic simulation approach considers all 2128 primary inputs.

A Systematic Review of Fault Injection Attacks on IoT Systems

“…Formal analysis methods are mathematical procedures used in software verification. The authors of [34,36,54] utilized model-checking methods to analyze cryptography software for vulnerabilities. Given-Wilson et al [8] described a framework for run-time verification of fault-injected software binaries using model checking to validate the expected software properties defined as variables and constants at certain positions in the software.…”

“…Although simulated processor-level modifications allow microarchitecturallevel tools to simulate effects that closely replicate actual hardware effects of fault injection attacks, instruction-level tools are easier to implement as they directly modify the assembly instructions and do not require knowledge of the processor architecture and working. Much of the literature has utilized simulation tools for the vulnerability analysis of safety-critical IoT software, such as cryptography software, password-checking procedures, and device firmware [23,30,34,36,62]. However, fault injection attacks can also affect the application software of an IoT system.…”

“…Potet et al [31] analyzed the control flow graphs generated dynamically from the fault-injected executables. The techniques used in the literature to analyze the software fault injection output include model checking [34,36,54] and machine learning [7,33,55]. Model-checking methods utilize certain pre-defined model properties of the IoT software, such as security variables.…”

SoK: Assisted Fault Simulation

“…The target audience for this paper is developers of general-purpose software and not specifically cryptographic implementations. Although many fault simulators [1,5,6,14,[16][17][18]24,[26][27][28][29]31,33] can verify the implementations of cryptographic algorithms, we exclude them in this work because there is already an overview of such tools [4]. We found four fault simulators in the public domain suitable for such a developer, namely FiSim [25], ZOFI [23], ARMORY [13] and ARCHIE [12].…”

Experimental Evaluation of Delayed-Based Detectors Against Power-off Attack

“…However, it is critical to ensure the protection of these detectors themselves against potential FIAs. There is a bunch of research work on the vulnerability of detectors [8] [9] to various types of Fault Injection Attacks (FIAs) as well as methods for protecting them. All of them assume that the detector is connected to the power supply, but none of them have been evaluated against FIA when the power is off.…”