DE69022424T2

DE69022424T2 - Nichtablehnung in Rechnernetzwerken.

Info

Publication number: DE69022424T2
Application number: DE69022424T
Authority: DE
Inventors: Christopher James Geo Holloway
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1990-11-09
Filing date: 1990-11-09
Publication date: 1996-03-28
Anticipated expiration: 2010-11-10
Also published as: EP0484603B1; CA2054582A1; DE69022424D1; JPH04227154A; US5226079A; EP0484603A1; JPH07123256B2; CA2054582C

Description

Die vorliegende Erfindung betrifft Rechnernetzwerke und insbesondere das Problem der Nichtablehnung von Nachrichten, die mit Hilfe solcher Netzwerke übermittelt werden.
Vertrauliche oder geheime Daten werden oft über elektronische Netzwerke übertragen, die getrennte Datenverarbeitungsgeräte miteinander verbinden. So werden zum Beispiel Daten über Bankgeschäfte zwischen den Zweigstellen einer Bank oft nicht auf Papier, sondern elektronisch über Netzwerke übertragen, die aus elektrischen, optischen, Funk- oder anderen Kommunikationsverbindungen bestehen. Daß diese Netzwerke eine sichere Übertragung der Daten bieten müssen hat man seit langem erkannt. Zu diesem Zweck werden sensitive Daten vor der Übertragung meist verschlüsselt.
Die Verschlüsselung von Daten, die übertragen werden sollen, ist in dem Buch "Security for Computer Networks" (D.W. Davies und W.L. Price, 1984, John Wiley & Sons) genau beschrieben. Es gibt mehrere Methoden oder Algorithmen, nach denen Daten verschlüsselt werden können, meist unter der Kontrolle eines speziellen Schlüssels. Für die vorliegenden Zwecke sollen diese Algorithmen jedoch als zwei Kategorien betrachtet werden, nämlich symmetrische und asymmetrische Algorithmen.
Symmetrische Algorithmen beruhen auf einem geheimen Schlüssel, der nur dem Absender und dem Empfänger der Nachricht bekannt ist. Beide Parteien kennen denselben Schlüssel, und das System bietet einen sicheren bidirektionalen Kommunikationskanal zwischen ihnen. Ein Beispiel für einen symmetrischen Algorithmus ist der Data Encryption Standard (DES), der in dem obengenannten Buch beschrieben wird.
Bei einem asymmetrischen Algorithmus (ebenfalls in diesem Buch beschrieben) haben Absender und Empfänger der Nachricht verschiedene, aber komplementäre Schlüssel. Die Schlüssel sind insofern komplementär, als der eine Schlüssel nur zur Verschlüsselung, der andere nur zur Entschlüsselung verwendet werden kann. Nur einer der beiden Schlüssel muß geheimgehalten werden, und es ist tatsächlich ein wichtiges Kennzeichen eines solchen Algorithmus, daß der andere Schlüssel, der nicht geheim ist, weithin bekannt gemacht werden kann, ohne daß dadurch die Sicherheit gefährdet würde. In einem solchen System mit öffentlichem Schlüssel hat meist der Datenempfänger einen geheimen Schlüssel, der zur Entschlüsselung empfangener Nachrichten dient. Der entsprechende Verschlüsselungsschlüssel wird öffentlich verbreitet und von jeder Partei verwendet, die dem betreffenden Empfänger eine Nachricht senden möchte.
Ein Sicherheitsproblem besteht darin, daß es möglich sein muß, die Authentizität einer Nachricht festzustellen, die zwischen zwei Parteien übermittelt wird. Der Empfänger muß, mit anderen Worten, feststellen können, ob eine bestimmte Nachricht, die angeblich von einem bestimmten Absender empfangen wurde, tatsächlich von diesem Absender stammt und ohne Verstümmelung durch Netzwerkfehler oder böswillige Veränderungen durch Dritte empfangen wurde. Dies ist insbesondere dann notwendig, wenn die Nachricht vor der Entschlüsselung nur wenig Redundanz aufweist. So könnte zum Beispiel eine Nachricht, die aus einer langen Ziffernfolge besteht, bei oberflächlicher Prüfung als Zufallsfolge erscheinen. In diesen Fällen wäre es schwierig, aus dem Text der entschlüsselten Nachricht allein zu schließen, ob die Nachricht verstümmelt wurde.
Zudem dürfte klar sein, daß bei der Entschlüsselung des Textes mit einem öffentlichen Schlüsselsystem ein Mittel benötigt wird, um die Identität des Absenders zu authentifizieren.
Die Authentifizierung einer Nachricht erfolgt oft, indem der Absender ein Authentifizierungs-"Token" an die Nachricht anhängt. Im Fall der DES-Verschlüsselung kann dieses Token als Nachrichten-Authentifizierungscode (MAC, Message Authentication Code) bezeichnet werden (siehe z.B. das Dokument EP-A-0 246 823). Der Absender erzeugt ein Authentifizierungstoken aus dem Text der Nachricht mit Hilfe eines geheimen Schlüssels, den nur Absender und Empfänger kennen. Dann übermittelt der Absender dem Empfänger das Token gemeinsam mit dem Token. Wenn die Nachricht erfolgreich empfangen wurde, erzeugt der Empfänger mit dem geheimen Schlüssel aus dem Text der Nachricht seine eigene Version des Tokens und vergleicht sie mit dem empfangenen Token. Wenn die zwei Versionen des Tokens identisch sind, ist die Authentizität der Nachricht erwiesen.
Die Verwendung von Authentifizierungstokens gibt dem Empfänger Gewißheit über die Authentizität der Identität des Absenders und des Inhalts der Nachricht, und zwar in allen Fällen außer bei einem Streit zwischen dem Absender und dem Empfänger selbst. Aus Gründen, auf die unten noch näher eingegangen wird, kann der Absender eine vom Empfänger empfangene Nachricht mit der Begründung, der Empfänger hätte die Nachricht entschlüsseln und das entsprechende Token selbst erzeugen können, ablehnen, d.h. deren Auslösung leugnen. Da der Empfänger die Möglichkeit hat, eine Nachricht und das entsprechende Token zu fälschen, kann er, mit anderen Worten, nicht beweisen, daß eine empfangene Nachricht mit Token von dem Absender stammt. Dieses Problem zeigt die Notwendigkeit eines Nichtablehnungsverfahrens, das weitere Beweise für die Herkunft einer Nachricht liefern kann. Ein derartiges Verfahren würde das Vertrauen in die Nutzung elektronischer Netzwerke wie zum Beispiel automatischer elektronischer Wertübertragungssysteme steigern.
Insbesondere symmetrische Authentifizierungsalgorithmen weisen die offensichtliche Schwäche auf, daß derselbe Schlüssel sowohl dem Absender als auch dem Empfänger bekannt ist und das Authentifizierungstoken vom Empfänger tatsächlich während des Authentifizierungsvorgangs erzeugt wird.
Im Fall der asymmetrischen Authentifizierungsalgorithmen, bei denen das Authentifizierungstoken meist als die "digitale Unterschrift (DSG, digital signature) bezeichnet wird, wurde argumentiert, daß der Empfänger das Authentifizierungstoken des Absenders zwar überprüfen, aber nicht erzeugen könne, da Absender und Empfänger verschiedene, komplementäre Schlüssel haben. Wenn das Token gültig sei, so das Argument weiter, müsse der Absender für die Nachricht verantwortlich gewesen sein. Um dieses Argument jedoch zur Unterstützung einer Forderung nach Nichtablehnung aufrechtzuerhalten, muß gezeigt werden, daß nur der Absender allein den Schlüsselwert hat, der vom Absender zur Erzeugung des Authentifizierungstokens verwendet wurde.
Asymmetrische Eigenschaften können auch in symmetrischen Verschlüsselungssystemen durch den Einsatz von Hardware- Kontrollen erreicht werden, die verhindern, daß ein Empfänger mit seinem Schlüssel die legitimen Aktionen des Absenders emuliert. Die IBM-Produkte 4753, 4754 und 4755 verfügen über eben diese Eigenschaft. (IBM ist ein eingetragenes Warenzeichen der International Business Machines Corporation.)
Zur Erhöhung des Vertrauens in die Authentizität einer Nachricht wurden schon mehrere andere Ansätze verfolgt. US 4264782 und US 4326098 beschreiben eine Sicherheitsprüfungseinheit, die als "Tresor" bezeichnet wird und als sicherer Aufbewahrungsort für die Verschlüsselungsschlüssel für eine Anzahl angeschlossener Datenterminals dient. Diese Schlüssel werden verwendet, um die Authentizität der zwischen den Terminals ausgetauschten Nachrichten festzustellen.
US 4393269 bezieht sich auf Protokolle, durch die der Empfänger einer Nachricht mit unterschiedlichem Gewißheitsgrad die Integrität einer empfangenen Nachricht feststellen kann.
Alle oben beschriebenen Systeme leiten die Integrität der Identität des Absenders und der Nachricht von der Annahme ab, daß der Schlüssel des Absenders einmalig ist. Bei symmetrischen wie auch asymmetrischen Ansätzen werden die geheimen Schlüssel durch eine Hardware geschützt, die gegen Manipulationen und physische oder elektronische Angriffe gesichert ist. Die Einmaligkeit des Schlüssels hängt somit von der Vertrauenswürdigkeit der Hardware selbst und von den bei der Verwaltung der Hardware verwendeten Sicherheitsmaßnahmen ab. Die angenommene Einmaligkeit des Schlüssels des Absenders kann daher aus folgenden Gründen in Gefahr kommen:
a) Aus reinem Zufall; dies ist zwar unwahrscheinlich, läßt sich aber nicht widerlegen.
b) Durch legitime Absicht. Zur Erfüllung der Backup- oder Kapazitätsanforderungen müssen unter Umständen mehrere identische Hardware-Einheiten vorhanden sein.
c) Durch illegitime Absicht. Wo innerhalb eines Unternehmens der legitimen Absicht durch Arbeitspraktiken im Unternehmen Raum gegeben wird, können solche Praktiken durch Erpressung oder Bedrohung unterlaufen werden.
d) Durch Versehen. Die Stellen, die die Schlüssel verwalten, dürfen unter keinen Umständen mehreren Datenverarbeitungsgeräten dieselben Schlüssel und Identitäten zuweisen oder Geräte initialisieren, deren Hardware sich nicht als sicher erwiesen hat. Beide Ziele können jedoch durch ein Versehen verfehlt werden.
Unabhängig von der Ursache einer Schlüsselverdopplung besteht immer die Möglichkeit, daß es einmal dazu kommt.
Weitere Angriffe auf die Forderung nach Nichtablehnung sind möglich. Wenn sich zum Beispiel ein Hashing-Algorithmus, der Teile der Nachricht miteinander verbindet (wozu keine geheimen Schlüssel erforderlich sind), als schwach erweist, können andere Datennachrichten erfolgreich an echte Authentifizierungstoken angehängt werden. Ein solcher Angriff auf eine häufig verwendete Hashing-Funktion (die Funktion Hash 2 nach ISO-Norm) wurde tatsächlich auch festgestellt. Dadurch wird der Nachweis erschwert, daß die Daten zu ihrem zugehörigen Authentifizierungstoken gehörten, als die Nachricht ausgelöst wurde.
Auf dem Stand der Technik gibt es daher kein überzeugendes Verfahren zur Unterstützung einer Forderung nach der Nichtablehnung einer Nachricht.
Unter einem ersten Gesichtspunkt bietet die vorliegende Erfindung ein Datenverarbeitungsgerät, das an ein Netzwerk mit anderen Datenverarbeitungsgeräten angeschlossen werden kann, welches umfaßt: ein Mittel, das bei Anschluß an das Netzwerk zum Senden einer Nachricht an ein zweites zu dem Netzwerk gehörendes Datenverarbeitungsgerät dient, gekennzeichnet durch: ein Mittel zum kryptographischen Kombinieren von Informationen, die aus der Nachricht abgeleitet sind, Informationen, die aus einer oder mehreren vorangegangenen Nachrichten abgeleitet sind, die zwischen dem ersten Datenverarbeitungsgerät und dem zweiten oder einem weiteren zu dem Netzwerk gehörenden Datenverarbeitungsgerät übertragen wurden, und geheimen Informationen, die sich in dem erstgenannten Datenverarbeitungsgerät befinden, um ein Token zu erzeugen, das mit der Nachricht verbunden werden soll.
Die Erfindung ergänzt die Verwendung eines Authentifizierungstokens, das an eine Nachricht angehängt wird, um einen starken Nachweis für die Herkunft der Nachricht zu erbringen. Obwohl mehrere Hardware-Einheiten gemeinsam dieselben Schlüsselwerte und sogar dieselben logischen Identitäten verwenden können, ermöglicht die Erfindung die Unterscheidung, welche dieser Einheiten für die Erzeugung eines Tokens neuen Typs verantwortlich war, das als "Nichtablehnungsvektor" (NRV, Non-Repudiation Vector) bezeichnet wird.
Die Erfindung bietet das Mittel zur Verbindung jeder Nachricht, die von einer bestimmten Hardware-Einheit gesendet oder empfangen wurde, mit vorangegangenen und nachfolgenden Nachrichten, die von dieser Einheit behandelt wurden. Dadurch entsteht eine Kette kryptographisch verbundener Nachrichten.
In einem Datennetzwerk gemäß der Erfindung wird die Beweislast bei der Ablehnung einer Nachricht auf den Absender der Nachricht übertragen. Zur Ablehnung einer Nachricht muß der Absender nachweisen, wie seine Hardware-Einheit den Zeitraum, in dem die umstrittene Nachricht gesendet wurde, hätte durchlaufen können, ohne den zu der umstrittenen Nachricht gehörenden NRV zu erzeugen. Der umstrittene NRV kann als "Brücke" zwischen der vorausgegangenen und der nachfolgenden Aktivität der Hardware-Einheit des Absenders betrachtet werden, und daher bedeutet die Ablehnung des umstrittenen NRV auch die Ablehnung aller vorausgegangenen und nachfolgenden Transaktionen des Absenders (die zum Zeitpunkt des Streits womöglich schon als legitim akzeptiert wurden). Diese vorangegangenen und nachfolgenden Transaktionen können mit einer Vielzahl anderer unabhängiger Hardware-Einheiten ausgeführt worden sein, die vielleicht zu anderen Unternehmen gehören. Im Fall eines Streits über eine bestimmte Nachricht können diese anderen Unternehmen daher eine unabhängige Bestätigung der Integrität der Nachricht liefern. Bei Bedarf kann die nachfolgende bestätigte Aktivität nach einem Streit durch den Austausch von Nachrichten mit einer unabhängigen Schiedsstelle festgestellt werden. Ebenso kann die vorangegangene bestätigte Aktivität durch den Austausch von Nachrichten mit einer solchen Stelle festgestellt werden, bevor die Hardware-Einheit des Absenders erstmals für geschäftliche Transaktionen eingesetzt wird.
Zur Ablehnung einer beanstandeten Nachricht muß die Hardware- Einheit des Absenders, mit anderen Worten, diese Nachricht an dem Punkt in der Geschichte der Einheit neu verarbeiten, an dem die beanstandete Nachricht angeblich gesendet wurde, und nachweisen, daß der bei der Neuverarbeitung der beanstandeten Nachricht erzeugte NRV nicht dem NRV entspricht, der an die beanstandete Nachricht angehängt war, und auch nicht mit der nachfolgenden Aktivität der Hardware-Einheit des Absenders verbunden ist.
Zudem muß der Absender die richtige Verbindung zwischen der vorangegangenen und der nachfolgenden Aktivität in seiner Hardware-Einheit nachweisen können, notfalls durch Erstellen einer anderen Nachricht, die die Herstellung der Verbindung ermöglicht. Eine solche Nachricht sollte auch durch den Partner bei dieser Nachricht bestätigt werden können.
In jeder Hardware-Einneit eines Absenders sollte möglichst ein Protokoll der Aktivität der Hardware-Einheit geführt werden. Das Protokoll ist ein Speicher für geheime Informationen, die aus dem Token oder der zugehörigen Nachricht oder aus beiden abgeleitet werden, und auch für nicht geheime Informationen, die aus dem Token oder der zugehörigen Nachricht oder aus beiden abgeleitet werden. Dieses Protokoll, das als Nichtablehnungsprotokoll (NRL, Non- Repudiation Log) bezeichnet wird, sollte mit Integrität geführt werden, so daß keine illegitimen Hinzufügungen, Streichungen oder Änderungen unerkannt vorgenommen werden können. Darüber hinaus sollten einige der Informationen in dem Protokoll, die die Aktivitäten im Protokoll zu einer Sequenz verknüpfen, die von den NRVs repräsentiert wird, geheim gehalten werden. Bei dem Mittel zum Protokollieren und zum Wahren der Integrität und Sicherheit der protokollierten Daten (sei es ein physisches oder ein kryptographisches Mittel) kann es sich um diejenigen Mittel handeln, die auf dem Stand der Technik bekannt sind. Als Verbindungsmechanismus wird ein kryptographisches Mittel verwendet.
Die Verbindungen zwischen vorangegangener und nachfolgender Aktivität und die Werte der NRVs selbst werden mit Hilfe von Schlüsseln bestimmt, die in der Hardware-Einheit des Absenders gespeichert sind. Es besteht keine Notwendigkeit, diese Schlüssel gemeinsam mit einer anderen Einheit zu nutzen, doch selbst wenn sie gemeinsam genutzt werden, wird die Eigenschaft der Nichtablehnung nicht gefährdet, da andere Einheiten nicht dieselbe Geschichte der Nachrichtenverarbeitung durchlaufen haben und die Geräte daher, wie gesagt, einmalig sind.
Dem Empfänger einer Nachricht wird möglichst eine Kopie des vom Absender erzeugten NRV zugesendet, und er speichert die von dem empfangenen NRV abgeleiteten Informationen für die Verwendung bei der Klärung eines Streits. Der Einfachheit halber kann der NRV an die zugehörige Nachricht angehängt werden. Es würde im weitesten Sinne der Erfindung allerdings auch ausreichen, die Nachricht und den zugehörigen NRV auf irgendeine Weise in Verbindung zu bringen. In diesem Fall könnte der NRV von der Hardware des Absenders oder an einem anderen Ort gespeichert werden. In einem bevorzugten Ausführungsbeispiel wird der NRV an die Nachricht angehängt und kryptographisch durch ein Authentifizierungstoken wie einem MAC oder einer DSG mit der Nachricht in Verbindung gebracht, bevor er gesendet wird. Absender und Empfänger der Nachricht speichern dann beide die vom NRV abgeleiteten Informationen als Eintrag in einer geordneten Liste, die in einem dedizierten Speicher gespeichert wird (dem Nichtablehnungsprotokoll). Ferner können auch lokal erzeugte Sicherheitsinformationen in Verbindung mit einer bestimmten Nachricht beim Absender und/oder Empfänger gespeichert werden.
Vorzugsweise werden einige oder alle Informationen, die von der vorangegangenen Nachricht bzw. den vorangegangenen Nachrichten abgeleitet werden, tatsächlich aus den Tokens gewonnen, die zu dieser Nachricht bzw. diesen Nachrichten gehören.
Zwar läßt sich die Erfindung auch auf ein Datenverarbeitungsgerät anwenden, das nur als Absender oder nur als Empfänger von Nachrichten verwendet wird, doch vorzugsweise umfaßt ein Datenverarbeitungsgerät gemäß der Erfindung ein Mittel zum Senden und zum Empfangen von Nachrichten, so daß ein einzelnes Gerät sowohl zum Senden als auch zum Empfangen von Nachrichten verwendet werden kann. Dies ist vorzuziehen, weil in einer typischen geschäftlichen Anwendung eines solchen Datenverarbeitungsgeräts die Nachrichten Teil einer Zwei-Wege-Korrespondenz zwischen den Datenverarbeitungsgeräten wären.
Wenn es zu einem Streit über die Ablehnung einer Nachricht kommt, werden der NRV oder die aus dem NRV abgeleiteten Informationen benötigt, um den Streit zu klären. Es ist daher vorzuziehen, daß jeder Eintrag in dem oben erwähnten dedizierten Speicher mit dem Eintrag zu der vorangegangenen Nachricht verbunden ist, die von dem Kombiniermittel behandelt wird. Diese Verbindung könnte mit Adressierzeigern erreicht werden, oder einfacher noch durch das Speichern der Einträge nacheinander in chronologischer Reihenfolge. In der Praxis ist jede Nachricht Teil einer Transaktion zwischen mehreren Datenverarbeitungsgeräten. Ein Datenverarbeitungsgerät kann gleichzeitig an mehreren solchen Transaktionen beteiligt sein. Um die Verfolgung der zu einer bestimmten Transaktion gehörenden Einträge zu erleichtern, werden diese Einträge möglichst ebenfalls verbunden, zum Beispiel mit relativen Adressierzeigern.
Eine weitere Verbindung zwischen jedem Eintrag in dem dedizierten Speicher und dem Eintrag, der zu der letzten von dem Datenverarbeitungsgerät gesendeten Nachricht gehört, sollte möglichst ebenfalls vorhanden sein.
In einem bevorzugten Ausführungsbeispiel enthält der NRV Kontrollinformationen und Informationen, die von der aktuellen Nachricht, der vorangegangenen Nachricht in der aktuellen Transaktion, der letzten von dem Datenverarbeitungsgerät gesendeten Nachricht und der letzten in dem dedizierten Speicher des Absenders aufgezeichneten Nachricht abgeleitet sind. Dieinformationen, die von anderen Nachrichten als der ersten abgeleitet sind, können natürlich unter Bezugnahme auf den NRV oder andere gespeicherte, zu diesen Nachrichten gehörende Informationen gewonnen werden. Es sollte, wie bereits erwähnt, möglichst ein kryptographisches Authentifizierungstoken (ein MAC, eine DSG oder ein anderes im Fach bekanntes Token) verwendet werden, um die aktuelle Nachricht mit ihrem NRV zu verbinden. Dieses Token kann als Teil des NRV an den Nachrichtenempfänger gesendet werden. In einem bevorzugten Ausführungsbeispiel enthält der Empfänger ein Mittel zur Überprüfung der Integrität des Authentifizierungstokens.
Unter einem zweiten Gesichtspunkt bietet die vorliegende Erfindung auch ein Datennetzwerk, bestehend aus mehreren Datenverarbeitungsgeräten gemäß der obigen Beschreibung und einem Mittel, das die Datenverarbeitungsgeräte zur Übertragung von Nachrichten zwischen ihnen miteinander verbindet.
Um das umfassende Verständnis der Erfindung zu erleichtern, wird nachstehend nur als Beispiel ein bevorzugtes Ausführungsbeispiel unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, wobei gilt:
Figur 1 ist eine schematische Darstellung eines Datenkommunikationsnetzwerks, wie es auf dem Stand der Technik bekannt ist.
Figur 2 zeigt den Betrieb von zwei Datenverarbeitungsgeräten, die Informationen über ein Netzwerk austauschen, wie es auf dem Stand der Technik bekannt ist.
Figur 3 zeigt zwei Datenverarbeitungsgeräte, die gemäß der Erfindung Informationen austauschen.
Figur 4 zeigt den Nichtablehnungsvektor (NRV, Non-Repudiation Vector), der in einem bevorzugten Ausführungsbeispiel der Erfindung verwendet wird.
Figur 5 zeigt, wie der NRV kryptographisch mit der zugehörigen Nachricht verbunden werden kann.
Figur 6 zeigt den Algorithmus zur Erzeugung von Teilen des NRV.
Figur 7a bis 7e zeigt die Beziehung zwischen dem Inhalt der zu Nachrichten gehörenden NRVs und dem Inhalt der zu den NRVs gehörenden NRL-Einträge bei verschiedenen Verbindungsstufen, die mit der Erfindung erreichbar sind.
Figur 8 zeigt die Beziehung zwischen dem Inhalt der zu Nachrichten gehörenden NRVs und den zugehörigen NRL-Einträgen zweier voneinander unabhängiger und ineinander verzahnter Transaktionen.
Figur 9 faßt die Verbindungen und Abhängigkeiten zwischen einer aktuellen Nachricht, ihrem NRV, den aktuellen und vorangegangenen NRL-Einträgen sowie den bei diesem NRL erzeugten vorangegangenen und nachfolgenden NRVs zusammen.
Figur 10 ist ein Flußdiagramm, das die Vorgehensweise zur Klärung eines Ablehnungsstreits über eine bestimmte Nachricht veranschaulicht.
Zunächst soll Figur 1 betrachtet werden, die ein schematisches Datennetzwerk zeigt, das drei Datenverarbeitungsgeräte 10, 20 und 30 zeigt, bei denen es sich zum Beispiel um Mikrocomputer, Mainframe-Computer, Scannerkassen oder Geldautomaten handeln kann. Die Datenverarbeitungsgeräte 10, 20 und 30 können sich in verschiedenen Gebäuden, Städten oder sogar Ländern befinden. Die Datenverbindungen 40, 50 und 60, die in dem Netzwerk verwendet werden, können elektrische, Funk-, Glasfaser- oder andere Übertragungsmedien oder tragbare Speichermedien umfassen. Außer im Fall von Netzwerken innerhalb einzelner Gebäude werden die Verbindungen meist von einem Telekommunikationsunternehmen betrieben und an den Nutzer der Verbindung vermietet oder verpachtet. Wenn sensitive kommerzielle oder finanzielle Informationen zwischen den Datenverarbeitungsgeräten ausgetauscht werden, wird meist mit einer Verschlüsselung gearbeitet, um die Vertraulichkeit der Informationen zu wahren.
Figur 2 zeigt den Betrieb von zwei Datenverarbeitungsgeräten 100 und 200, die für den Austausch verschlüsselter Daten über die Datenverbindung 160 vorgesehen sind. In dem Datenverarbeitungsgerät 100 wird von der Einheit 110, bei der es sich um ein Speichergerät oder einen anderen Teil des Datenverarbeitungsgeräts handeln kann, eine Nachricht ausgelöst. Die Einheit 120 verschlüsselt die Nachricht unter der Kontrolle des Schlüssels 130, und die Einheit 140 erzeugt unter der Kontrolle des Schlüssels 150 ein zu der Nachricht gehörendes Authentifizierungstoken. Die verschlüsselte Nachricht und das Authentifizierungstoken werden dann über die Verbindung 160 zu dem Datenverarbeitungsgerät 200 übertragen.
Wenn die verschlüsselte Nachricht und das Token von dem Datenverarbeitungsgerät 200 empfangen werden, wird die Nachricht von der Einheit 210 unter der Kontrolle des Schlüssels 220 entschlüsselt. Die Einheit 230 überprüft dann die Integrität des Authentifizierungstokens unter der Kontrolle des Schlüssels 240. Zum Schluß wird die Nachricht in der Einheit 250 zur weiteren Verarbeitung gespeichert, die von dem Datenverarbeitungsgerät 200 verlangt werden kann.
Es dürfte klar sein, daß alle in Zusammenhang mit Figur 2 beschriebenen Vorrichtungen im Fachgebiet der Datenübertragung bekannt sind. Es können symmetrische oder asymmetrische Verschlüsselungs- und Authentifizierungsalgorithmen verwendet werden. Wenn symmetrische Algorithmen verwendet werden, ist der Schlüssel 130 identisch mit dem Schlüssel 240 und der Schlüssel 150 identisch mit dem Schlüssel 220. Wenn asymmetrische Algorithmen verwendet werden, korrespondieren diese Schlüssel paarweise, sind aber nicht im Wert identisch.
Figur 3 zeigt ein System gemäß der Erfindung zum Austausch von Nachrichten zwischen den Datenverarbeitungsgeräten 300 und 400 über die Verbindung 160. In der Figur ist das Datenverarbeitungsgerät 300 der Absender und das Datenverarbeitungsgerät 400 der Empfänger. Allerdings dürfte klar sein, daß in der Praxis meist ein einzelnes Datenverarbeitungsgerät selektiv als Absender und als Empfänger fungiert.
Das Datenverarbeitungsgerät 300 enthält eine Nachrichtenauslösungseinheit 110 und eine Verschlüsselungseinheit 140 unter der Kontrolle des Verschlüsselungsschlüssels 150, wie oben in Verbindung mit Figur 2 beschrieben. Das Datenverarbeitungsgerät 400 enthält eine entsprechende Nachrichtenspeichereinheit 250 und eine Entschlüsselungseinheit 210 unter der Kontrolle des Schlüssels 220.
Nachdem die Nachricht von dem Datenverarbeitungsgerät 300 mit Hilfe der Einheit 110 ausgelöst wurde, wird sie an die Einheit 310, den Erzeuger des Nichtablehnungsvektors (NRV) weitergeleitet. Der NRV selbst wird unten noch eingehend beschrieben. Diese Einheit 310 steht unter der Kontrolle zweier weiterer Schlüssel 320 und 330 und empfängt als Eingabe Informationen, die in dem Nichtablehnungsprotokoll (NRL) 340 gespeichert sind und von einer oder mehreren vorangegangenen Nachrichten abgeleitet sind, die von dem Datenverarbeitungsgerät 300 gesendet oder empfangen und der Einheit 310 präsentiert wurden. (Nicht alle Nachrichten, die von dem Datenverarbeitungsgerät gesendet oder empfangen werden, müssen der Einheit 310 präsentiert werden. Es ist möglich, daß nur diejenigen Nachrichten an die Einheit 310 weitergeleitet werden, die mit anderen Datenverarbeitungsgeräten ausgetauscht wurden, die einen Nichtablehnungsmechanismus betreiben.) Die in dem Nichtablehnungsprotokoll gespeicherten Informationen werden mit Integrität gespeichert, und einige Teile der Informationen werden mit Geheimhaltung gespeichert. Der Mechanismus, der die entsprechende Integrität und Geheimhaltung der Informationen gewährleistet, ist hier nicht dargestellt, könnte aber physische und kryptographische Mittel umfassen, wie sie auf dem Stand der Technik verwendet werden.
Die Einheit 310 erzeugt den NRV aus der aktuellen Nachricht und den vorangegangenen Informationen unter der Kontrolle des Schlüssels 320, und sie erzeugt, wiederum unter der Kontrolle des Schlüssels 320, auch einen zugehörigen NRL-Eintrag. Dieser NRL-Eintrag wird in dem NRL 340 gespeichert. Der NRV- Erzeuger 310 erzeugt mit dem Schlüssel 330 auch ein Authentifizierungstoken (MAC oder DSG), das den gesendeten NRV kryptographisch mit der gesendeten Nachricht verbindet. Dieses Token kann von dem Empfänger 400 mit Hilfe der NRV- Überprüfungseinheit 430 unter der Kontrolle des Schlüssels 420 auf die übliche Weise überprüft werden.
Die zusammengesetzte Nachricht mit dem NRV wird an die Einheit 140 weitergeleitet, wo sie mit Hilfe des Schlüssels 150 entschlüsselt wird. Die verschlüsselte zusammengesetzte Nachricht wird über die Verbindung 160 an das Datenverarbeitungsgerät 400 übermittelt. Soweit die Verbindung betroffen ist, ist der NRV nicht vom Rest der zu übermittelnden Daten zu unterscheiden.
Wenn die Nachricht von dem Datenverarbeitungsgerät 400 empfangen wird, wird sie an die Entschlüsselungseinheit 210 weitergeleitet, wo sie mit Hilfe des Schlüssels 220 entschlüsselt wird. Das Authentifizierungstoken wird von der NRV-Überprüfungseinheit 430 unter der Kontrolle des Überprüfungsschlüssels 420 auf Authentizität überprüft. Nach dieser Überprüfung entfernt die Einheit 430 den NRV von der Nachricht und erzeugt mit Hilfe des Schlüssels 410 einen NRL- Eintrag aus der Nachricht, den NRV und einen oder mehrere vorangegangene Einträge aus dem NRL. Die Einheit 430 setzt dann den erzeugten NRL-Eintrag in das NRL und leitet die Nachricht zur Speicherung im Nachrichtenspeicher 250 an das Datenverarbeitungsgerät 400 weiter. Dasselbe NRL kann zur Speicherung von Einträgen verwendet werden, die zu Nachrichten gehören, die von einem Datenverarbeitungsgerät gesendet und empfangen wurden.
Auch hier können symmetrische und asymmetrische Algorithmen verwendet werden. Wenn symmetrische Algorithmen verwendet werden, ist der Schlüssel 330 identisch mit dem Schlüssel 420 und der Schlüssel 150 identisch mit dem Schlüssel 220. Wenn asymmetrische Algorithmen verwendet werden, korrespondieren diese Schlüssel paarweise, sind aber nicht im Wert identisch. In beiden Fällen sind die Schlüssel 320 und 410 voneinander unabhängig.
In der Praxis können viele Datenverarbeitungsgeräte miteinander kommunizieren, und verschiedene Werte der Schlüssel 150, 220, 330 und 420 können selektiv verwendet werden, wie es den Beteiligten an der jeweiligen Übertragung auskommt. Allerdings sind die Schlüssel 320 und 410 für das Datenverarbeitungsgerat spezifisch, dem sie gehören; sie können als solche unveränderlich sein und müssen sich nicht auf die Parteien beziehen, die an der jeweiligen Übertragung beteiligt sind.
Figur 4 stellt die Informationen dar, die in dem zu den einzelnen Nachrichten gehörenden Nichtablehnungsvektor (NRV) enthalten sind. Der NRV ist eine Datenstruktur, die mit allen beteiligten Nachrichten verbunden ist. Er enthält Informationen, die den Urheber einer Nachricht bezeichnen, ein Token 520, das eine Nachricht mit vorangegangenen und nachfolgenden Nachrichten verbindet, die sich auf dieselbe Transaktion oder auf dasselbe zugehörige Datenverarbeitungsgerät beziehen können, aber nicht müssen, sowie einen Authentifizierer 530, der den NRV kryptographisch mit seiner zugehörigen Nachricht verbindet.
In einem bevorzugten Ausführungsbeispiel enthält der NRV 500 folgende Komponenten:

