Zusammenfassung

  • Der primäre CBT-Kern begann als Gruppenschlüsselzentrum; authentifizierte Baumknoten konnten ACL, Gruppenschlüssel und KEK übernehmen und weitere Beitritte bedienen.
  • Damit sank die zentrale Arbeit, während die privilegierte Angriffsfläche wuchs. Eine strengere Variante des RFC behielt die Verteilung nur bei Kernroutern.
  • Der gemeinsame Schlüssel unterschied keine einzelnen Sender, und eine ACL-Löschung entzog kein bereits gelerntes Geheimnis. Herkunft und Ausschluss verlangten neue kryptografische Zustände.

Zwei Bäume auf denselben Leitungen

Auf der einen Ebene verbindet ein Baum Sender und Empfänger. Auf der anderen verbindet er diejenigen, die ein Geheimnis kennen und weitergeben dürfen. Beide Ebenen können dieselben Router und Leitungen benutzen. Sie beantworten dennoch verschiedene Fragen: Wo darf ein Paket fließen, und wer darf den Kreis der Eingeweihten vergrößern?

RFC 1949 legte diese Ebenen übereinander. Ausgangspunkt war die Last eines herkömmlichen Key Distribution Centre. Es musste jeden Empfänger authentifizieren und den Gruppenschlüssel für ihn gesondert schützen. Auch eine gemeinsame Multicast-Übertragung der einzelnen Chiffrate beseitigte die individuelle Herstellung nicht.

Der aktuelle RFC-Editor-Eintrag führt den Text von A. Ballardie als Experimental und datiert ihn auf Mai 1996. Das ist kein Nachweis für Einsatz oder Verbreitung. Es ist eine Einladung, den vorgeschlagenen Mechanismus einschließlich seiner offengelegten Annahmen zu prüfen.

CBT besaß bereits einen expliziten Beitrittsweg. Ein JOIN_REQUEST wanderte in Richtung eines Kerns; ein JOIN_ACK kehrte auf dem Rückweg zurück und bestätigte den Zweig. Die CBT-Architektur beschrieb Eltern- und Kindbeziehungen. Die CBTv2-Spezifikation betrachtete einen Router erst nach empfangenem ACK als on-tree.

Diese bestätigte Nachbarschaft ließ sich für Schlüssel nutzen. Der Gruppeninitiator übergab dem primären Kern eine signierte ACL. Der Kern nahm zunächst die GKDC-Rolle ein und erzeugte Gruppenschlüssel sowie KEK. Ein beitretender Host lieferte ein signiertes Token; Router prüften die Steuernachrichten; ein erfolgreiches Zugriffspaket kam mit Richtlinie, Schlüsseln und Parametern der Security Association zurück, jeweils für den nächsten Empfänger verschlüsselt.

Der eigentliche Skalierungsschritt

Der Kern hätte weiterhin jedes Blatt einzeln bedienen können. RFC 1949 ging weiter: Ein authentifizierter Knoten durfte ACL und Schlüsselmaterial speichern, einen späteren Beitritt prüfen und die Materialien erneut verpacken. Die Arbeit breitete sich mit dem Baum aus.

Dasselbe galt für die Entscheidungsmacht. Wer einen Beitritt billigte, öffnete einem neuen Empfänger den Gruppenschlüssel. Dezentralisiert wurde nicht nur Verschlüsselungsarbeit, sondern die praktische Ausübung einer Zulassungsregel.

Die GKMP-Spezifikation benannte dagegen einen Gruppencontroller, der Schlüssel erzeugte und erneuerte, Empfangsbestätigungen sammelte, Berechtigungszertifikate prüfte und Kompromittierungsinformationen behandelte. Beide Ansätze zeigen: Der Verzicht auf ein dediziertes zentrales KDC ist kein Verzicht auf Kontrolle. Die Funktion erhält nur einen anderen Träger.

Eine eingebaute Rücknahme der Delegation

RFC 1949 fragte ausdrücklich, ob allen Routern des Lieferbaums vertraut werden dürfe. Im weit verteilten Modell konnten gewöhnliche Knoten Schlüssel entschlüsseln, prüfen, neu verschlüsseln und verteilen. Ein kompromittierter Router beeinflusste damit nicht nur den Paketweg, sondern Mitgliedschaft und Vertraulichkeit.

Die strengere Option leitete sichere Beitritte bis zu einem Kern weiter und ließ die Schlüsselverteilung nur bei Kernroutern. Das System wurde weniger verteilt, aber der privilegierte Kreis kleiner. Die relevante Wahl lag zwischen mehr Entlastung und weniger Verwahrern, nicht zwischen zwei politischen Etiketten.

