DPA is annoying (again?)

I am currently in Limoges, visiting the University to work on a collaborative research project. The buzz in the computer science department is that Christophe Clavier, one of their researchers, has just won the DPA contest, organized at CHES. And of course, I took the opportunity to discuss that with him.

I won’t even start claiming that I understand anything about DPA, and I will carefully avoid commenting on the “maximum likelihood method with a bivariate known model” he is using (I did not choose to emphasize the “known” word; somebody else did). However, if I get the result right, the result of this contest is that Christophe has been able to break a DES key with 142 traces (in fact, 43 traces, since the rules of the contest stated that the algorithm needed to remain stable for 100 rounds to win) on average, for 100 tries. This means that in some cases, he was able to make it with 30 traces, or may be even less.

A DES key broken on average with 43 traces? What does it mean for us developers?

Well, the usual way to battle against DPA is to limit the number of possible tries. In many cases, the limit is set quite high, in the hundreds or thousands, even 32767 or 65535 (basic values for 16-bit oriented people). If it becomes possible to break a key with 42 traces, some of the limits will need to get down. For some applications, this will not be a problem; let’s just recompile with a new value, or even send an administrative command to update a value. For many others, the limit is enforced by a counter that is used for other purposes (typically, a transaction counter, limited to 32767 or 65535 for the lifetime of the card). This may not work that well any more.

Of course, in most cases, we are not using DES, but triple-DES. And the rules of the contest made it easier on the contestants, since they knew the value of the key to start with, so the algorithm could be tailored to that key. And there were no hardware countermeasures activated on these traces. And probably many more things.

So, no need to get nervous, and to stop the deployment of our current cards. Nevertheless, because our cards need to live for quite a while, we need to consider that this result is an advanced warning of the problems to come, and that we will eventually need to upgrade our countermeasures. New countermeasures may be invented in hardware, or in low-level software. However, application-level software remains the easier level to update/improve.

This was the first contest of this kind, and another one should be organized next year. The topic and rules are currently under discussion, but we can hope that this will help make the state-of-the-art attack techniques more well-known to the community, and also that it will encourage more labs to show off what they can do.

2 Comments

  • Christophe Clavier wrote:

    Eric,

    Thanks for posting about the results of this first DPA contest. I agree with the most parts of you text. I would like to give a small comment though.

    This is exact that the partipants to the DPA contest knew the secret key, but this was only for verification purpose. It is not true that their methods have been tailored for that key value. At least this was not the case for the different methods I proposed. I am quite confident that my methods would have given very similar figures whatever the key.

  • Sylvain GUILLEY wrote:

    Hi Eric,

    Given the interest raised by this contest, a second edition has been launched. This year, the goal is to still to evaluate the strength of attacks against an unprotected implementation of a block cipher (AES). Of course, most commercial smartcards embed advanced countermeasures that make such side-channel attacks difficult. Thus, we view this 2nd contest more as a way to learn how to compare attacks ; for this purpose, we will rate them according to metrics such as partial/global success rates or guessing entropy, and also according to the computational power of the attacker. We hope this will improve our understanding of the real threats on secure hardware…

    More information there: http://www.dpacontest.org/v2/

Leave a Reply

Your email is never shared.Required fields are marked *