CCPA/CPRA Biometric Compliance:
Encrypted by Default, Deletable by API

§1798.140(b) — Biometric Information Definition

The CCPA defines "biometric information" broadly: an individual's physiological, biological, or behavioral characteristics that can be used, singly or in combination, to establish individual identity. This includes face, fingerprint, iris, voice, palm, and vein patterns, as well as identifier templates such as faceprints and minutiae templates.

Do BFV Ciphertexts Constitute "Biometric Information"?

This is the central question for any FHE-based biometric processor. H33 stores BFV-encrypted embeddings — 128-dimensional feature vectors encrypted under the BFV scheme (N=4096, single 56-bit modulus Q, t=65537). The raw biometric image never leaves the client device. The feature vector is extracted on-device, encrypted on-device, and only the ciphertext is transmitted to H33's servers.

Under a strict reading of 1798.140(b), the ciphertext alone cannot "establish individual identity." BFV ciphertexts are semantically secure under the Ring Learning With Errors (RLWE) hardness assumption — they are computationally indistinguishable from uniformly random polynomials without the decryption key. H33 operates under a threshold decryption model where no single party holds the complete secret key. The ciphertext is therefore not merely "pseudonymized" — it is encrypted under a scheme with provable IND-CPA security.

The practical consequence of this conservative position: H33 and its customers apply all CCPA/CPRA biometric protections to the stored ciphertexts, even though the mathematical argument for exemption is strong. This provides defense-in-depth — if a regulator treats ciphertexts as biometric information, every requirement is already satisfied. If they do not, the protections represent excess compliance rather than a gap.

§1798.105 — Right to Deletion

Section 1798.105 grants consumers the right to request deletion of personal information collected by a business. The business must comply and must direct its service providers and contractors to delete the consumer's data. For biometric information used solely for authentication, the statutory exceptions (completing a transaction, legal compliance, security incident detection) rarely apply.

Cryptographic Deletion via unenroll()

H33 provides a single-call unenroll() API that permanently and irrevocably destroys the enrolled biometric ciphertext. Because H33 never stores the plaintext biometric, deletion of the ciphertext is absolute — there is no residual data from which the biometric could be reconstructed. The operation returns a Dilithium-signed deletion receipt — a post-quantum verifiable proof that the deletion occurred at a specific timestamp.

# Delete a consumer's biometric enrollment
# Returns a Dilithium-signed deletion receipt for audit/compliance

curl -X DELETE https://api.h33.ai/v1/biometric/unenroll \
  -H "Authorization: Bearer $H33_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "enrollment_id": "usr_8xKm3nPq...",
    "reason": "ccpa_deletion_request",
    "requestor": "consumer_direct",
    "require_receipt": true
  }'

// Response — cryptographic deletion receipt
{
  "deleted": true,
  "enrollment_id": "usr_8xKm3nPq...",
  "ciphertext_destroyed": true,
  "plaintext_existed": false,
  "deletion_timestamp": "2026-02-23T14:32:07.481Z",
  "backup_purged": true,
  "irrevocable": true,
  "receipt": {
    "digest": "sha3_256:a4f9c1e8...",
    "signature": "dilithium5:base64...",
    "algorithm": "ML-DSA-87 (FIPS 204)",
    "signer_pk": "base64...",
    "verifiable": true
  }
}

Dilithium-Signed Deletion Receipt

The deletion receipt is not a database record — it is a cryptographic attestation. H33 computes a SHA3-256 digest of the deletion event (enrollment ID, timestamp, reason, operator) and signs it with a Dilithium-5 key (ML-DSA-87, FIPS 204). The receipt can be independently verified by any party holding the signer's public key, providing non-repudiable proof of deletion for regulatory audits, litigation holds, and compliance documentation.

use zeroize::Zeroize;

impl CollectiveAuthority {
    /// CCPA 1798.105 — Right to Deletion.
    /// Destroys BFV ciphertext, zeroizes memory, returns
    /// a Dilithium-signed receipt for compliance audit.
    pub fn unenroll(
        &mut self,
        enrollment_id: &EnrollmentId,
    ) -> Result<DeletionReceipt, UnenrollError> {
        // 1. Remove ciphertext from storage
        let mut ct = self.templates
            .remove(enrollment_id)
            .ok_or(UnenrollError::NotFound)?;

        // 2. Zeroize ciphertext memory before deallocation
        for poly in ct.polys.iter_mut() {
            poly.zeroize();
        }

        // 3. Remove from batch slots if SIMD-enrolled
        self.batch_index.remove(enrollment_id);

        // 4. Build deletion event and compute SHA3-256 digest
        let event = DeletionEvent {
            enrollment_id: enrollment_id.clone(),
            timestamp: Utc::now(),
            ciphertext_destroyed: true,
            plaintext_existed: false,
        };
        let digest = sha3_256(&event.to_canonical_bytes());

        // 5. Sign digest with Dilithium-5 (ML-DSA-87)
        let signature = self.attestation_key
            .sign_dilithium(&digest);

        // 6. Return verifiable deletion receipt
        Ok(DeletionReceipt {
            event,
            digest,
            signature,
            algorithm: "ML-DSA-87".into(),
        })
    }
}

§1798.100 — Right to Know

Consumers have the right to request that a business disclose the categories and specific pieces of personal information it has collected. Under CPRA, this extends to sensitive personal information including biometrics. Businesses must respond within 45 days (extendable to 90 with notice).

What H33 Stores vs. What It Does Not

The Right to Know response for H33-processed biometric data is unique: there is no "biometric information" to disclose in plaintext form. The server stores only BFV ciphertexts — encrypted polynomial coefficients that are computationally indistinguishable from random data without the decryption threshold.

