Contact
MRTD Analysis
Analysis of the ePass with RFID Chip

About

The new biometric passport is supposed to be more secure and "even more unforgeable" than the old one, say those responsible for it. But its muddle of standards, the complex architecture and a seemingly premature Concept are everything but inspiring confidence.

News: Response to Mr. Barry Kefauver on security

This is an open response to an interview that Mr. Barry Kefauver gave on the MRTD report by ICAO Vol.2, No2.

In this interview Mr. Kefauver makes incorrect claims, ignores a number of facts and simply tries to blame me. With this open letter I would like to clarify some facts from a security and RFID expert.s point of view.

Mr. Kefauver attended my presentation at the Document ID World where he rejected most of the facts I presented. There he pointed out that we had to look at it solely as a security document. His argument that my following claims are all unfounded, are pure politics. His claim that experts designed a secure passport is just wrong if we look at the following facts.

First, the MRTD uses only TLV (http://en.wikipedia.org/wiki/Type-length-value) and the whole parsing, encoding and decoding of information has to be done with code written for this specific purpose. Every IT expert or system designer would use a standard ASN.1 (http://en.wikipedia.org/wiki/ASN.1) encoder and decoder, which would enable every inspection system or reader to formally verify the contents of the MRTD.

This would help prevent software bugs from being introduced by custom hand-written code.

One of the golden rules for secure systems is "keep it simple and stupid" (KISS). The ePassport applies useless meta-formats and the whole system of reading the passport is immensely complex. A complex system is harder to implement than a simple one, this in itself raises the level of potential vulnerabilities exponentially.

Another example is the Extended Access Control. To give certain biometric data a higher level of protection, a cryptographic certificate which is only valid for a limited amount of time is required. Obviously, a reliable clock is necessary to facilitate the time limitation. However, the only trusted system, which is the RFID chip inside the passport itself, has no time source at its disposal. So how can this process work without a time source inside the RFID ePassport? It can.t.

The biometric data is stored as a complete data set and not as a hashed data set. Mr. Kefauver claims, if the biometric data is hashed, it would "make it useless in a globally-interoperable environment such as border control."
The fact is, if for example the fingerprint is not hashed, a duplicate physical fingerprint could be easily built from the image stored on the ePassport. A hashed value of this sensitive data would protect the biometric data against physical replications. Mr. Kefauver is not telling us why we should not be concerned about this.


His next argument is that all the scenarios we presented are based on
us seeing "these chip-based passports as a toy to be brought into the laboratory and made sport with on the basis of impractical and questionable scenarios, [...]".

However, this is the standard approach followed by well-established companies in the security industry for many years when auditing any system.

A specific scenario may be impractical or questionable today, but it might be realistic tomorrow and it is simply wrong to handle security issues this way. In essence, the history of IT security and systems teaches us, there is no impractical or questionable scenario. Just the opposite is true:
Typically there are more scenarios to be found in the real world that will break a given system than could ever be detected or anticipated in a laboratory environment.

In the interesting part of the interview, where Mr. Kefauver is asked about the security features of the chip, his statements avoid the core of the problem. Instead he repeatedly points out that the print features will protect the chip.

From our point of view, Mr. Kefauver does not understand that the use of the ePassport opens a public channel into the inspection system including the computer systems at border control. Thus, malicious data injected into an official passport could find its way into those systems when the passport is presented there.

"The fact is that the genre of chip used for inventory control and the 14443 chip used in passports are completely different technologies [...]".

This quote shows the lack of technical expertise Mr. Kefauver has in the RFID field. The same RFID reader used to read ISO 14443 chips can read ISO 15693 chips (the chips used for inventory control), with the same antenna. If ISO 14443 and 15693 were completely different technologies why is RFDump (http://www.rfdump.org) able to read both types using the exact same program code?

.Cloning a chip is basically the electronic version of photocopying someone else.s passport data page. Imagine going up to a passport inspector and attempting to present a photocopied data page of somebody else.s passport, and essentially you have the security-threat equivalent of cloning a chip. You.d be laughed out of border control and escorted to the door, maybe by security officials, maybe by the nice men in white coats. Again, the rigour to be applied with cloning is the .so what. test.

Cloning a chip has no impact on a passport.s security or the bearer.s privacy it is a non-issue..


This is incorrect in two ways. A digital copy of data is always identical to the original (this is the very nature of digital versus analog) and thus can.t be distinguished from the original. A photocopy of the data page is clearly distinguishable from the original and
would of course be detected by a human inspector. Furthermore, since the ultimate goal is to have automatic gates at border control, we should assume that in the long run we will lose the human element as an additional layer of protection to make sure the documents presented at border control .make sense..

To compare this with Mr. Kefauver.s example, here is ours:

An illegitimate passenger with a cloned (valid) data chip embedded in his passport approaches the automated inspection system. Before his trip he prepared his original passport. He destroyed the original RFID Chip in his microwave oven and taped the new forged RFID chip into his passport. The cloned chip is a copy of his destroyed original chip but extended with a software exploit that gives him full control of the
computer inside the inspection system.  After checking the physical security functions the RFID reader tries to read the data in the passport. While reading the forged data, the exploited takes over the IT system. No human is able to see anything suspicious, but the changed software now allows him to pass the border control.

So, Mr. Kefauver, how do you deal with this scenario? And please don.t tell me that your systems are 100% secure, evaluated systems. We all know this is not the truth.

IT security is much more complex. Not a single piece of software in the world is 100% secure. Two examples are the Apple iPhone or the Microsoft license validation in Windows Vista. Both are cracked, although Apple and Microsoft employed their best and brightest developers to protect their assets. Why does the ICAO think they can do better in the software field than the two largest software companies in the world?


Another example where we are only told half of the truth:

"The bottom line is that yes, you can skim, but this is extremely impractical with Basic Access Control and other measures that States are now implementing using state-of-the-art cryptographic technology.."
So why is the key for the Basic Access Control printed on top of the
passport data page?

How secure is the "state-of-the-art", or better 3DES, if the key space is very limited, and the key can be inferred using the personal data of the passports owner. In theory it would be sufficient to look over the shoulder of somebody who is filling out his US immigration form on an airplane to obtain all information necessary to deduct the key.

When you check into a hotel in Europe, the first thing the receptionist typically does is making a copy of your passport's data page, so the hotel employees can register you. Again, gone is your key for Basic Access Control.

.[...] nor does it matter that someone can get far more useful information from a trash-can in your driveway, nor does it matter that many hotels, for instance, regularly ask for your passport and photocopy it for their verification and records, thereby duplicating exactly the same sort of information that a skimmer might find from a chip with much more expense and effort [...]".

But all this gives access to tracking and tracing the holder of the passport. Most citizens can decide what to dump into their trashcans. However, if you need to travel and have to use an ePassport, you cannot do this any longer - except if you are from Switzerland where you can choose if you want a RFID chip embedded into your new passport or not.

MRTD design

The new electronic passport, which is actually called MRTD (machine readable travel document) includes, next to the classical passport security measures, a smart card controller, that communicates over an RFID interface that meets the ISO-14443 standard. Alternatively the smart card data can also be stored in a matrix bar code instead of a RFID controller.

The architecture holds certain weak points, that are however only obvious to those with a detailed knowledge of the passport's underlying concepts and technologies. After an introduction to these basics, we will present potential risks from the perspective of an IT-security expert.

First of all, the RFID chip's design: It uses a smart card controller of a type that is produced e.g. by Philips or Infinion. In most cases these are dual interface controllers, which means that they have a PIN interface (using the ISO 7816-XX standards) as well as an RFID interface. However, since travel documents are exposed to a lot of stress and have to last up to ten years the electronic passport's contact interface has been dropped in favour of the RFID ISO-14443 interface. The RFID reader has to be able to read the tag – as the RFID chip is often called – from a distance of less than 10 cm (about four inch).

Faster encryption with crypto hardware

After the card has been activated the operating system is loaded and programs can be executed. These programs are written in Assembler, C or Java and run directly on the smart card after being translated into the processor's machine code. The RFID chips that are used for electronic passports additionally include acceleration hardware for cryptographic functions.

The up to 72 kByte of data stored on the Chip inside the passport can be divided into two groups: in meta information (EF.SOD and EF.COM) and the files DG1 to DG4 (data group). EF.COM is a kind of index that includes information on which data groups exist on the tag. EF.SOD (security object data) includes the signed hash value, which is needed to verify its authenticity.

The individual data groups include the following information: DG1 stores an electronic version of the machine readable zone (MRZ), the machine readable line that is printed on the passport's first page. This data group holds information such as the document number, its issuer, its duration of validity as well as the owner's name and birth date. This file is mandatory.

DG2 holds the owner's picture, which should also be printed on the document itself. It is stored in CBEFF (Common Biometric Encoding File Format, ISO 19785). This format, which has been pushed by the industry lobby, creates a – superfluous – meta level, which includes the definition of the biometric format used in the document. The last two data groups, DG3 and DG4 are optional files, used for other biometric data such as iris scans and finger prints.

MRTD risks

The reinvention of the wheel

The description language for data structures ASN.1 follows the same idea as XML: If offers a language description (Lex) that defines the document format. This allows creating a parser and an automated data generator by providing a processor with the language description. As a consequence it should be possible to easily create complex protocol parsers with already existing and tested libraries and quickly verify data correctness. However, this only works if the ASN.1 standard is observed – which the MRTD does not.

Those responsible for the planned travel documents created new tags with the ICAO standard – and reinventing the wheel. Because of that, instead of the automatically generated one a handwritten parser is necessary. At least the data are encoded according to the X.690 standard.

The X.690 standard describes data encoding in TLV (type-length-value). The basic encoding rules (BER) laid down in this standard describe how certain syntax notations in ASN.1 are mapped to the TLV structure. Those responsible for the new electronic passport chose a different way though: Instead of describing the passport's data structures in ASN.1 they just kept the TLV format that is actually fully defined by the BER. Thus they defined tags that, according to the BER could never exist. Because of that, there is no way to describe the passport's data using ASN.1, since a BER compatible ASN.1 encoder would create a different TLV-encoding. As a consequence also in this case a parser has to be built by hand or exceptions have to be be inserted into standard libraries. This yields the result, that future passport checks require purpose-built readers and cannot use standardised ones.

Basic cryptographic security

When performing the so called basic access control (BAC) cryptography first comes into play. However, one can't help but think that this concept offers only little security. In order to prevent passer-bys from reading the electronic passport, an – only optional – protection of the transmission line, the radio interface, is intended. The data in DG1 and DG2 however are stored in plain text.

In order to allow a tap-proof connection, this connection has to be encrypted. The key used for the initiation of this connection is generated from the MRZ. How this works in detail can be seen in the ICAO standard. The reader has to (optically) read the page with the picture and the printed MRZ. The software then uses these data to generate the key that is used to set up an encrypted connection between the reader and the RFID controller. This way the reader signs on to the passport. If the key is incorrect, the passport cannot be read. The BAC encryption is optional, it is left to the passport issuer. If a passport supports it, it cannot be read in plain text.

So, in order to read a passport, the owner's name (spelled correctly), the birthday and the document number are required. However, these data, which are printed in the second line of the MRZ, are by no means secret. Not only the passport's owner but also every hotel or bank that occasionally stores passport numbers for reasons of security, e.g. when withdrawing money, know these data. All other necessary information can be found in standing data. Thus also unauthorised people can generate a key.

Next problem: Since according to the ISO 14443 standard every day has to have a unique chip ID, it would be possible to track the movements of a passport's owner, without a BAC procedure. In order to prevent this, the ICAO standard intends to use random data for the ISO 14443 ID, that is regenerated every time the chip is initialised. Due to the low entropy in this case it needs to be investigated, in how this procedure can provide truly random data, because if the random number's range is too small, it is possible to draw conclusions as to the common origin.

Extended access control

The so called extended access control is supposed to restrict access to the data groups DG3 and DG4 (DG3 and DG4 are not used in the already provided electronic passports of the Federal Republic of Germany). This shall be achieved by encrypting the data object. For decryption a public key infrastructure (PKI) has to be established on a global basis, for all participating countries. With only temporary valid certificates it shall be possible to read data from DG3 and DG4, either online or using a reader. It is however still unclear, how the Certificate Revocation List (CRL), that includes invalid certificates or their serial numbers will be handled and where it will be stored. But as long as a lost root certificate cannot be recalled, it can be used by computer criminals to electronically forger data groups.

In order to prevent the manipulation of DG data, a hash value is computed over every data group. A kind of master hash value is then computed over the sum of all hash values and signed with the country certificate of the issuing country. The reader holds a list of the public keys of all participating countries. Using these it can validate the included data after reading the electronic passport's structure and computing the according hash values. This signed hash value will be stored on the chip in the EF.SOD sector.

Vulnerabilities in the concept

In order to successfully check the hash data, the signature has to be read after intensive format parsing. To do this, the inspection system first reads unchecked data, that are then parsed by the newly created ICAO formats. The whole system's complexity and the lack of possibilities to reuse existing, already audited libraries make programming errors more than likely. The inability to program syntactically correct parsers and to properly handle formats has in recent years been the most common reason for software vulnerabilities, not the actual cryptographic procedures.

ICAO's complex muddle of formats causes several weak spots:



The future of MRTD

It is more than questionable, whether the new electronic passport will prove to be of much use to its new owners. A so far closed system, that inspects the passports, now accepts data from a currently not trustworthy 72 kByte memory with a micro controller – regardless of the fact, that there could just as well be any other software but the ICAO layout running on the chip.

Would a customs official let an unknown person connect a usb stick to his or her PC? Most certainly not. But this is exactly what happens with the electronic passport: its data is first read without any verification. Only after passing them through several non-standard compliant self-made parsers can the reader validate the data.

The programmers of the German reference system Golden Reader Tool (GRT) report, that the implementation of the electronic passport API was a complex and difficult task. In general this rather increases the vulnerability to attacks.

Maybe a team of IT security and data protection experts should have taken a look at the system, before it was launched. The way it is now, the golden rule KISS – Keep it simple, stupid – has been sunk in a sea of lobbyism, featuritis and national interests.

This article does not at all regard the quality of biometric data, that introduces its very own security issues with respect to wrong acceptance- and refusal rates, as well as the impossibility to recover a once compromised feature. The electronic passport's future remains precarious.

MRTD in the press

English

Contact

For press contacts or interviews please contact press@mrtdanalysis.org

Donate

Supprt MRTD-Analysis with a donation: Donate Bitcoin