Zusammenfassung

  • ITU-T X.1711 vereinheitlicht die gemeinsame Architektur und den allgemeinen Ablauf von Protokollen zur Quanten-Schlüsselverteilung; ein konkretes Protokoll wählt die Empfehlung nicht aus.
  • Ihr eigener Geltungsbereich schließt protokollspezifische Sicherheitsbeweise, die Umsetzung der Module und deren Implementierungssicherheit aus. Die ITU-Nachricht stellt X.1711 zugleich als Referenz für Sicherheitszertifizierung vor.

Die Pressemitteilung klingt wie eine Abkürzung für den Einkauf. Die ITU nennt X.1711 den ersten internationalen Standard für QKD-Protokolle, eine wichtige Referenz für Sicherheitszertifizierung und eine Hilfe bei der Auswahl zertifizierter Module. Die Empfehlung selbst ist genauer. Sie liefert eine gemeinsame Karte. Sie wählt weder die Strecke noch prüft sie das Fahrzeug oder stellt das Zertifikat aus.

X.1711 wurde am 16. März 2026 genehmigt und ist in Kraft. Die Nachricht dazu erschien am 23. Oktober. Das Dokument behandelt den Rahmen für QKD-Module, die über eine Quantenverbindung in der Quantenschicht eines Netzwerks verbunden sind. Es beschreibt Architektur und allgemeinen Ablauf eines Protokolls. Danach zieht die Scope-Notiz eine klare Grenze: konkrete Protokolle, Sicherheitsbeweise, Modulimplementierungen und Implementierungssicherheit liegen außerhalb der Empfehlung.

Dieser Satz trägt die Geschichte. Die Empfehlung zeigt, wie Protokollfunktionen zusammenspielen, ohne Käufern vorzuschreiben, welchem Verfahren sie vertrauen sollen. Der Haupttext trennt die Quantenkommunikationsphase, in der gemeinsame Rohdaten entstehen, von der Schlüsselableitung, die daraus den endgültigen Schlüssel erzeugt. Dazu gehören Datenauswahl, Schätzung der Kanalparameter, Fehlerkorrektur, Prüfung übereinstimmender Daten an beiden Enden und Privacy Amplification.

Die Parameterschätzung ist die Weiche zwischen Weiterlaufen und Abbruch. Reichen die beobachteten Kanaleigenschaften unter den Bedingungen des Protokolls nicht zur Schlüsselerzeugung, bricht das Verfahren ab und beide Endpunkte geben Schlüssel der Länge null aus. Das Wort „Quanten“ macht nicht jeden Austausch zum Schlüssel. Es gibt eine Messung, einen Grenzwert und einen Abzweig mit der Aufschrift: Stopp.

Der klassische Kanal ist ein weiterer Realitätstest. Über ihn laufen Nachrichten für Datenauswahl, Schätzung, Fehlerkorrektur und Privacy Amplification. X.1711 verlangt Integrität und Herkunftsauthentifizierung; Vertraulichkeit ist nicht erforderlich. Ein Angreifer darf die Unterhaltung lesen. Das Protokoll muss Änderungen erkennen und abbrechen. Quantensignale authentifizieren die Gesprächspartner auf dem klassischen Kanal nicht nebenbei.

Die Empfehlung enthält Beispiele für Decoy-State-BB84 und gaußmodulierte kohärente Zustände sowie Anhänge zu Angriffsmodellen, Sicherheitsbeweisen und Implementierungssicherheit. Diese Anhänge sind ausdrücklich kein integraler Bestandteil. Anhang VI beschreibt Gerätefehler und Seitenkanäle und erklärt, warum Charakterisierung und Tests für die Sicherheitszertifizierung von Modulen wichtig sind. Das ist eine Karte des Problems, kein Zertifizierungsprüfplan.

Hier liegt der Unterschied zwischen einem Standard als Einkaufshilfe und einem Standard, der Hardware freigeben kann. X.1711 liefert gemeinsame Begriffe und einen Ablauf, um Protokollverhalten zu diskutieren. Die ITU-Mitteilung reicht weiter bis zu Zertifizierung und Produktauswahl. Die Empfehlung benennt kein Prüflabor, kein Bestehensprofil, keine verpflichtende Modulkonfiguration und kein Verzeichnis zertifizierter Geräte. Ihre Scope-Notiz setzt Implementierungssicherheit außerhalb der Grenze.

Käufer brauchen den Beleg hinter dem Siegel: Welche Hardwareversion wurde geprüft? Welches Protokoll und welcher Sicherheitsbeweis waren Teil des Tests? Wie wurde die Authentifizierung des klassischen Kanals geprüft? Welche Seitenkanaltests liefen? Welches Ergebnis bestand, und wer hat es unterschrieben? „QKD-konform“ ohne diese Felder ist ein Aufkleber mit Physik-Doktorhut.

Der gemeinsame Rahmen bleibt nützlich. Er gibt Netzwerktechnikern und Normungsgremien einen gemeinsamen Ort, um Schnittstellen und Fehlerbedingungen zu besprechen. Die Zertifizierung eines Moduls braucht jedoch einen weiteren Beleg: Testverfahren, Konfiguration, Bestehenskriterien, ausstellende Stelle und eine aktuelle Liste bestandener Module. X.1711 legt die Karte auf den Tisch. Die Adresse des Zertifizierungsbüros fehlt noch.

Quellen