Biometric Template Protection Without Storage

The biometric industry has spent two decades building increasingly sophisticated ways to protect stored biometric templates: cancelable biometrics, biometric salting, fuzzy commitment schemes, secure sketch constructions, and hardware enclaves. Every one of these approaches starts from the same premise -- that biometric templates must be stored on a server, and the engineering challenge is to protect them once stored. H33 starts from a different premise: what if the server never stores plaintext biometric templates at all?

This is not a semantic distinction. It is an architectural one. When a server stores biometric templates, even in protected form, the templates become a high-value target. The protection scheme becomes the attack surface. The key management for the protection scheme becomes an additional liability. The server operator becomes a data controller with regulatory obligations regarding biometric data. All of these consequences flow from one design choice: storing templates on the server.

H33's FHE biometric architecture eliminates this design choice entirely. Biometric templates are encrypted on the client device before transmission. They are stored on the server only in encrypted form. They are compared on the server in encrypted form. They are never decrypted on the server. The server never possesses plaintext biometric data, and therefore the entire category of attacks against stored templates is rendered irrelevant.

The Storage Problem

Every biometric database is a target. The U.S. Office of Personnel Management breach in 2015 exposed 5.6 million fingerprint records. The Biostar 2 breach in 2019 exposed 27.8 million biometric records including fingerprint and facial recognition data. The Suprema leak included biometric data from banks, police, and defense contractors. In each case, the biometric data was stored on servers, and the server security was compromised.

These breaches are particularly damaging because biometric data is irrevocable. A compromised fingerprint cannot be changed. A compromised facial template cannot be rotated. The damage is permanent, and the liability extends indefinitely. Under BIPA, the statutory damages alone for a breach of 5.6 million fingerprint records would be between $5.6 billion and $28 billion, depending on whether the violations are classified as negligent or intentional.

The industry's response has been to improve the protection of stored templates. But improving protection still accepts the fundamental risk: the templates exist in a recoverable form on the server, and the protection can potentially be defeated. Better protection raises the bar for attackers but does not eliminate the attack category.

Encrypted-Only Storage

H33's approach removes the attack category entirely. The server stores only BFV ciphertexts that contain biometric template data. These ciphertexts are encrypted under a key that the server does not possess. The server cannot decrypt the stored templates because it does not have the decryption key. Even if the entire database is exfiltrated, the attacker obtains only ciphertexts that are computationally indistinguishable from random noise.

The security of BFV encryption is based on the Ring Learning With Errors (RLWE) problem, which is believed to be hard even for quantum computers. This means that even an attacker with a future quantum computer cannot decrypt the stored biometric templates. The stored data is protected against both current and future computational capabilities.

The key management architecture uses a threshold decryption scheme. The decryption key is split among multiple parties using a secret sharing scheme. No single party possesses the complete key. Decryption requires a threshold number of parties to cooperate. This means that no single insider, no single compromised server, and no single legal subpoena can force decryption of stored biometric templates.

Comparison in the Encrypted Domain

Storage protection alone is insufficient if the templates must be decrypted for comparison. This is where FHE provides its critical capability. The BFV scheme supports homomorphic operations -- addition and multiplication -- on encrypted data. Biometric comparison can be expressed as a sequence of these operations.

The specific computation depends on the biometric modality and the comparison metric. For fingerprint minutiae, the comparison involves computing distances between minutiae points in the encrypted domain. For facial recognition, the comparison involves computing the cosine similarity or Euclidean distance between encrypted feature vectors. For iris recognition, the comparison involves computing the Hamming distance between encrypted iris codes.

In each case, the computation takes encrypted inputs, performs algebraic operations on the ciphertexts, and produces an encrypted result. The encrypted result is a ciphertext that, when decrypted, yields the comparison score. The server performs the computation without knowing the input templates or the output score.

The practical implementation uses the batched inner product as the core comparison operation. A biometric template vector of dimension d is encoded into a BFV plaintext polynomial. The enrollment template and authentication template are both encrypted as ciphertexts. The server computes the inner product by multiplying the ciphertexts element-wise and summing the results. The resulting ciphertext encrypts the inner product value, which is the similarity score.

What This Means for Compliance

The regulatory landscape for biometric data is tightening globally. BIPA in Illinois established the precedent of private right of action for biometric data mishandling, leading to billions of dollars in settlements and judgments. Texas enacted its own biometric privacy law. Washington state has biometric protections. The EU's GDPR treats biometric data as a special category requiring explicit consent and additional safeguards. China's Personal Information Protection Law has specific provisions for biometric data. India's Digital Personal Data Protection Act classifies biometrics as sensitive personal data.

For organizations subject to these regulations, the server-side absence of plaintext biometric data is a material compliance advantage. Under BIPA, the obligations apply to entities that "possess" biometric data. A server that stores only encrypted ciphertexts and never decrypts them has a strong argument that it does not "possess" biometric data in the regulatory sense, because the data is computationally inaccessible to the server operator.

