eKYC deep tech: signatures, scores and attacks.

The document, byte by byte

Start where every remote check starts, with the identity document — but this time read it the way the software does.

The machine-readable zone, with its arithmetic

The two lines at the bottom of a passport (three on most ID cards) are the machine-readable zone (MRZ), laid out by ICAO Doc 9303. Each field that matters — document number, date of birth, expiry — is followed by a check digit, and the final digit of the zone checks a composite of the others. The algorithm is small enough to hold in your head:

1. Give each character a value: digits are themselves, A to Z are 10 to 35, and the filler < is 0.
2. Multiply the values by the repeating weights 7, 3, 1 — first character ×7, second ×3, third ×1, fourth ×7 again, and so on.
3. Sum the products. The check digit is the sum modulo 10.

Work one example once by hand and the MRZ stops being a mystery. But be clear about what the check digit is for: it catches misreads — a camera's OCR turning O into 0, a transposed pair — not forgery. A forger can compute check digits as easily as you can. Integrity against tampering comes from the next layer down.

The chip, its hash tree and its signatures

Biometric passports and modern ID cards carry a contactless chip. The software first has to earn access to it: either Basic Access Control (BAC), where the access keys are derived from MRZ fields (so only someone who has seen the data page can read the chip), or the stronger, newer PACE protocol. Inside, the data lives in numbered data groups of the Logical Data Structure — DG1 repeats the MRZ data, DG2 holds the reference face image — and alongside them sits the Document Security Object (SOD): a file containing a hash of every data group, signed by the issuing state.

Passive authentication is the verification walk: hash each data group you read and compare against the SOD's stored hashes, then verify the SOD's signature against the state's Document Signer Certificate (DSC), which chains up to that state's Country Signing CA (CSCA) — the root certificates states exchange through channels such as the ICAO Public Key Directory. If the chain verifies, you have a cryptographic fact: this data is exactly what the issuing state signed. What passive authentication does not prove is that the chip is original — a byte-perfect copy of a genuine chip carries genuine signatures. Detecting a clone needs a challenge-response protocol (Active Authentication or Chip Authentication), where the chip must prove possession of a private key that cannot be copied out of it.

So a document check is really a stack of claims, each with its own failure mode: the MRZ parses (or the capture was bad), the check digits hold (or OCR misread), the hashes match (or the data was altered), the chain verifies (or the certificate is unknown, expired or revoked), the chip answers the challenge (or it may be a clone). An engineer who knows which layer failed knows what the failure means — and a system should record which layer failed, not just "document rejected".

The face, score by score

Face matching is not magic; it is geometry in a learned vector space, and its errors obey arithmetic you can reason about.

From pixels to a vector

A modern pipeline runs detect → align → embed: find the face, normalise its pose and crop, then pass it through a neural network that outputs an embedding — a vector of a few hundred numbers positioned so that images of the same person land close together and images of different people land far apart. Comparing two faces means comparing two vectors; the similarity score is a distance dressed up as a number.

Two distributions, one threshold

Run millions of comparisons and the scores form two overlapping distributions: genuine pairs (same person) scoring high, impostor pairs (different people) scoring lower. A threshold is a vertical line through both. Everything above it is called a match — including the tail of impostors above the line (the false match rate, FMR); everything below is called a non-match — including the tail of genuine users below it (the false non-match rate, FNMR). Move the threshold and you trade one error for the other; plot FNMR against FMR at every threshold and you have the DET curve, the honest portrait of an algorithm. This is why no serious engineer says a matcher is "99% accurate" — the only meaningful statement is FNMR at a stated FMR, which is exactly how NIST's Face Recognition Technology Evaluation (FRTE) reports its 1:1 results. In practice you choose the FMR your risk tolerates (say, one in a hundred thousand) and you buy the FNMR the algorithm delivers there.

The two hidden variables

Two things move those distributions under your feet. The first is image quality: blur, pose, lighting and compression widen the genuine distribution, and most false rejections in production trace back to a poor capture, not a poor algorithm — which is why quality is measured as its own number (the open-source OFIQ implements the standardised quality components) and why a good system rejects a bad capture before it ever scores a face. The second is who is being matched: NIST's demographic study (NIST IR 8280) measured error rates differing across sex, age and skin tone for many algorithms — differentials that have narrowed in newer systems but must be measured, not assumed. A threshold calibrated on one population can quietly deliver a different FMR on another; an institution that never checks has an unfairness problem it cannot see.

Liveness, and the attack engineer

A matcher only answers "is this the same face?" It cannot answer "is there a live person in front of the camera?" — that is presentation attack detection (PAD), standardised by the ISO/IEC 30107 series, and it is where the arms race lives.

Presentation attacks, and how PAD is scored

A presentation attack puts an artefact in front of the real camera: a printed photo, a replayed video on a screen, a 3D mask. PAD systems look for the tells — texture, depth, reflections, micro-movement, responses to a challenge ("turn your head"). Like matching, PAD is probabilistic, and ISO/IEC 30107-3 scores it with two error rates that mirror FMR and FNMR: APCER, the share of attacks wrongly accepted as genuine, and BPCER, the share of genuine users wrongly rejected as attacks. A vendor who quotes one without the other is telling you half a story — APCER near zero is easy if you reject half your real customers.

Injection attacks walk around the camera

