Seminar KERI – Witnesses, Watchers und verteilte Validierung

Witnesses ersetzen keine Controller und stimmen nicht über fachliche Wahrheit ab. Sie bestätigen den beobachteten Eventzustand eines AID und erhöhen Verfügbarkeit sowie Nachweisbarkeit. Watchers ergänzen dieses Modell durch unabhängige Beobachtung und Konflikterkennung.

Inhaltsübersicht

• Seminarprofil
• Zielgruppe
• Lernziele
• Seminarinhalte
• Praxisanteile
• Voraussetzungen

Seminarprofil

Der Kurs analysiert Topologien, Schwellen und Fehlerszenarien. Teilnehmer dimensionieren Witness-Pools, prüfen Receipts, erkennen Duplicity und entwerfen Monitoring sowie Betriebsprozesse.

Zielgruppe

KERI-Architekten und Entwickler, Betreiber von Witness- und Watcher-Infrastruktur, Security Operations, Auditoren und Plattformverantwortliche.

Lernziele

• Witness- und Watcher-Rollen korrekt abgrenzen
• Receipts und KERLs gegen Schwellenregeln validieren
• verfügbare und resiliente Witness-Topologien entwerfen
• Duplicity und inkonsistente Event-Sichten erkennen
• Monitoring, Incident Handling und Service Levels definieren

Seminarinhalte

Schritt 1: Direkten und indirekten Modus unterscheiden

Die direkte Gegenparteiprüfung wird vom indirekten, durch Witness-Receipts unterstützten Modus abgegrenzt. Es wird geklärt, welche zusätzliche Aussage Receipts liefern und welche nicht.

• Controller-Signatur und Witness-Receipt trennen
• Verfügbarkeit von Wahrheit unterscheiden
• Verifier-Verantwortung erhalten

Schritt 2: Witness-Pool und Schwellen planen

Anzahl, Betreiberdiversität, geografische Verteilung, Netzpfade und Schwellen werden nach Bedrohungsmodell dimensioniert. Mehr Witnesses sind nicht automatisch sicherer, wenn Betreiber- oder Infrastrukturabhängigkeiten gleich bleiben.

• Fehler- und Angriffstoleranz berechnen
• gemeinsame Ausfallursachen erkennen
• Rotation des Pools vorbereiten

Schritt 3: Receipts und KERLs validieren

Controller-Events, Witness-Receipts und veröffentlichte KERLs werden zusammengeführt. Die Prüflogik berücksichtigt Reihenfolge, Threshold, Event-Digest und aktuelle Witness-Konfiguration.

• Receipt an Event binden
• veraltete Witness-Sets erkennen
• fehlende und widersprüchliche Receipts behandeln

Schritt 4: Watcher und Discovery einsetzen

Watcher beobachten Event-Historien und können Duplicity-Evidenz liefern. Discovery und Endpoint-Auflösung werden so gestaltet, dass der Verifier nicht blind einer einzelnen Quelle folgt.

• unabhängige Beobachtung organisieren
• OOBI- und Endpoint-Daten prüfen
• mehrere Sichten konsolidieren

Schritt 5: Duplicity und Partitionen analysieren

Netzpartition, Verzögerung, Datenverlust und absichtliche doppelte Ereignisse werden voneinander unterschieden. Die Reaktion reicht von erneuter Abfrage bis zur Quarantäne des AID.

• Konfliktkriterien definieren
• Evidenz manipulationsarm sichern
• automatische und manuelle Eskalation trennen

Schritt 6: Betrieb und Monitoring aufbauen

Latenz, Receipt-Quote, Event-Rückstand, Datenbankzustand, Zertifikate beziehungsweise Transport, Ressourcenverbrauch und Erreichbarkeit werden überwacht. Wartung darf die geforderte Schwelle nicht unbemerkt unterschreiten.

• SLOs und Alarmierung definieren
• Rolling Maintenance planen
• Backup, Restore und Replay testen

Praxisanteile

• Witness-Schwellen für mehrere Bedrohungsmodelle berechnen
• Receipt- und KERL-Daten validieren
• Partition und Duplicity auseinanderhalten
• Monitoring- und Betriebscheckliste für einen Witness-Pool erstellen

Voraussetzungen

KERI-Grundlagen, Key Event Logs, Thresholds und digitale Signaturen. Netzwerk- und Betriebskenntnisse sind hilfreich.