Verifying redundant-check based countermeasures

Abstract

To thwart fault injection based attacks on critical embedded systems, designers of sensitive software use redundancy based countermeasure schemes. In some of these schemes, critical checks (i.e. conditionals) in the code are duplicated to ensure that an attacker cannot bypass such a check by flipping its result in order to get to a protected point (corresponding e.g. to a successful authentication or code integrity verification). This short paper presents a source-codelevel verification technique of the correct implementation of such countermeasures. It is based on code instrumentation and deductive verification. The proposed technique was implemented in a tool prototype and evaluated on a real-life case study: the bootloader module of a secure USB storage device called WooKey, supposed to be resistant to fault injection attacks. We were able to prove the correctness of almost all redundant-check countermeasures in the module except two, and found an error in one of the unproven ones. CCS CONCEPTS• Security and privacy → Logic and verification; • Software and its engineering → Formal software verification;

A Compositional Methodology to Harden Programs Against Multi-Fault Attacks

“…In the context of CFI many protections have been proposed and proved, as in [3]. In the context of fault injection, formal methods have been used to establish the effectiveness of countermeasures [15], [16], [20]. But these works are dedicated to particular forms of countermeasures and specific fault models, and they address single faults only.…”

“…This solution introduces serious and unnecessary run-time overheads. On the other hand, methods have been proposed to prove hardened programs [8], [28], [20], or to verify the efficiency of a given form of countermeasures against attacker models [15], [16]. All these approaches are developed in the context of single fault and adapted to a particular countermeasure or fault model.…”

“…According to the state of the art, applications must now be protected against (spacial or temporal) multi-fault injection [23], [33], namely when several faults can be injected at various times or locations during an execution. As a consequence developing applications which are robust becomes a very challenging task and a trial and errors game, in particular because countermeasures can be also the target of attacks [4], [20]. The aim of this paper is to propose a methodology for developers allowing to harden an application against multi-fault attacks: taking into account the fact that countermeasures themselves can be attacked and helping to place protection schemes inside the program w.r.t a set of fault models and an attack objective.…”

“…According to the state of the art, applications must now be protected against multifault injection [23], [33]. As a consequence developing applications which are robust becomes a very challenging task, in particular because countermeasures can be also the target of attacks [4], [20]. The aim of this paper is to propose an assisted methodology for developers allowing to harden an application against multifault attacks, addressing several aspects: how to identify which parts of the code should be protected and how to choose and place the appropriate countermeasures, giving guarantees on the robustness of the protected program.…”