Cryptographic Erasure in Ternary Logic

This document is the unified reader-facing presentation of the four-step Cryptographic Erasure research program. Each step originated as a standalone Deep Research output; together they constitute the complete specification for deployment authorization. The specification is internally consistent across all verified architectural constraints, provides hardware-enforced cryptographic guarantees bounded by explicitly stated assumptions, and requires governance council members to accept each residual risk through individual signed statements before deployment proceeds.

Preamble and architectural scope

Ternary Logic mandates that every governed action produce a cryptographically sealed Decision Log entry committed to an immutable append-only ledger anchored across multiple blockchains. This design creates an inherent tension: the same immutability guaranteeing accountability becomes an attack surface for trade-secret extraction and an obstacle to GDPR Article 17 erasure obligations. Cryptographic erasure resolves both tensions through a unified key-destruction primitive that renders protected content computationally unrecoverable without altering the ledger's Merkle commitment structure.

All constructions use binary cryptographic primitives (AES-256-GCM, HKDF-SHA3-256, HMAC-SHA3-512) for hardware-acceleration compatibility and standards compliance. Ternary logic governs execution state transitions between cryptographic operations, not the operations themselves: the three-valued state machine (State +1 Execute, State 0 Hold, State -1 Block) gates key release, pipeline access, and zeroization at the hardware-software boundary.

Notation

• || denotes byte-string concatenation
• H(x) denotes SHA3-256(x) per NIST FIPS 202
• PRF(k,v) denotes HMAC-SHA3-512(k,v), 512-bit output
• KDF(ikm, salt, info) denotes HKDF-SHA3-256 per RFC 5869

Section 1: Forward secrecy and erasure threat models

1.1 Trade secret threat model

Decision Log justification fields carry proprietary intelligence constituting trade secrets under the Defend Trade Secrets Act (18 U.S.C. 1836) and EU Trade Secrets Directive (2016/943/EU): model configuration parameters, risk scoring thresholds, counterparty inference chains, algorithmic weighting coefficients, and governance escalation rationales. The ledger distinguishes audit-accessible fields (timestamps, event identifiers, state transitions, Merkle indices, anchor hashes) from EKR-encrypted fields (justification narratives, proprietary parameters, counterparty identifiers).

Three adversary classes define the threat surface. The passive archive reader possesses read access to committed ciphertext but holds no epoch keys; defense requires IND-CCA2 security from AES-256-GCM with non-reused nonces. AES-256 provides 128-bit post-quantum security under Grover's algorithm, eliminating the need for symmetric cipher migration. The active partial-compromise adversary has obtained some epoch N key through insider theft; the architectural response is strict epoch-bounded forward secrecy following the taxonomy of Boyd, Gellert, Jager, and Stebila (The Computer Journal, vol. 64, no. 4, pp. 639-652, 2021). The metadata adversary analyzes ciphertext lengths, commit timing, and anchor frequency; mitigation is achieved through constant-rate Merkle batch commitment (one batch every 30 seconds with padding entries), fixed-length ciphertext padding, and normalized anchor cadence.

1.2 Erasure threat model

Article 17(1) of the General Data Protection Regulation establishes the right to erasure. The TL ledger's immutability creates a direct conflict: physical deletion of any entry would break the Merkle commitment chain. Cryptographic erasure, formalized by Boneh and Lipton in "A Revocable Backup System" (6th USENIX Security Symposium, 1996), resolves this conflict. NIST SP 800-88 Rev 2 recognizes Cryptographic Erase as a valid Purge-level sanitization technique.

The European Data Protection Board addressed this directly in Guidelines 02/2025 on Processing of Personal Data through Blockchain Technologies, adopted 8 April 2025. The CNIL's September 2018 report and the UK ICO's "beyond use" doctrine provide complementary positions. Residual legal risk persists: some jurisdictions may not accept cryptographic erasure equivalence, requiring explicit disclosure to the competent supervisory authority before deployment.

1.3 Unified destruction guarantee

Both threat models resolve to the same primitive: key zeroization through the hardware root of trust. Epoch-scope destruction renders all EKR-encrypted content within an epoch permanently unrecoverable; subject-scope destruction targets only the Subject Derivation Table entry for the requesting data subject. Both invoke the same hrot_zeroize() interface, producing FIPS 140-3 compliant key destruction. Both produce the same audit evidence: a Destruction Event record committed to the Immutable Ledger before zeroization executes, per the No Log = No Action invariant.

