Liveness Detection Techniques for
Biometric Authentication

Biometric authentication is only as strong as its ability to distinguish a living person from a forgery. Liveness detection—also called presentation attack detection (PAD)—is the critical layer that separates production-grade biometric systems from those vulnerable to trivially cheap spoofing. A printed photograph, a looping video on a tablet screen, a silicone mask molded from a 3D scan, or a GAN-generated deepfake injected at the camera driver level: each of these represents a distinct class of presentation attack, and each requires a different detection strategy. Without robust liveness detection, biometric authentication is theater—a system that authenticates images, not people.

The stakes are not abstract. In 2025, presentation attacks accounted for an estimated 18% of biometric fraud attempts across the financial sector. The attack surface is expanding: consumer-grade deepfake tools can generate photorealistic face swaps in real time, and injection attack toolkits that bypass camera APIs entirely are available as open-source projects. Any biometric system deployed without layered liveness detection is operating on borrowed time.

Passive vs Active Liveness Detection

Liveness detection methods divide into two broad categories: passive and active. Each has distinct strengths, failure modes, and user experience implications. Understanding both is essential for architects designing biometric authentication pipelines.

Passive Liveness Detection

Passive liveness operates without requiring any deliberate action from the user. The system analyzes the captured biometric sample—typically a single frame or short video clip—for artifacts that distinguish a live face from a presentation attack instrument (PAI). The user simply looks at the camera. There is no instruction to blink, turn their head, or speak a phrase.

The core techniques in passive liveness include:

• Texture analysis: Real skin exhibits micro-texture patterns (pores, fine wrinkles, subsurface light scattering) that printed photos and screen replays cannot reproduce faithfully. Convolutional neural networks trained on large PAI datasets can detect these differences at the pixel level, even when the attack image is high-resolution. The key discriminator is the frequency domain: printed paper introduces halftone dot patterns, and LCD/OLED screens produce a characteristic sub-pixel grid that is absent from real skin.
• Moiré pattern detection: When a camera captures an image displayed on another screen, the interaction between the two pixel grids creates moiré interference patterns—visible as wavy bands or color shifts. These patterns are physically unavoidable when re-photographing a screen and provide a high-confidence signal for screen replay attacks. Detection is robust even when the attack screen is high-refresh-rate or uses anti-moiré coatings.
• Micro-expression and micro-movement analysis: Even when a subject holds still, a living face exhibits involuntary micro-movements: blood flow causes subtle color changes in the skin (remote photoplethysmography, or rPPG), the eyes perform microsaccades at 1–2 Hz, and the nostrils and lips exhibit sub-millimeter motion from breathing. A printed photo or static mask produces none of these signals. Temporal analysis across even 0.5 seconds of video can extract enough signal to reject static PAIs with high confidence.
• Specular reflection analysis: The cornea of a live eye produces characteristic specular highlights that move consistently with head position and light source direction. 2D reproductions (photos, screens) produce reflections that are either absent, static, or geometrically inconsistent with the illumination environment. This signal is particularly effective against screen replay attacks.

The primary advantage of passive liveness is user experience: the verification is invisible, requiring no cognitive load or deliberate action. This matters for accessibility (users with motor impairments) and for throughput (no waiting for the user to complete a challenge). The downside is that passive methods can be more susceptible to high-quality 3D attacks—silicone masks with realistic skin texture and embedded eye prosthetics can defeat texture analysis alone.

Active Liveness Detection

Active liveness requires the user to perform a specific action in response to a challenge. The system verifies both that the action occurred and that the biometric sample captured during the action matches the enrolled template.

• Blink detection: The simplest active challenge. The system prompts the user to blink and verifies that the eye region exhibits the characteristic temporal signature of a blink (closure and reopening over 200–400ms). Effective against printed photos but trivially defeated by video replay attacks.
• Head turn / pose estimation: The system prompts the user to turn their head to a random direction (left, right, up, down). A 3D face mesh is fitted to verify that the rotation is geometrically consistent with a real 3D head, not a 2D planar transformation of a photo. More resistant to video replay than blink detection because the attacker would need to anticipate the random direction.
• Challenge-response with randomized prompts: The system presents a random sequence of actions (e.g., “smile, then turn left, then look up”) and verifies the timing and order. The randomization defeats pre-recorded video attacks because the attacker cannot predict the sequence. However, real-time deepfake generators can potentially respond to challenges if they operate at sufficient frame rate.
• Speech-based liveness: The user reads a randomly generated phrase. The system verifies lip movement consistency with the audio, voice biometric match, and temporal alignment. Combines face and voice modalities. Effective but adds latency (2–5 seconds for the speech prompt) and fails in noisy environments or for users with speech impairments.

Active liveness provides stronger guarantees against sophisticated attacks at the cost of user friction. The challenge duration (typically 2–5 seconds) adds latency to the authentication flow, and the cognitive requirement creates accessibility barriers. In practice, most production systems use passive liveness as the primary path and fall back to active challenges only when the passive confidence score is below threshold.

The Deepfake Challenge