Der Ursprungskontrollvektor 510 (OCV, origin Control Vector)

Der Ursprungskontrollvektor enthält die Bezeichnung der Urheber der Nachricht und des zu der Nachricht gehörenden NRV, die Identität des NRL des Absenders sowie Synchronisierungsdaten. Folgende Untermerkmale sind in dem OCV enthalten:
a) Ursprungsprotokollidentität - Dies ist die Identität der Nichtablehnungsvektor-Erzeugungseinheit 310, die zur Erzeugung dieses NRV verwendet wurde.
b) Ursprungs-NRL-Sequenz - Dies ist die Identität des zu diesem NRV gehörenden Eintrags im NRL 340 des Urhebers.
c) Ursprungsbenutzeridentität - Hiermit wird der Benutzer des Datenverarbeitungsgeräts 300 bezeichnet, der dafür verantwortlich war, daß die Originalnachricht dem NRV- Erzeuger 310 präsentiert wurde.
d) Ursprungsauthentifizierungsschlüsselidentifikator - Hiermit wird der Schlüssel 330 bezeichnet, der zur Erzeugung des Authentifizierungstokens verwendet wurde, das die Nachricht mit dem NRV verbindet.
e) Ursprungs zeit - Dies ist die Uhrzeit und das Datum, wie sie dem absendenden NRV-Erzeuger 310 bekannt sind.
f) Ursprungszeitinversionsindikator - Er zeigt an, ob der Eintrag im NRL des Urhebers, der zu der in der gegenwärtigen Transaktion zuletzt beim Urheber eingegangenen Nachricht gehört, eine Ursprungszeit angegeben hatte, die nach der Ursprungszeit dieses NRV lag.
g) Transaktionskontrolle - Dies gibt an, ob dieser NRV für eine Nachricht erzeugt worden war, die angeblich die erste, mittlere oder letzte Nachricht einer verbundenen Transaktion war.
h) Neuerzeugungskontrolle - Beim Testen einer beanspruchten Ablehnung (wird später beschrieben) wird es wichtig zu verlangen, daß die Nichtablehnungstokens einer oder mehrerer Nachrichten anhand der Informationen, die zum Zeitpunkt der ursprünglichen Erzeugung verfügbar gewesen wären, neu erzeugt werden. Dabei entstehen auch zusätzliche Einträge im NRL. Zur Unterscheidung von Nachrichten, die zu den neu erzeugten NRVs gehören, von authentischen Nachrichten, gibt dieses Flag an, ob der NRV original oder neu erzeugt ist.