Transparency Report Endpoint

# Retrieve enrollment metadata for a Right to Know response
# Returns what is stored and what is not — no biometric data in response

curl -X GET https://api.h33.ai/v1/biometric/enrollment-info \
  -H "Authorization: Bearer $H33_API_KEY" \
  -G -d "enrollment_id=usr_8xKm3nPq..."

// Response
{
  "enrollment_id": "usr_8xKm3nPq...",
  "enrolled_at": "2026-01-15T09:22:41Z",
  "modality": "face",
  "data_stored": {
    "bfv_ciphertext": true,
    "ciphertext_size_bytes": 32768,
    "encryption_scheme": "BFV (N=4096, t=65537, Q=56-bit)",
    "plaintext_stored": false,
    "raw_biometric_stored": false,
    "feature_vector_stored": false
  },
  "last_auth_at": "2026-02-23T11:07:33Z",
  "auth_count": 142,
  "pq_secure": true
}

Service Provider Obligations: H33 as Processor

CCPA defines a "service provider" as an entity that processes personal information on behalf of a business pursuant to a written contract. CPRA strengthened these obligations under 1798.140(ag), adding explicit prohibitions on retention, cross-customer data combination, and autonomous processing. H33 qualifies as a service provider — it processes biometric ciphertexts on behalf of its customers (the businesses) and never acts as a controller.

Architectural Enforcement of Service Provider Obligations

Traditional service providers rely on contractual commitments to restrict data use. H33's architecture provides cryptographic enforcement: the constraints are not promises in a DPA — they are mathematical impossibilities enforced by the BFV scheme.

Opt-Out Architecture: Client Controls Extraction

CCPA grants consumers the right to opt out of the sale of personal information (1798.120). CPRA expanded this to include sharing for cross-context behavioral advertising and added the right to limit use of sensitive personal information (1798.121). For biometric data, these rights impose the strictest handling requirements in the statute.

H33 Never Initiates Biometric Collection

The opt-out architecture is fundamental to H33's design. H33 is a passive processor. It never initiates, prompts, or requests biometric collection from consumers. The customer's application decides when to collect biometric data, from whom, and for what purpose. H33 provides the encryption and matching infrastructure — the business controls the collection decision.

• Collection is opt-in by design. The consumer must actively provide a biometric (face scan, fingerprint touch, etc.) through the customer's application. There is no background collection, passive surveillance, or ambient biometric capture.
• The customer can stop at any time. Discontinuing API calls to H33's enrollment and verification endpoints immediately halts all biometric processing. No data continues to flow.
• FHE makes extraction impossible. Even if biometric data were somehow collected without consent, the BFV ciphertext cannot be decrypted by H33 to produce usable biometric information. The opt-out is enforced by the laws of mathematics.

CCPA Data Flow: Consumer → Business → H33

Understanding CCPA compliance requires understanding the three-party relationship and where biometric data exists in what form at each stage. The following diagram traces the complete CCPA data flow from consumer to business to H33 service provider:

CCPA Requirements vs. H33 Technical Controls

The following table maps each CCPA/CPRA consumer right and business obligation to the specific H33 technical control that satisfies it:

Breach Notification and Liability Reduction

Under CCPA 1798.150, a data breach involving biometric information triggers statutory damages of $100–$750 per consumer per incident in private actions, plus administrative fines of $2,500 per violation ($7,500 for intentional violations). For a company with 1 million enrolled users, a biometric breach could mean $100M–$750M in statutory damages alone.

H33's architecture does not merely reduce breach liability — it can eliminate the breach notification trigger entirely. A server compromise yields only BFV ciphertexts, which are:

• Semantically secure — IND-CPA under the RLWE assumption. No information about the plaintext leaks from the ciphertext.
• Post-quantum resistant — the RLWE problem is believed to be hard for both classical and quantum computers.
• Threshold-decrypted — no single party (including H33) holds the complete decryption key. Compromising the server does not yield the key.

FHE vs. Traditional Biometric Architectures

To understand why H33's approach represents a categorical improvement in CCPA compliance, compare the data exposure surface across common biometric storage architectures:

Every traditional architecture requires the server to observe the plaintext biometric at some point — during enrollment, during comparison, or both. H33's FHE architecture eliminates this exposure entirely. The server performs authentication computations on ciphertexts and never observes the underlying biometric data. This is the difference between contractual compliance (promising not to misuse data you can see) and cryptographic compliance (being unable to misuse data you cannot see).

Implementation Guidance for Customers

H33 provides the cryptographic infrastructure, but CCPA compliance is the responsibility of the business (controller). Customers integrating H33's biometric APIs should implement:

• Privacy policy disclosure: Disclose that biometric information is collected (even in encrypted form). List modalities (face, fingerprint, etc.) and purpose (authentication). Disclose H33 as a service provider.
• Notice at collection (1798.100(b)): Inform consumers at or before the point of collection about categories of personal information being collected and their purposes. Biometric enrollment screens must include this notice.
• Sensitive PI opt-in: Biometric enrollment must be opt-in, not default-on. CPRA requires the right to limit use of sensitive personal information.
• Retention schedule: Establish and disclose a retention period for biometric templates. Call unenroll() when the retention period expires.
• Consumer request handling: Implement a workflow for fulfilling Right to Know, Right to Delete, and Right to Correct requests within the 45-day deadline. H33's APIs provide the technical primitives; the business must implement the consumer-facing request intake.
• DPA execution: Execute H33's Data Processing Addendum. This contract is required under 1798.140(ag)(1) and includes all CCPA-mandated service provider provisions.