DE60312659T2

DE60312659T2 - Leichtgewicht identifizierung von informationen

Info

Publication number: DE60312659T2
Application number: DE60312659T
Authority: DE
Inventors: Andrea Ipswich SOPPERA
Original assignee: British Telecommunications PLC
Current assignee: British Telecommunications PLC
Priority date: 2002-03-04
Filing date: 2003-02-24
Publication date: 2007-12-06
Anticipated expiration: 2023-02-25
Also published as: EP1343286A1; DE60312659D1; EP1481522B1; EP1481522A1; US20050091545A1; WO2003075534A1; CA2478153A1

Description

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;

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;

688

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".

Claims

Informationsauthentisierungsverfahren zur Authentisierung von Elementen von Information (30, 32, 34, 102, 104, 106), 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 jeweils es selbst betreffen, wobei das Verfahren die Schritte aufweist: a) Authentisieren (S.7.4, S.9.3) eines ersten der Informationselemente, das starke Authentisierungsdaten enthält, unter Verwendung der starken Authentisierungsdaten; b) Authentisieren (S.7.12, S.9.9) 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 Authentisieren weiterer Informationselemente 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.
Verfahren gemäß Anspruch 1, wobei die Informationselemente (30, 32, 34) einen Teil eines verbundenen Graphs von Informationselementen bilden, 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 m, wobei m < x, jeweils enthält: Verbindungsinformation, die ein oder mehrere weitere(s) Informationselement(e) in Ebene m + 1 betrifft; und schwache Authentisierungsdaten, die jeweils das oder jedes der verwiesenen Informationselement(e) in der Ebene m + 1 betreffen; wobei der Schritt b) weiter aufweist: d) Authentisieren (S.7.12) des oder jedes zugegriffenen Informationselements in der m + 1sten Ebene unter Verwendung der jeweiligen schwachen Authentisierungsdaten, die in dem Informationselement in der Ebene m enthalten sind, welches das oder jedes zugegriffene Informationselement in der m + 1sten Ebene betrifft; und der Schritt c) weiter aufweist das Setzen von m = m + 1 an dem Beginn jeder Iteration, bis m + 1 = x.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei jedes Stück von schwachen Authentisierungsdaten ein Hash-Wert ist, 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 b) aufweist Berechnen des Hash-Werts (S.7.10) des anderen Informationselements unter Verwendung der Hash-Funktion und Vergleichen des berechneten Hash-Werts (S.7.12) mit dem jeweiligen Hash-Wert, der von den schwachen Authentisierungsdaten dargestellt wird.
Verfahren gemäß Anspruch 3, wobei die Hash-Funktion eine Einweg-Funktion aufweist, die einmal oder mehrere Male angewendet wird.
Verfahren gemäß Anspruch 1, wobei die Informationselemente ein erstes Informationselement und andere Informationselemente aufweisen, wobei die anderen Informationselemente zeitvariante Versionen des ersten Informationselements sind.
Verfahren gemäß Anspruch 1 oder 5, wobei die schwachen Authentisierungsdaten für ein bestimmtes Informationselement ein Hash-Wert sind, der von einer Hash-Funktion erzeugt wird, die als ihr Argument die schwachen Authentisierungsdaten von dem nächsten zeitlichen Informationselement nimmt.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die starken Authentisierungsdaten eine digitale Signatur sind, die unter Verwendung einer Kryptographie mit öffentlichem Schlüssel erzeugt wird.
Verfahren gemäß einem der Ansprüche 1 bis 6, wobei die starken Authentisierungsdaten eine Vielzahl von Signaturwerten aufweisen, die jeweils unter Verwendung einer pseudozufälligen Funktion erzeugt werden, die als ihre Argumente das Informationselement nimmt, welches die Daten betreffen, und jeweils unterschiedliche Schlüssel für jeden Signaturwert.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei die Informationselemente Indexnachrichten sind, die von einem oder mehreren Indexnachrichtenserver(n) übertragen werden.
Computerprogramm, das Anweisungen aufweist, die, wenn sie auf einem Computer ausgeführt werden, den Computer veranlassen, gemäß den Verfahrensschritten einem der Ansprüche 1 bis 9 zu arbeiten.
Computer-lesbares Speichermedium, das ein Computerprogramm gemäß Anspruch 10 speichert.
Elektromagnetisches Signal, das eine Information enthält, die das Computerprogramm gemäß Anspruch 10 repräsentiert.
Vorrichtung (60) zur Authentisierung von Informationselementen (30, 32, 34, 102, 104, 106) gemäß dem Verfahren der Ansprüche 1–9, 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.
Vorrichtung (60) gemäß Anspruch 13, wobei die Informationselemente (30, 32, 34) einen Teil eines verbundenen Graphs von Informationselementen bilden, 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 das schwache Authentisierungsmittel (688) weiter ausgebildet ist, das oder jedes zugegriffene Informationselement in der n + 1sten Ebene zu authentisieren 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 weiter Zählmittel aufweist, die ausgebildet sind, in Verwendung n = n + 1 an dem Beginn jeder Iteration zu setzen, bis n + 1 = x.
Vorrichtung (60) gemäß einem der Ansprüche 13 bis 14, wobei jedes Stück von schwachen Authentisierungsdaten ein Hash-Wert ist, 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 das schwache Authentisierungsmittel (688) weiter aufweist: Berechnungsmittel zum Berechnen des Hash-Werts des anderen Informationselements unter Verwendung der Hash-Funktion; und Vergleichsmittel zum Vergleichen des berechneten Hash-Werts mit dem jeweiligen Hash-Wert, der von den schwachen Authentisierungsdaten dargestellt wird.
Vorrichtung (60) gemäß Anspruch 15, wobei die Hash-Funktion eine Einweg-Funktion aufweist, die einmal oder mehrere Male angewendet wird.
Vorrichtung (60) gemäß Anspruch 13, wobei die Informationselemente ein erstes Informationselement und andere Informationselemente aufweisen, wobei die anderen Informationselemente zeitvariante Versionen des ersten Informationselements sind.
Vorrichtung (60) gemäß Anspruch 13 oder 17, wobei die schwachen Authentisierungsdaten für ein bestimmtes Informationselement ein Hash-Wert sind, der von einer Hash-Funktion erzeugt wird, die als ihr Argument die schwachen Authentisierungsdaten von dem nächsten zeitlichen Informationselement nimmt.
Vorrichtung (60) gemäß einem der Ansprüche 13 bis 18, wobei die starken Authentisierungsdaten eine digitale Signatur sind, die unter Verwendung einer Kryptographie mit öffentlichem Schlüssel erzeugt wird.
Vorrichtung (60) gemäß einem der Ansprüche 13 bis 19, wobei die starken Authentisierungsdaten eine Vielzahl von Signaturwerten aufweisen, die jeweils unter Verwendung einer pseudozufälligen Funktion erzeugt werden, die als ihre Argumente das Informationselement nimmt, welches die Daten betreffen, und jeweils unterschiedliche Schlüssel für jeden Signaturwert.
Vorrichtung (60) gemäß einem der Ansprüche 13 bis 20, wobei die Informationselemente Indexnachrichten sind, die von einem oder mehreren Indexnachrichtenserver(n) übertragen werden.