The cryptography behind electronic passports

Did you know that most modern passports are actually embedded devices containing an entire filesystem, access controls, and support for several cryptographic protocols? Such passports display a small symbol indicating an electronic machine-readable travel document (eMRTD), which digitally stores the same personal data printed in traditional passport booklets in its embedded filesystem. Beyond allowing travelers in some countries to skip a chat at border control, these documents use cryptography to prevent unauthorized reading, eavesdropping, forgery, and copying.

This blog post describes how electronic passports work, the threats within their threat model, and how they protect against those threats using cryptography. It also discusses the implications of using electronic passports for novel applications, such as zero-knowledge identity proofs. Like many widely used electronic devices with long lifetimes, electronic passports and the systems interacting with them support insecure, legacy protocols that put passport holders at risk for both standard and novel use cases.

Electronic passport basics

A passport serves as official identity documentation, primarily for international travel. The International Civil Aviation Organization (ICAO) defines the standards for electronic passports, which (as suggested by the “Chip Inside” symbol) contain a contactless integrated circuit (IC) storing digital information. Essentially, the chip contains a filesystem with some access control to protect unauthorized reading of data. The full technical details of electronic passports are specified in ICAO Doc 9303; this blog post will mostly focus on part 10, which specifies the logical data structure (LDS), and part 11, which specifies the security mechanisms.

The filesystem architecture is straightforward, comprising three file types: master files (MFs) serving as the root directory; dedicated files (DFs) functioning as subdirectories or applications; and elementary files (EFs) containing actual binary data. As shown in the above figure, some files are mandatory, whereas others are optional. This blog post will focus on the eMRTD application. The other applications are part of LDS 2.0, which would allow the digital storage of travel records (digital stamps!), electronic visas, and additional biometrics (so you can just update your picture instead of getting a whole new passport!).

How the eMRTD application works

The following figure shows the types of files the eMRTD contains:

There are generic files containing common or security-related data; all other files are so-called data groups (DGs), which primarily contain personal information (most of which is also printed on your passport) and some additional security data that will become important later. All electronic passports must contain DGs 1 and 2, whereas the rest is optional.

Comparing the contents of DG1 and DG2 to the main passport page shows that most of the written data is stored in DG1 and the photo is stored in DG2. Additionally, there are two lines of characters at the bottom of the page called the machine readable zone (MRZ), which contains another copy of the DG1 data with some check digits, as shown in the following picture.

Digging into the threat model

Electronic passports operate under a straightforward threat model that categorizes attackers based on physical access: those who hold a passport versus those who don’t. If you are near a passport but you do not hold it in your possession, you should not be able to do any of the following:

• Read any personal information from that passport
• Eavesdrop on communication that the passport has with legitimate terminals
• Figure out whether it is a specific passport so you can trace its movements¹

Even if you do hold one or more passports, you should not be able to do the following:

• Forge a new passport with inauthentic data
• Make a digital copy of the passport
• Read the fingerprint (DG3) or iris (DG4) information²

Electronic passports use short-range RFID for communication (ISO 14443). You can communicate with a passport within a distance of 10–15 centimeters, but eavesdropping is possible at distances of several meters³. Because electronic passports are embedded devices, they need to be able to withstand attacks where the attacker has physical access to the device, such as elaborate side-channel and fault injection attacks. As a result, they are often certified (e.g., under Common Criteria).

We focus here on the threats against the electronic components of the passport. Passports have many physical countermeasures, such as visual effects that become visible under certain types of light. Even if someone can break the electronic security that prevents copying passports, they would still have to defeat these physical measures to make a full copy of the passport. That said, some systems (such as online systems) only interact digitally with the passport, so they do not perform any physical checks at all.

Cryptographic mechanisms

The earliest electronic passports lacked most cryptographic mechanisms. Malaysia issued the first electronic passport in 1998, which predates the first ICAO eMRTD specifications from 2003. Belgium subsequently issued the first ICAO-compliant eMRTD in 2004, which in turn predates the first cryptographic mechanism for confidentiality specified in 2005.

While we could focus solely on the most advanced cryptographic implementations, electronic passports remain in circulation for extended periods (typically 5–10 years), meaning legacy systems continue operating alongside modern solutions. This means that there are typically many old passports floating around that do not support the latest and greatest access control mechanisms⁴. Similarly, not all inspection systems/terminals support all of the protocols, which means passports potentially need to support multiple protocols. All protocols discussed in the following are described in more detail in ICAO Doc 9303 Part 11.

Legacy cryptography

Legacy protection mechanisms for electronic passports provide better security than what they were replacing (nothing), even though they have key shortcomings regarding confidentiality and (to a lesser extent) copying.

Legacy confidentiality protections: How basic access control fails

