Why Every Biometric Vendor Decrypts to Compare -- And Why That's a Problem

Every biometric authentication system in production today follows the same fundamental pattern: encrypt the biometric template for storage, decrypt it for comparison, then delete the plaintext from memory. Vendors describe this process using reassuring language about secure enclaves, hardware security modules, and memory protections. What they do not describe is the window -- however brief -- during which your biometric data exists as plaintext in server memory, vulnerable to side-channel attacks, memory scraping, cold boot attacks, and compromised privileged processes.

This window is the industry's open secret. It exists because the mathematical operations required for biometric comparison -- Euclidean distance, cosine similarity, correlation matching -- have traditionally required plaintext operands. You cannot compute the distance between two vectors if both vectors are encrypted. Or at least, you could not until fully homomorphic encryption made it possible.

The Standard Biometric Pipeline

To understand why decryption is the problem, you need to understand how biometric matching actually works. The pipeline has four stages in every major vendor's implementation.

Stage one: enrollment. The user provides a biometric sample -- a fingerprint scan, facial image, iris pattern, or voice recording. The biometric sensor captures the raw data, and a feature extraction algorithm converts it into a mathematical representation called a template. This template is typically a vector of 128 to 4,096 floating-point or integer values that encode the distinguishing features of the biometric. The template is encrypted and stored in a database.

Stage two: capture. When the user authenticates, a new biometric sample is captured and a new template is extracted. This template is encrypted for transmission to the matching server.

Stage three: comparison. This is where the problem lives. The matching server must compute a similarity score between the enrollment template and the authentication template. This computation requires both templates to be in plaintext. The server decrypts both templates, computes the distance or similarity metric, produces a numeric score, and then erases the plaintext templates from memory.

Stage four: decision. The similarity score is compared against a threshold. If the score exceeds the threshold, the authentication succeeds. If not, it fails.

Stage three is the vulnerability. No matter how secure stages one, two, and four are, the comparison stage requires plaintext biometric data in server memory. And once biometric data has been in plaintext memory, the security guarantee is fundamentally weakened.

Why Plaintext Exposure Matters More for Biometrics

When a password is compromised, you change it. When a private key is compromised, you revoke it and generate a new one. When a biometric template is compromised, you have no remediation path. You cannot change your fingerprints. You cannot change your iris patterns. You cannot change the geometry of your face. Biometric data is the only authentication factor that cannot be revoked or rotated.

This irrevocability means that biometric template exposure has permanent consequences. A database breach that exposes encrypted passwords is serious but recoverable. A database breach that exposes biometric templates is permanent. Every system that ever uses those biometric features for authentication is compromised in perpetuity.

The industry has responded to this reality with two mitigations: template protection schemes and secure hardware. Template protection schemes transform the biometric template using a key or transformation function, so that the stored template is not directly usable even if extracted. Secure hardware (TEEs, SGX enclaves, ARM TrustZone) isolates the decryption and comparison operations from the rest of the system.

Both mitigations reduce risk, but neither eliminates plaintext exposure. Template protection schemes still require the transformed template to be decrypted or untransformed for comparison. Secure enclaves still contain plaintext data, just in a different memory region. The attack surface is smaller, but it exists. Side-channel attacks against Intel SGX (Spectre, Meltdown, Foreshadow, Plundervault, and many others) have demonstrated that enclave isolation is not absolute. ARM TrustZone has had its own series of vulnerabilities. The hardware mitigation reduces the probability of exposure but does not eliminate the possibility.

The FHE Alternative: Comparison Without Decryption

Fully homomorphic encryption eliminates plaintext exposure entirely by performing the comparison in the encrypted domain. Both the enrollment template and the authentication template remain encrypted throughout the entire pipeline, including during the comparison stage. The server computes the similarity score on encrypted data without ever decrypting either template.

The mathematical basis is straightforward. Biometric comparison typically reduces to one of several distance or similarity metrics. Euclidean distance between two vectors can be decomposed into additions, subtractions, and multiplications. Cosine similarity involves dot products and normalizations. Inner products are a direct algebraic operation. All of these operations can be performed on BFV or CKKS ciphertexts.

In H33's implementation, the BFV scheme encodes biometric template vectors into ciphertexts with a plaintext modulus of t=65537. The enrollment template and the authentication template are encrypted under the same public key. The matching server computes the inner product of the two encrypted vectors, producing an encrypted similarity score. This encrypted score is returned to the key holder (or a designated threshold decryption authority) for decryption and thresholding.

At no point does the matching server have access to the plaintext template data. The server performs the computation, produces the result, but has no knowledge of either the input data or the output score. The entire comparison happens in the encrypted domain.

What the Server Sees

This distinction is not academic. It has concrete implications for what an attacker can extract from a compromised server.

In the traditional model, a compromised matching server provides the attacker with access to plaintext biometric templates during the comparison window. Even if this window is milliseconds, a memory scraping attack, a debugging interface, or a privileged process can capture the data. The attacker obtains biometric templates that can be used to impersonate users on any system that accepts those biometrics.

In the FHE model, a compromised matching server provides the attacker with encrypted ciphertexts and the ability to observe encrypted computations. The ciphertexts are indistinguishable from random noise without the private key. The computations on the ciphertexts do not reveal the underlying data. The attacker can observe the server performing computations but cannot determine what data is being compared or what the result is.

