Cryptographic Erasure

Disposal you can prove. Retention you can keep.

GDPR Art. 17, HIPAA Right to be Forgotten, and CCPA erasure rights pull in one direction. SOX, SEC Rule 17a-4, FINRA 4511, and HIPAA record-retention pull in the other. Bolt and Aeira use a single cryptographic construction that satisfies both — by destroying the only key that can read the data while preserving the ciphertext and an independently verifiable receipt.

Request the architecture brief Back to Trust Center

The construction

Four primitives, composed.

The mechanism has four pieces. The novelty is in the composition: each piece is a well-understood cryptographic primitive; combined, they deliver erasure-with-retention without sacrificing either obligation.

Cryptographic-erasure construction flow Per-tenant Customer Master Key wraps data-encryption keys. Encrypted bytes are stored in WORM ciphertext. Erasure destroys the tenant CMK in the KMS; the operator-root key signs a tamper-evident receipt that is appended to the BoltAuditSink Merkle chain. An auditor can verify the receipt after disposal because the operator-root key is distinct from the destroyed tenant CMK. BEFORE ERASURE — NORMAL OPERATION 1 Per-tenant CMK held in your KMS wraps DEKs 2 WORM ciphertext retained for SOX / SEC / HIPAA ERASURE REQUEST APPROVED 3 CMK destroyed disposal inside the KMS WORM ciphertext bytes remain on the shelf no key exists to read them unreadable 4 Tamper-evident receipt signed under operator-root key emit BoltAuditSink Merkle chain receipt appended at signed position Operator-root key is distinct from the destroyed tenant CMK — receipt remains verifiable after disposal.

  1. 1. Per-tenant Customer Master Key

    Every tenant's data — index entries, embeddings, audit chain payloads, PII vault — is encrypted at rest with a tenant-specific Customer Master Key (CMK) wrapped by your KMS. The CMK never leaves the KMS; the wrapped data-encryption keys live alongside the ciphertext.

  2. 2. WORM ciphertext retention

    The encrypted bytes remain in their write-once-read-many store after erasure. Regulators that require retention (SOX, SEC, HIPAA record-keeping) see the ciphertext on the shelf; nobody can read it. The same physical bytes satisfy both the retention duty and the erasure right.

  3. 3. Cryptographic disposal of the CMK

    When a subject erasure request is approved, the tenant CMK is destroyed inside the KMS. Every wrapped data-encryption key that depended on it becomes mathematically unrecoverable. The ciphertext is now indistinguishable from random noise to every party — including Sparcle, the operator, and any future court order.

  4. 4. Tamper-evident audit receipt

    The disposal event is recorded as a signed receipt under the operator-root key — a key distinct from the disposed tenant CMK. The receipt is verifiable after the tenant key is gone. The receipt is appended to the BoltAuditSink Merkle chain so it cannot be removed or backdated.

Why this satisfies both obligations

The single primitive that closes the gap.

Erasure right satisfied

GDPR Art. 17 and HIPAA Right to be Forgotten require that the data subject's information cease to be available. Cryptographic destruction of the only key capable of decrypting the data delivers that result without depending on every downstream backup, replica, or archive cooperating with a row-level delete.

Retention duty preserved

SOX, SEC Rule 17a-4, FINRA 4511, HIPAA record-retention, and equivalent obligations require that records persist for defined windows. The encrypted bytes remain. The retention auditor sees the artifact; only the readability has been revoked. This is the construction's central design point — both obligations satisfied by the same primitive.

Receipt independently verifiable

The signing key for the receipt is the operator-root key, kept under separate KMS isolation from the tenant CMK. Destruction of the tenant CMK does not affect the receipt's signature. A future auditor can verify the receipt long after the tenant key is gone.

Chain integrity preserved

The receipt is added to the BoltAuditSink Merkle chain. Removing or modifying the receipt would break the chain hash for every later event. The receipt is therefore as durable as the audit chain itself.

KMS backends

Where the key lives is your choice.

The construction is backend-agnostic; the trait-level abstraction lets each customer pick the KMS that fits their custody bar. The trait surface is identical, so swapping backends never changes the security model.

Backend
Status
LocalKms
File-backed, production-tested. Used in pilots, development, and air-gapped deployments where customer policy forbids cloud KMS.
AwsKms
Reference implementation in the aeira-rs trait library. Cloud-service integration testing in flight.
VaultKms
Reference implementation against HashiCorp Vault Transit. Cloud-service integration testing in flight.
PKCS#11 HSM
Reference implementation on the roadmap for buyers with HSM-mandated key custody (defense, federal, FFI).
Azure Key Vault, GCP KMS
On the roadmap. Track this page or contact [email protected] for target dates.

What an auditor receives

The packet your DPO or external auditor uses.

When a subject erasure request is processed, the customer's compliance officer can extract, for that request:

  • The signed disposal receipt, with the operator-root public key needed to verify it.
  • The Merkle inclusion proof showing the receipt is sealed in the audit chain at a specific position, with the chain hash before and after.
  • A timestamped record of which tenant CMK was destroyed, which ciphertext objects were dependent on it, and which retention policy applied to each.
  • A reference to the KMS audit log entry recording the destruction, signed by the KMS itself.

Customers running a SOC 2 or HIPAA audit feed this packet directly to their auditor. For GDPR Art. 17 Supervisory-Authority response, the packet provides the verifiable statement of completion that data-protection regulators look for.

What this page does not claim

Where the construction's edges sit.

The construction is precise about what it delivers. It is equally precise about what it does not. This section names the limits buyers and auditors should understand before relying on the receipt.

  • The construction is auditor-acceptable, not auditor-asserted. Sparcle does not claim a third-party cryptographer has certified this implementation. A customer whose external auditor or regulator requires an independent attestation should treat that as a separate engagement; reference materials and a threat model are available under NDA for that work.
  • The construction protects ciphertext at rest. Plaintext that has already been delivered to a downstream system the customer controls (a SIEM, a data warehouse, an external archive) is outside Sparcle's reach. The customer's erasure runbook needs to address those surfaces directly.
  • The construction does not erase the audit-receipt itself. The receipt records that the subject's data was disposed of; the receipt is durable by design. Regulators reading GDPR Art. 17 in conjunction with audit-retention obligations treat that as the correct outcome.
  • Quantum-resistance is not a property of the construction today. The CMK destruction guarantees readability removal under classical assumptions. A migration path to post-quantum KMS backends is on the roadmap; the construction is backend-agnostic.

Related controls

How this primitive sits next to the rest of the trust posture.

Cryptographic erasure is one control in a broader compliance architecture. The pages below cover the surrounding pieces:

  • Controls evidence map — where this primitive maps in SOC 2, HIPAA, GDPR, and ISO 27001 control matrices.
  • Where the model runs — how PII never reaches the LLM in plaintext, so the erasure surface stays small.
  • Sub-processor disclosure — why the customer's KMS, not Sparcle, holds the keys this construction destroys.
  • Security questionnaire — pre-filled answers covering encryption posture, key custody, and audit chain integrity.

Want the threat model and the formal write-up?

The full construction document — threat model, formal definitions, KMS-backend conformance test, and integration test report — is available under a mutual NDA during pilot evaluation.

[email protected] Browse the Trust Center