danny/Infrafabric-POC-docs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(ifttt): receipt-first + hardening crossover

Browse source
This commit is contained in:
root 2025-12-29 13:07:00 +00:00
parent 26abcf8d48
commit 87503e65a4
2 changed files with 294 additions and 49 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

128
IF_TTT_SECURITY_HARDENING_SUMMARY_v1.3.md Normal file
View file

@ -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

215
IF_TTT_THE_SKELETON_OF_EVERYTHING_.md
View file

@ -8,12 +8,19 @@
**Author:** Danny Stocker, InfraFabric Research **Author:** Danny Stocker, InfraFabric Research
**Date:** December 2, 2025 **Date:** December 2, 2025
**Updated:** December 28, 2025 (Receipt-First Chronology + Public Receipts) **Updated:** December 29, 2025 (Receipt-First Chronology + Public Receipts + Hardening + Dev/Prod Profiles)
**Version:** 2.0 (Legal Voice Edition) **Version:** 2.1 (Legal Voice Edition)
**IF.citation:** `if://doc/ttt-skeleton-paper/v2.0` **IF.citation:** `if://doc/ttt-skeleton-paper/v2.1`
**Word Count:** ~15,000 words **Word Count:** ~15,000 words
**Status:** Production Documentation **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 ## Abstract
@ -40,7 +47,11 @@ That is not surveillance. That is the only foundation on which trustworthy AI ca
### Part I: Foundations ### Part I: Foundations
1. [The Origin: From Footnotes to Foundation](#1-the-origin-from-footnotes-to-foundation) 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) 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) 3. [The SIP Protocol Parallel: Telephony as Template](#3-the-sip-protocol-parallel-telephony-as-template)
### Part II: Infrastructure ### 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. 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) ### 1.4.1 The sequence (what happens, in order)
**Required steps:** **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): 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 - Dossier (rendered): https://infrafabric.io/static/dossier/6qRgcR01kw_qNo63Dbs_ob9n
- Trace (receipt): https://infrafabric.io/static/trace/6qRgcR01kw_qNo63Dbs_ob9n - Trace (receipt): https://infrafabric.io/static/trace/6qRgcR01kw_qNo63Dbs_ob9n
- Source (PDF): https://infrafabric.io/static/source/6153a5998fe103e69f6d5b6042fbe780476ff869a625fcf497fd1948b2944b7c.pdf - Source (PDF): https://infrafabric.io/static/source/6153a5998fe103e69f6d5b6042fbe780476ff869a625fcf497fd1948b2944b7c.pdf
Optional triage selector (bundle downloads + expected SHA256): 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 ### 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/<shareId>` 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. The Three Pillars: Traceable, Transparent, Trustworthy
## 2.1 Traceable: Every Claim Links to Evidence ## 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. **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):** **No-login share aliases (stable):**
- Single-link bundle (recommended): `https://infrafabric.io/static/pack/<shareId>.md` - Single-link bundle (HTML view):
- Marketing-safe excerpt: `https://infrafabric.io/static/marketing/<shareId>.md` - https://infrafabric.io/static/pack/<shareId>
- Review pack: `https://infrafabric.io/static/review/<shareId>.md` (alt: `https://infrafabric.io/static/review-pack/<shareId>.md`) - Single-link bundle (raw Markdown):
- Rendered dossier: `https://infrafabric.io/static/dossier/<shareId>` (download: `https://infrafabric.io/static/dossier/<shareId>/download`) - https://infrafabric.io/static/pack/<shareId>.md
- IF.TTT trace page (receipt): `https://infrafabric.io/static/trace/<shareId>` - Marketing-safe excerpt (HTML view):
- Source PDFs: `https://infrafabric.io/static/source/<sha256>.pdf` - https://infrafabric.io/static/marketing/<shareId>
- Marketing-safe excerpt (raw Markdown):
- https://infrafabric.io/static/marketing/<shareId>.md
- Review pack (HTML view):
- https://infrafabric.io/static/review/<shareId>
- https://infrafabric.io/static/review-pack/<shareId>
- Review pack (raw Markdown):
- https://infrafabric.io/static/review/<shareId>.md
- https://infrafabric.io/static/review-pack/<shareId>.md
- Rendered dossier:
- https://infrafabric.io/static/dossier/<shareId>
- Rendered dossier (download Markdown):
- https://infrafabric.io/static/dossier/<shareId>/download
- IF.TTT trace page (receipt):
- https://infrafabric.io/static/trace/<shareId>
- Source PDFs:
- https://infrafabric.io/static/source/<sha256>.pdf
**Sandbox fallback:** **Sandbox fallback:**
- If an evaluator’s environment blocks `red-team.*` hostnames, use: `https://infrafabric.io/r/<shareId>` - If an evaluator’s environment blocks `red-team.*` hostnames, use: `https://infrafabric.io/r/<shareId>`
@ -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`. 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` - Example triage selector (HTML view):
- Public verifier: `https://infrafabric.io/static/hosted/iftrace.py` - 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: **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 - Cached with 60-second TTL
- Rotatable with version tracking - 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:** **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) [^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 ```python
@dataclass @dataclass
class QuantumReadySignedMessage: class QuantumReadyReceipt:
# Classical Ed25519 (current) content_hash: str
signature_ed25519: str # Ed25519 signature (64 bytes) signature_ed25519: str
public_key_ed25519: str # Ed25519 public key (32 bytes) signer_pubkey_ed25519: str
signature_pq: Optional[str] = None
# Post-Quantum ML-DSA (FIPS 204) pq_algo: Optional[str] = None # "ML-DSA-87" (FIPS 204) or "Dilithium5"
signature_ml_dsa: Optional[str] # ML-DSA-65 signature (~3,309 bytes) pq_status: str = "classical-only" # "hybrid-fips204" | "hybrid-draft" | "classical-only"
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
``` ```
**Migration Timeline:** **Migration Timeline:**
@ -1190,9 +1307,9 @@ def verify_quantum_ready(message: QuantumReadySignedMessage) -> bool:
| ML-DSA-44 | 2,420 bytes | 38× | | ML-DSA-44 | 2,420 bytes | 38× |
| ML-DSA-65 | 3,309 bytes | 52× | | ML-DSA-65 | 3,309 bytes | 52× |
| ML-DSA-87 | 4,627 bytes | 72× | | 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.
--- ---