Section 2: Key hierarchy architecture

2.1 Epoch key derivation via HKDF-SHA3-256

The epoch encryption key is derived using HKDF-SHA3-256 following the extract-then-expand paradigm formalized by Krawczyk (CRYPTO 2010, Springer LNCS vol. 6223, pp. 631-648) and standardized in RFC 5869. The input keying material for epoch N is:

IKM_n  = hrot_attest_counter(n) || heartbeat_entropy_n || merkle_root_{n-1}
salt_n = uint64_be(n)
info   = governance_domain_id || algorithm_id || "EKR-EPOCH"
epoch_key_n = HKDF-SHA3-256(IKM_n, salt_n, info)[0:32]

The genesis case (epoch 0) uses H(genesis governance ceremony attestation) in place of the prior Merkle root. AES-256-GCM is selected as the baseline authenticated cipher per NIST FIPS 197 and SP 800-38D, with AES-NI delivering throughput exceeding 2,200 MB/s per core. The hash agility mechanism encodes the algorithm identifier in the info field, enabling clean migration between cryptographic suites without breaking the epoch chain.

2.2 Subject-derived keys for commanded erasure

Per-subject encryption keys use a hardened hierarchical derivation:

subject_key_n = PRF(epoch_key_n, subject_pseudonym_S || uint64_be(n))

The subject pseudonym is the Hybrid Shield output, already committed to the Merkle tree. Subject keys are never stored persistently; they are re-derived on demand from the epoch key and subject pseudonym. Commanded erasure destroys the Subject Derivation Table entry for the target subject, removing the pseudonym from the derivation lookup path.

The audit read key is derived as a separate branch:

audit_key_n = PRF(master_audit_secret || chain_code, uint64_be(n))

Auditors receive audit_key_n for specific epochs upon authorized request. They cannot derive epoch_key_n because the audit derivation path uses a different root secret. They cannot derive audit_key_n±1 because the PRF is evaluated independently per epoch.

2.3 Key lifecycle state machine

The epoch key lifecycle follows a five-state progression mapped to TL ternary states: Genesis (State 0-Transient during derivation, State +1 on completion), Active (State +1, default 24-hour duration), Rotation-Pending (State +1 until boundary), Escrowed (Shamir k-of-n threshold custody, State -1 for direct operational use), and Zeroized (State -1 permanent, terminal state). Forced rotation triggers include heartbeat entropy failure, tamper detection, and authorized governance command.

Section 3: Hardware root of trust and timing architecture

3.1 HRoT epoch counter and physical security

The baseline TPM 2.0 binding uses the NV Index facility with the TPMA_NV_COUNTER attribute per TCG TPM 2.0 Library Specification. TPM2_NV_Increment advances the counter; TPM2_NV_Certify produces an attestation signature. The ROCA vulnerability (CVE-2017-15361, Nemec et al. ACM CCS 2017) affected approximately 25% of TPMs globally; the specification addresses this class through standardized probabilistic prime generation, ROCA fingerprint detection during deployment validation, and the post-quantum migration path that replaces RSA-based attestation with SLH-DSA signatures.

Physical tamper protection requires a tamper mesh conforming to FIPS 140-3 Security Level 3. The Thales Luna 7 HSM (NIST Certificate 4962, April 2024) implements this through a multi-chip standalone module in a tamper-responsive enclosure. Fault injection mitigation follows the countermeasure taxonomy in the Trusted Firmware-M Fault Injection Mitigation guidance.

3.2 Timing budget and the Fast Lane Prohibition

The Fast Lane Prohibition is a named mandatory constraint: direct HRoT non-volatile storage access is prohibited in the Fast Lane decision path (sub-2ms latency budget). TPM 2.0 NV operations carry latencies of 5 to 600 milliseconds, which would violate the Fast Lane budget by one to two orders of magnitude.

The Fast Lane budget sum totals approximately 0.3 ms under normal conditions, providing a 5.7x margin within the 2ms budget.

3.3 Heartbeat entropy source

The TRNG conforms to NIST SP 800-90B (January 2018), with minimum 256 bits of min-entropy per epoch key derivation. Startup testing requires 4,096 noise source samples per SP 800-90B Section 4.3; continuous health testing applies the Repetition Count Test and Adaptive Proportion Test every 100 milliseconds. Entropy failure triggers State 0-Suspended and emergency epoch rotation before the next log entry is accepted. The TRNG operates on a separate power domain from the log generation pipeline, with no network-accessible interface on the entropy output path.

