Injection attacks on liveness and video KYC

The path a selfie takes

Every face check begins with light on a sensor and ends with a decision. Between the two, the frames pass through four hands that are not yours: the sensor, the camera driver, the operating system and the capture screen in your app. An attacker who can take over any one of them can hand your app a face that was never in front of the lens.

1. S1Lens and sensorLight becomes pixels
2. S2Camera driverPresents the camera
3. S3Operating systemDelivers the frames
4. S4Your appThe capture screen
5. S5DeepID SDKReads the frames, the path, the device and the SIM
6. S6DecisionWith its reasons

A presentation attack happens in front of the lens, at S1. An injection attack happens later, at S2, S3 or S4, and never touches the lens at all. Liveness reads the frames that reach it, so it answers for S1 and nothing after.

Six attacks, six entry points

From the attack liveness was built for to the ones that never touch the lens, with what liveness alone concludes, the check that catches each one and the decision word in its own column. The reason codes are illustrative.

1. A1

   Photo or mask

   Enters: In front of the lensBlock

   A printed photo, a cut-out or a mask is held up to a real camera on a real phone. The frames are genuine; what is in front of the lens is not.

   Liveness alone

   Usually flags it. The attack liveness was built for. Texture, depth and reflections give it away.

   The DeepID check

   Face liveness flags the flat or rigid surface, and the face is compared with faces on earlier applications. PRESENTATION_ATTACK

2. A2

   Screen replay

   Enters: In front of the lensBlock

   A recorded or generated video plays on a second screen held up to the camera. The frames come through the real pipeline, so the device sees nothing unusual.

   Liveness alone

   Usually flags it. Screen edges, glare and moiré patterns are what liveness looks for.

   The DeepID check

   Liveness reads the screen’s glare, edges and moiré, and the session is checked for the same face elsewhere. PRESENTATION_ATTACK

3. A3

   Virtual camera

   Enters: S2, the camera driverBlock

   A virtual camera registers with the operating system as a camera. Your app asks for the camera and receives whatever video the attacker plays: a recording, a generated face or a live face swap.

   Liveness alone

   Passes. A clean, live-looking face that blinks and turns on cue.

   The DeepID check

   The stream is checked for signs of injection, and the device for root and emulation. VIRTUAL_CAMERA · INJECTED_STREAM · DEVICE_TAMPERED

4. A4

   Hooked app

   Enters: S4, your appBlock

   A hooking framework attaches to your app’s process and intercepts the call that hands camera frames to your code. The real camera keeps working; its frames are dropped and replaced.

   Liveness alone

   Passes. Whatever frames the hook supplies. They look live.

   The DeepID check

   Instrumentation in the app process and a tampered or repackaged app are read on the device. DEVICE_TAMPERED

5. A5

   Emulator

   Enters: Under everythingBlock

   The phone itself is software running on a computer. The sensor, the driver and the operating system are all emulated, and the camera is a webcam or a video file on the host. One person can run many phones at once.

   Liveness alone

   Passes. A webcam or a video file on the computer, presented as the phone’s camera.

   The DeepID check

   Hardware, sensor and build properties no real phone has, and no SIM the network can confirm. EMULATOR · NUMBER_UNVERIFIED

6. A6

   Face swap

   Enters: S2 or S4Block

   A real person sits in front of a camera while a model replaces their face, in real time, with someone else’s, often built from the photo on a stolen ID. It blinks, turns and speaks on cue. The swapped face reaches the app through a virtual camera or a hook.

   Liveness alone

   Can pass. A real person really moving, so movement-based liveness can pass.

   The DeepID check

   Signs of a swapped face on the stream, the path it arrived by, and the same face under other names. No single signal decides. DEEPFAKE_SIGNS · INJECTED_STREAM · FACE_REUSED

What liveness alone proves, and what it cannot

Liveness answers one question well. A face check a bank can rely on needs five more, and most of them are about the path and the phone rather than the face.

Tightening liveness alone does not close the gap. An injected stream shows a live-looking face, so a stricter threshold on the face reaches it late, if at all, and turns away more genuine customers on the way. No vendor spots every generated face. DeepID makes the attacker fake the camera, the phone, the SIM and the history as well, at the same time, and when in doubt the check fails closed: deny or send for review, never pass.

Two tests to ask for

Two standards separate the two kinds of attack, and a bank can ask any vendor, DeepID included, for the lab, the level and the date of a result under each.

• ISO/IEC 30107-3 sets out how presentation attack detection is tested and reported: photos, screens and masks shown to the camera.¹
• CEN/TS 18099 sets out testing for biometric data injection attack detection: fake video fed into the camera stream.²

A result under the first says nothing about the second. Ask for both.

Where DeepID fits

At sign-up, at video KYC and whenever a new phone is bound, DeepID checks that a live person is in front of a real camera, that the stream reached the app untouched, that the phone is intact and the SIM is the customer’s, and that the face has not opened other accounts. The instant answer comes on the phone and the final one from the server before the bank acts, and every session leaves a signed record. See liveness and face match, device intelligence, video KYC and the video KYC deepfake use case.

Which checks run at which moment is your policy, set per journey. DeepID supports compliance and never guarantees it.

Sources

This guide explains mechanisms and quotes no figures. The two standards are the tests to ask a vendor for. Nothing in this guide is legal advice.

1. ISO (opens in a new tab), Jan 2023ISO/IEC 30107-3:2023, Biometric presentation attack detection, Part 3: Testing and reporting
2. EVS (opens in a new tab), Nov 2024CEN/TS 18099:2024, Biometric data injection attack detection