In this post I will try to explain how electronic passports work, how to read files from them and how to verify the authenticity of the chips inside them. Hopefully it will provide an entry point for those who have not tinkered with smart cards in the past.

First we start with introductions and history.

History

An identity document is a document that proves the identity of a person. These documents can be identity cards, passports, or other types of documents. Machine Readable Travel Documents (MRTDs) are official documents issued by a State^[1] or an organization and are used for travel. They were introduced by the International Civil Aviation Organization (ICAO) to increase the clearance speed of passengers through passport control points^[2].

The ICAO specifies three different sized MRTDs. These are Size 1 Machine Readable Official Travel Documents (TD1), Size 2 Machine Readable Official Travel Documents (TD2), and Size 3 Machine Readable Travel Documents (TD3)^[2]. TD1 and TD2 size documents are usually in the form of a card, and TD3 size documents are usually passport books that contain pages^[2]. All three sized MRTDs contain two mandatory zones. The first one is the Visual Inspection Zone (VIZ), which includes information about the document holder and is eye-readable^[2]. The other zone is the Machine Readable Zone (MRZ) which summarizes the information contained in VIZ. TD1, TD2 and TD3 size documents and their VIZ and MRZ can be seen in figures below.

VIZ

VIZ

MRZ

VIZ

MRZ

VIZ

MRZ

In addition, MRZ includes a check digit for data elements such as the document number, date of birth, and date of expiry. The check digits depend on the values of these data elements and determine if the MRZ is scanned correctly. A final check is calculated on the earlier mentioned information with their check digits included and optional data elements and is placed at the end of the MRZ for TD2 and TD3 size documents and at the end of the second line for TD1 size documents. For example, the information in a TD1 size document MRZ is shown below (hover over the elements for more information).

Electronic Machine Readable Travel Documents (eMRTDs) are Machine Readable Travel Documents (MRTDs) that contain an embedded contactless smart card chip. In 1980, ICAO published the first edition of Document Series 9303 (Doc 9303) to standardize MRTDs^[2]. In 2006, the technical reports for eMRTDs were incorporated into Doc 9303 to create an effective biometric identification system^[2]. Even though Doc 9303 does not standardize national identity documents, many countries already issue identity cards or residence permit cards with eMRTD applets.

The specifications for eMRTDs contain information about the Logical Data Structure (LDS), which describe how the data are stored and formatted in the contactless smart card chip and the Public Key Infrastructure (PKI) used by eMRTDs. Currently, ICAO Doc 9303 part 10^[6] contains the specifications regarding the LDS, and ICAO Doc 9303 part 12^[7] contains the specifications regarding the PKI.

eMRTD Files

The LDS contains the data printed on the eMRTD and some other extra data to prove the authenticity of the chip. There are files from EF.DG1 to EF.DG16, EF.SOD and 4 other files^[6]. These files contain facial image(s), MRZ data, and can optionally contain fingerprints, iris scans, displayed portraits, displayed signature, additional personal details, additional document details, optional details, security options, public keys used for security methods, and name and contact details of the person(s) to notify.

eMRTDs contain four required files and might contain other optional files. The first one is EF.COM which contains the LDS version, the Unicode version, and a list of files present on the document. Next are two files called EF.DG1 and EF.DG2. The file EF.DG1 stores the same information on the MRZ, and the file EF.DG2 stores facial image(s). The last required file is the EF.SOD. This file contains the Document Security Object (SO_D), which store the digests^[8] of files included in the contactless smart card chips in eMRTDs. It is important to note that the digest of the EF.COM file is not included in the SO_D^[9]. The SO_D is also signed, this signature is explained in detail in the next section.

These files and other optional files are placed in the documents during the personalization phase. After the personalization of a document, the chip has to be locked, and this means that no further change can be made in these files; no data can be written, modified, or deleted, and a locked chip cannot be unlocked^[10].

eMRTD PKI

In the PKI used for eMRTDs, a single Certificate Authority called Country Signing Certification Authority (CSCA) is run by each State, and it issues the certificates for that State. CSCAs have self-signed root CSCA Certificates (C_CSCAs) that issue the so-called Document Signer Certificates (C_DSs). The recommended maximum usage period for C_CSCAs is 3-5 years and for C_DSs it is 3 months or after signing 150 000 travel documents, whichever is sooner^[7][11].

The C_DSs sign the SO_D for each document issued by that State. The signed SO_Ds store the digests of files included in the contactless smart card chips in eMRTDs, in a file called EF.SOD as explained in the previous section. This file is used in the mandatory baseline security method “passive authentication.”

eMRTD Security Methods

eMRTDs contain a mandatory baseline security method called Passive Authentication and might also contain other advanced security methods ^[12].

Passive Authentication

