Zusammenfassung

  • Die aktuelle Key-Transparency-Architektur beschreibt, dass alle Anfragen und Beweise eines Nutzers gültig sein können, obwohl andere Nutzer eine unvereinbare Sicht erhalten. Konsistenz hält den Client auf einem Zweig; sie zeigt ihm nicht automatisch den anderen.
  • Zur Entdeckung braucht es einen eigenständigen Vergleich: einen nicht kolludierenden Auditor oder Manager, einen anonymen Zugriff oder Austausch zwischen Peers. Jede Variante verlagert Vertrauen, Datenschutz, Zustand und Betriebsverantwortung.

Ein stiller Fehler kann vollkommen konsistent aussehen

Der Einstieg ist ein konstruiertes Betriebsszenario, kein Bericht über einen bekannten Angriff. Er trennt zwei Aussagen. „Diese Antwort setzt meine bisherige Geschichte korrekt fort“ lässt sich lokal prüfen. „Alle Teilnehmer sehen dieselbe Geschichte“ setzt eine Beobachtung jenseits des eigenen Kanals voraus.

draft-ietf-keytrans-architecture-09 macht genau diese Trennung sichtbar. Der IETF Datatracker führt das Dokument als aktiven Internet-Draft. Revision 09 erschien am 29. Juni 2026, der Vorgang wurde am 9. Juli aktualisiert. Der WG-Status lautet Submitted to IESG for Publication, der IESG-Status Publication Requested; angestrebt ist Informational, ein Telechat-Termin fehlt. Der Text ist weder genehmigter RFC noch endgültig.

Das Grundproblem besteht schon vor dem Log. Ende-zu-Ende-Verschlüsselung schützt Nachrichteninhalte, lässt aber häufig den Dienstbetreiber das Verzeichnis kontrollieren, das eine sichtbare Identität an einen öffentlichen Schlüssel bindet. Tauscht der Betreiber den Schlüssel aus, kann die Verbindung weiterhin verschlüsselt sein, obwohl die authentisierte Gegenstelle verändert wurde.

Key Transparency schreibt diese Bindungen in ein kryptografisch geschütztes Append-only-Log. Search liefert Wert und Beweis, Update fügt eine Version hinzu, Monitor prüft wiederkehrend, ob frühere Werte erhalten blieben und eigene Labels unerwartet verändert wurden. Die gemeinsame Schicht koordiniert eine überprüfbare Historie. Sie ersetzt nicht die gesamte Autorität der Anwendung.

Ein bösartiges Log kann verschiedenen Nutzern verschiedene Historien zeigen. Jeder Client verlangt, dass die nächste Antwort zu seinem gespeicherten Baumkopf passt. Er bleibt damit auf einer linearisierbaren Sicht und verwirft später Widersprüche. Ein Fork lässt sich nicht geräuschlos wieder zusammenführen; er hinterlässt dauerhafte Anknüpfungspunkte. Solange die Gruppen ihre Baumköpfe nicht vergleichen, können jedoch beide Seiten ausschließlich gültige Ergebnisse sehen.

Der Vergleich ist eine eigene Sicherheitsleistung

Der Entwurf nennt drei Wege über die Trennlinie: vertrauenswürdige Dritte, anonyme Kommunikation mit dem Log und Peer-to-Peer-Kommunikation. Sie bringen eine Sicht ein, die nicht aus dem möglicherweise isolierten authentisierten Kanal stammt.

Bei Drittanbieter-Audits verfolgt ein Auditor das Append-only-Wachstum und signiert einen aktuellen Baumkopf. Die Signatur wird mit Antworten ausgeliefert. Das Modell setzt voraus, dass Auditor und Log nicht gemeinsam einen Fork signieren. Zudem arbeitet der Auditor typischerweise asynchron. Seine Signatur kann hinter dem neuesten Stand liegen. Die maximal zulässige Verzögerung ist eine Konfigurations- und Führungsentscheidung, keine feste Eigenschaft des Verfahrens.

