Let’s start by secret keys, used in symmetric algorithms like AES and DES. Such keys are just random values of a given length, without any strong mathematical property((Keys must verify some properties, though, as some values will not provide an adequate protection; however, the probability to get one of these keys is quite low, and no test is usually performed on the keys that are generated on a smart card.

A secret key therefore starts its life as a byte array filled with random data. For a triple DES key, we need 16 bytes of data. Two origins are possible for this data: it may be imported from the outside through a personalization command, or it may be generated on the card using a random number generator. Here is an example using a RNG:

  byte[] keyBytes = JCSystem.getTransientByteArray(COD,16);
  RandomData rng = RandomData.getInstance(ALG_SECURE_RANDOM);

  rng.generateData(keyBytes,0,16);

The next step consists in creating the key object and assigning the random data to the key object:

  DESKey key = KeyBuilder.buildKey(ALG_DES, LENGTH_3DES_2KEY);
  key.setKey(keyBytes);

When that is done, the essential is done. At this point, applet developers are not responsible any more for the protection of the key. The Java Card platform is in charge of implementing the key container classes in a way that protects keys from disclosure at all times (when they are stored and when they are used). In most cases, this means that the key values will be encrypted using another key, managed by the platform.

Applet developers should refrain from any attempt to protect cryptographic keys when they are stored in Key objects. However, the values of keys still need to be protected, whenever they are not stored in the proper containers. For instance, the raw data used to initialize the key should be cleared after the initialization. The initialization code therefore is as follows:

  try {
    rng.generateData(keyBytes,0,16);
    key.setKey(keyBytes);
  } finally {
    Util.arrayFillNonAtomic(keyBytes,0);
  }

With private keys (used in assymetric algorithms like RSA), things are even simpler, since there is a dedicated class to generate key pairs (a public key and a private key). This means that the actual key values are kept during the entire process under the protection of the platform.

Basically, the two rules about keys are:

• Keys stored in Key container are protected by the platform, and only by the platform.
• Plaintext key values should not be stored in byte arrays, expect for very short periods of time when absolutely needed, and the values should be cleared when then are not used any more.

Following them is a good start in the proper protection of cryptographic keys.

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.