In eMRTDs, data stored in the files from EF.DG1 to EF.DG16 are protected from modification by a mandatory security method called Passive Authentication (PA). Passive Authentication protects the contents of documents from changes and ensures the authenticity of data; however, it does not prevent exact copies of the documents. Therefore, other security methods such as Active Authentication and Chip Authentication should be used to prevent the cloning of eMRTD chips. Passive Authentication used to be the only required security method used in eMRTDs until ICAO Doc 9303 7th edition; however, with the ICAO Doc 9303 8th edition, access control is also mandatory.

Passive Authentication uses a PKI to verify the authenticity of the data stored in the eMRTD chip. The specifications for this PKI are in ICAO Doc 9303 part 12^[7]. In addition to the certificates introduced above (C_CSCA and C_DS), this PKI also includes other types of certificates, such as:

• Master List Signer Certificate (C_MS), which is used to sign a Master List (ML) that contains the C_CSCAs that are “trusted” by the issuing State;
• Deviation List Signer Certificate (C_DLS), which is used to issue Deviation Lists (DLs). DLs describe a set of documents with defects; but, it does not apply to individual documents or a small number of documents. In such cases where a small number of documents are defective, the issuing State should recall these documents through other means. DL is issued for thousands of documents if they are all defective, and
• Certificate Revocation Lists (CRLs) are used to revoke any certificate issued by the CSCA. Only the latest C_CSCA can issue CRLs, and these CRLs also include the certificates issued by older C_CSCAs. This makes the PKI simpler.
• LDS2 Signer Certificates, namely LDS2 Travel Stamp Signer Certificate (C_LDS2-TS), LDS2 Electronic Visa Signer Certificate (C_LDS2-V) and LDS2 Additional Biometrics Signer Certificate (C_LDS2-B). I touch upon these briefly towards the end of this post under Terminal Authentication section.
• Bar Code Signer Certificates (C_BCS) and Bar Code Signer for non-constrained environments certificate (C_BCS-NC), which are used to sign the data encoded in the bar code which stores the signature together with the data. ICAO Doc 9303 Part 13 ^[13] goes into detail about the Bar Code usage within eMRTDs. ICAO Doc 9303 Part 12^[7] specifies two use cases for C_BCS usage, Visas and Emergency Travel Documents.

ICAO Public Key Directory (PKD) is a PKD that allows States to distribute necessary objects for eMRTD PKI. These include C_CSCAs, C_DSs, CRLs, C_MSs, and MLs, C_DLSs, and DLs, C_BCSs and C_BCS-NCs. Participation in ICAO PKD requires a registration fee and an annual fee. As more countries participate in the ICAO PKD, the price of these fees goes down. As of 2023, the registration fee is 15 900 USD, and the annual fee is 23 745.45 USD^[14]. The downside of not being a participant of ICAO PKD is to do bilateral agreements on a country-to-country basis. As of February 2024, ICAO PKD has 95 member States^[15].

Chip Access Control

When eMRTDs first was introduced, the chips could be directly read. This let an attacker execute two types of attacks. First, they can read the files inside the document just by being nearby, and this type of attack is called skimming, and also, they can eavesdrop on the communication between the chip and an inspection system. This security feature prevents skimming and eavesdropping by requiring information printed on the document from the inspection system to create an encrypted Secure Messaging (SM) channel for communication between the chip and the inspection system. Until the ICAO Doc 9303 7th edition, the specifications used to allow chips that would not implement any access control, but since 8th edition (2021), chips that do not implement any access control are not allowed. The SM channel is created by establishing two session keys and a Send Sequence Counter (SSC). The first session key, Encryption Session Key (KS_ENC), is used to encrypt and decrypt the Application Protocol Data Unit (APDU) sent between the chip and the inspection system, and the second session key, MAC Session Key (KS_MAC), is used to calculate the Message Authentication Code (MAC) of the APDU. The purpose of the MAC is to verify the integrity and the authenticity of the received APDU. The SSC is a counter that is incremented each time an APDU is sent and is used to prevent APDU reordering and replay attacks. For eMRTDs, there are two access control methods described below.

Basic Access Control (BAC)

BAC is used to create two session keys from the information taken from the MRZ using symmetric-key cryptography^[16]. However, since symmetric-key cryptography is used to derive the session keys, the entropy of the created keys depends on the input length. As for the input, all three inputs have shortcomings. For example, the document numbers are generally sequential, the date of expiry can be assumed at most ten years, and the date of birth can be estimated or assumed less than a hundred years. This makes the entropy of the session keys low by today’s standards^[17], and under certain circumstances, these encrypted channels are shown to be cracked in under 30 seconds^[18].

Password Authenticated Connection Establishment (PACE)