Beim Drittanbieter-Management speichert und betreibt der Manager den größten Teil des Logs. Der Kommunikationsdienst prüft Zugriffsrechte und authentisiert neue Label-Versionen. Nicht-Kollusion bleibt Voraussetzung, und der Betreiber muss Forks des Managers selbst erkennen können. Mehrere unabhängige Dritte können Schwellenwertsignaturen bilden; trotzdem brauchen Mitgliedschaft, Schwelle, Schlüsselwechsel und Ersatz klare Zuständigkeiten.

Contact Monitoring verzichtet auf einen ständigen institutionellen Zeugen. Label-Eigentümer prüfen regelmäßig ihren aktuellen Wert. Kontakte, die einen sehr neuen Wert gesehen haben, kommen später zurück und kontrollieren, ob dieser vor der Wahrnehmung durch den Eigentümer entfernt wurde. Zusätzlich muss die Anwendung anonyme oder direkte Vergleiche zur Fork-Erkennung durchführen. Aufwand und Vertrauen wandern zu Geräten, Onlinezeiten und dem tatsächlichen sozialen Graphen.

Ein anonymer Abruf holt einen Baumkopf über einen Kanal, der den Fragenden nicht identifiziert, und vergleicht ihn mit der authentisierten Sicht. Das Log kann bei mehreren Forks nicht sicher wissen, welchen es zurückgeben soll. Wiederholung steigert die Entdeckungswahrscheinlichkeit, solange der Kanal wirklich anonym und nicht selektiv blockierbar ist.

Peer-Gossip benötigt nur kompakte Daten und kann über einen bandbreitenarmen Außenkanal, sogar per QR-Code, laufen. Entscheidend ist jedoch ein zusammenhängender Zeugen-Graph. Treffen zwei Gemeinschaften nie aufeinander, kann das Log sie auf getrennten Zweigen halten. Ein interoperables Nachrichtenformat schafft noch keine gesellschaftliche Verbindung.

Wiederherstellung ohne Gedächtnis schwächt die Aussage

Der Client fordert Kontinuität, weil er einen früheren Prüfpunkt behält. Geht dieser Zustand verloren, kann ein Ersatzverlauf angeboten werden, ohne mit einer gespeicherten Erinnerung zu kollidieren. Der Entwurf behandelt Zustandsverlust deshalb ausdrücklich als Sicherheitsrisiko.

Bei Contact Monitoring sind frische Werte innerhalb des Überwachungsfensters und unzureichend verbreitete Log-Bereiche besonders betroffen. Bei Drittanbieter-Audits entsteht eine empfindliche Zeitspanne durch die akzeptierte Verzögerung des Auditors. Flüchtige Web-Sitzungen, Gerätewechsel, unvollständige Sicherungen oder erzwungene Rücksetzungen verändern damit die Garantie, obwohl der kryptografische Prüfer unverändert bleibt.

Eine Kontowiederherstellung sollte festlegen, was fortbesteht: letzter akzeptierter Baumkopf, offene Monitor-Pflichten, Zeugensignaturen, Zeitpunkte der Vergleiche und Identität der Log-Konfiguration. Ist Kontinuität nicht beweisbar, muss die Lücke dokumentiert und einer lokalen Wiederherstellungsentscheidung zugeführt werden. Ein bekanntes Gerät darf nicht stillschweigend zum geschichtslosen Erstnutzer werden.

Auch die Entdeckungsfrist besteht aus mehreren Größen: maximal akzeptiertes Antwortalter, Reasonable Monitoring Window, reale Häufigkeit der Hintergrundprüfung, Takt anonymer Abrufe oder von Gossip, Auditor-Verzug und Wirksamkeit der Manager-Kontrolle. Nutzer müssen eventuell lange genug online bleiben. „In begrenzter Zeit erkennbar“ ist nur dann eine Betriebsaussage, wenn jede Grenze gemessen wird und einen Eigentümer hat.

Die Überwachung muss daher Beweis- und Vergleichserfolg trennen. Zu erfassen sind Alter des Geräte-Checkpoints, Alter externer Aussagen, gescheiterte Vergleiche, Monitor-Rückstände, Wiederherstellungen, Ablehnung veralteter Antworten sowie Zeit zwischen Konflikt und lokaler Maßnahme. Eine vollständig grüne Beweisquote kann innerhalb eines privaten Forks bestehen.

Transparenz hebt Zugriffsregeln nicht auf

