diff --git a/IF_TTT_SECURITY_HARDENING_SUMMARY_v1.3.md b/IF_TTT_SECURITY_HARDENING_SUMMARY_v1.3.md new file mode 100644 index 0000000..96477a6 --- /dev/null +++ b/IF_TTT_SECURITY_HARDENING_SUMMARY_v1.3.md @@ -0,0 +1,128 @@ +# 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 + diff --git a/IF_TTT_THE_SKELETON_OF_EVERYTHING_.md b/IF_TTT_THE_SKELETON_OF_EVERYTHING_.md index caf39b3..3472a57 100644 --- a/IF_TTT_THE_SKELETON_OF_EVERYTHING_.md +++ b/IF_TTT_THE_SKELETON_OF_EVERYTHING_.md @@ -8,12 +8,19 @@ **Author:** Danny Stocker, InfraFabric Research **Date:** December 2, 2025 -**Updated:** December 28, 2025 (Receipt-First Chronology + Public Receipts) -**Version:** 2.0 (Legal Voice Edition) -**IF.citation:** `if://doc/ttt-skeleton-paper/v2.0` +**Updated:** December 29, 2025 (Receipt-First Chronology + Public Receipts + Hardening + Dev/Prod Profiles) +**Version:** 2.1 (Legal Voice Edition) +**IF.citation:** `if://doc/ttt-skeleton-paper/v2.1` **Word Count:** ~15,000 words **Status:** Production Documentation +**Public receipt for this paper (no login):** +- Trace: https://infrafabric.io/static/trace/kqUwV9Zyt5LApuPs3dBR6WwO +- Pack (HTML): https://infrafabric.io/static/pack/kqUwV9Zyt5LApuPs3dBR6WwO +- Pack (raw Markdown): https://infrafabric.io/static/pack/kqUwV9Zyt5LApuPs3dBR6WwO.md + +Note: hashes are published on the trace page. We do not inline a “self-hash” here to avoid self-referential hash loops. + --- ## Abstract @@ -40,7 +47,11 @@ That is not surveillance. That is the only foundation on which trustworthy AI ca ### Part I: Foundations 1. [The Origin: From Footnotes to Foundation](#1-the-origin-from-footnotes-to-foundation) + - [The IF.TTT Lifecycle (Chronological, Receipt-First)](#14-the-ifttt-lifecycle-chronological-receipt-first) + - [Two Realities: Single-Host Prototype vs Portable Production](#15-two-realities-single-host-prototype-vs-portable-production) + - [Hardening the Trust Skeleton: IF.ARMOUR → IF.SECURITY.*](#16-hardening-the-trust-skeleton-ifarmour--ifsecurity) 2. [The Three Pillars: Traceable, Transparent, Trustworthy](#2-the-three-pillars-traceable-transparent-trustworthy) + - [Public Receipts: No-Login Share Surface + Triage Bundles](#211-public-receipts-no-login-share-surface--triage-bundles) 3. [The SIP Protocol Parallel: Telephony as Template](#3-the-sip-protocol-parallel-telephony-as-template) ### Part II: Infrastructure @@ -132,6 +143,22 @@ The rest of this paper explains *why* IF.TTT works (pillars, protocols, infrastr Below is the chronological chain-of-custody path that turns a document, decision, or output into something a skeptical reader can verify without credentials. +### 1.4.0 What IF.TTT proves (and what it does not) + +IF.TTT is designed to be black/white. If we can’t prove a property, we don’t imply it. + +**IF.TTT proves (when the receipts verify):** +- The published output bytes match the `output_sha256` shown on the trace page. +- The published source bytes match the `source_sha256` shown on the trace page. +- A trace record exists that binds those two hashes to a `trace_id` and a public `shareId`. +- When signatures are present, the receipt was signed by the registry key (and can be validated using the verifier tooling). + +**IF.TTT does not prove (and does not claim to):** +- That the source document is “true” or correct; only that it is the source that was used. +- That the output’s interpretation is correct; only that the output is the one that was published. +- That a vendor claim is valid; only that the claim exists in the source (and can be located and discussed). +- That your organization is compliant; only that you can produce verifiable receipts that support audits. + ### 1.4.1 The sequence (what happens, in order) **Required steps:** @@ -162,14 +189,23 @@ If IF.TTT is real, a skeptical reader should be able to “taste it” immediate Example share surface (no login): -- Pack (single link): https://infrafabric.io/static/pack/6qRgcR01kw_qNo63Dbs_ob9n.md +- Pack (HTML view): https://infrafabric.io/static/pack/6qRgcR01kw_qNo63Dbs_ob9n +- Pack (raw Markdown): https://infrafabric.io/static/pack/6qRgcR01kw_qNo63Dbs_ob9n.md - Dossier (rendered): https://infrafabric.io/static/dossier/6qRgcR01kw_qNo63Dbs_ob9n - Trace (receipt): https://infrafabric.io/static/trace/6qRgcR01kw_qNo63Dbs_ob9n - Source (PDF): https://infrafabric.io/static/source/6153a5998fe103e69f6d5b6042fbe780476ff869a625fcf497fd1948b2944b7c.pdf Optional triage selector (bundle downloads + expected SHA256): -- https://infrafabric.io/static/hosted/review/trace-bundles/d70ed99a/index.md +- https://infrafabric.io/static/hosted/review/trace-bundles/b6547c03/index.html +- https://infrafabric.io/static/hosted/review/trace-bundles/b6547c03/index.md + +Offline verifier (no login; HTML + raw): + +- https://infrafabric.io/static/hosted/iftrace.html +- https://infrafabric.io/static/hosted/iftrace.py + +Note (practical): some automated reviewer environments can fetch the HTML pages but reject binary downloads (`.tar.gz`). In those cases, use the HTML receipts for reading and verify bundles locally via a normal shell/browser. ### 1.4.3 Why this matters @@ -179,6 +215,79 @@ The “trace” is not a closing paragraph. It is the start of trust: a chain-of --- +## 1.5 Two Realities: Single-Host Prototype vs Portable Production + +IF.TTT must describe two deployment realities clearly. Mixing them creates “trust theater”: claims that sound right but don’t match what’s actually deployed. + +### 1.5.1 Reality A (today): single-host prototype, local-first + +What exists today (black/white): +- A single-host deployment can publish public receipts (`/static/*`) and enable offline verification (triage bundles + `iftrace.py`). +- The architecture is split into separable roles (edge/static serving, application layer, internal registry) so components can be moved without changing the receipt surface. + +What this does **not** claim: +- Multi-region availability. +- Compliance guarantees. +- Immunity to compromise of the host itself. + +Practical shape (portable components): +- **Edge/static**: terminates TLS and serves the public receipt surface (`/static/*`). +- **Application layer**: generates packs/dossiers/review bundles and calls the registry for signing. +- **Registry**: signs receipts and records audit entries; treats keys as first-class assets. +- **Storage**: may store only hashes (default) or optionally store source/bundle bytes (configurable). + +### 1.5.2 Reality B (portable): production profile, infrastructure-agnostic + +The production profile is the same system, with different failure domains: +- The receipt surface stays stable; only the origin infrastructure changes. +- Core state moves to explicit data stores (registry + audit log + optional object storage for source files and bundles). +- Keys are treated as first-class assets (rotation, least privilege, backup strategy), because “the ledger is only as trustworthy as the signer.” + +Portable deployment principle: +- The application layer is not coupled to specific hardware. The same units can run as containers on a single host today and be moved to cloud infrastructure later without changing the public receipt surface. + +### 1.5.3 Invariants (must not change when moving environments) + +- Public receipts: `https://infrafabric.io/static/trace/` remains the “receipt surface.” +- Verifiability: anyone can hash artifacts and compare to the trace. +- Optional offline receipts: triage bundles can be verified without internal credentials. + +--- + +## 1.6 Hardening the Trust Skeleton: IF.ARMOUR → IF.SECURITY.* + +IF.TTT is a governance skeleton. It still needs an application-layer security posture. + +### 1.6.1 Hostile-world assumption (explicit) + +- Treat every interaction as occurring in a potentially compromised environment (operators, admins, clients, and infrastructure). +- Treat uploads and verification requests as adversarial inputs. +- Treat the verifier (`iftrace.py`) as a supply-chain surface. +- Treat signing keys and key material as the primary target (the ledger is only as trustworthy as the signer). + +### 1.6.2 Naming (avoid drift) + +- “IF.ARMOUR” is the research umbrella for adversarial hardening patterns. +- In the InfraFabric naming system, the security layer surfaces as `IF.SECURITY.*`: + - `IF.SECURITY.DETECT` (monitoring, anomaly detection) + - `IF.SECURITY.CHECK` (validation, policy enforcement, integrity checks) + - `IF.SECURITY.WATCH` (liveness, drift, health checks, escalation) + - `IF.SECURITY.TRAP` (honeypots, tarpits, deception) + +### 1.6.3 What’s deployed vs what’s proposed (black/white) + +- Deployed: public receipts, offline verifier, and trace integrity checks (hash binding + signatures) — the “proof layer.” +- Proposed (hardening roadmap): additional controls described in `if://doc/ifttt-security-hardening/v1.3`, including: + - Honey-trace / canary endpoints to detect scraping and “receipt poisoning”. + - Resource exhaustion / tarpitting (economic defense) for abusive clients. + - Swarm-Lock + Purgatory Protocol (freeze + isolate suspected compromise before it contaminates receipts). + - Tiered backups and replication paths for survivability under zero-day compromise. + - Supply-chain hardening for public verifier distribution. + - Public summary (safe to share): `IF_TTT_SECURITY_HARDENING_SUMMARY_v1.3.md` + +The core rule is simple: +> A receipt that cannot survive contact with adversaries becomes a new kind of theater. + # 2. The Three Pillars: Traceable, Transparent, Trustworthy ## 2.1 Traceable: Every Claim Links to Evidence @@ -205,12 +314,28 @@ IF.TTT is not only an internal `if://` scheme. It also has a **public receipt su **Where this fits in the lifecycle:** this section is the detailed spec for steps **4–7** in §1.4 (public receipts + optional triage bundles). It is not a bolt-on; it is the external interface of the Traceable pillar. **No-login share aliases (stable):** -- Single-link bundle (recommended): `https://infrafabric.io/static/pack/.md` -- Marketing-safe excerpt: `https://infrafabric.io/static/marketing/.md` -- Review pack: `https://infrafabric.io/static/review/.md` (alt: `https://infrafabric.io/static/review-pack/.md`) -- Rendered dossier: `https://infrafabric.io/static/dossier/` (download: `https://infrafabric.io/static/dossier//download`) -- IF.TTT trace page (receipt): `https://infrafabric.io/static/trace/` -- Source PDFs: `https://infrafabric.io/static/source/.pdf` +- Single-link bundle (HTML view): + - https://infrafabric.io/static/pack/ +- Single-link bundle (raw Markdown): + - https://infrafabric.io/static/pack/.md +- Marketing-safe excerpt (HTML view): + - https://infrafabric.io/static/marketing/ +- Marketing-safe excerpt (raw Markdown): + - https://infrafabric.io/static/marketing/.md +- Review pack (HTML view): + - https://infrafabric.io/static/review/ + - https://infrafabric.io/static/review-pack/ +- Review pack (raw Markdown): + - https://infrafabric.io/static/review/.md + - https://infrafabric.io/static/review-pack/.md +- Rendered dossier: + - https://infrafabric.io/static/dossier/ +- Rendered dossier (download Markdown): + - https://infrafabric.io/static/dossier//download +- IF.TTT trace page (receipt): + - https://infrafabric.io/static/trace/ +- Source PDFs: + - https://infrafabric.io/static/source/.pdf **Sandbox fallback:** - If an evaluator’s environment blocks `red-team.*` hostnames, use: `https://infrafabric.io/r/` @@ -223,8 +348,14 @@ When a dossier needs a stronger “cryptographic receipt”, IF.TTT can publish Each bundle ships with a manifest and can be verified offline using `iftrace.py`. -- Example triage selector (downloads + expected SHA256): `https://infrafabric.io/static/hosted/review/trace-bundles/d70ed99a/index.md` -- Public verifier: `https://infrafabric.io/static/hosted/iftrace.py` +- Example triage selector (HTML view): + - https://infrafabric.io/static/hosted/review/trace-bundles/b6547c03/index.html +- Example triage selector (raw Markdown): + - https://infrafabric.io/static/hosted/review/trace-bundles/b6547c03/index.md +- Public verifier (HTML view): + - https://infrafabric.io/static/hosted/iftrace.html +- Public verifier (raw Python): + - https://infrafabric.io/static/hosted/iftrace.py **Implementation:** Every IF.TTT-compliant output includes a citation block: @@ -1120,7 +1251,7 @@ Any failure = message rejected. No exceptions. - Cached with 60-second TTL - Rotatable with version tracking -## 9.4 Post-Quantum Cryptography: Future-Proofing IF.TTT +## 9.4 Post-Quantum Cryptography: Future-Proofing IF.TTT (and why we say “Quantum Ready”) **The Quantum Threat:** @@ -1136,42 +1267,28 @@ Ed25519 is vulnerable to Shor's algorithm on a sufficiently powerful quantum com [^pq1]: [NIST Post-Quantum Cryptography Standards](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards) -**IF.TTT Quantum-Ready Schema Extension:** +**What “Quantum Ready” means (black/white):** + +- A **VERIFIED** trace is one where the public artifacts hash to the values shown on the trace page (and, when signatures are present, the classical signature verifies). +- A **QUANTUM READY** trace is one where an additional post-quantum receipt exists *and* can be verified using PQ tooling. + +This is intentionally modest language: “Quantum Ready” means “a PQ receipt exists,” not “the whole world is quantum-safe.” + +**IF.TTT Quantum-Ready receipt shape (hybrid signatures):** + +- Classical signature: Ed25519 +- Post-quantum signature: ML-DSA-87 (FIPS 204) when available (fallback: Dilithium5) +- PQ payload pattern (deterministic): `content_hash + signature_ed25519` ```python @dataclass -class QuantumReadySignedMessage: - # Classical Ed25519 (current) - signature_ed25519: str # Ed25519 signature (64 bytes) - public_key_ed25519: str # Ed25519 public key (32 bytes) - - # Post-Quantum ML-DSA (FIPS 204) - signature_ml_dsa: Optional[str] # ML-DSA-65 signature (~3,309 bytes) - public_key_ml_dsa: Optional[str] # ML-DSA-65 public key (~1,952 bytes) - - # Hybrid verification flag - quantum_ready: bool = False # True when both signatures present - migration_date: Optional[str] # When PQ signatures become mandatory -``` - -**Hybrid Verification Strategy:** - -```python -def verify_quantum_ready(message: QuantumReadySignedMessage) -> bool: - """Verify both classical and post-quantum signatures.""" - - # Phase 1 (Current): Ed25519 only - ed25519_valid = verify_ed25519(message.signature_ed25519, message.payload) - - # Phase 2 (Transition): Ed25519 + ML-DSA - if message.quantum_ready and message.signature_ml_dsa: - ml_dsa_valid = verify_ml_dsa(message.signature_ml_dsa, message.payload) - return ed25519_valid and ml_dsa_valid - - # Phase 3 (Post-CRQC): ML-DSA only - # (Activated when quantum threat becomes real) - - return ed25519_valid +class QuantumReadyReceipt: + content_hash: str + signature_ed25519: str + signer_pubkey_ed25519: str + signature_pq: Optional[str] = None + pq_algo: Optional[str] = None # "ML-DSA-87" (FIPS 204) or "Dilithium5" + pq_status: str = "classical-only" # "hybrid-fips204" | "hybrid-draft" | "classical-only" ``` **Migration Timeline:** @@ -1190,9 +1307,9 @@ def verify_quantum_ready(message: QuantumReadySignedMessage) -> bool: | ML-DSA-44 | 2,420 bytes | 38× | | ML-DSA-65 | 3,309 bytes | 52× | | ML-DSA-87 | 4,627 bytes | 72× | -| Hybrid (Ed25519 + ML-DSA-65) | 3,373 bytes | 53× | +| Hybrid (Ed25519 + ML-DSA-87) | 4,691 bytes | 73× | -The storage overhead is significant but acceptable for audit trails. IF.TTT schemas include the `quantum_ready` field now to enable seamless migration later. +The storage overhead is significant but acceptable for audit trails. IF.TTT receipts include explicit PQ metadata (`pq_status`, `pq_algo`) so public traces can be honest about what exists and what was verified. ---