NFC passport chip check

A foreign applicant proves identity with the passport’s contactless chip. The phone opens an encrypted channel to the chip with a key that only the printed data page can give, reads the data, and the system proves that the data was signed by the issuing state and has not been changed. A 1:1 face match with a presentation-attack check then ties the person holding the phone to that data.

Available in: the native mobile app only (iOS and Android, on a phone with NFC). A web browser cannot send the commands a passport chip needs — Web NFC reads NDEF tags only, not ISO/IEC 14443 APDUs. An applicant who starts on the web is shown a QR code at this step; the app reads the chip and the result returns to the same application.

Who does it: the applicant holds the passport to the phone. Officers read the result on the identity tab of the application and customer file. This page is written for IT, risk and audit readers who need to know what is checked.

Standards: ICAO Doc 9303, 8th edition, Parts 10–12 · RFC 5652 (CMS) · ISO/IEC 14443 and ISO/IEC 7816-4 · ISO/IEC 19794-5 (face image) · ISO/IEC 30107-3 (presentation attack detection).

Opening the channel

Everything in this diagram happens between the app and the chip on the applicant’s own phone.

The key comes from the printed page; PACE turns it into session keys without sending a key over the air; every command after that is encrypted and MACed.

Stage	What happens
1 Key from the printed page	The app reads the MRZ by OCR and builds `MRZ_information` = document number ‖ check digit ‖ date of birth ‖ check digit ‖ date of expiry ‖ check digit. It derives `K_π = KDF(SHA-1(MRZ_information), 3)`, cut to the length the chip’s cipher uses. Nothing leaves the phone at this stage.
2 PACE (Generic Mapping, ECDH)	The chip sends a nonce `s` encrypted under `K_π`; only a reader that saw the real page can decrypt it. Both sides exchange ephemeral keys (`PK_A = x·G`, `PK_C = y·G`) and map to a new generator `Ĝ = s·G + x·PK_C`. A second exchange over `Ĝ` gives the shared secret `K = x'·PK'_C`, from which `K_Enc = KDF(K, 1)` and `K_MAC = KDF(K, 2)`. Each side proves it holds the same keys with a token: `T_A = MAC(K_MAC, PK'_C)`, `T_C = MAC(K_MAC, PK'_A)`. A wrong MRZ gives a wrong `s`, and every later step fails.
3 Secure Messaging	Every APDU is wrapped as `DO'87' = E(K_Enc, data)` and `DO'8E' = MAC(K_MAC, SSC ‖ …)`. The send sequence counter `SSC` goes up by one on every message, so a changed byte fails the MAC and ends the session, and an old message cannot be replayed.
4 Read	`SELECT` and `READ BINARY` over the encrypted channel: DG1 (the MRZ data), DG2 (the face image, ISO/IEC 19794-5, JPEG or JPEG 2000) and EF.SOD (the document security object, a CMS SignedData).

A chip that does not support PACE is read with BAC: K_seed = the first 16 bytes of SHA-1(MRZ_information), then a challenge–response with 3DES-CBC and Retail MAC (ISO/IEC 9797-1 algorithm 3). The principle is the same — the key comes from the printed page. The protocol used is recorded with the result.

Proving the data and the person

The app sends the raw DG1, DG2 and EF.SOD to the system. The checks below run in the system against its own trust store, offline: no call is made to the issuing state at the time of the application.

Three Passive Authentication checks prove the data; the face match proves the person. All four must pass.

Check	What it computes	What it proves
A1 Data integrity	`H(DG1)` and `H(DG2)`, with the hash algorithm declared in the LDSSecurityObject, must equal `dataGroupHashValue[1]` and `dataGroupHashValue[2]`.	The data read now is the data written when the passport was issued.
A2 Document signature	`messageDigest` in `signedAttrs` must equal `H(LDSSecurityObject)`, and `Verify(PK_DSC, signature, H(signedAttrs))` must be true.	The hash table was signed by the holder of the Document Signer key (DSC). Changing any one hash breaks the signature.
A3 Certificate chain	`Verify(PK_CSCA, DSC.signature)` is true; the CSCA is in the system’s trust store; the DSC’s validity period, `keyUsage` and the CSCA’s `basicConstraints` are checked; revocation is checked against the CRL where the issuing state publishes one.	The DSC leads back to the state that issued the passport.
Face 1:1 and PAD	The DG2 image is compared 1:1 with a live face captured at that moment; the similarity score is compared with a threshold set in advance, with a presentation-attack check to ISO/IEC 30107-3.	The person at the phone is the person whose data was proven genuine.

Trust store. CSCA certificates come from the CSCA master list, itself a signed CMS SignedData whose signature is checked before import. The store is updated on a set cycle and is under the system’s control; certificates are never taken from the session being checked.

What a forger would have to do

The chain from the issuing state to the data in the chip: alter any level and the check at that level fails; a full copy of a genuine chip is closed by the face match with PAD.

Check	To pass, a forger must	Why that is not practical
PACE / BAC	Have the real MRZ of the passport in hand to recover `s` from `z`	`K_π` is never sent; an eavesdropper without `s` cannot compute `Ĝ` or the session key.
Secure Messaging	Know `K_MAC` to produce a correct MAC, with an `SSC` that matches the chip’s	A changed byte fails the MAC; an old message fails the counter.
A1	Build DG data whose hash equals the value already signed in the LDSSecurityObject	That is a second preimage of SHA-2, for which no practical method is known.
A2	Produce a valid signature without the DSC private key	RSA and ECDSA rest on factoring and the discrete logarithm, with no practical attack at the key sizes in use.
A3	Hold the issuing state’s CSCA private key, or insert a false certificate into the trust store	The trust store comes from a signed master list under the system’s control and does not accept certificates from the session.
Face 1:1 and PAD	Present a face that meets the threshold against DG2 and passes the presentation-attack check	It ties the person physically present to the proven data, which closes off using someone else’s genuine passport.

What this check does not cover, and what covers it

Passive Authentication proves the data, not the chip. A full copy of an unmodified chip, with the original data and signatures, still passes A1–A3.
Active Authentication and Chip Authentication would detect a copied chip, but not every issuing state supports them, so they cannot be required of every passport.
The control that covers this is the combination already in the flow: the channel can only be opened with the printed page in hand, and the 1:1 face match with presentation-attack detection ties the live person to the chip’s image.
Revocation lists are not published by every state. The system checks the status only where a source exists, and records the source and the time it checked.

What is recorded

So that the same check can be re-run on the same evidence:

the access protocol (PACE or BAC) and the algorithms used — hashAlgorithm and signatureAlgorithm;
every pair of hashes — computed by the system and read from dataGroupHashValues;
the DSC used — serialNumber, issuer, subject, validity, subjectKeyIdentifier;
the CSCA used — subject, subjectKeyIdentifier, and which master list and import it came from;
the revocation result, its source and the time it was checked;
the face result — similarity score, the threshold applied, and the presentation-attack result;
the time of the application and a log of every stage in both diagrams.

What the system does or refuses

Any one check fails, the passport check fails. The result passes only when A1, A2, A3 and the face match all pass.
The phone never decides the result. The app reads the chip; Passive Authentication and the face decision run in the system.
Web hands off to the app. On the web, this step shows a QR code that opens the native app; the application continues in the same place after the chip is read.