Das Nichtablehnungstoken 520 (NRT, Non-Repudiation Token)

Das NRT enthält die Informationen, die extern geprüft und getestet werden können, um nachzuweisen, ob der behauptete NRV-Erzeuger 310 an der Erzeugung des NRV beteiligt war. Es kann sich um eine zusammengesetzte Datenstruktur handeln, die folgende Untermerkmale umfaßt:
a) Das erzeugte Nichtablehnungstoken (GNRT, Generated Non- Repudiation Token) - Dies ist der veröffentlichte Wert, der von dem zu dem Datenverarbeitungsgerät 300 des Urhebers gehörenden NRV-Erzeuger 310 erzeugt wurde. In dem vorliegenden Ausführungsbeispiel umfaßt das GNRT 8 Byte binäre Daten.
b) Das verbundene Nichtablehnungstoken (LNRT, Linked Non- Repudiation Token) - Dies ist potentiell ein Token mit freiem Format und variabler Länge, dessen Zweck darin besteht, eine extern überprüfbare Zugehörigkeit dieses NRV zu einem oder mehreren anderen NRVs herzustellen, die zuvor zwischen denselben beiden Datenverarbeitungsgeräten 300 und 400 ausgetauscht wurden. In dem bevorzugten Ausführungsbeispiel handelt es sich um ein einziges Datenelement mit 8 Byte binären Daten und entspricht dem GNRT von dem NRV, der zu der vorangegangenen Nachricht gehört, die in derselben Transaktion gesendet oder empfangen wurde. In der Praxis kann diese Verbindung von erheblichem Wert sein, doch aufgrund der Konvention kann es notwendig sein, weitere oder weniger Verbindungen herzustellen.

