nx9-chronoseal-rs/docs/THREAT_MODEL.md

ChronoSeal Threat Model

ChronoSeal is a cost-raising cryptographic attestation daemon. It increases the burden on automated clients while preserving privacy, determinism, and operational transparency.

Purpose

ChronoSeal protects web resources by making browser automation and replay attacks more expensive and fragile. It is not intended to be a perfect bot blocker.

Protected Assets

Asset	Protection focus
Page content	Prevent automated scraping and replay of protected content
API responses	Reduce scripted access to sensitive endpoints
Server compute	Increase attacker resource costs
Session continuity	Enforce live session progression
Behavioral integrity	Validate plausible browser activity

Attacker Profiles

Level 1 — Commodity Scraper

• Tools: curl, requests, headless HTTP clients
• Capability: no WASM execution, no browser engine

ChronoSeal response:

• cannot initialize a session
• no session_id is produced
• content remains protected behind the attestation layer

Level 2 — Headless Browser Operator

• Tools: Playwright, Puppeteer, Selenium
• Capability: browser engine available, but automation is not indistinguishable from a real user

ChronoSeal response:

• mouse entropy and pause checks become active barriers
• hash chain continuity requires per-session state tracking
• synthetic heartbeats become expensive to maintain at scale

Level 3 — Stealth Automation

• Tools: browser stealth plugins, CDP patching, synthetic event injection
• Capability: can execute JavaScript and WASM, may spoof some browser signals

ChronoSeal response:

• signature, hash chain, and mutation commitment require correct WASM execution
• private key is generated per page load and never exposes raw key material
• silent rejection hides validation rules from attacker feedback

Level 4 — Sophisticated Operator

• Tools: real browser farms, hardware input devices, custom chain management
• Capability: high engineering investment and real device scale

ChronoSeal response:

• significantly increases operational cost and complexity
• forces a full protocol implementation rather than best-effort scraping
• is not designed to stop such adversaries completely

Attack Vectors and Mitigations

Replay Attack

Attack: resend a previously observed heartbeat.

Mitigations:

• timestamp window enforcement (±30 seconds)
• chained Blake3 hash continuity
• server-issued salt rotation
• mutation step progression

Signature Forgery

Attack: forge a heartbeat without the private key.

Mitigations:

• Ed25519 signature over the canonical payload
• private key generated and stored inside WASM memory only
• signature verification occurs on every heartbeat

Mutation Tampering

Attack: send an invalid or stale mutation commitment.

Mitigations:

• server recomputes the gene commitment from server-authored mutation orders
• heartbeat request includes mutation_step and gene_commitment
• mismatched commitment causes silent rejection

Session Hijacking

Attack: steal a valid session_id and reuse it.

Mitigations:

• session_id alone is insufficient
• attacker also needs current prev_hash and private key
• keypair is generated per browser session in WASM

Fingerprint Enumeration

Attack: probe the API with malformed requests to discover validation logic.

Mitigations:

• all invalid heartbeats return {"status":"ok"}
• no explicit error messages are exposed
• silent rejection removes oracle behavior

Limitations

ChronoSeal does not protect against:

• real users intentionally acting as bots
• server-side application vulnerabilities
• full browser farm operators with real input devices
• persistent fingerprinting or identity profiling
• pre-signed session payload reuse after a legitimate success if the attacker also has the current salt and key

Operational Security Notes

• Do not use RUST_LOG=debug in production; it may expose internal identifiers.
• Always serve ChronoSeal traffic over HTTPS.
• Use sqlite-in-memory for ephemeral sessions when persistence is not required.
• Use sqlite-disk or valkey when session state needs to survive restarts.

Disclosure

See SECURITY.md for the vulnerability disclosure policy.