class="navbar-brand">

Secure Collection

FISSC: the Fault Injection and Simulation Secure Collection

We present FISSC, the first public code collection dedicated to fault injection robustness evaluation. Applications are hardened against fault injections by the way of countermeasures, allowing to abort the execution or infect observable results. Crafting applications robust against fault injections, and evaluating this robustness, is an open problem for all actors of the secure application development life cycle. For instance developpers and evaluators have to evaluate the accuracy of a set of countermeasures with respect to assets to be protected. In order to assist this process, some tools have been developed. The major difficulty for these tools is the absence of representative codes and criteria to evaluate or compare obtained results. The FISSC collection is the first public response to this problem.

We aim to:

  • Provide a common set of representative secure applications that can be hardened against fault injection.
  • Provide an inventory of classical countermeasures illustrated through examples allowing to evaluate the accuracy of these countermeasures.
  • Provide a methodology for analyzing and comparing the results of a robustness evaluation campaign.

This way we provide developers and evaluators with the means to quantify and qualify the robustness of code examples and to analyze the effectiveness and relevance of countermeasures in hardened code.

Get FISSC

The benchmark is provided on request. Please send an e-mail to sertif-secure-collection@univ-grenoble-alpes.fr

Results on an example

Here is an analysis of the results of three tools, Lazart CELTIC and EFS on an example of the secure collection.

FISSC Architecture

We simply have a directory for shared files, containing the definition of common types and functions, and a directory for each secure application.

Each example (e.g. aes_addRoundKey_cpy) has its own directory, containing a Makefile, an include directory and a source directory. In the source directory:

  • code.c defines the function under analysis (e.g. a function verifying a PIN code);
  • countermeasure.c defines the countermeasure function, setting a flag to indicate that an attack has been detected;
  • initialize.c setups the variables of the program;
  • oracle.c defines the oracle determining whether an attack is successful;
  • main.c defines the main function that calls the function under analysis and checks the oracle.

The main() function returns 1 if the oracle is verified, 0 otherwise.

For some examples, assembly listings (Thumb-2) are provided in the lst directory.

For now the available exemples in the collection are:

  • aes_addRoundKey_cpy: where we are looking for attacks disrupting the copy of the key
  • VerifyPIN
  • VerifyPIN with hardened bools
  • VerifyPIN with hardened bools and fixed-time loop
  • VerifyPIN with hardened bools, fixed-time loop and inlined function
  • VerifyPIN with hardened bools, and fixed-time loop, inlined function, PTC decremented first, PTC backup and loop counter
  • VerifyPIN with hardened bools, fixed-time loop, PTC decremented first and double call
  • VerifyPIN with hardened bools, fixed-time loop, inlined call, PTC decremented first and double test
  • VerifyPIN with hardened bools, fixed-time loop, inlined call, PTC decremented first, double test and step counter
  • VerifyPIN with hardened bools and control-flow integrity
  • VerifyPIN with hardened bools, fixed-time loop, inlined call, PTC decremented first, double test, step counter and control-flow integrity
  • GetChallenge
  • GetChallenge with hardened bools, virtual stack, double arguments, step counter and loop counter
  • CRT-RSA
  • CRT-RSA with Aumuller countermeasure
  • CRT-RSA with Shamir countermeasure

For each version of VerifyPIN, we are looking for attacks:

  • leading to a successful authentication with an erroneous PIN
  • leading to a non-decrement of the try counter in case of a failed authentication

For each example, results are provided in a directory named TOOL_results_SCENARIO. Each result directory contains:

  • .dot files displaying high-level attack scenarios on the CFG
  • .out files containing details about the input and the trace of each attack

Contributions

We seek for contributions, either adding new examples or adding results of new tools to existing examples. The format and architecture of examples is described in the section FISCC Architecture. To know about the prototypes and expected results of each function, please take VerifyPIN_0 as example.

To provide results for new tools, you have to describe the attacks found and a way to implement them.

Please put in a text file: - at which level is your tool working (source level, intermediate language level, binary level, etc.) - nature of the attack(s) - temporality of the attack(s) - multiplicity of the attack(s) - observable effects of the attack(s) - for low-level attack(s), what is an interpretation at a higher level ? - for high-level attack(s), what are possible low-level implementations ?

Please additionally provide traces or translated source/binary code (depending on the level you are working at) in a directory named YOUR_TOOL_results.

All contributions must be sent to sertif-secure-collection@univ-grenoble-alpes.fr for review.