This is a categorical difference, not a quantitative one. It is not that FHE makes the attack harder. It makes the attack uninformative. There is nothing to extract from a server that never has the plaintext data.

Performance at Scale

The historical objection to FHE biometric matching has been performance. In the early days of FHE research, a single biometric comparison took minutes. This made FHE impractical for real-time authentication, which requires sub-second response times.

H33's BFV engine on Graviton4 hardware performs FHE biometric matching at a sustained rate of 1.6 million authentications per second, with a per-authentication latency of 42 microseconds. The FHE batch computation (32 users per ciphertext) takes 943 microseconds. The entire pipeline, including post-quantum attestation and ZKP verification, completes in 1,345 microseconds per batch.

These numbers are not only fast enough for real-time authentication; they are faster than many traditional biometric matching systems that operate on plaintext data. The performance objection is no longer valid.

The batch architecture is important for understanding the performance model. Instead of comparing one enrollment template against one authentication template, the system encodes 32 user templates into a single ciphertext using the BFV batching capability. The inner product computation is performed once on the batched ciphertext, producing 32 similarity scores in a single operation. This amortizes the FHE overhead across 32 users, reducing the per-user cost to a fraction of the single-operation latency.

The Privacy Regulatory Dimension

Biometric data is subject to some of the strictest privacy regulations in the world. The Illinois Biometric Information Privacy Act (BIPA) imposes statutory damages of $1,000 per negligent violation and $5,000 per intentional violation for improper collection, storage, or handling of biometric data. GDPR classifies biometric data as a special category of personal data subject to additional protections under Article 9. The California Consumer Privacy Act (CCPA) and the Texas Capture or Use of Biometric Identifier Act impose their own requirements.

A common thread in these regulations is the concept of data minimization: collect and process only the minimum data necessary for the purpose. The traditional biometric pipeline violates the spirit of data minimization by decrypting full biometric templates when only a similarity score is needed. The matching server does not need the template data. It needs the comparison result. FHE provides exactly the comparison result without providing the template data.

For organizations facing BIPA litigation, GDPR enforcement, or regulatory scrutiny of biometric data handling, FHE biometric matching offers a fundamentally stronger privacy posture. The server never possesses the biometric data. It cannot disclose what it does not have. The regulatory risk associated with server-side biometric data exposure is eliminated because the data exposure itself is eliminated.

Template Protection Without Compromise

Existing template protection schemes -- cancelable biometrics, biohashing, fuzzy vaults, secure sketches -- attempt to solve the same problem through mathematical transformations. They apply a keyed transformation to the template before storage, so that the stored representation is not directly usable without the key.

These schemes have known limitations. Cancelable biometrics can be subjected to linkage attacks if the transformation parameters are compromised. Biohashing requires managing an additional secret (the hash key) alongside the biometric. Fuzzy vaults have information leakage properties that reduce the effective entropy of the biometric. Most critically, all of these schemes still require the original or transformed template to be in plaintext during comparison.

FHE eliminates these compromise. There is no transformation key to manage. There is no information leakage during comparison. There is no plaintext template at any point in the matching process. The biometric data is encrypted at the point of capture and never decrypted on the matching server.

The H33 Biometric Architecture

H33's biometric authentication system uses the BFV homomorphic encryption scheme with a three-stage verification pipeline.

Enrollment: The user's biometric template is captured on the client device, encoded as an integer vector with values modulo t=65537, and encrypted using the H33 public key. The encrypted template is transmitted to the H33 infrastructure and stored. The plaintext template is zeroed from client memory immediately after encryption. No plaintext template is ever transmitted or stored on any server.

Authentication: A new biometric sample is captured on the client device, encoded and encrypted identically to the enrollment template, and transmitted to the matching engine. The matching engine computes the inner product of the encrypted authentication template and the encrypted enrollment template, producing an encrypted similarity score.

Attestation: The encrypted similarity score is bound to a post-quantum attestation that records the computation timestamp, the scheme parameters, and the verification result. The attestation is signed with three independent PQ signature schemes and distilled to 74 bytes using the H33-74 primitive. The 74-byte attestation provides proof that the biometric comparison was performed correctly on the encrypted data, without revealing the biometric data or the match score.

The result is a biometric authentication system where no server ever possesses plaintext biometric data, and every authentication produces an independently verifiable proof that the computation was performed correctly.

What Needs to Change

The biometric industry needs to abandon the assumption that decryption is a necessary step in comparison. This assumption was valid when FHE was too slow for real-time use. It is no longer valid. The technology to perform biometric comparison in the encrypted domain exists, runs at scale, and is available as a production API.

Vendors who continue to decrypt biometric templates for comparison are making a choice, not facing a limitation. They are choosing to expose biometric data in plaintext because their existing architectures were built around plaintext comparison, and migration requires engineering investment. This choice creates risk for their customers and regulatory exposure for their organizations.

For enterprises evaluating biometric vendors, the question to ask is straightforward: does your matching engine ever have access to plaintext biometric templates? If the answer is yes -- even if it is qualified with "only briefly" or "only in a secure enclave" -- the system has a plaintext exposure window. The only correct answer is "no, comparison is performed entirely in the encrypted domain." That answer is now achievable.