138 lines
4.2 KiB
Markdown
138 lines
4.2 KiB
Markdown
# 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](../SECURITY.md) for the vulnerability disclosure policy.
|