Incremental Auth: Delta Updates for Biometric Templates

Biometric templates are not static. Faces age. Fingerprints change with wear and environmental exposure. Iris patterns can shift due to medical conditions or aging. A biometric system that captures a template once and uses it forever will experience degrading accuracy over time as the enrolled template diverges from the user's current biometric presentation. Traditional systems handle this through periodic re-enrollment: the user visits an enrollment station, provides fresh biometric samples, and the template is replaced.

Re-enrollment is operationally expensive. It requires user cooperation, physical presence at an enrollment station, administrative oversight, and system downtime for the template replacement. For large-scale deployments (enterprise workforce, national ID systems, banking customers), re-enrollment campaigns are logistically complex and costly. Users who cannot or will not re-enroll experience degrading authentication accuracy, leading to increased false rejections and eventually system abandonment.

Incremental authentication solves this by updating the enrolled template automatically during normal authentication events. Each successful authentication provides a fresh biometric sample that can be used to refine the stored template, keeping it current with the user's natural biometric evolution. The challenge in an FHE-based system is performing this update without ever decrypting the template.

The Delta Update Mechanism

The core idea is simple: instead of replacing the entire template, compute the difference (delta) between the current stored template and the fresh sample, then apply a weighted update to shift the stored template toward the fresh sample. In plaintext, this is straightforward vector arithmetic. In the encrypted domain, it requires homomorphic addition and scalar multiplication on BFV ciphertexts.

The update formula is: new_template = (1 - alpha) * old_template + alpha * fresh_sample, where alpha is the learning rate (typically between 0.05 and 0.15). This weighted average moves the template toward the fresh sample by a small amount, smoothing out noise from any single capture while gradually adapting to genuine biometric changes.

In the FHE domain, both old_template and fresh_sample are encrypted. The scalar multiplications ((1 - alpha) and alpha) are plaintext-ciphertext multiplications, which BFV supports natively. The addition is a ciphertext-ciphertext addition, also native to BFV. The entire update is performed homomorphically without decrypting either the stored template or the fresh sample.

Noise Budget Management

Every homomorphic operation consumes noise budget. The delta update involves two plaintext-ciphertext multiplications and one ciphertext-ciphertext addition. Plaintext-ciphertext multiplication consumes more noise budget than addition but less than ciphertext-ciphertext multiplication. The total noise consumption per update is modest, but it accumulates over many updates.

After a configurable number of incremental updates (typically 50 to 100), the noise budget approaches exhaustion. At this point, H33 triggers a refresh operation. The user's client device requests the current encrypted template, decrypts it locally (the client holds the private key), re-encrypts it with fresh noise budget, and uploads the refreshed ciphertext. This refresh looks like a normal authentication event to the server; only the client knows a refresh occurred.

Quality Control

Not every authentication sample should update the template. A sample captured in poor lighting, at an extreme angle, or with a partially obscured face should not influence the enrolled template. H33 applies quality control before triggering an update.

The match score from the authentication provides the primary quality signal. Only samples that match with scores significantly above the acceptance threshold are used for template updates. This ensures that the updating samples are high-quality representations of the genuine user, not borderline matches that might introduce noise into the template.

The learning rate alpha is adaptive: higher confidence matches get higher alpha (the template moves more toward high-quality samples) and lower confidence matches get lower alpha or are excluded entirely. This prevents template drift from accumulated low-quality updates while ensuring that genuine biometric changes (aging, weight change, hairstyle) are incorporated efficiently.

Preventing Template Drift

The primary risk of incremental updates is template drift: the gradual shift of the template away from the original enrollment, potentially toward an impostor's biometric if the system is under attack. H33 mitigates this through several mechanisms.

First, the learning rate is bounded. Alpha never exceeds 0.15, meaning no single update can shift the template more than 15% toward the fresh sample. An attacker would need many successful authentications (which require matching the current template) to significantly shift the template.

Second, the update history is tracked through H33-74 attestations. Each update event is attested, creating a cryptographic audit trail. If drift is detected, the attestation chain can be walked backward to identify when the drift began and whether it correlates with suspicious authentication patterns.

Third, the original enrollment template is preserved (encrypted) alongside the incrementally updated template. Periodic comparison between the current template and the original detects excessive drift. If the templates diverge beyond a configurable threshold, the system flags the account for manual review and reverts to the original template.

Post-Quantum Security

All incremental update operations are performed in the BFV FHE domain, providing inherent post-quantum security through lattice-based hardness assumptions. The delta computations, the weighted averaging, and the noise budget refreshes all operate on encrypted data protected by RLWE. Each update event is attested with H33-74 three-family signatures, providing quantum-resistant proof of the template lifecycle.

Incremental auth is not just a convenience feature. It is an operational necessity for any biometric system deployed at scale. By performing updates in the encrypted domain, H33 maintains template freshness without creating the plaintext exposure windows that traditional re-enrollment requires.

