There have been several posts on Bruce Schneier’s blog about e-passports, including a recent one. Bruce’s views are interesting, and he raises interesting issues about RFID on passports. On the other hand, the comments posted on this post and related ones, show that there are lots of misunderstandings about the technology.
Of course, this is smart card technology, and it seems that, in many cases, Java Card is present behind the scenes. I would like to react on two main topics:
- Possible attacks on RFID passports. In particular, passport cloning, and how to identify someone’s nationality.
- How to disable your own passport. Some people seem interested in destroying the RFID chip on their passports, and this may be possible without using a microwave.
Cloning a passport is quite easy, because this is not a threat that the electronic passport defends against. Even if your passport includes access control (you must be authenticated before to read the data from the chip), the data from which the key is derived in printed on the passport. The idea is here to avoid skimming, not cloning. Therefore, in all cases, the data is readily available, and the cloning process is easy:
- Get the ICAO spec. The specs are all freely available. The interesting one is the description of the Logical Data Structure.
- Using a contactless smart card reader, read the data using standard ISO7816 commands. If access control is required, you will need to compute the key.
- Write a Java Card application that implements the ICAO spec (that is the painful part, but you may be able to find chips that implement that spec).
- Load the application on a card, and personalize it with the data you got from the other card.
Of course, this does not solve much of the problem. A cloned passport, in particular if it includes biometric data, still does not allow you to get through customs. Actually, this may already be a benefit, since it is more difficult to imitate somebody’s fingerprint than to simply look similar (since the picture is the only authentication means in classical passports).
About identifying someone’s nationality by skimming (without opening the passport), there are several possible leads:
- If the passport does not support the access control option, then there is no problem: simply read the “Issuing state” field.
- If the passport supports access control, then authentication is required before to start reading data. There are many attacks available, but they require a complicated setup, so we won’t consider them here.
- Another interesting lead is the initialization of the communication between the chip and the reader. The chip returns a string of bytes (ATS, Answer To Select), which contains protocol information and “historical bytes”. These bytes should be ignored by readers, but they usually contain product version information and other interesting things. Depending on these bytes, it may be possible to identify a provider, or even an issuing country. I have not tried it on a passport, but these bytes are usually quite interesting.
- The final lead comes from the fact that there are many options in the specification. It may be possible to use this information to identify citizens of a country. A typical way to do so is to try all optional commands. This is often possible even if access control is required: the status word will be different for an unsupported command and for an “access denied” command. The same trick may allow users to identify the data layout, by examining the answers to the SELECT command.
Such attacks are trivial, and they are cheap to design and implement. Anybody with the slghtest smart cad knowledge is able to design them, provided that they have access to a few passports to test them. So identifying the nationality of a passport holder does not look that difficult.
The main issue is here that skimming is a new issue for smart card people, and that our current basic specifications are not designed to resist to that attack. This does not mean that we can’t deend against it, but just that we need to consider it in our security requirements.