The threat model for liveness detection shifted fundamentally with the advent of real-time deepfake generators. Traditional liveness—both passive and active—assumes the camera is trustworthy: that the video frames arriving at the analysis pipeline originate from a physical sensor observing a physical scene. Injection attacks violate this assumption entirely.

In a camera injection attack, the attacker installs a virtual camera driver that intercepts the camera API at the operating system level. The biometric application believes it is receiving frames from a physical camera, but the frames are actually generated by a deepfake model running in real time. The deepfake model takes a source video of the attacker and maps it onto a target identity, producing photorealistic face-swapped frames at 30+ fps. Because the frames never pass through a physical camera, all optical-level detection (moiré patterns, specular reflection, screen pixel grid) is bypassed.

Modern injection attacks can also respond to active liveness challenges. If the deepfake model operates at sufficient frame rate, it can render the target identity performing blinks, head turns, and even speech—all driven by the attacker’s own movements in real time. This renders naive active liveness ineffective.

Defending against injection attacks requires moving detection upstream, to the sensor level:

• Secure camera attestation: The camera hardware cryptographically signs each frame with a device-bound key, proving it originated from a physical sensor. The verification server rejects frames that lack valid attestation. This is effective but requires hardware support (available on recent iOS and select Android devices).
• IR and depth sensor fusion: Structured light or time-of-flight depth sensors produce 3D point clouds that are physically impossible to spoof from a 2D injection. Even if the RGB stream is compromised, a genuine depth map from a hardware sensor provides an independent liveness signal.
• Frame-level forensics: Deepfake generators leave statistical fingerprints—GAN artifacts in the frequency domain, temporal inconsistencies in the face boundary region, and compression artifacts that differ from real camera ISP output. These forensic signals are subtle but detectable by specialized neural networks trained on large-scale deepfake corpora.

FHE-Encrypted Liveness Verification

Traditional liveness detection has a fundamental privacy problem: the verification server must see raw biometric frames to analyze them. This means that every liveness check creates a window where unencrypted facial images exist on a server—a high-value target for attackers and a compliance liability under GDPR, BIPA, and similar biometric privacy regulations.

H33 eliminates this window by performing liveness verification on encrypted data. The approach works because liveness signals—texture features, temporal motion vectors, depth map statistics, IR reflectance ratios—can be encoded as numerical feature vectors and embedded into the same BFV ciphertext that carries the biometric template for identity matching.

The pipeline operates as follows: On the client device, the SDK extracts both identity features (face embedding, 128 dimensions) and liveness features (texture scores, motion vectors, depth statistics—additional dimensions packed into the same SIMD slots) from the captured frames. These features are encrypted locally using the BFV scheme (N=4096 polynomial degree, single 56-bit modulus, plaintext modulus t=65537) before leaving the device. The raw frames are discarded on the client and never transmitted.

On the server, H33 performs the biometric comparison and liveness verification simultaneously via homomorphic inner product computation. The BFV SIMD slot packing batches 32 users into a single ciphertext (4096 slots ÷ 128 biometric dimensions), and each user’s slot region includes the liveness feature components alongside the identity features. The entire batch—identity matching plus liveness verification—executes in approximately 1,109µs for 32 users, yielding ~42µs per authentication. At sustained production load on Graviton4 hardware (192 vCPUs), this pipeline achieves 2.17M authentications per second.

The critical property is that the server never decrypts the biometric data or the liveness features. The homomorphic inner product produces an encrypted match score that encodes both “is this the claimed identity?” and “was this captured from a live person?” in a single computation. The result is decrypted only on the authority node holding the secret key, and only the binary match/no-match decision is returned. Raw feature vectors, individual liveness scores, and biometric templates remain encrypted throughout.

Multi-Signal Fusion in Encrypted Feature Vectors

Effective liveness detection requires fusing multiple independent signals. In H33’s architecture, this fusion happens before encryption—on the client device—so that the server operates on a single unified feature vector without knowing which dimensions represent identity and which represent liveness.

The signals fused into the encrypted feature vector include:

• Depth maps: If the device has a structured light or ToF sensor, the depth map is reduced to a compact statistical representation (mean depth, depth variance, face-to-background depth ratio, nose protrusion metric). These features are highly discriminative: a printed photo produces a flat depth profile, a screen replay produces depth consistent with the screen plane, and a silicone mask produces depth consistent with a rigid object lacking the fine-scale surface variation of real skin.
• IR reflectance: Near-infrared illumination (available on Face ID-equipped devices and many enterprise cameras) reveals subsurface scattering properties that differ between live skin, paper, silicone, and screens. The IR reflectance ratio is encoded as a single feature dimension—it is one of the most compact yet effective liveness signals available.
• Texture analysis scores: The CNN-based texture classifier on the client device produces a compact embedding (typically 8–16 dimensions) that captures the spatial frequency characteristics of the captured face. This embedding is appended to the identity feature vector before encryption.
• Temporal consistency: Motion vectors across the capture window (typically 500ms–1s of video) are reduced to summary statistics: microsaccade frequency, rPPG amplitude, lip micro-motion energy, head pose stability. These temporal features are encoded as additional dimensions in the feature vector.

BFV’s SIMD batching is key to making this efficient. The 4096 polynomial slots are partitioned across 32 users, giving each user 128 slots. Of these, a typical configuration allocates 96 slots to the face identity embedding and 32 slots to liveness features. The homomorphic inner product computes a weighted dot product across all 128 dimensions simultaneously—identity matching and liveness verification are fused into a single FHE operation with no additional ciphertext cost.

This design means that adding more liveness signals does not increase per-authentication latency, as long as the total feature dimensionality stays within the 128-slot budget per user. Architects can trade identity embedding resolution for liveness signal breadth depending on the threat model: a high-security deployment facing sophisticated 3D mask attacks might allocate 64 dimensions to identity and 64 to multi-modal liveness, while a consumer mobile deployment might use 112 identity dimensions and 16 liveness dimensions.

Accuracy Metrics and Standards Compliance

Liveness detection performance is measured by two complementary error rates defined in ISO 30107-3:

These two rates are in tension: lowering APCER (fewer successful attacks) tends to increase BPCER (more false rejections of genuine users). The operating point is chosen based on deployment context. Financial services and government identity programs typically operate at APCER < 0.1% even at the cost of higher BPCER, because the cost of a successful attack far exceeds the cost of asking a legitimate user to retry. Consumer applications tolerate higher APCER to minimize user friction.

ISO 30107-3 defines the testing methodology: PAI species (printed photos at various resolutions, screen replays at various sizes, 3D masks at various material qualities, partial face overlays) are enumerated, and APCER is reported per species. This per-species reporting is critical because a system might achieve <0.1% APCER against printed photos while failing at 15% APCER against high-quality silicone masks. Aggregate APCER alone is misleading.

In H33’s architecture, the liveness decision is part of the encrypted pipeline, so the match/no-match result inherits the post-quantum attestation chain. Every liveness verification result is signed with Dilithium (ML-DSA-65)—the same post-quantum signature scheme that attests to the identity match. This means the liveness result is non-repudiable and quantum-resistant: an attacker cannot forge a liveness attestation even with a quantum computer. The Dilithium signature is batched (one sign+verify per 32-user batch) to keep the attestation overhead at ~244µs per batch rather than per authentication.

Production Deployment Considerations

Deploying liveness detection at scale introduces engineering constraints that laboratory testing does not surface. The following considerations are drawn from production deployments of H33’s encrypted biometric pipeline.

Mobile SDK Requirements

The client-side SDK must access the camera at the hardware API level (AVCaptureSession on iOS, Camera2 on Android) rather than through high-level browser APIs (getUserMedia). Browser-based camera access is susceptible to virtual camera injection on desktop platforms and provides limited access to depth and IR sensors on mobile. The SDK performs feature extraction and encryption on-device, sending only the BFV ciphertext to the server. This requires approximately 50ms of client-side computation on modern mobile SoCs (A15+ on iOS, Snapdragon 8 Gen 2+ on Android) for feature extraction, encoding, and encryption.

Camera API and Sensor Access

Not all devices provide the full sensor suite. The SDK must degrade gracefully:

• Depth + IR + RGB (Face ID-class): Full multi-signal fusion. Highest security level. APCER < 0.05% against all PAI species including high-quality 3D masks.
• RGB + depth (Android structured light): Strong liveness. Depth provides robust rejection of 2D attacks. APCER < 0.2% against 2D PAIs, < 1% against basic 3D PAIs.
• RGB only (most devices): Passive texture + temporal analysis only. APCER < 0.5% against 2D PAIs, weaker against 3D attacks. Active liveness challenge recommended as fallback.

Network Latency Budget

H33’s server-side processing consumes ~42µs per authentication. In practice, the end-to-end latency is dominated by network round-trip time, not computation. A typical breakdown for a mobile deployment:

• Feature extraction + encryption (client): ~50ms
• Network round-trip: 20–150ms (depending on region and connectivity)
• Server processing: ~0.042ms
• Total: 70–200ms end-to-end

The server processing is negligible. Optimization effort should focus on reducing ciphertext payload size (currently ~32KB per authentication after SIMD batching) and ensuring edge deployment in regions close to the user population.

Graceful Degradation

When liveness confidence is ambiguous—the passive score falls in the gray zone between clear accept and clear reject—the system must not simply fail. Production deployments should implement a tiered response:

• High confidence (score > 0.95): Accept immediately. No user-facing friction.
• Medium confidence (0.70–0.95): Trigger a single active challenge (head turn or blink). The challenge result is combined with the passive score for a final decision.
• Low confidence (< 0.70): Reject with a user-friendly message (“Please ensure good lighting and try again”). Log the event for fraud analysis. After 3 consecutive rejections, escalate to a secondary authentication method.

This tiered approach keeps the false rejection rate low for genuine users (most will pass on the first attempt with high confidence) while maintaining strong attack resistance for borderline cases. The active challenge fallback adds 2–3 seconds of latency but applies to fewer than 5% of genuine authentication attempts in well-lit indoor environments.