-
Technisches
Gebiet
-
Die
Erfindung betrifft eine Einrichtung zur kryptographisch gesicherten Übertragung
von Daten über
ein unsicheres Kommunikationsnetz an mehrere Empfänger.
-
Hintergrund
der Erfindung
-
Eine
kryptographisch gesicherte Übertragung
von Daten über
ein unsicheres Kommunikationsnetz an mehrere Empfänger wird
beispielsweise für
IP-basierte Anwendungen, wie Pay-TV, Pay-per-view, Business-TV und andere, sowohl
video-orientierte als auch nicht video-orientierte Anwendungen in
vorteilhafter Weise angewendet. Durch Übertragung von Daten an mehrere
Empfänger – Multicast-Übertragung
genannt – wird
unter anderem ein gleichzeitiges Verkaufen derselben Multimedia-Inhalte
an eine große
Zahl von Empfängern (Nutzern)
ermöglicht,
da die vom Kommunikationsnetz zu übertragende Datenmenge auf
ein Minimum reduziert wird.
-
Bei
den in Frage kommenden Kommunikationsnetzen werden die Daten meistens
in Form von Paketen übertragen,
die Multicast-Übertragung
erfolgt also in Multicast-Paketen.
-
Bei
der Übertragung
von Daten über
Kommunikationsnetze können
Dritte die Kommunikation unerlaubt abhören oder in die Kommunikation
aktiv eingreifen. Im letzteren Fall können Angreifer zum Beispiel
zusätzliche
Information in das Kommunikationsnetz einschleusen oder sich durch
Vergabe einer falschen Identität
Zugriff auf schützenswürdige Daten oder
Dienste verschaffen.
-
Für die Übertragung über unsichere
Kommunikationsnetze bestehen deshalb die folgenden Schutzziele und
Anforderungen:
- 1. Integrität der übertragenen Daten, d.h. ein Empfänger einer
Nachricht kann sich sicher sein, dass die Nachricht nicht bei der Übertragung
von einem unberechtigten Dritten verändert wurde.
- 2. Nichtabstreitbarkeit der übertragenen
Daten, d.h. ein Absender einer Nachricht kann nicht das Absenden
dieser Nachricht gegenüber
Dritten abstreiten.
- 3. Vertraulichkeit der übertragenen
Daten, d.h. ein unberechtigter Dritter kann den Inhalt der übertragenen
Pakete nicht entschlüsseln.
- 4. Zugriffsschutz, d.h. nur Berechtigte können den Inhalt einer Nachricht
entschlüsseln
bzw. den Zugriff auf einen Dienst erlangen.
-
Insbesondere
beim Anbieten von Multicast-Diensten, die entweder kostenpflichtig
sind oder nur für
einen bestimmten Personenkreis, beispielsweise nur für das Management
einer Firma, bestimmt sind, sind unter anderem die oben genannten Schutzziele
eine zwingende Anforderung.
-
Für die Übertragung
zu einem Empfänger (Unicast)
in IP-Netzen existiert bereits ein sicherer Standard in Form von
IPSec und IKE, der unter anderem in S. Kent, R. Atkinson, "Security Architecture
for the Internet Protocol",
IETF, RFC 1828, November 1998 und D. Harkins, D. Carrel, "The Internet Key
Exchange (IKE)",
IETF, RFC 2409, Proposed Standard, November 1998 beschrieben ist.
Dieser Lösungsansatz
ist jedoch nicht vollständig
auf die Multicast-Übertragung
anwendbar.
-
Unter
dem Aspekt der Sicherheit ergeben sich bei der Anwendung der bekannten
Verfahren für die
Multicast-Übertragung
folgende Problemfelder:
- 1. Tritt ein Benutzer
(Empfänger)
zu einer Multicast-Sitzung hinzu, so soll es ihm nicht möglich sein,
die vor dem Beitritt übertragenen
Daten der Multicast-Sitzung zu entschlüsseln.
- 2. Verlässt
ein Benutzer eine Multicast-Sitzung, so soll er die zeitlich folgenden
Daten der Multicast-Sitzung nicht entschlüsseln können.
- 3. Die Sender-Authentizität
von Nachrichten für die
Multicast-Gruppe
kann nicht mit herkömmlichen
symmetrischen Verfahren gelöst
werden, da alle Gruppenmitglieder im Besitz eines symmetrischen
Gruppenschlüssels
sind. Damit kann zwar die Gruppen-Authentizität, jedoch nicht die Sender-Authentizität erreicht
werden. Daher sind Angriffe aus der Gruppe auf die anderen Gruppen-Mitglieder
möglich.
Diese Problematik betrifft sowohl die eigentliche Nachrichtenübermittlung der
Multicast-Sitzung
als auch die Meldungen des Schlüsselverteil-Protokolls.
-
Aufgabe
der Erfindung ist es daher, eine kryptographisch gesicherte Übertragung
von Daten für
Multicast-Sitzungen vorzuschlagen, bei welcher die oben genannten
Probleme und Nachteile vermieden werden.
-
Darstellung
der Erfindung
-
Diese
Aufgabe wird erfindungsgemäß dadurch
gelöst,
dass eine Sicherheits-Einrichtung einen Eingang zur Zuführung von
Daten aus einer Multicast-Datenquelle über einen gesicherten Kanal
und einen Ausgang zum Anschluss an das Kommunikationsnetz aufweist
und Komponenten zur Verschlüsselung,
zur Verwaltung und Verteilung von Schlüsseln in Abhängigkeit
von der Konfiguration einer jeweils gebildeten Multicast-Sitzung
enthält.
-
Insbesondere
ist dabei vorgesehen, dass die Sicherheits-Einrichtung folgende Komponenten umfasst:
- – eine
in den Datenfluss zwischen der Multicast-Datenquelle und im Kommunikationsnetz eingefügte kryptographische
Komponente,
- – Mittel
zur Verwaltung von Empfängerdaten
und Parametern von Multicast-Sitzungen,
- – eine
Authentifikations-Komponente zur Prüfung von Anmeldungen zu einer
Multicast-Sitzung und zum Initialisieren von Sicherheitsfunktionen
für die
jeweilige Multicast-Sitzung und
- – eine
Schlüsselverwaltungs-Komponente
zur Erzeugung und Verteilung von Schlüsseln an die Empfänger und
an die kryptographische Einrichtung.
-
Ein
wesentlicher Vorteil der erfindungsgemäßen Einrichtung liegt darin,
dass der Sender von der Sicherheits-Einrichtung entkoppelt ist,
ebenso wie der Empfänger
von einer Empfänger-Einrichtung gemäß einer
unten aufgeführten
Weiterbildung der Erfindung. Insbesondere ist es mit der Erfindung
möglich,
Informationen beliebiger Unicast- und Multicast-Datenquellen der
Sicherheits-Einrichtung zuzuführen
und als sicheren Multicast-Datenstrom über einen
unsicheren Kanal, wie zum Beispiel das Internet, zu übertragen.
-
In
vielen Vorrichtungen für
Sender und Empfänger
ist es meistens aus technischer Sicht nicht oder nur durch erheblichen
Aufwand möglich,
eine Integration von Verschlüsselung-
und Schlüsselverwaltungs-Komponenten
vorzunehmen. Durch die mit der Erfindung erzielte Entkoppelung wird
dieses Problem in vorteilhafter Weise gelöst.
-
Bei
dem Kommunikationsnetz kann es sich zum Beispiel um ein Firmennetz,
eine Satellitenverbindung, das Internet oder ein Breitbandkabelnetz handeln.
Die physikalischen Eigenschaften und die Transportmechanismen des Übertragungsmediums sind
für die
Erfindung nicht von Bedeutung.
-
Eine
Hauptanwendung für
die erfindungsgemäße Sicherheits-Einrichtung liegt
im Bereich Pay-Streaming bzw. Business-TV, d.h. in der sicheren
Verteilung von Audio- und Video-Streams per Multicast an eine gegebenenfalls
große
Gruppe von Empfängern.
Dabei wird die Sicherheits-Einrichtung – im folgenden auch Multicast-Security-Gateway, MSG
genannt – hinter
einem Streaming-Server installiert und kann mehrere Streams (beispielsweise TV-Kanäle) gleichzeitig
bearbeiten.
-
Eine
weitere wichtige Anwendung der erfindungsgemäßen Einrichtung ist ein satellitengestützes IP-Multicast,
nämlich
die Übertragung
von Inhalten mit Hilfe des Internet-Protokolls (IP) über Satellitenkanäle. Neben
der hohen Datenübertragungskapazität einer
Satellitenverbindung ermöglicht
die große
Ausleuchtungszone des Satelliten die Versorgung einer beliebigen
Anzahl von Empfängern
mit identischer Information durch nur einen Sendevorgang.
-
Die
Mittel zur Verwaltung von Empfängerdaten
und Parametern von Multicast-Sitzungen können zentral angeordnet oder
dezentral auf die anderen Komponenten verteilt sein, vorzugsweise
sind sie von einer Datenbank-Komponente gebildet, insbesondere von
einer relationalen Datenbank.
-
Eine
vorteilhafte Ausgestaltung der erfindungsgemäßen. Einrichtung besteht darin,
dass ferner eine Administrations-Komponente
vorgesehen ist, die über
eine Benutzeroberfläche
von einem Administrator bedienbar ist, wobei vorzugsweise vorgesehen
ist, dass die Benutzeroberfläche über ein Netzwerk
mit Hilfe eines sicheren Kanals mit der Administrations-Komponente
(ADM) verbindbar ist. Insbesondere ist die Benutzer-Oberfläche (UI)
web-basiert. Dadurch ist eine räumliche
Entkoppelung des Administrators von der Sicherheits-Einrichtung
möglich.
Zudem kann die Benutzeroberfläche
leicht an die jeweiligen Aufgaben der Sicherheits-Einrichtung angepasst
werden.
-
Eine
andere vorteilhafte Ausgestaltung der Erfindung besteht darin, dass
die Schlüsselverwaltungs-Komponente
Mittel zur Übertragung
von Schlüsselmanagement-Nachrichten
an die Empfänger
aufweist, die zum Zwecke der Prüfung
der Authentizität
und Integrität
asymmetrisch digital signiert werden. Dies hat den Vorteil, dass
die große
Anzahl der potentiellen Empfänger
nicht mit geheimen Schlüsseln
versehen zu werden braucht.
-
Eine
Weiterbildung der erfindungsgemäßen Einrichtung
besteht darin, dass in einer Empfänger-Einrichtung folgende Komponenten
vorgesehen sind:
- – eine Authentifikations-Komponente,
die zum An- und Abmelden der Empfänger-Einrichtung von einer
Multicast-Sitzung mit der Authentifikations-Komponente der Sicherheits-Einrichtung
zur gegenseitigen Authentifikation der Sicherheits-Einrichtung und
der Empfänger-Einrichtung in
Verbindung tritt,
- – eine
Schlüsselverwaltungs-Komponente,
die von der Sicherheits-Einrichtung
eingehende Schlüsselmanagement-Nachrichten
bearbeitet und die zur Multicast-Sitzung notwendigen Parameter und
Schlüssel
ableitet, und
- – eine
kryptographische Komponente zur Entschlüsselung der über das
Kommunikationsnetz eintreffenden Daten der Multicast-Sitzung und
zur Prüfung
ihrer Integrität.
-
Hiermit
ist wie auf der Senderseite eine Trennung zwischen der kryptographischen
Einrichtung und der Datensenke möglich.
Wie bereits erwähnt, geht
die Verteilung der Schlüssel
an sich von der Sicherheits-Einrichtung aus, wobei je nach Art der
Multicast-Sitzung die Initiative von der Sicherheits-Einrichtung
oder auch empfängerseitig
ausgehen kann. Davon unabhängig
kann bei der Weiterbildung vorgesehen sein, dass die Schlüsselverwaltungs-Einrichtung
der Empfänger-Einrichtung
ferner zur Anforderung von Schlüsselmanagement-Nachrichten
bei der Schlüsselverwaltungs-Komponente
der Sicherheits-Einrichtung ausgebildet ist. Damit kann seitens der
Empfänger-Einrichtung
die Schlüsselverwaltungs-Komponente
der Sicherheits-Einrichtung kontaktiert werden und bei Bedarf individuelle
Schlüsselmanagement-Nachrichten
anfordern.
-
Bei
einer Reihe von Anwendungen ist die Authentifizierung der Empfänger-Einrichtung
MSG-Client vorrangig, beispielsweise beim Pay-TV. Bei anderen Anwendungen
ist es jedoch auch wichtig, dass sich der Sender gegenüber dem
Empfänger
authentifiziert. Deshalb ist bei einer vorteilhaften Ausgestaltung
der Weiterbildung vorgesehen, dass die kryptographische Komponente
der Empfänger-Einrichtung ferner
zur Überprüfung der
Sender-Authentizität
ausgebildet ist.
-
Zur
Weiterleitung der Multicast-Daten kann bei der Weiterbildung vorgesehen
sein, dass die Empfänger-Einrichtung
mindestens einen Ausgang zur Weitergabe der entschlüsselten
Daten an eine Abspiel-Komponente oder an ein weiteres Kommunikationsnetz
aufweist.
-
Eine
Anmeldung zu einer Multicast-Sitzung kann vorzugsweise dadurch erfolgen,
dass eine öffentlich
zugängliche
Informations-Einrichtung
zur Ankündigung
von Multicast-Sitzungen vorgesehen ist, wobei die zur Teilnahme
an der jeweiligen Multicast-Sitzung erforderlichen Daten in Form
eines WWW-Links vorliegen und durch die Verknüpfung der Namens-Extension
des WWW-Links mit einer Multi-Purpose-Internet-Mail-Extension an
die Empfänger-Einrichtung übergeben
werden.
-
Ein
Vorteil der erfindungsgemäßen Einrichtung,
nämlich
die Trennung zwischen den kryptographischen Einrichtungen und der
Datenquelle bzw. Datensenke kommt gemäß einer anderen Weiterbildung
vorzugsweise dadurch zum Tragen, dass eine Sicherheits-Einrichtung
und/oder eine Empfänger-Einrichtung
zur Verwaltung mehrerer Multicast-Sitzungen ausgebildet sind.
-
Neben
dem primären
Ziel, nämlich
eine gesicherte Übertragung
von Daten von einer Multicast-Datenquelle zu Empfängern, kann
auch eine Sicherung der Datenübertragungin
umgekehrter Richtung erforderlich sein, beispielsweise beim Austausch
von Schlüsseln
oder bei Übertragung
von Informationen, welche zur Bezahlung der Teilnahme an einer Multicast-Sitzung
dienen.
-
Hierzu
ist bei einer anderen Weiterbildung der Erfindung vorgesehen, dass
die Empfänger-Einrichtung
eine Komponente zur Verschlüsselung
von für
die Sicherheits-Einrichtung bestimmten Nachrichten aufweist.
-
Kurze Beschreibung
der Zeichnung
-
Die
Erfindung lässt
zahlreiche Ausführungsformen
zu. Zwei davon sind schematisch in der Zeichnung anhand mehrerer
Figuren dargestellt und nachfolgend beschrieben. Es zeigt:
-
1 ein Blockschaltbild eines
Ausführungsbeispiels,
-
2 das Blockschaltbild mit
zugehörigen Abläufen der
Schritte einer Multicast-Sitzung und
-
3 ein weiteres Ausführungsbeispiel
mit satellitengestützter Übertragung.
-
Beschreibung
der Ausführungsbeispiele
-
Bei
dem Ausführungsbeispiel
nach 1 sind das MSG
und die Empfänger-Einrichtung – im folgenden
MSG-Client genannt – über einen
unsicheren Kanal C miteinander verbunden. Je nach Anwendungsgebiet
kommt hierfür
jedes zur Datenübertragung
geeignete Netz, unter anderem das Internet, ein IP-basiertes Intranet,
ein Mobilfunk-, Rundfunk-, Satelliten-, Stromversorgungs- und/oder
Fernsehnetz in Frage. Das MSG enthält eine Datenbank DB, eine Administration
ADM, einen Authentifikationdienst AS, eine Schlüsselverwaltung und – verteilung
SVV und eine kryptographische Komponente zur Verschlüsselung
und zum Integritätsschutz
(VIS). Vorzugsweise sind alle Komponenten auf besonders gehärteten Betriebssystemen
installiert und somit vor Angriffen von außen abgesichert. Die Datenbank
DB nimmt die Verwaltung von Benutzern, Parametern zu Multicast-Sitzungen,
Zugriffserlaubnissen für
Multicast-Sitzungen,
Schlüsselmanagement,
Zertifikatsverwaltung und Aktionsaufträge zwischen den einzelnen Komponenten
vor.
-
Optional
kann die Komponente SVV den aktuellen Zustand des Schlüsselmanagements
für eine Sitzung
in der Datenbank DB vorhalten. Dadurch ist es möglich, Dienste, wie ständige Aufrechterhaltung des
Betriebes durch Vervielfältigung
von Komponenten auf verschiedenen operativen Einheiten (Hot-stand-by), zu ermöglichen.
Die Datenbank DB wird durch die Komponente ADM administriert, wozu eine
web-basierte Benutzeroberfläche über einen
sicheren Kommunikationskanal vorgesehen ist. Als Sicherungsverfahren
kommen hier HTTP über
SSL oder TLS in Frage.
-
Die
Komponente AS beinhaltet die Bereitstellung eines sicheren Authentifikationsdienstes,
bei dem sich die Benutzer (Empfänger)
zu einer Multicast-Sitzung mittels Zertifikat über das TLS-Protokoll (TLS = Transport Layer Security),
beschrieben in T. Dierks, C. Allen, "The TLS Protocol Version 1.0", IETF, RFC 2246,
Proposed Standard, Januar 1999, anmelden können und die Parameter und
Schlüssel für die korrekte
Initialisierung des Schlüsselmanagements
in der Empfänger-Einrichtung
MSG-Client über
einen TSL-Tunnel erhalten.
-
Der
Authentifikationsdienst AS weist seine Identität ebenfalls durch ein Zertifikat
aus. Verschiedene Typen der Anmeldung zwischen Authentifikationsdienst
und MSG-Client werden weiter unten beschrieben. Neben dem Protokoll
TLS kann auch ein anderes Protokoll, das Authentizität, Vertraulichkeit und
Integrität
zwischen den Kommunikationspartnern erreicht, eingesetzt werden.
Die Komponente SSV dient einem effizienten Schlüsselmanagement, Batch-rekeying
und einer effizienten und sicheren Verteilung der kryptographischen
Schlüssel
an die berechtigten Empfänger
einer Multicast-Sitzung.
-
Für das Schlüsselmanagement
stehen verschiedene Verfahren zur Verfügung, beispielsweise LKH, bekannt
aus D. Wallner, E. Harder, R. Agee, "Key Management for Multicast: Issues
and Architectures",
IETF, RFC 2627, Juni 1999, oder OFT veröffentlicht unter anderem in
Ran Canetti et al "Multicast Security:
A Taxonomy and Efficient Constructions" in Proceedings IEEE INFOCOM'99, Seiten 708 bis
716, 1999. Batch rekeying ist unter anderem beschrieben in Xiaozhou
Steve Li, Yang Richard Yang, Mohamed G. Gouda, Simon S. Lam, "Batch-rekeying for
secure group communications",
Proceedings of Tenth International World Wide Web Conference (WWW10), (Hong
Kong, China), Seiten 525-534, Mai 2001.
-
Über die
Komponente DB erhält
die Komponente SSV Meldungen über
Empfänger,
die sich beim Authentifikationsdienst AS angemeldet oder abgemeldet
haben. Die Schlüssel,
welche die Komponente SSV verwaltet, teilen sich auf in die Typen
KEK und TEK. Mit den Schlüsseln
KEK, die je nach Schlüsselmanagement-Protokoll
in Listen oder in Bäumen
hierarchisch angeordnet sein können, werden
Schlüssel
(KEK oder TEK) für
das effiziente Schlüsselmanagement
verschlüsselt.
-
Die
Komponente SSV beinhaltet die Generierung von kryptographischen
Schlüsseln
für die Verschlüsselung
und den Integritätsschutz
in der Komponente VIS. Die Nachrichten mit den Schlüsseln KEK
und TEK werden an die Empfänger
der Multicast-Gruppe
entweder als Unicast- oder als Multicast-Nachrichten versendet.
Je nach vorgenommener Aktion im Schlüsselmanagement und dem Schlüsselmanagement-Protokoll
selbst ist eine der beiden Varianten effizienter.
-
Zur
Prüfung
der Authentizität
und Integrität
in den Empfänger-Einrichtungen werden
die Schlüsselmanagement-Nachrichten
von der Komponente SSV asymmetrisch signiert. Die Anwendung von
rein symmetrischen Integritätsverfahren
hat den Nachteil, dass ein schädliches
Gruppenmitglied fehlerhafte Schlüsselmanagement-Nachrichten an die
Gruppenmitglieder schicken kann. Die Erstellung und die Prüfung von
digitalen Signaturen ist wesentlich aufwendiger als die eines symmetrischen
Integritätscodes, so
dass bei hoher Last des MSG bzw. des MSG-Clients eine Erstellung bzw. eine Überprüfung der
digitalen Signaturen für
einige Pakete unterlassen werden muss. Da die Schlüsselmanagement-Nachrichten
im Vergleich zu den eigentlichen Nachrichten der Multicast-Sitzung
nur sehr selten generiert werden, dürfte dieser Engpass nicht oft
auftreten.
-
Die
Komponenten AS, DB und SVV sind vorzugsweise derart ausgelegt, dass
die Integration verbesserter Schlüsselmanagement-Protokolle einfach möglich ist.
Dies kann zum Beispiel durch einen Objekt-orientierten Programmieransatz
erreicht werden.
-
In
der Komponente VIS wird die Verschlüsselung und der Integritätsschutz
der eigentlichen Nachrichtenpakete der Multicast-Sitzung mittels
IPSec ESP Tunnel Modus mit Schlüsseln
durchgeführt, die
von der Komponente SVV bereit gestellt werden. Es sind jedoch auch
andere sichere Transportprotokolle nicht ausgeschlossen. Die Komponente
VIS ist vorzugsweise derart gekapselt, dass man die konkrete IPSec-Implementierung
einfach austauschen kann.
-
Die
gesamte Kommunikation der Komponenten ADM, AS, SVV und VIS geschieht über die Datenbank
DB bzw. über
Netzwerkverbindungen. Dadurch kann man eine Lastverteilung auf verschiedene
operative Einheiten, beispielsweise Rechner, erzielen. Ebenso können dadurch
Dienste, wie dynamische Lastverteilung und Gewährleistung des Betriebs, bei
Ausfall einer operativen Einheit durch Vervielfachung der Funktionalitäten auf
mehrere operative Einheiten erreicht werden.
-
Die
Komponenten des MSG-Clients MSGC sind eine Authentifikations-Komponente
AC, eine Komponente zur Schlüsselverwaltung
SV und eine Komponente zur Entschlüsselung- und Integritäts-Prüfung EIP.
-
Die
Komponente AC wird beim Anmelden und Abmelden des MSG-Clients von einer
Multicast-Gruppe, die vom MSG verwaltet wird, benötigt. Über ein
sicheres Protokoll, vorzugsweise das TLS-Protokoll, tritt die Komponente AC mit
der Komponente AS des MSG in Kontakt und authentifiziert sich beispielsweise
mit einem digitalen Zertifikat. Die Komponente AS kann sich ebenfalls
gegenüber
der Komponente AC mit einem digitalen Zertifikat authentifizieren.
-
Die
Komponente SV bearbeitet die eingehenden Schlüsselmanagement-Nachrichten,
die von der Komponente SVV an die Gruppenmitglieder (berechtigte
Empfänger)
gesendet wurden. Aus diesen Nachrichten werden die für den jeweiligen
MSG-Client notwendigen Parameter und Schlüssel gewonnen. Aufgabe der
Komponente SV ist es, immer die aktuellen Schlüssel KEK einer Sitzung der
Komponente EIP bereit zu stellen.
-
Hat
die Komponente SV nicht alle notwendigen Informationen zur Bildung
des aktuellen Schlüssels
KEK erhalten, so kann sie die Komponente SVV kontaktieren und individuelle
Schlüsselmanagement-Nachrichten
anfordern.
-
In
der Komponente EIP werden die eingehenden Nachrichtenpakete, die
zu den angemeldeten Multicast-Sitzungen des MSG-Clients gehören, bezüglich ihrer
Integrität
geprüft
und entschlüsselt. Bei
Bedarf kann auch eine Überprüfung der
Sender-Authentizität
erfolgen, falls entsprechende Informationen zwischen dem MSG und
dem MSG-Client vereinbart wurden. Die notwendigen kryptographischen
Schlüssel
erhält
die Komponente EIP von der Komponente SV. Die geprüften und
entschlüsselten Pakete
können
entweder an eine externe Abspiel-Komponente DS übergeben oder an ein Kommunikationsnetz,
das hinter dem MSG-Client liegt, weitergeleitet werden.
-
Bei
dem Ausführungsbeispiel
nach 1 ist ferner außerhalb
der Sicherheits-Einrichtung MSG ein. öffentlich zugänglicher
Informationsdienst, beispielsweise in Form eines WWW-Servers ANK,
vorgesehen. Zukünftige
Benutzer klicken eine angekündigte
Sitzung in Form eines WWW-Links mit Hilfe ihres WWW-Browsers an.
Durch die Verknüpfung
der Namensextension des WWW-Links mit einem so genannten MIME-Typ
(Multipurpose Internet Mail Extensions) wird der MSG-Client gestartet
und ihm die notwendigen Sitzungsparameter übergeben.
-
Im
Gegensatz zu den Darstellungen in 1 kann
das Ausstellen und Verwalten von Authentifikations-Informationen,
beispielsweise digitalen Zertifikaten, auch außerhalb des MSG durch geeignete
externe Einrichtungen übernommen
werden. Dies betrifft teilweise auch den MSG-Client, der zum Beispiel die
Korrektheit und Vertrauenswürdigkeit
von digitalen Zertifikaten prüfen
muss, die während
des TLS-Protokolls ausgetauscht werden.
-
Im
folgenden werden unter Hinweis auf 2 die
einzelnen Abläufe
bei Betrieb und bei der Nutzung des MSG und des MSG-Client und deren
Interaktion beschrieben.
-
Schritt
1 und Schritt 2: Im Schritt 1 wird die Datenbank DB des MSG über einen
WWW-Browser und über
die Komponente ADM administriert. Der Administrator authentifiziert
sich gegenüber
dem ADM. Dies geschieht vorzugsweise über das TLS-Protokoll mittels
eines Zertifikates. Nach einer erfolgreichen Authentifikation ist
ein sicherer (authentischer, integrer und vertraulicher) Tunnel
zwischen WWW-Browser und ADM aufgebaut. Der Administrator kann nun die
Inhalte, wie Benutzer oder Sitzungsinformationen der Datenbank DB
ansehen, ergänzen,
verändern oder
löschen
(Schritt 2).
-
Schritt
3 und Schritt 4: Die vom MSG angebotenen Multicast-Sitzungen können zum
Beispiel über
einen öffentlich
zugänglichen
Informationsdienst ANK veröffentlicht
werden. Vorzugsweise können
die Multicast-Sitzungen über
einen WWW-Server in Form von parametrisierten WWW-Links verbreitet
werden. Benutzer können
diese mit einem WWW-Browser sichten und selektieren (Schritt 3). Bei
einem Klick auf einen WWW-Zink, der Informationen über die Netzwerkadresse
eines AS-Dienstes und die Sitzungsnummer der Multicast-Sitzung erhält, wird
beim Benutzer der Schritt 4 aktiviert, bei dem die Parameter im
WWW-Zink an den WWW-Browser des Benutzers übergeben werden.
-
Schritt
5: Der MSG-Client wird mit den Parametern innerhalb des WWW-Links
auf dem Rechner eines Benutzers gestartet. Alternativ kann der MSG-Client
auch über
eine Kommandozeile gestartet werden und ihm dabei die erforderlichen
Parameter einer Multicast-Sitzung übergeben werden. In diesem
Fall sind die Schritte 1 bis 4 nicht notwendig. Dennoch muss man
zum Start des MSG-Clients die für
eine Multicast-Sitzung notwendigen öffentlichen Parameter ermitteln.
-
Schritt
6: Mit Hilfe der Parameter aus Schritt 3, 4 und 5 nimmt der AC Kontakt
mit dem AS des MSG auf. Es findet eine gegenseitige Authentifizierung
statt. In bevorzugter Weise wird diese Authentifizierung mittels
des TLS-Protokolls und digitaler Zertifikate durchgeführt. Über einen
vertraulichen und authentischen Kanal kann der AS die Multicast-Sitzungsparameter
dem AC mitteilen.
-
Schritt
7: Der AS prüft
in der DB, ob der Benützer
für diese
Multicast-Sitzung eine Berechtigung hat. Falls nein, so wird die
Kommunikation mit dem AC abgebrochen und es folgen keine weiteren
Schritte. Falls ja, so wird in der Datenbank eine Aktionsmeldung,
dass sich dieser Benutzer für
diese Multicast-Sitzung
angemeldet hat, eingetragen. Außerdem
werden dem Benutzer ein Schlüssel
und eine eindeutige Identifizierungsnummer zugeordnet und diese
ebenfalls in der Datenbank abgelegt. Des weiteren bezieht der AS
weitere Informationen zur Sitzung aus der DB, wie zum Beispiel den
verwendeten Schlüsselverwaltungsalgorithmus,
das Schlüsselverteilungsprotokoll
und die Parameter für
die kryptographischen Transformationen, die auf den Multicast-Datenstrom angewendet
werden.
-
Schritt
8: Der AS teilt dem AC die Parameter zur Multicast-Sitzung und den individuellen
Benutzerschlüssel
mit. Der Benutzerschlüssel
wird für
jede Sitzungsanmeldung neu vergeben.
-
Schritt
9: Der AC teilt dem SV die Parameter und den individuellen Benutzerschlüssel zur
ausgewählten
Multicast-Sitzung
mit. Über
einen vertraulichen, integren und authentischen Kanal (Schritt 14) erhält der SV
vom SVV die KEK und TEK mitgeteilt.
-
Schritt
10: Der SVV fragt in regelmäßigen zeitlichen
Abständen
die DB ab, um Aktionsmeldungen bezüglich neu angemeldeter Benutzer
oder abgemeldeter Benutzer zu erhalten. Hat sich ein Benutzer (mit
dem MSG-Client) in Schritt 6 bzw. Schritt 20 beim AS erfolgreich
angemeldet bzw. abgemeldet, so wird eine entsprechende Aktionsmeldung
in der DB abgespeichert. Liegt nun eine Neuanmeldung vor, so wird
der neue Benutzer in die Schlüsselverwaltung aufgenommen
und erhält über Unicast-
oder Multicast-Meldungen (Schritt 15) die entsprechenden Schlüssel über einen
vertraulichen, integren und authentischen Kanal mitgeteilt.
-
Schritt
11 und Schritt 12: Immer wenn ein neuer Benutzer in die Schlüsselverwaltung
aufgenommen wurde (Schritt 10), ein Benutzer aus der Schlüsselverwaltung
entfernt wurde (Schritt 21) oder ein TEK ungültig wird (z.B. nach Ablauf
eines Zeitgebers oder einer bestimmten Anzahl von bearbeiteten Nachrichten
der Multicast-Sitzung),
muss ein neuer TEK für
diese Sitzung neu generiert werden. Dieser TEK wird mit Schritt
15 bzw. 11 und 12 den Benutzern der Multicast-Sitzung bzw. der Komponente
VIS mitgeteilt. Der alte TEK für
diese Multicast-Sitzung ist dann ab einem bestimmten Zeitpunkt nicht
mehr gültig.
-
Schritt
13 und Schritt 14: Auf den von einer externen Datenquelle MCD erzeugten
Datenstrom, der zu einer bestimmten Multicast-Sitzung gehört, wird
durch die Komponente VIS kryptographische Transformationen basierend
auf den aktuellen TEKs angewandt. Es handelt sich dabei um die Anwendung
von Verschlüsselungsoperationen,
um die Bildung von Integritätsüberprüfungscodes
und um optionale Verfahren zur Gewährleistung der Sender-Authentizität. Die transformierten
Daten werden als Multicast-Datenstrom zu den Benutzern der Multicast-Sitzung
gesendet.
-
Schritt
15: Die Schritte 15, 16 sollten zeitlich parallel zu den Schritten
11 und 12 geschehen. Der SVV teilt in Schritt 15 den Gruppenmitgliedern
der Multicast-Sitzung die aktuellen Schlüssel und Parameter der Schlüsselverwaltung
des MSG mit. Die Kommunikation ist dabei vertraulich, integer und
optional auch sender-authentisch. Aus Effizienzgründen werden
die Nachrichtenpakete ebenfalls als Multicast-Nachrichten versendet,
falls diese für
mehr als ein Gruppenmitglied bestimmt sind. In der Komponente SV
werten die Gruppenmitglieder die Schlüsselmanagement-Nachrichten
aus und bestimmen daraus ihre aktuelle Position im Schlüsselmanagement
und ihre eigenen KEKs und TEKs. Können die Daten in der Nachricht
nicht vollständig
vom SV ausgewertet werden, so kann die Komponente SV optional die
Komponente SVV über
einen Rückkanal
kontaktieren und die Meldung oder die benötigten Schlüssel individuell anfordern.
-
Schritt
16: Der aktuelle TEK für
eine Multicast-Sitzung wird der Komponente EIP von der Komponente
SV übergeben.
-
Schritt
17: Empfängt
die Komponente EIP mit Schritt 14 Nachrichten zu einer Multicast-Sitzung, für die nicht
der aktuelle KEK vorhanden ist, so kontaktiert EIP mit Schritt 17
die Komponente SV. SV kann daraufhin mit Schritt 19 aktuelle Schlüssel zu dieser
Multicast-Sitzung beim SVV anfordern.
-
Schritt
18: Empfängt
die Komponente EIP Nachrichten zu einer Multicast-Sitzung, für die sich der
MSG Client angemeldet hat, so werden diese in Schritt 18 mit dem
aktuellen KEK entschlüsselt
und die Integrität
und optional die Sender-Authentizität der Nachrichten überprüft. Falls
die Prüfvorgänge erfolgreich
verlaufen, so werden die entschlüsselten Nachrichten
der Multicast-Sitzung an eine Datensenke DS (z.B. eine Video- oder Audioabspielkomponente)
zur weiteren Verarbeitung weitergereicht.
-
Schritt
19: Hat die Komponente SV die Meldungen für das Schlüsselmanagement nicht korrekt empfangen
oder hatten die Komponenten EIP und SV nicht den aktuellen Schlüssel KEK
für eine
Multicast-Sitzung, so kann das SV beim SVV aktuelle Schlüsselmanagement-Nachrichten
anfordern.
-
Schritte
20, 21 und 22: Die Beendigung (Austritt aus der Multicast-Gruppe)
des MSG-Clients wird mittels des TLS-Protokolls dem AS mitgeteilt. Der AS trägt eine
entsprechende Aktion in der DB ein. Das SW informiert sich in der
DB über
aktuelle Aktionen. Wird die Aktion, dass ein Benutzer eine Multicast-Gruppe
verlässt
mitgeteilt, so wird mit Schritt 22 dieser Benutzer aus der Schlüsselverwaltung
entfernt. Es werden neue Schlüssel
KEK und TEK generiert und die entsprechenden Folgeaktionen ausgelöst.
-
In 3 ist der Einsatz der Sicherheits-Einrichtung
MSG in einem satellitengestützten
Szenario abgebildet. Als Beispiel dient dabei die Übertragung von
Video- und Audiodatenströmen
innerhalb einer Organisation mit einer Zentrale und Niederlassungen,
beispielsweise eine in einem großen Land oder international
tätige
Sendegesellschaft. In der Zentrale ist das MSG 32 positioniert,
das von einem Videoserver 31 mit Video- und Audiodatenströmen versorgt
wird. Die Zentrale ist über
einen Router 33 und ein Firewall 34 am Internet 35 angeschlossen
und verfügt über ein
IP/DVB-Gateway 36 und einen DVB-Modulator 37 zur Übertragung
von IP Paketen über
einen Satelliten 38. In den Niederlassungen sind die Empfänger-Einrichtungen
MSGC 40 untergebracht. Die Niederlassungen sind mit einer
niedrigen Übertragungsrate
(z.B. GSM, PSTN, ISDN, DSL) am Internet 35 angeschlossen
und verfügen über eine Vorrichtung 39 für den Satellitenempfang. Über diese können sie
Video- und Audiodatenströme
mit einer hohen Übertragungsrate
empfangen. Die Satellitenverbindung ist in der Regel nur in der
Richtung vom MSG zum MSGC ausgelegt. Für die Kommunikation in der
Richtung von den Niederlassungen zur Zentrale bzw. von den Empfänger-Einrichtungen zur
Sicherheits-Einrichtung sind die Verbindungen mit niedriger Übertragungsrate
vorgesehen.
-
Über die
Verbindung mit der niedrigen Übertragungsrate
werden die Meldungen 3, 4, 6, 8, 19 und 20 (2) übertragen. Die Meldungen der
Schritte 14 und 15 werden dagegen über die Satellitenverbindung übertragen.