Feb 21, 2018

This is the fourth and final posting of our blog series on the security mechanisms of ePassports and similar ICAO 9303 identity documents. In the previous blogs, we provided an overview of the security mechanisms, and discussed the security mechanisms for privacy and authenticity in more depth, and in this last blog we focus on what we call the cloning detection security mechanisms.

Cloning detection revolves around detecting if the RFID chip has been copied. Using the authenticity mechanisms discussed earlier it is possible to validate that the information read from a chip is signed by the issuing government. This however does not prove if the information was read from a legitimate passport or from a copy of one. Depending on the use case, knowing that the holder of the document is in possession of the original passport is desirable or even absolutely necessary. The analogue equivalent of cloning detection is being able to distinguish between original passports from photocopies.

Currently there are two mechanisms that provide clone detection on ePasswords: Active Authentication (AA) and Chip Authentication (CA). Both of these mechanisms are supported by ReadID (with Chip Authentication only partly in production).

Active Authentication is based on asymmetric cryptography, whereby a randomly chosen challenge is sent to the passport, which is then signed by a private key residing on the passport chip. The public key associated with this private key can then be used to check the signature. This public key is part of the chip data that is signed by the issuing county. Since the private key cannot be read (as it’s private) and thus cannot be copied from the passport chip, ReadID can use the Active Authentication mechanism to ensure it is communicating with a real passport contrary to a clone.

Chip Authentication on the other hand is a mechanism which has two purposes: to establish secure messaging between the passport and the terminal (device that reads the passport), while also performing clone detection. Terminal and passport execute a so-called key agreement protocol, whereby both parties generate a public-private key pair, exchange only the public keys and finally derive a shared secret from the other party’s public key and their own private key. This is a well-known mechanism known as ‘Diffie-Hellman Key Exchange’. The terminal and passport use the shared secret to encrypt all further communication, making it only possible for the parties that joined the key agreement to decrypt messages. The trick with Chip Authentication is that the passport does not generate a key pair, but instead always uses the same public and private keys. Similar to Active Authentication, the public key is stored as part of the passport data that is signed by the issuing country. After the terminal has successfully executed the Chip Authentication protocol, it is certain that the passport is not a clone, reason being that the passport is in possession of the passport’s private key, which a clone would not have.

So why are two mechanisms needed? Some passports even have both mechanisms, while others have none! Active Authentication has been criticised for a possibility called 'challenge semantics': with Active Authentication it is possible to let the passport sign short messages. The response of the passport to this challenge is 'transferrable' in a sense that anyone can verify its validity, not only the terminal. Different opinions exist about whether this is a benefit of Active Authentication or a weakness. Notably, German passports lack the Active Authentication mechanism for this reason. With Chip Authentication this benefit/weakness does not exists: the response of the chip after Chip Authentication has occurred, is not transferrable to parties other than the specific terminal and is used as proof or signature.

Both the Active Authentication and Chip Authentication standards were designed with the assumption that the terminal is trusted to check the cloning detection. For the client-server (or SaaS) deployment of ReadID we assume the smartphone (the terminal) is untrusted, therefore the SaaS server always executes the authenticity and cloning detection security mechanisms securely, even if the smartphone contains malware or if has been manipulated in any way. For ReadID we have developed a unique solution to implement this in a secure manner in compliance with the standards.

A recent effort in optimising the performance of passport reading has resulted in an integration of the Password Authenticated Connection Establishment (PACE) protocol used to get access to the chip and Chip Authentication for cloning detection, called PACE-CAM. We have already extended ReadID with a working implementation of PACE. This is released for Android, and it beta for iOS (status October 2019).

Updated 22 oct 2019 with status PACE