ACSE / PME / ASMP·1.0 — Technical Whitepaper

Abstract

Adaptive Cryptographic Surface Engineering (ACSE) is a new architectural layer that continuously mutates the observable cryptographic identity of protected systems — API endpoints, session tokens, network fingerprints, database connection identifiers, and TLS certificates — at every rotation cycle (60 s by default). The engine's fingerprint at t+1 is computed from fresh entropy, independent of the one at t; what an attacker can observe of a host changes at every rotation.

This paper presents the complete ACSE stack: the Polymorphic Mutation Engine (PME) reference implementation, the Adaptive Surface Mutation Protocol (ASMP/1.0) for estate-wide coordination, the ten domain profiles, TorpedoRay and the KaliCoreTarget composite, red-team evaluation results, and performance benchmarks across all profiles.

1. Introduction

1.1 The Static Surface Problem

Modern cyberattacks succeed not because encryption or firewalls fail, but because the observable surface of the target system — its fingerprints, identifiers, session tokens — remains static and predictable long enough for the attacker to build a usable model and act on it.

The result is visible in every major breach of the past decade: long dwell times measured in days and months, credential harvesting that pays off because credentials remain valid indefinitely, lateral movement across network topologies that stay mapped because the topology does not change.

1.2 The Core Insight

ACSE enforces one formal property — the Kali Invariant: for every protected surface S and every rotation cycle t, the engine's fingerprint F(S, t+1) is computed from fresh entropy and is independent of F(S, t). The Hamming distance between successive fingerprints averages 128 bits — the expectation for two independently sampled SHA3-256 outputs.

An attacker who observes F(S, t) gains zero information about F(S, t+1). The reconnaissance model built over any number of cycles has no predictive power over the next cycle. The attacker's map expires before it can be acted on.

1.3 The KaliCore Philosophy

The PME engine is governed by KaliCore — the insight that continuous, autonomous surface mutation is not just a security feature but an operating principle. The name reflects the development lineage: built on Kali Linux, guided by the principle that Ma Kali — the goddess of time, transformation, and destruction of what is obsolete — best represents the engine's governing intelligence.

2. Background — What Existing Defences Miss

3. Architecture

3.1 Four-Layer Model

ACSE is structured as four co-operating layers — a management control plane that operators run the estate from, sitting above the three runtime layers that enforce the Kali Invariant. Each can be independently verified and independently deployed.

3.2 KaliCore — Governing Intelligence

KaliCore is the governing intelligence of the mutation engine — a three-subsystem triad that drives autonomous state transitions, manages entropy, and orchestrates the complete mutation lifecycle.

KaliCore transitions autonomously between three organ states based on the EWMA anomaly score: Sachs (steady-state), Hunter (elevated, score ≥ 0.35), and Main Organ (full response, score ≥ 0.70). Transitions are driven by authenticated anomaly signals from any source — network sensors, SIEM integrations, ASMP peer nodes.

3.3 PME Five Subsystems

The Polymorphic Mutation Engine comprises five co-operating subsystems, all orchestrated by MutationEngineCore:

• EntropyManager: ChaCha20-DRBG pool, health-gated, per-target SHA3-256 slicing — statistical independence across all registered targets
• CryptoAuditLogger: SHA3-256-chained append-only log — tamper-evident mutation history, hardware-attestation-bound in production
• StateTracker: Cryptographic checkpointing and atomic rollback — a partial mutation is prevented (all-or-nothing)
• Scheduler: Priority queue with burst coalescing — the Kali Invariant is not starved by load
• MutationTarget Registry: Plugin interface shared by the ten domain profiles, TorpedoRay and the KaliCoreTarget composite — all composed in the shipped agent and swappable by changing one registration call; apart from the surfaces listed on Scope, their behaviours act on an in-memory model (see §4)

3.4 The 4-Phase Atomic Mutation Cycle

Every mutation follows four phases regardless of profile. A partial mutation is not committed: the cycle is rolled back and the rollback verified, or the engine enters SafeMode (F12).

3.5 3-Line Integration API

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

4. Ten Bio-Inspired Profiles, Plus TorpedoRay and KaliCoreTarget

The ten bio-inspired profiles are not independent engines — they are ten expressions of a single MutationEngineCore, each tuned to its domain's threat model and compliance requirements. All enforce the Kali Invariant identically, and all 11 have real, tested implementations in the codebase. They differ in how far each has moved through integration: all composed in the shipped agent; apart from the surfaces listed on Scope, their behaviours act on an in-memory model — a routine config-wiring gap, not a design gap; SquidShield is implemented and tested but built per-transaction, so it needs a different integration model before it can be registered against the agent's per-node model; and ElectricEelGrid is implemented but deliberately not yet activated, pending a future anomaly-detection subsystem this project has not yet built.