The sharper modern threat does not perform for the camera at all. An injection attack feeds imagery directly into the pipeline — a virtual camera driver, a tampered app, a hardware interposer — so the "camera feed" is whatever the attacker renders, including a real-time deepfake of the victim's face answering your liveness challenges. Camera-facing PAD cannot see an attack that never crossed the lens; ENISA's remote-identity-proofing analysis and the European technical specification on biometric data injection (CEN/TS 18099) treat it as its own discipline. Defence moves down the stack: attest the capture environment (is this a real camera on a real device, in an untampered app?), watch for the artefacts of synthesis and re-encoding, bind the capture cryptographically to the session, and corroborate with signals that are expensive to fake at scale — the document chip's signatures from lesson 1 being the strongest, because a deepfake cannot forge a CSCA chain.

The honest engineering posture

"Liveness passed" is a probability, not a fact. Build as if some attacks get through: layer the independent checks (document cryptography, PAD, injection detection, device and behavioural signals), make any one layer's failure recoverable by the others, and record per layer — the same defence-in-depth and record-keeping logic that runs through every system in this series.

What an assurance level actually asserts

All the machinery so far answers one question to some confidence: is this applicant the person the evidence describes? Assurance frameworks turn that confidence into a claim an institution, an auditor or a counterparty can rely on.

The NIST model: three separable claims

NIST SP 800-63 (revision 4) separates three things institutions often blur. IAL — identity assurance level — is about enrolment: how strongly was the person proofed when the account was created? AAL — authentication assurance level — is about returning: how strong is the sign-in that connects today's session to that enrolled account? FAL covers federation, when one party vouches to another. The separation matters because the chain is only as strong as its weakest link: proof a customer to the highest standard at onboarding, protect the account with a guessable password, and an attacker does not need to beat your biometrics — they log in. Remote eKYC of the kind this series describes — validated evidence, a chip read, a biometric comparison of the live applicant to that evidence, liveness — is the territory of IAL2; the top level, IAL3, is defined around stronger, traditionally in-person or supervised-remote, proofing.

Evidence strength, validation, verification

Inside identity proofing, the framework names three steps you now recognise from earlier lessons. Evidence strength — what class of document is offered (a chipped passport outranks a paper utility bill precisely because of lesson 1's cryptography). Validation — is the evidence genuine and current (the hash tree, the certificate chain, the revocation check)? Verification — is the applicant the person the evidence describes (lesson 2's comparison, protected by lesson 3's liveness)? Europe's eIDAS regulation builds the same ladder with different labels — assurance levels low, substantial and high — and its 2024 revision adds the EU Digital Identity Wallet, which lesson 5 picks up.

The record is the product

When an institution says a customer was "verified at IAL2" or "substantial", it is making an assertion it must be able to defend years later. That means the system records what evidence was presented, which checks ran and their outcomes (which layer of lesson 1 passed; what score and threshold in lesson 2; which PAD result in lesson 3), when, and under which version of the rules — the reproducible, auditable record that every course in this series converges on. An assurance level with no record behind it is a label, not an assurance.

The new identity stack, without the hype

Everything so far verifies identity by inspecting evidence — reading a document, matching a face. The emerging stack inverts the flow: the issuer signs a claim once, and anyone can verify that signature forever.

Verifiable credentials, mechanically

In the W3C Verifiable Credentials model, three roles replace the document: an issuer (a government, a bank) signs a set of claims about a holder, who stores the credential in a wallet and presents it to a verifier. The verifier checks the issuer's digital signature — the same cryptographic move as lesson 1's passive authentication, but over data designed for it rather than scraped from a photographed card. Done well, the model adds selective disclosure: the holder proves "over 18" or "resident of Kenya" without revealing the whole document — less personal data in flight than any scan-and-OCR pipeline can manage, which lands exactly where data-minimisation law points. The mobile driving licence standard (ISO/IEC 18013-5) and the EU Digital Identity Wallet (the 2024 eIDAS revision) are this model reaching production scale.

What changes for eKYC, and what does not

For the verifier, the work shifts from judging an image to verifying a signature and trusting its issuer — no OCR confidence scores, no glare on the laminate. But be precise about what survives the shift:

• Binding still needs biometrics. A valid credential proves what the issuer signed, not who is holding the phone. Connecting the presenter to the credential still needs the matching and liveness of lessons 2 and 3 — or an authenticator bound at an enrolment that did.
• Trust moves, it does not vanish. Instead of CSCA certificates you manage issuer trust lists; a signature from an issuer you should not trust verifies perfectly and means nothing.
• Revocation is the hard part, as it always was: a credential valid at issuance may be cancelled tomorrow, and checking status without letting the status service track the holder is a live engineering tension.
• Adoption is uneven, so for years real systems will verify chips, faces and credentials side by side — which is why the deep mechanics of lessons 1 to 4 stay load-bearing even in the new stack.

That is the honest state of the art, all the way down: arithmetic on a printed zone, a signed hash tree, geometry in an embedding space, probabilities at a threshold, an arms race at the camera, assurance as a defensible record, and signatures beginning to replace scans — every layer checkable, every layer with a failure mode, and nothing anywhere that deserves the word magic.

Your certificate of completion

Enter your name as you want it to appear, then save the certificate as a PDF. In the print window, choose Save as PDF. A certificate is issued once per completion of the course.

Saolix does not record who takes this course, so it cannot verify these certificates. The certificate confirms completion of a free self-paced course and is not an accredited qualification.