-
Technisches Gebiet
-
Die
vorliegende Erfindung betrifft die schwache Authentisierung von
Information und insbesondere die Authentisierung von Information,
die in einer indizierten, verschachtelten oder anderweitig verknüpfter Form
angeordnet ist. Insbesondere zeigt die Erfindung ein Verfahren und
eine Vorrichtung zur Authentisierung von Information und ein Verfahren
und eine Vorrichtung zur Erzeugung von authentisierbaren Informationselementen.
-
Hintergrund der Erfindung
und Stand der Technik
-
Mit
der Zunahme des Austausches von Daten über miteinander verbundene
Computernetzwerke haben die alten Probleme, wie sicherzustellen
ist, dass über
ein Netzwerk empfangene Information nicht unterwegs verändert wurden,
oder dass sie von der Person stammt, die beansprucht, sie gesendet
zu haben, wachsende Wichtigkeit. Um diese Probleme anzusprechen,
entstand ein Zweig der Kryptologie, der als „Authentisierung" bekannt ist, der
Verfahren zur Authentisierung empfangener Information behandelt,
um entweder den Sender zu bestimmen und/oder dass die Information
unterwegs nicht verändert
wurde. Die hauptsächlichen
Verfahren der Authentisierung, die bereits in der Technik bekannt
sind, werden im Folgenden beschrieben.
-
Es
gibt mehrere klassische Quellen-Authentisierungsschemen für eine Broadcast-Kommunikation,
die in der Technik bekannt sind: i) das weithin bekannte klassische
Verschlüsselungssystem
mit öffentlichem
Schlüssel;
ii) die Nachrichten-Authentisierungs-Codes (MACs – Message
Authentication Codes), die von Canetti et al in „Efficient and Secure Source
Authentication for Multicast",
Autor Perrig, Canetti et al vorgeschlagen werden; iii) das bekannte TESLA-Schema;
und iv) das BIBA-Schema. Die oben erwähnten ersten zwei Verfahren
werden im Folgenden detailliert beschrieben aufgrund ihrer Relevanz
für die
vorliegende Erfindung.
-
Um
für eine öffentliche
Verschlüsselung
eine Quellen-Authentisierung für
einen Broadcast-Kanal vorzusehen, muss ein asymmetrischer Algorithmus verwendet
werden. Das Konzept einer asymmetrischen Sicherheit wurde eingeführt mit
der „öffentlicher
Schlüssel"-Kryptographie von Diffie und Hellman
in den 1970ern, aber nun gibt es ein Anzeichen, dass die Regierung
des Vereinigten Königreichs
die asymmetrische Sicherheit früher
entdeckt hat. Es gibt mehrere asymmetrische Algorithmen, die für diese
Art des Betriebs geeignet sind: RSA, ElGamal und Rabin, und zur
Verwendung bei der Authentisierung werden derartige Algorithmen
verwendet, um eine digitale Signatur der Information wie folgt zu
erzeugen.
-
Erstens
ist es für
einen Informationsanbieter erforderlich, ein öffentliches und privates Schlüsselpaar
zu erzeugen, wie in der Technik bekannt ist. Jeder Benutzer, der
eine Information von dem Informationsanbieter zu erlangen wünscht, muss
den öffentlichen
Schlüssel
des Anbieters erlangen und ihn speichern zur späteren Verwendung bei der Authentisierung
von Information.
-
Um
eine Authentisierung zu ermöglichen, wenn
der Informationsanbieter eine neue Information erzeugt, erzeugt
der Anbieter (typischerweise eine Art von Server) eine digitale
Signatur für
die Information durch Berechnen eines Hash-Werts für die Information
unter Verwendung einer bekannten Hash-Funktion. Der Hash-Wert wird
dann mit dem privaten Schlüssel
des Anbieters verschlüsselt,
um die Signatur zu liefern, und die Signatur wird an die Information
angehängt.
-
Um
die Information zu authentisieren, kann ein Empfänger, der die Information mit
der angehängten
Signatur empfangen hat, die verschlüsselte Signatur entschlüsseln unter
Verwendung des öffentlichen
Schlüssels
des Senders, wodurch der ursprüngliche
Hash-Wert wiedergewonnen wird. Durch Verwenden dann derselben Hash-Funktion auf der empfangenen
Information, um einen zweiten Hash-Wert zu erzeugen, und dessen Vergleichen
mit dem entschlüsselten
Hash-Wert ist es möglich,
auszusagen, ob die Daten bei der Übertragung verändert oder
beschädigt
wurden. Ferner bestätigt
die Fähigkeit,
den verschlüsselten
empfangenen Hash-Wert unter Verwendung des öffentlichen Schlüssels des Senders
zu entschlüsseln,
dem Benutzer, dass der Wert wahrscheinlich von dem Sender verschlüsselt wurde.
-
Somit
liefert die Verwendung von digitalen Signaturen, wie oben beschrieben,
sowohl eine Nichtabstreitbarkeit bzw. Verbindlichkeit durch den Sender
sowie eine Authentisierung der Nachricht.
-
Im
Folgenden werden verschiedene weitere Anforderungen für eine Verschlüsselung
mit öffentlichem
Schlüssel
beschrieben.
-
Schlüsselverwaltung
und Zertifikatsverteilung: Jeder Sender von Information muss an
die Empfänger
ein Zertifikat verteilen, das von einem Authentisierungsserver signiert
ist, das ihren öffentlichen
Schlüssel
enthält.
Dies bedeutet, dass jeder Empfänger
alle öffentlichen
Schlüssel
der Sender speichern muss.
-
Verifizierung:
Der Benutzer verwendet, um die Authentisierung zu prüfen, den
korrekten öffentlichen
Schlüssel
und verifiziert die digita le Signatur. Dieses Verfahren liefert
eine gute Leistung hinsichtlich der Sicherheit und für diese
Art der Anwendung ist es nicht erforderlich, einen langen Schlüssel zu verwenden,
128 Bits (oder 256 Bits) können
ausreichend sein.
-
Leistung:
Die Geschwindigkeit eines öffentlichen
Verschlüsselungsalgorithmus
ist langsamer als der normale Datenverschlüsselungsstandard (DES – Data Encryption
Standard) oder als mit einer Hash-Funktion. In der Software ist ein klassischer DES-Algorithmus
ungefähr
100-mal schneller als RSA, ferner sind klassische Hash-Funktionen schneller
als DES.
-
Eine
Verschlüsselung
mit öffentlichem Schlüssel kann
auch auf eine indizierte oder verknüpfte Information angewendet
werden (was die Basis des Problems der vorliegenden Erfindung bildet,
wie später
ersichtlich wird). Ein grundlegendes Indexauthentisierungsschema
unter Verwendung einer öffentlichen
Verschlüsselung
läuft ab
wie folgt:
(Terminologie: U ist der Empfänger der zu authentisierenden
Information; I_S ist ein Server, der eine Information erzeugt, die
Referenzen zu einer Information enthält, die von einem anderen I_S
oder einem anderen Server (S) erzeugt wird; A_S ist der Authentisierungsserver,
der die öffentlichen
I_S-Schlüssel verteilt;
und S ist ein Server der ursprünglichen
Information, die schließlich
von einem I_S referenziert wird).
- 1. U entscheidet,
von welchen I_Ss er Informationen empfangen möchte. Dies kann oft erreicht werden
durch Rückwärts-Suchen
der Informationsreferenzen, um herauszufinden, welcher I_S der ursprünglichen
Information entspricht, die von S verteilt wird (oder zu anderen
I_Ss in der Referenzkette). Zum Beispiel kann ein Client nach Web-Diensten
suchen, welche dieselben grundlegenden Merk male bieten, oder Indexankündigungen,
welche dieselbe Datenzufuhr referenzieren.
- 2. U sendet eine Anforderung an A_S und fragt nach den Zertifikaten
von I_S. Das Zertifikat enthält
die öffentlichen
Schlüssel
der Server, welche die Indizes erzeugen.
- 3. Wenn U eine Information von I_S empfängt, verifizieren sie die digitale
Signatur unter Verwendung des öffentlichen
Schlüssels
von I_S. Wenn die digitale Signatur nicht korrekt ist, wird die Nachricht
fallengelassen.
-
Nach
der Beschreibung der bekannten Techniken mit öffentlichem Schlüssel werden
nun die oben erwähnten
Nachrichten-Authentisierungs-Codes
(MACs – Message
Authentication Codes) beschrieben.
-
MACs
sind ein anderer Ansatz, um die Authentisierung eines Senders oder
einer Gruppe von Sendern in IP-Multicast zu erzielen, sie wurden
von Perrig, Canetti et al in [ibid] präsentiert. In Broadcast-Kommunikationen gibt
es viele verschiedene Szenarien, somit ist es schwierig, eine eindeutige
Lösung
für eine
Quellen-Authentisierung auszusuchen. MACs adressieren dieses Problem
durch Ermöglichen
einer guten Leistung in einem Szenario, wo es eine kleine Gruppe
von Sendern und eine große
Anzahl von Empfängern
gibt. Die Verwendung von MACs wird wie folgt zusammengefasst.
-
In
einem Szenario mit einem Sender hält jeder Sender einen Satz
von N Schlüsseln
und hängt an
jedes Paket N MACs an, wobei jeder MAC mit einem unterschiedlichen
Schlüssel
berechnet wird. Ein MAC ist eine pseudozufällige Funktion, die einen geheimen
Schlüssel
K und eine Nachricht M nimmt und einen Wert MAC(K, M) zurückgibt.
Die Eigenschaft dieser Funktion ist, dass ein Benutzer, der M und MAC
kennt, eine unbedeutende Wahrscheinlichkeit hat, denselben MAC zu
erzeugen, ohne den Schlüssel
zu kennen. Jeder Empfänger
hält einen
Teilsatz von N Schlüsseln
und verifiziert den MAC unter Verwendung der Schlüssel, die
er hält.
Wenn der Empfänger
mit diesem Schlüssel
den verwandten Teilsatz der MACs verifizieren kann, ist das Paket
authentisiert. Der wichtige Nachteil wird dargestellt von der Koalition
von „schlechten" Benutzern, aber
es ist mit einer geeigneten Auswahl der Schlüssel-Teilsätze möglich, diese Art des Problems
zu vermeiden. Das Verfahren kann einfach für ein Szenario mit vielen Sendern
unter Verwendung desselben Satzes von Schlüsseln erweitert werden. Jedoch
hält jeder
Sender einen anderen Satz von Schlüsseln, damit keine Koalition
von Sendern eine Nachricht fälschen
kann. Dieses Ziel wird erreicht durch Differenzieren der Sequenz
der Schlüssel
in primäre
und sekundäre Schlüssel. Jeder
sekundäre
Schlüssel
wird von dem primären
abgeleitet unter Verwendung einer pseudozufälligen Funktion, wobei der
primäre
Schlüssel
mit der öffentlichen
Identität
des Senders kontrollsummiert bzw. gehashed wird. Jeder Sender empfängt von
einem sicheren dritten Teilnehmer einen Satz von N sekundären Schlüsseln, während Empfänger einen
Teilsatz der primären
Schlüssel
halten. Die Empfänger
können
unter Verwendung der pseudozufälligen
Funktion und der öffentlichen
Identität
der Sender einen Teilsatz der primären Schlüssel berechnen. Wir bemerken,
dass dieses Verfahren probabilistisch ist, da es für einen
Angreifer schwierig ist, die Signatur zu fälschen.
-
U.S.-Patent
6,021,491 beschreibt Verfahren, Vorrichtungen und Produkte zum Verifizieren
der Authentizität
von Daten in einer oder mehreren Datendatei(en). Jede Datendatei
ist mit einem Identifizierer vorgesehen, wie eine Einweg-Hash-Funktion
oder eine zyklische Redundanzprüfung
(CRC – cyclic
redundancy checksum). Eine Signaturdatei, welche die Identifizierer
für eine
oder mehrere Datenda tei(en) enthält,
ist mit einer digitalen Signatur vorgesehen, die mit einem Signaturalgorithmus
erzeugt wird. Die Datendatei(en) und die Signaturdatei werden dann übertragen
oder anderweitig einem Benutzer zur Verfügung gestellt. Der Benutzer
verifiziert die digitale Signatur in der Signaturdatei unter Verwendung
eines Signaturverifizierungsalgorithmus. Sobald als authentisch
verifiziert, kann die Signaturdatei verwendet werden, jede der Datendateien
zu verifizieren. Eine Verifizierung der Datendateien kann erreicht
werden durch Vergleichen des Identifizierers für jede Datendatei mit dem entsprechenden
Identifizierer in der Signaturdatei. Wenn die Identifizierer in den
Daten- und Signaturdateien übereinstimmen, dann
kann die Datendatei als authentisch markiert werden. Wenn die Identifizierer
nicht übereinstimmen,
dann kann die Datendatei zurückgewiesen
werden oder anderweitig demgemäß behandelt
werden.
-
Die
Europäische
Patentanmeldung 1 089 516 beschreibt Verfahren und Systeme für einen
einzelnen Anmelde-Benutzer-Zugang zu mehreren Webservern. Ein Benutzer
wird authentisiert an einem ersten Webserver (z.B. durch Benutzername und
Passwort). Der erste Webserver liefert dem Benutzer eine Webseite
mit einem Dienstselektor (z.B. ein Hyperlink, der die URL eines
zweiten Webservers aufweist, der den von dem Selektor angezeigten Dienst
anbietet). Wenn der Benutzer den Dienstselektor aktiviert, konstruiert
und überträgt der erste Webserver
einen verschlüsselten
Authentisierungs-Token (z.B. ein Cookie) von dem ersten Webserver
an einen zweiten Webserver über
den Benutzer-Client. Der erste und der zweite Webserver teilen sich
eine Teil-Domain. Der Authentisierungs-Token weist eine Ablaufzeit
auf und wird von dem ersten Webserver digital signiert und an dem
zweiten Webserver authentisiert. Bei Authentisierung ermöglicht der
zweite Webserver dem Benutzer, an dem zweiten Webserver eine Sitzung
zu führen.
-
Die
internationale Patentanmeldung WO01/11843 beschreibt ein Verfahren
zum Kommunizieren von authentisierter Information, die ein digitales öffentliches
Schlüsselzertifikat
betrifft. Es wird eine Hash-Baumdatenstruktur erzeugt, die eine
vordefinierte Liste möglicher
Information enthält,
wie Autorisationen, Beschränkungen,
Privilegien oder Validitätsdaueranzeigen.
Die Elemente der Liste können Text
und codierte Werte umfassen. Jeder Listeneintrag ist vorangestellt
mit einem anderen zufälligen Daten(blocker)wert,
der sicher gespeichert und unmöglich
zu erraten ist. Jedes Listenelement wird kontrollsummiert bzw. gehashed,
um einen Blatt-Hash (leaf hash) zu erzeugen, die Blatt-Hashes werden kombiniert,
um einen Hash-Baum zu erzeugen, und der Wurzel(root)-Knoten des
Baums wird in ein digitales Zertifikat oder eine Nachricht eingebettet,
die unter Verwendung eines privaten Schlüssels signiert wird. Als Antwort
auf eine Anforderung für
eine authentisierte Information, die ein digitales öffentliches Schlüsselzertifikat
betrifft, gibt die Zertifikatsautorität das relevante Listenelement,
seinen Blockerwert und andere Hash-Werte frei, um das Listenelement
unter Verwendung des Wurzelknotens zu authentisieren, der in dem
digitalen Zertifikat eingebettet ist.
-
Nach
der Beschreibung der Hintergrundtechnik wird nun das spezifische
Problem, das von der vorliegenden Erfindung gelöst wird, in dem Kontext der
Hintergrundtechnik diskutiert.
-
Das
von der Erfindung adressierte Problem ist die effiziente Authentisierung
von Information, die als eine Zusammensetzung von Information empfangen
wird, die von mehreren Quellen stammt. Die zusammengesetzte Information
kann zusammen in einem einzelnen Paket enthalten sein oder alternativ kann
die Information als ein Graph miteinander verbundener Komponenten
geliefert werden, die andere Teilkomponenten betreffen. Zum Beispiel
kann eine Email frühere
Emails in dem Hauptteil (body) der Top-Level-Email enthalten. Jeder Email
in der Top-Level-Email kann eine Anzahl von anderen Nachrichten
enthalten und so weiter. Alle diese Komponenten werden dann zusammen
geliefert. Die Alternative kann eine Serie von Webseiten sein oder die
Verbindung von einzelnen Komponenten-Webdiensten, wobei nur die Top-Level-Seite
oder Webdienst anfänglich
abgerufen wird, aber dann wird in der Navigation der Information
oder der Verwendung des Webdienstes auf andere Komponenten zugegriffen.
-
Herkömmlicherweise
gibt es zwei Ansätze für das Problem.
Das erste Verfahren umfasst ein Authentisieren nur der Top-Level-Information,
unter der Annahme, dass der Anbieter der Top-Level-Information für die Authentizität der Teilkomponenten
garantieren kann. Dies ist typisch für das Lesen einer Email, die
andere Emails zitiert. Nur der letzte Sender der Information hat
eine angehängte
Signatur, die verifiziert wird durch die Verwendung einer öffentlichen Verschlüsselung
(siehe frühere
Technik für
eine technische Beschreibung). Der andere typische Ansatz, der in
verknüpften
Media- oder Komponentendiensten öfter
verwendet wird, ist, jede Komponente zu authentisieren, die von
einem anderen Server stammt. Oft ist dies, da der Server auch wünscht, den
Client zu authentisieren, der die Information anfordert. Die Information
ist eine Sammlung verknüpfter
Information, die möglicherweise
von unterschiedlichen Servern stammt. Zusätzlich werden diese Nachrichten von
einer großen
Gruppe von Clients gelesen, die nicht unbedingt dieselbe Navigationswurzel
teilen, aber beide Anforderungen für eine Authentisierung haben.
Ein Client, der beginnt, die Information von einem Punkt in dem
Informationsgraph zu navigieren, sollte einen zufriedenstellenden
Grad einer Authentisierung durchführen können.
-
Das
Problem besteht auch bei indizierten Nachrichtentechnologien, wie
das „Generic
Announcement Protocol",
das in unserer früheren internationalen
Patentanmeldung Nr. PCT/GB01/02681 beschrieben wird. In dieser Technologie
werden Nachrichten verwendet, um über die Existenz anderer Nachrichten
zu informieren, und sind in einer Baumstruktur miteinander verbunden.
Die Datennachrichten sind die Blätter
des Baums, während Nachrichten
höheren
Levels Indizes sind, welche die Nachrichten niedrigeren Levels betreffen
(die auch selbst Indexnachrichten sein können). Diese Nachrichten können von
einer Anzahl von Servern stammen und von einer großen Anzahl
von Clients empfangen werden. Abhängig davon, an welchen Daten- oder
Blatt-Nachrichten ein Client interessiert ist, kann er stattdessen
eine geringere Anzahl von Indexnachrichten hören. Jedoch werden nicht alle
Clients denselben Wurzelindex für
ihren Bedarf verwenden oder überhaupt
Indizes verwenden.
-
Wenn
die Komponenteninformation in der Form von Verweisungen zu anderen
Orten (und in dem Fall der Nachrichten, Zeiten) ist, gibt es eine Möglichkeit
für Betrüger, die
Komponenteninformation anzubieten, unabhängig davon, wie vertrauenswürdig der
Verweiser ist. Nur ein Authentisieren der Wurzelinformationsquelle
ist nicht ausreichend. Auch wenn man die Navigation an jedem Punkt
starten kann, muss jede Komponente als die Wurzel authentisierbar
sein. Jedoch stellt ein Authentisieren jeder Komponente durch die
Verwendung eines schweren bzw. starken Authentisierungsverfahrens
ein signifikantes Problem dar, da es eine hohe Belastung für eine große Anzahl
von Clients bringt. Da dem Verweiser bereits vorher die Authentizität der Komponentenquelle
versichert wurde, würde
es derart erscheinen, dass die Clients einen Großteil dieses Aufwands duplizieren
müssten.
-
Zusammenfassung der Erfindung
-
Die
vorliegende Erfindung adressiert das obige Problem durch das Vorsehen
eines Authentisierungsverfahrens, wo die Wurzelquelle für diesen individuellen
Client auf eine sichere Weise unter Verwendung eines schweren bzw.
starken Authentisierungsverfahrens authentisiert werden kann, und dann
auf die frühere
Server-zu-Server-Authentisierung
aufgebaut werden kann, um ein schwaches Verfahren der Authentisierung
für eine
weitere Client-Server-Informationsnavigation
zu ermöglichen.
-
Bezüglich einem
ersten Aspekt sieht die vorliegende Erfindung ein Informationsauthentisierungsverfahren
zur Authentisierung von Elementen von Information vor, wobei die
Informationselemente schwache Authentisierungsdaten enthalten, die
andere Informationselemente betreffen, wobei zumindest eines der
Informationselemente starke Authentisierungsdaten enthält, die
jeweils es selbst betreffen, wobei das Verfahren die Schritte aufweist:
- a) Authentisieren eines ersten der Informationselemente,
das starke Authentisierungsdaten enthält, unter Verwendung der starken
Authentisierungsdaten;
- b) Authentisieren eines weiteren der Informationselemente unter
Verwendung der schwachen Authentisierungsdaten, die in dem ersten
Informationselement enthalten sind; dadurch gekennzeichnet, dass
das Verfahren weiter aufweist:
- c) iteratives Wiederholen des Schrittes b) unter Verwendung
schwacher Authentisierungsdaten aus dem Informationselement, das
in der vorherigen Iteration authentisiert wurde, um so ein oder mehrere
weitere(s) Informationselement(e) zu authentisieren.
-
Die
Erfindung sieht den Vorteil vor, dass eine rechnerisch intensive
starke Authentisierung nur für das
erste Informationselement durchgeführt werden muss, auf das zugegriffen
wird, nachfolgende referenzierte Informationselemente erfordern
dann nur eine schwache Au thentisierung, die rechnerisch relativ
gering intensiv ist. Diese Unterscheidung zwischen den jeweiligen
rechnerischen Intensitäten
der schwachen und starken Authentisierung ist eine wichtige Charakteristik
der Erfindung, da eine starke Authentisierung rechnerisch intensiver
ist als eine schwache Authentisierung. Eine weitere Charakteristik
ist, dass die starke Authentisierung als sicherer betrachtet wird
als eine schwache Authentisierung.
-
Vorzugsweise
bilden in einem ersten Ausführungsbeispiel
die Informationselemente einen Teil eines verbundenen Graphs von
Informationselementen, wobei der verbundene Graph x Ebenen von Informationselementen
aufweist, wobei x eine reale Zahl größer als 3 ist, und wobei jedes
Informationselement in Ebene n, wobei n < x, jeweils enthält: Verbindungsinformation,
die ein oder mehrere weitere(s) Informationselement(e) in Ebene
n + 1 betrifft; und schwache Authentisierungsdaten, die jeweils
das oder jedes der verwiesenen Informationselement(e) in der Ebene
n + 1 betreffen; wobei der Schritt b) weiter aufweist:
- d) Authentisieren des oder jedes zugegriffenen Informationselements
in der n + 1sten Ebene unter Verwendung der jeweiligen schwachen
Authentisierungsdaten, die in dem Informationselement in der Ebene
n enthalten sind, welches das oder jedes zugegriffene Informationselement
in der n + 1sten Ebene betrifft;
und der Schritt c) weiter
aufweist das Setzen von n = n + 1 an dem Beginn jeder Iteration,
bis n + 1 = x.
-
Derartige
Merkmale ermöglichen,
dass die Erfindung auf einen verbundenen Graph von Information jeder
Größe angewendet
werden kann, während
der Vorteil erhalten bleibt, dass nur das Informationselement, auf
das zuerst zugegriffen wird, unter Verwendung starker Authentisierung
authentisiert werden muss.
-
Weiter
enthält
vorzugsweise jedes weitere Informationselement starke Authentisierungsdaten, die
sich darauf beziehen, so dass jedes Informationselement als das
erste Informationselement behandelt werden kann. Dies ermöglicht,
dass eine Navigation von Information von jedem Punkt in dem verbundenen
Graph von Information beginnen kann.
-
Weiter
ist in dem ersten Ausführungsbeispiel vorzugsweise
jedes Stück
von schwachen Authentisierungsdaten ein Hash-Wert, der aus einer Hash-Funktion
abgeleitet wird, die das jeweilige Informationselement, das ein
bestimmtes Stück
der schwachen Authentisierungsdaten betrifft, als ein Argument nimmt,
und wobei der Authentisierungsschritt d) aufweist ein Berechnen
der Hash-Werte des oder jedes Informationselements, auf das in Schritt
c) zugegriffen wird, unter Verwendung der Hash-Funktion und ein
Vergleichen des einen oder der mehreren berechneten Hash-Werts/Werte
mit den jeweiligen Hash-Werten, die von den schwachen Authentisierungsdaten
dargestellt werden. Die Verwendung einer Hash-Funktion als die schwache
Authentisierung ermöglicht
eine minimale Verwendung von Berechnungsressourcen.
-
In
einem weiteren Ausführungsbeispiel
sind die schwachen Authentisierungsdaten für ein bestimmtes Informationselement
vorzugsweise ein Hash-Wert, der von einer Hash-Funktion erzeugt wird,
die als ihr Argument die schwachen Authentisierungsdaten von dem
nächsten
zeitlichen Informationselement nimmt. Dies ist besonders von Vorteil, wenn
die Informationselemente jeweils zeitvariable Versionen eines anfänglichen
Informationselements sind, und liefert den Vorteil, dass nur das
anfängliche Informationselement
authentisiert werden muss unter Verwendung der starken Authentisierungsdaten und
dann können
zukünftige
Versionen des Informationselements die starke Authentisierung „ausleihen" durch Authentisieren
in einer Kette von dem ersten Element unter Verwendung der schwachen
Authentisierungsdaten.
-
Vorzugsweise
wird die Authentisierung so spät
wie möglich
durchgeführt
nach dem ersten Feststellen, ob die Referenz bzw. der Verweis einen
Wert hat. Somit werden Ressourcen durch ein Authentisieren von Referenzen
nicht verschwendet, die nicht navigiert werden.
-
Ein
zweiter Aspekt der Erfindung sieht auch eine Vorrichtung (60)
zur Authentisierung von Informationselementen (30, 32, 34, 102, 104, 106)
vor, wobei die Informationselemente (30, 32, 34, 102, 104, 106)
schwache Authentisierungsdaten enthalten, die andere Informationselemente
betreffen, wobei zumindest eines der Informationselemente starke Authentisierungsdaten
enthält,
die es selbst betreffen, wobei die Vorrichtung aufweist:
- a) starke Authentisierungsmittel (686)
zum Authentisieren eines ersten der Informationselemente, das starke
Authentisierungsdaten enthält,
unter Verwendung der starken Authentisierungsdaten; und
- b) schwache Authentisierungsmittel (688) zum Authentisieren
eines weiteren der Informationselemente unter Verwendung der schwachen
Authentisierungsdaten, die in dem ersten Informationselement enthalten
sind;
dadurch gekennzeichnet, dass das schwache Authentisierungsmittel
(688) weiter ausgebildet ist, iterativ seine Operation
zu wiederholen unter Verwendung schwacher Authentisierungsdaten
aus dem Informationselement, das in der vorherigen Iteration authentisiert
wurde, um so ein oder mehrere weitere(s) Informationselement(e)
zu authentisieren.
-
Zusätzlich sieht
in einem dritten Aspekt die Erfindung ein Computerprogramm vor,
das Anweisungen aufweist, die, wenn sie auf einem Computer ausgeführt werden,
den Computer veranlassen, das Verfahren entweder des ersten oder
des zweiten Aspekts durchzuführen.
-
Ebenso
kann die Erfindung auch ein Computer-lesbares Speichermedium vorsehen,
das ein Computerprogramm speichert, gemäß dem fünften Aspekt der Erfindung.
Das Computer-lesbare Speichermedium kann jedes magnetische, optische,
magneto-optische, feste (solidstate) oder jedes andere Datenspeichermedium
sein, das Daten speichern kann, die repräsentativ sind für Anweisungen
für einen
Computer.
-
Aus
allen Aspekten ermöglicht
die Erfindung eine Authentisierung von Informationselementen, die aus
unterschiedlichen Quellen und/oder auf unterschiedlichen Kanälen empfangen
werden, die auf eine schwache Weise durchgeführt wird mit reduzierter rechnerischer
Belastung, als es ansonsten der Fall wäre, wenn eine starke Authentisierung
jedes Elements durchgeführt
würde.
-
Weitere
Merkmale, Aspekte und Vorteile der Erfindung werden offensichtlich
aus den begleitenden Ansprüchen.
-
Kurze Beschreibung der Zeichnungen
-
Weitere
Merkmale und Vorteile der vorliegenden Erfindung werden offensichtlich
aus der folgenden Beschreibung ihrer Ausführungsbeispiele, dargestellt
nur auf beispielhafte Weise, und unter Bezugnahme auf die beigefügten Zeichnungen,
in denen gleiche Referenzzeichen gleiche Teile bezeichnen, und wobei:
-
1 den
normalen Fluss von Indexnachrichten unter Verwendung des „Generic
Announcement Protocol" des
Standes der Technik darstellt;
-
2 ein
mögliches
Angriffs-Szenario zeigt, wobei ein Angreifer eine falsche Nachricht
in den Nachrichtenstrom eingefügt
hat;
-
3 das
Nachrichtenformat und den Kompilierprozess darstellt, die von einem
ersten Ausführungsbeispiel
der vorliegenden Erfindung vorgesehen werden;
-
4 ein
Blockdiagramm ist, das die funktionalen Elemente eines Indexservers
der Ausführungsbeispiele
der Erfindung zeigt;
-
5 ein
Ablaufdiagramm ist, das die Schritte zeigt, die in dem ersten Ausführungsbeispiel
von einem Indexserver bei der Erzeugung einer neuen Indexnachricht
durchgeführt
werden;
-
6 ein
Blockdiagramm ist, das die funktionalen Elemente eines Benutzer-Computers
der Ausführungsbeispiele
der Erfindung zeigt;
-
7 ein
Ablaufdiagramm ist, das die Schritte zeigt, die von einem Benutzercomputer
in dem ersten Ausführungsbeispiel
durchgeführt
werden, um eine Indexnachricht zu authentisieren;
-
8 ein
Ablaufdiagramm ist, das die Schritte zeigt, die in einem zweiten
Ausführungsbeispiel von
einem Indexserver bei der Erzeugung einer neuen Indexnachricht durchgeführt werden;
-
9 ein
Ablaufdiagramm ist, das die Schritte zeigt, die von einem Benutzercomputer
in dem zweiten Ausführungsbeispiel
durchgeführt
werden, um eine Indexnachricht zu authentisieren; und
-
10 das
Nachrichtenformat und den Kompilierprozess darstellt, die von dem
zweiten Ausführungsbeispiel
der vorliegenden Erfindung vorgesehen werden.
-
Beschreibung der Ausführungsbeispiele
-
Ausführungsbeispiele
der Erfindung werden nun beschrieben, die als ihre Basis die indizierte
Ereignisnachrichtentechnologie nimmt, die hier als GAP (Generic
Announcement Protocol) bezeichnet wird, und die in unserer früheren internationalen
Patentanmeldung Nr. PCT/GB01/02681 beschrieben wird, die oben angeführt wird.
Eine kurze Beschreibung der GAP-Architektur und -Operation wird
unten angeführt,
aber für
weitere Details wird der geneigte Leser auf unsere frühere Anmeldung
verwiesen, deren Inhalte durch Bezugnahme hier aufgenommen sind.
-
Im
Folgenden wird das „Generic
Announcement Protocol" eingeführt und
seine Sicherheitsanforderungen hinsichtlich einer Authentisierung.
Diese Information wird dann als Hintergrund für den nächsten Abschnitt verwendet,
der detailliert zeigt, wie die vorliegende Erfindung für das „Generic
Announcement Protocol" implementiert
werden kann.
-
Das „Generic
Announcement Protocol" oder GAP
ist ein Protokoll für
die effiziente Verteilung von Ankündigungen über ein Multicast-Netzwerk. Das „Generic
Announcement Protocol" (GAP)
besteht aus zwei Typen von Ankündigungen.
Der erste Typ von Ankündigungen
sind die, die abgehört
werden im Interesse einer Client-Anwendung, und als sekundäre Ankündigungen
bezeichnet werden. Diese sekundären
Ankündigungen
werden an die GAP-Kommunikationsebene geleitet durch einen höheren Ebenen-Anwendungs-Server
und werden schließlich
an interessierte Client-Anwendungen weitergeleitet. Die andere Klasse
von Ankündigungen
werden als primäre
Ankündigungen
bezeichnet und enthalten eine Nutzlast, die eine oder mehrere sekundäre (Anwendungs-)Ankündigung(en)
betrifft. GAP trennt diese primären
Ankündigungen
in Indexankündigungen und
Verwaltungs-Ankündigungen.
Sowohl Index- als auch Verwaltungs-Ankündigungen
sind nicht für
den Anwendungs-Client bestimmt, sondern werden stattdessen von der
GAP-Software-Ebene selbst verwendet, um zu konfigurieren, wie sie
sekundäre
oder Daten-Ankündigungen
abhört.
Tatsächlich
werden diese primären
Ankündigungen
verwendet, um die GAP-Software-Ebene zu konfigurieren.
-
Einzelne
GAP-Ankündigungen
werden als Teil einer laufenden Serie von Ankündigungen betrachtet. Diese
Serie verwandter Ankündigungen wird
durch eine gemeinsame „Announcement
Thread ID" (AThID)
identifiziert und ist in dem Ankündigungs-Header
zu finden. Typischerweise betrifft die Nutzlast-Information in Ankündigungen
mit derselben AThID dasselbe Datenelement. Zum Beispiel können sie
eine Serie von aktualisierten Tarifen für einen bestimmten Dienst sein.
-
Der
Ankündigungs-Header
enthält
auch eine Versionsnummer (VN), die Ankündigungen in einem gemeinsamen
Thread eindeutig identifiziert. Diese Versionsnummer dient einer
Vielzahl von Funktionen. Neben einer eindeutigen Identifizierung
einer Ankündigung
platziert sie auch die Ankündigung
in einer Zeitreihe und ermöglicht
die Erfassung von fehlenden Ankündigungen.
-
Der
letzte Teil des Ankündigungs-Headers enthält eine
GAP-Protokoll-Versionsnummer
und eine Anzahl von Flags, die für
GAP und Anwendungen höherer
Ebene verfügbar
sind. Eines dieser Flags wird verwendet, um anzuzeigen, ob eine
Ankündigung
eine Konfigu rationsankündigung
ist und als solche anders als eine Daten-Ankündigung
behandelt werden soll.
-
Jeder
Ankündigungs-Thread
wird an eine oder mehrere Multicast-Netzwerkadresse(n) übertragen. Eine Software-Komponente,
als GAP-Ankündiger (announcer)
bezeichnet, handhabt die Ankündigung
von Ereignissen an das Multicast-Netzwerk, während eine andere Komponente,
als der GAP-Listener bezeichnet, verantwortlich ist für die Erfassung von
Ankündigungen
von dem Multicast-Netzwerk. Der GAP-Listener handelt im Interesse
von Client-Anwendungen und überwacht
ausgewählte
Multicast-Gruppen hinsichtlich der erforderlichen Ankündigungs-Threads.
Der GAP-Listener pflegt auch eine Liste von verfügbaren Indizes für die Ankündigungs-Threads,
die er überwachen
soll. Ob der Listener den Daten-Ankündigungs-Thread direkt überwacht
oder einen dieser Indizes benutzt, wird von dem Listener intelligent
entschieden. Zum Beispiel ist ein Index, der hauptsächlich Ankündigungs-Threads betrifft,
an denen der Listener interessiert ist, wahrscheinlich lohnend,
abzuhören.
Ein anderer Index, der nur einen interessanten Ankündigungs-Thread und
viele Ankündigungs-Threads mit hohem
Volumen betrifft, an denen kein Interesse besteht, kann nicht so
nützlich
sein. Durch Verwendung von Indizes kann der GAP-Listener das Volumen
von Ankündigungen
reduzieren, die er empfangen muss, und ebenso Multicast-Gruppen-Ressourcen
freigeben, die er verwendet, um die Ereignisankündigungen abzuhören, bis
diese Ereignisankündigungen
tatsächlich
stattfinden.
-
Der
GAP-Listener empfängt
auch Konfigurationsankündigungen,
die sein Verhalten steuern. Diese Konfigurationsankündigungen
informieren den Listener über Änderungen
zu Ankündigungs-Threads und
verwandter Information, einschließlich über den Thread-Multicast-Ort und
verfügbare
Indizes.
-
Nach
der Beschreibung der grundlegenden GAP-Architektur wird als nächstes ein
Abhör-Verhalten
in dem „Generic
Announcement Protocol" (GAP) beschrieben,
woraus die Wichtigkeit der Indexauthentisierung und wie bösartige
Indexankündigungen die
Leistung von GAP beeinflussen können
offensichtlich wird.
-
Das
Verhalten des Listeners hängt
von der Information ab, die er durch die Indexkanäle empfängt. Die
folgenden Punkte beschreiben eine mögliche Sequenz von Aktionen,
die von einem Client durchgeführt
werden, der einen Indexkanal abhört.
-
1. Abhören
eines Indexkanals.
-
Ein
Client hört
den Indexkanal ab, um zu wissen, wenn eine Datenankündigung
auf einem der Anwendungskanäle
gemacht wird. Der Benutzer hält die
Verbindung zu diesem Indexkanal kontinuierlich aufrecht, um den
Datenverkehr zu überwachen.
-
2. Prüfe
Index-Header
-
Der
Benutzer filtert alle Indizes, die nicht die erwartete AThID (Announcement
Thread ID) und Versionsnummer (VN) haben. Wenn eine erwartete Indexankündigung
empfangen wird, verarbeitet der Benutzer die Nutzlast. Die nächste erwartete
Indexankündigung
wird dieselbe Index-ThID haben, mit der VN inkrementiert.
-
3. Prüfe
Indexnutzlast
-
Ein
Benutzer, der eine neue Indexinformation bekommt, wird prüfen, welche
Datenankündigung geändert ist,
durch Untersuchen der Indexankündigungs-Nutzlast.
Wenn die Benutzeranwendung an der neuen Datenankündigung interessiert ist, dann nimmt
sie an dem Anwendungskanal teil, um die Information zu bekommen.
-
4. Abhören
des Datenkanals
-
Der
Benutzer nimmt an diesem Kanal teil, um die korrekte Datenankündigung
zu bekommen. Der Benutzer sollte temporär mit diesem Kanal verbunden
sein und verlässt
ihn nach dem Empfang der erwarteten Datenankündigung.
-
Der
Listener hat kein Verfahren, um dem Sender zu vertrauen, da die
IP-Adresse des Senders gefälscht
sein kann oder die korrekte Information von einem bösartigen
Sender modifiziert werden kann oder „Hacker" können
einen „schlechten" Ankündiger einführen. GAP
ist ein mehrschichtiges Protokoll hinsichtlich von Kanälen (Indexkanal
und Daten-Kanal), diese zwei Kanaltypen tragen unterschiedliche
Arten von Information mit unterschiedlichen Sicherheitsanforderungen,
somit kann es interessant sein, zwei verschiedene Verfahren zur
Authentisierung zu haben, eines für die Datennachrichten und
das andere für
Indexnachrichten. Zum Beispiel kann der Datenkanal nur einer starken
Authentisierung unterzogen werden, während der Indexkanal einer
starken oder einer schwachen Authentisierung unterzogen wird, wie
geeignet.
-
Nach
der Beschreibung eines Szenarios ohne jegliche Sicherheit wird nun
die Authentisierungs-Operation eingeführt. Der Client ist wahrscheinlich
immer mit dem Indexkanal verbunden. Jedoch ist der Client nicht
an dem gesamten Verkehr interessiert, der von diesem Kanal getragen
wird, und kann die unerwünschten
Indexankündigungen
einfach fallen lassen. Nur eine ausgewählte Gruppe der Indizes wird
verarbeitet. Diese Gruppe hat die erwartete AThID und die korrekte
VN. Der Benutzer prüft dann
die Nutzlast, um zu sehen, ob er interessiert ist, Datenankündigungen
abzurufen, die in der Indexnutzlast detailliert sind. Im positiven
Fall nimmt der Empfänger
an dem Datenkanal teil. Vor dem Senden der Teilnahmenachricht möchte der
Empfänger
die Indexankündigung
authentisieren. Deswegen sind in der Zusammenfassung die von dem
Benutzer durchzuführen den
Operationen: Abhören
Indexkanal → Prüfen AThID → Prüfen VN → Prüfen Nutzlast → Indexauthentisierung → Teilnahme
Datenkanal. Diese von dem Benutzer durchzuführenden Operationen werden
hinsichtlich der Priorität
geplant.
-
Abhören des
Indexkanals und Prüfen
des Headers und der Nutzlast werden als Operationen mit geringen
Kosten angesehen. Es wird angenommen, dass die Größe des Indexpakets
begrenzt ist oder zumindest vernachlässigbar im Vergleich zu Datenpaketen.
Die Authentisierungsoperation wurde eingeführt vor der Teilnahme an dem
Datenkanal, um eine unnütze
Ressourcenzuteilung in das Netzwerk zu vermeiden. Es wird somit
nach einem Authentisierungsalgorithmus mit geringen Kosten gesucht,
was bedeutet, dass theoretisch die Ressourcen der Benutzer nicht
verbraucht werden müssen,
um die Authentizität
der Indexpakete zu verifizieren. Es ist wichtig, zu berücksichtigen,
dass eines der Hauptziele der Indexnachrichten-Authentisierung ist, unnütze Operationen
für die
Teilnahme am Datenkanal zu vermeiden. Die von der Erfindung vorgesehene
Lösung sucht
nach einem Kompromiss zwischen einer Situation einer starken Authentisierung
(jede Indexankündigung
wird authentisiert) und keiner Authentisierung, wo der Benutzer
die Authentizität
eines Indexes verifiziert durch Prüfen der Datenankündigung.
Die bei dieser Evaluierung beteiligten Parameter sind die Netzwerk-Ressourcen-Kosten und die Latenzzeit, um
an einem neuen Multicast-Kanal teilzunehmen. Es wird berücksichtigt,
dass der Erzeugungs- und Verifizierungs-Overhead für die Authentisierungs-Information
kompatibel sein sollte mit der rechnerischen Leistungsfähigkeit
der Empfänger.
-
Um
vollständig
die Notwendigkeit des von der vorliegenden Erfindung vorgesehenen
Mechanismus zu demonstrieren, werden in den nächsten Abschnitten die Effekte
von bösartigen
Indexankündigungen
analysiert, die während
einer GAP-Sitzung gesendet werden.
-
Das
Senden eines gefälschten
Indexes durch einen Angreifer kann unterschiedliche und wichtige
Probleme hinsichtlich von Multicast-Netzwerk-Ressourcen erzeugen und kann
die Leistung des Benutzers beeinträchtigen. Von einem GAP-Standpunkt
aus ist die wichtigste Information, die von dem Index getragen wird,
die AThID, die VN und die Nutzlast. Ein Angreifer, der eine gefälschte Indexankündigung
in ein Multicast-Netzwerk senden möchte, muss diese Information
kennen, ansonsten können
Indexpakete, die mit einer ungültigen
AThID oder VN gesendet werden, von der Firewall oder dem Empfängerfilter
fallengelassen werden. Es ist jedoch zu sehen, dass diese Art des
Angriffs eine „Dienstverweigerungs-(DoS – Denial
of Service)"-Situation hinsichtlich
einer Netzwerk-Bandbreite erzeugen könnte. Auch wenn das DoS-Problem
nicht spezifisch beschrieben wird, muss berücksichtigt werden, dass, da
der Benutzer immer mit dem Indexkanal verbunden ist, ein bösartiger
Verkehr authentische Indizes verzögern kann. Wenn eine Indexauthentisierung
erzielt wird unter Verwendung von Verfahren wie TESLA [Tesla: Multicast
Authentication Transform. Author: Perrig, Canetti, Briscoe, Tygar
and D.X. Song], die eine strikte Zeitanforderung haben, erzeugt
diese Art des Angriffs einige Probleme.
-
Die 1 und 2 zeigen
eine Situation, in der ein Angreifer eine gefälschte Indexinformation mit
AThID, VN und Nutzlast sendet, die kompatibel ist zu der von dem
Listener erwarteten. Mit einer gefälschten Header-Information
sind AThID & VN
nicht korrekt. Ein Benutzer, der den Indexkanal abhört, berücksichtigt
die Indexnutzlast nur, wenn: i) der Benutzer an der AThID interessiert
ist; und ii) die VN der AThID = = ALTE_VN + 1 oder VN > ALTE_VN.
-
Das
klassische Szenario wird in 1 gezeigt,
wobei der Index-Generator
Indexankündigungen
sendet, die zu einem bestimmten Anwendungskanal gehören. Der
Empfänger
prüft den
Header und die Nutzlast, um zu wissen, dass sich etwas in dem Datenkanal
verändert
hat. In dieses klassische Szenario wird nun ein bösartiger
Benutzer eingeführt,
der gefälschte
Indexpakete senden wird, und es werden die Effekte vom Standpunkt
des Empfängers
aus analysiert (siehe 2).
-
Dieser
Angriff betrifft die Synchronisierung zwischen dem Sender und dem
Empfänger.
Bei GAP gibt es keine Spezifikation hinsichtlich der Synchronisierung,
aber es ist offensichtlich, dass der Benutzer immer die neueste
Version der Indexankündigung abhört. Ein
Benutzer, der gefälschte
Indexpakete empfängt,
kann eine Information verlieren, die betrifft, nach welcher Indexversion
er abhören
soll. Der Empfänger
muss, um diese Situation zu retten, mit dem Index-Generator kommunizieren,
um die Versionsnummer wieder zu synchronisieren, die er erwartet. Dies
verschwendet Ressourcen und ist eine Situation, die bei jeder Implementierung
von GAP vermieden werden sollte. Jedoch erscheint dieser Angriff nicht
als ein untragbares Problem und unter Verwendung eines Authentisierungs-Verfahrens
kann es gelöst
werden. Es ist nicht wichtig, jede Indexnachricht zu authentisieren,
da es ausreichend ist, nur Ankündigungen
zu verifizieren, die den Benutzer auffordern, an dem Datenkanal
teilzunehmen.
-
Es
ist interessant anzumerken, dass ein Index eigentlich authentisiert
wird durch die Information, die er trägt. Die Authentisierung eines
Indexpakets kann verifiziert werden durch einfaches Prüfen der
Authentizität
der Information, die in der Indexnutzlast gesendet wird. Um dies
zu tun, sollte ein Benutzer die Authentizität jeder Datenankündigung
prüfen
(zwischen zwei aufeinander folgenden Indizes sollte sich nur eine
Datenankündigung ändern).
Der wichtigste Nachteil dieses Verfahrens ist, dass eine Nachricht
Zeit benötigt,
um authentisiert zu werden, und Netzwerkressourcen (um an dem Multicast- Kanal teilzunehmen).
Folglich ist offensichtlich, dass die Erzeugung von gefälschten
Indizes als ein Dienstverweigerungs(DoS – Denial of Service)-Angriff
wirken kann.
-
Unter
Betrachtung als nächstes
einer gefälschten
Nutzlast (Forged Payload), ist dies der Fall, wenn ein Angreifer
in seiner gefälschten
Indexnachricht eine inkorrekte Datenankündigungsinformation aufnimmt.
Ein Angreifer, der ein Paket mit einer betrügerischen Nutzlast sendet,
kann vorsätzlich
eine dynamische Änderung
der Struktur des Multicast-Baums erzeugen. Jedes Mal, wenn eine
neue Datenankündigung
indiziert wird, nimmt der Benutzer an einem spezifizierten Multicast-Baum
teil, um sie zu bekommen. In dem tatsächlichen Multicast-Protokoll
verursacht eine Teilnahme-Operation Kosten hinsichtlich Bandbreiten-Ressourcen
und rechnerischen Operationen. Während
einer Teilnahme-Operation können
zumindest drei Protokolle verwendet werden: IGMP-Protokoll zwischen
dem Benutzer und dem ersten Multicast-Router, ein Intra-Domain-Protokoll, wie
PIM-SM, und ein
Inter-Domain-Protokoll, wie BGMP.
-
Unter
Betrachtung als nächstes
eines Antwort-Angriffs (Reply-Attack),
ist dies der Fall, wenn ein bösartiger
Benutzer eine alte authentische Ankündigung wiederholt. Dieses
Problem kann in einigen speziellen Anwendungen als wichtig betrachtet werden,
in denen derselbe Wert der Index- und Datenankündigung wiederholt wird. Sogar
eine klassische digitale Signaturkonstruktion kann dieses Problem
nicht lösen,
wenn die Authentisierungsparameter nicht über die Zeit verändert werden.
Normalerweise wird [siehe „IP
Security Document Roadmap", Autor
R. Thayer et al], um diese Art von Problem zu lösen, ein Sequenznummernfeld
in die Pakete eingefügt,
aber in unserem Fall hat GAP bereits dieses Feld in der Form der
Versionsnummer (VN). Um jedoch die Sicherheit in unserem Schema
zu erhöhen und
diese Art von Problem während
einer Langzeitsitzung zu vermeiden, können wir einen nonce-Wert hinzufügen, der
in diesem Fall eine Zeitstempel-Information ist.
-
Nach
der Beschreibung der grundlegenden Architektur der Ausführungsbeispiele
wird nun die tatsächliche
schwache Authentisierungstechnik beschrieben, die von der vorliegenden
Erfindung vorgesehen ist.
-
Die
neue Authentisierungstechnik nutzt die hierarchische Struktur von
GAP aus. Die Indexstruktur von GAP kann als ein Baum gesehen werden.
Die Wurzel des Baums ist ein Top-Level-Superindex und umfasst Information
hinsichtlich der Teilindizes. Die vorliegende Erfindung sieht vor,
dass ein Empfänger, der
einen Indexbaum abhört,
nur den Eltern-Index authentisieren muss, damit die gesamte Gruppe
der Kinder authentisiert ist. Wenn der Empfänger den Wurzelindex abhört, kann
er mit nur einer Verifizierungsoperation den gesamten Baum authentisieren.
-
Um
diese Struktur besser zu verstehen, wird ein reales Beispiel gegeben.
Eine Person empfängt eine
Email, die eine andere Email umfasst, die genauso eine andere Email
enthält,
und so weiter. Im Grunde genommen empfängt sie verschachtelte Emails.
Wenn der letzte Empfänger
den letzten Sender authentisieren kann, kann er alle verschachtelten Emails
authentisieren. Die einzige erforderliche Hypothese ist eine Vertrauensbeziehung
zwischen den aufeinander folgenden Sendern. Dieses Beispiel kann
einfach auf GAP erweitert werden, da die Indexstruktur hierarchisch
ist, und ein Benutzer, der die Authentisierung eines Wurzelindexes
verifizieren kann, kann der Authentisierung der gesamten Baumstruktur
vertrauen. Technisch sehen die Ausführungsbeispiele der Erfindung
vor, dass der Empfänger
die Authentisierung eines Superindexes unter Verwendung einer öffentlichen
Verschlüsselung
oder eines MACs-Schemas verifiziert und dann verifiziert er den Teilindex
mit einer pseudozufälligen
Funktion (HASH).
-
Um
eine verschachtelte Indexauthentisierung (Nested Index Authentication)
vorzusehen, wie oben beschrieben, ist es erforderlich, das Index-Design
etwas zu modifizieren, um in die Nutzlast der Indexankündigung
ein neues Feld einzuführen,
das einen pseudozufälligen
Funktionswert der Indexnachrichten trägt, die indiziert werden. Folglich
ist mit dieser Modifikation die neue Nutzlast-Zeile für einen
Index:
Index_Ankündigungs-Thread-ID
(AThID);
Versions_Nummer;
H(H(Index_Ankündigung));
und
Verwaltungs-Flag (MGT – Management).
-
Die
Eigenschaften der Hash-Funktion bedeuten, dass es unwahrscheinlich
ist (aber nicht unmöglich),
denselben H(M)-Wert mit einer anderen Nachricht M zu erzeugen, aber
mit einem gegebenen H(M) ist es unmöglich, M zu berechnen. In den
Ausführungsbeispielen
verwenden wir aus Sicherheitsgründen
doppeltes Hash und der H(M)-Wert
wird nicht offenbart, bis die erste authentisierte Indexankündigung
gesendet ist.
-
Jede
Indexnachricht hat auch ein Authentisierungsfeld. Das Feld enthält eine
digitale öffentliche Verschlüsselungssignatur
oder eine MACs-Sequenz (beide sind im Allgemeinen in der Technik
bekannt). Auf diese Weise kann jede Indexankündigung verifiziert werden,
auch ohne eine Indexankündigung
höheren
Levels abzuhören.
-
Die
von der vorliegenden Erfindung vorgesehene Technik stellt eine gute
Lösung
dar, um das Problem einer Ressourcenzuteilung zu lösen, das
Benutzer betrifft, welche die Authentisierung zu vieler Indi zes
in kurzen Intervallen prüfen.
Der Empfänger muss
nur eine begrenzte Anzahl von Superindizes verifizieren, jedoch
ist erforderlich, dass die Erzeugung dieser Indexankündigungen
in der Rate begrenzt ist, ansonsten sind die Ressourcenprobleme noch
immer möglich.
Für eine
bestimmte Art von Anwendungen kann der Authentisierungsserver den Superindex
erzeugen mit dem Ziel, die Authentisierungsleistung des Systems
zu verbessern.
-
Die
Skalierbarkeitseigenschaft ist eine weitere Stärke dieses Verfahrens. Es ist
nicht erforderlich, dass der Benutzer den Wurzelindex abhört, da ein Benutzer
jeden Index in dem Baum abhören
kann und er noch immer die Authentisierung durchführen und
die Erfindung ausnutzen kann.
-
Eine
detaillierte Beschreibung des ersten Ausführungsbeispiels der Erfindung
wird nun unter Bezugnahme auf die 3 bis 7 beschrieben.
-
3 liefert
einen Überblick über den
Betrieb des ersten Ausführungsbeispiels
unter Verwendung von GAP. Es wird hier die Anwendung 3 betrachtet,
die Ereignisankündigungen
mit AThID = 3 erzeugt. Die neueste Ereignisankündigung ist die Versionsnummer
(VN) = 5 und diese Information wird über einen zuverlässigen und
sicheren Kanal an den Indexserver (I.S.) 2 geleitet.
-
Der
Indexserver 2 erzeugt dann eine Indexnachricht 34, wobei
AThID = 20 und VN = 50. Die Indexnachricht 34 enthält as ihre
Nutzlast die AThID und VN, die von der Anwendung 3 empfangen wurden,
und umfasst auch eine digitale Signatur, die unter Verwendung einer
starken Authentisierung erzeugt wurde, wie eine Verschlüsselung
mit öffentlichem
Schlüssel
oder Nachrichtenzugriffscodes. Die digitale Signatur liefert selbst
eine sichere Authentisierung der Indexnach richt 34, so
dass, wenn ein GAP-Listener nur die Indexnachricht 34 empfängt, er die
Nachricht authentisieren kann. Zusätzlich zu der digitalen Signatur
ist auch ein Zeitstempel enthalten.
-
Der
Indexserver 2 sendet die Indexnachricht 34 an einen zweiten
Indexserver 3 über
einen zuverlässigen
und sicheren Kanal. Der Indexserver 3 empfängt auch eine weitere Indexnachricht
mit der Ankündigungs-Thread-ID
= 10 und der Versionsnummer = 30 von dem Indexserver 1. Nach dem
Empfang dieser beiden Indexnachrichten von dem Indexserver 2 und
dem Indexserver 1 fährt
der Indexserver 3 dann fort, eine weitere Indexnachricht 32 mit
der Ankündigungs-Thread-ID = 100 und
der Versionsnummer = 300 zu kompilieren. Die Indexnachricht 32 weist
in ihrer Nutzlast die Ankündigungs-Thread-ID und die Versionsnummer
der Indexnachricht 34 auf und auch der von dem Indexserver
1 empfangenen Indexnachricht. Zusätzlich zu diesen Werten berechnet
der Indexserver 3 für
jede Indexnachricht, die in der Nutzlast der Indexnachricht 32 repräsentiert
ist, einen doppelten Hash-Wert jeder empfangenen Indexnachricht
und nimmt als Teil der Nutzlast die berechneten Hash-Werte auf.
Somit wird ein Hash-Wert H(H(M)) durch den Indexserver 3 für die dort
empfangene Indexnachricht 34 berechnet und dieser berechnete
Hash-Wert wird als Teil der Nutzlast der Indexnachricht 32 aufgenommen.
-
Zusätzlich zu
der Nutzlast umfasst die Indexnachricht 32 auch eine digitale
Signatur, die unter Verwendung eines starken Authentisierungsverfahrens
erzeugt wird, wie eine Verschlüsselung
mit öffentlichem
Schlüssel
oder Nachrichtenzugriffscodes. Die digitale Signatur liefert selbst
eine sichere Authentisierung der Indexnachricht 32, so
dass, wenn ein Listener nur die Indexnachricht 32 empfängt, er die
Nachricht authentisieren kann. Zusätzlich zu der digitalen Signatur
ist auch ein Zeitstempel enthalten.
-
Der
Indexserver 3 überträgt die Indexnachricht 32 an
einen weiteren Indexserver 4 über
einen zuverlässigen
und sicheren Kanal. Der Indexserver 4 stellt in diesem Beispiel
die Wurzel des Indexbaums dar und erzeugt Super-Indexnachrichten 30,
die von allen GAP-Listenern abgehört werden sollen, die das System
verwenden. Die Super-Indexnachricht 30 hat die
Ankündigungs-Thread-ID
= 1000 und die Versionsnummer = 200. Die Super-Indexnachricht 30 trägt als ihre
Nutzlast die Ankündigungs-Thread-IDs
und Versionsnummern der Indexnachrichten, wie der Indexnachricht 32,
die an den Indexserver 4 kommuniziert werden. Zusätzlich ist
für jede
Indexnachricht, die in der Nutzlast repräsentiert ist, ein Doppel-Hash-Wert
dieser Nachricht ebenfalls darin enthalten, so dass die Super-Indexnachricht 30 in
ihrer Nutzlast eine Ankündigungs-Thread-ID,
eine Versionsnummer und einen Hash-Wert für jede dazwischenliegende Indexnachricht
enthält,
wie Indexnachricht 32, die darin repräsentiert ist.
-
4 zeigt
ein Blockdiagramm der internen funktionalen Elemente eines Indexservers
1, 2, 3 oder 4. Insbesondere ist ein Indexserver 40, der
als ein Indexserver in der GAP-Architektur wirkt, intern mit einer
Netzwerkkarte 42 vorgesehen, um eine Netzwerkverbindung
vorzusehen, um dem Indexserver zu ermöglichen, mit anderen Indexservern,
Anwendungen oder GAP-Listenern zu kommunizieren. Eine Zentraleinheit 44 ist
weiter vorgesehen, um die Operation des Servers gemäß einem
oder mehreren Computerprogramm(en) zu steuern, das/die auf einer
internen Festplatte 48 gespeichert ist/sind. Ein lokaler
Eingabe- und Ausgabe-Anschluss 46 ermöglicht dem Server, mit seinen
menschlichen Operatoren über
herkömmliche
Eingabe- und Ausgabe-Mittel zu kommunizieren, wie Monitore, Tastaturen,
Computermaus oder Ähnliches.
Ein Datenbus 47 ist vorgesehen, der ermöglicht, dass Daten und Befehle zwischen
den unterschiedlichen Elementen des Servers 40 kommuniziert
werden.
-
Die
Festplatte 48 speichert darauf eine Anzahl von Computerprogrammen,
wobei es sich insbesondere um eine Betriebs-Suite von Programmen 484,
ein GAP-Ebenen-Programm 482 handelt, das die Funktionalität des Servers
steuert, um ihn zu veranlassen, als ein GAP-Indexserver zu arbeiten.
Zusätzlich
ist ein Compilerprogramm 486 vorgesehen, das den Server
steuert, um Indexnachrichten zu erzeugen. Ferner ist ein starkes
Authentisierungsprogramm 488 vorgesehen, das wirkt, um
eine starke Authentisierung von Nachrichten vorzusehen, und zusätzlich ist
auch ein schwaches Authentisierungsprogramm 4810 vorgesehen,
das wirkt, um eine schwache Authentisierung vorzusehen unter Verwendung
der Hash-Funktionen, wie beschrieben.
-
6 ist
ein Blockdiagramm der funktionalen Elemente, die an dem Computer
eines Benutzers erforderlich sind, um die Indexnachrichten zu empfangen
und zu authentisieren, die von den Indexservern erzeugt werden.
Insbesondere weist ein Benutzercomputer 60 eine Netzwerk-Eingabe-
und Ausgabe-Karte 62 auf, die eine Verbindung des Benutzercomputers 60 mit
einem Kommunikationsnetzwerk ermöglicht,
um dem Benutzercomputer zu ermöglichen,
mit den Indexservern zu kommunizieren. Lokale Eingabe- und Ausgabe-Mittel 64 sind
ebenfalls vorgesehen, um dem menschlichen Operator des Benutzercomputers
zu ermöglichen,
damit zu kommunizieren, und zusätzlich
ist eine Zentraleinheit 66 vorgesehen, um den Betrieb des
Benutzercomputers 60 zu steuern. Ein Computer-lesbares
Speichermedium, wie die Festplatte 68, ist weiter vorgesehen,
auf dem eine Anzahl von Computerprogrammen gespeichert sind, um
den Betrieb des Benutzercomputers 60 zu steuern. Ein Datenbus 67 sieht
eine Datenkommunikation zwischen den verschiedenen Elementen vor.
-
Das
Computer-lesbare Speichermedium 68 speichert eine Anzahl
von Computerprogrammen, einschließlich einer Suite von Betriebspro grammen 684,
und ein GAP-Ebenen-Programm 682, das den Benutzercomputer 60 steuert,
die erforderlichen GAP-Funktionen durchzuführen. Zusätzlich ist ein starkes Authentisierungsprogramm 686 vorgesehen, das
eine starke Authentisierung empfangener Indexnachrichten vorsieht,
und ferner ist auch ein schwaches Authentisierungsprogramm 688 vorgesehen,
um eine schwache Authentisierung empfangener Indexnachrichten zu
ermöglichen.
Die spezifischen Betriebsdetails des starken Authentisierungsprogramms 686 und
des schwachen Authentisierungsprogramms 688 werden später beschrieben.
-
Nach
der Beschreibung der internen Blockstrukturen der Indexserver und
der Benutzercomputer wird nun das Betriebsverfahren unter Bezugnahme
auf die 3, 5 und 7 beschrieben.
-
Der
Betrieb jedes Indexservers wurde oben diskutiert unter Bezugnahme
auf die 3, aber 5 zeigt
in einer Ablaufdiagrammform die Schritte, die von jedem bestimmten
Indexserver bei der Erzeugung einer Indexnachricht unternommen werden.
-
Unter
Bezugnahme auf 5 greift in Schritt 5.1 der
Indexserver auf das Informationselement zu, das mit der Indexnachricht
verbunden werden soll, die von dem Indexserver erzeugt werden soll.
In der GAP-Architektur
wird dieser Schritt erfüllt
durch die „niedrigerer
Level"-Anwendung oder den
Indexserver, ein Senden an den Indexserver in Betrieb wird beschrieben
entweder als eine Ereignisankündigung oder
eine Indexnachricht, die Ereignisankündigungen als ihre Nutzlast
enthält.
Das heißt,
das Informationselement in der GAP-Architektur ist entweder die Ereignisankündigung,
die von einer Anwendung erzeugt wird, oder eine Indexnachricht,
die von einem Indexserver niedrigeren Levels erzeugt wird.
-
Nach
dem Zugriff auf das Informationselement berechnet in Schritt 5.2 der
Indexserver den Hash-Wert des darauf zugegriffenen Informationselements
unter Verwendung einer bekannten Hash-Funktion. Vorzugsweise wird
die Hash-Funktion zwei oder mehrere Male angewendet, um eine zusätzliche
Sicherheit vorzusehen. In der GAP-Architektur werden die Indexnachrichten
niedrigeren Levels, die an dem Indexserver empfangen werden, die von
uns behandelt werden, als die Eingabe in die Hash-Funktion verwendet,
so das der berechnete Hash-Wert den Hash der eingegebenen Indexnachricht
repräsentiert.
-
Nach
der Berechnung des Hash-Werts kompiliert in Schritt 5.3 der
Indexserver ein neues Informationselement, das Zeiger zu der zugegriffenen
Information enthält,
plus den Hash-Wert, der in Schritt 5.2 berechnet wurde.
In dem Kontext der GAP-Architektur wird dieser Schritt erfüllt durch
die Erzeugung einer neuen Indexnachricht des geeigneten Ankündigungs-Thread-Identifizierers,
aber mit einer inkrementierten Versionsnummer, die als ihre Nutzlast
die Ankündigungs-Thread-Identifizierer
und Versionsnummern von empfangenen Indexnachrichten geringeren
Levels enthält,
und zusätzlich
die berechneten Hash-Werte dieser empfangenen Indexnachrichten geringeren
Levels.
-
In
Schritt 5.4 wird die kompilierte Indexnachricht als Eingabe
in eine starke Authentisierungsfunktion verwendet, wie eine Authentisierung
unter Verwendung einer Verschlüsselung
mit öffentlichem Schlüssel, um
eine digitale Signatur zu erzeugen, oder durch Verwendung von Nachrichtenzugriffscodes.
Die Verwendung einer Verschlüsselung
mit öffentlichem
Schlüssel
oder Nachrichtenzugriffscodes zur Authentisierung ist allgemein
in der Technik bekannt, aber weitere Details, die für die vorliegende
Erfindung spezifisch sind, werden später beschrieben.
-
Folgend
auf die Erzeugung der starken Authentisierungsdaten für die neue
Nachricht werden in Schritt 5.5 die erzeugten starken Authentisierungsdaten
als Teil der kompilierten neuen Indexnachricht (Informationselement)
als ein zusätzliches
Feld davon aufgenommen. Ferner ist auch ein Zeitstempel enthalten.
-
Die
obigen Schritte stellen die Schritte dar, die von einem Indexserver
unternommen werden, um eine neue Indexnachricht zu erzeugen, und
der Prozess ist bei Schritt 5.6 abgeschlossen, wenn das neue
Informationselement in der Form der Indexnachricht übertragen
wird.
-
Es
sollte angemerkt werden, dass die obigen Schritte im Allgemeinen
von einem Indexserver durchgeführt
werden, unabhängig
davon, wo der Server in dem Indexbaum liegt. Somit ist, ob der Indexserver
die Super-Indexnachrichten, dazwischenliegende Indexnachrichten
oder Indexnachrichten des niedrigeren Levels erzeugt, das Verfahren
wie beschrieben.
-
Nach
der Beschreibung der Erzeugung von Indexnachrichten durch die Indexserver
wird nun unter Bezugnahme auf die 3 und 7 beschrieben,
wie die tatsächliche
Authentisierung durch Benutzer unter Verwendung des Ausführungsbeispiels der
vorliegenden Erfindung durchgeführt
wird.
-
In
einer indizierten oder verknüpften
Informationsumgebung, wie der GAP-Architektur, hört jeder Benutzer im Allgemeinen
eine Top-Level-Indexnachricht
ab, wie in dem GAP-Kontext die Super-Indexnachricht 30. (Es ist
jedoch anzumerken, dass, obwohl dies typisch sein kann, es für Benutzer
jedoch auch möglich
ist, direkt Indexnachrichten niedrigeren Levels abzuhören). Ob
ein Benutzer die Super-Indexnachricht 30 oder zuerst eine
Indexnachricht niedrigeren Levels abhört, in der vorliegenden Erfindung
ist es für
den Benutzer erforderlich, die Nachricht oder das Informationselement
zu authentisieren, das er zuerst abhört (und das somit als die effektive Route
des Listener-Indexbaums verwendet wird), unter Verwendung eines
sicheren Authentisierungsverfahrens, wie es von der Verschlüsselung
mit öffentlichem
Schlüssel
oder Nachrichtenzugriffscodes vorgesehen ist. Deswegen greift in
Schritt 7.2 ein Benutzercomputer zuerst auf ein Informationselement
zu, was in dem Kontext der GAP-Architektur entweder ein Abhören der
Super-Indexnachricht oder einer anderen Indexnachricht ist. Dann
authentisiert in Schritt 7.4 der Benutzercomputer das empfangene
Informationselement oder die Indexnachricht unter Verwendung einer
starken Authentisierung, wie eine öffentliche Verschlüsselung
oder Nachrichtenzugriffscodes. Wenn eine öffentliche Verschlüsselung
verwendet wird, dann enthält
das digitale Signaturfeld jeder Indexnachricht eine digitale Signatur,
die unter Verwendung der Verschlüsselung
mit öffentlichem
Schlüssel erzeugt
wird. Alternativ, wenn Nachrichtenzugriffscodes verwendet werden,
dann enthält
das digitale Signaturfeld jeder Nachricht eine Serie von Nachrichtenzugriffscodes,
wie sie in der Technik bekannt sind.
-
Es
ist hier anzumerken, dass vorzugsweise jede Indexnachricht oder
Informationselement, die/das von den Indexservern erzeugt wird,
drei zusätzliche
Steuerungs-Flags enthält,
wobei es sich um ein Flag handelt, um anzuzeigen, ob die Nachricht
an sich authentisierbar ist oder nicht, ein weiteres Flag, um anzuzeigen,
ob sie authentisierbar ist unter Verwendung entweder einer digitalen öffentlichen Schlüsselsignatur
oder von Nachrichtenzugriffscodes, und schließlich ein drittes Steuerungs-Flag, um
anzuzeigen, ob sie authentisierbar ist gemäß dem schwachen Authentisierungsverfahren
der vorliegenden Erfindung. Diese Steuerungs-Flags in Kombination
können
dem (GAP)-Listener
sagen, welches Authentisierungsverfahren auf eine empfangene Indexnachricht
angewendet werden sollte.
-
Egal
welches starke Authentisierungsverfahren in Schritt 7.4 verwendet
werden kann, vorausgesetzt, das schwache Authentisierungsverfahren,
das von der vorliegenden Erfindung vorgesehen wird, wird für die empfangene
Indexnachricht verwendet, in Schritt 7.6 werden der Hash-Wert
oder -Werte der verbundenen Informationselemente oder Indexnachrichten
in dem zugegriffenen ersten Informationselement oder der (Super)-Indexnachricht
gespeichert. In der GAP-Architektur
werden die Hash-Werte von Indexnachrichten niedrigeren Levels, die
in der ersten empfangenen Indexnachricht referenziert werden, gespeichert.
-
Wenn
dann der (GAP)-Listener bestimmt, dass er auf eines der verbundenen
Informationselemente (wie eine Indexnachricht des niedrigeren Levels)
zugreifen muss, wird in Schritt 7.8 auf das Informationselement
oder die Indexnachricht zugegriffen. Dann wird, um nur die schwache
Authentisierung dieser Nachricht oder dieses Informationselements durchzuführen und
von der sicheren Authentisierung zu leihen, die durch Verwendung
des starken Authentisierungsverfahrens in Schritt 7.4 erlangt
wurde, in Schritt 7.10 der Hash-Wert des zugegriffenen
Informationselements oder der Indexnachricht berechnet und in Schritt 7.12 wird
der berechnete Hash-Wert mit dem gespeicherten Hash-Wert verglichen,
der aus der ersten empfangenen Indexnachricht oder dem Informationselement
genommen wurde, die/das der starken Authentisierung unterzogen wurde. Durch
einen Vergleich des in Schritt 7.10 berechneten Hash-Werts
mit dem Hash-Wert,
der aus der sicher authentisierten Indexnachricht oder dem Informationselement
abgerufen wurde, ist es möglich, eine
Aussage zu treffen, ob das Informationselement oder die Indexnachricht,
auf das/die in Schritt 7.8 zugegriffen wird, authentisch
ist, durch effektives „Leihen" der Sicherheit von
dem Informationselement oder der Indexnachricht, das/die unter Verwendung des
starken Authentisie rungsverfahrens sicher authentisiert wurde, das/die
aber auf das neu zugegriffene Informationselement oder die Indexnachricht zeigt
und darin auch einen Hash-Wert des angezeigten Informationselements
oder der Indexnachricht enthält.
Wenn der Hash-Wert, der aus dem tatsächlichen Informationselement
oder der Indexnachricht berechnet wurde, auf die in Schritt 7.8 zugegriffen wurde,
nicht gleich ist zu dem Hash-Wert, der aus der sicher authentisierten
Indexnachricht oder dem Informationselement abgerufen wurde, dann
wird das zugegriffene Informationselement oder die Indexnachricht
verworfen.
-
Die
obigen Schritte 7.2 bis 7.12 beschreiben im Wesentlichen,
wie ein einzelnes Informationselement oder eine Indexnachricht eine
Ebene unter dem ersten Informationselement oder der Indexnachricht, das/die
sicher authentisiert wurde, von dessen/deren sicherer Authentisierung
profitieren kann. Jedoch sieht die vorliegende Erfindung auch die
sichere Authentisierung vor, die von dem starken Authentisierungsverfahren
von Schritt 7.4 vorgesehen wird, die weiter entlang des
Indexbaums geleitet wird an Informationselemente oder Indexnachrichten,
die weiter unten in dem Indexbaum liegen. Dies wird in dem unteren
Teil der 3 gezeigt.
-
Hier
wird die Super-Indexnachricht 30 sicher authentisiert unter
Verwendung eines starken Authentisierungsverfahrens, wie Nachrichtenzugriffscodes
oder Verschlüsselung
mit öffentlichem
Schlüssel.
Die derart authentisierten Werte hierin umfassen jedoch Hash-Werte der Indexnachrichten,
die in der Super-Indexnachricht 30 referenziert sind, wie
zum Beispiel die Indexnachricht 32 des dazwischenliegenden
Levels. Somit kann, wie bereits beschrieben, die Indexnachricht 32 des
dazwischenliegenden Levels authentisiert werden durch Vergleichen
eines Hash-Wertes, der aus der Nachricht 32 bei Empfang berechnet
wird, mit dem Hash-Wert, der in der Super-Indexnachricht 30 angezeigt
wird. Jedoch referenziert auch die In dexnachricht 32 des
dazwischenliegenden Levels selbst eine Indexnachricht 34 niedrigen
Levels und enthält
auch den Hash-Wert dieser Indexnachricht 34 niedrigen Levels.
Somit ist es, wenn auf die Indexnachricht 34 niedrigen
Levels zugegriffen wird und sie abgerufen wird, für den Benutzercomputer
möglich,
den Hash-Wert der zugegriffenen Nachricht 34 zu berechnen
und diesen berechneten Wert mit dem Hash-Wert zu vergleichen, der
in der Indexnachricht 32 des dazwischenliegenden Levels
enthalten ist, der selbst durch Referenz zu der Super-Indexnachricht 30 authentisiert
wurde. Auf diese Weise kann die Authentisierung der Super-Indexnachricht 30,
die von dem starken Authentisierungsverfahren unter Verwendung einer
Verschlüsselung
mit öffentlichem
Schlüssel
oder der Nachrichtenzugriffscodes vorgesehen wird, in dem Indexbaum
von Indexnachricht zu Indexnachricht (oder allgemeiner von Informationselement
zu Informationselement) weitergeleitet werden durch Referenz zu
den Hash-Werten, die in jeder Nachricht der Nachrichten eine Ebene
unter ihnen in dem Baum enthalten sind. Eigentlich wird die starke
Authentisierung der Super-Indexnachricht (oder der ersten zugegriffenen Nachricht
oder des Informationselements) von den Indexnachrichten des dazwischenliegenden
und niedrigen Levels „ausgeliehen". Es ist die Aufgabe dieser
Hash-Werte, die starke Authentisierung der ersten (oder Super-)Indexnachricht
effektiv weiterzuleiten, die wir hier als „schwache Authentisierung" bezeichnen.
-
Zurück zu 7,
diese Fähigkeit,
eine verschachtelte schwache Authentisierung vorzusehen, kann durch
das Vorsehen des Schrittes 7.14 vorgesehen werden, wobei
nachfolgend auf die schwache Authentisierung des Informationselements
oder der Indexnachricht, auf das/die in Schritt 7.8 zugegriffen wird,
eine Evaluierung gemacht wird, um zu bestimmen, ob dieses Informationselement
oder diese Indexnachricht selbst weitere Verbindungen zu Informationselemente
oder Indexnachrichten des niedrigeren Levels enthält. Wenn
ja, ent hält
die Nachricht auch die Hash-Werte der Informationselemente oder Indexnachrichten
des niedrigeren Levels, die hier referenziert sind, und somit kehrt
die Verarbeitung zurück
zu Schritt 7.6, wo diese Hash-Werte gespeichert werden.
Auf die verwiesenen Informationselemente oder Indexnachrichten des
niedrigeren Levels wird dann in Schritt 7.8 zugegriffen
und die Hash-Werte der zugegriffenen Informationselemente oder Indexnachrichten
werden in Schritt 7.10 berechnet. Eine schwache Authentisierung
wird dann vorgesehen durch Vergleichen des berechneten Hash-Werts mit
den Hash-Werten,
die gerade gespeichert wurden in Schritt 7.6, und wenn
die Hash-Werte übereinstimmen,
dann kann die Nachricht als authentisch angesehen werden.
-
Es
sollte angemerkt werden, dass die oben beschriebene Iteration so
oft wie erforderlich wiederholt werden kann, abhängig davon, wie viele Ebenen in
dem Indexbaum vorhanden sind. In jeder Iteration wird die starke
Authentisierung, die für
das Informationselement oder die Indexnachricht vorgesehen ist, auf
das/die zuerst zugegriffen wurde, effektiv den Indexbaum entlang
weitergeleitet.
-
Obiges
beschreibt, wie die schwache Authentisierung der vorliegenden Erfindung
durchgeführt
wird, durch effektives „Ausleihen" der starken Authentisierung
des Informationselement oder der Indexnachricht, auf das/die zuerst
zugegriffen wird. Es wurde oben erwähnt, dass beabsichtigt ist,
dass die starke Authentisierung durchgeführt wird unter Verwendung einer
Verschlüsselung
mit öffentlichem Schlüssel, um
eine digitale Signatur zu erzeugen, oder unter Verwendung von Nachrichtenzugriffscodes.
Während
diese beiden Authentisierungsverfahren selbst an sich in der Technik
bekannt sind, werden weitere Details ihrer Anwendung auf das Ausführungsbeispiel
der vorliegenden Erfindung im Folgenden gegeben.
-
Eine
Authentisierung unter Verwendung digitaler Signaturen, die unter
Verwendung einer Verschlüsselung
mit öffentlichem
Schlüssel
erzeugt werden, ist in der Technik weithin bekannt, und es werden
wenig weitere Details hier gegeben. RSA ist der bevorzugte öffentliche
Verschlüsselungsalgorithmus zur
Verwendung mit der Erfindung und ist der Industriestandard auf der
meisten Welt. Der RSA-Algorithmus
wurde in den U.S.A patentiert, das Patent ist am 20. September 2000
abgelaufen.
-
Die
Verwendung von digitalen Signaturen erfordert auch die Verwendung
einer Einweg-Hash-Funktion und der bevorzugte Algorithmus ist MD4,
eine Einweg-Hash-Funktion, die von Ron Rivest entwickelt wurde.
MD steht für
Nachrichten-Kurzfassung (message digest), der Algorithmus erzeugt
eine Ausgabe von 128 Bit. Es ist der schnellste Algorithmus hinsichtlich
der Verschlüsselungsgeschwindigkeit,
die letzte Version MDS verbessert MD4, ist aber komplexer und langsamer.
Es ist anzumerken, dass diese Hash-Funktion auch vorzugsweise verwendet
wird, um die Hash-Werte zu berechnen, die für eine schwache Authentisierung
in der vorliegenden Erfindung erforderlich sind.
-
Eine
Verwendung digitaler Signaturen erfordert auch einen Authentisierungsserver.
Dieser arbeitet wie eine Datenbank und verteilt an den Benutzer
das Zertifikat, das die Identität
des Indexgenerators enthält,
und seinen öffentlichen
Schlüssel.
Das Zertifikat ist für
eine Zeitdauer gültig.
Der Benutzer kann auf das Zertifikat zugreifen unter Verwendung einer
URL, die in der Indexankündigung
spezifiziert wird.
-
Als
eine Alternative zur Verwendung einer Kryptographie mit öffentlichem
Schlüssel
erwähnen wir
auch, dass Nachrichtenzugriffscodes (MAC – Message Access Codes) ebenso
als das starke Authentisie rungsverfahren verwendet werden können, und
weitere Details der Verwendung von MACs in dem vorliegenden Ausführungsbeispiel
werden im Folgenden angeführt.
-
Bei
der Verwendung des „Generic
Announcement Protocol" (GAP)
sind wir daran interessiert, Indexankündigungen authentisieren zu
können, die
andere Indexankündigungen
betreffen, und schließlich
Datenankündigungen
von verschiedenen Anwendungen. Jeder Indexgenerator hat eine Sequenz
von N sekundären
Schlüsseln
und jeder Empfänger,
der am Abhören
der Indizes interessiert ist, die von diesem Generator erzeugt werden,
erhält
einen Teilsatz der primären
Schlüssel.
Die Schlüssel des
Empfängers
werden auf eine Weise verteilt, welche die Wahrscheinlichkeit beschränkt, dass
eine Benutzerkoalition alle Schlüssel
eines Senders kennen kann. Wenn ein Listener Indexankündigungen
authentisieren möchte,
muss er sich mit einem Authentisierungsserver verbinden, der einen
Teilsatz der primären
Schlüssel
verteilt. Dieses Verfahren ist interessant, da es keine Komplexität auf der
Empfängerseite
hinzufügt.
Der Empfänger,
der einen Teilsatz der primären
Schlüssel
kennt, kann die Authentisierung jeder Indexankündigung prüfen unter Verwendung immer
derselben Schlüssel.
Hinsichtlich einer Berechnungsressource muss ein Empfänger, der
die Authentizität
einer Indexankündigung
verifizieren muss, eine Hash-Funktion für jeden Schlüssel ausführen, den
er kennt. Wenn jedoch der Verifizierungsprozess zu teuer wird, kann
die Authentisierung einer Nachricht evaluiert werden mit kleinen
Teilsätzen
des primären
Schlüssels
(weniger pseudozufällige
Funktionsberechnung erforderlich). Dies ist akzeptabel, da ein Index
an sich authentisiert wird durch Bezugnahme durch einen vorher authentisierten
Index oder durch Referenzieren schließlich einer Datenankündigung,
die authentisiert wird.
-
Das
grundlegende Index-Authentisierungsschema geht wie folgt weiter:
-
Terminologie:
-
- R' = <K'1, K'2, K'3, ..., K'N> Satz primärer Schlüssel, R''I_S
= <H(K'1, I_S), H(K'2, I_S), ..., H(K'N, I_S)> Satz sekundärer Schlüssel;
- I_S, der Server, der die Indexankündigung erzeugt, kennt einen
Satz von N sekundären
Schlüsseln R''I_S;
- A_S, der Authentisierungsserver kennt und verteilt einen Satz
von R' und R''I_S;
- S, Server, der die Sitzung initiiert;
- U, der Empfänger,
kennt einen Teilsatz der N primären
Schlüssel
R' u I R'.
-
U
sendet eine Anforderung an den Server S für eine Information und empfängt als
Antwort Daten und Indexinformation mit einer Unicast-Nachricht, die von
dem Server S gesendet wird. U nimmt dann an dem Indexkanal teil
und sendet weiter eine Anforderung an A_S und fragt nach dem Teilsatz
der primären
Schlüssel
R' u I R'. Dieser Teilsatz
wird verteilt unter Verwendung eines sicheren Kanals. Dann sendet I_S
Nachrichten, die unter Verwendung einer MAC-Funktion authentisiert
sind. Eine Nachricht wird begleitet von <MAC (K''1,
M), MAC (K''2, M), MAC (K''3, M), ..., MAC (K''N,
M)>. Wenn U eine Indexankündigung
empfängt,
verifiziert er alle die MACs, die unter Verwendung der Schlüssel in
seinem Teilsatz erzeugt wurden.
-
Das
MACs-Verfahren, das oben beschrieben wurde, kann die Laufzeit der
Authentisierungsoperation reduzieren. Die Laufzeit für den Authentisierer wird
dramatisch reduziert, die Laufzeit des Verifizierers ist vergleichbar
mit der öffentlichen
Schlüsselsignatur.
Jedoch kann in einem bestimmten Fall die Verifizierung ablaufen
unter Verwendung eines beschränkten
Teilsatzes von Schlüsseln,
um die Leistung zu verbessern.
-
Unter
Berücksichtigung
des Kommunikations-Overheads haben die zwei Algorithmen eine ähnliche
Leistung. Für
die MACs werden Hash-Funktionen
verwendet unter Verwendung nur 1 Bits aus jedem MAC. Unter Berücksichtigung
der öffentlichen Verschlüsselungssignatur
ist eine Anforderung, dass jeder Empfänger den öffentlichen Schlüssel jeder Quelle
speichern soll. Das Schlüsselzertifikat
wird nicht mit der Nachrichtenankündigung gesendet, ansonsten
wird die Länge
der Nachricht erhöht.
Zu jedem Paket wurde ein Feld (URL oder IP-Adresse) hinzugefügt, das zu dem Authentisierungsserver zeigt.
Beide Lösungen
erfordern die Verteilung eines öffentlichen
Schlüssels
oder primärer
Schlüssel,
die vorgesehen werden unter Verwendung des Authentisierungsservers
(A.S.). Diese Schlüsselverteilung
ist oft eine Sicherheitsfrage hinsichtlich der Schlüsselverwaltung,
ein ähnliches
Problem ist die Entwicklung der öffentlichen
Schlüsselinfrastruktur
(PKI – Public
Key Infrastructure). Die schwache Authentisierungstechnik der vorliegenden
Erfindung löst
auch teilweise dieses Problem durch Minimieren der Anzahl von Sätzen von
Schlüsseln
(in dem Fall der MACs) oder öffentlichen
Schlüsseln
(in dem Fall der Verschlüsselung
mit öffentlichem
Schlüssel),
die verteilt werden müssen.
-
Das
oben beschriebene Ausführungsbeispiel hat
die Anwendung der Erfindung auf eine Index-basierte Ereignisankündigungsarchtitektur,
wie GAP, beschrieben, aber es sollte offensichtlich sein, dass die
Erfindung nicht auf eine derartige Verwendung beschränkt ist
und in jedem System verwendet werden kann, wo eine sichere starke
Authentisierung zuerst erforderlich ist, wobei die Authentisierung
dann weitergeleitet werden kann an verbundene Datenelemente über ein
relativ weniger sicheres schwaches Authentisierungsverfahren. Als
ein Beispiel eines weiteren Systems kann in einem weiteren Ausführungsbeispiel,
das eine Gruppenkommunikation vorsieht, ein Authentisierungsserver
(äquivalent
in der Struktur und Funktion zu ei nem Indexserver des ersten Ausführungsbeispiels)
Authentisierungsnachrichten an eine Gruppe von Benutzern verteilen,
wobei die Authentisierungsnachrichten zu einer starken Authentisierung
fähig sind,
die aber auch einen Zugriff auf tatsächliche Datennachrichten ermöglichen,
die dann auf die schwache Weise der vorliegenden Erfindung authentisiert
werden.
-
Ein
zweites Ausführungsbeispiel
der vorliegenden Erfindung wird nun unter Bezugnahme auf die 8, 9 und 10 beschrieben.
Das zweite Ausführungsbeispiel
soll ermöglichen,
dass eine schwache Authentisierung von unterschiedlichen zeitvariierenden
Versionen desselben Informationselements durchgeführt wird.
Somit kann zum Beispiel in dem GAP-Szenario eine Indexnachricht
mit dem Namen Index_1 und der Versionsnummer 1 unter Verwendung
einer starken Authentisierung authentisiert werden, aber dann können nachfolgende
Versionen der Indexnachricht, wie Index_1, Versionsnummer 2 und
Versionsnummer 3, usw., unter Verwendung einer schwachen Authentisierung
in einer Kette von der starken Authentisierung der anfänglichen Version
authentisiert werden. Das zweite Ausführungsbeispiel erweitert somit
das Konzept des oben beschriebenen ersten Ausführungsbeispiels, um eine schwache
Authentisierung weiterer Versionen desselben Informationselements
zu ermöglichen.
Dies wird ereicht durch im Vorhinein Erzeugen einer Hash-Kette der
Länge M,
wobei die Werte der Hash-Kette dann als die schwachen Authentisierungsdaten
verwendet werden.
-
Das
Konzept der vorliegenden Erfindung wird klarer durch Bezugnahme
auf das in 10 gezeigte Beispiel. Hier erzeugt
ein Indexserver vor der Erzeugung der Informationselemente eine
Hash-Kette, die von einer anfänglichen
zufälligen
Nachricht m startet. m ist vorzugsweise eine geeignete Größe, damit
die Hash-Kette eine geeignete Län ge
irgendwo zwischen 20 und 1000 Werten hat. Ein Beispiel davon wäre, wenn
m ein zufälliger
Satz von Daten der Länge
128 Bits ist.
-
Die
Hash-Kette wird konstruiert durch n-Mal Anwenden einer Einweg-Funktion
rekursiv auf m, bis n Hash-Werte erzeugt wurden. Das heißt, um einen ersten
Hash-Wert zu erzeugen, wird m als eine Eingabe in eine Einweg-Funktion
verwendet, die als die Hash-Funktion verwendet wird, um einen ersten Hash-Wert
m' zu liefern. Dann
wird m' als die
Eingabe in die Einweg-Funktion verwendet, um einen zweiten Hash-Wert
m'' zu liefern. Dieser
zweite Hash-Wert m'' wird dann wieder
als die Eingabe in die Hash-Funktion verwendet, um einen dritten
Hash-Wert m''' zu liefern, und so weiter, bis eine
Kette von Hash-Werten der Länge
n erzeugt wurde.
-
Sobald
die Hash-Kette erzeugt wurde, kann ein Indexserver, der das zweite
Ausführungsbeispiel der
Erfindung durchführt,
Informationselemente ausgeben, wie Nachrichtenelemente. 10 liefert
ein Beispiel eines ersten Nachrichtenelements 102, das eine
GAP-Indexnachricht
mit dem Namen Index_1 und der Versionsnummer eins ist. Das Nachrichtenelement 102 trägt Nutzlastdaten
in der Form von Nachrichten-IDs und Versionsnummern für andere GAP-Nachrichten und ebenso
Hash-Werte für
diese weiteren Nachrichten zur Verwendung derer schwachen Authentisierung
auf dieselbe Weise, wie oben hinsichtlich des ersten Ausführungsbeispiels
beschrieben. Zusätzlich,
um eine starke Authentisierung des Nachrichtenelements 102 vorzusehen,
wird auch ein digitales Signaturfeld getragen. Jedoch trägt gemäß dem zweiten
Ausführungsbeispiel
der Erfindung das Nachrichtenelement 102 auch ein weiteres Nachrichten-Hash-Feld, in dem
einer der Hash-Werte gespeichert ist, der von der Hash-Kette erzeugt wird.
Da dies die erste Version des Nachrichtenelements Index_1 ist, ist
der Hash-Wert in dem Nachrichten-Hash- Feld der des letzten Hash-Werts in der Hash-Kette.
Der Grund dafür
wird später
offensichtlich.
-
Nun
wird angenommen, dass der Indexserver das Nachrichtenelement 102 übertragen
hat und dass es an einem GAP-Listener an einem Benutzercomputer
empfangen wurde. Der Benutzercomputer kann das empfangene Nachrichtenelement 102 stark authentisieren
und dann nachfolgend weitere Nachrichten, die in dem Nachrichtenelement 102 referenziert
sind, schwach authentisieren unter Verwendung der schwachen Authentisierungsdaten,
die darin vorgesehen sind, die diese anderen Nachrichten betreffen,
auf die in dem ersten Ausführungsbeispiel
beschriebene Weise. Zusätzlich
wird jedoch der Hash-Wert aus dem zusätzlichen Nachrichten-Hash-Feld
ebenfalls gespeichert, und was eine schwache Authentisierung weiterer
Versionen des Nachrichtenelements Index_1 ermöglicht, wie im Folgenden beschrieben
wird.
-
Nun
wird deshalb angenommen, dass die Informationselemente, auf die
in dem Nachrichtenelement Index_1 Bezug genommen wird, derart geändert werden,
dass eine weitere Version des Index_1-Nachrichtenelements übertragen werden muss. Diese
weitere Version wird als das Nachrichtenelement 104 gezeigt,
was das Index_1-Nachrichtenelement
mit der Versionsnummer 2 ist. Wie oben trägt das Nachrichtenelement 104 Nutzlastdaten,
die Zeiger sind, und schwache Authentisierungsdaten für weitere
Informationselemente zur Verwendung auf die oben beschriebene Weise
hinsichtlich des ersten Ausführungsbeispiels.
Zusätzlich
trägt das
Nachrichtenelement 104 auch ein digitales Signaturfeld,
um dessen starke Authentisierung selbständig zu ermöglichen.
-
Gemäß dem zweiten
Ausführungsbeispiel der
Erfindung hat das Nachrichtenelement 104 zusätzlich zu
Obigem auch ein Nachrichten- Hash-Feld, das
darin einen Hash-Wert trägt,
der für
eine schwache Authentisierung des Nachrichtenelements verwendet
werden kann. Der Hash-Wert in diesem Feld ist der vorletzte Wert
in der Hash-Kette,
die vorher von dem Server erzeugt wurde. Dies ist so, damit der Hash-Wert
in dem Nachrichten-Hash-Feld verwendet werden kann, um das Nachrichtenelement 104 schwach
zu authentisieren durch Ausleihen der starken Authentisierung der
vorherigen Version der Index_1-Nachricht in der Form des Nachrichtenelements 102.
Eine schwache Authentisierung wird wie folgt durchgeführt.
-
Wenn
ein GAP-Listener an einem Benutzercomputer das Nachrichtenelement 104 empfängt, liest
er den Hash-Wert in dem Nachrichten-Hash-Feld und verwendet den
Hash-Wert als eine Eingabe in eine Hash-Funktion. Die Hash-Funktion
ist eine identische Einweg-Funktion
zu der, die von dem Indexserver verwendet wurde, um die Hash-Kette
zuerst zu erzeugen, so dass die Ausgabe der Hash-Funktion ein weiterer Hash-Wert ist,
der identisch zu dem Hash-Wert sein sollte, der in dem Nachrichten-Hash-Feld
des Nachrichtenelements 102 gespeichert wurde, wenn das
Nachrichtenelement 104 authentisch ist. Da der Hash-Wert
aus dem Nachrichten-Hash-Feld des Nachrichtenelements 102 vorher
von dem GAP-Listener gespeichert wurde, wird ein Vergleich des gespeicherten
Werts und des Hash-Werts,
der aus dem in dem Nachrichtenelement 104 enthaltenen Hash-Wert
berechnet wird, durchgeführt
und wenn der Vergleich zeigt, dass der berechnete Hash-Wert derselbe
ist die der Hash-Wert, der aus dem Nachrichtenelement 102 gespeichert
ist, dann wird das Nachrichtenelement 104 authentisiert.
Auf diese Weise kann das Nachrichtenelement 104 die starke
Authentisierung des Nachrichtenelements 102 auf eine schwache
Weise „ausleihen".
-
Nun
wird angenommen, dass die Nachrichten, welche die Index_1-Nachrichtenelemente
betreffen, sich wieder derart verändert haben, dass ein weiteres
Index_1-Nachrichtenelement mit der Versionsnummer 3 von dem Server übertragen
werden muss. Ein derartiges Nachrichtenelement wird in 10 als Nachrichtenelement 106 gezeigt,
woher zu sehen sein wird, dass dieses eine Versionsnummer 3 hat. Dieses
Nachrichtenelement 106 enthält auch Zeiger und schwache
Authentisierungsdaten für
andere Nachrichtenelemente auf dieselbe Weise wie oben hinsichtlich
des erste Ausführungsbeispiels
beschrieben wurde und enthält
auch seine eigene digitale Signatur, um dessen unabhängige starke
Authentisierung zu ermöglichen.
Zusätzlich
hat jedoch gemäß dem zweiten
Ausführungsbeispiel
das Nachrichtenelement 106 ein Nachrichten-Hash-Feld, das
in diesem Fall einen Hash-Wert enthält, welcher der drittletzte
in der Hash-Kette war, die im voraus von dem Server erzeugt wurde.
Wenn ein GAP-Listener
an einem Benutzercomputer das Nachrichtenelement 106 empfängt, kann
der Hash-Wert, der in dem Nachrichten-Hash-Feld enthalten ist, in
die Einweg-Funktion eingegeben werden, um einen weiteren Hash-Wert zu
erlangen, der dann mit dem Hash-Wert verglichen wird, der in dem
Nachrichten-Hash-Feld des Nachrichtenelements 104 empfangen
wird, und wenn der berechnete Hash-Wert derselbe ist wie der gespeicherte
Wert, dann wird das Nachrichtenelement 106 authentisiert.
Somit ist zu sehen, dass die schwache Authentisierung von dem ursprünglichen
Nachrichtenelement 102 entlang der zeitvariierenden Versionen
des Nachrichtenelements weitergeleitet werden kann mittels der Hash-Werte,
die von der Hash-Kette erzeugt werden. Während die 10 nur
zwei Schritte der schwachen Authentisierung zeigt, um das Nachrichtenelement 104 und
das Nachrichtenelement 106 zu authentisieren, sollte offensichtlich
sein, dass so viele weitere Schritte der schwachen Authentisierung
weiterer Versionen des Nachrichtenelements Index_1 durchgeführt werden
können,
wie es Elemente in der Hash-Kette gibt. Vorzugsweise wird jedoch
die schwache Authentisierung nicht für mehr als 100 Nachrichten
durchgeführt,
danach führt
der GAP-Listener an dem Benut zercomputer eine starke Authentisierung
durch und dann startet die schwache Authentisierungskette neu. Das
heißt,
die Hash-Kette muss nicht länger
als 100 Hash-Werte sein. Eine derartige Anordnung hilft, eine hohe
Sicherheit für
die Nachrichten aufrecht zu erhalten.
-
Somit
kann gemäß dem zweiten
Ausführungsbeispiel
eine schwache Authentisierung für zeitvariable
Versionen derselben Informationselemente sowie zwischen unterschiedlichen
Informationselementen durchgeführt
werden.
-
8 und 9 formalisieren
das oben beschriebene Verfahren in die Funktionen, die von einem
Indexserver, wie in 4 gezeigt, und einem Empfängercomputer,
wie in 6 gezeigt, durchgeführt werden. Insbesondere zeigt
die 8 die Schritte, die von einem Compilerprogramm 486 an
einem Indexserver 40 gemäß dem zweiten Ausführungsbeispiel
durchgeführt
werden und als nächstes beschrieben
werden.
-
Zuerst
erzeugt in Schritt 8.1 der Indexserver eine Hash-Kette
der Länge
n. Wie oben beschrieben, wird eine Hash-Kette erzeugt durch Eingabe
eines bekannten Stücks
von zufälligen
Daten, das vorzugsweise eine Länge
von 128 Bit hat, in eine Einwegfunktion, um einen ersten Hash-Wert
zu erlangen. Der erlangte Hash-Wert wird dann verwendet als die Eingabe
in die Funktion, um einen zweiten Hash-Wert zu erlangen, der dann weiter verwendet wird
als eine Eingabe in die Funktion, um einen dritten Hash-Wert zu
erlangen, und so weiter. Die Einweg-Funktion wird somit (n – 1)-Mal
rekursiv angewendet, um eine Hash-Kette der Länge n zu erlangen.
-
Dann
wird in Schritt 8.2 ein Zähler x auf eins initialisiert.
Dieser Zähler
wird verwendet, um dem Indexserver zu ermöglichen, eine Aufzählung der
Anzahl der Nachrichten, die erzeugt werden, hinsichtlich der Hash-Kette
zu behalten, so dass er weiß, wann
eine neue Hash-Kette erzeugt werden muss.
-
Dann
wird in Schritt 8.3 eine FOR-Schleife initialisiert, die
auf dem Informationselement der Version x wirkt. Bei der ersten
Iteration der FOR-Schleife, da bei Schritt 8.2 x auf eins
initialisiert wurde, wirkt die FOR-Schleife auf das Informationselement
der Version 1.
-
In
der FOR-Schleife ist der erste durchzuführende Schritt der Schritt 8.4,
wobei auf das zu verbindende Informationselement zugegriffen wird.
Zum Beispiel kann dies in dem Beispiel der 10 das
Informationselement Index_10 sein, das in der Nutzlast des Nachrichtenelements
Index_1 referenziert ist. Dann wird in Schritt 8.5 der
Hash-Wert des zugegriffenen
Informationselements berechnet und in Schritt 8.6 wird
ein neues Informationselement, Index_1, Version x (in diesem Fall
Version 1 bei der ersten Iteration) kompiliert, das die ID des zugegriffenen
Informationselements sowie den berechneten Hash-Wert umfasst.
-
In
Schritt 8.7 werden starke Authentisierungsdaten in der
Form eines Nachrichtenzugriffscodes oder einer digitalen Signatur
erzeugt für
das neue Informationselement Index_1, Version eins. Dann werden
in dem Schritt 8.8 die starken Authentisierungsdaten in
dem neu kompilierten Informationselement Index_1, Versionsnummer
1 aufgenommen. Insoweit sind die Schritte 8.4, 8.5, 8.6, 8.7 und 8.8 identisch
zu den entsprechenden Schritten, wie in dem ersten Ausführungsbeispiel
durchgeführt.
-
Gemäß dem zweiten
Ausführungsbeispiel wird
jedoch in dem Schritt 8.9 in dem Informationselement Index_1,
Versionsnummer 1 zusätzlich
ein Hash-Wert aus der Hash-Kette aufgenommen, der in einem Nachrichten-Hash-Feld
enthalten ist, das darin explizit vorgesehen ist. Insbesondere ist
der Hash-Wert, der in dem Nachrichten-Hash-Feld enthalten ist, der (n + 1-x)-te
Hash-Wert aus der Hash-Kette. Das heißt, bei der ersten Iteration
durch die FOR-Schleife, wo x gleich 1 ist, ist der n-te Hash-Wert
aus der Hash-Kette, d.h. der letzte Wert in der Hash-Kette, als
der Hash-Wert in dem Nachrichten-Hash-Feld enthalten. Der Grund
dafür wird
oben erläutert,
da die nächste
Version der Nachricht, wenn gesendet, unter Verwendung der Hash-Funktion authentisiert
werden kann.
-
In
Schritt 8.10 wird das Nachrichtenelement 102,
wobei es sich um die Nachricht mit Index_1, Versionsnummer 1 handelt,
zum Empfang durch GAP-Listeners an den verschiedenen Benutzercomputern übertragen.
Dann wird in Schritt 8.11 eine Evaluation durchgeführt, um
zu prüfen,
ob x gleich n ist, welche die Anzahl von Hash-Werten in der Hash-Kette
sind, und wenn nicht, geht die Verarbeitung weiter zu Schritt 8.12,
wo x um 1 inkrementiert wird. Danach geht die Verarbeitung weiter
zu dem Beginn der FOR-Schleife an dem Schritt 8.3 und die Schritte
in der FOR-Schleife werden wiederholt, dieses Mal mit x gleich 2.
Es sollte hier angemerkt werden, dass, sobald x inkrementiert wurde,
die Schritte in der FOR-Schleife beginnend bei Schritt 8.3 nur wiederholt
werden, wenn eine neue Version des Informationselements mit Index_1
erforderlich ist. Sobald eine solche neue Version erforderlich ist,
werden die Schritte durchgeführt
mit der Versionsnummer (x) auf 2 gesetzt.
-
Zurück zu einer
Betrachtung des Schrittes 8.11 wird hier bestimmt, dass
x gleich n ist, was bedeutet, dass so viele Versionen der Index_1-Nachricht übertragen
wurde, wie es Elemente der Hash-Kette gibt. In einem solchen Fall
ist es nicht länger
möglich,
einen Hash-Wert
in das Nachrichten-Hash-Feld von neuen Versionen der Nachricht zu platzieren,
und somit kann die schwache Authentisierung nicht weiter entlang
der Nachrichten-Versions-Kette weitergeleitet werden. In einem solchen Fall
wird der Prozess in 8 als endend gezeigt, aber in
der Realität
ist wahrscheinlich, dass der Prozess einfach wieder bei Schritt 8.1 beginnt,
wobei eine weitere Hash-Kette erzeugt wird und die Schritte wiederholt
werden. In einem solchen Fall muss jedoch an einem GAP-Listener
an einem Benutzercomputer, der die Nachrichten empfängt, eine
starke Authentisierung der Index_1-Nachricht mit Versionsnummer (n + 1)
stark authentisiert werden unter Verwendung der digitalen Signatur.
Sobald eine solche starke Authentisierung durchgeführt wurde,
können nachfolgende
Versionen der Nachricht dann schwach authentisiert werden auf die
oben beschriebene Weise.
-
9 zeigt
vormals die Schritte, die an einem GAP-Listener an einem Benutzercomputer durchgeführt werden,
um eine Sequenz von Nachrichtenelementen mit unterschiedlichen zeitvariierenden
Versionen zu authentisieren. Ein derartiger Prozess wird zum Beispiel
durchgeführt
von dem GAP-Programm 682 in Kombination mit dem starken Authentisierungsprogramm 686 und
dem schwachen Authentisierungsprogramm 688, die sich an
den Benutzercomputern befinden.
-
Unter
Bezugnahme auf 9 wird zuerst an Schritt 9.1 eine
Variable y auf eins initialisiert. Dann wird in Schritt 9.2 die
erste Version des Informationselements, z.B. das Nachrichtenelement
Index_1, empfangen. Da dies die erste Version des Nachrichtenelements
ist, ist es in Schritt 9.3 erforderlich, das empfangene
Nachrichtenelement stark zu authentisieren unter Verwendung der
darin enthaltenen digitalen Signatur. Sobald die Nachricht authentisiert wurde,
wird in Schritt 9.4 der Hash-Wert aus dem Nachrichten-Hash-Feld
gespeichert. Da dies die erste Version des Nachrichtenelements ist,
ist der Hash-Wert der letzte Hash-Wert in der Hash-Kette, die von
dem Indexserver erzeugt wird. Der Schritt 9.4 beendet die
Schritte, die unmittelbar auf den Empfang der ersten Version des
Informationselements Index_1 durchgeführt werden, und der Benutzercomputer
wartet dann, bis die nächste
Version des Nachrichtenelements (zum Beispiel das Nachrichtenelement 106,
Index eins, Versionsnummer 2) in Schritt 9.5 empfangen
wird. Sobald dies stattgefunden hat, wird in Schritt 9.6 der
Zähler
y um eins inkrementiert, und dann wird in Schritt 9.7 der
Hash-Wert aus dem Nachrichten-Hash-Feld der neu empfangenen Version
des Nachrichtenelements gespeichert.
-
Dann
wird in Schritt 9.8 der Hash-Wert aus der neu empfangenen
Version des Nachrichtenelements als eine Eingabe in eine Einwegfunktion
verwendet, die identisch ist zu der Einwegfunktion, die von dem
Indexserver verwendet wurde, um die Hash-Kette zu erzeugen. Die
Ausgabe dieser Einwegfunktion ist ein weiterer Hash-Wert, der dann
in Schritt 9.9 mit dem Hash-Wert verglichen wird, der vorher
in der vorherigen Version des Nachrichtenelementsempfangen wurde,
und von dem Benutzercomputer gespeichert. Wenn der berechnete Hash-Wert gleich
ist zu dem vorher gespeicherten Hash-Wert, dann wird die neu empfangene
Version des Nachrichtenelements authentisiert. Auf diese Weise kann durch
Berechnen eines Hashes eines Hash-Werts, der in einem neu empfangenen
Nachrichtenelement enthalten ist, und dessen Vergleichen mit dem Hash-Wert,
der in einer vorher empfangenen Version des Nachrichtenelements
empfangen wurde, und das selbst authentisiert wurde, die Authentisierung des
vorher empfangenen Nachrichtenelements für das neue Nachrichtenelement
auf eine schwache Weise „ausgeliehen" werden. Somit wird
eine schwache Authentisierung des neu empfangenen Nachrichtenelements
durchgeführt.
-
Nach
der schwachen Authentisierung wird in Schritt 9.9 eine
Evaluierung durchgeführt,
um zu bestimmen, ob der Zähler
y geringer ist als eine Anzahl n, welche die Anzahl der Hash-Werte
in der Hash- Kette
ist, die von dem Server erzeugt wird. Diesen Wert n kennen die GAP-Listener
gemäß dem schwachen
Authentisierungsprotokoll. Wenn y geringer als n befunden wird,
kehrt die Verarbeitung zu Schritt 9.5 zurück, wobei
der Empfänger
wartet, um die nächste
Version der Nachrichtenelemente zu empfangen. Sobald die nächste Version
empfangen wurde, kann deren schwache Authentisierung durchgeführt werden
durch Wiederholen der Schritte 9.6, 9.7, 9.8 und 9.9,
wie oben beschrieben. Auf diese Weise kann die schwache Authentisierung
von Version zu nachfolgender Version so oft weitergeleitet werden,
wie es Werte in der Hash-Kette gibt.
-
Wenn
in Schritt 9.10 die Evaluierung zeigt, dass y nicht länger geringer
als n ist, bedeutet dies, dass so viele Versionen der Nachrichtenelemente empfangen
wurden, wie es Elemente der Hash-Kette gibt, die von dem Indexserver
erzeugt wurde, und somit muss der Prozess erneut beginnen. Während in 9 gezeigt
wird, dass der Prozess dann endet, ist es in einer realen Implementierung
wahrscheinlich, dass der gesamte Prozess stattdessen erneut beginnt,
wobei der Empfängercomputer
eine starke Authentisierung der nächsten Version des Nachrichtenelements
durchführt,
die empfangen wurde, und danach eine schwache Authentisierung durchführt.
-
Zusammenfassend
haben wir in dem ersten Ausführungsbeispiel
gezeigt, wie eine schwache Authentisierung unterschiedlicher Nachrichtenelemente (oder
anderer Informationselemente) durchgeführt werden kann, die von einem
ersten Nachrichtenelement referenziert werden, unter Verwendung
von Einwegfunktionen. Insbesondere die schwache Authentisierung
kann von Nachrichtenelement zu Nachrichtenelement in einer Kette
weitergeleitet werden. Zusätzlich
haben wir in dem zweiten Ausführungsbeispiel
auch gezeigt, wie eine schwache Authentisierung zwischen unterschiedlichen
zeitvariablen Versionen derselben Informationselemente durchgeführt werden kann.
In diesem Fall muss eine Hash-Kette im Voraus erzeugt werden und
die Werte aus der Hash-Kette in den nachfolgenden Versionen des
Informationselements in umgekehrter Reihenfolge aufgenommen werden.
Durch Authentisieren der Hash-Werte aus der Hash-Kette können auch
die unterschiedlichen zeitvariablen Versionen der Informationselemente
ebenso schwach authentisiert werden. Die Hauptvorteile der Erfindung
sind, dass sie eine rechnerische Effizienz an empfangenden Vorrichtungen
verbessert sowie einen akzeptablen Grad einer Sicherheit beibehält. Zusätzlich ermöglicht sie,
dass eine Authentisierung von Nachrichten, die von unterschiedlichen
Quellen und auf unterschiedlichen Kanälen empfangen werden, durchgeführt wird.
-
Außer der
Kontext erfordert offensichtlich etwas anderes, sollen in der Beschreibung
und in den Ansprüchen
die Wörter „aufweisen", „aufweisend" und Ähnliches
in einem inklusiven Sinn interpretiert werden, im Gegensatz zu einem
exklusiven oder erschöpfenden
Sinn; das heißt,
in dem Sinn von „einschließend, aber
nicht darauf beschränkt".