Q&A: NFC attacks

Over the years, I got quite a few questions about Java Card and related technologies. As a diverging extension to the tutorial, and as a way to bring back some technical content here, I will try to write a few Q&A entries on a regular basis. The first one is about NFC attacks, a topic that currently raises some questions.

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.

No Comments

Leave a Reply

Your email is never shared.Required fields are marked *