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.

The NFC Forum has recently added the possibility to include a signature record in tags. Adding such a signature can be used to ensure that the content of the tag (say, a URL) has been written by the person who sign it, and not modified afterwards. OK, so what does such a signature really bring in terms of security?

Well, I must admit that I am not really sure. Of course, one of the reasons is that I am yet to see a phone that verifies these signatures; I may also not have all the information. So far, I have read the NDEF spec, and the thesis by Markus KilÃ¥s on this topic. So, let’s say that this entry will get modified at some point.

Let’s continue with the URL example, on a very simple, innocuous example: a tag in Nice that contains a URL pointing to explanations about the Ste-Reparate Cathedral. If this tag is signed, then we can expect that a mobile phone would verify the signature before to forward the URL to the browser. However, the mobile phone would also be able to read unsigned tags.

Let’s now consider the two main attacks on this kind of tags:

• Cloning. The entire record can be read freely, so a signature doesn’t protect at all against cloning. A Nice supporter may be able to put a Ste-Reparate tag on a Notre-Dame de Paris poster.
• Tag replacement. The signature does not protect against this. If a Paris supporter comes to Nice, removes the Ste-Reparate tag and replaces it with a Notre-Dame de Paris tag, this will work with a browser. Of course, the phone may display a small “Trusted” icon for a recognized signature, but unless all tags rapidly become signed, I doubt that users will notice this icon any time soon.

So, my conclusion is that signatures are likely to be useless for this URL use case, at least before the industry reaches a global agreement on a way to define how signatures should be handled on phones.

Of course, signatures may still be very useful in proprietary applications, which may be used in the industry. In such cases, the signatures will be verified by a specific application. In that case, it would solve part of the tag replacement attacks, since it would mean that a tag from a given company could only be replaced by another tag from the same company (or a clone of it). This means that a good level of tamper-evidence will also be required.

Not really good looking so far, but if I have missed something, I would be really glad to update this to something more positive.

NFC is red hot these days, and NFC phones are starting to come out. So, what kind of attacks can we do with these phones? Are there really new things? Let’s try to look at a few things.

First, let me recall a few things about NFC. NFC is a complex standard, with several modes of operation. To simplify things, we will only consider two:

• Reader mode. In that case, the phone acts as a card/tag reader. This mode is activated by default, and will be used in particular to detect smart posters and other fun things of the sort.
• Card emulation mode. In that case, the phone acts as a smart card. You can use your phone as a payment card (for instance, using an EMV protocol), or as a transport card. This mode is usually not active by default. In card emulation mode, the applications typically run on a Secure Element (SE), which may be the UICC (SIM card), an Embedded Secure Element (soldered on the phone), or even a removable Secure MicroSD card (not yet widely supported, though).

The first attack that most people think about is the unintended use of the smart card emulation applications. This is quite strange, because this is definitely an aspect in which the use of NFC enhances security. When you have a contactless card in your pocket, this card is always active; if it gets in a proper field, it will wake up and (maybe) start a transaction. With a NFC phone, it is possible to deactivate the listening; in that case, the phone will only listen after an explicit action from the user (for instance, starting a payment application). You don’t have to do that, and you can also leave your phone activated by default. This is a compromise between security and ease of use that is left to the end user’s decision. However, in all cases, the security is at least as good as what you get with a standard contactless card.

The next category of attacks comes from mobile applications, still in card emulation mode. Why mobile applications, since the card emulation applications run on a Secure Element? Well, the applications are running on a mobile phone, and mobile phone users are expecting some kind of interaction when they use their phone. For instance, when doing a payment, the user would expect some message on the screen explaining that there is an ongoing payment. And this message is quite likely to be displayed by a mobile application.

In most NFC phones, an event is triggered when an application is selected on a SE. This event can then be forwarded to an application. That’s when things get interesting: if this mobile application wants to display interesting information to the user, it will need to interact with the SE application. This means that it should be able to use a SE Access API. If this API is not well secured, it’s an open bar for attackers, who can select an application, send commands to any applications, etc. Of course, if the SE applications are well secured, there is not much to do, except denial-of-service attacks. But then, that already is a combination f two “if”‘s: a bit much for security.

Securing a SE Access API is easy in principle. You can for instance take a look at JSR-177, which proposes a solution that works very well. More precisely, it works will on the UICC, because the UICC belongs to the mobile operator, and the use of JSR-177 requires a signature by the mobile operator. Now, if a bank wants to deploy an application on a MicroSD, does it want to depend on a mobile operator? Maybe not.

Similar problems occur everywhere. If Apple does NFC on iPhone, they are quite likely to include an embedded SE that they will tightly control, and the problem for the bank will be the same, replacing the operator by Apple. On open systems like Android, the problem is different but not easier: in a system based on self-certification, who is in charge of enseuring that secure elements are not abused? These things will be clarified, but we can expect to have some room for attacks here, at least in the beginning. Of course, this does not mean that interesting attacks are feasible, as that depends on the target applications. Since the first applications will be ports of well-known card applications, the expectations should not be too high.

The last potential attack that I will mention is about tag reading. It may be possible to “hijack” a tag reading through a mobile application, and replace the content of the tag with another content, for instance linking an ad to an activist site fighting the advertiser. As long as tags are used for advertising, such attacks will be just fun, but they may get more interesting if tags are used for more sensitive applications. Note that very similar attacks already exist today with QR-codes.

This is definitely not a complete list, and I am sure that a few unexpected things will happen with NFC, leading to vulnerabilities, attack paths, and interesting work. We’ll see.