Under GDPR, the principle of data protection by design (Article 25) requires that data protection is integrated into processing activities. FHE biometric matching is the most complete implementation of data protection by design possible for biometric authentication: the data protection is not an add-on or a control layered on top of processing; it is inherent in the processing itself.

For data controllers evaluating biometric vendors, the FHE approach reduces compliance risk in measurable ways. Data Protection Impact Assessments (DPIAs) for biometric processing under GDPR require evaluating the risks of data exposure. When the server never has access to plaintext biometric data, the risk assessment changes fundamentally. The residual risk of server-side biometric data exposure is zero, not low or mitigated, but zero.

The Enrollment Flow

The enrollment process in the H33 architecture differs from traditional biometric enrollment in one critical respect: encryption happens on the client device, before the biometric template leaves the user's control.

The user's device captures the biometric sample using the device's sensor (camera for facial recognition, fingerprint reader for fingerprint, etc.). The device's biometric SDK extracts the template vector from the raw sample. The raw biometric sample is discarded immediately after template extraction; it is never transmitted.

The template vector is encoded into a BFV plaintext representation. The encoding maps each element of the template vector to a coefficient of the plaintext polynomial, modulo the plaintext modulus t=65537. The encoded plaintext is then encrypted using the H33 public key, producing a BFV ciphertext.

The ciphertext is transmitted to the H33 enrollment service and stored. The service stores only the ciphertext. It never receives the plaintext template. It cannot derive the plaintext template from the ciphertext because it does not have the private key.

The entire enrollment flow ensures that plaintext biometric data exists only on the user's device, only for the duration of template extraction and encryption (typically a few milliseconds), and is zeroed from device memory immediately after encryption. No plaintext biometric data is ever transmitted over any network.

The Authentication Flow

Authentication follows a similar pattern. The user's device captures a new biometric sample, extracts a template, encodes and encrypts it. The encrypted authentication template is transmitted to the matching engine.

The matching engine retrieves the encrypted enrollment template from storage. It computes the inner product of the two encrypted templates using homomorphic multiplication and addition. The result is an encrypted similarity score.

The encrypted similarity score is sent to a threshold decryption service. This service coordinates with the threshold key holders to decrypt only the similarity score, not the templates. The decrypted score is compared against the authentication threshold. The threshold determination (match or no-match) is returned to the requesting application.

The threshold decryption architecture ensures that the score can be decrypted without any single party having access to the full decryption key. The key holders never see the biometric templates. They see only the similarity score, and only when threshold decryption is explicitly requested. This provides defense in depth: even the parties capable of decryption can only access the comparison result, not the underlying biometric data.

Performance Characteristics

The H33 FHE biometric engine processes biometric authentications at a sustained rate exceeding 1.6 million per second on Graviton4 hardware. The per-authentication latency of 42 microseconds includes the FHE computation, post-quantum attestation, and ZKP verification.

For comparison, traditional plaintext biometric matching systems typically achieve latencies of 10 to 100 milliseconds per comparison, depending on the template size and comparison algorithm. H33's FHE matching at 42 microseconds is faster than most plaintext systems, despite performing the computation on encrypted data.

This performance inversion -- encrypted computation being faster than many plaintext implementations -- is achieved through three techniques. First, the BFV batching scheme amortizes the FHE overhead across 32 users per ciphertext. Second, the inner product computation maps directly to BFV's native multiply-and-add operations without requiring relinearization or modulus switching in the critical path. Third, the Graviton4's 192 vCPUs enable massive parallelism across independent authentication requests.

The result is a system where the privacy guarantee (zero plaintext exposure) comes at no performance cost. Organizations do not need to choose between biometric privacy and authentication performance. They get both.

Migration from Traditional Biometric Systems

Organizations with existing biometric authentication systems can migrate to FHE-based matching without re-enrolling users. The migration process involves encrypting existing stored templates using the H33 public key and replacing the plaintext templates with the resulting ciphertexts. The existing templates are then securely erased from the legacy system.

This migration can be performed incrementally, with users migrated in batches. During the transition period, the system can support both legacy plaintext matching and FHE matching, with users transparently routed to the appropriate pipeline based on their migration status.

The re-encryption process is a one-time operation per user. Once a user's template is encrypted under the H33 public key and stored as a ciphertext, all subsequent authentications use the FHE matching pipeline. The user experience does not change: the same biometric sensor, the same capture process, the same authentication result. The change is entirely in the server-side processing, where plaintext templates are replaced by encrypted computations.

For organizations starting new biometric deployments, the H33 architecture is available as an API that integrates with standard biometric SDKs. The integration requires adding client-side encryption to the enrollment and authentication flows and replacing the server-side matching call with the H33 FHE matching API. The total integration effort is measured in days, not months.