3.4 Ternary-binary interface governance semantics

The epoch key must not be readable by the AES engine unless the ternary state register holds State +1. State 0 gates the key bus physically (not merely logically); State -1 triggers immediate key bus zeroization. The +1-to--1 transition must take effect within one clock cycle regardless of AES pipeline depth. The 0-to-+1 transition requires a two-cycle hold to prevent transient glitches from allowing unauthorized reads. Physical implementation details are deferred to the Hardware Architecture folder.

Overview

Step 2 integrates the cryptographic foundations from Step 1 with the structural invariants of the TL architecture: the No Log = No Action principle, Merkle tree construction, the Hybrid Shield pseudonymization layer, and the Anchors pillar. It then specifies the full governance workflow for GDPR commanded destruction, distinct from scheduled epoch rotation.

Section 4: NL=NA integration and Merkle architecture integration

4.1 DITL gate interaction with epoch key availability

Epoch key availability is a hard prerequisite for DITL gate signal generation. The gate sequence proceeds in strict serial order: log content generated in TEE memory; epoch key retrieved from TEE cache (State 0-Transient during retrieval, maximum latency 0.5 milliseconds within the Fast Lane budget); encryption executes; plaintext immediately zeroized from hardware-accessible memory; Merkle leaf constructed; gate signal released (State +1).

Destruction Event log entries are themselves EKR-encrypted and must be generated and Merkle-committed before zeroization executes. The Destruction Event is the cryptographic proof that destruction was governed, authorized, and logged. Zeroization without a preceding committed Destruction Event is a protocol violation detectable by auditors examining the anchor chain.

4.2 Merkle leaf construction for encrypted entries

Each encrypted log entry produces a Merkle leaf with RFC 6962 domain separation:

leaf = H(0x00 || ciphertext || authenticated_tag || epoch_number
         || entry_sequence || subject_pseudonym_hash)

The 0x00 prefix distinguishes leaf hashes from internal node hashes (0x01 prefix), following RFC 6962 (Laurie, Langley, Kasper, 2013) and RFC 9162 (Laurie, Messeri, Stradling, 2021). This construction traces to Crosby and Wallach ("Efficient Data Structures for Tamper-Evident Logging," 18th USENIX Security Symposium, 2009). SHA3-256's sponge construction, unlike Merkle-Damgard, is inherently resistant to length-extension attacks.

Epoch boundaries mid-batch require an additional epoch map leaf per epoch represented in the batch:

epoch_map_leaf = H(0x00 || epoch_number || epoch_key_fingerprint)

where epoch_key_fingerprint = H(epoch_key_n) is a one-way commitment to the key. This prevents epoch substitution attacks where an adversary swaps entries between epochs while maintaining valid individual leaf hashes.

4.3 Hybrid Shield operation order

Pseudonymization executes first, producing the subject pseudonym committed to the Merkle tree. EKR encryption executes second, encrypting the pseudonymized content. This ordering produces a two-layer protection structure: a verifier with pseudonymization keys but not epoch keys can verify identity commitments without reading content; a verifier with epoch keys but not pseudonymization keys can read content but cannot resolve pseudonyms. Full access requires both keys under separate governance authorization tracked independently in the Immutable Ledger.

The legal basis rests on GDPR Article 4(5) defining pseudonymization and EDPB Guidelines 01/2025 on Pseudonymisation (adopted 14 January 2025). The Hybrid Shield mapping constitutes the "additional information" referenced in Article 4(5); its storage under separate governance authorization satisfies the "kept separately" requirement.

4.4 Anchor timing decoupling

Predictable anchor scheduling creates exploitable attack surfaces: targeted network disruption (eclipse attacks per Heilman et al. 24th USENIX Security Symposium 2015) and fee market manipulation (MEV/frontrunning per Daian et al. IEEE S&P 2020, mempool flooding per Saad et al. IEEE ICBC 2019).

Epoch boundary timing incorporates a uniformly distributed random offset from the TRNG, bounded to plus or minus 20 percent of nominal epoch duration. For a 24-hour epoch, actual boundaries may occur up to 4.8 hours before or after nominal. Anchor publication uses an independent schedule not synchronized to epoch boundaries. Jitter offsets are logged in Epoch Rotation Events and Destruction Events for auditability, satisfying both unpredictability (to adversaries) and reconstructability (for auditors).

Section 5: Commanded destruction - GDPR erasure governance

5.1 Erasure authorization protocol

Commanded destruction is architecturally distinct from automated EKR rotation. Conflating them creates audit ambiguity. A valid erasure command requires four sequential prerequisites:

1. Authenticated data subject request with identity verification against the Hybrid Shield pseudonym mapping, logged and Merkle-committed per NL=NA. GDPR Article 12(3) requires response within one month.
2. Custodian multi-signature authorization. Default threshold: 3-of-5 for subject-scope destruction, 5-of-7 for epoch-scope destruction. Implements Shamir secret sharing (Communications of the ACM, vol. 22, no. 11, 1979). Threshold signatures generated via FROST (Komlo and Goldberg, SAC 2020; RFC 9591, June 2024) so the signing key is never materialized in any single location.
3. Destruction Event log entry generated, EKR-encrypted, and Merkle-committed before any zeroization executes.
4. Confirmation receipt to the data subject containing the ledger reference hash.

Custodian selection enforces segregation of duties: no individual holds multiple shares; no single organizational unit controls a majority; at least one share is held by an independent fiduciary.

5.2 Subject key destruction execution

The Subject Derivation Table is stored in HRoT non-volatile memory, not in software state. The target entry is overwritten with cryptographically random data (not zeroes) to defeat wear-leveling and deduplication optimizations, following Wei, Grupp, Spada, and Swanson ("Reliably Erasing Data from Flash-Based Solid State Drives," 9th USENIX FAST, 2011). Hasan and Ray ("Data Recovery from Scrubbed NAND Flash Storage," 29th USENIX Security, 2020) demonstrated that even scrubbed NAND retains analog threshold voltage imprints, motivating the defense-in-depth multiple-overwrite approach.

After overwrite, TPM2_NV_UndefineSpace deallocates the NV index. The two-step process satisfies NIST SP 800-88 Revision 2 Purge-level sanitization requirements. The epoch key itself is not destroyed; only the derivation path for that specific subject is severed.

Attestation of destruction uses TPM2_NV_Certify producing a signed TPMS_ATTEST structure, appended to the Destruction Event log entry before that entry is Merkle-committed. This quote constitutes the cryptographic proof of erasure.

5.3 Regulatory compliance documentation

The architecture resolves the apparent conflict between securities retention (SEC Rule 17a-4, FINRA Rule 4511) and data protection erasure (GDPR Article 17) by distinguishing between content (rendered unrecoverable via key destruction) and proof of governance (retained indefinitely). SEC Rule 17a-4(f) as amended effective 3 January 2023 permits an audit-trail alternative to WORM storage; the TL Merkle-committed blockchain-anchored log satisfies this alternative through structural immutability, NL=NA-enforced audit trails, embedded timestamps, and FROST threshold signatures identifying authorizing custodians.

Destruction Event log entries are retained indefinitely. The log entry is not the personal data; it is the proof that personal data was destroyed, retained in pseudonymized form consistent with the GDPR Article 5(2) accountability principle.

Overview

The symmetric core (AES-256-GCM and HKDF-SHA3-256) requires zero post-quantum migration, while the public-key components demand structured replacement by 2030. This step specifies concrete migration paths for ML-KEM-1024 and SLH-DSA-SHAKE-128s, provides four formally verifiable LTL properties with complete NuSMV models, defines five CAVP-style test vectors, and delivers four architectural diagrams.

Section 6: Post-quantum migration path

6.1 AES-256-GCM requires no post-quantum migration

AES-256-GCM retains 128-bit security under quantum attack. Grover's algorithm provides at most a quadratic speedup, reducing n-bit key security to n/2 bits. NIST's PQC FAQ confirms AES-256 meets Category 5, the highest security level. The 128-bit authentication tag provides 2^-128 forgery probability per NIST SP 800-38D.

6.2 HKDF-SHA3-256 provides the immediate post-quantum baseline

The SHA-3 sponge construction achieves security bounded by O(2^(c/2)) where c=512 for SHA3-256, yielding 256-bit classical and 128-bit quantum security (Bertoni, Daemen, Peeters, Van Assche, EUROCRYPT 2008). Song and Yun proved HMAC/NMAC are quantum-secure PRFs ("Quantum Security of NMAC and Related Constructions," CRYPTO 2017).

6.3 ML-KEM-1024 targets key encapsulation migration

