BIPA Compliance with FHE Biometrics:
How H33 Satisfies 740 ILCS 14

What is BIPA?

The Biometric Information Privacy Act (740 ILCS 14), enacted in 2008 by the Illinois General Assembly, is the most aggressive biometric privacy statute in the United States. Unlike GDPR's biometric provisions or the Texas CUBI statute, BIPA grants a private right of action — any individual can sue, not just the attorney general. This single feature has made BIPA the source of more biometric litigation than every other US privacy law combined.

BIPA defines "biometric identifier" to include retina or iris scans, fingerprints, voiceprints, and scans of hand or face geometry. It defines "biometric information" as any information derived from biometric identifiers used to identify an individual. The statute's five operative sections — 15(a) through 15(e) — establish a comprehensive framework for how private entities must handle biometric data. Every company processing biometric data for Illinois residents must comply.

The Five Pillars of BIPA Section 15

The following sections analyze how H33's FHE biometric architecture addresses each of these requirements — not with policy language, but with cryptographic guarantees.

Traditional Biometric Storage vs. H33 FHE

Before examining each BIPA section, it is worth understanding the fundamental architectural difference between traditional biometric systems and H33's FHE approach. The table below makes the contrast explicit.

Architecture: Data Flow Diagram

The following diagram shows the complete data flow from client-side biometric capture through H33's FHE pipeline. The critical observation is that plaintext biometric data never crosses the client-server boundary.

Section 15(a) — Retention & Destruction Policy

BIPA Section 15(a) requires that any entity possessing biometric data must develop a written policy, made available to the public, establishing a retention schedule and guidelines for permanently destroying biometric identifiers and biometric information. The data must be destroyed when the initial purpose for collecting it has been satisfied or within three years of the individual's last interaction with the entity, whichever occurs first.

In a traditional biometric system, "destruction" means deleting plaintext templates from a database — a process fraught with complications. Backups, replicas, log files, and cache layers can all retain copies of the biometric data long after the primary record is deleted. Proving that destruction was complete and irreversible is often impossible.

The FHE ciphertext lifecycle is well-defined: enrollment creates the ciphertext, verification operates on the ciphertext homomorphically, and unenroll() destroys it. This maps directly onto BIPA's requirement for a retention schedule with defined destruction criteria. The lifecycle is enforced by the cryptosystem, not by an administrator remembering to purge records.

Section 15(b) — Informed Written Consent

Section 15(b) is the most litigated provision of BIPA. It requires that before collecting any biometric identifier or biometric information, the entity must: (1) inform the subject in writing that a biometric identifier or biometric information is being collected or stored; (2) inform the subject in writing of the specific purpose and length of term for which the data is being collected, stored, and used; and (3) receive a written release executed by the subject.

This is fundamentally a customer-facing obligation — the entity that interacts with the end user must obtain consent. H33 operates as a backend biometric authentication infrastructure provider. H33's architecture, however, is specifically designed to make the customer's compliance burden as light as possible.

Section 15(c) — No Profiting from Biometric Data

Section 15(c) is blunt: "No private entity in possession of a biometric identifier or biometric information may sell, lease, trade, or otherwise profit from a person's or a customer's biometric identifier or biometric information."

This provision was designed to prevent the commoditization of biometric databases — the scenario where a company collects fingerprints for employee timekeeping and then sells that database to a data broker or advertising network. With traditional biometric systems, the prohibition is enforced only by policy and the threat of litigation. The technical capability to extract and sell the data exists; only the legal prohibition prevents it.

H33's FHE architecture converts this policy control into a mathematical impossibility. The enrolled biometric templates are BFV ciphertexts encrypted under a threshold public key. The threshold decryption protocol requires k-of-n authorities to collaborate in order to decrypt any ciphertext. No single party — including H33 itself — possesses the complete decryption key.

This means H33 cannot extract the plaintext biometric embedding from the stored ciphertext, even under compulsion. The encrypted embeddings have zero commercial value to any party that does not control the threshold key quorum. Selling the ciphertext database would be selling noise — computationally indistinguishable from random data without the threshold key shares.

The prohibition in 15(c) is satisfied not because H33 chooses not to profit from biometric data, but because the architecture makes profiting from it computationally infeasible.

Section 15(d) — No Unauthorized Disclosure

Section 15(d) prohibits any private entity from disclosing, redisclosing, or otherwise disseminating a person's biometric identifier or biometric information unless: the subject consents, the disclosure completes a financial transaction requested by the subject, the disclosure is required by state or federal law, or the disclosure is required pursuant to a valid warrant or subpoena.

