Summary

  • Die KEYTRANS-Architektur vom 1. November ergänzt einen Abschnitt zur Integrität des Clients; in der Fassung vom 7. Oktober fehlte er.
  • Wer einem einzelnen Nutzer veränderte App-Software oder Log-Konfiguration liefert, kann dessen Beweisprüfung und Überwachung abschalten oder die vertrauenswürdigen Schlüssel austauschen.

Ein korrekt geführtes Register hilft wenig, wenn der Prüfer auf dem Telefon neue Anweisungen bekommen hat. Genau diese Lücke beschreibt Fassung 11 des IETF-Entwurfs zur Key Transparency. Das Verfahren soll aufdecken, wenn ein Kommunikationsdienst einem Konto heimlich einen anderen öffentlichen Schlüssel zuordnet. Der Client fragt den Log ab, prüft kryptografische Belege und merkt sich frühere Zustände. Die neue Ziffer 7.3 fragt, wer diesen Client und seine Konfiguration verteilt.

Oft ist es der Dienst selbst. Er kann zugleich Betreiber des Logs und Lieferant der Kontrollsoftware sein. Der Entwurf beschreibt, wie ein gezielt veränderter Client die Beweisprüfung oder das Monitoring auslassen könnte. Eine veränderte Konfiguration könnte den öffentlichen Schlüssel des Logs oder eines Dritten durch einen vom Betreiber kontrollierten Schlüssel ersetzen. Der Log muss dafür gegenüber allen anderen Nutzern nicht manipuliert werden. Eine einzelne Installation reicht als Angriffspunkt.

Die Fassung 10 vom 7. Oktober enthielt keinen Abschnitt „Client Integrity“. Die neue Fassung nennt vier Voraussetzungen: sichere Ausführung auf dem Gerät, korrekte Implementierung, authentische Log-Konfiguration und genaue lokale Zeit. Ein kompromittiertes Gerät kann private Schlüssel und Klartext direkt preisgeben. Zurückgesetzter Client-Zustand kann frühere Beobachtungen vergessen lassen; eine falsche Uhr kann eine veraltete Log-Ansicht gültig erscheinen lassen.

Der Entwurf nennt Gegenmittel mit unterschiedlichem Zweck. Bei Binary Transparency würde jede veröffentlichte Softwareversion vor der Installation in einem öffentlichen, nur ergänzbaren Log stehen. Open Source und reproduzierbare Builds würden unabhängige Prüfung ermöglichen. Verifizierter Start, Sandboxing, geschützte Schlüssel und authentifizierte Zeit betreffen weitere Schwachstellen. Das Dokument meldet weder einen tatsächlichen Angriff noch eine konkrete Einführung dieser Maßnahmen. Im Datatracker steht es als aktiver Arbeitsgruppenentwurf, der dem IESG zur Veröffentlichung vorliegt.