Access Controls for Electronic Machine-Readable Travel Documents

The Power of NFC: Reading Passports from your Phone

Welcome to our continuing exploration of NFC capabilities and how they enable you to read the data on electronic passports. In part 1 of this series, we examined the history of NFC on iOS and some of the basics of the NFC protocol. In this post, we’ll discuss the access controls in the ICAO9303 specification for electronic machine-readable travel documents (eMRTDs). We’ll also look at the common files stored on a passport’s NFC chip and how those files are accessed. Future posts will build on this foundation to explore more advanced access control options and how to use the Jumio SDK with electronic passports.

Security Capabilities of Electronic Passports

The NFC chips in passports host a basic operating system that provides cryptographic and file retrieval capabilities. The chip may optionally be encrypted and secured with either a basic access mechanism or a password-authenticated access mechanism. Encryption is not required but it’s heavily recommended by the International Civil Aviation Organization (ICAO) and by security organizations. Some countries include additional passive protections, such as the wire mesh faraday cage in the covers of United States passports, preventing access to the NFC chip unless the cover is open.

These security capabilities provide a way of ensuring the data stored on an eMRTD is only read with the consent of the owner of the passport. Without at least basic encryption, a passport could be read unsuspectingly while still in a person’s pocket. The ICAO added supplemental access controls to the standard after security professionals demonstrated several notable weaknesses in the basic encryption. These included brute-force attacks against the encryption key and man-in-the-middle attacks while the passport is being read.

Access Control Types

When the passport data is encrypted, the ICAO9303 specification allows for two primary ways of accessing it: Basic Access Control (BAC) and Password Authenticated Connection Establishment (PACE). Passports issued since January 1, 2018 may have any one of the following configurations (at least as of the time of writing this post):

• No chip access controls, simply called plain MRTDs
• BAC only
• PACE and BAC
• PACE only

In the future the BAC protocol may be deprecated, but as of the time of writing all applications reading an eMRTD must maintain support for both protocols. This post will focus on explaining BAC, and we’ll reserve an in-depth discussion of PACE for the next post in our series.

Whether using BAC or PACE, the purpose of the access controls is to force the reader to provide some knowledge of the physical passport and to then establish a channel for secure communication between the NFC reader and the passport NFC chip. Data is exchanged over this channel using a capability referred to as Secure Messaging. This Secure Messaging mechanism then allows the reader to access the passport’s digital signing certificate as well as sensitive information including biometric identifiers.

Basic Access Control

In order to establish secure messaging with and retrieve data from the NFC chip, the NFC reader must establish a session key. This key is established using 3DES as a block cipher and following a three-pass challenge-response protocol. The password for this key is relatively straightforward, using data printed in the passport itself. The reader can scan the machine-readable zone (MRZ) of the passport using OCR or rely on manual entry of the data. The data elements comprising the password are: document number, date of birth, and expiration date.

In order to begin authentication, the reader issues a get challenge command to the chip. This causes the chip to generate a nonce (a random, one-time-use identifier) and send it to the reader. The reader then issues an external authenticate command to the chip, providing both the chip’s original nonce (to prove it was received and the message is valid) and a new randomly generated nonce. Once this is completed, the reader and chip derive the session keys for further communication, and secure messaging is now possible.

The BAC specification operates on the assumption that negotiating a session key requires opening and physically inspecting the passport. This implies that the passport owner must knowingly hand over the document for inspection and validation. Unfortunately, in practice, the standard is weaker than anticipated.

One major weakness in BAC is the fact that most passport issuers do not assign document numbers randomly; instead, they’re typically assigned sequentially. Knowing how particular countries assign passport IDs, a sophisticated attacker can arrive at a reasonable approximation of the passport number. Combining this with educated guesses on the expiration date and date of birth, the range of possible passwords is greatly reduced and brute force attacks on the encryption are feasible in reasonable timeframes.

Using this knowledge, an attacker gains a few different vectors to compromise passport data. The most straightforward is to passively intercept the transmissions between the reader and the card and then attack the session key later. Attackers can also actively attack cards present in a target’s pocket or purse by concealing a reader under a table or chair. In either case, BAC is not as robust as initially envisioned. This weakness led the ICAO to create the Supplemental Access Controls, including PACE.

Secure Messaging

The result of completing authentication between the reader and the chip, whether BAC or PACE, is establishment of a secure communications channel. Information is exchanged over this channel through a defined Secure Messaging protocol. Once the channel is established, communications are only allowed between the authenticated reader and chip. If another reader attempts to initiate communication, the Secure Messaging channel is aborted and the reader must re-authenticate.

