-
Die
vorliegende Erfindung betrifft ein Datenkommunikationssystem und
insbesondere die Steuerung des Zugriffs durch Benutzer auf Kopien
digital codierter Daten. Sie kann zum Beispiel auf die Steuerung
von Daten angewendet werden, die über das Internet per Multicast-Verfahren verteilt
werden.
-
Multicast-Routing-Techniken
wurden entwickelt, damit mehrere Kopien eines Datenelements effektiv an
eine große
Anzahl von Endbenutzern verteilt werden können. Damit derartige Techniken
jedoch kommerziell verwertet werden können, ist es erforderlich,
einen Zugriff von Benutzern auf die Daten selektiv zu steuern. Zum
Beispiel in einer Anwendung, in der ausgewählte Börsenkurse über das Internet an Teilnehmer
verteilt werden, ist es notwendig, sicherzustellen, dass nur Benutzern
auf die Daten zugreifen, welche die relevante Teilnahmegebühr bezahlt
haben. Dies kann erreicht werden durch Verschlüsseln der Daten und Freigabe
des relevanten Schlüssels
für den
Benutzer nur als Gegenleistung für
die Zahlung der Teilnahmegebühr.
Wenn jedoch das Abonnement eines Benutzers nach einer festgelegten
Zeitdauer oder nach Erhalt einer vorgegebenen Quantität von Daten
abläuft,
wäre es
erforderlich, den Schlüssel
für alle
Benutzer zu ändern,
um diesen einen Benutzer auszuschließen. In einer derartigen Situation
wird der zu einer Schlüsselverteilung
gehörende Verkehr
zu einem signifikanten Betriebs-Overhead und kann sogar den Verkehr
der Daten selbst übersteigen.
-
WO
97 26611 A offenbart ein Bereitstellungssystem für elektronische Daten zum Broadcast
von Daten von einem zentralen Server an eine Vielzahl von Endbenutzern.
Daten von dem Server werden während
des Broadcasts verschlüsselt
gesendet und können
an einem Benutzer-Terminal nur entschlüsselt werden, wenn der richtige
Schlüssel von
einem Sicherheitsmechanismus freigeben wird. Vor dem Broadcast wird
an die Benutzer ein Katalog versendet, so dass sie bestimmen können, welche
Broadcast-Übertragungen
sie zu erhalten wünschen.
Zusätzlich
wird regelmäßig (z.B.
monatlich) die Konten-Information
für den
Benutzer (einschließlich
Kreditbegrenzungen, usw.) an den Sicherheitsmechanismus gesendet.
Bei Beginn einer Broadcast-Übertragung
umfasst eine Ankündigungsmeldung
einen Ursprung für
einen Schlüssel,
der an den Sicherheitsmechanismus geleitet wird. Der Sicherheitsmechanismus
erzeugt und gibt den zur Entschlüsselung
des Broadcasts erforderlichen Schlüssel nur frei, wenn er zuerst
aus der Konten-Information ermittelt hat, dass der Benutzer einen
ausreichenden Kredit und eine Berechtigung hat, um die Broadcast-Übertragung
zu empfangen. Eine Entschlüsselung
der erhaltenen Daten während
der Broadcast-Übertragung
kann daraufhin vonstatten gehen.
-
Das
Dokument EP-A-0 528 730 betrifft die Übertragung einer Vielzahl von
Datenelementen, die von einer Steuermeldung begleitet werden. Vor
der Übertragung
wird eine Vielzahl unterschiedlicher Steuerungswörter erzeugt, die jeweils für einen
Benutzer spezifisch sind und jeweils verwendet werden, um ein anderes Datenelement
zu verwürfeln,
so dass bei Erhalt nur der relevante Benutzer das Datenelement korrekt
wiederherstellen kann, das für
ihn gedacht ist. Während
der Übertragung
ist die mit den Daten versendete Steuermeldung ein gemeinsames (root)
Steuerungswort, mit dem jeder Benutzer sein eigenes spezifisches
Steuerungswort erzeugen kann, um auf die Daten zuzugreifen.
-
Gemäß einem
ersten Aspekt der vorliegenden Erfindung ist vorgesehen ein Verfahren
zum Verteilen digital codierter Daten, mit:
- a)
einem Aufteilen der Daten in eine Vielzahl von Frames (Rahmen);
- b) einem Verschlüsseln
der Frames;
- c) einem Verteilen mehrerer Kopien der Frames an eine Vielzahl
von Benutzern, wobei jeder Frame mit einem Steuerfeld verteilt wird;
gekennzeichnet durch
- d) ein Übertragen
eines Ursprungswerts zur Schlüsselerzeugung
an jeweilige gesicherte Module, die sich bei jedem der Vielzahl
von Benutzern befinden;
- e) ein Entschlüsseln
der Frames bei jeweiligen Benutzern unter Verwendung von Schlüsseln, die
von dem an die gesicherten Module übertragenen Ursprungswert abgeleitet
sind, wobei die gesicherten Module eine Entschlüsselung eines jeweiligen Frames
nur dann ermöglichen,
wenn das Steuerfeld an die gesicherten Module geleitet wurde;
- f) ein Weiterleiten einer Steuermeldung in dem Steuerfeld an
die gesicherten Module bei einem ausgewählten Benutzer oder mehreren
ausgewählten
Benutzern; und
- g) als Antwort auf die Steuermeldung bei dem oder jedem ausgewählten Benutzer,
Steuern der Verfügbarkeit
von aus dem Ursprungswert erzeugten Schlüsseln, dadurch Steuern eines
Zugriffs auf die Daten durch die Benutzer.
-
Der
in diesem Dokument verwendete Begriff „Frame" (Rahmen) bezeichnet ein Objekt der
Anwendungsschicht, das manchmal als eine Anwendungsdateneinheit
(ADU – Application
Data Unit) bezeichnet wird, und muss beispielsweise von herkömmlichen
Video-„Frames" unterschieden werden.
Die Begriffe Anwendungsdateneinheit und Frame werden in diesem Dokument äquivalent
verwendet.
-
Das
Verfahren der vorliegenden Erfindung liefert eine vollständige und
wirksame Steuerung eines Zugriffs von Benutzern auf Daten, ohne
zu großen
Kommunikations-Overheads zu führen.
Dies wird erreicht durch Aufteilen der Datenelemente in Frames,
individuellem Verschlüsseln
der Frames mit einer Reihe von Schlüsseln und Ver wendung eines
gesteuerten gesicherten Moduls an dem Kundenstandort, um die entsprechende
Reihe von Schlüsseln
zu erzeugen, die zur Entschlüsselung
der empfangenen Daten erforderlich ist. Das gesicherte Modul wird
gesteuert, um die Verfügbarkeit
der Schlüssel
zu begrenzen. Zum Beispiel kann eine anfängliche Aufbau-Meldung an das
gesicherte Modul dieses anweisen, nur eine begrenzte Anzahl von Schlüsseln zu
erzeugen, beispielsweise einhundert. Wenn der Benutzer später eine
Verlängerung
seines Abonnements bezahlt, kann eine weitere Steuermeldung an das
gesicherte Modul gesendet werden, damit aus dem existierenden Ursprungswert
weitere Schlüssel
erzeugt werden können.
-
Die
Erfindung umfasst, ist aber nicht darauf begrenzt, Datenkommunikationssysteme,
in denen die Frames oder „ADUs" z.B. über ein öffentliches
Verbund-Datennetz, wie dem Internet, kommuniziert werden. Sie umfasst
auch Systeme, in den der Schritt des Kommunizierens von ADUs z.B.
durch ein physikalisches Verteilen eines Datenträgers, wie einer die ADUs enthaltenden
CD-ROM, ausgeführt
wird. Die Daten auf dem Verteilermedium können in Frames aufgeteilt sein,
jeweils mit einer Sequenznummer und jeweils mit einem unterschiedlichen
Schlüssel
verschlüsselt.
Während
des Lesens der Daten von dem Datenträger erzeugt das gesicherte
Modul Schlüssel,
wobei dies offline geschehen kann. Eine Online-Verbindung kann trotzdem
erforderlich sein, um z.B. eine Bestätigung anzufordern und zur Übertragung
einer Antwort, wie einer Bestätigung.
-
Obwohl
die Erfindung zur Verwendung in einem Multicast-Datenkommunikationsnetz geeignet ist, kann
sie auch in einem weiten Bereich anderer Kontexte angewendet werden,
wo immer es erforderlich ist, einen Zugriff auf weit verteilte Datenelemente
zu steuern. Mögliche
Anwendungen umfassen Multicast-Audio/Video-Ströme
für Video
auf Bestellung, Netz-Radio oder -Überwachung; Steuern des Zugriffs
auf die Inhalte von CD-ROMs oder anderer Speichermedien, die Software
oder Multimedia-Daten enthalten; Steuern des Zugriffs auf einen
Satz von Gutscheinen, die Zugriff auf andere Dienste ermöglichen;
einen Multicast-Strom von Meldungen, wie Aktienkurse, Preise von
Kommunikationsnetzen, Elektrizitätspreise,
Netzverwaltungsmeldungen, Nachrichtenelemente, Portfolio-Information, Gruppenbesprechungen,
Standard-Dokumente, akademische Veröffentlichungen, Magazine, Produktübersichten, „schwarze
Listen", Strafverfolgungsintelligenz, Rechtsfälle, Eigenschaftsprofile,
pharmazeutische Testergebnisse, usw.; eine Sequenz von Multicast-Meldungen in einem
Netzwerk-Spiel, einer virtuellen Welt oder Simulations-Szenarium
(z.B. eine Eignungsprüfung), möglicherweise
nur die Meldungen, die einen Zugriff steuern, aber möglicherweise
auch alle Datenmeldungen, für
die eine Empfangsbestätigung
entscheidend ist für
die Gerechtigkeit des Ergebnisses der Simulation.
-
Steuermeldungen
werden vorzugsweise, aber nicht notwendigerweise online verteilt.
Sie können über alle
geeigneten Mittel (z.B. auf Plastikkarten, Barcodes, punktförmige Wiedergabe
(microdots), Disketten, usw.) verteilt werden.
-
Ein
Steuerfeld wird an jeden der Vielzahl von Benutzern verteilt und
das gesicherte Modul ist ausgebildet, eine Entschlüsselung
eines jeweiligen Frames nur zu ermöglichen, wenn das Steuerfeld
an das gesicherte Modul geleitet wurde. Vorzugsweise wird die Steuermeldung
zum Modifizieren der Verfügbarkeit
von Schlüsseln
in dem Steuerfeld an das gesicherte Modul kommuniziert.
-
Diese
Merkmale der Erfindung erschweren es dem Benutzer, die durch das
Schlüsselerzeugungssystem
ausgeübte
Kontrolle zu umgehen. Indem mit jedem Frame ein Steuerfeld an das
gesicherte Modul übermittelt
wird und nur eine Entschlüsselung
ermöglicht
wird, wenn das Steuerfeld empfangen wird, schützen sie vor einer Unterbrechung
des Steuerkanals zu dem gesicherten Modul.
-
Vorzugsweise
umfasst jeder Daten-Frame ein Frame-Identitätsfeld und jeder von dem gesicherten Modul
erzeugte Schlüssel
ist spezifisch für
einen von dem Feld identifizierten Frame.
-
Wie
im Folgenden weiter diskutiert wird, wird die Sicherheit des Systems
weiter verbessert, indem ein Frame-Identitätsfeld aufgenommen und der
Vorgang der Entschlüsselung
abhängig
von der Frame-Identität gemacht
wird.
-
Das
Verfahren kann umfassen ein Erzeugen und Speichern einer Empfangsbestätigung für jeden
von dem Benutzer entschlüsselten
Frame.
-
Der
Benutzer kann die Daten-Frames empfangen und verarbeiten unter Verwendung
eines geeigneten Terminals, wie einem Personalcomputer oder jede
andere geeignete Vorrichtung, wie zum Beispiel ein Java-fähiges Mobiltelefon.
Das gesicherte Modul stellt einen Bereich in dem Kundenterminal
bereit, der sich effektiv unter der Steuerung des Daten-Anbieters
befindet und auf den der Kunde nicht ohne weiteres einen Zugriff
hat. Das gesicherte Modul kann einfach ein Software-Modul sein,
das einen Verschlüsselungsalgorithmus ausführt. Es
kann zum Beispiel als ein Java-Programm implementiert werden, das
von dem Betreiber der entfernten Datenquelle als Teil des Vorgangs
des Aufbaus einer Sitzung verteilt wird. Für noch höhere Stufen von Sicherheit
ist es vorzuziehen, dass das gesicherte Modul einen dedizierten
Prozessor und Speicher aufweist, die sich, optional, aber nicht
notwendigerweise, innerhalb eines physikalisch gesicherten Gehäuses befinden. Beispiele
derartiger gesicherter Module umfassen Smartcard-Strukturen und
kryptographische PC-Karten.
-
Wenn
das gesicherte Modul nur eine relativ geringe Verarbeitungsleistung
aufweist, wie es zum Beispiel bei einer Smartcard der Fall sein
kann, muss dieses Modul einfach die unterschiedlichen jeweiligen Schlüssel ausgeben.
Andere, in dem Hauptteil des Kunden-Terminals ablaufende Prozesse sind dann
für die Entschlüsselung
der Daten-Frames verantwortlich. Alternativ, wenn das gesicherte
Modul mehr Verarbeitungsleistung aufweist, wenn zum Beispiel eine
kryptographische Co-Prozessor-Karte verwendet wird, werden die verschlüsselten
Daten-Frames vorzugsweise an das gesicherte Modul übermittelt
und das Modul erzeugt die jeweiligen Schlüssel, entschlüsselt die
Frames und gibt die entschlüsselten
Frames zum Beispiel an ein Anwendungsprogramm aus, das auf dem Kundenterminal
läuft.
-
Die
Steuermeldung wird mit einem Daten-Frame an die Vielzahl der Benutzer
verteilt. Vorzugsweise ist ein Benutzer-Identitätsfeld, das einen ausgewählten Benutzer
oder eine Gruppe von Benutzern identifiziert, in der Steuermeldung
enthalten, und wobei auf die Steuermeldung nur von dem von dem Benutzer-Identitätsfeld identifizierten
Benutzer oder von der Gruppe von Benutzern reagiert wird. Die Steuermeldung
kann ein Stopp-Flag und ein Kontaktiere-Sender-Flag umfassen. Zum
Beispiel kann das Kontaktiere-Sender-Flag verwendet werden, um einen
entfernten Prozeduraufruf (remote procedure call) von dem Kundenterminal
an die Datenquelle zu starten, wodurch eine neue Richtlinie zur
Schlüsselerzeugung
an das Terminal kommuniziert werden kann.
-
Das
Verfahren kann ein Anwenden digitaler Wasserzeichen umfassen, d.h.
unterschiedliche charakteristische Variationen von Daten, die an
unterschiedlichen jeweiligen Kundenterminals entschlüsselt werden. Dies
dient dazu, die Erfassung von Täuschung
durch Schwindel zu ermöglichen,
zum Beispiel wenn ein Kunde Schlüsselwerte
oder entschlüsselte
Daten an einen anderen Kunden weitergibt.
-
Gemäß einem
zweiten Aspekt der vorliegenden Erfindung ist vorgesehen ein Datenkommunikationssystem,
mit
- a) einer entfernten Datenquelle, die ausgebildet
ist, eine Vielzahl von Frames auszugeben;
- b) Verschlüsselungsmitteln
zum Verschlüsseln
der Vielzahl von Frames mit verschiedenen jeweiligen Schlüsseln;
- c) einem Kommunikationskanal, der ausgebildet ist, mehrere Kopien
der verschlüsselten
Daten-Frames, jeweils mit einem Steuerfeld, zu verteilen;
- d) einer Vielzahl von Kunden-Endgeräten, die ausgebildet sind,
von dem Kommunikationskanal jeweilige Kopien der verschlüsselten
Daten-Frames mit den Steuerfeldern zu empfangen; gekennzeichnet
durch
- e) eine Schlüssel-Erzeugungsvorrichtung,
die sich in einem Kunden-Endgerät befindet
und programmiert ist, aus einem Ursprungswert Schlüssel zur
Verwendung bei der Entschlüsselung
von Daten-Frames
zu erzeugen;
- f) mit der Schlüssel-Erzeugungsvorrichtung
verbundene Schlüssel-Steuermittel, wobei
die Schlüssel-Steuermittel
aufweisen:
eine Schnittstelle zum Empfangen des Steuerfelds;
Steuermittel,
die ausgebildet sind, nur Schlüssel
zur Entschlüsselung
der jeweiligen Frames freizugeben, für die ein Steuerfeld empfangen
wird;
Steuermittel, die ausgebildet sind, als Antwort auf Steuermeldungen
in dem Steuerfeld, die Verfügbarkeit von
aus dem Ursprungswert erzeugten Schlüsseln für Benutzer zu steuern; und
- g) Entschlüsselungsmittel,
die mit der Schlüssel-Erzeugungsvorrichtung
verbunden und ausgebildet sind, die an dem Kunden-Endgerät von dem
Kommunikationskanal empfangenen Daten-Frames zu entschlüsseln.
-
Es
ist ebenfalls ein Verfahren zum Betreiben eines Kunden-Endgeräts gemäß Anspruch
9 und ein Kunden-Endgerät
gemäß Anspruch
12 vorgesehen.
-
Die
Erfindung umfasst auch Kunden-Endgeräte und Daten-Server, die ausgebildet
sind, die Erfindung in allen ihren Aspekten zu implementieren. Sie
umfasst auch Verfahren und Systeme, in denen Daten ihren Ursprung
aus einer Vielzahl von unterschiedlichen Datenquellen haben.
-
Die
vorliegende Erfindung darstellende Systeme werden im Folgenden auf
beispielhafte Weise unter Bezugnahme auf die beigefügten Zeichnungen
beschrieben, in denen:
-
1 eine
schematische Darstellung eines Datenkommunikationssystems ist, das
das Netz verwirklicht;
-
2 eine
schematische Darstellung ist, welche die funktionalen Komponenten
des Kunden-Terminals in dem System von 1 detaillierter
zeigt;
-
3 ein
Ablaufdiagramm ist, das die hauptsächlichen Betriebsphasen des
Systems von 1 zeigt;
-
4 ein
Ablaufdiagramm ist, das die Verifizierungsphase detaillierter zeigt;
-
5 ein
Ablaufdiagramm ist, das die Initialisierungsphase detaillierter
zeigt;
-
6 ein
Ablaufdiagramm ist, das die Phase „Empfangen/Entschlüsseln" detaillierter zeigt;
-
7 ein
Ablaufdiagramm ist, das die Empfangsphase detaillierter zeigt;
-
8 die
Software-Architektur des Kunden-Terminals zeigt;
-
9 die
Software-Architektur des Daten-Servers zeigt;
-
10a und 10b die
Struktur eines Daten-Frames zeigt;
-
11 Meldungsflüsse in dem
Datenkommunikationssystem zeigt;
-
12 das
Netzwerk eines alternativen Ausführungsbeispiels
zeigt.
-
Wie
in 1 gezeigt, umfasst ein Datenkommunikationssystem
einen Daten-Server 1 („Rechner des Senders"), der mit mehreren
Kunden-Terminals 2 über ein
Datenkommunikationsnetz 3 verbunden ist. Obwohl zur einfacheren
Darstellung nur einige Kunden-Terminals gezeigt sind, kann der Daten-Server 1 in
der Praxis mit vielen Terminals gleichzeitig kommunizieren. In dem
vorliegenden Beispiel ist das Datenkommunikationsnetz 3 das öffentliche
Internet. Die Teilnetze und die zugehörigen Router, die den Daten-Server
mit den Kunden-Terminals
verbinden, unterstützen
IP (Internet Protokoll)-Multicasting.
-
In
dem vorliegenden Beispiel ist der Daten-Server 1 ein Video-Server.
Der Daten-Server liest einen Videodatenstrom aus einer Massenspeichervorrichtung
und komprimiert die Daten unter Verwendung eines geeigneten Komprimierungsalgorithmus,
wie MPEG 2. Ein Verschlüs selungsmodul
in dem Daten-Server 1 teilt dann den komprimierten Videodatenstrom
in Frames. Zum Beispiel kann jedes Frame Daten aufweisen, die einer
Minute des Videosignals entsprechen. Ein Verschlüsselungsalgorithmus, wie der
im Folgenden detaillierter beschriebene, verschlüsselt dann die Frames der Daten.
Ein gemeinsamer Verschlüsselungsalgorithmus wird
für alle
Frames in einer Sitzung verwendet. Jedoch wird eine Sequenz von
Schlüsseln
verwendet, mit einem anderen Schlüssel für jeden aufeinander folgenden
Frame.
-
An
jedem Kunden-Terminal werden ankommende Daten-Frames unter Verwendung
eines gesicherten Moduls 4 verarbeitet. Wie im Folgenden
detaillierter beschrieben wird, erzeugt das gesicherte Modul 4 eine Sequenz
von Schlüsseln,
die den ursprünglich
zum Verschlüsseln
der Daten-Frames verwendeten Schlüsseln entsprechen. Die Anzahl
der zu erzeugenden Schlüssel
in einer bestimmten Sitzung wird durch einen Vertrag zwischen dem
Benutzer und dem Betreiber des Daten-Servers bestimmt. Zum Beispiel
in dem Fall von Video auf Bestellung kann der Benutzer ein Programmmaterial
auswählen,
als Antwort darauf identifiziert der Server die Anzahl der zum Entschlüsseln aller
Frames in dem Programm erforderlichen Schlüssel und die Kosten des Programms.
Als Gegenleistung für
die Zahlung von dem Benutzer sendet der Server den Ursprungswert
für den
Schlüssel
zusammen mit einer Steuerungsanweisung für das gesicherte Modul, die
erforderliche Anzahl der Schlüssel,
z.B. einhundert, zu erzeugen. Die Schlüssel können an den Hauptprozessor
des Kunden-Terminals ausgegeben werden, damit die Daten entschlüsselt werden
können.
Alternativ kann das gesicherte Modul selbst den Schritt der Entschlüsselung
durchführen.
In jedem Fall speichert das gesicherte Modul ein Verzeichnis der
erzeugten Schlüssel.
Dieses Verzeichnis kann zum Beispiel die gesamte Anzahl der während einer
Sitzung ausgegebenen Schlüssel
zusammen mit einer Sitzungs-ID und einer Aufzeichnung der Zeit der Sitzung
aufweisen.
-
Während der
Sitzung können
Steuerungssignale gesendet werden, um die Zugriffsrechte des Kunden zu
modifizieren. Zum Beispiel kann der Kunde wählen, das Programm zu einem
frühen
Zeitpunkt zu beenden, und eine Rückvergütung bekommen.
Dies wird bewirkt durch eine Übertragung
eines Daten-Frames von dem Daten-Server, der zusätzlich zu den Daten selbst
eine Steuermeldung enthält,
welche die Identität
des bestimmten Kunden oder der Gruppe von Kunden aufweist, dessen/deren
Zugriffsrechte modifiziert werden sollen. Die Steuermeldung kann
ein einfaches „Stopp"-Flag umfassen, das,
wenn es gesetzt ist, veranlasst, dass das gesicherte Modul keine
Schlüssel
mehr freigibt. Mögliche
Formate für
die Kommunikation von Steuerungssignalen werden im Folgenden unter
Bezugnahme auf die 10A und 10B detaillierter
diskutiert. Umgekehrt kann der Benutzer wählen, zusätzliches Programmmaterial anzusehen,
in diesem Fall kann eine Steuermeldung an das gesicherte Modul gesendet
werden, um die Anzahl der zu erzeugenden Schlüssel zu erhöhen, z.B. von 100 auf 200.
Andere Änderungen
des Status sind ebenfalls möglich.
Die Frames können
ein Meta-Datenfeld umfassen, das verwendet wird, um zum Beispiel
zwischen zwei unterschiedlichen Klassen von Teilnehmern zu unterscheiden.
Zum Beispiel können
Teilnehmer in die Klassen Gold, Silber und Bronze unterteilt werden,
wobei Gold-Benutzer Zugriff auf Daten-Frames mit Meta-Datenwerten
m 1, m2 oder m3 haben, Silber-Benutzer Zugriff auf m1 oder m2 haben
und Bronze-Benutzer nur Zugriff auf m1haben. Als Gegenleistung für eine Zahlung
während
der Sitzung kann der Benutzer sein Abonnement aufwerten, z.B. von
Bronze zu Silber, und dadurch Zugriff auf Programmmaterial erhalten,
das in Frames mit m2 Meta-Datenwerten übertragen
wird, zusätzlich
zu Material, das in Frames mit m 1 Meta-Datenwerten übertragen
wird. Die Änderung wird
von dem Daten-Server bewirkt, der eine Steuermeldung an das gesicherte
Modul überträgt und eine Schlüsselerzeugung
für m2-Frames
zusätzlich
zu m1-Frames anfordert.
-
Jeder
Daten-Frame oder ADU kann mit einem Frame-Typ gesendet werden, durch
den die Frames auf unterschiedliche Arten erhalten oder gesteuert
werden können.
Zum Beispiel kann ein Benutzer für
eine Stunde eines Videostroms bezahlen, wobei aber Werbung und Vor-/Abspann
nicht zu dieser Stunde zählen.
In diesem Fall umfasst jeder Frame einen Typ, der signiert oder
verschlüsselt
sein kann, mit einer weiteren Schlüsselsequenz, die den Frame
als sich auf gebührenpflichtige
oder nicht gebührenpflichtige
Daten beziehend identifiziert. Ein Anbieter von Werbung kann für die Kosten
der Netzübertragung
von z.B. Werbung zahlen unter der Bedingung, dass der Benutzer seine
Empfangsbestätigung
zurückgibt.
Dieser Mechanismus kann auch in Systemen des Typs benutzt werden,
in denen ein Benutzer dafür
bezahlt wird, Werbung zu erhalten.
-
Vor
dem Beginn einer Sitzung kann ein Kunden-Terminal 2 mit
dem Betreiber des Datennetzes 3 einen Vertrag über eine
Dienstqualität
(QoS – Quality
of Service) abgeschlossen haben, was erfordert, dass eine bestimmte
minimale Anzahl von Frames pro Zeiteinheit geliefert werden muss.
Wenn daraufhin durch eine Überlastung
in dem Netzwerk 2 die Rate der Frame-Lieferung unter die
in dem Vertrag spezifizierte Rate fällt, fordert das Kunden-Terminal 2 von
dem Daten-Server 1 eine
Rückerstattung
der Gebühren
für diese
Sitzung. Um diese Anforderung zu validieren, fordert der Daten-Server 1 von
dem gesicherten Modul 4 eine „Empfangsbestätigung". Diese Bestätigung umfasst
die in dem Datenspeicher gespeicherten Daten und liefert so eine
fälschungssichere
Anzeige der Anzahl der Frames, die entschlüsselt und dem Kunden im Verlauf
einer bestimmten Sitzung zur Verfügung gestellt wurden.
-
2 zeigt
die hauptsächlichen
funktionalen Komponenten des Kunden-Terminals, die für die vorliegende
Erfindung relevant sind. Eine Netz-Schnittstelle 22 kommuniziert
Daten-Frames an das und von dem Datennetz. Die Daten-Frames gehen
von der Schnittstelle 22 an ein gesichertes Modul 23.
Das gesicherte Modul 23 weist Teilmodule auf, die ein Entschlüsselungs-Modul
D, ein Schlüssel-Erzeugungs-Modul K und einen gesicherten
Speicher S aufweisen. Das Schlüssel-Erzeugungs-Modul
leitet eine Reihe von Schlüsseln
an das Entschlüsselungs-Modul,
das eine Reihe von Daten-Frames entschlüsselt, die es von der Schnittstelle 22 erhalten
hat, und leitet sie an ein Anwendungsschicht-Modul 24.
Dieses führt
eine weitere Verarbeitung durch und übermittelt die entstehenden
Daten an eine Ausgabe-Vorrichtung, die in diesem Beispiel eine Videoanzeigeeinheit
VDU 25 ist. In einer bevorzugten Implementierung kann die
Schnittstelle 22 in Hardware durch ein ISDN-Modem und in
Software durch einen TCP/IP-Stack ausgeführt werden. Das gesicherte
Modul 23 kann zum Beispiel eine Smartcard sein, die an
das Kunden-Terminal über
ein PCMCIA-Socket angeschlossen ist. Die Smartcard kann eine einer
Anzahl von standardmäßigen Datenschnittstellen
verwenden, wie die Java-Card-API (Application Programmer's Interface) von
Sun Microsystems oder die Smartcard-Architektur von Microsoft. Alternativ
kann das gesicherte Modul von einer PCI kryptographischen Co-Prozessor-Karte dargestellt
werden, wie sie kommerziell von IBM erhältlich ist.
-
8 zeigt
eine Software-Architektur für
das Kunden-Terminal. Die Anwendungsschicht an dem Terminal wird
von einem Entschlüsselungs-Datenkanal
unterstützt,
der wiederum über
einer Datenkanalschicht liegt, die z.B. mit einem Netzwerk verbunden
ist. Der Entschlüsselungs-Datenkanal
steht in Verbindung mit einem Entschlüsselungs-Modul. Dieses Entschlüsselungs-Modul
ruft Res sourcen in einem gesicherten Modul (innerhalb des gestrichelten
Kastens gezeigt), das eine Empfangs-Schlüssel-Erzeugungsvorrichtung,
eine Schlüssel-Erzeugungsvorrichtung
und einen Bestätigungs-Speicher
aufweist. Es ist offensichtlich, dass diese Architektur nur ein
Beispiel ist und dass Alternativen innerhalb des Umfangs der Erfindung
möglich
sind. Zum Beispiel kann sich der Bestätigungs-Speicher außerhalb
des gesicherten Moduls befinden.
-
9 zeigt
eine entsprechende Architektur für
einen Datenserver. Sie weist den Sender, den Verschlüsselungs-Datenkanal,
die Verschlüsselungsvorrichtung
und die Schlüssel-Erzeugungsvorrichtung
auf.
-
3 zeigt
die Hauptphasen in dem Betrieb des oben beschriebenen Systems. In
der Phase P1 verifiziert der Server, ob das gesicherte Modul in
dem Kunden-Terminal vertrauenswürdig
ist und eine bekannte Identität
besitzt. In der Phase P2 wird das gesicherte Modul initialisiert,
um Daten für
eine bestimmte Sitzung zu entschlüsseln. In der Phase P3 werden
die Daten übertragen
und eine Entschlüsselung
durchgeführt.
Während
dieser Phase kann eine Steuermeldung an das Steuerungsmodul gesendet
werden, um zum Beispiel die Anzahl der Frames zu modifizieren, auf
die der Benutzer zugreifen darf. In der Phase P4, die optional ist,
wird eine Bestätigung
erzeugt. Diese Phasen werden nun detaillierter erläutert.
-
Wenn
das gesicherte Modul beispielsweise eine Smartcard ist, dann wird
diese Smartcard von dem Hersteller mit einem eindeutigen öffentlichen/privaten
Schlüsselpaar
ausgegeben. Dieses Schlüsselpaar
kann von einer vertrauenswürdigen
dritten Partei zertifiziert werden. In der Phase P1 führt der
Server Schritte aus, um zu bestätigen,
dass die Smartcard tatsächlich
von einem vertrauenswürdigen
Lieferanten stammt. Die Schritte der Phase P1 werden in 4 gezeigt.
In Schritt S 1 erzeugt der Server einen Zufalls-String. In Schritt S2
sendet der Server den Zufalls-String über das Datennetz an das Kunden-Terminal. In Schritt
S3 wird der Zufalls-String an das gesicherte Modul übermittelt
(z.B. die Smartcard). In Schritt S4 signiert die Smartcard den Zufalls-String.
In Schritt S5 sendet die Smartcard den signierten String zusammen
mit dem relevanten öffentlichen
Schlüssel
zurück
an die auf dem Kunden-Terminal laufende Anwendung. In Schritt S6
sendet diese Client-Anwendung den signierten String und den öffentlichen
Schlüssel über das
Datenkommunikationsnetz an den Server zurück. In Schritt S7 verifiziert
der Server den signierten Zufalls-String.
-
Wie
in 5 gezeigt, erzeugt (s51) der Server, um das gesicherte
Modul zur Entschlüsselung
von Daten in einer bestimmten Sitzung einzurichten, zuerst einen
Ursprungswert zur Verwendung mit einer geeigneten pseudo-zufälligen oder
chaotischen Funktion, um eine Reihe von Schlüsseln zu erzeugen. Er erzeugt
auch einen Sitzungs-Schlüssel (s52).
Der Server verschlüsselt
den Ursprungswert und eine maximale Anzahl von zu erzeugenden Schlüsseln unter
Verwendung des öffentlichen
Schlüssels
des gesicherten Moduls (s53). Dann überträgt er den verschlüsselten
Ursprungswert und die maximale Anzahl der zu erzeugenden Schlüssel und
den Sitzungs-Schlüssel
an das Kunden-Terminal (s54). Die Client-Anwendung übermittelt
den Ursprungswert und den Sitzungs-Schlüssel an das gesicherte Modul
(s55). Das gesicherte Modul setzt einen Paket-Zähler auf Null (s56) und initialisiert
eine Sequenz-Erzeugungsvorrichtung mit dem Ursprungswert (s57).
Das Kunden-Terminal ist dann bereit, Daten-Frames zu empfangen und zu entschlüsseln.
-
Der
Server sendet daraufhin eine Reihe von Frames an den Client. Jeder
Frame besitzt eine Frame-Nummer (hier auch als Paketnummer bezeichnet).
Mit jedem Frame kann auch ein Sitzungs-Schlüssel übertragen werden. Die Folge
der Schritte für
den n-ten Frame wird in 6 dargestellt. In Schritt s61
sendet der Server den verschlüsselten
n-ten Frame an den Client. Der Client fordert den Schlüssel x für den Frame
n von dem gesicherten Modul an (s62). Das gesicherte Modul zeichnet
die Anforderung auf (s63). Die Smartcard sendet dann den Schlüssel x an
den Client zurück
(s64). Der Client entschlüsselt
den Frame unter Verwendung von x (s65). Der Client prüft, um festzustellen,
ob der Frame der letzte der Sitzung ist (s66).
-
Wenn
nicht, werden die Schritte für
den n+1sten und nachfolgende Frames wiederholt.
-
Zum
Aufbau der Sitzung hat der Kunde vorher eine Übereinkunft mit dem Diensteanbieter
bezüglich dem
Grad der Dienstqualität
für die
Sitzung verhandelt. Für
eine Anwendung wie Video auf Bestellung kann dieser Grad streng
sein: zum Beispiel kann der Kunde verlangen, dass kein Frame der
Anwendungsschicht während
der Übertragung
verloren geht. Wenn dann dieser Grad der Dienstqualität nicht
erreicht wird, fordert der Kunde eine Rückerstattung von dem Diensteanbieter.
Die Anforderung für
eine Rückerstattung
kann zum Beispiel spezifizieren, dass es einen Frame-Verlust zu
einer bestimmten Zeit während
der Video-Übertragung gab.
Bei der Verarbeitung einer derartigen Anforderung fordert der Server
von dem Kunden eine Bestätigung an.
Wie in 7 gezeigt, fordert in Schritt s71 der Client eine
Bestätigung
für eine
bestimmte Sitzung s von dem gesicherten Modul an. Das gesicherte
Modul liest die Daten, die es für
diese Sitzung gespeichert hat, und erzeugt eine Bestätigung mit
diesen Daten (s72). Das gesicherte Modul signiert die Bestätigung mit
dem privaten Schlüssel
des gesicherten Moduls (s73). Das gesicherte Modul sendet die signierte
Bestätigung
an den Client zurück
(s74). Der Client wiederum überträgt die signierte
Bestätigung
an den Server (s75). Der Server überprüft die Signatur
auf der Bestätigung
unter Verwendung des öffentlichen
Schlüssels
des gesicherten Moduls (s76). Der öffent liche Schlüssel kann
aus einer an dem Server gespeicherten Datenbank gelesen werden. Nach
der Verifizierung der Signatur kann der Server den Anspruch des
Kunden für
eine Rückerstattung
unter Verwendung der in der Bestätigung
enthaltenen Daten überprüfen. Diese
Daten können
zum Beispiel eine Diskrepanz zwischen der Anzahl von in einer Sitzung
entschlüsselten
Frames und der von dem Server übertragenen
Anzahl zeigen, wodurch der Anspruch des Kunden, dass ein Frame verloren
ging, bestätigt
wird.
-
Unter
Verwendung der folgenden Notation
sign(k, d) – d signiert
mit Schlüssel
k (d.h. d und die Signatur von d mit k)
enca(k, d) – d asymmetrisch
verschlüsselt
mit Schlüssel
k
encs (k, d) – d
symmetrisch verschlüsselt
mit Schlüssel
k
können
die oben beschriebenen Schritte wie folgt zusammengefasst werden:
-
1. Bestätigen der
gesicherten Raum-ID
-
Die
Aufgabe besteht hier darin, zu bestätigen, dass der gesicherte
Raum ein Raum ist, dem der Sender vertrauen kann.
- 1.
Sender erzeugt einen Zufalls-String r (Ad-hoc)
- 2. Sender sendet r an Empfänger
- 3. Empfänger
sendet r an gesicherten Raum
- 4. Gesicherter Raum signiert r mit privatem Schlüssel s,
um sign(s, r) zu erzeugen
- 5. Gesicherter Raum sendet sign(s, r) und öffentlichen Schlüssel p,
der von TTP mit seinem privatem Schlüssel t signiert wurde (wodurch
sign(t, p) erzeugt wird), an Empfänger zurück
- 6. Client sendet [sign(s, r), sign(t, p)] an Sender zurück
- 7. Sender überprüft sign(t,
p) mit TTP (entweder durch Aufrufen TTP-Server oder unter Verwendung des öffentlichen
Schlüssels
TTPs im Cache)
- 8. Sender überprüft sign(r,
s) mit p
-
2. Einrichten des Ver-/Entschlüsselungs-Systems
zum Entschlüsseln
von Daten
-
Der
Sender muss das Schlüssel-System
derart einrichten, dass er eine Sequenz von Nummern zum Entschlüsseln jedes
Pakets erzeugen kann. Diese Sequenz wird eine chaotische/pseudo-zufällige Sequenz sein.
- 1. Sender erzeugt einen Ursprungswert v
- 2. Sender erzeugt einen Sitzungs-Schlüssel k
- 3. Sender verschlüsselt
v unter Verwendung des öffentlichen
Schlüssels
P des gesicherten Raums und erzeugt enca(p, v)
- 4. Sender sendet [k, enca(p, v)] an Client
- 5. Client sendet [k, enca(p, v)] an Karte
- 6. Ver-/Entschlüsselungs-System
setzt Paket-Zähler
auf Null
- 7. Ver-/Entschlüsselungs-System
entschlüsselt
enca(p, v) unter Verwendung geheimen Schlüssels s
- 8. Ver-/Entschlüsselungs-System
initialisiert Sequenz-Erzeugungsvorrichtung
mit v
-
Die
Sitzungsinformation kann aufweisen:
im Klartext gesendet:
Sitzungsschlüssel
Verschlüsselt gesendet:
Ursprungswert
Typ
der Sequenz-Erzeugungsvorrichtung
Bestätigungstyp (für Nicht-Zurückweisung)
Maximale
Anzahl der zu erzeugenden Schlüssel
(für Multicast-Schlüssel-Management)
-
In
diesem Szenario befinden sich eine begrenzte Anzahl von Sequenz-Erzeugungsvorrichtungen
und Bestätigungen,
die als Identifizierer verwendet werden können, die als Teil der Sitzungsinformation
gesendet werden. Alternativ kann ein gesicherter Klassenlader implementiert
werden, wodurch neue Sequenz-Erzeugungsvorrichtungen und Bestätigungen
in das Verschlüsselungssystem
hochgeladen werden können.
Ein weiterer Aspekt des Aufbaus einer Sitzung ist eine Sitzungsänderung.
Der Benutzer kann für
den Erhalt einer bestimmten Menge von Daten zahlen und später für mehr Daten
zahlen. Dies kann durch ein Aktualisieren der Sitzungsinformation
(z.B. durch Erhöhen
der maximalen Anzahl von zu erzeugenden Schlüsseln) gehandhabt werden, während die
Sitzung aktiv ist.
-
3. Empfangen
und Entschlüsseln
von Daten
-
Der
Sender sendet eine Sequenz von Frames an dem Empfänger, jeweils
mit einer Frame-Nummer und einem Sitzungs-Schlüssel.
- 1.
Sender verschlüsselt
Frame fn, k mit Frame-Schlüssel
xn, k, um encs(xn, k, fn, k) für
Frame n in Sitzung k zu erzeugen
- 2. Sender sendet encs(xn, k, fn, k) an Empfänger
- 3. Empfänger
fordert Schlüssel
xn, k für
Frame n in Sitzung k von Ver-/Entschlüsselungs-System an
- 4. Ver-/Entschlüsselungs-System
speichert Anforderung mit erhaltenem Objekt (für Nicht-Zurückweisung )
- 5. Ver-/Entschlüsselungs-System
sendet Schlüssel
xn, k an Empfänger
zurück
- 6. Empfänger
entschlüsselt
encs(xn, k, fn, k) unter Verwendung von xn, k, um fn, k zu erhalten
-
4. Erzeugung einer Bestätigung (für Nicht-Zurückweisung)
-
- 1. Empfänger
fordert Bestätigung
für Sitzungs-Schlüssel s von
Ver-/Entschlüsselungs-System
an
- 2. Ver-/Entschlüsselungs-System
erzeugt Bestätigung
für Sitzungs-Schlüssel k,
ck
- 3. Ver-/Entschlüsselungs-System
signiert ck mit privatem Schlüssel
s und liefert sign(s, ck)
- 4. Ver-/Entschlüsselungs-System
sendet sign(s, ck) an Empfänger
zurück
- 5. Empfänger
sendet sign(s, ck) an Sender
- 6. Sender vergleicht sign(s, ck) mit öffentlichem Schlüssel p des
Ver-/Entschlüsselungs-Systems,
von dem bekannt ist, dass es von dem Client benutzt wird (nachschlagen
in Datenbank)
- 7. Sender gibt Rückerstattung,
wenn erforderlich
-
Die
zum Erzeugen von Schlüsseln
in den obigen Beispielen verwendete Sequenz kann an Kunden-Terminals
unter Verwendung von HTTP (Hyper Text Transport Protocol) als Java-Code
verteilt werden. Eine geeignete chaotische Funktion ist: xn+1 = 4rxn(1 – xn)
-
Wenn
r = 1, nimmt und berechnet diese Funktion Zahlen in dem Bereich
0 bis 1. Eine derartige chaotische Funktion hat die Eigenschaft,
dass alle Fehler in dem Wert von xn exponentiell
ansteigen, wenn die Funktion wiederholt wird. In Betrieb verwendet
das gesicherte Modul intern eine höhere Genauigkeit als die Genauigkeit
der für
den Client verfügbaren
Schlüsselwerte.
Zum Beispiel kann das gesicherte Modul intern 128-Bit Zahlen verwenden
und dann an den Client nur die signifikantesten 32 Bits zurücksenden.
Beim Erzeugen der Schlüs selwerte
wird die chaotische Funktion wiederholt, bis der Fehler in dem an
den Client zurückgesendeten Wert
größer wird
als der Bereich. Dies verhindert, dass der Benutzer die Sequenz
aus den von dem gesicherten Modul zurückgesendeten Werten erraten
kann.
-
Als
eine alternative oder zusätzliche
Sicherheitsmassnahme kann eine andere Funktion für jede Sitzung verwendet werden.
Dies dient dazu, die Möglichkeit,
dass der Kunde Schlüsselwerte
vorhersagen kann, weiter zu reduzieren.
-
10A zeigt das Format eines in einer ersten Implementierung
des oben beschriebenen Systems übertragenen
Frames. Das Format des Frames ist wie folgt:
- 1.
Signatur von Hash (2)
- 2. Hash von 3, 4, 5, 6
- 3. Schlüssel-ID
- 4. Stopp-Flag (j/n) (verschlüsselt)
- 5. Kontaktiere-Sender-Flag (j/n) (verschlüsselt)
- 6. Karten-IDs (verschlüsselt)
- 7. Frame-Daten
-
Der
Frame wird an der Netzschnittstelle eines Kunden-Terminals erhalten
und die Felder 1 bis 6 werden an das gesicherte Modul übertragen.
Diese weisen einen verschlüsselten
Block auf, der sowohl Steuerfelder als auch eine Schlüssel-Identität enthält. Dieser
Block wird in dem gesicherten Modul entschlüsselt. Wenn die Karten-ID die
des fraglichen gesicherten Moduls ist, überprüft das gesicherte Modul die
Felder 4 und 5, das Stopp-Flag und das Kontaktiere-Sender-Flag.
Wenn das Stopp-Flag gesetzt ist, werden keine weiteren Schlüssel mehr
ausgegeben. Wenn das Kontaktiere-Sender-Flag gesetzt ist, führt die
Karte einen entfernten Prozeduraufruf (remote procedure call) an
den Sender (oder den Repräsentanten
des Senders) durch und erhält
eine neue Richtlinie zur Erzeugung von Schlüsseln. Das gesicherte Modul
gibt dann, wenn es nicht anderweitig von den Steuerfeldern angewiesen
wird, einen Schlüssel
aus zur Verwendung bei der Entschlüsselung der in Feld 7 enthaltenen
Frame-Daten. Die gesamte Länge
der an das gesicherte Modul übermittelten
Steuerfelder und insbesondere die Anzahl der Karten-IDs (Feld 6)
kann variabel sein, wobei in diesem Fall zusätzlich zu den gezeigten Feldern
ein weiteres nicht verschlüsseltes
Feld vor den Steuerfeldern aufgenommen wird, um die Gesamtlänge der
Steuermeldung anzuzeigen. Wenn das gesicherte Modul kein Steuerfeld
empfängt,
hört es
auf, Schlüssel
auszugeben. Auf diese Weise kann weder ein unbeabsichtigter Verlust
einer Steuermeldung noch eine absichtliche Entfernung einer derartigen
Meldung dazu führen,
dass der Kunde einen nicht autorisierten Zugriff auf Daten erhält.
-
10B zeigt das Format eines in einer zweiten Implementierung
des oben beschriebenen Systems übertragenen
Frames. Das Format des Frames ist wie folgt:
- 1.
Signatur von Hash (2) (signiert mit dem öffentlichen Schlüssel des
Senders)
- 2. Hash von 3, 4 und 5
- 3. Schlüssel-ID
- 4. Steuermeldung (verschlüsselt)
- 5. Karten-ID(s) (verschlüsselt)
- 6. Frame-Daten
-
Der
Stack übermittelt
die Felder 1, 2, 3, 4 und 5 in das gesicherte Modul, um den Schlüssel für 6 zu erhalten.
Die Verwendung dieses Frame-Formats beruht auf einem Wahrscheinlichkeitsverfahren
zum Steuern des Zugriffs. Jedes Mal, wenn ein Frame gesendet wird,
enthält
er eine verschlüsselte
Steuermeldung und eine Karten-ID, die zusammen mit der Schlüssel-ID
in den gesicherten Raum übermittelt werden
müssen,
um den Schlüssel
zu erhalten. Die Steuermeldung kann ein Code sein, der den Befehl „Gib keine
weiteren Schlüssel mehr
aus" darstellt.
Wenn die Karte dies erhält
und die Karten-ID(s) sich darauf beziehen, führt sie den Befehl aus. Wenn
mehrere Benutzer aus einer Sitzung ausgeschlossen werden sollen,
werden ihre Karten-ID(s) durch unterschiedliche Pakete rotiert.
In diesen Beispielen stellt die Karten-ID das „Benutzer-Identitätsfeld" dar, auf das sich
die folgenden Claims beziehen.
-
Die 11 zeigt
die mit dem Aufbau einer Sitzung verbundenen Meldungsflüsse. Meldung
1 ist eine Anforderung von einer Anwendung an dem Kunden-Terminal
für einen
Zugriff auf beispielsweise 100 Daten-Frames. Auf diese Meldung können andere
Transaktionen (nicht gezeigt) folgen, in Folge derer der Kunde für die angeforderten
Daten bezahlt, zum Beispiel unter Verwendung einer Kreditkartennummer.
Daraufhin überträgt der Sender
eine Aufbau-Meldung, Meldung 2, an ein gesichertes Modul-Proxy auf
dem Rechner des Kunden. Das Steuerfeld dieser Aufbau-Meldung wird
an das gesicherte Modul selbst weitergeleitet (Meldung 3). Das Feld
kann zum Beispiel die Anzahl der zu erzeugenden Schlüssel und
für welche
Frame-Nummern spezifizieren. Es kann auch den Ursprungswert zur
Schlüsselerzeugung
enthalten. Eine Rückmeldung
wird dann von dem gesicherten Modul an den Proxy (Meldung 4), von
dem Proxy an den Sender (Meldung 5) und von dem Sender an die Anwendung,
welche die ursprüngliche
Anforderung erzeugt hat (Meldung 6), zurückgesendet. Die Schnittstelle
zwischen dem Sender und dem Proxy, die durch die gestrichelte Ellipse
dargestellt wird, kann zum Beispiel unter Verwendung von Java-RMI
(Remote Method Invocation) oder, wie in diesem Fall, einer CORBA-Schnittstelle
implementiert werden.
-
Um
die Sicherheit des Systems durch Verringern der Möglichkeit,
dass Schlüsselwerte
von dem Benutzer vorhergesagt werden können, zu erhöhen, können Daten-Frames
unter Verwendung zweier Schlüssel-Sequenzen
statt einer verschlüsselt
werden. Die erste ist für
den Schlüssel
zur Frame-Verschlüsselung, wie
oben beschrieben. Die zweite Sequenz ist für einen Frame-Identifizierungs-Schlüssel. Jedes
Paket innerhalb eines Frames enthält zumindest eine Frame-Sequenz-Nummer n,
die von Null inkrementiert werden kann, und einen Frame-Identifizierungs-Schlüssel in, der aus der zweiten Sequenz erzeugt wird,
und die Daten, die mit einem Schlüssel en verschlüsselt werden,
der aus der ersten Sequenz erzeugt wurde. Zur Entschlüsselung der
Daten ist der Schlüssel
en aus dem Entschlüsselungs-System erforderlich.
Der Schlüssel
wird identifiziert, indem n geliefert wird, und bewiesen wird, dass
es einen Frame gibt, der mit diesem Schlüssel verschlüsselt wurde,
indem in geliefert wird. Um die Sequenz
zu knacken, kann ein Angreifer nur eine begrenzte Anzahl von Schlüsseln verwenden,
außer
er/sie kann die Identifizierungs-Sequenz
aus derselben begrenzten Anzahl von Schlüsseln knacken. Zusätzlicher
Schutz kann vorgesehen werden, indem die Sequenz-Erzeugungsvorrichtung sich weigert,
mehr Schlüssel
zu liefern, wenn die Anwendung einen falschen Frame-Identifizierungs-Schlüssel liefert,
und es optional der Anwendung verweigert wird, die Sitzung nochmals
neu zu starten.
-
12 zeigt
ein weiteres alternatives Ausführungsbeispiel,
in dem mehrere Daten-Quellen 1, 1a Daten an die
Kunden-Terminals kommunizieren. Obwohl zur einfacheren Darstellung
nur zwei Daten-Quellen
gezeigt sind, kann das System in der Praxis viel mehr Quellen umfassen.
Wo mehrere Quellen Daten erzeugen, ist es möglich, die Erfindung auf einer
pro-Quelle-Grundlage zu verwenden, wobei jeder Empfänger in
die Aufbau-Phase mit jeder Quelle eintritt. Für eine große Anzahl von Quellen wird
dies jedoch nicht-skalierbar und zeitraubend. Stattdessen besteht
in einer bevorzugten Implementierung eine an einem Empfänger ankommende
Sequenz-ID einer ADU aus zwei Teilen, der Sender-ID und der pro-Sender-Sequenz-ID.
Die Sender-ID kann seine IP-Adresse und Port-Nummer sein, in dem
Fall würden
diese sich bereits in dem Header jedes Pakets befinden. Die Sender-ID
wirkt als ein Offset zu dem primären
Ursprungswert, um einen sekundären
Ursprungswert zu erzeugen (z.B. durch eine XOR-Verknüpfung mit dem Ursprungswert).
Somit betreibt jede Smartcard so viele Schlüssel-Sequenzen, wie sie Sender
hört, wobei
jede Sequenz tatsächlich
von demselben primären
Ursprungswert abstammt, dann aber auf einen sekundären Ursprungswert
versetzt wird, bevor jede Sequenz auf ähnliche Weise wie die unten
beschriebenen pseudo-zufälligen
oder chaotischen Sequenzen gestartet wird.
-
Wenn
eine ADU ankommt, wird die Sender-ID untersucht, um die korrekte
Sequenz zu finden, dann ermöglicht
die Sequenz-ID die Erzeugung des korrekten Schlüssels. Dadurch muss jeder Empfänger für alle Sender
in einer Sitzung mit vielen Sendern nur einmal durch den Aufbau
gehen.
-
Der
Sitzungs-Initiator erzeugt den primären Ursprungswert und übermittelt
ihn unter Verwendung einer herkömmlichen
kryptographischen Verschlüsselung
(z.B. mit dem öffentlichen
Schlüssel
jedes Senders) an jeden Sender. Jeder Sender versetzt den primären Ursprungswert
mit seiner eigenen ID, um den sekundären Ursprungswert zu erzeugen,
den er zum Start der Schlüssel-Sequenz
für gesendete
ADUs verwendet.
-
Jeder
Sender kann jeden Empfänger
durch die Aufbau-Phase führen,
indem er ihm den primären
Ursprungswert übermittelt,
unter der Annahme, dass es einen Weg für jeden Sender gibt, festzustellen,
wer ein autorisierter Empfänger
ist (z.B. ein von dem Sitzungs-Initiator geliefertes und signiertes
Verzeichnis oder ein Token, den der Initia tor jedem Empfänger als
Gegenleistung für
eine Zahlung gibt, den jeder Empfänger jedem Sender zeigen muss).
-
Die
oben beschriebenen Beispiele können
verwendet werden im Zusammenhang eines Netzes einer Interessengemeinschaft
(COIN) oder eines virtuellen privaten Netzes (VPN). In diesem Fall
unterteilt jede Quelle von Information ihre Daten in ADUs und überträgt jede
mit unterschiedlichen Schlüsseln
verschlüsselte ADU über das
COIN. Dieselbe ADU wird immer mit demselben Schlüssel übertragen, unabhängig davon,
wie oft sie an unterschiedliche Parteien innerhalb des COIN übertragen
wird. Informationsquellen können
direkt, wie die an dem COIN beteiligten Parteien, oder indirekt
sein, wie Web-Server
oder Cache-Speicher, die allen Parteien innerhalb des COIN gemeinsam
zugänglich
sind. In dem indirekten Fall wird die Information an den Web-Server
oder Cache mit der Sequenznummer im Klartext, aber mit verschlüsselten
Daten gesendet. Sie wird in derselben verschlüsselten Form gespeichert, wie
sie zuerst übertragen
wird. Erst wenn der letzte Empfänger
auf den Web-Server oder Cache zugreift, erzeugt die Smartcard den
Schlüssel
für die
Entschlüsselung und
speichert den Erhalt der Information. Die oben beschriebenen Wasserzeichen-Techniken
können
verwendet werden, wenn eine Zurückverfolgung
bezüglich
wer entschlüsselte
Daten weitergeleitet hat, erforderlich ist.
-
Unten
folgende Tabelle 1 listet einen Java-Code zur Implementierung einer
chaotischen Funktion auf. Sie liefert die nächste Zahl in einer Sequenz
oder die n-te Zahl in einer Sequenz.
-
Die
Schlüsselwerte
müssen
nicht notwendigerweise von einer Sequenz erzeugt werden. Stattdessen können andere
Funktionen der Form k = f(Ursprung, Frame-ID) verwendet werden,
wobei k ein Schlüsselwert ist.
Zum Beispiel können
die binären
Werte der Frame- Identität verwendet
werden, um aus dem Paar von Funktionen eine auszuwählen, die
zum Betrieb mit dem Ursprungswert verwendet wird. Vorzugsweise wird
ein Paar rechnerisch symmetrischer Funktionen verwendet. Zum Beispiel
können
rechts- oder links-verschobene X-ODER-Verknüpfungen (exklusive ODER) abhängig davon
ausgewählt
werden, ob ein binärer
Wert 1 oder 0 ist. Wenn man diese Funktionen jeweils A und B bezeichnet,
dann hat beispielsweise Frame Nummer sechs, d.h. 110, einen Schlüssel, der
durch aufeinander folgende Abläufe
AAB mit dem Ursprungswert erzeugt wurde.
-
-
-
-