In H33's architecture, the biometric never leaves the encrypted domain. The entire authentication flow — enrollment, storage, comparison, and decision — operates on ciphertexts. The only output of the verification pipeline is a boolean match/no-match score, revealed through threshold decryption of a single comparison result. The actual biometric embedding is never decrypted at any point in the pipeline.

Even under a valid subpoena or warrant, H33 could only produce the BFV ciphertext — which is computationally indistinguishable from random noise without the threshold key shares held by the distributed authority quorum. This is not obstruction; it is the mathematical reality of the cryptosystem. The data simply does not exist in a form that can be "disclosed" in the statutory sense.

Section 15(e) — Reasonable Standard of Care

Section 15(e) requires that biometric data be stored, transmitted, and protected "using the reasonable standard of care within the [entity's] industry" and "in a manner that is the same as or more protective than the manner in which the entity stores, transmits, and protects other confidential and sensitive information." This is the security obligation.

The phrase "reasonable standard of care" is deliberately vague — it is a negligence standard that evolves with industry practice. Courts will look to what similarly situated entities do. For biometric data in 2026, the baseline expectation includes encryption at rest, encryption in transit, access controls, and audit logging.

H33's security posture does not merely meet the reasonable standard of care. It categorically exceeds it by deploying a defense-in-depth stack that no other biometric authentication provider currently offers:

The industry standard for biometric data protection in 2026 is AES-256 encryption at rest with TLS 1.3 in transit. H33 provides all of that plus fully homomorphic encryption (the data is never decrypted, even during computation), post-quantum transport encryption (resistant to future quantum attacks on key exchange), post-quantum attestation signatures (tamper-evident auth results), and threshold key management (no single point of compromise). This is not a marginal improvement over the standard of care — it is a fundamentally different security model.

BIPA Compliance Checklist

The following table maps each operative section of BIPA to H33's specific compliance mechanism and current status.

Enrollment & Verification API Flow

The following code blocks show the complete BIPA-compliant biometric lifecycle: enrollment, verification, and destruction. At no point does a plaintext biometric cross H33's API boundary.

Step 1: Client-Side Embedding Extraction & Encryption

import h33
from arcface import ArcFaceModel

# Step 1a: Extract embedding CLIENT-SIDE (raw image never sent to H33)
model = ArcFaceModel.load("arcface-r100")
embedding = model.extract(face_image)   # 128-dim float vector

# Step 1b: Encrypt embedding with H33's FHE public key
client = h33.Client(api_key="h33_pk_...")
encrypted = client.encrypt_embedding(embedding)

# The raw face_image and plaintext embedding STAY on the client.
# Only the BFV ciphertext (~32KB) is transmitted to H33.

Step 2: Enrollment (Ciphertext Stored on H33)

curl -X POST https://api.h33.ai/v1/biometric/enroll \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "user_id": "usr_8xKm2...",
    "encrypted_embedding": "base64_bfv_ciphertext...",
    "consent_timestamp": "2026-02-23T14:30:00Z",
    "retention_days": 1095
  }'

// Response
{
  "enrolled": true,
  "user_id": "usr_8xKm2...",
  "slot": 14,                  // SIMD batch slot (0-31)
  "ciphertext_id": "ct_3fRn...",
  "retention_expires": "2029-02-23T14:30:00Z",
  "attestation": "dilithium_sig..."
}

Step 3: Verification (Homomorphic Comparison)

curl -X POST https://api.h33.ai/v1/biometric/verify \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "user_id": "usr_8xKm2...",
    "encrypted_probe": "base64_bfv_ciphertext..."
  }'

// Response — boolean only, no biometric data returned
{
  "match": true,
  "score_encrypted": true,    // comparison done on ciphertexts
  "threshold_met": true,
  "latency_us": 48,
  "attestation": "dilithium_sig...",
  "zkp_proof": "stark_lookup_proof..."
}

Step 4: Destruction (BIPA 15(a) Compliant Unenroll)

curl -X DELETE https://api.h33.ai/v1/biometric/unenroll \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "user_id": "usr_8xKm2...",
    "reason": "user_request"
  }'

// Response — cryptographic destruction confirmation
{
  "unenrolled": true,
  "user_id": "usr_8xKm2...",
  "ciphertext_destroyed": true,
  "slot_zeroed": true,
  "destruction_timestamp": "2026-02-23T15:00:00Z",
  "attestation": "dilithium_sig...",   // signed proof of destruction
  "recoverable": false
}

The Verdict