Formally verified software countermeasures for control-flow integrity of smart card C code

Abstract

Fault attacks can target smart card programs to disrupt an execution and take control of the data or the embedded functionalities. Among all possible attacks, control-flow attacks aim at disrupting the normal execution flow. Identifying harmful control-flow attacks and designing countermeasures at the software level are tedious and tricky for developers. In this paper, we propose a methodology to detect harmful inter-and intra-procedural jump attacks at the source code level and automatically inject formally proven countermeasures into a C code. The proposed software countermeasures protect the integrity of individual statements at the granularity of single C statements. They support many control-flow constructs of the C language. The countermeasure scheme can detect an attack early either inside a control-flow construct or only at its exit. The secured source code defeats 100% of attacks that jump over at least two C source code statements. Experiments showed that the resulting code is also hardened against unexpected function calls and jump attacks at the assembly code level. Securing a source code automatically and extensively with our scheme degrades the performance. The performance overhead of our countermeasures on three well-known encryption algorithms available in C ranged from +41% to +138% on an x86 platform and from +45% to +217% on an ARM-v7 platform. However, combining code rewriting with hardening of sensitive code regions identified by the weakness detection step enables an application to be fully hardened while limiting the overhead.

A Detection Approach for Vulnerability Exploiter Based on the Features of the Exploiter

“…However, due to the fine-grained CFI imposes too much overhead on the system, it is difficult to implement. e CFI program proposes a simplified version of the solution, which is called coarse-grained CFI [12,13]. Coarse-grained CFI neither needs to obtain the CFG of the program nor needs to assign a corresponding address ID to each address where the program jumps.…”

FIPAC: Thwarting Fault- and Software-Induced Control-Flow Attacks with ARM Pointer Authentication

“…ACFC [79] reduces the performance penalty down to 47 % by decreasing the checking precision and thereby reducing the security guarantees. Similarly, other approaches [39,31] annotate the source code with counter increment and verification macros to detect control-flow deviations. However, a protection scheme requiring manual source code modifications is not practical.…”

Countermeasures Optimization in Multiple Fault-Injection Context

“…The figure 1 shows how a conditional branching is protected by introducing two CCPs (the secswift_assert statement is equivalent to our abstract alarm command). 3) LHB [20]: this countermeasure introduces step counters to protect against C-level instruction skips. Each counter check corresponds to a CCP in our approach.…”

“…The countermeasure presented in section V-C3 is analyzed in [21] and [20]. The correctness of the hardened code and its robustness with respect to C-level single jump attack faults is proved by model-checking for each basic control-flow statement.…”

“…The correctness of the hardened code and its robustness with respect to C-level single jump attack faults is proved by model-checking for each basic control-flow statement. In [20], a lighter version of this countermeasure scheme is proposed to reduce its overhead (at the cost of delaying the attack detection). However, this variant remains generic, and it is not (automatically) tailored for a precise code example, which could lead to further optimizations.…”