logo dexlab

ePassport security

sample document

An ePassport is a paper passport containing an RFID chip. Chip operation is described by standard Doc 9303 published by the International Civil Aviation Organization (ICAO). The chip contains data about the passport holder including the holder's name, date of birth, document number and facial picture. To prevent fraud the system - both the chip and the inspection system - contains a number of security features. An overview of ePassport security mechanisms:

  • Basic Access Control (BAC)
    BAC protects the communication channel between the chip and the reader by encrypting the transmitted information. Before data can be read from the chip, the reader needs to provide a key which is derived from the date of birth, the date of expiry and the document number. By using BAC the transferred information cannot easily be eavesdropped without knowing the correct key. Using BAC is optional.

  • Passive Authentication (PA)
    PA prevents modification of passport chip data. The chip contains a file ("EF.SOD") that stores the hash values of all files stored in the chip like the picture and finger prints, and a digital signature of these hashes. This digital signature is made using a document signing key which itself is signed by a country signing key. If a file on the chip (like the picture) is changed, the change can be detected since the hash value and /or the digital signature is incorrect. Inspection systems need access to all used public country keys to check whether the digital signature is generated by a trusted country. Using PA is mandatory.

  • Active Authentication (AA)
    AA is used to detect cloned passport chips. The chip contains a private key that cannot be read or copied, but its existence can easily be proven. Using AA is optional.

  • Extended Access Control (EAC)
    EAC adds functionality to check the authenticity of both the chip ("Chip Authentication") and the inspection system ("Terminal Authentication"). Chip Authentication uses AA-like technology to detect cloned chips. Terminal Authentication is used to limit access to EAC-protected data files. Only inspection systems that have access to a secret key - digitally signed by the government - are allowed to read the sensitive data. Furthermore EAC uses stronger encryption than BAC. EAC is typically used to protect finger prints and iris scans. Using EAC is optional. In the European Union, using EAC is mandatory for all documents issued starting June 28th 2009.


Jeroen van Beek, founder of Dexlab, first presented attacks targeting both PA and AA during the 2008 USA Black Hat Briefings in Las Vegas. In later presentations new attacks and a tools are presented. Presentation slides can be found on the Black Hat website:

A description of the attacks can be found below, categorized by the attacked security mechanism:

  • Passive Authentication (PA)
    PA describes how an inspection system can check whether the chip content is signed by an authorized document signer. To do so, an inspection system must check the public key of the document signing key in the chip (part of EF.SOD) against a list of trusted country certificates. This list is:

    A local copy. "Country Signing CA Certificates (CCSCA) MUST distributed by strictly secure diplomatic means (out-of-band distribution)". The problem with this option is that in some cases diplomatic means just aren’t there (e.g. Iran « Israel) and that this is a manual process which is prone to (un)intended human errors.


    The ICAO PKD. The problem with this option is that in May 2008 only 9 countries were signed up to the PKD. According to research of The Times, only 5 countries were actively using the PKD in August 2008.

    Since the list of country keys is not 100% complete in both cases, an attacker can start his own country (country keys are self-signed!) and start issuing passport chips. Real-life inspection systems and Golden Reader Tool (GRT) do not warn about the unknown country key. Note that Golden Reader Tool is the reference implantation for ePassport compliancy testing. According to ICAO "an eMRTD read and accepted by the GRT can be considered as being compliant with the LDS and PKI standards".

  • Active Authentication (AA)
    The index file "EF.COM" - telling the inspection system which files are available - is not protected. By copying the original data files and an altered index file to an ePassport emulator, the optional AA mechanism can be disabled. The issue is described by ICAO in supplement 7 of Doc 9303 (R1-p1_v2_sIV_0006). The issue is "rejected" even though a good fix is described (use EF.SOD instead of EF.COM). There’s a significant risk that countries implement vulnerable code since e.g. ICAO’s "worked example" is insecure. The same supplement that documents the rejected fix also shows a vulnerable example.

    If AA is successfully disabled, cloned chips cannot be detected. This attack might also allow an attacker to disable other optional security features such as finger prints.

    As a proof of concept Dexlab implemented the described downgrade attack for NFC-enabled Nokia cell phones. If you own a Nokia 6131 NFC or 6212 NFC, please try this at home and clone with your phone using eCL0WN!

  • Development process of inspection systems
    Chip characteristics are defined by the ICAO standard. Inspection systems are a responsibility of the country enrolling them. Dutch self scan setups do not seem to perform adequate security checks. The Dutch government responded to the findings (in Dutch) and said that more advanced will be enrolled in 2009. Though there is no standard that documents security features of the inspection systems (yet?). So systems are currently being built and are planned to be enrolled in 2009 but there is no documented design available. No safeguards. No independent third party reviews possible by e.g. universities and security researchers. And we are talking about a critical application called border control...

    Entrust, which handles PKI security for ePassports, says that we should trust them. "Governments’ security experts aren’t dummies and they aren’t going to make those mistakes". No word about a safe design. Just trust the professionals. Yeah right :) Trust but verify...

    Without a documented standard it is not possible to verify if the intended software quality is really implemented.


An example: the European Union passport-free travel zone ("Schengen countries", image source: Wikipedia). If just one Schengen country uses an insecure inspection system, illegal immigrants and terrorists can enter that country and freely travel within the entire zone. So the main question is: are all ePassport inspection systems (now and in future) 100% secure?

schengen countries

Now what?

To better guarantee the safety of ePassports now and in the future it is absolutely necessary to evaluate important public systems like this in an open evaluation procedure. The past, referring for instance to voting computers and the Dutch OV chipcard, has proven that closed (unpublished) implementations are not very secure after all. Although parts of the ePassport documentation are available (for a fee), no open documentation nor evaluation is available for reader equipment. It is necessary that not only the travel document, but the system as a whole can be evaluated and studied.

Do it yourself

Please visit the download section of this website to get an ePassport emulator and software to clone backup your own ePassport chip. For hardware requirements please refer to my presentation slides above.

Further reading

Jeroen van Beek / Dexlab in the news:

Interesting publications and projects by third parties: