PME — Engineering the Polymorphic Mutation Engine

Abstract

The Polymorphic Mutation Engine (PME) is the production reference implementation of ACSE. This paper describes the engineering decisions behind its five core subsystems, the 3-line integration API, the complete production TEE adapter stack (all five adapters across all major hardware-rooted security environments), and the test and benchmark methodology validating the Kali Invariant across 2,130 automated tests (20 October 2026).

PME is implemented in Rust — chosen for ownership-model memory safety. Zero unsafe blocks exist in the engine core, eliminating the class of memory vulnerabilities responsible for the majority of critical security flaws in C/C++ cryptographic implementations.

1. Five-Subsystem Architecture

2. EntropyManager

2.1 ChaCha20-DRBG Pool

The EntropyManager maintains a ChaCha20-DRBG entropy pool seeded from the OS CSPRNG. ChaCha20-DRBG is chosen over CTR-DRBG for its cache-timing side-channel resistance — critical when PME is deployed on hardware partially observable to an attacker. The pool is health-gated with NIST SP 800-90B continuous tests.

2.2 Per-Target Entropy Slicing

Multiple registered targets share the same pool but receive statistically independent slices:

entropy_for_target = SHA3-256(entropy_bundle || target_id || cycle_seq)

SHA3-256 preimage resistance means that entropy slices for any two targets are computationally independent even if the attacker observes one target's slice.

3. CryptoAuditLogger

3.1 SHA3-256 Chain Construction

Each audit record contains: UUID, timestamp (nanoseconds), profile ID, pre-mutation fingerprint, post-mutation fingerprint, entropy hash (not the entropy itself), trigger reason, TEE attestation quote, and:

chain_hash[N] = SHA3-256(chain_hash[N-1] || all_record_fields[N])

Chain verification is O(N) — a single forward pass. Any modification to any record changes its chain hash, invalidating all subsequent records.

3.2 TEE-Bound Records

Where a TPM 2.0 is present, the audit-signing key is a non-extractable key generated inside the TPM, and a TPM2_Certify assertion binds that key's identity to the TPM — the key's name, not each record, and not a PCR or platform-state quote. Records are signed by that key, so the chain is tamper-evident. There is no per-record hardware quote, no manufacturer endorsement-key chain, and the Control Plane does not yet verify these assertions (#143, #146); this binds the signing key to a TPM, not the full platform state. See the scope page.

4. StateTracker — Atomic Rollback

Before every mutation, StateTracker creates a cryptographic checkpoint: current fingerprint, chain hash, cycle sequence number, and TEE-attested timestamp. If Phase 3 validation fails, rollback to the checkpoint is atomic. The audit log receives a ROLLBACK record documenting the failure.

Post-mutation invariant checks (all three must pass or rollback):

1. Fingerprint change: assert fp_after != fp_before
2. Hamming distance: assert hamming(fp_after, fp_before) ≥ 128 bits
3. Profile validity: assert target.validate(fp_after) == true

5. Scheduler — Trigger Management

Burst coalescing prevents mutation storms: multiple high-priority triggers within a configurable window are merged into a single cycle. The Kali Invariant is maintained; thrashing is prevented.

6. MutationTarget Registry — 3-Line API

Any Rust application gains full ACSE protection with three lines:

let mut engine = MutationEngineCore::new(tee_adapter);                    // Line 1
engine.register(Box::new(SquidShieldTarget::new("payments")), "fin");  // Line 2
engine.trigger_mutation(TriggerReason::PerInvocation, None);           // Line 3

Swapping profiles or adding multiple profiles requires only changing the registration call — no application code changes needed. KaliCoreTarget (Profile 0xFF) fans out to all registered profiles simultaneously.

7. TEE/TPM Adapter Stack — One Live, Four Hardware-Pending

8. Testing Methodology — 2,130 Tests

• Unit tests: isolated subsystem tests covering every code path
• Profile tests: per-profile Kali Invariant enforcement, fingerprint uniqueness, rollback
• Integration tests: end-to-end 4-phase cycles across all profiles and all 6 TEE/TPM adapters
• Chain verification tests: audit chain integrity, tamper detection, rollback re-verify
• Red team simulation: automated scenarios including the linkability attack

All benchmarks are Criterion estimates: 100 samples, 3-second warmup, --release build. Reproducible with:

cargo bench --bench mutation_benchmark

9. pme-console Management Interface

The pme-console is an Actix-Web management interface (port 8888) providing six operational tabs: Profile Dashboard, Mutation History (SHA3-256 chain viewer), Anomaly Telemetry, ASMP Peer Network, KaliCoreTarget Control, and Demo Harness (Tab 6 — 11-step dual-panel attack simulation for CERT-In and enterprise evaluation).