Supplemental Access Control and Active Authentication

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. Part 1 and part 2 of this series examined the history of NFC on iOS, discussed the NFC protocol, and introduced ICAO9303, the specification for Electronic Machine-Readable Travel Documents (eMRTDs). This post expands on these concepts to focus on the features introduced with Supplemental Access Control (SAC) to shore up weaknesses in the Basic Access Control (BAC) specification. We will also look briefly at Active Authentication, which is used to validate the integrity of the NFC chip.

Why Supplemental Access Controls?

Prior to the establishment of SAC protocols, the security of electronic passports relied on the BAC mechanism explored in detail in the previous article of this series. The older protocol displayed several notable vulnerabilities, which SAC primarily addresses through the new Password-Authenticated Connection Establishment (PACE) mechanism.

The most straightforward change with the newer protocol is the introduction of more robust encryption standards. PACE allows for AES encryption with up to 256-bit keys, a vast improvement over the 3DES encryption that BAC originally required. More important than this encryption upgrade, however, is the introduction of a Diffie-Hellman key exchange algorithm for deriving session keys. This greatly improves upon the simple shared secret used to derive session keys with BAC.

Negotiating session keys still begins with a shared password. Just as with BAC, this shared password may be the machine-readable zone (MRZ) on the passport’s data page. A more secure option is now available, however, in the form of a Card Access Number (CAN). The CAN is randomly generated using a cryptographically secure algorithm providing a much greater degree of entropy over the MRZ, which has many predictable or narrowly defined elements.

With Diffie-Hellman, or the more secure Elliptic-Curve variant, the system uses this shared password to arrive at cryptographically strong session keys. Standard Diffie-Hellman uses modulo arithmetic to compute a shared secret. This shared secret may be determined via brute-force methods, though it’s computationally expensive. Elliptic-Curve Diffie-Hellman creates an even more secure shared key for the same key length. When compared to RSA encryption, for example, a 256-bit elliptic curve key is equivalent in strength to a 3,072-bit RSA public key.

Along with the enhanced encryption, SAC defines a mechanism for the passport’s NFC chip to validate whether the reader is authorized to access data on the passport. This is accomplished by establishing a chain of trust whereby issuers provide signed certificates to the inspection stations of trusted nations or devices.

This aspect of SAC works alongside Extended Access Control (EAC), which describes two capabilities to increase security of eMRTDs — chip authentication and terminal authentication. These controls are used primarily to gate access to the more sensitive data groups described in part two of this series. Most notably, this includes fingerprint and iris images. Accessing this information is not necessary for the identity verification Jumio currently performs, so EAC is beyond the scope of this article.

Initiating PACE

Establishing a PACE session is a multi-step process, including (at a very high level):

• Determine the appropriate encryption protocols
• Compute the initial password and map nonces
• Generate ephemeral domain parameters
• Perform a Diffie-Hellman key exchange
• Derive session keys and verify authentication tokens
• Begin secure messaging

Performing these steps involves a sequence of Application Protocol Data Units (APDUs) issued to the passport NFC chip. The APDU specification is part of the ISO/IEC smartcard specification and is defined in ISO/IEC 7816–4 Organization, security and commands for interchange. For the purposes of this article we’ll mention the commands used and then explore the APDU structure in more detail in Part 4 of this series.

Protocol Determination

The first step in negotiating a PACE connection is querying the CardAccess file from the passport. This file is available to the inspection station (mobile device) before a secure session is established. It describes the encryption protocols supported by the eMRTD NFC chip. If this file is not available, the inspection station reverts to using BAC.

Querying the file uses a basic Read Binary APDU. The file consists of a few key elements: a list of protocols supported by the eMRTD, a version number, and parameter ID. Each line in the protocol list defines the following information for a given protocol: the mapping type, symmetric cipher, key length, block cipher mode, and authentication token. For example, PACE with an Elliptic Curve Diffie-Helman key agreement, generic mapping mode, and 256-bit AES block cipher with CMAC is represented as id-PACE-ECDH-GM-AES-CBC-CMAC-256.

All combinations of protocols, as well as descriptions of the other parameters, are found in the ICAO report on supplemental access control. Issuers of passports using PACE must support at least one of the listed protocols. Inspection stations by contrast must support all possible combinations to ensure interoperability. To keep this requirement manageable, the ICAO chose to keep the available protocol permutations to a manageable count, defining a total of eight standard Diffie-Hellman and 11 Elliptic Curve Diffie-Hellman protocols.

Password Computation

As with BAC, the PACE protocol begins with a shared password. Unlike BAC, the password is used to initiate a Diffie-Hellman key exchange. The password may be one of two values: the MRZ or, if available, the CAN printed on the passport’s data page. The CAN is much more secure than the MRZ, being generated by a cryptographically secure algorithm, but it is optional, and not all passport issuers make use of it.

Regardless of which password is used, the first step is computing its SHA-1 message digest. This hashed value is then issued to the eMRTD in a Basic Authentication APDU. The response from the NFC chip contains a securely generated nonce — a one-time use, cryptographically secure random number — encrypted with the same shared password.

One word of caution here: some NFC chips implement protections against invalid password submission. One of our developers, in prototyping PACE interactions, managed to lock his passport. Of course, figuring this out was complicated by the 20-second timeout iOS enforces on NFC reads. He had a long moment of panic until he realized he could unlock the passport using a separate Android device that had a different passport-reading utility loaded on it.

Nonce Mapping and Shared Secret Generation

Once decrypted, the nonce is mapped into a pseudorandom number generator. There are two mapping methods available: integrated and generic. Under integrated mapping, the inspection device randomly generates a new nonce and sends it to the eMRTD to be used in the mapping function. Under generic mapping, the inspection device and eMRTD conduct an anonymous Diffie-Hellman key exchange to generate the new value used in the mapping function.

The mapping functions yield ephemeral domain parameters, as described in the ICAO report on supplemental access control mentioned previously. The inspection system and eMRTD perform a Diffie-Hellman key exchange based on these ephemeral domain parameters. The result of this exchange is either an unsigned integer or, in the case of Elliptic Curve Diffie-Hellman, a point on the shared curve.

Key Derivation and Secure Messaging

The next step is derivation of session keys using the results of the Diffie-Hellman exchange. This may be classic Diffie-Hellman or the more secure Elliptic Curve variant, depending on what the eMRTD supports and defines in the CardAccess file. With the session keys in hand, the inspection station and eMRTD are free to initiate secure messaging using these keys to encrypt the APDUs. A send sequence counter (SSC) maintains an active count of every message transferred between the devices and is included as part of each APDU. In the case that secure messaging is ever interrupted, the SSC of the last successful message and the previous session key are used with basic authentication APDUs for generating new session keys, allowing messaging to resume.

Once secure messaging is started, the eMRTD may only communicate with the inspection device that initiated PACE. The SSC, along with the shared secrets generated via Diffie-Hellman, prevent other devices from inserting or intercepting messages. While messages may be recorded and decoded using brute force mechanisms, real-time interception and decoding of the messages is computationally prohibitive, allowing a great degree of trust in this communications channel.

Summary

This post reviewed the PACE protocol in detail. The Jumio SDK implements these steps to allow application developers a great deal of certainty in proofing the identity of users. The next post in this series will explore in more detail what the Jumio SDK provides and how it may be used in end-user applications.

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)