ML-KEM-1024 (NIST FIPS 203, 13 August 2024) provides NIST Category 5 security. Post-migration IKM construction: IKM = counter_be || heartbeat_entropy || prev_merkle_root || mlkem_shared_secret. Cryptographic agility is maintained through the algorithm identifier in the HKDF info field: pre-migration epochs use "SHA3-256-AES-256-GCM-v1"; post-migration epochs use "SHA3-256-AES-256-GCM-MLKEM1024-v1".

CNSA 2.0 (NSA, September 2022, updated December 2024) mandates ML-KEM-1024 with new acquisitions CNSA 2.0 compliant by 1 January 2027 and all non-compliant equipment phased out by 31 December 2030. NIST IR 8547 sets the broader deprecation deadline at 2030 and full disallowance by 2035.

6.4 SLH-DSA-SHAKE-128s targets epoch attestation signatures

TPM 2.0 ECDSA P-256 signatures are quantum-vulnerable under Shor's algorithm. SLH-DSA-SHAKE-128s (NIST FIPS 205, 13 August 2024) is the migration target: 32-byte public key, 64-byte private key, 7,856-byte signature at NIST Category 1. Security reduces entirely to hash function properties, with no lattice or number-theoretic assumptions. The scheme descends from SPHINCS (Bernstein et al. EUROCRYPT 2015) and SPHINCS+ (Bernstein et al. ACM CCS 2019).

6.5 Epoch chain migration protocol

Migration proceeds in three phases. Announcement phase: 5-of-7 FROST governance threshold designates a future epoch M as the migration epoch. Dual-derivation phase: at epoch M, both old-algorithm and new-algorithm key derivations execute in parallel; both keys and their algorithm identifiers are committed to the ledger. Confirmation phase: 5-of-7 governance threshold signs a migration-complete attestation; epoch M+1 uses exclusively the new construction; the old derivation path is retired.

Section 7.1 LTL formal specification with NuSMV model checking

Four Linear Temporal Logic properties specified for model checking in NuSMV (Cimatti et al. CAV 2002). LTL was introduced as a program verification formalism by Pnueli (18th FOCS, 1977).

Property 1 - Epoch transition safety

G (EpochBoundary -> X (KeyZeroized AND MerkleRootCommitted))

Globally, whenever an epoch boundary occurs, in the immediately next state both the previous epoch key has been zeroized and the new Merkle root has been committed. State space: 32 reachable states. Expected outcome: TRUE. Counterexample class: any trace where epoch_boundary holds at step i but at step i+1 either prev_key_status remains active or merkle_status remains pending.

Property 2 - Epoch liveness

F (EpochStart -> F KeyAvailableWithinDeadline)

There exists a future state where, if an epoch starts, the epoch key eventually becomes available within the derivation deadline. State space: 176 states. Expected outcome: TRUE for both F-guarded and stronger G-guarded variants.

Property 3 - Erasure ordering safety

G (ErasureCommand -> X (DestructionEventLogged AND X MappingZeroized))

At step i an erasure command is issued, at step i+1 the destruction event is logged (NL=NA enforcement), at step i+2 the subject-derived key mapping is zeroized. State space: 20 states. Expected outcome: TRUE. Counterexample class: any transition from commanded to a state other than logged (skipping NL=NA), or from logged to a state other than zeroized.

Property 4 - NL=NA coupling

G ((State0 OR StateNeg1) -> NOT EncryptionActive)

Encryption operations are blocked in all ternary states except State +1. State space: 8 states. Expected outcome: TRUE. The DEFINE for EncryptionActive structurally gates encryption behind tl_state = plus1, making the property hold by construction of the DITL gate logic.

Section 7.2 Attack surface control table

Section 7.3 NIST CAVP-style test vectors

Five test vectors exercise the HKDF-SHA3-256 epoch key derivation. The info field is constant across all vectors (53 bytes):

info = "TL-EKR-TEST-DOMAIN-v1" || "SHA3-256-AES-256-GCM-v1" || "EKR-EPOCH"

Hex (53 bytes):
544c2d454b522d544553542d444f4d41494e2d7631
534841332d3235362d4145532d3235362d47434d2d7631
454b522d45504f4348

• TEST 1 - Genesis epoch: counter=0x01, entropy=0x00{32}, prev_root=H(0x00{32})
• TEST 2 - Normal epoch: counter=0x42, non-trivial entropy and prev_root
• TEST 3 - Emergency rotation: entropy=0xAA{32} below min-entropy threshold
• TEST 4 - Avalanche negative test: TEST 2 with single bit flipped; output must differ in 100-156 of 256 bits (3-sigma bound)
• TEST 5 - Dependency chain negative test: TEST 2 with prev_root byte altered; output must differ entirely