In order to prevent eavesdropping, you need to set up a secure channel. Typically, this is done by deriving a shared symmetric key, either from some shared knowledge, or through a key exchange. However, the passport cannot have its own static public key and send it over the communication channel, because this would enable tracing of specific passports.

Additionally, it should only be possible to set up this secure channel if you have the passport in your possession. So, what sets holders apart from others? Holders can read the physical passport page that contains the MRZ!

This brings us to the original solution to set up a secure channel with electronic passports: basic access control (BAC). When you place your passport with the photo page face down into an inspection system at the airport, it scans the page and reads the MRZ. Now, both sides derive encryption and message authentication code (MAC) keys from parts of the MRZ data using SHA-1 as a KDF. Then, they exchange freshly generated challenges and encrypt-then-MAC these challenges together with some fresh keying material to prove that both sides know the key. Finally, they derive session keys from the keying material and use them to set up the secure channel.

However, BAC fails to achieve any of its security objectives. The static MRZ is just some personal data and does not have very high entropy, which makes it guessable. Even worse, if you capture one valid exchange between passport and terminal, you can brute-force the MRZ offline by computing a bunch of unhardened hashes. Moreover, passive listeners who know the MRZ can decrypt all communications with the passport. Finally, the fact that the passport has to check both the MAC and the challenge has opened up the potential for oracle attacks that allow tracing by replaying valid terminal responses.

Forgery prevention: Got it right the first time

Preventing forgery is relatively simple. The passport contains a file called the Document Security Object (EF.SOD), which contains a list of hashes of all the Data Groups, and a signature over all these hashes. This signature comes from a key pair that has a certificate chain back to the Country Signing Certificate Authority (CSCA). The private key associated with the CSCA certificate is one of the most valuable assets in this system, because anyone in possession of this private key⁵ can issue legitimate passports containing arbitrary data.

The process of reading the passport, comparing all contents to the SOD, and verifying the signature and certificate chain is called passive authentication (PA). This will prove that the data in the passport was signed by the issuing country. However, it does nothing to prevent the copying of existing passports: anyone who can read a passport can copy its data into a new chip and it will pass PA. While this mechanism is listed among the legacy ones, it meets all of its objectives and is therefore still used without changes.

Legacy copying protections: They work, but some issues remain

Preventing copying requires having something in the passport that cannot be read or extracted, like the private key of a key pair. But how does a terminal know that a key pair belongs to a genuine passport? Since countries are already signing the contents of the passport for PA, they can just put the public key in one of the data groups (DG15), and use the private key to sign challenges that the terminal sends. This is called active authentication (AA). After performing both PA and AA, the terminal knows that the data in the passport (including the AA public key) was signed by the government and that the passport contains the corresponding private key.

This solution has two issues: the AA signature is not tied to the secure channel, so you can relay a signature and pretend that the passport is somewhere it’s not. Additionally, the passport signs an arbitrary challenge without knowing the semantics of this message, which is generally considered a dangerous practice in cryptography⁶.

Modern enhancements

Extended Access Control (EAC) fixes some of the issues related to BAC and AA. It comprises chip authentication (CA), which is a better AA, and terminal authentication (TA), which authenticates the terminal to the passport in order to protect access to the sensitive information stored in DG3 (fingerprint) and DG4 (iris). Finally, password authenticated connection establishment (PACE⁷, described below) replaces BAC altogether, eliminating its weaknesses.

Chip Authentication: Upgrading the secure channel

CA is very similar to AA in the sense that it requires countries to simply store a public key in one of the DGs (DG14), which is then authenticated using PA. However, instead of signing a challenge, the passport uses the key pair to perform a static-ephemeral Diffie-Hellman key exchange with the terminal, and uses the resulting keys to upgrade the secure channel from BAC. This means that passive listeners that know the MRZ cannot eavesdrop after doing CA, because they were not part of the key exchange.

Terminal Authentication: Protecting sensitive data in DG3 and DG4

Similar to the CSCA for signing things, each country has a Country Verification Certificate Authority (CVCA), which creates a root certificate for a PKI that authorizes terminals to read DG3 and DG4 in the passports of that country. Terminals provide a certificate chain for their public key and sign a challenge provided by the passport using their private key. The CVCA can authorize document verifiers (DVs) to read one or both of DG3 and DG4, which is encoded in the certificate. The DV then issues certificates to individual terminals. Without such a certificate, it is not possible to access the sensitive data in DG3 and DG4.

Password Authenticated Connection Establishment: Fixing the basic problems

The main idea behind PACE is that the MRZ, much like a password, does not have sufficient entropy to protect the data it contains. Therefore, it should not be used directly to derive keys, because this would enable offline brute-force attacks. PACE can work with various mappings, but we describe only the simplest one in the following, which is the generic mapping. Likewise, PACE can work with other passwords besides the MRZ (such as a PIN), but this blog post focuses on the MRZ.