Der Nachrichtenauthentifizierer 530

Dies ist ein MAC oder eine DSG, die kryptographisch die Nachricht mit dem angehängten NRV verbinden. Sie decken sowohl die Nachricht als auch alle oben beschriebenen Komponenten des NRV ab.
Zusammenfassend ist jeder NRV in dem vorliegenden Ausführungsbeispiel mit Hilfe seines Nichtablehnungstokens (NRT) mit drei Dingen verbunden:
a) mit der Nachricht, zu der der NRV gehört;
b) mit der vorangegangenen Nachricht in der aktuellen Transaktion und
c) mit der Sequenz der im Protokoll gespeicherten Einträge.
Figur 5 veranschaulicht die kryptographische Verbindung der Nachricht mit dem NRV durch Vermittlung eines Authentifizierungstokens. Es ist auf dem Stand der Technik (Figur 5 (a)) bekannt, wie eine Nachricht 540 kryptographisch "versiegelt" wird, um die Erkennung aller unerlaubten Veränderungen zu ermöglichen, indem aus den Nachrichtendaten und einem geheimen Schlüssel 130 ein Authentifizierungstoken 545 (ein MAC oder eine DSG, wie oben beschrieben) errechnet wird. Mit Hilfe desselben Verfahrens kann in dem vorliegenden Ausführungsbeispiel (Figur 5 (b)) die Nachricht 550 mit den Komponenten des NRV 510, 520 verbunden werden, indem aus den kombinierten Daten und einem geheimen Schlüssel 330 das Authentifizierungstoken 580 errechnet wird. So wird jeder Versuch, die Nachricht oder den Inhalt des NRV zu verändern, bei der Überprüfung des Authentifizierungstokens erkannt.
Figur 6 zeigt das Verfahren zur Erzeugung von Nichtablehnungstokens, die in den NRV aufgenommen und vertraulich im NRL gespeichert werden sollen. Unter Bezugnahme auf die Figur handelt es sich bei den Eingaben für dieses Verfahren um:
a) die Nachrichtendaten 600, mit denen der NRV verbunden werden soll; und
b) die Verbindungsdaten 610, mit denen dieser NRV kryptographisch verbunden werden soll.
Das Verfahren zur Erzeugung des Nichtablehnungstokens (NRT) steht unter der Kontrolle eines privaten Verschlüsselungsschlüssels 630 (der nicht für diese NRV- Erzeugungseinheit einmalig sein muß) und nutzt das im Fach bekannte Verfahren zur Erzeugung des Nachrichten- Authentifizierungscodes (MAC). Das Verfahren erzeugt zwei Nichtablehnungstokens, die als erzeugtes Nichtablehnungstoken (GNRT, Generated Non-Repudiation Token) 680 und als Protokollverbindungs-Nichtablehnungstoken (LGLNRT, Log- Linkage Non-Repudiation Token) 670 bezeichnet werden. Das GNRT ist in den zu der Nachricht gehörenden NRV integriert, doch das LGLNRT wird geheimgehalten und in dem Nichtablehnungsprotokoll NRL gespeichert.
Das GNRT und das LGLNRT bestehen jeweils aus zwei Abschnitten, einem rechten und einem linken. In beiden Fällen werden diese Abschnitte aus Abschnitten von zwei MACS gewonnen, die aus der Nachricht bzw. aus den Verbindungsdaten erzeugt werden. So sind GNRT und LGLNRT jeweils abhängig von den Nachrichten- und den Verbindungsdaten.
Das Erzeugungsverfahren besteht aus zwei Hauptschritten, die gleichzeitig ausgeführt werden. In der ersten Stufe erzeugt ein MAC-Erzeuger 620 mit dem privaten Schlüssel 630 aus der Nachricht einen ersten MAC, MAC1 (650). MACL 650 ist 8 Byte lang und in zwei Teile untergliedert, nämlich MAC1L (652), den vier linken Bytes, und MAC1R (651), den vier rechten Bytes. MAC1 650 stellt eine kryptographische Verbindung zwischen der Nachricht und dem NRV dar.
Außerdem wird von dem Erzeuger 620 mit dem Schlüssel 630 ein zweiter MAC, MAC2 (660), erzeugt. Dieser MAC2 660 wird aus einem zusammengesetzten Wort 610 erzeugt, bestehend aus dem LGLNRT 611, dem GNRT 612 und dem LNRT 613 aus dem vorangegangenen NRV, die in dieser NRV-Erzeugereinheit erzeugt und in diesem NRL gespeichert wurden, sowie dem GNRT 614 und dem LNRT 615 aus der vorangegangenen Nachricht, die in der gegenwärtigen Transaktion gesendet oder empfangen wurden, und zwar in dieser Reihenfolge miteinander verkettet. Auch MAC2 (660) besteht aus zwei Teilen mit je vier Bytes, nämlich MAC2L 662, den vier linken Bytes, und MAC2R 661, den vier rechten Bytes. Der Zweck des MAC2 besteht darin, eine kryptographische Verbindung zwischen der gegenwärtigen Nachricht, der vorangegangenen Nachricht in der Transaktion und der vorangegangenen Nachricht, die von dem Absender stammt, herzustellen.
Das neue GNRT 680 wird dann erzeugt, indem MAC1L (652) und MAC2L (662) zu einem Acht-Byte-Feld verkettet werden. Ebenso ist das neue LGLNRT 670 die Verkettung von MAC2R (661) und MAC1R (651).
Da das MAC-Verfahren mit Eingaben von variabler Länge arbeitet, können die Nachricht und die Verbindungsdaten von variabler Länge sein. Insbesondere ermöglicht dies Flexibilität, wenn durch Konvention definiert wird, wie viele Verbindungen welchen Typs in den Verbindungsdaten für eine praktische Umsetzung benötigt werden. Damit der Nichtablehnungsmechanismus gültig ist, muß mindestens ein geheimes Verbindungstoken (in diesen Fall das LGLNRT 611 des vorangegangenen Eintrags im NRL des Urhebers) vorhanden sein. In dem vorliegenden Ausführungsbeispiel werden weitere Verbindungsinformationen (612, 613, 614 und 615) verwendet; andere Verbindungsmechanismen könnten ebenfalls eingesetzt werden, doch bei jedem Mechanismus müssen zugehörige Daten und Zeiger im NRL bereitgestellt werden, damit auf die Verbindungsinformationen zugegriffen werden kann.
Das bevorzugte Ausführungsbeispiel soll das Erzeugungsverfahren nicht über die oben genannte Erfordernis eines geheimen Verbindungstokens wie etwa Token 611 hinaus einschränken. Insbesondere der private MAC-Schlüssel 630 könnte durch eine Vielzahl von Schlüssein zur Erzeugung einer Vielzahl von zugehörigen Authentifizierungstokens (MACs, DSGs oder anderen Tokens) ersetzt werden, von denen auf irgendeine Weise Daten zur Erstellung der Nichtablehnungstokens bezogen werden.
Aus der obigen Ableitung dürfte zu erkennen sein, daß das LGLNRT von der aktuellen Nachricht und von dem LGLNRT aus dem vorangegangenen Eintrag im NRL abhängig ist. Vom Aufbau her ist es daher von allen vorangegangenen Nachrichten abhängig, die von dem betreffenden NRL behandelt wurden.
Die Figur 7(a) zeigt eine grundlegende Umsetzung des NRV und des zugehörigen NRL-Eintrags; die Figuren 7(b) bis 7(e) zeigen dann Verbesserungen dieser grundlegenden Form. In dem bevorzugten Ausführungsbeispiel wird die letzte Stufe der Verbesserung verwendet, die in Figur 7(e) dargestellt ist.
In Figur 7(a) ist der mit einer bestimmten Nachricht verbundene NRV 710 mit dem zu dieser Nachricht gehörenden NRL-Eintrag 720 dargestellt. In dieser grundlegenden Umsetzung sind drei Teile des NRV dargestellt: die Protokollierte Sequenznummer (LSEQ, Logged Sequence Number) 711, das oben beschriebene GNRT 712 und ein Authentifizierungs-MAC, der die anderen Komponenten 711 und 712 des NRV mit der Nachricht verbindet. LSEQ 711 ist ein Bestandteil des oben beschriebenen OCV und wird der Sequenznummer 721 des zu der Nachricht gehörenden NRL- Eintrags 720 gleichgesetzt. Dies bedeutet, daß das NRL zu einem späteren Zeitpunkt zu Überprüfungszwecken lokalisiert werden kann. Das erzeugte Nichtablehnungstoken GNRT wird sowohl im NRV als 712 als auch im NRL als 723 aufgezeichnet. Zusätzlich umfaßt der NRL-Eintrag ein Protokollverbindungs- Nichtablehnungstoken LGLNRT 722, das gemäß der oben im Zusammenhang mit Figur 6 beschriebenen Methode erzeugt wurde. Das LGLNRT wird geheimgehalten und bietet die Grundlage für die Verbindung einer langen Reihe von NRL-Einträgen miteinander.
Die in dem NRV und dem NRL in Figur 7(a) enthaltenen Informationen bilden die Grundbausteine des Nichtablehnungsmechanismus in diesem Ausführungsbeispiel. In dem NRL werden zur Unterstützung dieser Grundverbindung keine Zeiger benötigt, da die Verbindung immer zu dem vorangegangenen NRL-Eintrag besteht.
Verbesserungen an dem grundlegenden Nichtablehnungsmechanismus werden im folgenden unter Bezugnahme auf die Figuren 7(b) bis 7(e) beschrieben.
In Figur 7(b) kann das NRL zusätzlich Einträge für empfangene Nachrichten aufzeichnen. In dieser Figur ist der NRV 730 für eine empfangene Nachricht dargestellt, gemeinsam mit dem NRL- Eintrag 740 des Empfängers. In diesem Fall bezieht sich die protokollierte Sequenznummer im OCV auf das NRL des Urhebers (nicht dargestellt) und wird deshalb als RSEQ (Received Sequence Number, empfangene Sequenznummer) bezeichnet. Diese RSEQ wird im NRL 740 des Empfängers gespeichert 741, zusätzlich zu der Sequenznummer LSEQ des Eintrags im NRL 740. Außerdem wurde vom Standpunkt des Empfänger-NRL 740 das Token GNRT im NRV abgesetzt vom Urheber erzeugt und wird daher als RNRT (Received Non-Repudiation Token, empfangenes Nichtablehnungstoken) 731 bezeichnet. Das RNRT wird im NPL 740 gespeichert 742.
Betont werden muß, daß der einzige Unterschied zwischen dem GNRT und dem RNRT in der Perspektive liegt; in einem bestimmten NRL wird das erzeugte Nichtablehnungstoken als GNRT bezeichnet, wenn es in diesem NRL in Verbindung mit einer gesendeten Nachricht erzeugt wurde, und als RNRT, wenn es in diesem NRL in Verbindung mit einer empfangenen Nachricht empfangen wurde. Dementsprechend zeichnet das Datenfeld 723 in Figur 7(a) jetzt selektiv das GNRT oder das RNRT auf, je nachdem ob der Eintrag zu einer gesendeten oder einer empfangenen Nachricht gehört.
Nachdem nun gesendete und empfangene OCVs aufgezeichnet sind, können die Nachrichten, die zu einer einzelnen Transaktion gehören, miteinander verbunden werden, wie in Figur 7(c) gezeigt. In dieser Figur veranschaulichen die zwei NRVs 750 und die zugehörigen NRL-Einträge 760 einen möglichen Mechanismus für diese Transaktionsverbindung.
Die NRVs 750 wurden verbessert und weisen einen Transaktionskontrollindikator 751 auf, eine Komponente des OCV. Dieser Indikator zeigt an, ob sich der NRV auf die erste, eine mittlere oder die letzte Nachricht einer Transaktion bezieht. Außerdem wurde ein weiteres Datenfeld 753 zu dem NRV hinzugefügt, das ein verbundenes Nichtablehnungstoken LNRT liefert, das mit dem GNRT oder dem RNRT aus der vorangegangenen Nachricht in der Transaktion gleichgesetzt wird. Das Datenfeld 752 wird für das GNRT bzw. RNRT verwendet, das sich auf die aktuelle Nachricht bezieht. Die NRL-Einträge 760 werden entsprechend verbessert, so daß sie ein Datenfeld 761 bieten, in dem das LNRT aus den einzelnen - gesendeten oder empfangenen - Nachrichten aufgezeichnet wird. Ebenso wird ein Rückwärtszeiger 762 bereitgestellt, der die Sequenznummer des zu der vorangegangenen Nachricht in der Transaktion gehörenden Eintrags in diesem NRL angibt. Das GNRT bzw. RNRT 763 dieser vorangegangenen Nachricht muß dem LNRT 761 der aktuellen Nachricht entsprechen; dies kann beim Empfang einer bestimmten Nachricht überprüft werden.
Da das NRL Einträge für empfangene wie auch für erzeugte NRVs enthält, besteht eine dritte Verbesserung darin, diese zu lokal erzeugten NRVs gehörenden NRL-Einträge miteinander zu verbinden. Ein Verfahren hierzu ist in Figur 7(d) dargestellt; für die Zwecke dieser Erläuterung ist es jedoch nicht nötig, die zugehörigen NRVs zu zeigen. Die NRL-Einträge 770 zeigen einen weiteren Zeiger, der die NRL-Einträge 773, 774 und 775 rückwärts mit dem letzten erzeugten Eintrag 772 verbindet.
Zwei letzte Verbesserungen sind in dem in Figur 7(e) dargestellten NRL 780 veranschaulicht. Auch hier sind die zugehörigen NRVs nicht dargestellt, da sie für diese Erläuterung nicht benötigt werden. Die in Figur 7(e) dargestellten zusätzlichen Merkmale sollen die Integrität des NRL selbst verbessern.
Das erste der zusätzlichen Merkmale in der Figur besteht in der Sicherung der NRL-Daten. Ein Verfahren besteht in der Verwendung einer physischen Sicherung, im Grunde in einer verschlossenen Barriere zur Verhinderung unbefugter Zugriffe auf die NRL-Einträge. Statt dessen können aber auch kryptographische Verfahren eingesetzt werden. In Figur 7(e) wird das geheime Feld LGLNRT im NRL zu der verschlüsselten Form ELGLNRT 781 (Enciphered LGLNRT) verschlüsselt. Außerdem wurde für jeden NRL-Eintrag ein MAC 782 erzeugt, um unerkannte Veränderungen oder Verstümmelungen zu verhindern. Die zur Anwendung dieser Verfahren verwendeten Schlüssel müssen für den Mechanismus zur Erzeugung der Nichtablehnungstoken, der die NRL-Einträge erstellt, geheim sein.
Das zweite dargestellte Merkmal besteht in der Einführung einer Schiedsstelle zur Beilegung von Streitigkeiten bei Versuchen, eine Nachricht abzulehnen. Mit einer unabhängigen Schiedsstelle, die das Vertrauen der kommunizierenden Parteien genießt, werden Nachrichten ausgetauscht, damit sie einen ersten Eintrag 783 im NRL und nach einem Streit auch einen nachfolgenden NRL-Eintrag 784 liefert. In der Praxis würden solche Nachrichten während des Betriebs des Systems in regelmäßigen Abständen mit der Schiedsstelle ausgetauscht. Wenn es zum Streit kommt, können dann die Verbindungen zwischen NRL-Einträgen zu abgesicherten Einträgen vor- und zurückverfolgt werden, die von der Schiedsstelle überprüft werden können. Dadurch können Streitigkeiten auch geschlichtet werden, wenn es keinen vorangegangenen oder nachfolgenden Geschäftseintrag im NRL gibt.
Figur 8 zeigt eine Sequenz von acht Einträgen in einem Nichtablehnungsprotokoll (NRL, Non-Repudiation Log) 800, die zu den Nachrichten 880 aus zwei ineinander verzahnten Transaktionen gehören. Die NRVs der Nachrichten und die zugehörigen NRL-Eintrage sind mit 861, 862, ... 868 bezeichnet.
Das NRL 800 kann als weitere Verbesserung betrachtet werden, zusätzlich zu den im Zusammenhang mit Figur 7 beschriebenen. Es enthält zu jedem Eintrag die folgenden Datenelemente, von denen einige der Übersichtlichkeit halber in dem Diagramm fortgelassen sind. Viele dieser Elemente wurden oben bereits beschrieben, sind aber hier im Rahmen einer Zusammenfassung erneut aufgeführt:

