ChronoSeal Threat Model & Security Assumptions

ChronoSeal is a cost-raising session attestation layer. It makes API scraping and session replay attacks expensive by requiring continuous, stateful execution.

Security Objectives

The system aims to achieve the following cryptographic and protocol protections:

Reject replayed or out-of-order heartbeat payloads.
Reject heartbeats that do not maintain the exact server-issued synthetic gene mutation sequence.
Bind heartbeats to a browser-local Ed25519 session key.
Ensure basic HTTP clients (without JS/WASM engines) cannot pass validation.
Avoid detailed verification feedback via a silent failure model.
Ensure user privacy by avoiding long-term profiling or cross-site tracking.

Attacker Cost Model & Classification

We classify potential adversaries into four distinct capability tiers:

Tier 1: Commodity HTTP Clients

Examples: curl requests, Python requests, Go scrapers, or scripts without browser execution capabilities.

Status: Fully Protected. These clients cannot generate Ed25519 signatures, interpret the VM math challenges, or maintain the BLAKE3 hash-chain. They are rejected at the first check.

Tier 2: Basic Headless Browsers

Examples: Out-of-the-box Puppeteer, Playwright, or Selenium setups.

Status: Partially Protected. These engines can run JS and load the WASM runtime. However, the attacker must simulate plausible interaction paths, maintain state, and solve VM challenges. This imposes substantial CPU and memory overhead on the automation runner, rendering large-scale automated scraping expensive.

Tier 3: Stealth Automation

Examples: Patched browser binaries, custom Node.js scripts using mock variables, or WASM emulator state runners.

Status: Partially Protected. Attackers must implement the complete state progression model. The server-controlled Synthetic Gene Mutation Engine forces emulator scripts to execute matching dynamic programs. Silent rejection hides which validation failed, complicating debugging.

Tier 4: Distributed Browser Farms

Examples: Clusters of real browsers, custom input hardware simulators, or human-operated CAPTCHA solvers.

Status: Unprotected. ChronoSeal raises execution costs but cannot guarantee complete protection against real user machines. Additional application-level access gating is required.

Attack Vectors & Mitigations

1. Replay Attacks

Attack: Intercepting a successful client heartbeat and sending it again to keep a session alive.

Mitigation: The server checks if the request's prev_hash matches the stored last_hash. Since accepted heartbeats rotate the salt and advance the hash, a repeated payload is immediately discarded as stale. Step counts and timestamp drift bounds also block historical replays.

2. Signature Forgery

Attack: Generating heartbeats without possessing the session's private key.

Mitigation: All heartbeats are signed using the Ed25519 key generated locally in the WASM engine. The server validates the signature against the registered public key before processing.

3. Mutation Spoofing

Attack: Submitting fake gene commitments or bypassing mutation rounds.

Mitigation: The server keeps the authoring program of the pending mutation. It applies the program to a clone of the session's committed gene state and asserts that the client's submitted commitment matches, failing silently on divergence.

4. Feedback Oracle Probing

Attack: Eliciting detailed error reasons (e.g. "invalid signature", "limiter triggered") to reverse-engineer verification thresholds.

Mitigation: Heartbeat endpoints always return 200 OK with a standard status: ok JSON shape on failure. Accepted responses are distinguished only by containing next-state keys (next_salt, etc.).

Key Security Invariants

The system guarantees the following invariants to preserve attestation integrity:

Single Sequence: A session can have exactly one expected step at any time. Bifurcation is impossible.
VM Parity: Stack results must exactly match server re-execution of the VM opcodes.
Locking: Session changes use Compare-And-Swap (CAS) optimistic locking to prevent race conditions.

⚠️

v1.0.2 Hardening: We enforce strict CPU concurrency limits (1 to 256), DPR boundaries, aspect ratio validations, and an entropy event cap (max 500 events) to prevent server resource exhaustion attacks.