Conformance criterion: Expected outputs must be computed using a NIST ACVP-validated HKDF implementation (ACVP KDA/HKDF per SP 800-56C, hmacAlg=SHA3-256). Implementations must match the ACVP reference output byte-for-byte.

Section 7.4 Mandatory diagrams

Preamble

This step is the Governance Council Acceptance Document. Steps 1 through 3 defined the complete technical specification. This document does not add new technical content. It draws a clear line around the protections established in Steps 1 through 3, names the risks that remain outside that line, and presents each residual risk as an explicit, signable acceptance statement. Every member of the governance council must read, understand, and sign this document before deployment proceeds.

Section 8.1 What Cryptographic Erasure protects

Protection 1: Content confidentiality

All logged decisions, subject records, and governance actions are encrypted at rest under AES-256 with epoch-scoped keys derived through HKDF-SHA3-256 (Step 1, Section 2.2). An adversary who obtains ciphertext but lacks both the epoch key and the subject key cannot recover plaintext. Bounded by the computational hardness of AES-256 and HKDF-SHA3-256, which NIST SP 800-175B Rev 1 (March 2020) classifies as providing confidentiality services at or above 128-bit security strength.

Protection 2: Forward secrecy across epoch boundaries

Compromise of an epoch key exposes only the log entries encrypted under that single epoch. Forward secrecy depends on HRoT zeroization of the prior epoch key executing before key material becomes extractable by any attacker, including an attacker with physical access. If zeroization is delayed or defeated, forward secrecy for the affected epoch transition is lost.

Protection 3: GDPR Article 17 compliance through crypto-shredding

Subject-specific decryption key destruction within HRoT non-volatile memory (Step 2, Section 5.2) renders all subject-linked ciphertext computationally unrecoverable. The governance audit trail documents the destruction event, FROST authorization, and Merkle commitment. Dependent on supervisory authority acceptance of crypto-shredding in the specific deployment jurisdiction. EDPB Guidelines 02/2025 treat crypto-shredding as a pragmatic near-equivalent where true deletion is technically impracticable, while requiring controllers to document the rationale and conduct a DPIA.

Section 8.2 What Cryptographic Erasure does not protect against

Section 8.3 Residual risk acceptance criteria

The governance council must acknowledge each statement below individually and explicitly before deployment authorization. A signature next to each statement constitutes acceptance. Refusal to sign any single statement blocks deployment until the concern is resolved.

Section 8.4 Degraded mode in software-only deployment

Any deployment operating without a hardware root of trust must carry the following disclosure in all compliance documentation, regulatory submissions, and audit reports. This disclosure may not be omitted, abbreviated, or paraphrased in a way that obscures its meaning.

Required Degraded Mode Disclosure:

"This deployment operates in software-only mode without a Hardware Root of Trust. In this mode, Cryptographic Erasure degrades to policy-only enforcement with the following specific consequences: (1) The epoch counter is software-managed and subject to manipulation by any attacker with operating system privileges. (2) Key zeroization executes through software memory operations that may leave recoverable traces in swap files, core dumps, or volatile memory subject to cold-boot extraction. (3) The Fast Lane Prohibition cannot be hardware-enforced and relies on software scheduling constraints that a privileged attacker can override. (4) Erasure guarantees under GDPR Article 17 become governance commitments backed by procedural controls rather than hardware-enforced cryptographic constraints. This degraded mode must not be represented as equivalent to hardware-enforced Cryptographic Erasure in any compliance documentation."

Under GDPR Article 32, controllers must implement technical measures appropriate to risk, taking into account the state of the art. Hardware security modules certified to FIPS 140-3 Level 3 provide tamper-resistant enclosures and automatic zeroization; software-only deployments correspond to FIPS 140-3 Level 1. The gap between Level 1 and Level 3 is not incremental. For SEC Rule 17a-4 compliance, the WORM requirement is supported by hardware-enforced immutability in Level 3 mode; in software-only mode, immutability depends on operating system access controls that privileged insiders can modify.

Section 8.5 Cross-reference consistency index

Five architectural constraints verified across all sections of Steps 1 through 3. Any inconsistency found is flagged explicitly rather than resolved silently.

Constraint 1: Fast Lane Prohibition

Constraint 2: NL=NA coupling to destruction events

Constraint 3: State -1 permanence

Constraint 4: Plaintext prohibition

Constraint 5: Audit key isolation

Signature block