WINDI System › Föderation › Merkle Transparency Log

CT-STYLE RFC 6962 PHASE 3B APPEND-ONLY

WINDI Merkle Transparency Log

Öffentliche, append-only, kryptografische Transparenz für combined_root_hash Anker von WINDI-Knoten.

Zweck

Der WINDI Merkle Transparency Log bietet öffentliche, append-only, kryptografische Transparenz für combined_root_hash-Anker, die von WINDI-Knoten und/oder dem Hub emittiert werden.

Ermöglicht jedem Dritten die Verifizierung, dass:

ein bestimmter combined_root_hash veröffentlicht wurde
zu oder vor einem bestimmten Zeitpunkt
in einem append-only Log (mit Konsistenzbeweisen)
mit kompakten Verifikationsbeweisen (Inclusion Proofs)

Dieses Design folgt CT-Prinzipien (RFC 6962 Familie): Leaf-Hashing mit Präfix 0x00, Node-Hashing mit Präfix 0x01, periodische Signed Tree Heads (STH) signiert vom Log-Betreiber.

Terminologie

Begriff	Definition
`Leaf payload`	Kanonisches JSON, das einen Ankereintrag beschreibt (z.B. `combined_root_hash`, `node_id`, `ts`).
`Leaf hash`	`SHA256(0x00 \|\| canonical_json(leaf_payload))`
`Node hash`	`SHA256(0x01 \|\| left_hash \|\| right_hash)`
`Merkle root`	Root-Hash über `tree_size` Blätter.
`STH`	Signed Tree Head — signierte Aussage über (`tree_size`, `timestamp`, `root_hash`) vom Log-Betreiber.
`Inclusion proof`	Auditpfad, der beweist, dass ein Blatt in einem Baum der Größe `tree_size` enthalten ist.
`Consistency proof`	Beweis, dass ein neuerer Baum eine append-only-Erweiterung eines älteren Baums ist.

Bedrohungsmodell

Im Geltungsbereich

Nachträgliche Manipulation	Sobald ein Blatt in einem STH enthalten ist, kann ein Angreifer es nicht ändern/entfernen, ohne Beweise oder Konsistenz zu brechen.
Rückdatierung	Der Log bietet öffentliche Ordnung und einen signierten STH-Zeitstempel; die Veröffentlichung kann extern auditiert werden.
Stille Änderungen	Wenn ein System versucht, die Geschichte nach dem Anchoring umzuschreiben, kann der Beweis gegen den öffentlichen Log geprüft werden.
Split-View-Angriffe	Mit STH-Pinning und Konsistenzverifikation können Clients Log-Rollback oder divergente Ansichten erkennen. Nur wenn Monitors/Pinning verwendet werden.

Außerhalb des Geltungsbereichs

Unehrlicher Betreiber	Wenn der Betreiber einen Anker nie veröffentlicht, kann der Log nicht beweisen, dass er existierte.
Kompromittierter Signaturschlüssel	Ein kompromittierter Schlüssel kann betrügerische STHs signieren. Gegenmaßnahme: Schlüsselrotation, Keyset-Historie, Multi-Party-Monitoring.
Falsche Hash-Generierung	Der Log beweist nur die Veröffentlichung des Hash; die Korrektheit wird durch WINDI Bundle-Verifikation (WCAF-Kette, Signaturen) validiert.
Zeitgenauigkeit	Der Zeitstempel im STH wird vom Betreiber behauptet. Stärkere Garantien durch Verankerung an externem Zeitstempelsystem möglich.

Sicherheitseigenschaften

Was bewiesen wird

Gegeben: combined_root_hash, leaf_index, STH, Inclusion Proof und öffentlicher Schlüssel — kann ein Verifizierer beweisen:

Der combined_root_hash entspricht einem Blatt im Merkle-Baum der Größe tree_size.
Der Baum-Root für tree_size stimmt mit dem signierten STH überein.
Daher war der combined_root_hash spätestens zum STH.timestamp im Log enthalten.
Mit Konsistenzbeweisen: Der Log ist append-only über die Zeit (kein Rollback, kein Umschreiben).

Was NICHT bewiesen wird