Der Protokollkontrollvektor (LCV, Log Control Vector) 810

Der LCV ist analog zu dem OCV des NRV und enthält ebenfalls eine Reihe von Unterfeldern:
a) Die Protokollsequenznummer (LSEQ, Log Sequence Number) 811 bezeichnet diesen Eintrag im NRL.
b) Die Erstellungsmethode (nicht dargestellt) beschreibt die zur Erzeugung der Werte LGLNRT und GNRT verwendete Berechnungs- und Verbindungskonvention. Sie wird aufgezeichnet, damit diese Werte bei der Schlichtung eines Streits zu Überprüfungszwecken mit derselben Konvention neu erzeugt werden können, die bei der ursprünglichen Erstellung verwendet wurde.
c) Der Ursprungskontrollvektor (OCV, Origin Control Vector) wird als genaue Kopie des OCV gespeichert, der in dem zu diesem NRL-Eintrag gehörenden NRV gesendet oder empfangen wurde.

Das protokollverbundene Nichtablehnungstoken (LGLNRT, Log- Linked Non-Repudiation Token) 820

Dies ist der geheime (und potentiell verschlüsselte) Wert, mit dem dieser NRL-Eintrag mit vorangegangenen und nachfolgenden NRL-Einträgen verbunden wird.

Das Nichtablehnungstoken NRT (Non-Repudiation Token) 830

