2007-08-24

RFID Passports Revisited

I've written about RFID and passports before, but have let most of the recent news about its interaction with the new biometric passport standards slip. But I can't pass up the latest tidbit.

The problem with RFID in general is that you can't make reasoned arguments against it without sounding like a kook that is afraid of black helicopters and mind probes. The thing is, that there really are some serious issues raised by the widespread adoption of RFID that simply are not possible if simpler (and cheaper, and more suited to the application) technologies like 2D barcode are used instead.

In short, the advantage of RFID is that the tag's information can be retrieved without the operator needing to actually see the tag. The disadvantage of RFID is that the tag's information can be retrieved without the operator needing to actually see the tag. But that actually isn't the reason for today's bit of ranting.

The ICAO is the agency of the UN that sets standards for passports, which are generally adopted by the member nations, including the US. The ICAO established a standard requiring that passports carry biometric information about the holder in addition to the usual date of birth, full name, and issuing country which is about all the information that passports classically carry.

Apparently, a typical bit of biometric info to include is an image of a fingerprint. Rather than storing an encoded hash of a matching print that would require a border checkpoint to use an equivalent (usually patented if not trade secret) technology to match a bearer's print, someone chose to store a simple image of the print. Since it is important to use as little space as possible to store the image, JPEG2000 is used to compress a photograph of the fingerprint. If you are going to store a fingerprint in a document with a hoped-for lifetime of 10 years, that is all reasonable.

Unfortunately, the makers of the passport readers all appear to have used JPEG2000 implementations that have some (or all) source code in common. In particular, there is a known bug in the JPEG2000 implementation that makes it vulnerable to a buffer overrun attack.

A determined individual demonstrated recently that he was able to use off-the-shelf technology to clone a copy of a passport's RFID chip. That is bad enough. But his latest revelation is worse: he was able to modify his cloned copy of a passport's otherwise valid RFID tag to include a fingerprint picture that exercises a known buffer overrun attack on JPEG2000. That tag has been demonstrated to crash every passport reader it has touched.

Today's attack is just a denial of service. The passport station would be crashed, and under normal conditions it could be restarted relatively easily and wouldn't crash again until another bad passport was brought through. (Of course the fiasco at LAX the other day involving 10000 people stuck on the tarmac outside of the customs barrier for as much as seven hours could be the result of that denial, especially if the official reaction to such a crash was institutionally stupid.)

But one of the better ways to inject code of the attacker's own choosing into a device is to carefully craft a buffer overrun attack so that rather than crashing the targeted system, it actually takes it over. At that point, you have code provided by an attacker running inside a passport terminal. These terminals are networked, and it is not inconceivable that such an attack could have effects that are both subtle and far reaching.... I'll let you fill in your own risks from that point.

No comments: