Face Liveness Detection in Biometric Terminals: How to Specify It

Resolution is the wrong question

Two modules can both be listed as 2 MP and behave nothing alike. One is a colour sensor with a rolling shutter; the other pairs a colour sensor with a near-infrared sensor and an 850 nm illuminator. The first will accept a phone screen held 40 cm from the lens. The second will not, because the screen emits almost no energy in that band and the infrared channel sees a flat rectangle instead of a face.

Resolution does have a floor. Face matching works from the relative geometry of roughly 80 landmarks plus texture patches, and most engines want at least 120 pixels between the pupils. A 2 MP sensor at 0.4 to 1.2 metres clears that comfortably. Going to 5 or 8 MP helps at 2 metres, on a large self-service kiosk, or when the face occupies a small part of a wide frame. It does not add anti-spoofing.

So the order of questions is: which channels does the capture have, what attack classes are they meant to reject, and only then how many pixels. Vendors who lead with megapixels are usually telling you they have no second channel.

Three capture architectures and what each can prove

The near-infrared channel works because skin reflects 850 to 940 nm light in a predictable way and a printed sheet or an LCD panel does not. That is a physical property, not a trained behaviour, which is why it holds up across user populations in a way that pure image analysis does not.

The depth channel works on geometry. A photograph has no nose. A curved mask has a nose but usually the wrong curvature and no subsurface scattering, so the depth map is close but not right. Depth is the stronger signal against masks and the weaker signal against a screen, which is why some terminals pair depth with infrared rather than choosing one.

The numbers that belong in the contract

Suppliers quote recognition rates like 99.5 percent. That figure comes from a 1:1 matching test on a still image set and says nothing about whether the image was a live person. The anti-spoofing numbers are separate and are defined in ISO/IEC 30107-3:

• APCER is the share of attack presentations accepted as genuine. Lower is better.
• BPCER is the share of genuine users rejected as attacks. Lower is better, but it moves against APCER.

Both only mean something at a stated operating point and on a stated attack set. A sentence that can go into a purchase order looks like this: BPCER not above 3 percent at APCER not above 1 percent, measured on at least 300 bona fide presentations and 900 attack presentations covering printed photo, screen replay and 3D mask, at 300 to 800 lux, on the firmware version supplied.

If a laboratory report exists, ask for the report date, the firmware version tested and the attack classes it covered. A report on a different build is a different product. If no report exists, the fallback is to run the acceptance script in this article yourself and record the firmware hash, so a later delivery can be compared against the build that passed.

Treat the result as a rate, not a pass or fail. A system that rejects 98 percent of screen attacks is not secure or insecure; it is a system where two in a hundred attempts succeed, and whether that is acceptable depends on whether an operator is watching.

The attacks that actually reach a counter

Threat models written in an office tend to start with silicon masks. What arrives at a service counter is usually simpler:

• A phone screen playing a video. Brightness on a modern phone is 400 to 600 nits, which is enough to look convincing to a colour sensor at 30 to 50 cm. It is the single most common attempt.
• A printed A4 photo. Cheap, and it still works against a monocular camera in dim light where the algorithm has little texture to judge.
• A tablet held up with a recorded clip. The slight motion of a hand holding a device is often read as natural movement by weaker detectors.
• A paper or resin mask. Rare at a bank counter, routine at an unattended gate where nobody is watching.
• Injected video. A virtual camera driver feeds synthetic frames to the SDK and no physical attack ever happens. No sensor-level defence sees this, because there is no sensor in the path.

The last one is worth a separate question in the RFQ. Ask whether the SDK can verify that frames come from the built-in camera, and whether it returns a signed liveness result or only a score. Injection attacks are the reason some deployments require the liveness decision to be made in the terminal firmware rather than in an app.

Conditions that quietly break liveness

A camera that passes on a bench in a lab can fail in a real lobby, and the failures are usually environmental rather than algorithmic.