Implementation Details

The incremental update is triggered only after a successful authentication that meets quality thresholds. The fresh sample must match the stored template with a score significantly above the acceptance threshold (typically the 80th percentile of genuine match scores or higher). This ensures that only high-quality, high-confidence samples influence the template, preventing drift from borderline or low-quality captures.

The update computation in the FHE domain proceeds as follows. The server holds the encrypted stored template T_enc and the encrypted fresh sample S_enc. The server computes: T_new_enc = scalar_mult((1 - alpha), T_enc) + scalar_mult(alpha, S_enc). Both scalar_mult operations are plaintext-ciphertext multiplications, and the addition is a ciphertext-ciphertext addition. All three operations are native BFV operations that consume minimal noise budget.

The updated template T_new_enc replaces T_enc in the server's storage. An H33-74 attestation is generated for the update event, recording the timestamp, the update number (how many incremental updates have been applied since the last full enrollment or refresh), and a hash commitment to the update parameters. This attestation chain provides a complete, cryptographically verifiable history of the template's evolution.

Comparison with Traditional Approaches

Traditional biometric systems handle template aging through three approaches, all of which have significant drawbacks compared to FHE incremental updates.

Periodic re-enrollment: Users are required to re-enroll at regular intervals (annually, biannually). This is operationally expensive, requires user cooperation, and creates a plaintext exposure event at each re-enrollment. Many users skip or delay re-enrollment, leading to degrading accuracy for the most negligent users, who are often the ones who need the most assistance.

Plaintext template adaptation: Some systems perform template updates in plaintext, decrypting the stored template, computing the weighted update, and re-encrypting the result. This creates a plaintext exposure window for every update event, multiplying the attack surface by the number of successful authentications (since each one triggers a potential update).

Multiple enrollment templates: Some systems store multiple templates per user (enrolled at different times) and match against all of them. This increases storage requirements linearly with the number of templates and increases matching time proportionally. It does not address template aging directly; it mitigates it by increasing the probability that at least one stored template is close enough to the current presentation to produce a match.

H33's FHE incremental update avoids all of these drawbacks. Updates happen automatically during normal authentication (no user cooperation needed). The template never exists in plaintext during the update (no exposure window). Only one template is maintained (constant storage and matching time). And the update is mathematically precise (exact weighted average, not heuristic approximation).

Deployment Considerations

When deploying incremental auth, several configuration parameters affect the behavior and security properties of the system. The learning rate alpha determines how quickly the template adapts. Higher alpha means faster adaptation to genuine biometric changes but also faster potential drift under attack. Lower alpha means slower adaptation but greater resistance to manipulation. The recommended range is 0.05 to 0.15, with the specific value tuned based on the expected rate of biometric change in the user population (younger populations change more rapidly; elderly populations are more stable).

The quality threshold for update eligibility should be set higher than the authentication acceptance threshold. A common configuration is to require match scores in the top 20% of the genuine score distribution for update eligibility. This ensures that only the highest-quality samples influence the template while still allowing a reasonable proportion of authentications to trigger updates.

The noise budget refresh interval should be set based on the expected authentication frequency. For a user who authenticates 10 times per day, a refresh every 50 updates means a refresh every 5 days. The refresh is transparent to the user (it happens during a normal authentication) and adds minimal latency (the re-encryption is performed on the client device).

Security Analysis of Incremental Updates

The security of incremental authentication rests on several properties that must be maintained throughout the update lifecycle. First, the template must remain within the user's biometric subspace. The weighted averaging mechanism with bounded learning rate ensures that each update moves the template by at most alpha times the distance between the current template and the new sample. An attacker attempting to shift the template toward their own biometric would need to successfully authenticate many times (each requiring a match against the current template), and the bounded learning rate limits how far the template can move per authentication event.

Second, the noise budget must be managed to prevent correctness failures. Each incremental update consumes a small amount of BFV noise budget. The refresh mechanism (client-side decrypt and re-encrypt) replenishes the budget before exhaustion. The refresh interval is conservative: the noise consumed per update is tracked precisely, and the refresh is triggered with substantial budget remaining rather than waiting for near-exhaustion. This provides a safety margin that accounts for variability in noise consumption across different template values.

Third, the attestation chain must be tamper-evident. Each update event is attested with H33-74, creating a hash-chained record of the template's evolution. Any attempt to tamper with the template history (inserting fraudulent updates, removing legitimate updates, or modifying update parameters) would break the hash chain and be detected during verification. The attestation chain also enables forensic analysis if template drift is detected: investigators can walk the chain to identify exactly when and how the drift occurred.

These security properties combine to make incremental authentication safe for production deployment. The bounded learning rate prevents rapid drift. The quality threshold prevents low-quality updates. The noise budget management prevents correctness failures. The attestation chain provides tamper evidence. And the original template preservation provides a recovery mechanism for the rare cases where drift exceeds acceptable bounds despite these safeguards.