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.