Liveness detection and deepfake injection attacks: where face recognition and deepfake detection meet

This is the page where this site's two sections meet. It belongs to the deepfake detection hub and follows from the bridge page: an identity check must recognise the face and decide whether it is live at the same time, and the second decision is where face recognition deployments need deepfake detection.

01What liveness detection is

A face recognition system compares faces; it does not know whether the face it was shown exists in the room. Liveness detection, or presentation attack detection (PAD) in the vocabulary of the ISO/IEC 30107 series, supplies that missing judgement. It may be passive, analysing the captured frames for signs of a flat surface, a screen's refresh pattern or a printed texture, or active, asking the person to turn their head, blink or follow a dot and checking that the response is consistent with a three-dimensional face moving in real time. Either way its output is a second score, separate from the match score, and a verification is accepted only when both pass.

02Presentation attacks versus injection attacks

Printed and replay attacks

A presentation attack is anything held up to a real camera. The classic kinds are a printed photograph, a photograph or video replayed on a phone or tablet screen, and a mask. The OULU-NPU database, one of the standard face anti-spoofing benchmarks, is built from exactly these: "the presentation attack types considered in the OULU-NPU database are print and video-replay", recorded from 55 subjects with the front cameras of six mobile devices across three sessions, 4,950 real-access and attack videos in all (OULU-NPU). The camera genuinely captures the attack, so the evidence is in the captured frames: paper texture, screen moiré, missing depth, reflections.

Virtual cameras and injected deepfakes

An injection attack never reaches the camera. The attacker replaces the sensor's output further down the pipeline, with a virtual camera driver, a modified application or an intercepted stream, and feeds the verification app a video of their choosing. That video can be a face swap or a reenactment of the target produced in real time, of the kinds described on the kinds of face deepfake page. Because the frames were never captured from a flat surface, the cues that catch presentation attacks are absent. What remains is the integrity of the capture path, which the app must attest, and the traces of the generator in the video itself, which is a deepfake detection problem.

03How presentation attack detection is tested

ISO/IEC 30107-3:2023, "Information technology, Biometric presentation attack detection, Part 3: Testing and reporting", second edition published in January 2023, sets out how PAD systems are evaluated and reported; it replaced the 2017 first edition (ISO). Its two headline rates mirror the two error types of any detector. The attack presentation classification error rate (APCER) is the proportion of attack presentations of a given kind that the system wrongly accepts as genuine. The bona fide presentation classification error rate (BPCER) is the proportion of genuine presentations wrongly rejected as attacks. APCER is reported per attack type, because a system can stop prints and pass screens, and the two rates trade off against each other through the threshold in the same way as the false positive and false negative rates on the metrics page. The general framework for biometric error reporting sits one level up, in ISO/IEC 19795-1:2021 (ISO).

Two things follow for reading a liveness claim. A single accuracy figure hides which attack types were tried and how many genuine users were rejected to achieve it. And a PAD test certifies performance against the artefacts in the test, which for most published benchmarks means prints, replays and sometimes masks, not injected video.

04Face anti-spoofing datasets and benchmarks

OULU-NPU (FG 2017) is the most cited of the mobile-era sets. Beyond its 55 subjects and 4,950 videos, its value is in its four protocols, designed "for the evaluation of the generalization capability of the face PAD methods": each holds out a different condition, unseen environment, unseen attack devices, unseen cameras, and all three at once, so that a method is scored on conditions it did not train on. That design predates, and anticipates, the cross-dataset discipline that deepfake detection adopted later. Results are reported as APCER, BPCER and their average, so a paper's table can be read directly against the standard's definitions.

No equivalent public benchmark exists for injection attacks, because the artefact is not an object that can be filmed but a software path that differs by device and application. Published evaluation there is mostly vendor testing against the vendor's own injection methods, which is why this site does not list figures for it.

05Where deepfake detectors fit in a verification flow

A deployment that uses face recognition runs, in order: capture, liveness, matching, decision. The NIST evaluations measure the matching step on operational images and say nothing about liveness, which NIST tests separately if at all; the face verification metrics page explains the match score they report. Presentation attack detection guards the capture step against objects in front of the camera. A deepfake detector of the kind scored on this site's results page guards against injected video, and its published limits apply in full: trained on curated fakes, lower on unseen generators, lower again on compressed streams. A verification flow that relies on it alone inherits those numbers.

For an individual rather than a system, the question is the same but the tools are different; the checking a face video page is the equivalent of this one for a person holding a clip.

How these attacks fit the four steps of an identity check, and which step has a public evaluation, is on the KYC and deepfakes page.