Under BAC, the derived session key is used to encrypt all transmissions over the Secure Messaging channel using 3DES encryption. The BAC protocol allows both the reader and the chip to arrive at the same fixed key (based on the MRZ as described previously), an important facet of symmetric encryption algorithms like 3DES. The PACE protocol also uses symmetric encryption but allows for much more robust AES encryption, and it introduces a Diffie-Hellman algorithm for deriving shared keys.

With Secure Messaging established, the reader may begin issuing commands to the passport chip to retrieve specific data elements. The data on the chip is structured according to the ISO/IEC 7816 standard (see page 12 in ICAO9303, Part 10). Within the chip’s Master File is at least one Application bearing the ISO-registered ID for eMRTDs. The Master File also contains files associated with PACE authentication: EF.CardAccess and EF.CardSecurity. The contents of the Application File are described below.

The commands used with Security Messaging are formulated as smartcard Application Protocol Data Units (APDUs), compliant with ISO/IEC 7816 — Part 4: Organization, security and commands for interchange. The commands supported by MRTDs, as defined in ICAO9303, Part 10, are:

• SELECT — Select the Application and File within the Application to be read
• READ BINARY — Read the binary data from the SELECTed file; the reader may be required to invoke this multiple times to retrieve a larger file, such as the passport image

As part of the Secure Messaging format, both the reader and the chip compute special Command and Response APDUs. After determining the full command or response to be sent, the payload is padded to the proper length and encrypted using 3DES or AES, depending on the access method and configuration of the chip. Section 9.8 of ICAO9303, Part 11, contains an in-depth description of how these APDUs are computed.

Application File and Data Groups
The eMRTD Application (assigned the ID A0 00 00 02 47 10 01 by the ISO) contains up to 18 Electronic Files (EFs) as shown on page 4 in ICAO9303, Part 10. The bulk of these are referred to as Data Groups, numbered 1 through 16. The other two are EF.COM, which provides header and group inventory information, and EF.SOD, a digitally signed file that contains hash values for each Data Group in the Application.

The EF.SOD file is of particular interest to us at Jumio. The signatory for this file is the nation state issuing the passport. The ICAO maintains a master list of valid root certificates used to sign passports. By first satisfying access controls on the passport and then retrieving the EF.SOD file, we’re able to use the ICAO master list to establish a trust chain through to the issuing authority. This gives us an acceptable level of assurance that the passport is legitimate and can be trusted as an identity-proofing document.

Of the 16 possible Data Groups, only the first two are mandatory. The first Data Group (DG1) contains details from the MRZ, as well as additional identifying information as printed on the passport. Also present in DG1 are various check digits, both for certain individual fields as well as a composite check digit. The second Data Group (DG2) contains an image of the passport holder. This image is intended for use with facial recognition systems. The other Data Groups allow for standardized storage of, among other things, additional biometric information (fingerprint and retinal images) and images of passport elements such as the holder’s signature.

At present, Jumio primarily validates the authenticity of passports. This is accomplished by establishing a chain of trust to a certificate authority using the EF.SOD as described above. Our SDK does have access to all the Data Groups, but validation focuses on a few of the fields in Data Groups 1 and 11 — notably the name, date of birth, and place of birth. We can envision uses for the other data in the future, but that’s not currently part of our solution. For example, we might compare the user’s selfie to the snapshot of the passport and also compare it to the encoded photo on the NFC chip.

Summary

This post focused on foundational concepts of eMRTDs and the legacy access mechanism, BAC. Understanding BAC in particular is important, as the ICAO continues to support this for legacy passports. Even when the ICAO decides to deprecate the BAC standard, support will be required until passports requiring it reach their expiration date. Still, the PACE standard does provide much greater security, and our next post will explore it in greater detail. That post will also cover some of the other advanced security mechanisms designed to validate the integrity of the passport chip. Thank you for joining us as we continue to share what we found while working with passport NFC chips!

References

https://www.icao.int/publications/Documents/9303_p10_cons_en.pdf

https://www.icao.int/publications/Documents/9303_p11_cons_en.pdf

This a series of blog posts highlighting our experiences with reading passports from your phone via NFC:

• Part 1: Introduction to Enabling NFC in your App
• Part 2: Access Controls for Electronic Machine-Readable Travel Documents
• Part 3: Supplemental Access Control and Active Authentication
• Part 4: Bringing NFC to the Phone (coming soon)