PACE was introduced in 2006 by German Federal Office for Information Security (BSI) to overcome the shortcomings of BAC^[19]. PACE uses public-key cryptography to derive the session keys, and the entropy of the session keys does not depend on the input password. Therefore, for the PACE protocol, a six-digit number called Card Access Number (CAN) can be printed on the document and used as a password to establish an SM channel with the eMRTD. An example of this number is shown below on an Estonian residence permit card sample. In 2011, it was decided that by December 31, 2014, all European Union Member States have to implement PACE in their electronic passports^[20]; however, for global interoperability, States should not implement PACE without implementing BAC until December 31, 2017^[21]. The States may choose only to implement PACE in the eMRTDs they issue starting from January 1, 2018^[21].

CAN

Authentication of Data (Clone Detection)

There are two security methods that prevent cloning of the eMRTD chip, these are Active Authentication (AA) and Chip Authentication (CA). For both Active Authentication and Chip Authentication, a private key file resides in the eMRTD chip. However, these private keys are protected and cannot be extracted or retrieved from the chip but are used internally to prove that the chip is not cloned.

Active Authentication (AA)

For Active Authentication, the inspection system first reads the file EF.DG15 and extracts the public key corresponding to the private key in the chip. Then, if Elliptic-Curve Digital Signature Algorithm (ECDSA) based Active Authentication is used, it conditionally reads the file EF.DG14. The authenticity of the information in these files is provided by the signed digest value of these files. Next, the inspection system sends a challenge to the chip, and the chip creates the signature of this challenge using its private key. This signature is then sent back to the inspection system, and the inspection system verifies that the chip’s private key created the signature. Some countries, such as Turkey and Germany, do not support Active Authentication in their passports because of challenge semantics. Challenge semantics means that an inspection system could send short messages to the chip such as the current time and location and track the document holder ^[23].

If the digest of EF.DG15 is listed in the SO_D, it signals that Active Authentication is supported. The EF.DG15 file contains Active Authentication public key. For Active Authentication, the chip, using the corresponding private key, signs a challenge sent by the inspection system. The inspection system can later verify this signature using the Active Authentication public key. Since the Active Authentication public key is in EF.DG15 and this file is protected by Passive Authentication, the public key cannot be tampered with. If the chip uses ECDSA-based Active Authentication, the ActiveAuthenticationInfo SecurityInfo structure must be present in EF.DG14 and be used for Active Authentication. This entry contains the Object Identifier (OID) of the hashing algorithm used for the Active Authentication. However, if the document uses RSA-based Active Authentication, the hashing algorithm used is found from the trailer bytes attached in the response.

Chip Authentication (CA)

Chip Authentication uses Diffie–Hellman Key Exchange (DH) protocol to create new session keys and verify that the chip is not cloned. Therefore Chip Authentication is not vulnerable to this type of attack.

If the digests of the EF.DG14 file exist in the SO_D, it might contain SecurityInfos structures that might mean that the Chip Authentication mechanism is supported. If present, the Chip Authentication public key (and optionally elliptic curve domain parameters) are read. The chip might support more than one algorithm for Chip Authentication, and in these cases, the inspection system is free to choose any of the supported. Next, the inspection system creates an ephemeral public key pair in the same domain as the Chip Authentication public key and sends this key to the chip. If the card can successfully calculate the shared secret using the key agreement algorithm (DH or Elliptic-Curve Diffie–Hellman) and use this shared secret to compute new session keys, an OK reply is returned. From here onwards, the new session keys are used. To prove that the Chip Authentication public key is authentic and unchanged, Passive Authentication must be used. As a result of this process, the inspection system can ensure that the chip is not cloned. It also provides strong Session Keys (KS_ENC and KS_MAC).

Additional Security Mechanisms

In addition to the security mechanisms mentioned above, there are three more options provided to the States if they so choose to utilize them. These are:

Comparison of Scanned MRZ and MRZ read from EF.DG1

This security method proves that the chip and the physical document belong together however it does not prevent cloning.

Terminal Authentication (TA)

Terminal Authentication is a security method that protects sensitive data from unauthorized access. In the context of eMRTDs, the sensitive data is defined as the fingerprint and iris data stored in EF.DG3 and EF.DG4 files, respectively^[2]. However, this security method requires a new PKI, namely, the Authorization PKI ^[7]. In this PKI, the States have a Country Verifying Certification Authority (CVCA). This CVCA issues a Self-Signed CVCA Certificate (C_CVCA) that in turn issues Document Verifier Certificates (C_DVs) for other States. The C_DVs issue certificates for inspection systems of this State, and these inspection systems can obtain access to sensitive data by first sending the certificate chain that begins with the C_CVCA public key stored in the chip and ends with the certificate issued for the inspection system to the chip, and next by signing the challenge sent back by the chip using the certificate issued for itself.

Encryption of Additional Biometrics

One last mechanism is to encrypt the additional biometrics stored within the chips. This mechanism is out of scope of the ICAO Doc9303 and is left to the States to implement themselves. The decryption keys must be loaded into the Inspection Systems and shared with bilateral agreements with other States if necessary.

If you want to learn more about the technical details about some of the protocols specified here, read on to the second part of this blog post.

Footnotes: