How to protect your identity verification from deepfakes - with NFC Learn more
Using our App? Go here

Cloning detection for ePassports

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 NFC 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.

There are two mechanisms that provide clone detection on ePassports: Active Authentication (AA) and Chip Authentication (CA). Both of these mechanisms are supported by ReadID.

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 SaaS (client-server) 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 (and patented) solution to implement this in a secure manner in compliance with the standards.


Try it yourself for free

Interested in NFC-based identity verification? Our free personal app ReadID Me is available in the App and Plays stores. No personal information is shared with Inverid or other parties; it is a client-only verification.

Or subscribe to our newsletter, sent about 6 times per year.