Das NRT enthält die Informationen, die extern geprüft und getestet werden können, um nachzuweisen, ob der behauptete NRV-Erzeuger 310 an der Erzeugung des NRV beteiligt war. Es kann sich um eine zusammengesetzte Datenstruktur handeln, die folgende Untermerkmale umfaßt:
a) Das erzeugte Nichtablehnungstoken (GNRT, Generated Non- Repudiation Token) 831 ist der veröffentlichte Wert, der von dem zu dem Datenverarbeitungsgerät 300 des Urhebers gehörenden NRV-Erzeuger 310 erzeugt wurde. In dem vorliegenden Ausführungsbeispiel umfaßt das GNRT 8 Byte binäre Daten.
b) Das verbundene Nichtablehnungstoken (LNRT, Linked Non- Repudiation Token) 832 ist potentiell ein Token mit freiem Format und variabler Länge, dessen Zweck darin besteht, eine extern überprüfbare Zugehörigkeit dieses NRV zu einem oder mehreren anderen NRVs herzustellen, die zuvor zwischen denselben beiden Datenverarbeitungsgeräten 300 und 400 ausgetauscht wurden. In dem bevorzugten Ausführungsbeispiel handelt es sich um ein einziges Datenelement mit 8 Byte binären Daten und entspricht dem GNRT von dem NRV, der zu der vorangegangenen Nachricht gehört, die in derselben Transaktion gesendet oder empfangen wurde. In der Praxis kann diese Verbindung von erheblichem Wert sein, doch aufgrund der Konvention kann es notwendig sein, weitere oder weniger Verbindungen herzustellen.

Konventionsverbindungszeiger 840

Für jede der Verbindungen, die von der Konvention zur Erzeugung von GNRT und LGLNRT verlangt wird, mit Ausnahme der Verbindung zu dem vorangegangenen NRL-Eintrag, wird ein Rückwärtszeiger benötigt, um den zu verbindenden NRL-Eintrag zu identifizieren. Es sind zwei Untermerkmale dargestellt (siehe auch Figur 7(e)):
a) Der Transaktionsverbindungszeiger 841 zeigt auf den NRL- Eintrag, der zu der vorangegangenen Nachricht in der Transaktion gehört.
b) Der erzeugte Eintragsverbindungszeiger 842 zeigt auf den NRL-Eintrag, der zu der vorangegangenen Nachricht gehört, für die von diesem Nichtablehnungstoken-Erzeuger ein NRV erzeugt wurde.
Andere Rückwärtszeiger können verwendet werden, wenn es die verwendete Erzeugungskonvention erfordert.

Der Nachrichtenauthentifizierer

Hierbei handelt es sich um einen MAC, der verwendet werden kann, um die Sicherheit und Integrität des NRL sicherzustellen. Dies ist oben im Zusammenhang mit Figur 7(e) beschrieben.
Figur 8 zeigt ferner einige der Bestandteile des NRV 880, der zu jeder Nachricht gehört. Sie sind dargestellt, um ihre Zugehörigkeit zu den NRL-Einträgen zu veranschaulichen. Der vollständige NRV ist oben im Zusammenhang mit Figur 4 beschrieben. Bei den dargestellten Komponenten handelt es sich um:

Die Ursprungssequenznummer 881