Key Transparency lässt Transport und weitgehend auch Autorisierung bei der Anwendung. Sie darf Anmeldung verlangen, Suchrechte auf Kontakte begrenzen, Raten beschränken und fremde Änderungen blockieren. Das Log belegt die Ausführung einer erlaubten Operation; es entscheidet nicht, wer sie ausführen darf.

Contact Monitoring zeigt eine zeitliche Ausnahme. Wer gestern ein Label suchen durfte, kann heute das Recht verloren haben, muss aber später noch Monitor ausführen, um die damals entstandene Prüfpflicht abzuschließen. Der Entwurf verlangt, diese Prüfung weiter zu ermöglichen. Eine pauschale Sperre könnte genau den Kanal beseitigen, der ein nachträgliches Verbergen zeigt.

Die Datenschutzflächen unterscheiden sich. Ein Auditor sieht Anzahl, Reihenfolge und ungefähre Zeit der Änderungen, nicht jedoch Klartext von Labels und Werten. Ein Manager kennt meist Labels, Werte, Historie und Abfragemuster wie der Betreiber. Ein anonymer Kanal muss Metadaten schützen. Peer-Austausch vermeidet einen zentralen Beobachter, kann aber Begegnungen offenbaren. Einen informationslosen Zeugen gibt es nicht.

Ein unabhängiges Arrangement braucht deshalb konkrete Regeln: beobachtbare Daten, Aufbewahrung, Korrelationsmöglichkeiten, signierter Gegenstand, Schlüsselverteilung, Verzögerungsgrenze und Austauschverfahren. Unabhängigkeit darf nicht nur auf dem Organigramm stehen.

Bei der Migration den alten Beweis nicht abschalten

Clients sollen mehrere Logs verarbeiten können, weil ein Wechsel ein wichtiger Wiederherstellungsweg nach Log-Ausfall ist. Bei schrittweiser Migration muss das alte Log lange genug verfügbar bleiben, damit auch selten aktive Nutzer ihre Überwachung abschließen. Ein vorzeitiges Abschalten nimmt ihnen die Möglichkeit, bestimmtes früheres Fehlverhalten aufzudecken.

Bei einem sofortigen Wechsel müssen endgültige Größe und Root-Hash des alten Logs über einen vertrauenswürdigen Kanal verteilt werden. Alle brauchen denselben Abschluss-Checkpoint. In föderierten Diensten ist zusätzlich eine einheitliche Regel nötig, welches Log für welche Identität zuständig ist. Sonst entsteht die Trennung bereits bei der Auflösung der Autorität.

Pruning erfordert ebenfalls Trennung. Serialisierte Nutzerdaten können ablaufen oder dauerhaft unzugänglich werden, während kryptografische Bestandteile weiterhin für Beweise des verbleibenden Zustands nötig sind. Datenschutzlöschung und Beweisfortbestand müssen koordiniert, dürfen aber nicht gleichgesetzt werden.

Ein erkannter Fork liefert Beweis, keinen Universalbefehl

Sobald zwei überprüfbare Sichten widersprechen, kann ein Nutzer nicht abstreitbare Belege für das Fehlverhalten des Logs sichern. Was folgt, entscheidet die Anwendung: warnen, Schlüsselwechsel einfrieren, Nachrichten zurückhalten, außerhalb des Dienstes prüfen, ein Gerät isolieren oder einen begrenzten Betrieb während der Untersuchung aufrechterhalten.

Fehlalarm, Identitätsmissbrauch und Ausfall haben je nach Umfeld unterschiedliche Kosten. Die gemeinsame Mechanik soll den Konflikt sichtbar und transportierbar machen. Die konkrete Folge bleibt bei den Akteuren, die Kontext kennen und Schaden tragen; sie muss dokumentiert, überprüfbar und umkehrbar sein.

Eine Einführung ist nicht bewiesen, weil ein Laborversuch die Baumstruktur validiert. Zu prüfen ist, ob unabhängige Vergleiche tatsächlich laufen, Zustand normale Wiederherstellung überlebt, alte Evidenz während der Migration erreichbar bleibt und die Organisation benennen kann, wer Kommunikation unterbrechen darf. Transparent wird das Log erst, wenn seine Zeugen einander erreichen.

Quellen