Link-time smart card code hardening

Abstract

This paper presents a feasibility study to protect smart card software against fault-injection attacks by means of link-time code rewriting. This approach avoids the drawbacks of source code hardening, avoids the need for manual assembly writing, and is applicable in conjunction with closed third-party compilers. We implemented a range of cookbook code hardening recipes in a prototype link-time rewriter and evaluate their coverage and associated overhead to conclude that this approach is promising. We demonstrate that the overhead of using an automated link-time approach is not significantly higher than what can be obtained with compile-time hardening or with manual hardening of compiler-generated assembly code.

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

“…The weakness detection and code securing processes can be performed at different code levels: source code [6], any intermediate code such as during the compilation process [7,8], or binary code [9]. Working at the assembly or binary code level seems to be the most adapted level when considering physical faults.…”

“…However, identification of weaknesses requires determining the faults that have an impact on the program security to understand their effect for adding a protection code to counteract them. At these levels, high-level information such as sensitive variables and control flow is not directly available owing to loss of information to code transformations and code optimization during the compilation process [10,11,9]. Matching assembly instructions with the source code to retrieve semantics about high-level elements is not trivial; moreover, sometimes, it is impossible and time consuming if manually performed.…”

Efficient Design and Evaluation of Countermeasures against Fault Attacks Using Formal Verification

“…Loop iteration counter duplication, because it attempts to guard the control flow of a loop, and uses some clever tricks to do so (e.g. inverting the condition of a branch) [20]. 3. instruction duplication, since the principal idea behind this technique is widely applicable [12].…”

“…al. in a prototype link-time code rewriter [20], to show that it is possible to apply those protections automatically, and with an acceptable overhead. The technique we describe here is referred to by the authors as memory store verification.…”

“…Another countermeasure implemented by De Keulenaer et al aims to protect the number of iterations of a loop [20]. An unprotected code fragment is shown in Listing 4, whereas Listing 6 shows the same code fragment after protection.…”