Auch die Belege blieben begrenzt. Ein JOIN_ACK bestätigte einen Zweig in einem bestimmten Zustand. Eine Signatur wies einen Nachrichtenersteller nach. Keines bewies, dass alle ACL-Kopien aktuell waren, alte Schlüssel gelöscht wurden oder ein Router später nicht kompromittiert würde.

Ein Gruppenschlüssel konnte den Sender nicht benennen

Kennt jedes Mitglied dasselbe Geheimnis, kann eine gültige Nachricht von jedem dieser Mitglieder stammen. RFC 1949 verteilte deshalb senderbezogene Schlüssel gesondert. Ein Mitglied konnte signiertes Sendermaterial unter dem Gruppenschlüssel veröffentlichen. Ein externer Sender verhandelte zunächst mit dem primären Kern, der dessen Material anschließend an die Gruppe gab.

Mitgliedschaft, Sendeberechtigung und konkrete Urheberschaft sind getrennte Aussagen. Aus dem gemeinsamen Geheimnis folgt weder die Identität einer Person noch ein institutionelles Mandat oder die Berechtigung für eine nachgelagerte Handlung.

Ausschluss begann mit einem neuen Geheimnis

Der Entwurf kannte KEK und regelmäßigen Schlüsselwechsel. Für den selektiven Ausschluss aus der bestehenden Kommunikation bot er trotzdem nur einen neu gebildeten CBT-Gruppenbaum mit neuen Schlüsseln an. Ein gelöschtes Mitglied kannte die aktuelle Generation bereits.

Die spätere logische Schlüsselhierarchie in RFC 2627 machte das Ausschlussprinzip in einem anderen Baum sichtbar. Alle Schlüssel, die ein entfernter Nutzer vom Blatt bis zur Wurzel kannte, mussten ersetzt und ausschließlich an die verbleibenden Nutzer verteilt werden. Das ist weder derselbe Baum noch ein Kausalbeleg; es quantifiziert dieselbe Grenze zwischen Registereintrag und Wissen.

Die MSEC-Architektur in RFC 4046 trennte später Aufnahme, Entfernung, autorisierte Quelle, skalierbares Rekeying, Kollusionsresistenz und Wiederherstellung nach Kompromittierung. Ein Gruppenschlüssel ist somit nur ein Zustand in einer längeren Folge von Autoritätswechseln.

Gegen die symbolische Abkürzung

Heng Lus Prinzip der Vorrangigkeit laufenden Codes verlangt operative Belege: Stimmen ACL-Versionen überein? Wer hält Schlüssel? Werden alte Generationen gelöscht? Erreicht das Rekey alle verbleibenden Zweige? Kann ein ausgeschlossenes Blatt neue Daten noch öffnen? Der RFC-Status beantwortet keine dieser Fragen.

Die Idee einer minimalen Anfangsspezifikation und freiwilligen Übernahme erklärt die Eleganz der Wiederverwendung von JOIN und ACK. Schlüsselverteilung konnte optional in einen vorhandenen Mechanismus eingebettet werden. Doch eine kleine Spezifikation muss gerade die Vererbung des Verteilungsrechts sichtbar halten.

Die Trennung von Realitätsebenen verhindert, dass „verteilt“ als Sicherheitsbeweis dient. Unter dem Wort liegen primärer Kern, signierte ACL, vertrauenswürdige Router, Gruppenschlüssel, KEK, Sendernachweise und Rekey-Generation. Das Zentrum verschwand als einzelner Arbeitsort; seine Autorität erschien als replizierter Betriebszustand wieder.

RFC 1949 hinterlässt deshalb zwei Maße für Skalierung. Nachrichten und Verschlüsselungen sind das erste. Privilegierte Knoten, veraltete Richtlinien, Kompromittierungswege und die Kosten eines wirksamen Austritts sind das zweite.

Quellen

  1. RFC Editor — aktueller Eintrag zu RFC 1949
  2. RFC 1949 — Scalable Multicast Key Distribution
  3. RFC 2093 — Group Key Management Protocol Specification
  4. RFC 2189 — Core Based Trees version 2 Protocol Specification
  5. RFC 2201 — Core Based Trees Multicast Routing Architecture
  6. RFC 2627 — Key Management for Multicast
  7. RFC 4046 — MSEC Group Key Management Architecture
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile