Biometrics, remote authentication, and the attack matrix

Enrolment, and the two modes people confuse

A biometric system never stores the picture. At enrolment a sensor captures the characteristic — face, fingerprint, hand geometry, retina, iris, signature, voice — and the system extracts a feature set, a number or set of numbers called the template. What it keeps is (ID, optional PIN, template): a numerical surrogate, not an image.

The system then runs in one of two modes, and the exam does not treat the two words as synonyms even though most people do.

• Verification is one-to-one. The user supplies an identifier and a biometric sample; the system compares the sample against that one stored template. This is authentication in the ordinary sense: a claim, then a check of the claim.
• Identification is one-to-many. The user supplies no identifier at all; the presented sample is compared against every stored template until one matches or none does.

The difference sets the computational cost, and at scale it is enormous. A national border system running in identification mode against a watchlist performs billions of cross-comparisons a day, because every arriving traveller is compared against the entire database rather than against one record.

Why a threshold cannot be tuned to win

Two templates from the same finger never match exactly — sensor noise, dry or swollen skin, a different placement. So matching produces a score s, compared against a threshold t: s ≥ t is a match, s < t is not.

Picture the two distributions. Repeated samples from one genuine user give a bell-shaped spread of scores. Samples from impostors give another bell curve, lower down. The two overlap — that overlap is a property of the biometric and the sensor, not of your policy — and the threshold cuts through it. Two error rates follow:

• False match rate (FMR) — how often samples from different sources are judged the same. A false match accepts an impostor.
• False nonmatch rate (FNMR) — how often samples from the same source are judged different. A false nonmatch rejects a valid user.

Now move the threshold. Raise t, demanding a closer match: fewer impostors clear the bar, so FMR falls — and more genuine users fail to clear it, so FNMR rises. Lower t and both move the other way. The two rates move in opposite directions, always, because they are the two tails on either side of the same cut. There is no setting that reduces both; there is only a choice about which error you would rather make.

That choice is made by naming the application, and three operating points are named:

• The equal-error point, where FMR equals FNMR, is the conventional default and a fair single-number summary of a system's quality.
• A very low FMR for high-security access — a vault door, a key-management console. Here an impostor getting in is a catastrophe and a genuine user being turned away is an inconvenience, so you accept a high FNMR and give people a fallback route.
• A low FNMR for forensic use — a watchlist producing candidates for a human analyst. This is the counter-intuitive one and it is worth being able to defend: a forensic system deliberately tolerates false matches, because missing the person you are looking for is the unrecoverable error, and a human filters the candidate list afterwards.

Plotting FMR against FNMR gives the operating characteristic curve; each point on it is one threshold setting, and lower-and-to-the-left is a better system. Moving along your own curve buys security with convenience, and buys convenience with security, and never buys both. (This exact geometry returns as the base-rate problem in intrusion detection, so it is worth owning now.)

Remote authentication: one skeleton, four protocols

Authenticating over a network adds two threats the local case does not have: eavesdropping on whatever the user sends, and replay of an authentication sequence the attacker observed. The general answer is a challenge–response protocol, and all four variants share one skeleton:

1. The user sends an ID.
2. The host replies with a nonce r — a fresh random value used once — plus the identifiers of the functions to apply.
3. The user returns a value computed over the nonce and their secret.
4. The host recomputes the same value and compares.

The password variant is the one to be able to reconstruct, because three separate defences are stacked in it and each answers a different attack. The host stores h(P), a hash, not the password — so a host attack yields no plaintext. The response is f(r, h(P)), so the hash itself is never transmitted — an eavesdropper cannot lift a value that would let them log in later. And the nonce defeats replay — today's response is worthless tomorrow. Being able to name all three separately, and say which attack each answers, is the exam answer.

The token variant is the same skeleton with a passcode W in place of the password, and one extra move worth noticing: the user activates the token with a password shared only between user and token. The host is not involved in that step and never sees it.

The two biometric variants differ in a way that is the sharpest design argument in the chapter. In the static protocol the client returns E(r, D, BT) — the nonce, the capture device identifier D, and the template — and the host checks three things: the nonce came back right, the matching score against the stored template beats the threshold, and D is a registered device. In the dynamic protocol the host instead sends a random sequence — numbers, characters or words — which the user must speak, type or write; scoring uses the stored template and the challenge sequence.

Why is the capture device authenticated in the static case but not the dynamic one? Because a static template is a fixed secret that can be replayed if stolen, so the host must have a reason to believe the sample came from equipment it trusts. A dynamic biometric is bound to a sequence issued moments ago, so a replayed signal simply answers the wrong question.

Worked example — taking apart a public file of encrypted private keys

A system proposes to abolish the password file. Instead it publishes a world-readable file, one entry per user, holding the user's identifier, their public key, and their private key encrypted under a key derived from their login password. Nothing secret is stored, the argument runs, because the private key is encrypted and the password appears nowhere. Critique it.

The scheme is worse than the file it replaces, for four reasons that build on each other.

The file is public, so the attack is entirely offline. They do not need to break in, and nothing they do afterwards touches the system. Every defence a login path provides evaporates at once: no rate limiting, no account lockout after five failures, no log entry, no alert. An administrator watching the system sees a completely normal day while the attack runs.

The attack is on the password, not on the key. The RSA key may be 3072 bits; irrelevant. The attacker guesses a candidate login password, derives the decryption key from it exactly as the legitimate software would, and decrypts the entry. The effective security of the whole scheme is the entropy of the login password, and that is a number in the low tens of bits, not thousands.

There is a built-in success oracle, and this is the part answers usually miss. How does the attacker know a guess was right? Because the file also publishes the matching public key. Take the candidate private key the decryption produced, sign an arbitrary message with it, and verify that signature under the published public key. It verifies only when the guess was correct. The attacker therefore has a free, instant, perfectly reliable correctness test — supplied by the scheme itself, requiring no interaction with anything.

And the exposure is permanent and undetectable. The attacker can copy the file once and grind on it for years, revisiting it with better hardware and better candidate ordering, and there is no moment at which the defender learns it happened.

The fixes follow directly from the four faults. Do not publish the encrypted private key — keep the file readable only by a privileged account, which restores the perimeter this design threw away. Derive the decryption key with a slow, salted key-derivation function with a high cost parameter, so each guess costs the attacker real time and no work can be shared across users. And do not co-locate the verification material with the thing it verifies: publishing the public key next to the encrypted private key is what converts a hard problem into a checkable one.

The general moral, which is this course's thesis: removing the password file did not remove the password's exposure. It moved it, and made it public.