• Direct sunlight. Sunlight carries strong near-infrared energy. An 850 nm illuminator can be washed out at a glass entrance, and the reflectance difference the check depends on disappears. A 940 nm source, a modulated source with a matched filter, a shading hood or a different mounting position all help; the supplier should be asked what was measured, not what the module datasheet claims.
• Backlight. A window behind the user drives the auto-exposure down until the face is a silhouette. Fixed-exposure capture with an infrared flash solves it and is one reason the second channel earns its cost.
• Masks, glasses and helmets. Masked-face matching is a separate capability from anti-spoofing and has to be specified separately. Safety helmets and reflective vests change the outline the detector expects.
• Distance and height. A fixed-focus module optimised for 0.5 metres produces a soft image at 1.2 metres. On a counter used by standing adults and seated children, a tilt-adjustable camera head is worth more than an extra megapixel.
• Counter glass. Acrylic screens and glass partitions add reflections and, in some installations, a colour cast that the infrared channel reads as an anomaly. A 20 mm offset in mounting position often fixes it.

The practical step is a worst-condition test on site, at the busiest hour, with the partition in place and the sun at the worst angle of the day. Half a day of that finds more problems than a week of lab tuning.

1:1 verification and 1:N identification are different products

A counter check is 1:1: the user presents an ID document, the terminal reads it, and the face is compared against that one record. Because the search space is a single template, the threshold can be relaxed and BPCER stays low. Most identity verification terminals, including the dual-screen ID verification terminal, are built around this flow.

A 1:N deployment is a different problem. Searching a watchlist or an access-control database means the same false accept rate is applied across every record in the set, so the operating point moves and the liveness requirement rises with it: an attack that gets past 1:1 is an impersonation, an attack that gets past 1:N is an unauthorised entry with no credential at all.

Two rules follow. First, do not run the 1:N search on the terminal; capture and quality-check locally, match on the server. Second, do not store templates on the device beyond the upload window. A biometric template is personal data under most regimes even though it cannot be turned back into a photograph, and a field device holding a template library is a concentration of risk that is hard to justify.

Face and fingerprint on the same terminal

Fingerprint is the more reliable single modality indoors and the cheaper one to integrate. It also fails on worn, wet or dirty fingers, and the failure rate on a construction site is high enough to matter. Face is contactless and fast, and it is the modality that survives gloves and clean-room protocols, but it is sensitive to light and to the position of the camera.

Running both is not redundancy for its own sake. The usual pattern is face for the initial 1:1 check and fingerprint as the confirming factor on high-value transactions, or fingerprint as primary with face as a fallback when the sensor rejects twice. Either pattern lowers the number of users who cannot complete a session, which is the metric that shows up in a deployment review.

In the Xinhong range the split is explicit. The XH-400 is a 10.1-inch IP65 tablet with a 5 MP front camera, a Ministry of Public Security certified fingerprint module and an NFC reader, which suits counter and field verification where an operator is present. The dual-screen terminal ships with a 2 MP monocular camera as standard and a 2 MP binocular camera as an option; for an unattended flow that has to resist screen replay, the binocular build is the one to quote. The XH-100 handheld covers mobile enrolment with FAP 10, 20 or 30 fingerprint options in a 5-inch body.

What to write into the RFQ

1. Capture architecture, stated explicitly: monocular RGB, binocular RGB plus NIR, or depth. Refuse a quotation that leaves it ambiguous.
2. Attack classes to be rejected: printed photo, screen replay, video playback, 3D mask, and injected video if the SDK is exposed to third-party apps.
3. APCER and BPCER at a stated operating point, with the attack set size and lighting range.
4. Working distance and user height range, and whether the camera head tilts.
5. Mask, glasses and helmet policy: what the system does, not what the marketing page says.
6. Record format: ISO/IEC 19794-5 face image or a documented template, plus where it is stored.
7. Acceptance script: 30 people, 5 attack presentations each, 2 lighting conditions, results recorded per class on the supplied firmware.

Item 7 is the one that changes behaviour. A supplier who knows the acceptance test before the order will design the build around it, and you end up arguing about measured results rather than adjectives.

What Xinhong ships

We build the capture hardware and integrate the modules; we do not claim a laboratory presentation attack detection certificate for builds that have not been tested, and we will not quote a number we have not measured. What we can do is supply the configuration that matches the attack classes you name, run your acceptance script on a sample before the order, and freeze the firmware version that passed so later deliveries stay comparable.

If your flow is a supervised counter, a monocular terminal with a good fingerprint module is usually enough and someone is watching the screen. If the flow is unattended, or the credential is the face itself, specify the second channel and test it in the room where it will be installed.