Es sind drei Nachrichtenquellen dargestellt, die jeweils eine eigene Ursprungssequenznummer haben. Es sind:
a) Der lokale NRT-Erzeuger, der die Ursprungssequenznummern 1, 2, ... hat.
b) Ein erster Partner, der die Ursprungssequenznummern a, hat.
c) Ein zweiter Partner, der die Ursprungssequenznummern A, B, ... hat.
Es ist zu bemerken, daß bei empfangenen Nachrichten in der Ursprungssequenz, wie sie von dem empfangenden NRL wahrgenommen wird, Lücken vorkommen. Diese Lücken gehören zu Nachrichten, die von dem Partner zu anderen Knoten in dem Datennetzwerk gesendet werden.

Das Nichtablehnungstoken (NRT, Non-Repudiation Token) 882

Wie bei dem protokollierten NRT handelt es sich hier um eine zusammengesetzte Struktur.

Die Transaktionskontrolle (TRNCTL, Transaction control) 883

Sie gibt an, ob die Nachricht sich als erste, mittlere oder letzte Nachricht einer Transaktion ausgibt.
In Figur 8 sind zwei separate, ineinander verzahnte Transaktionen dargestellt.

Transalltion mit dem ersten Partner:

Diese Transaktion besteht aus folgenden vier Nachrichten, die durch Rückwärtsverkettung von den Transaktionsverbindungszeigern 841 aus identifiziert werden können:
- erste Nachricht 862, vom ersten Partner empfangen;
- mittlere Nachricht 864 empfangen;
- mittlere Nachricht 867 gesendet; und
- letzte Nachricht 868 empfangen.

Transaktion mit dem zweiten Partner:

Auch hier besteht die Transaktion aus vier Nachrichten, die von den Transaktionsverbindungszeigern 841 aus identifiziert werden können:
- erste Nachricht 861, an den zweiten Partner gesendet;
- mittlere Nachricht 863 gesendet;
- mittlere Nachricht 865 empfangen; und
- letzte Nachricht 866 gesendet.
Die von diesem NRL 800 abgesendeten Nachrichten, nämlich die Nachrichten 861, 863, 866 und 867, veranlassen ein erzeugtes GNRT. Der erzeugte Eintragsverbindungszeiger 842 für die einzelnen Einträge zeigt auf den LSEQ-Wert für die neueste dieser lokal abgesendeten Nachrichten.
Die NRT-Werte der NRL-Einträge 830 und der Nachrichten-NRVs 882 sind für jeden einzelnen Eintrag identisch, aber der LGLNRT-Wert 820 erscheint nicht in dem NRV für diese Nachricht; statt dessen wird er von dem NRL geheimgehalten, wie oben beschrieben. Die Ausdrücke "GNRT" und "RNRT" beziehen sich auf erzeugte NRTs 830, die lokal erzeugt bzw. empfangen wurden.
Es ist hier nicht nötig, den Wert zu erläutern, der den einzelnen Datenfeldern für die einzelnen Einträge in Figur 8 zugewiesen ist; die Bedeutung dieser Werte dürfte sich aus der obigen Beschreibung ergeben. Die zu der Nachricht 864 (die von dem ersten Partner empfangen wurde) gehörenden Werte werden jedoch anhand eines Beispiels erläutert.
Es sind zwei Komponenten des LCV 810 für die Nachricht 864 dargestellt: LSEQ und OSQ. LSEQ hat für diese Nachricht den Wert "864"; dies ist einfach ein Index für die Position des Eintrags in dem NRL 800. Der Wert OSQ, "f", bezieht sich auf die Position des Eintrags dieser Nachricht in dem NRL des ersten Partners. Der Wert LGLNRT 820 wird lokal erzeugt und geheimgehalten, wie oben beschrieben.
Das erzeugte NRT für diese Nachricht wurde tatsächlich von dem ersten Partner abgesetzt erzeugt; als empfangenes Token (RNRT) wird es mit "R4" bezeichnet und als LNRT für die nächste Nachricht 867 in dieser Transaktion verwendet. Ebenso ist der Wert LNRT, "R2", der erzeugte NRT-Wert aus der vorangegangenen Nachricht 862 in dieser Transaktion.
Es sind zwei Verbindungszeiger dargestellt; der erzeugte Verbindungszeiger hat den Wert "863" und zeigt auf die vorangegangene (an irgendeinen Partner) abgesendete Nachricht, die ein lokal erzeugtes NRT hat, und der Transaktionskontrollzeiger hat den Wert "862" und zeigt auf die vorangegangene Nachricht in dieser Transaktion. Für die erste Nachricht in einer Transaktion müssen den Verbindungszeigern unter Umständen willkürliche Werte (000 im Diagramm) zugewiesen werden.
Bezug nehmend auf die NRV-Einträge 800, die in Figur 8 dargestellt sind, hat die OSQ für die Nachricht 864 den Wert "f", denselben wie die OSQ im NRL. Ebenso enthalten die Felder GNRT und LNRT dieselben Werte wie die zu ihnen gehörenden Felder im NRL. Das Transaktionskontrollfeld 883 schließlich hat den Wert "m", der zeigt, daß die Nachricht 864 sich weder als erste noch als letzte Nachricht in der Transaktion ausgibt.
Figur 9 faßt die verschiedenen Verbindungen zusammen, die zwischen einer Nachricht 900, ihrem NRV und dem zugehörigen NRL-Eintrag, zwischen den Einträgen innerhalb des NRL 920 und zwischen den Nachrichten innerhalb einer einzigen Transaktion aufgebaut werden.
Die Nachricht wird durch den Nachrichten- Authentifizierungscode (MAC, Message Authentication Code) 905 mit ihrem NRV verbunden und wird mit dem Eintrag im NRL 920 des Absenders durch die Ursprungssequenznummer 910, die in dem NRV der Nachricht erscheint, und eine oder beide der Sequenznummern im NRL identifiziert.
Innerhalb des NRL 920 können die Einträge selbst mit Hilfe von zwei Verbindungsmechanismen verbunden sein, die oben näher beschrieben sind, und zwar unabhängig davon, ob die Nachrichten zu derselben Transaktion gehören. Der erste besteht darin, jeden NRL-Eintrag mit dem vorangegangenen und dem nachfolgenden Eintrag zu verbinden (schematisch durch die Verbindungen 930 bzw. 935 dargestellt). Die zweite Verbindung verbindet jeden NRL-Eintrag mit dem vorangegangenen und dem nachfolgenden Eintrag, für den ein GNRT nicht empfangen, sondern lokal erzeugt wurde. Sie sind schematisch als die Verbindungen 940 bzw. 945 dargestellt und werden während der Erzeugung des LGLNRT und im Fall einer gesendeten Nachricht des GNRT, das sowohl im NRL als auch im NRV der gesendeten Nachricht aufgezeichnet wurde, kryptographisch hergestellt.
Das Nichtablehnungstoken der Nachricht besteht aus zwei Komponenten: dem GNRT, das für diese Nachricht neu erzeugt wurde, und dem LNRT, das aus dem zu der vorangegangenen Nachricht in der Transaktion gehörenden NRL-Eintrag genommen wird 950. Dieses kombinierte NRT wird sowohl im NRV als auch im NRL aufgezeichnet 915. Das GNRT für erste oder mittlere Nachrichten in einer Transaktion werden in der nächsten Nachricht in dieser Transaktion als deren LNRT reflektiert. 955.
Es dürfte daher zu erkennen sein, daß die Nachrichten, mit denen eine bestimmte Nachricht verbunden ist, vielfältig sind und unabhängig voneinander sein können (d.h. mit einer Transaktion mit einer unbeteiligten dritten Partei verbunden sein können). Dadurch können bei der Schlichtung eines Streits die Beweise vieler Partner zur Feststellung der Authentizität eines einzelnen umstrittenen Elements herangezogen werden.
Nun verbleibt noch, das Verfahren zur Klärung eines Streits zwischen zwei Parteien über die Frage zu beschreiben, ob der behauptete Absender einer umstrittenen Nachricht tatsächlich der wahre Absender war. Figur 12 zeigt ein Flußdiagramm des Streitklärungsverfahrens. Der erste Schritt 1000 besteht darin, die relevanten Einträge aus dem NRL des angeblichen Absenders zu besorgen, die den Zeitraum vor und nach dem Absenden der Nachricht abdecken, sowohl von der Zeit her als auch von den Sequenznummern der NRL-Einträge her. Die umstrittene Nachricht bezeichnet das verwendete NRL und die zu der Nachricht gehörende NRL-Sequenznummer. Der behauptete Absender muß auf Verlangen eines Schiedsrichters eine Kopie dieses NRL vorlegen. Die Weigerung, dies zu tun, würde einen Vertrauensbruch darstellen und die künftige Glaubwürdigkeit des Absenders in ein zweifelhaftes Licht rücken. Das NRL des Empfängers zu der umstrittenen Transaktion muß ebenfalls vorgelegt werden.
Wenn sich im NRL des Absenders keine nachfolgenden Einträge befinden, wird durch einen Dialog mit einer unabhängigen Drittpartei (möglichst einer Schiedsstelle) ein Eintrag erzwungen. Dies kann auch schon früher getan worden sein, um einen ersten Eintrag im NRL zu schaffen.
In Schritt 1010 werden die oben beschafften NRLS bestätigt. Die NRLs werden auf richtige Reihenfolge und Vollständigkeit überprüft. Jeder Eintrag in jedem der NRLs stellt einen Teil eines Dialogs dar. Die zu empfangenen Nachrichten gehörenden Einträge bezeichnen die NRL des Partners und die NRL- Sequenznummern. Kopien dieser zugehörigen NRLs sollten ebenfalls beschafft werden. Die Einträge in den NRLs der einzelnen Partner müssen zu denen in den NRLs der Streitparteien passen.
Insbesondere sollten auf diese Weise folgende Elemente bestätigt werden:
a) das Element in den NRLs der einzelnen Streitparteien, das dem umstrittenen Element unmittelbar vorausgeht;
b) das Element in den NRLs der einzelnen Streitparteien, das dem umstrittenen Element unmittelbar folgt;
c) die Elemente in den NRLs der einzelnen Streitparteien, die vor und nach dem umstrittenen Element erzeugt wurden; und
d) das Element in den NRLs der einzelnen Streitparteien vor und nach der umstrittenen Transaktion in der Transaktionssequenz.
Die Integrität der obengenannten umgebenden Elemente muß ebenfalls bestätigt werden. Anhand der Aufzeichnungen der Geschäftstransaktionen zu diesen umgebenden Elementen muß die Beziehung zwischen den NRL-Einträgen und den Transaktionsdaten mit Hilfe des MAC oder der DSG der Nachrichten überprüft werden, die NRVs enthielten. Die Transaktionsverbindung muß ebenfalls überprüft werden, indem die GNRT/LNRT-Ketten verfolgt werden, und zwar sowohl in den Nachrichten als auch in den NRLs.
Wenn eins dieser früheren Elemente ebenfalls umstritten ist, dann müssen zwei verschiedene Streitigkeiten in der Reihenfolge der NRL-Sequenzen geregelt werden. Bevor der vorliegende Streit geklärt werden kann, müssen alle früheren Streitigkeiten geklärt sein.
Bei der Klärung der frühesten Einträge kommt es auf die ersten paar Einträge im NRL an. Sie müssen dort im Rahmen eines Dialogs mit einer Registrierungsstelle abgelegt worden sein, die das Vorhandensein der Hardwareeinheit des Absenders registriert und selbst ein NRL zur Überprüfung dieser ersten paar Einträge führt.
In Schritt 1020 wird ein Neuerstellungstest durchgeführt. Die Hardwareeinheit des Absenders wird aufgefordert, einen NRV zu der umstrittenen Nachricht zu erstellen, als ob der Zustand des NRL derselbe wäre wie zu dem Zeitpunkt, als der ursprüngliche, umstrittene, NRV erstellt wurde. Anzumerken ist, daß die Zeit, die NRL-Sequenz und das Neuerzeugungs-Flag (und dadurch auch der MAC) des neu erstellten NRV zwar anders sind, doch das NRT, das LNRT und das XNLT darüber entscheiden, ob der neu erstellte NRV dem umstrittenen NRV entspricht.
Wenn der Absender eine andere Datennachricht hat, die er anstelle der umstrittenen Nachricht gesendet zu haben behauptet, dann wird der NRV für diese andere Nachricht an dieser Position im NRL neu erstellt.
In Schritt 1030 wird dann ein Neuaufbautest durchgeführt. Anhand des neu erstellten NRV muß der Absender zeigen, daß das als nächstes erzeugte (und nicht umstrittene) NRT und XNLT ebenfalls aus den Nachrichtendaten der als nächstes gesendeten Nachricht erzeugt worden wäre.
Wenn beide Tests 1020 und 1030 positiv sind, ist die Echtheit der umstrittenen Nachricht erwiesen 1040. Wenn die umstrittene Nachricht falsch ist, fallen beide Tests negativ aus 1045.
Wenn eine Nachricht gefunden wird, für die ein Test bestanden wird, der andere dagegen nicht 1050, muß die Streitpartei, für die der Test nicht bestanden wurde, eine Nachricht produzieren, die historisch bestätigt werden kann und für die der Test bei ihrem NRL bestanden würde. Gelingt dies nicht, kommt das Datenverarbeitungs- und Sicherheitssystem dieser Streitpartei in Verruf und muß ersetzt werden, und die umstrittene Nachricht gilt als echt. Dahinter steht die Behauptung, daß die kryptographische Verbindung so beschaffen ist, daß es praktisch nicht möglich ist, eine solche Nachricht in angemessener Zeit zu finden.
Zusammenfassend läßt sich feststellen, daß das im Zusammenhang mit Figur 10 beschriebene Streitklärungsverfahren und das Gesamtsystem gemäß obiger Beschreibung die Aktivitäten eines bestimmten Absenders mit unumstrittenen Nachrichten, die mit einer Reihe außerhalb des Streits stehender Parteien ausgetauscht wurden, und mit vorangegangenen und nachfolgenden unumstrittenen Nachrichten, die mit demselben Partner ausgetauscht wurden, verbinden. Diese Möglichkeit, unabhängige Beweise in einen Streit einzubeziehen, bringt den umstrittenen Absender, der die umstrittene Nachricht ablehnen möchte, in die Lage, sein eigenes einwandfreies Verhalten nachweisen zu müssen, anstatt die Nachricht einfach zu leugnen.
Die Erfindung wurde zwar unter Bezugnahme auf ein bevorzugtes Ausführungsbeispiel beschrieben, doch dem Fachmann dürfte klar sein, daß viele verschiedene Ausführungsbeispiele möglich sind, ohne die Reichweite der Erfindung, wie sie in den Ansprüchen dargelegt ist, zu verlassen. Das oben beschriebene System kann auf mehrere unterschiedliche Arten implementiert werden, zum Beispiel mit generischen Datenverarbeitungskomponenten unter Softwaresteuerung, mit maßgeschneiderten oder speziell gestalteten integrierten Schaltkreisen oder mit hart verdrahteten diskreten Logikkomponenten. Die Erfindung kann zum Beispiel als Peripheriegerät eines Datenverarbeitungsgeräts oder als alleinstehendes Verschlüsselungsgerät in eine größere Datenverarbeitungsanlage integriert sein.