*TorpedoRay is not one of the ten domain-specific profiles above — it is a distinct 12th profile that mutates the transport channel itself (JA3/JA3S fingerprint, session token) beneath all of them, rather than a business surface within one of them. It is composed in the shipped agent, both standalone and as a KaliCore sub-target, bringing the total the shipped agent can construct today to 5: KaliCore, KrakenNet, NautilusVault, LeviathanGrid, and TorpedoRay. See WP-08 for the full architecture and patent claims.

5. ASMP/1.0 — Adaptive Surface Mutation Protocol

ASMP/1.0 transforms PME from a node-level library into an estate-wide coordinated defence. Five authenticated message types carry the Kali Invariant across the network. MSG-001, MSG-002 and MSG-004 are live in the shipped product, and MSG-003 is specified but not yet used by the product; MSG-005 (node-granted protected actions) gates one protected action — an operator's "rotate now" — and is not currently wired into any live API authentication path — production API authentication today is API-key + RBAC.

6. Implementation & Test Results

6.1 Technology Stack

• Language: Rust — zero
• unsafe
• blocks in the engine core; memory safety by construction
• Cryptography: SHA3-256 (Keccak) for all token derivation, fingerprinting, and audit chain linking. ChaCha20-DRBG for entropy.
• Benchmarking: Criterion — 100 samples per measurement, 3-second warmup,
• --release
• build. All numbers are Criterion mean estimates, 12 October 2026, on an Intel Core i5-8265U laptop: the compute time of one mutation cycle in the in-memory model, not a rotation interval (a deployed node rotates every 60 s by default).
• Testing: 2,130 tests passed, 0 failed, 14 ignored (20 October 2026)
• Management: pme-console — Actix-Web dashboard (port 8888) with 6 tabs including Demo Harness for CERT-In evaluation

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

Switching TEE adapters requires changing one constructor parameter. All profiles and all engine logic are adapter-agnostic. Only TpmAdapter has been exercised against real hardware and produces a verified, non-extractable audit-signing key today. SGX, Nitro, and SEV-SNP are real, unit-tested implementations awaiting funded hardware access to validate, not further engineering; ARM CCA is a harder limit, since no commercially purchasable ARM CCA hardware exists to test against at all.

7. Red Team Evaluation

The red team assumed a white-box adversary with full architectural knowledge, optimal algorithms, and an unconstrained tool set (Metasploit, Nmap, Wireshark, Burp Suite, custom Python). Attack duration was unbounded.

8. Performance Benchmarks

All benchmarks are Criterion mean estimates, 12 October 2026, on an Intel Core i5-8265U laptop (compute time of one mutation cycle in the in-memory model; a deployed node rotates every 60 s by default), --release build, 100 samples per measurement.

* GlassFrog low throughput by design (HIPAA proof per cycle). † Sachs mode; Hunter and Main Organ increase rate at lower throughput.

9. Case Studies

Three high-impact breaches illustrate where PME is designed to intervene. The counterfactuals describe the design: each capability they rely on is marked where it is planned rather than built. In every case, the attack depended on a surface that remained static long enough to exploit.

9.1 Change Healthcare (February 2024)

Impact: $2.457B total cost · 192.7M patient records · $22M Bitcoin ransom · 9-day dwell

9.2 SolarWinds Orion (Detected December 2020)

Impact: 18,000+ organisations · 14+ months dwell · US federal agencies compromised

9.3 Stryker-Handala Wiper Attack (March 2026)

Impact: 50TB exfiltrated · 200,000+ devices wiped · 79 countries · ~6 months dwell

10. Conclusion

Adaptive Cryptographic Surface Engineering represents a fundamental shift from static defence to continuous cryptographic motion. The Kali Invariant is a structural property, not a policy assertion — enforced at every rotation cycle and checked by an independent verifier.

The complete stack — CP v0.4.0, PME, ASMP/1.0 (MSG-001, MSG-002, MSG-004), and all ten domain-specific profiles' implementations — is built and in pilot preparation, with hardware-rooted audit-signing key custody live and hardware-verified on TPM 2.0 today — SGX, Nitro, SEV-SNP, and ARM CCA adapters are real, unit-tested code pending real-hardware validation (see §6.2) — and a 2,130-test suite (0 failed, 14 ignored, 20 October 2026) passing. the ten domain profiles, TorpedoRay and the KaliCoreTarget composite are all composed in the shipped agent; apart from the surfaces listed on Scope, their behaviours act on an in-memory model (see §4). MSG-005 (node-granted protected actions; TEE binding planned) is modelled in ProVerif and gates one protected action today, but is not yet wired into a live API authentication path; production API authentication is API-key + RBAC.