DE69928519T2

DE69928519T2 - Protokoll zur ubereinkunft über einen authentifizierten schlüssel

Info

Publication number: DE69928519T2
Application number: DE69928519T
Authority: DE
Inventors: Simon Blake-Wilson; B. Donald JOHNSON; Alfred Menezes
Original assignee: Certicom Corp
Current assignee: Certicom Corp
Priority date: 1998-05-01
Filing date: 1999-05-03
Publication date: 2006-08-10
Anticipated expiration: 2019-05-04
Also published as: AU3590299A; DE69928519D1; WO1999057844A1; JP2002514841A; EP1075746B1; EP1075746A1

Description

Diese Erfindung betrifft Verschlüsselungssysteme und insbesondere Authenticated-Key-Agreement-Protokolle, die in Verschlüsselungssystemen verwendet werden.
Ein Key-Agreement-Problem besteht, wenn sich zwei Entitäten geheim über ein verteiltes Netzwerk auf Schlüsseldaten verständigen wollen. Es sind umfangreich Lösungen des Key-Agreement-Problems, dessen Sicherheit auf einem Diffie-Hellman-Problem in finiten Gruppen basiert, benutzt worden.
Es wird indes angenommen, dass die Entität i geheime Schlüsseldaten mit der Entität j vereinbaren will. Jede Partei verlangt die Zusicherung, dass keine andere Partei als i und j die Schlüsseldaten, auf die man sich vereinbart hat, berechnen kann. Dies kann als Authenticated-Key-Agreement-Protokoll (AK) bezeichnet werden. Es ist klar, dass dieses Problem schwieriger zu lösen ist als das Key-Agreement-Problem, bei dem i sich nicht darum kümmert, mit welcher Entität es sich in Bezug auf einen Schlüssel einigt; zu diesem Problem schreibt i vor, dass der Schlüssel mit j und keiner anderen Entität geteilt werden darf.
Im Hinblick auf das Diffie-Hellman-Problem hat man verschiedene Techniken vorgeschlagen, um das AK-Problem zu lösen. Es konnten aber keine praktischen Lösungen beweisbar gezeigt werden, um dieses Ziel zu erreichen, und dieser Mangel hat in vielen Fällen zur Verwendung von fehlerhaften Protokollen geführt.
Da bei dem AK-Problem i lediglich verlangt, dass nur j den Schlüssel eventuell berechnen kann und nicht, dass j tatsächlich den Schlüssel berechnet hat, verlangt man oft, dass Lösungen implizite (Schlüssel-)Authentifikationen bereitstellen. Wenn i zusätzlich sicherstellen will, dass j wirklich den vereinbarten Schlüssel berechnet hat, dann ist die Schlüsselbestätigung in dem Key-Agreement-Protokoll enthalten, was zur so genannten expliziten Authentifikation führt. Das sich ergebende Ziel wird als authentifiziertes Key-Agreement mit Schlüsselbestätigung (AKC) bezeichnet. Es kann gesehen werden, dass die Schlüsselbestätigung tatsächlich die Gewissheit hinzufügt, dass i wirklich mit j kommuniziert. Folglich ähnelt das Ziel der Schlüsselbestätigung dem Ziel der Authentifizierung einer Entität, wie es in Diffie-Hellman definiert ist. Genauer gesagt verschafft aber die Einbindung der Authentifizierung einer Entität in dem AKA-Protokoll i die zusätzliche Sicherheit, dass j den Schlüssel berechnen kann, statt die stärkere Gewissheit, dass j tatsächlich den Schlüssel berechnet hat.
Es wurden eine Anzahl verschiedener Angriffsarten gegen bisherige Schemata vorgeschlagen. Es gibt zwei Hauptangriffe, denen ein Protokoll widerstehen sollte. Der erste ist ein passiver Angriff, bei der ein Angreifer versucht zu verhindern, dass ein Protokoll sein Ziel erreicht, indem lediglich redliche Entitäten, die Testprotokolle ausführen, beobachtet werden. Der zweite ist ein aktiver Angriff, bei dem ein Angreifer zusätzlich die Kommunikation selbst in irgendeiner möglichen Weise untergräbt, indem man Nachrichten einkoppelt, Nachrichten abfängt, Nachrichten wiederholt, Nachrichten verändert und dergleichen.
Für ein sicheres Protokoll ist es somit erforderlich, sowohl passiven als auch aktiven Angriffen zu widerstehen, da vernünftigerweise vermutet werden kann, dass ein Angreifer diese Fähigkeiten in einem verteilten Netzwerk hat.
Die Veröffentlichung „Strong PasswordOnly Authenticated Key Exchange" Computer Communications Review, Band 26, Nr. 5, 1. Oktober 1996, Seiten 5–26, XP000641968 ISSN: 0146-4833, Autor D. P. Jablon, offenbart ein einfaches Passwort gestütztes Exponential-Schlüssel-Austauschverfahren, das die Authentifizierung und Schlüsseleinrichtung über einen unsicheren Kanal unter Verwendung nur eines kleines Passwortes ermöglicht, ohne dass das Risiko eines Off-line-Dictionary-Angriffs besteht. Jablon verwendet einen einfachen verschlüsselten Diffie-Hellman (DH)-Schlüsselaustausch oder eine auf einem Passwort basierende Abwandlung dieses Schemas, um einen gemeinsamen Schlüssel K einzurichten.
Die europäische Patentanmeldung EP 0 481 121 von Hitz offenbart ein Authenticated-Key-Agreement-Protokoll, bei dem dauerhafte und flüchtige, öffentliche und private Schlüssel verwendet werden. Hitz verwendet dauerhafte Schlüssel, um vor dem DH-Austausch die Sender zu authentifizieren.
Es ist somit erstrebenswert, ein Key-Agreement-Protokoll zu schaffen, das zumindest einige der obigen Nachteile entschärft.
DARSTELLUNG DER ERFINDUNG
Die Erfindung betrifft ein Verfahren, wie es im Patentanspruch 1 beansprucht ist.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Diese und weitere Merkmale der bevorzugten Ausführungsformen der Erfindung werden aus der nachfolgenden detaillierten Beschreibung und unter Bezugnahme auf die beigefügten Zeichnungen deutlicher, wobei
1 ein schematisches Diagramm eines digitalen Datenkommunikationssystems ist,
2, 3, 4 und 5 Ausführungsformen eines Key-Agreement-Protokolls gemäß der vorliegenden Erfindung sind.
BESCHREIBUNG DER BEVRZUGTEN AUSFÜHRUNGSFRMEN
In der nachfolgenden Erläuterung wird von der im Folgenden umrissenen Notation in der Veröffentlichung von Diffie-Hellman mit dem Titel „New Directions in Cryptography", IEEE Transactions on Information Theory, November 1976 vollständiger Gebrauch gemacht und beschrieben, und die Veröffentlichung wird hier durch Bezugnahme mit aufgenommen.
Es wird Bezug genommen auf die 1, in der ein Datenkommunikationssystem 10 ein Entitäten- oder Korrespondenzpartnerpaar, die als Sender i und Empfänger j bezeichnet sind, enthält, welche durch einen Kommunikationskanal 16 miteinander verbunden sind. Jeder der Korrespondenzpartner i und j enthält eine Verschlüsselungseinheit 18, 20, die in der nachfolgend beschrieben Weise digitale Information verarbeiten und diese zur Übertragung über den Kanal 16 herrichten kann. Darüber hinaus können die Verschlüsselungseinheiten entweder ein zweckbestimmter Prozessor oder ein für allgemeine Zwecke dienender Prozessor mit Software zur Programmierung des für allgemeine Zwecke dienenden Computers zur Durchführung spezifischer kryptografischer Funktionen sein.
Die Protokolle sind in Form von arithmetischen Operationen in einer Untergruppe beschrieben, die durch ein Element α primer Ordnung q in der multiplikativen Gruppe Z * / p = {1, 2, ..., p – 1} erzeugt ist, wobei p eine Primzahl ist. In jedem Fall ist der private Wert einer Entität ein Element S_i von Z * / q = {1, 2, ..., q – 1} und der entsprechende öffentliche Wert ist
so dass i' s Schlüsselpaar K_i= (S_i, P_i) ist. Es ist zu beachten, dass die Protokolle genauso gut auch in arithmetischen Operationen in irgendeiner finiten Gruppe beschrieben werden können und selbstverständlich würde dies die Konvertierung der Sicherheitsannahmen des Diffie-Hellman-Problems auf diese Gruppe erfordern. Des Weiteren wird ein einzelner Lauf eines Protokolls Sitzung [session] genannt. Beispielsweise werden die Schlüsseldaten, auf die man sich im Zuge eines Protokolllaufs vereinbart hat, als Sitzungsschlüssel bezeichnet. Die individuellen Nachrichten, die einen Protokolllauf bilden, werden Flows genannt.
Die nachfolgend beschriebenen Protokolle verwenden verschiedene Primitive [primitives]. Von diesen Primitiven sind die zwei verwendeten Primitive: Message Authentication Codes (MAC) und Diffie-Hellman Schemata (DHS). Natürlich können manche Anwendungen andere Primitive zur Erzielung einer Bestätigung verwenden wollen. Wenn beispielsweise der vereinbarte Sitzungsschlüssel später zur Verschlüsselung zu verwenden ist, scheint es vernünftig zu sein, ein Verschlüsselungsschema zu verwenden, um eine Schlüsselbestätigung auszuführen anstatt mit der Implementierung eines MAC Zeit zu verschwenden.
Protokoll 1
Es wird nun Bezug genommen auf die 1, in der eine grafische Darstellung einer ersten Ausführungsform eines AKC-Protokolls (Protokoll 1) gemäß der vorliegenden Erfindung gezeigt ist, das allgemein mit dem Bezugszeichen 22 gekennzeichnet ist. Wir verwenden ∈_R, um ein unabhängig, zufällig gewähltes Element zu kennzeichnen und Kommata, um eine einzigartige Codierung durch Konkatenation (oder irgendeine andere einzigartige Codierung) zu kennzeichnen. Es wird angenommen, dass H₁ und H₂ unabhängige Random-Oracles darstellen und (p, q, α) globale Parameter sind. Die Random-Oracles können wie folgt durch das Werfen einer Münze definiert werden. Es wird angenommen, dass alle Parteien mit einer Black-Box Random-Funktion H(·): {0, 1}^k→ {0, 1^k} ausgestattet sind. Wenn H zum ersten Mal ausgeführt wird, sagen wir auf den String x, reicht sie den String der Länge k entsprechend ihrer ersten k Münzwürfe als H(x) zurück. Wenn sie mit einem zweiten String x' abgefragt wird, vergleicht H zuerst x und x'. Wenn x' = x, liefert H wieder seine ersten k Münzwürfe H(x). Ansonsten liefert H seine zweiten k Münzwürfe als H(x'). In der Umschreibung wird H allgemein durch Hash-Funktion H modelliert. Wenn die Entität i wünscht, einen Lauf von P mit der Entität j zu initiieren, wählt i per Zufall ein Element R_i ∈_R Z * / q und sendet
zu j. Nach dem Erhalt dieses Strings überprüft j, ob
dann wählt j R_j ∈_R Z * / q und berechnet α^Rj und
Schließlich verwendet j k', um MAC_k'(2, i, j, α^Rj, α^Ri) und sendet diese authentisierte Nachricht zu i. (Man erinnere sich, dass MAC_k'(m) das Paar (m, α) repräsentiert und nicht nur das Tagα). Nach Erhalt dieses Strings überprüft i, ob die Form dieser Nachricht korrekt ist und ob
Die Entität i berechnet dann
wobei in Erinnerung zu rufen ist, dass α^Sj der dauerhafte öffentliche Schlüssel von j ist, und verifiziert die authentisierte Nachricht, die eingegangen ist. Gegebenenfalls akzeptiert i und sendet an j
Nach Erhalt dieses Strings überprüft j die Form der Nachricht, verifiziert die authentisierte Nachricht und akzeptiert. Beide Parteien berechnen den vereinbarten Sitzungsschlüssel als
Wenn zu irgendeinem Zeitpunkt eine Überprüfung oder eine Verifikation, die von i oder j durchgeführt wird, fehlschlägt, dann beendet diese Partei den Protokolllauf und weist zurück.
In der Praxis kann die Entität i wünschen, ihre Identität dem ersten Flow des Protokolls 1 hinzuzufügen. Wir lassen diese Identität weg, da bestimmte Anwendungen verlangen können, die involvierten Entitäten auf der Paketebene anstatt der Nachrichtenebene zu identifizieren – in diesem Fall ist deswegen die wiederholte Identifizierung von i überflüssig.
Es ist zu beachten, dass im Protokoll 1 die Entitäten zwei verschiedene Schlüssel verwenden – ein Schlüssel zur Bestätigung und ein sich von dem Sitzungsschlüssel unterscheidender Schlüssel zur nachfolgenden Verwendung. Insbesondere kann die übliche Praxis, den gleichen Schlüssel sowohl für die Bestätigung als auch als Sitzungsschlüssel zu verwenden, nachteilig sein, wenn dies bedeutet, dass der gleiche Schlüssel von mehr als einer Primitive verwendet wird.
Das Protokoll 1 unterscheidet sich von den meisten vorgeschlagenen AKC-Protokollen dahingehend, dass die Entitäten ihre dauerhaften geheimen Werte und sitzungsspezifischen geheimen Werte verwenden. Die meisten vorgeschlagenen Protokolle verwenden bei der Bildung aller Schlüssel sowohl dauerhafte als auch flüchtige Geheimnisse. Im Protokoll 1 werden dauerhafte Geheimnisse als auch flüchtige Geheimnisse auf ziemlich unterschiedliche Art umgesetzt. Dauerhafte Geheimnisse werden nur zur Bildung eines sitzungsunabhängigen Confirmation-Schlüssels verwendet und flüchtige Geheimnisse werden nur zur Bildung des vereinbarten Sitzungsschlüssels verwendet. Konzeptionell hat dieser Ansatz gegenüber herkömmlichen Techniken sowohl Vor- als auch Nachteile. Auf der positiven Seite ist anzumerken, dass die Verwendung von dauerhaften Schlüsseln und flüchtigen Schlüsseln eindeutig ist, was dazu dient, die Effekte einer Schlüssel-Kompromitierung zu klären – Kompromitierung eines dauerhaften Schlüssels ist für die Sicherheit von zukünftigen Sitzungen fatal und muss unmittelbar beseitigt werden, wohingegen die Kompromitierung eines flüchtigen Geheimnisses nur diese bestimmte Sitzung schädigt. Negativ ist, dass im Protokoll 1 beide Entitäten einen dauerhaften gemeinsamen Sicherheitsschlüssel k' beibehalten müssen.
Protokoll 2
Das Protokoll 2 ist ein AKC-Protokoll, das zur Bewältigung einiger Nachteile des Protokolls 1 ausgestaltet ist. Es ist in der 3 grafisch dargestellt. Die durch die Entitäten i und j ausgeführten Aktionen gleichen denen des Protokolls 1, außer dass die Entitäten bei der Berechnung der beiden Schlüssel, die sie einsetzen, sowohl flüchtige als auch dauerhafte Werte verwenden. Insbesondere verwenden die Entitäten
als ihren MAC-Schlüssel für diese Sitzung und
als vereinbarten Sitzungsschlüssel. Entgegen dem Protokoll 1 werden im Protokoll 2 beide dauerhaften Geheimnisse als auch beide flüchtigen Geheimnisse zur Erstellung jedes Schlüssels verwendet. Weil dies dazu führt, dass die Auswirkungen einer Kompromittierung eines dieser Werte weniger deutlich werden, bedeutet dies auch, dass kein dauerhafter gemeinsamer Schlüssel vorhanden ist, der in jeder Sitzung zwischen i und j für MAC-Nachrichten verwendet wird. Die zwei Entitäten teilen sich aber weiterhin einen dauerhaften geheimen Wert
Dieser Wert muss deswegen zusammen mit S_i und S_j selbst gegen eine Kompromitierung überwacht werden. Konzeptmäßig ist es möglich, im Protokoll 2 die AK-Phase und die Key-Confirmation-Phase zu trennen.
Protokoll 3
Eine Ausführungsform eines sicheren AK-Protokolls ist in der 4 dargestellt, die eine grafische Darstellung der von i und j in einem Lauf des Protokolls 3 vorgenommenen Aktionen zeigt. Dass das Protokoll 3 kein sicheres AK-Protokoll ist, wenn ein Angreifer unbestätigte Sitzungsschlüssel aufdecken kann, zeigt der folgende Angriff. E beginnt zwei Läufe des Protokolls, einen mit Π 3 / i,j und einen mit Π u / i,j. Angenommen, Π 3 / i,j sendet
und Π u / i,j sendet
E übermittelt nun
zu Π u / i,j und
zu Π α / i,j. E kann nun den Sitzungsschlüssel
der von Π 3 / i,j gehalten wird, herausfinden, indem der durch Π u / i,j gehaltene (gleiche) Schlüssel aufgedeckt wird.
In diesem Protokoll muss beim Trennen des Authenticated-Key-Agreements von der Key-Confirmation Sorgfalt walten gelassen werden. Das obige Protokoll 3 ist in dem vollständigen Modell des Distributed Computing kein sicheres AK-Protokoll, kann aber nichtsdestotrotz in ein sicheres AKC-Protokoll umgewandelt werden. Ein strittiger Punkt ist hier, ob es realistisch ist, zu erwarten, dass ein Angreifer Schlüssel lernen kann, die nicht bestätigt worden sind.
Wir haben deswegen in dieser Beschreibung versucht, die Ziele des AK und des AKC zu trennen. Ein Grund, warum wir uns bemüht haben, das Authenticated-Key-Agreement von der Key-Confirmation zu trennen, besteht darin, Flexibilität dahingehend zu ermöglichen, wie eine bestimmte Implementierung versucht eine Key-Confirmation zu erzielen. Beispielsweise können die Architektur betreffende Überlegungenerforderlich machen, dass ein Key-Agreement und eine Key-Confirmation voneinander getrennt werden – einige Systeme können während eines „Real-Time"-Telefongesprächs eine Key-Confirmation liefern, bevor ein Sitzungsschlüssel über ein Computernetzwerk vereinbart wird, während es andere Systeme stattdessen bevorzugen, eine Confirmation implizit auszuführen, indem der Schlüssel verwendet wird, um spätere Kommunikationen zu verschlüsseln.
Der Grund, warum wir die Verwendung einer Untergruppe von primer Ordnung durch die DHSs spezifiziert haben, besteht darin, verschiedene bekannte Sitzungsschlüssel-Angriffe auf AK-Protokolle zu vermeiden, die die Tatsache ausnutzen, dass ein Schlüssel gezwungen werden kann, in einer kleinen Untergruppe von Z * / p zu liegen. Unter dem Gesichtspunkt Nachwei se der Sicherheit könnten wir genauso gut auch Annahmen über DHSs gemacht haben, die in Z * / p anstatt in einer Untergruppe von Z * / p definiert sind.
Es mag insbesondere zu beachten sein, dass, wie im Falle des Protokolls 3, viele bisherige AK-Protokolle bei der Bildung des vereinbarten Schlüssels keine Asymmetrie enthalten, um hervorzuheben, welche involvierte Entität der Initiator des Protokolls und welche die Antwortende des Protokolls ist.
Protokoll 4
Noch einmal, anstatt dass wir die Aktionen von i und j in diesem Protokoll verbal beschreiben, veranschaulichen wir diese Aktionen in der 5. Während auf den ersten Blick das Protokoll 4 mit dem hinlänglich bekannten MTI-Protokoll, bei dem der berechnete gemeinsame Wert
ist, fast identisch aussieht, ist der folgende wichtige Unterschied zu beachten. Die Entität i berechnet im Protokoll 4 einen anderen Schlüssel in Abhängigkeit davon, ob i glaubt, dass sie die Initiatorin oder die Antwortende ist. Im ersten Fall berechnet i
und im zweiten Fall
Wie zuvor erwähnt, ist eine derartige Asymmetrie in einem sicheren AK-Protokoll erstrebenswert. Selbstverständlich ist eine solche Asymmetrie nicht immer anzustreben – eine bestimmte Umgebung kann erfordern, dass i immer den gleichen Schlüssel berechnet, ganz gleich, ob i der Initiator oder der Antwortende ist.
Wenn tatsächlich gezeigt werden kann, dass das Protokoll 4 ein sicheres AK-Protokoll ist, dann kann es im gleichen Sinne wie das Protokoll 2 in ein sicheres AKC-Protokoll umgewandelt werden.
Eine Frage, die sich stellt, ist, wie die Random-Oracles H₁ und H₂ initiiert werden. Eine Hash-Funktion, wie beispielsweise SHA-1, sollte für die meisten Anwendungen eine ausreichende Sicherheit bieten. Sie kann auf verschiedene Arten verwendet werden, um Instantiierungen unabhängiger Random-Oracle zu schaffen. Beispielsweise kann eine Implementierung des Protokolls 1 gewählt werden, um folgende Formel auszuführen: H1(x): = SHA-1(01, x)undH2(x): = SHA-1(10, x).
Eine besonders effiziente Instantiierung der im Protokoll 2 verwendeten Random-Oracles ist möglich, indem SHA-1 oder RIPEMD-160 verwendet werden. Es wird angenommen, dass 80-Bit-Sitzungsschlüssel und MAC-Schlüssel erforderlich sind. Dann können die ersten 80 Bits von
als k' verwendet werden und die zweiten 80 Bits können als k verwendet werden. Natürlich können solche effizienten Implementierungen nicht die höchste denkbare Sicherheit für irgendeine Instantiierung bieten.
Es ist einfach, bei Implementierungen des AKC-Protokolls Einsparungen in der Bandbreite zu machen. Anstatt in den Flows 2 oder 3 die vollen authentisierten Nachrichten [authenticated messages] (m, α) zu senden, kann in beiden Fällen die Entität viel von m weglassen, den Rest der Nachricht lässt man durch seinen Empfänger schlussfolgern.
In einigen Anwendungen mag es nicht wünschenswert sein, jedes Mal, wenn ein neuer Sitzungsschlüssel gefordert wird, einen Protokolllauf auszuführen. Wenn man beispielsweise insbesondere das Protokoll 2 hernimmt, können die Entitäten verlangen, das der vereinbarte Schlüssel wie folgt berechnet wird:
Anstatt jedes Mal, wenn ein neuer Schlüssel verlangt wird, das gesamte Protokoll laufen zu lassen, wird dann meistens einfach der Zähler inkrementiert. Die Entitäten müssen dann nur gelegentlich auf das Protokoll selbst zurückgreifen, um etwas zusätzliches Vertrauen in die „Frischheit" der Sitzungsschlüssel zu erhalten, die sie gerade verwenden.
In den Protokollen 1, 2 und 3 können Leistungs- und Sicherheitsgründe es wünschenswert machen, eine größere (und wahrscheinlich sicherere) Gruppe für die Berechnung der statischen Diffie-Hellman-Zahl
anstatt für die Berechnung der flüchtigen Diffie-Hellman-Zahl
zu verwenden. Die größere Gruppe ist erstrebenswert, weil die statische Zahl öfters verwendet werden wird. Die statischen Zahlen können gecached werden, um für eine Beschleunigung der Berechnung des Sitzungsschlüssels zu sorgen.
Schließlich ist zu beachten, dass eine praktische Instantiierung von G (angenommen, G generiert Schlüsselpaare für jede Entität) unter Verwendung von Zertifikaten die Kenntnis des si cheren Werts überprüfen sollte, bevor ein Zertifikat auf den entsprechenden öffentlichen Wert ausgegeben wird. Wir glauben, dass dies bei der Implementierung einer Zertifikationshierarchie eine merkliche Sicherheitsmaßnahme darstellt.
Während die Erfindung in Verbindung mit der spezifischen Ausführungsform und in einer spezifischen Verwendung beschrieben wurde, werden sich Fachleute über verschiedene Modifikationen klar werden. Beispielsweise wird jede Entität gewöhnlich selbst Schlüsselpaare generieren und dann diese durch eine Zertifikationsautorität zertifiziert bekommen.
Die in dieser Beschreibung verwendeten Begriffe und Ausdrücke sind als erläuternd und nicht limitierend zu verstehen. Es versteht sich, dass innerhalb des Schutzbereichs der Ansprüche verschiedene Modifikationen der Erfindung möglich sind.

Claims

Verfahren zur Schlüsselübereinkunft zwischen einem Paar von Entitäten i und j in einem digitalen Kommunikationssystem (10), in dem jede der Entitäten eine Entitätsidentität und ein privates und ein entsprechendes öffentliches Schlüsselpaar S_i, P_i bzw. S_j, P_j hat, wobei das System globale Parameter zum Erzeugen von Elementen einer Gruppe hat und das Verfahren die folgenden Schritte umfasst: a) die Entität i wählt einen privaten Sitzungswert R_i, b) die Entität i übermittelt einen dem privaten Sitzungswert R_i entsprechenden öffentlichen Sitzungswert Q_i an die Entität j, c) die Entität j berechnet einen aus dem öffentlichen Schlüssel P_i der Entität i und dem privaten Schlüssel S_j der Entität j abgeleiteten dauerhaften gemeinsamen geheimen Schlüssel k', wobei zur Berechnung eine erste Funktion H₁ verwendet wird, d) die Entität j verwendet den Schlüssel k' zum Berechnen einer ersten authentisierten Nachricht über die Entitätsidentitäten von i und j, den öffentlichen Sitzungswert Q_i der Entität i, und einen zu einem privaten Sitzungswert R_j der Entität j zugehörigen öffentlichen Sitzungswert Q_j der Entität j, e) die Entität j übermittelt die erste authentisierte Nachricht an die Entität i, f) die Entität i verifiziert die erste authentisierte Nachricht, g) die Entität i berechnet den Schlüssel k', wobei der Schlüssel k' aus dem öffentlichen Schlüssel P_j der Entität j und dem privaten Schlüssel S_i der Entität i gemäß der ersten Funktion H₁ abgeleitet wird, h) die Entität i verwendet den Schlüssel k' zum Berechnen einer zweiten authentisierten Nachricht über die Entitätsidentitäten von i und j und die öffentlichen Sitzungswerte Q_i und Q_j der Entitäten, und leitet die zweite authentisierte Nachricht an die Entität j weiter, i) die Entität j verifiziert die zweite authentisierte Nachricht, und j) die Entität i berechnet einen flüchtigen gemeinsamen geheimen Schlüssel k, wobei die Berechnung des Schlüssels k den privaten Sitzungswert R_i der Entität i und den aus der ersten authentisierten Nachricht erhaltenen öffentlichen Sitzungswert Q_j der Entität j verwendet, k) die Entität j berechnet den Schlüssel k, wobei die Berechnung des Schlüssels k durch die Entität j den privaten Sitzungswert R_j der Entität j und den aus der zweiten authentisierten Nachricht erhaltenen öffentlichen Sitzungswert Q_i der Entität i verwendet, womit sich das Entitätspaar i und j auf die Verwendung des Schlüssels k in dem digitalen Datenkommunikationssystem (10) verständigt.