Seite 3: Schlüsselmanagement

Inhaltsverzeichnis

Schlüsselmanagement: Unicast-orientierte Protokolle für den Schlüsselaustausch (etwa IKE, Internet Key Exchange) sind nicht direkt für das Schlüsselmanagement in Gruppen geeignet, da sie für jede Instanz einen separaten Schlüssel aushandeln. Stattdessen muss der GCKS einen gemeinsamen Schlüssel durch einen sicheren Kanal an alle autorisierten Gruppenmitglieder übertragen. Dieser Kanal kann auch mittels Unicast realisiert sein. Dei Abbildung verdeutlicht den Zusammenhang.

Rekeying: Kryptografische Schlüssel haben vorzugsweise eine beschränkte Lebensdauer. Der GCKS muss sie erneuern, bevor sie ablaufen. Passiert das doch, müssen die Mitglieder den GCKS um neue Schlüssel bitten, was bei vielen Benutzern schnell in einer Überforderung des GCKS resultiert ("Rekey Request Implosion"). Er kann die neuen Schlüssel sonst mittels Multicast an die Mitglieder senden und nicht mit dem vergleichsweise "teuren" Unicast. Ein den Teilnehmern bekannter KEK schützt die Multicast-Übertragung des neuen Schlüssels.

Von Bedeutung ist auch das Rekeying zum Zweck der Zugangskontrolle zu den gesendeten Daten. Tritt zum Beispiel ein Mitglied aus der Gruppe aus, sollte es nicht mehr in der Lage sein, zukünftige (nach seinem Austritt) übertragene Daten zu dechiffrieren (Forward Access Control). Kommt ein neues Mitglied hinzu, sollte es diesem andererseits nicht möglich sein, die vorangegangene Kommunikation (vor seinem Eintritt) zu entschlüsseln (Backward Access Control). Die Schlüssel müssen also je nach Anforderung der jeweiligen Anwendung allenfalls bei jeder Änderung in der Gruppenmitgliedschaft wechseln und zu den verbleibenden Mitgliedern gelangen. Hier spielt die Dynamik der Gruppe eine wesentliche Rolle. Bei einigen Anwendungen häuft sich die Registrierung der Teilnehmer zu Beginn der Übertragung, die Beschaffenheit der Gruppe bleibt relativ statisch bis zum Ende der Übertragung. Andere Applikationen, etwa Onlinespiele, sind sehr interaktiv, Spieler treten dem Spiel bei, andere verlassen es wieder. Je nach Gruppendynamik muss sich auch der Algorithmus für die Verteilung der neuen Schlüssel laufend anpassen, um eine möglichst effiziente Lösung zu finden.

Group Security Association: Die obigen Ausführungen lassen sich nun auf ein aus der Absicherung von Unicast-Kommunikation bekanntes Prinzip übertragen.

Bei einer IPSec-geschützten Unicast-Übertragung verhandeln die beteiligten zwei Hosts die zu verwendenden Security-Parameter, um eine SA mittels Internet Security Association and Key Management Protocol (ISAKMP) SA (Security Association) aufzubauen (RFC 4306). Diese SA schützt die Aushandlung einer weiteren SA, der IPSec SA für die sichere Datenübertragung. Ein ähnliches Modell lässt sich auch auf die Kommunikation von Gruppen anwenden: Eine "Group Security Association" (GSA, RFC 3740) gewährleistet die nötige Sicherheit zwischen mehreren Teilnehmern in einer Multicast-Gruppe.

Eine GSA besteht aus drei Teilen: Die Registration oder Kategorie-1-SA schützt den Download des Schlüssels zum Mitglied während der Registrierungsphase. Der Schlüssel-Download besteht aus einer Rekey SA und einer Data Security SA. Eine Rekey oder Kategorie-2-SA schützt den Update-Vorgang einer bestehenden Rekey SA oder Data Security SA. Die Data Security oder Kategorie-3-SA schließlich schützt die Multicast-Übertragung von Daten. Beispiele für solche Data Security SAs sind IPSec ESP (RFC 4306) oder das für Multicast erweiterte MESP.

Zwischen dem GCKS und den Mitgliedern kommen zwei SAs zum Einsatz. Die erste ist eine der Kategorie 1 (SA1), die zweite der Kategorie 2 (SA2). Zusätzlich existieren eine oder mehrere SAs der Kategorie 3 (SA3) zwischen den sendenden und empfangenden Mitgliedern.