Mobile Biometric Authentication:
Security Considerations for Apps

The Problem With Plaintext Biometrics

Every mobile device shipped in 2025 contains at least one biometric sensor. Face ID, Touch ID, ultrasonic fingerprint readers, and iris scanners have replaced PINs and passwords as the default unlock mechanism for billions of users. Yet the security model behind most mobile biometric implementations is dangerously shallow: the raw biometric template — a 128-dimensional floating-point vector representing your face, fingerprint, or voice — is matched in plaintext on the device or, worse, transmitted to a server for comparison.

This is a structural vulnerability. A password, once compromised, can be rotated. A biometric template cannot. Your fingerprint is the same today as it will be in thirty years. If an attacker extracts a plaintext template from device memory, a compromised TEE, or an intercepted API call, that biometric credential is permanently burned. No reset flow exists.

Platform APIs: Necessary but Insufficient

The first rule of mobile biometric security is straightforward: never implement your own capture and matching pipeline. iOS LocalAuthentication and Android BiometricPrompt provide hardware-backed, tested implementations that leverage the Secure Enclave (Apple) or StrongBox/TEE (Android) to isolate biometric processing from the application sandbox. These APIs handle sensor access, anti-spoofing heuristics, and local match-on-device logic without exposing raw template data to the calling application.

However, platform APIs only solve the local unlock problem. They confirm that the person holding the device matches the enrolled biometric — but they say nothing about server-side identity. When your backend needs to verify a user across devices, enforce step-up authentication for high-value transactions, or maintain a centralized audit trail, the platform API model breaks down. You are left with two choices: trust a boolean flag from the client (trivially spoofable) or transmit biometric data to the server (a template-exposure catastrophe).

What platform APIs protect

• Sensor access — Only the OS biometric stack touches the hardware
• Local matching — Templates never leave the Secure Enclave / TEE
• Anti-replay — Nonce-bound attestation tokens prevent reuse
• Liveness detection — Depth maps, IR projection, and randomized challenges defeat static spoofs

What they do not protect

• Cross-device identity — A user on a new phone has no enrolled template on-server
• Server-side verification — The backend receives a pass/fail flag, not a cryptographic proof
• Template confidentiality at rest — If your architecture stores templates for re-enrollment, they exist in plaintext somewhere

Encrypted Biometric Matching With FHE

Fully Homomorphic Encryption (FHE) eliminates the tradeoff between server-side verification and template confidentiality. Under BFV-based FHE, the biometric template is encrypted on the client before it ever leaves the device. The server performs the inner-product similarity computation directly on the ciphertext — without decrypting it at any point. The match result is returned encrypted, and only the client (holding the secret key) can read the outcome.

This is not a theoretical construction. H33's production pipeline performs encrypted biometric verification at 2,172,518 authentications per second on a single Graviton4 instance, with an end-to-end latency of approximately 42 microseconds per authentication. The system packs 32 users into a single BFV ciphertext using SIMD batching — 4,096 polynomial slots divided into 128-dimensional vectors — and computes all 32 similarity scores in a single FHE inner product operation taking roughly 1,109 microseconds per batch.

The Full Post-Quantum Authentication Stack

FHE alone protects template confidentiality, but a production biometric system also needs proof integrity and quantum resistance. H33 chains three cryptographic layers into a single API call:

The ZKP layer provides a succinct proof that the encrypted match score crosses the acceptance threshold, without revealing the score itself. The Dilithium signature (NIST ML-DSA, FIPS 204) binds the proof to a specific session, timestamp, and device — ensuring the attestation cannot be replayed, reordered, or forged, even by an adversary with a quantum computer.

Liveness Detection and Anti-Spoofing

Encrypted matching is meaningless if the biometric sample itself is spoofed. Presentation attacks — printed photos, silicone fingerprints, deepfake video — target the sensor layer before encryption ever occurs. Effective liveness detection requires a layered approach:

• Hardware-level challenges — Structured light (Face ID dot projector), ultrasonic pulse-echo (Qualcomm 3D Sonic), IR reflectance patterns that differ between living tissue and printed media
• Randomized motion prompts — Server-issued challenges (blink, turn head, speak a phrase) that are unpredictable and time-bound, defeating pre-recorded attacks
• Depth consistency checks — 3D mesh validation that rejects flat surfaces, even those printed on curved substrates
• Passive liveness signals — Subtle physiological indicators (micro-saccades, blood perfusion, sub-dermal texture) captured without explicit user interaction

The critical design constraint is that liveness signals must be evaluated before the biometric template is extracted and encrypted. A failed liveness check should abort the authentication flow entirely, with no template data ever leaving the sensor pipeline.

Implementation Checklist

For teams building mobile biometric authentication, these are the non-negotiable security properties that must hold across every code path:

• Use platform APIs exclusively — iOS LocalAuthentication / Android BiometricPrompt for local unlock; never roll your own capture stack
• Require Class 3 (Strong) biometrics — Reject Class 1/2 on Android; these lack hardware-backed anti-spoofing
• Encrypt templates before transmission — FHE if server-side matching is needed; at minimum, hybrid Kyber+AES-256-GCM for transport
• Bind attestations to sessions — Every biometric result must include a server-issued nonce, a timestamp, and a post-quantum signature
• Never store plaintext templates — Not on the device filesystem, not in a database, not in logs, not in crash reports
• Handle failures gracefully — After N failed attempts, fall back to a secondary factor (SMS OTP, hardware key) without leaking why the biometric failed
• Plan for quantum adversaries — Templates harvested today can be brute-forced tomorrow; use post-quantum encryption (lattice-based FHE, Dilithium signatures) now

The goal is not to make biometric authentication convenient — device vendors have already solved that. The goal is to make it cryptographically irreversible: even a total server compromise reveals zero biometric information about any enrolled user.

Why This Matters Now

The convergence of three trends makes post-quantum biometric security an urgent priority. First, mobile biometrics are no longer optional — they are the default authentication mechanism for banking, healthcare, and government applications. Second, harvest-now-decrypt-later attacks mean that biometric data encrypted with classical schemes today is already at risk from future quantum computers. Third, regulatory frameworks (GDPR Article 9, BIPA, India's DPDP Act) are tightening around biometric data processing, with penalties that scale to revenue.

H33's approach — FHE for template confidentiality, ZKP for proof integrity, and Dilithium for post-quantum attestation — addresses all three concerns in a single API call at 42 microseconds per authentication. The biometric data never exists in plaintext outside the client device. The server proves correctness without seeing the data. And every signature is quantum-resistant from day one.