Claims

1. Ein Datenverarbeitungsgerät (10), das an ein Netzwerk mit anderen Datenverarbeitungsgeräten (20, 30) angeschlossen werden kann, welches umfaßt:

ein Mittel (300), das bei Anschluß an das Netzwerk zum Senden einer Nachricht an ein zweites zu dem Netzwerk gehörendes Datenverarbeitungsgerät dient;

und gekennzeichnet ist durch:

ein Mittel (310) zum kryptographischen Kombinieren von Informationen, die aus der Nachricht (600) abgeleitet sind, von Informationen (612, 613, 614, 615), die aus einer oder mehreren vorangegangenen Nachrichten abgeleitet sind, die zwischen dem ersten Datenverarbeitungsgerät und dem zweiten oder einem weiteren zu dem Netzwerk gehörenden Datenverarbeitungsgerät übertragen wurden, und von geheimen Informationen (611), die sich in dem erstgenannten Datenverarbeitungsgerät befinden, um ein Token (540) zu erzeugen, das mit der Nachricht verbunden werden soll.

2. Ein Datenverarbeitungsgerät nach Anspruch 1, das ferner ein Mittel (300) zum Senden des Tokens mit der Nachricht an das zweite Datenverarbeitungsgerät umfaßt.

3. Ein Datenverarbeitungsgerät nach einem der vorangegangenen Ansprüche, bei dem einige oder alle der Informationen, die von der einen vorangegangenen Nachricht oder mehreren vorangegangenen Nachrichten abgeleitet sind, aus dem zu dieser Nachricht bzw. diesen Nachrichten gehörenden Token abgeleitet sind.

4. Ein Datenverarbeitungsgerät nach einem der vorangegangenen Ansprüche, das ferner umfaßt:

ein Mittel (140) zur Erzeugung eines Authentifizierungstokens (580) aus der Nachricht und ihrem zugehörigen Token, wodurch die Nachricht und das Token kryptographisch miteinander verbunden werden; und

ein Mittel zum Senden des Authentifizierungstokens an den Empfänger der Nachricht.

5. Ein Datenverarbeitungsgerät nach einem der vorangegangenen Ansprüche, bei dem das Token Kontrollinformationen (510), Informationen, die von der aktuellen Nachricht abgeleitet sind, Informationen, die von der vorangegangenen Nachricht in der aktuellen Transaktion abgeleitet sind, und Informationen, die von der letzten von dem Datenverarbeitungsgerät gesendeten Nachricht abgeleitet sind, umfaßt.

6. Ein Datenverarbeitungsgerät nach einem der vorangegangenen Ansprüche, das ferner einen Speicher (340) zum Speichern geheimer Informationen umfaßt, die von dem Token oder der zugehörigen Nachricht oder von beiden abgeleitet sind.

7. Ein Datenverarbeitungsgerät nach Anspruch 6, bei dem nicht geheime Informationen, die von der Nachricht oder dem zugehörigen Token oder von beiden abgeleitet sind, in dem Speicher gespeichert sind und bei dem das Datenverarbeitungsgerät ferner ein Mittel zur Verschlüsselung einiger oder aller Informationen, die gespeichert werden sollen, umfaßt.

8. Ein Datenverarbeitungsgerät nach Anspruch 6 oder 7, bei dem jeder Eintrag in dem Speicher mit einem benachbarten Eintrag in dem Speicher verbunden ist und

Informationen in chronologischer Reihenfolge in dem Speicher gespeichert sind.

9. Ein Datenverarbeitungsgerät nach den Ansprüchen 6 bis 8, bei dem jeder Eintrag in dem Speicher, der zu einer Nachricht gehört, die Teil einer mehrere Nachrichten umfassenden Transaktion ist, mit der vorangegangenen Nachricht in dieser Transaktion verbunden ist.

10. Ein Datenverarbeitungsgerät nach den Ansprüchen 6 bis 9, bei dem jeder Eintrag in dem Speicher mit dem Eintrag verbunden ist, der zu der letzten von dem Datenverarbeitungsgerät gesendeten Nachricht gehört.

11. Ein Datenverarbeitungsgerät nach einem der vorangegangenen Ansprüche, das ferner ein Mittel (400) umfaßt, das bei Anschluß an das Netzwerk zum Empfangen einer Nachricht dient, die von einem zu dem Netzwerk gehörenden Datenverarbeitungsgerät gesendet wird.

12. Ein Datennetzwerk (10, 20, 30, 40, 50, 60) mit mehreren Datenverarbeitungsgeräten (10, 20, 30) nach einem der vorangegangenen Ansprüche und Mitteln (40, 50, 60), die die Datenverarbeitungsgeräte zur Übertragung von Nachrichten zwischen ihnen miteinander verbinden.