ASMP/1.0 — A Wire Protocol for Coordinated Surface Mutation

Abstract

The Adaptive Surface Mutation Protocol (ASMP/1.0) transforms the Polymorphic Mutation Engine from a node-level library into a networked security system. This document is the authoritative protocol specification defining all five message types with complete wire formats, security properties, and formal verification results.

1. Design Goals

• Authenticated mutation coordination: All inter-node synchronisation is authenticated. Unauthenticated messages are rejected at the protocol layer.
• Peer authentication without transmitting the shared secret: Peers authenticate without revealing internal surface state to eavesdroppers.
• Cascade mutation: A single threat detection triggers simultaneous surface rotation across all authenticated peers.
• Node-granted management actions: A protected management action runs only with a token issued by the node itself (MSG-005). Binding that token to a hardware TEE is planned, not shipped.
• Implementation independence: The protocol is wire-level specified. A Go, Python, or FPGA implementation is fully interoperable with the Rust reference.

2. Notation

u8/u16/u64: unsigned integers, big-endian. [u8;N]: fixed byte array. SHA3-256(x): SHA3-256 (Keccak) hash. HMAC(key,msg): HMAC-SHA3-256. ||: byte concatenation. TEE_QUOTE(data): platform-specific TEE attestation quote.

3. MSG-001 — Mutation Frame

The fundamental audit unit. Every mutation produces exactly one Mutation Frame. Frames form a SHA3-256 chain constituting the tamper-evident estate-wide mutation history.

ASMP-MSG-001: Mutation Frame
  message_type:  u8      = 0x01
  version:       u8      = 0x01
  profile_id:    u8      // 0x01=MantisNet … 0x0A=LeviathanGrid … 0xFF=KaliCoreTarget
  cycle_seq:     u64     // monotonically increasing, per-profile
  entropy_hash:  [u8;32] // SHA3-256(entropy_bundle) — not the entropy itself
  surface_fp:    [u8;32] // SHA3-256(new observable surface state)
  prev_fp:       [u8;32] // SHA3-256(previous surface) — chain link
  organ_state:   u8      // 0=Sachs 1=Hunter 2=MainOrgan 3=Recovering
  node_id:       [u8;16] // UUID v4 of originating node
  timestamp_ns:  u64
  hmac:          [u8;32] // HMAC-SHA3-256(key, all preceding fields)

Chain property: frame[N].prev_fp == SHA3(frame[N-1].surface_fp) — inserting or removing a frame changes all subsequent HMACs, which are HMAC-key-protected.

4. MSG-002 — Peer Authentication Handshake

Step 1 (Initiator → Responder):
  HELLO { peer_id: [u8;16], claimed_epoch: u64, hmac: [u8;32] }

Step 2 (Responder → Initiator):
  CHALLENGE { nonce: [u8;32], surface_fp_at_epoch: [u8;32], hmac: [u8;32] }

Step 3 (Initiator → Responder):
  RESPONSE { proof: SHA3-256(nonce || ally_channel_fp_at_epoch), hmac: [u8;32] }

Step 4 (Responder → Initiator):
  VERDICT { result: u8 (0x00=REJECT | 0x01=ACCEPT), hmac: [u8;32] }

5. MSG-003 — Anomaly Signal

ASMP-MSG-003: Anomaly Signal
  source_node_id: [u8;16]
  anomaly_score:  u32     // Fixed-point [0,1] × 1_000_000
  signal_class:   u8      // 0x01=Network 0x02=AuthFail 0x03=Physical 0x04=SIEM
  target_node_id: [u8;16] // All-zeros = estate-wide
  timestamp_ns:   u64
  hmac:           [u8;32]

Only sources with the ASMP HMAC key can inject valid anomaly signals. Prevents adversarial signal injection (flooding with false anomalies to desensitise the estate).

6. MSG-004 — Defensive Leap

ASMP-MSG-004: Defensive Leap
  leap_token:     [u8;32] // SHA3-256(origin_fp || timestamp_ns || nonce)
  origin_node_id: [u8;16]
  threat_level:   u8      // 0x01=Elevated … 0x04=Critical
  target_scope:   u8      // 0xFF=Estate-wide
  epoch:          u64
  timestamp_ns:   u64
  hmac:           [u8;32]

7. MSG-005 — Node-Granted Protected Actions

Phase 1 — ATTEST_REQUEST (PME Node → Management Tool):
  { tee_quote: bytes, pme_version: [u8;8], mutation_epoch: u64,
    nonce: [u8;32], hmac: [u8;32] }

Phase 2 — ATTEST_RESPONSE (Management Tool → PME Node):
  { trusted: u8, trust_token: SHA3-256(tee_quote||nonce||epoch),
    expires_ns: u64,  // = now_ns + 1 mutation cycle duration (10–143µs)
    hmac: [u8;32] }

8. ProVerif Analysis Summary

Not proved: a zero-knowledge property (none was stated) and forward secrecy (the protocol does not provide it). See WP-07.

9. Interoperability Requirements

1. Implement all five message types with the wire formats specified above
2. Use SHA3-256 (Keccak) for all hash operations and HMAC-SHA3-256 for all MACs
3. Reject any message whose HMAC fails verification
4. Maintain a monotonically increasing cycle_seq per profile
5. Enforce MSG-005 trust_token TTL: reject tokens whose expires_ns < current timestamp