128 lines
4.4 KiB
Markdown
128 lines
4.4 KiB
Markdown
# IF.TTT Security Hardening — Public Summary (IF.ARMOUR crossover)
|
||
|
||
**Author:** InfraFabric Research
|
||
**Status:** Summary (safe to share)
|
||
**Updated:** 2025-12-29
|
||
**Version:** 1.3 (summary)
|
||
**Citation:** `if://doc/ifttt-security-hardening-summary/v1.3`
|
||
|
||
This is a **public summary** of the internal hardening proposal:
|
||
- Internal full paper: `if://doc/ifttt-security-hardening/v1.3`
|
||
- This summary intentionally omits operator details (hostnames, container IDs, internal network layout).
|
||
|
||
## What problem this solves (black/white)
|
||
|
||
IF.TTT’s job is to publish receipts that survive skepticism:
|
||
- A source artifact → `source_sha256`
|
||
- An output artifact → `output_sha256`
|
||
- A trace record binding them → `trace_id` + public `shareId`
|
||
- Optional offline bundles → `lightweight` / `standard` / `full`
|
||
|
||
Hardening is necessary because IF.TTT is exposed to adversarial pressure:
|
||
- spam and resource exhaustion
|
||
- scraping and tampering attempts
|
||
- epistemic attacks (“make the receipts look unreliable”)
|
||
- signer/key compromise attempts (the highest-value target)
|
||
|
||
Hardening does **not** mean “unhackable.” It means:
|
||
- failures are detected early
|
||
- damage is contained
|
||
- compromised components can be isolated
|
||
- receipts remain explainable and verifiable
|
||
|
||
## The hostile-world assumption (required)
|
||
|
||
Operate as if:
|
||
- clients are adversarial
|
||
- the network is hostile
|
||
- servers will eventually have unknown vulnerabilities
|
||
- the goal is to protect the **signing process** and preserve an auditable record
|
||
|
||
## IF.ARMOUR → IF.SECURITY.* (naming)
|
||
|
||
“IF.ARMOUR” is the research umbrella for adversarial hardening patterns.
|
||
|
||
In the product naming system, these patterns surface as:
|
||
- `IF.SECURITY.DETECT` — detect abuse/anomaly patterns
|
||
- `IF.SECURITY.CHECK` — validate inputs, policies, integrity
|
||
- `IF.SECURITY.WATCH` — liveness/drift checks + escalation rules
|
||
- `IF.SECURITY.TRAP` — honeypots/tarpits/deception
|
||
|
||
## Control themes (what gets hardened)
|
||
|
||
### 1) Economic defenses (rate limits + PoW)
|
||
|
||
Goal: make bulk abuse expensive while keeping normal users fast.
|
||
|
||
Mechanisms:
|
||
- per-route rate limiting on public surfaces
|
||
- “proof-of-work” challenges for suspicious upload paths (optional, adaptive)
|
||
|
||
### 2) Honey-traces (canary receipts)
|
||
|
||
Goal: detect scrapers and receipt poisoning attempts by publishing decoy shareIds and measuring interaction patterns.
|
||
|
||
Mechanisms:
|
||
- decoy receipts that look valid but are tagged internally
|
||
- automated triage when decoys are accessed at scale
|
||
|
||
### 3) Tarpits / time vampires
|
||
|
||
Goal: consume attacker resources (time, concurrency) while extracting behavioral signals.
|
||
|
||
Mechanisms:
|
||
- deliberate slow paths for suspicious clients (bounded)
|
||
- jitter and challenge escalation for repeated probing
|
||
|
||
### 4) Swarm-Lock + Purgatory Protocol (containment)
|
||
|
||
Goal: if a component is suspected compromised or desynchronized, **freeze** before poisoning receipts.
|
||
|
||
Mechanisms:
|
||
- liveness checks and quorum-based gating for critical state
|
||
- “lock” mode that halts signing/publishing
|
||
- “purgatory” mode that isolates and requires explicit rejoin validation
|
||
|
||
### 5) Backups and survivability (two realities)
|
||
|
||
Reality A (single-host prototype):
|
||
- local backups and snapshots are adequate for early-stage iteration
|
||
|
||
Reality B (portable production profile):
|
||
- tiered backups (hot/warm/cold)
|
||
- optional replication to a secondary host (or later to cloud object storage)
|
||
- recovery procedures documented as part of the trust model
|
||
|
||
### 6) Verifier supply-chain hardening
|
||
|
||
Goal: the offline verifier must be trusted.
|
||
|
||
Mechanisms:
|
||
- publish hashes for verifier artifacts
|
||
- optionally sign verifier releases
|
||
- keep “what is verified” vs “what is not” explicit in tool output
|
||
|
||
## What to expect (deployed vs planned)
|
||
|
||
Deployed (proof layer):
|
||
- public receipts + stable no-login aliases
|
||
- hash binding + signatures (including PQ receipts when available)
|
||
- offline verification path via triage bundles + verifier tooling
|
||
|
||
Planned (hardening layer):
|
||
- honey-traces and deception
|
||
- adaptive PoW + tarpits for abusive clients
|
||
- Swarm-Lock/Purgatory containment
|
||
- stronger backup tiers and survivability procedures
|
||
|
||
## Why this matters
|
||
|
||
Without hardening, public receipts can become a new kind of theater:
|
||
- visible, but easy to undermine
|
||
- impressive, but fragile under adversarial pressure
|
||
|
||
With hardening, IF.TTT becomes:
|
||
- boring to operate
|
||
- legible to reviewers
|
||
- resilient under skepticism and abuse
|
||
|