Dass das zugrunde liegende Dokument gültig ist (→ WINDI/WCAF-Kette)
Dass der Aussteller vertrauenswürdig ist (→ Issuer Registry + Policy)
Dass der Zeitstempel global genau ist (nur dass der Betreiber ihn signiert hat)
Dass der Log global konsistent ist, wenn keine Monitors/Pinning existieren

Datenmodell

Leaf Payload (Canonical JSON)

{
  "combined_root_hash": "<64 hex>",
  "node_id": "node:<...>",     // optional but recommended
  "ts": "ISO-8601 timestamp"   // server time of log append
}

Leaf Hash

leaf_hash = SHA256(0x00 || canonical_json(leaf_payload))

Node Hash

node_hash = SHA256(0x01 || left_hash || right_hash)

API Endpoints

POST /anchors

Anker hinzufügen

Request:

{
  "combined_root_hash": "<64 hex>",
  "node_id": "node:<...>"      // optional
}

Response:

{
  "leaf_index": 42,
  "leaf_hash": "<hex>",
  "sth": { ... }               // optional
}

GET /sth

Aktueller Signed Tree Head

{
  "tree_size": 12345,
  "timestamp": "ISO-8601",
  "root_hash": "<hex>",
  "signature_alg": "Ed25519",
  "signature": "<base64>",
  "key_id": "hub-log-2026"
}

GET /lookup?combined_root_hash=<hex>

Suche nach combined_root_hash

{
  "found": true,
  "leaf_index": 42,
  "leaf_hash": "<hex>",
  "ts": "ISO-8601",
  "node_id": "node:..."
}

GET /proof/inclusion?leaf_index=<n>&tree_size=<m>

Inklusionsbeweis

{
  "leaf_index": 42,
  "tree_size": 12345,
  "audit_path": ["<hex>", "<hex>", ...]
}

GET /proof/consistency?old_size=<n>&new_size=<m>

Konsistenzbeweis

{
  "old_size": 8000,
  "new_size": 12345,
  "consistency_path": ["<hex>", "..."]
}

GET /verify/:combined_root_hash

Komfort-Verifikationsbundle

{
  "lookup": { ... },
  "sth": { ... },
  "inclusion_proof": { ... }
}

GET /pubkey

Öffentlicher Schlüssel

{
  "key_id": "hub-log-2026",
  "algorithm": "Ed25519",
  "public_key_pem": "-----BEGIN PUBLIC KEY-----..."
}

Verifikationsalgorithmen (Client)

STH-Signatur verifizieren

Input: sth, log_public_key

JSON {tree_size, timestamp, root_hash} kanonisieren
Ed25519-Signatur über kanonische JSON-Bytes verifizieren

Inklusionsbeweis verifizieren

Input: leaf_payload, audit_path, leaf_index, tree_size, sth.root_hash

leaf_hash = SHA256(0x00 || canonical_json(leaf_payload))
Mit audit_path gemäß leaf_index-Position kombinieren, um Root zu rekonstruieren
Rekonstruierten Root mit sth.root_hash vergleichen

Konsistenzbeweis verifizieren

Input: old_sth, new_sth, consistency_path

Verifizieren, dass Root von old_size als Präfix von new_size konsistent ist
Rollback/Split-View erkennen, wenn gepinnte STHs divergieren

STH Lifecycle

Emissionsrichtlinien

STH alle N Appends emittieren (z.B. 100)
STH alle T Minuten emittieren (z.B. 1 min)
STH auf Anfrage emittieren (weniger ideal)

Client-Pinning (empfohlen)

Clients sollten persistieren:

{
  "tree_size": 12345,
  "root_hash": "<hex>",
  "timestamp": "ISO-8601",
  "key_id": "hub-log-2026"
}

Bei nächster Verifikation: neuen STH abrufen → tree_size ≥ gepinnten → Konsistenzbeweis abrufen und verifizieren → bei Fehlschlag: Rollback/Split-View melden.

Betriebsempfehlungen

STHs in /sth/history für Monitoring veröffentlichen.
Mehrere key_id mit Rotation und keyset.json unterstützen (Phase 3B.2+).
Drittanbieter-Monitors ermutigen: STH periodisch abrufen, Konsistenzkette verifizieren, STHs zwischen Parteien gossipen.

COMPATIBILITY NOTE

WINDI-Kerncodes bleiben sprachneutral. Menschenlesbarer Inhalt gehört zu i18n-Paketen; der Transparency Log speichert nur kryptografische Anker.