Rules of the Contest

Authors: Jean-Luc Danger¹, Guillaume Duc¹, Aziz Elaabid¹, Florent Flament¹, Sylvain Guilley¹, Philippe Hoogvorst¹, Laurent Sauvage¹, Philippe Bulens², François-Xavier Standaert², Nicolas Veyrat-Charvillon²
¹ Télécom ParisTech
² Université catholique de Louvain

Introduction

This page introduces the second edition of the contest (denoted as DPA Contest V2) and details the evolution of its rules, following the remarks in [2].

Target implementation

The DPA Contest V2 targets an unprotected implementation of the AES algorithm. Its full design (including HDL codes, bitstreams, control programs, etc.) is available for download and the documentation is available on the Documentation page.

The side-channel traces of the DPA contest have been acquired with a SASEBO GII board.

Contest setup

The DPA Contest V2 considers known-message and profiled attacks.

The known-message adversarial scenario is first motivated by the fact that this version of the contest is based on pre-computed databases of side-channel traces. The fair analysis of chosen-message attacks would require to perform online measurements during the evaluation of the attacks. Next, the choice of profiled attacks is motivated by the fact that the contest primarily aims to improve our understanding of the side-channel leakages. Hence, it appears natural to consider a setup that is close to the one used by evaluation laboratories and certification bodies (also known as ITSEFs).

The DPA Contest V2 uses three databases, two public and one private.

The first database, called the template base, is available to the participants. It contains the side-channel traces corresponding to 1,000,000 encryption operations. Each encryption is performed with a random key and a random plaintext. Keys, plaintexts and ciphertexts are public information. Hence, this database can be used to profile the attacks.

The second database, called the private base, is not available to the participants and will be used to evaluate the attacks with an independent set of measurements. It contains traces corresponding to 32 random keys, each of them used to encrypt 20,000 random plaintexts, i.e. a total of 640,000 traces.

The third base, called the public base, is available to the participants. It also contains 640,000 traces (32 random keys, different from the keys in the private base, each of them used to encrypt 20,000 random plaintexts, also different from the plaintexts used in the private base). This base can be used to test attacks, in the same conditions as they will be evaluated with traces from the private base.

The traces of the three bases have been acquired under the same conditions between 23/12/2009 and 02/01/2010 in this order: template base, private base and public base. The information needed to access the databases and the format of the traces are available on the page Tables.

Attack's description and requirements

In the DPA contest V2, one attack A(PV,TM) is defined as a piece of software A that takes a plaintext vector PV and a traces matrix TM as input and produces a result matrix RM as output. In our setting, the plaintext vector has size 20,000 * 1 and the traces matrix has size 20,000 * Ns, where Ns is the number of samples in each trace, one trace corresponding to the encryption of one plaintext. Finally, the result matrix has size 20,000 * 16 and can be represented as:

sk₁¹	sk₂¹	sk₃¹	...	sk₁₆¹
sk₁²	sk₂²	sk₃²	...	sk₁₆²
sk₁³	sk₂³	sk₃³	...	sk₁₆³
...	...	...	...	...
sk₁²⁰⁰⁰⁰	sk₂²⁰⁰⁰⁰	sk₃²⁰⁰⁰⁰	...	sk₁₆²⁰⁰⁰⁰

Each line of the result matrix contains 16 vectors sk_s^t. They correspond to the 16 bytes of the AES subkey that the attack aims to recover. That is, the subscript s corresponds to the index of a subkey byte, the superscript t indicates the number of traces that have been used to produce sk_s^t. In other words, sk₁¹⁰ corresponds to the least significant byte of the AES subkey and has been produced with the 10 first traces provided to the attack A.

Each vector sk_s^t has size 256 * 1 and contains the 256 candidates for a subkey byte, rated according to their likelihood. That is, the first position in a vector sk_s^t corresponds to the most likely value for the subkey byte s, the second position corresponds to the second most likely value...

A reference code for such an attack is available in the download page, in C programming language. Since the performance of the code will be part of its evaluation (see the next section), we encourage applicants to use such a compiled language rather than interpreted languages.

Evaluation criteria

The efficiency of an attack will be determined from a set of 32 independent experiments, corresponding to the 32 random secret keys in private base, each of these experiments using 20,000 random plaintexts (that are not directly available to the applicants but are provided as inputs to their attacks during the evaluation). Let us denote one attack as RM(j) = A(PV(j),TM(j)), with j in [1,32]. From the 32 result matrices that will be generated during the evaluation of an attack, the DPA Contest tool will generate the following metrics:

A 16 * 20,000 partial success rate matrix. It contains the first-order success rate defined in [1], sampled from 32 independent experiments, and computed independently for the 16 bytes of the AES selected subkey, in function of the number of traces used in the attack.
A 16 * 20,000 partial guessing entropy matrix (constructed similarly as the previous matrix), using the guessing entropy (see also [1]) as evaluation metric.
A 20,000 * 1 global success rate vector. It contains the first-order success rate in recovering all the 16 selected subkey bytes concurrently, sampled from 32 independent experiments, in function of the number of traces used in the attack.

These three metrics can be used to provide a fair picture of the efficiency of an attack, in function of its data complexity (since we consider know-plaintext attacks, with uniformly distributed messages, the data complexity is equivalent to the number of traces, i.e. with overwhelming probability, we never encrypt twice the same plaintext with the same key). Additionally, the evaluation tool will also generate approximations for:

The execution time. That is, the time needed to perform the 32 independent experiments will be saved as an evaluation criteria.

Reasonable Execution Time Requirement

This section was added on 27/08/2010 after the evaluation of some attacks.

Before sending an attack, the participant must run it completely (i.e. using all the 20,000 traces) on at least one key of the public base.

In addition, the time needed to run the attack on the all the 20,000 traces of a key of the public base, on a normal computer, must not exceed 48 hours.

Summary

In brief, a participant can use the template database in order to perform profile his leakage models and the public database to perform preliminary tests.

Once an attack is ready to be evaluated, it can be sent to us. We will launch it with the private database (32 independent experiments corresponding to 32 different secret keys). Finally, the evaluation metrics will be evaluated and sent back to the participant.

Contrary to last year, the code of your attack will not be published until the submission deadline. In addition, if you want (you must clearly specify it when you submit it), the code may not be published at all.

For more details on how to participate, check the Participate page.

References

[1] F.-X. Standaert, T.G. Malkin, M. Yung, A Unified Framework for the Analysis of Side-Channel Key Recovery Attacks, in the proceedings of Eurocrypt 2009, Lecture Notes in Computer Science, vol 5479, pp 443-461, Cologne, Germany, April 2009, extended version available on the Cryptology ePrint archive, http://eprint.iacr.org/2006/139

[2] F.-X. Standaert, P. Bulens, G. de Meulenaer, N. Veyrat-Charvillon, Improving the Rules of the DPA Contest, Cryptology ePrint Archive, http://eprint.iacr.org/2008/517

DPA Contest v2