First, both sides use the MRZ data (the password) to derive⁸ a password key. Next, the passport encrypts⁹ a nonce using the password key and sends it to the terminal, which can decrypt it if it knows the password. The terminal and passport also perform an ephemeral Diffie-Hellman key exchange. Now, both terminal and passport derive a new generator of the elliptic curve by applying the nonce as an additive tweak to the (EC)DH shared secret¹⁰. Using this new generator, the terminal and passport perform another (EC)DH to get a second shared secret. Finally, they use this second shared secret to derive session keys, which are used to authenticate the (EC)DH public keys that they used earlier on in the protocol, and to set up the secure channel. Figure 6 shows a simplified protocol diagram.

Anyone who does not know the password cannot follow the protocol to the end, which will become apparent in the final step when they need to authenticate the data with the session keys. Before authenticating the terminal, the passport does not share any data that enables brute-forcing the password key. Non-participants who do know the password cannot derive the session keys because they do not know the ECDH private keys.

Gaps in the threat model: Why you shouldn’t give your passport to just anyone

When considering potential solutions to maintaining passports’ confidentiality and authenticity, it’s important to account for what the inspection system does with your passport, and not just the fancy cryptography the passport supports. If an inspection system performs only BAC/PACE and PA, anyone who has seen your passport could make an electronic copy and pretend to be you when interacting with this system. This is true even if your passport supports AA or CA.

Another important factor is tracing: the specifications aim to ensure that someone who does not know a passport’s PACE password (MRZ data in most cases) cannot trace that passport’s movements by interacting with it or eavesdropping on communications it has with legitimate terminals. They attempt to achieve this by ensuring that passports always provide random identifiers (e.g., as part of Type A or Type B ISO 14443 contactless communication protocols) and that the contents of publicly accessible files (e.g., those containing information necessary for performing PACE) are the same for every citizen of a particular country.

However, all of these protections go out of the window when the attacker knows the password. If you are entering another country and border control scans your passport, they can provide your passport contents to others, enabling them to track the movements of your passport. If you visit a hotel in Italy and they store a scan of your passport and get hacked, anyone with access to this information can track your passport. This method can be a bit onerous, as it requires contacting various nearby contactless communication devices and trying to authenticate to them as if they were your passport. However, some may still choose to include it in their threat models.

Some countries state in their issued passports that the holder should give it to someone else only if there is a statutory need. At Italian hotels, for example, it is sufficient to provide a prepared copy of the passport’s photo page with most data redacted (such as your photo, signature, and any personal identification numbers). In practice, not many people do this.

Even without the passport, the threat model says nothing about tracking particular groups of people. Countries typically buy large quantities of the same electronic passports, which comprise a combination of an IC and the embedded software implementing the passport specifications. This means that people from the same country likely have the same model of passport, with a unique fingerprint comprising characteristics like communication time, execution time¹¹, supported protocols (ISO 14443 Type A vs Type B), etc. Furthermore, each country may use different parameters for PACE (supported curves or mappings, etc.), which may aid an attacker in fingerprinting different types of passports, as these parameters are stored in publicly readable files.

Security and privacy implications of zero-knowledge identity proofs

An emerging approach in both academic research and industry applications involves using zero-knowledge (ZK) proofs with identity documents, enabling verification of specific identity attributes without revealing complete document contents. This is a nice idea in theory, because this will allow proper use of passports where there is no statutory need to hand over your passport. However, there are security implications.

First of all, passports cannot generate ZK proofs by themselves, so this necessarily involves exposing your passport to a prover. Letting anyone or anything read your passport means that you downgrade your threat model with respect to that entity. So when you provide your passport to an app or website for the purposes of creating a ZK proof, you need to consider what they will do with the information in your passport. Will it be processed locally on your device, or will it be sent to a server? If the data leaves your device, will it be encrypted and only handled inside a trusted execution environment (TEE)? If so, has this whole stack been audited, including against malicious TEE operators?

Second, if the ZK proving service relies on PA for its proofs, then anyone who has ever seen your passport can pretend to be you on this service. Full security requires AA or CA. As long as there exists any service that relies only on PA, anyone whose passport data is exposed is vulnerable to impersonation. Even if the ZK proving service does not incorporate AA or CA in their proofs, they should still perform one of these procedures with the passport to ensure that only legitimate passports sign up for this service¹².

Finally, the system needs to consider what happens when people share their ZK proof with others. The nice thing about a passport is that you cannot easily make copies (if AA or CA is used), but if I can allow others to use my ZK proof, then the value of the identification decreases.

It is important that such systems are audited for security, both from the point of view of the user and the service provider. If you’re implementing ZK proofs of identity documents, contact us to evaluate your design and implementation.