DE102020200726A1

DE102020200726A1 - Verfahren zum Austausch kryptographischer Schlüssel zur quantensicheren Kommunikation zwischen einem Server und einem Client

Info

Publication number: DE102020200726A1
Application number: DE102020200726.8A
Authority: DE
Inventors: Esther Guerin; Sebastian Paul
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2020-01-22
Filing date: 2020-01-22
Publication date: 2021-07-22

Abstract

Die Erfindung betrifft ein Verfahren in einem Server zum Austausch kryptographischer Schlüssel zur quantensicheren Kommunikation zwischen dem Server (200) und einem Client (100), umfassend Empfangen, von einem Client (100), einer Anforderungsnachricht für einen sicheren Kommunikationskanal, wobei die Anforderungsnachricht mindestens einen quantensicheren öffentlichen Schlüssel und eine erste Nonce umfasst, wobei der quantensichere öffentliche Schlüssel Teil eines Schlüsselpaars ist, das mittels einer Schlüsselerzeugungsfunktion eines quantensicheren Schlüsselkapselungsmechanismus gebildet wurde; Erzeugen (230) einer zweiten Nonce; Kapseln (240) des quantensicheren öffentlichen Schlüssels mit einer Kapselungsfunktion des quantensicheren Schlüsselkapselungsmechanismus, wobei das Kapseln einen Geheimtext sowie ein gemeinsames Geheimnis erzeugt; Erzeugen (250) einer dritten und einer vierten Nonce unter Verwendung des erzeugten gemeinsamen Geheimnisses; Erzeugen (260) von hybriden symmetrischen Schlüsseln aus der ersten Nonce, der zweiten Nonce, der dritten Nonce und der vierten Nonce unter Verwendung eines Combiners, Senden einer Antwortnachricht (280) an den Client, wobei die Antwortnachricht mindestens den erzeugten Geheimtext und die zweite Nonce umfasst. Weiter betrifft die Erfindung ein komplementäres Verfahren auf der Seite des Clients zum Verarbeiten der Antwortnachricht.

Description

Die vorliegende Erfindung betrifft Verfahren zum Austausch kryptographischer Schlüssel zur quantensicheren Kommunikation zwischen einem Server und einem Client sowie eine Recheneinheit und ein Computerprogramm zu deren Durchführung.
Stand der Technik
Übliche kryptographische Anwendungen und Protokolle nutzen asymmetrische kryptographische Primitive zum Erzeugen eines gemeinsamen Geheimnisses (shared secret, ss), und symmetrische kryptographische Primitive zur Verwendung des erzeugten gemeinsamen Geheimnisses beim Datentransport. Im Allgemeinen beruht die Sicherheit durch kryptographische Primitive dabei auf der Komplexität (z.B. benötigter Rechenzeit) der verwendeten Algorithmen mit aktuellen Rechnerarchitekturen. Beispielsweise nutzt das weit verbreitete RSA-Verfahren die Faktorisierung großer Zahlen, die aufwändig zu berechnen ist; die Elliptic Curve Cryptography (ECC) basiert auf dem Problem der Berechnung diskreter Logarithmen in einer Gruppe aus Punkten einer elliptischen Kurve, wofür ebenfalls kein schneller Algorithmus bekannt ist.
Sobald jedoch ausreichend rechenstarke Quantencomputer zur Verfügung stehen, sind diese Probleme auf Grundlage des Shor-Algorithmus in Polynomialzeit lösbar. Ein Angreifer, der eine derart verschlüsselte Kommunikation abhört und abspeichert, könnte daher mit Quantencomputern die abgefangenen Informationen entschlüsseln, was auch als „store now, decrypt later“-Angriff bekannt ist. Damit bieten diese Verfahren keine zuverlässige Sicherheit mehr auf Grundlage ihrer Komplexität und müssen durch neue, quantensichere Verfahren (Post-Quantum Cryptography, PQC) ersetzt oder erweitert werden. Solche Verfahren werden auch als PQ-sicher bezeichnet. Derzeit wird eine Vielzahl von möglichen Alternativen ausgearbeitet, die in zukünftigen Standards verwendet werden könnten.
Dieses Problem betrifft eine Vielzahl beliebiger kryptographischer Anwendungen. Ein Beispiel sind Systeme auf Grundlage des OPC UA-Standards (Open Platform Communication Unified Architecture), der insbesondere im industriellen Bereich für Kommunikation zwischen Endgeräten wie Maschinen, Automaten, Fahrzeugen und entsprechenden zentralen Stellen genutzt wird (Machine-to-Machine). Zukünftig könnte OPC-UA beispielsweise auch eine Rolle für die Kommunikation von Endgeräten im Zusammenhang mit dem „Internet der Dinge“ (loT, internet of things) sowie der allgemeinen Vernetzung von Geräten in allen Bereichen spielen. Details des OPC UA-Standards können beispielsweise der mehrteiligen Standard-Spezifikation „OPC Unified Architecture Specification“ der OPC Foundation, Teil 1 bis Teil 14, abrufbar auf https://opcfoundation.org/developer-tools/specifications-unified-architecture, entnommen werden.
Eine grundlegende Eigenschaft von OPC UA ist die Möglichkeit der Bereitstellung von sicheren Kommunikationskanälen zwischen zwei Teilnehmern, insbesondere zwischen einem Client und einem Server. Dabei ist ein Handshake-Verfahren zur Initialisierung eines sicheren Kommunikationskanals zwischen den Teilnehmern vorgesehen. Das Verfahren beruht auf der Erzeugung einer sogenannten OpenSecureChannel-Anforderung durch den Client, die unter anderem eine Client-Nonce in Form einer kryptographisch sicheren Zufallszahl und ein validiertes Client-Zertifikat umfasst. Die OpenSecureChannel-AnforderungsNachricht wird dann unter Verwendung eines öffentlichen Schlüssels des Servers (pk_server) verschlüsselt und unter Verwendung eines privaten Schlüssels des Clients (sk_client) signiert. Die so erzeugte signierte und verschlüsselte Nachricht wird vom Client an den Server gesendet.
Das Zertifikat befindet sich im Header und kann daher vom Server ohne Entschlüsselung der Nachricht validiert werden. Falls das Zertifikat erfolgreich validiert wird, wird die Nachricht anschließend vom Server entschlüsselt und auf Authentizität überprüft. Anschließend erzeugt der Server eine kryptographische Zufallszahl als Server-Nonce. Zum Signieren und Verschlüsseln weiterer Nachrichten in dem sicheren Kanal werden dann symmetrische Schlüssel auf Grundlage der Server- und Client-Nonces erzeugt, indem diese als Eingangswerte einer pseudozufälligen Funktion (PRF) verwendet werden.
Anschließend sendet der Server eine Antwort zurück an den Client, die unter anderem die Server-Nonce enthält.
Die ausgetauschten Handshake-Nachrichten können weitere Elemente enthalten, beispielsweise eine Lebensdauer für ein Sicherheits-Token, welches anzeigt, nach welcher Zeit der gesicherte Kanal erneut durch eine weitere AnforderungsNachricht initialisiert werden muss.
Die eigentlichen Nachrichten in dem gesicherten Kanal werden dann durch die symmetrischen Sitzungsschlüssel (session keys) verschlüsselt und signiert, die sowohl beim Server als auch beim Client auf Grundlage der vorherigen Initialisierung und dem Austausch der asymmetrischen Schlüssel identisch erzeugt wurden. Die symmetrischen Sitzungsschlüssel können in definierten Zeitabständen regelmäßig erneuert werden.
Ein Angreifer, der die vorstehend beschriebenen Nachrichten während eines OpenSecureChannel-Handshakes (Anforderung und Antwort) abfängt, könnte bei Zugriff auf einen ausreichend rechenstarken Quantencomputer diese Nachrichten entschlüsseln und hätte damit alle notwendigen Informationen, um auch sämtliche folgenden Nachrichten einer Sitzung zu entschlüsseln. Das so gebildete Sicherheitsverfahren im OPC UA-Standard ist damit bislang nicht quantensicher. Es besteht also Bedarf, einen verbesserten Sicherheitsmechanismus zum Initialisieren einer sicheren Kommunikation zwischen zwei Teilnehmern zu entwerfen, insbesondere für den OPC UA-Standard.
Offenbarung der Erfindung
Erfindungsgemäß werden daher Verfahren zum Austausch kryptographischer Schlüssel zur quantensicheren Kommunikation zwischen einem Server und einem Client sowie eine Recheneinheit und ein Computerprogramm zu deren Durchführung mit den Merkmalen der unabhängigen Patentansprüche vorgeschlagen. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche sowie der nachfolgenden Beschreibung.
Dabei wird gemäß einem Aspekt ein Verfahren in einem Server zum Austausch kryptographischer Schlüssel zur sicheren Kommunikation zwischen dem Server und einem Client vorgeschlagen, wobei zunächst vom Client eine Anforderungsnachricht für einen sicheren Kommunikationskanal empfangen wird, wobei die Anforderungsnachricht mindestens einen quantensicheren öffentlichen Schlüssel und eine erste Nonce umfasst, wobei der quantensichere öffentliche Schlüssel Teil eines Schlüsselpaars ist, das mittels einer Schlüsselerzeugungsfunktion eines quantensicheren Schlüsselkapselungsmechanismus gebildet wurde. Außerdem wird eine zweite Nonce erzeugt. Anschließend wird der quantensichere öffentliche Schlüssel mit einer Kapselungsfunktion des quantensicheren Schlüsselkapselungsmechanismus gekapselt, wobei das Kapseln einen Geheimtext sowie ein gemeinsames Geheimnis erzeugt. Unter Verwendung dieses gemeinsamen Geheimnisses wird danach eine dritte und vierte Nonce erzeugt. Die erste, zweite, dritte und vierte Nonce werden dann unter Verwendung eines Combiners zum Erzeugen von hybriden symmetrischen Schlüsseln genutzt. Schließlich wird eine Antwortnachricht an den anfordernden Client gesendet, die mindestens den erzeugten Geheimtext und die zweite Nonce umfasst. Dabei können bevorzugt vier symmetrische Schlüssel erzeugt werden, wobei optional in beispielhaften Ausführungsformen auch weniger Schlüssel erzeugt werden können, wenn z.B. ein Modus gewählt wird, in dem Nachrichten nur signiert und nicht verschlüsselt werden sollen.
Auf diese Weise werden quantensichere Verfahren in einen bestehenden Schlüsselaustausch effektiv integriert und bieten insbesondere Schutz gegen passive Angriffe unter Verwendung von Quantencomputer (store now, decrypt later). Durch die Verwendung von vier Nonces können die bereits im herkömmlichen OPC UA-Standard genutzten zwei Nonces mitverwendet werden.
Optional kann nach dem Erzeugen der Schlüssel eine MAC-Funktion auf den Geheimtext, die erste und die zweite Nonce, zum Bilden eines Nachrichten-Authentifizierungs-Codes angewendet werden, wobei die MAC-Funktion einen der erzeugten hybriden symmetrischen Schlüssel verwendet, und wobei die Antwortnachricht an den Client zusätzlich den gebildeten Nachrichten-Authentifizierungs-Code umfasst. Dies ermöglicht es dem Client, die Gültigkeit der jeweils lokal erzeugten symmetrischen Schlüssel zu validieren, bevor sie zum Nachrichtenaustausch eingesetzt werden.
Darüber hinaus wird auch ein Verfahren in einem Client zum Austausch kryptographischer Schlüssel zur sicheren Kommunikation zwischen dem Client und einem Server vorgeschlagen, bei dem eine erste Nonce erzeugt wird und mittels einer Schlüsselerzeugungsfunktion eines quantensicheren Schlüsselkapselungsmechanismus ein asymmetrisches quantensicheres Schlüsselpaar mit einem quantensicheren öffentlichen Schlüssel und einem quantensicheren geheimen Schlüssel erzeugt wird. Anschließend wird eine Anforderungsnachricht an den Server gesendet, die mindestens den quantensicheren öffentlichen Schlüssel und die erste Nonce umfasst. Vom Server wird wiederum eine Antwortnachricht empfangen, die einen Geheimtext und eine zweite Nonce umfasst. Der Geheimtext wird mit einer Entkapselungsfunktion des quantensicheren Schlüsselkapselungsmechanismus unter Verwendung des geheimen quantensicheren Schlüssels entkapselt, wobei das Entkapseln ein gemeinsames Geheimnis ergibt. Damit können auch auf Client-Seite eine dritte und eine vierte Nonce unter Verwendung des gemeinsamen Geheimnisses gebildet werden, und schließlich hybride symmetrische Schlüssel aus der ersten Nonce, der zweiten Nonce, der dritten Nonce und der vierten Nonce unter Verwendung eines Combiners erzeugt werden.
Dabei kann bevorzugt die Antwortnachricht einen Nachrichten-Authentifizierungs-Code umfassen, so dass die erzeugten hybriden symmetrischen Schlüssel unter Verwendung des Nachrichten-Authentifizierungscodes validiert werden.
Das Erzeugen von hybriden symmetrischen Schlüsseln unter Verwendung eines Combiners in den vorstehenden Verfahren kann in einer beispielhaften Ausführungsform wie folgt ablaufen: Bilden von vorläufigen symmetrischen Schlüsseln durch Anwenden einer pseudozufälligen Funktion jeweils auf die erste und zweite Nonce sowie auf die dritte und vierte Nonce, wobei jede Nonce einmal als Startwert und einmal als Eingabewert für die jeweilige pseudozufällige Funktion gewählt wird; und Anwenden einer XOR-Funktion auf die gebildeten vorläufigen Schlüssel zum erhalten von hybriden symmetrischen Sitzungsschlüsseln. Durch die erweiterten pseudozufälligen Funktionen werden also vorläufige Schlüssel gebildet, die anschließend geeignet miteinander kombiniert werden.
Alternativ können zum Erzeugen von hybriden symmetrischen Schlüsseln unter Verwendung eines Combiners auch die folgenden Schritte genutzt werden: Anwenden einer XOR-Funktion auf die erste und die dritte Nonce zum Erhalten einer fünften Nonce, und Anwenden einer XOR-Funktion auf die zweite und die vierte Nonce zum Erhalten einer sechsten Nonce; und Bilden von hybriden symmetrischen Schlüsseln durch Anwenden von pseudozufälligen Funktionen auf die fünfte Nonce und die sechste Nonce. Damit wird die XOR-Funktion hier auf die Nonces statt auf die vorläufigen Schlüssel angewendet, so dass nur im letzten Schritt die neu erzeugten Nonces erweitert und gesplittet werden müssen. Insbesondere kann dabei die fünfte Nonce als Startwert und die sechste Nonce als Eingabewert für eine erste pseudozufällige Funktion gewählt werden, und die sechste Nonce als Startwert und die fünfte Nonce als Eingabewert für eine zweite pseudozufällige Funktion gewählt werden.
In einer weiteren beispielhaften Alternative zum Erzeugen von hybriden symmetrischen Schlüsseln unter Verwendung eines Combiners in den vorstehenden Verfahren können vorläufige symmetrische Schlüssel durch Anwenden einer pseudozufälligen Funktion jeweils auf die erste und zweite Nonce sowie auf die dritte und vierte Nonce gebildet werden, wobei jede Nonce einmal als Startwert und einmal als Eingabewert für die jeweilige pseudozufällige Funktion gewählt wird, und dann kryptographische Hashfunktionen auf die vorläufigen symmetrischen Schlüssel zum Bilden von hybriden symmetrischen Schlüsseln angewendet werden.
In den beispielhaften Teilverfahren zum Bilden hybrider Schlüssel kann der Ausgabewert jeder der pseudozufälligen Funktionen in zwei symmetrische Schlüssel und einen Initialisierungsvektor aufgeteilt werden, in Abhängigkeit von vorgegebenen Längenparametern für die Schlüssel und den Initialisierungsvektor. Die Länge kann beispielsweise in einer geeigneten Sicherheitsstruktur bzw. in ausgetauschten Grundeinstellungen vorgegeben sein. Falls weniger Schlüssel erzeugt werden, kann die Aufteilung der Ausgabewerte auch anders vorgenommen werden.
In einer Ausführungsform bildet die Antwortnachricht eine modifizierten Response-Nachricht für einen OpenSecureChannel-Handshake in einem OPC UA-Protokoll, und die Anforderungsnachricht bildet eine modifizierte Request-Nachricht für einen OpenSecureChannel-Handshake in einem OPC UA-Protokoll. Durch eine Erweiterung des bestehenden standardisierten Handshake-Verfahrens durch einen hybriden Schlüsselaustausch ohne Veränderung der ursprünglichen Handshake-Struktur wird ein quantensicheres Protokoll ermöglicht, das auch zur Kommunikation mit Endgeräten im OPC UA-Standard anwendbar ist, die keine dieser hier vorgestellten Verfahren unterstützen, so dass insbesondere für eine Übergangszeit bis zu vollständig quantensicheren Architekturen, Protokollen und Applikationen ausreichende Sicherheit geboten ist.
Da der OPC UA-Standard insbesondere auch auf Endgeräte mit begrenzten Ressourcen zielt, z.B. sogenannte Embedded Devices, kann damit auch für diese Geräte gerade im industriellen Umfeld ein sicheres Verfahren implementiert werden, ohne die Anforderungen an notwendige Ressourcen (z.B. Rechenzeit, Übertragungsgeschwindigkeit) massiv zu erhöhen. Es werden also erprobte, klassische Sicherheitsmechanismen genutzt, die in der hybriden Kombination dennoch Sicherheit gegen zukünftige Angriffe bieten.
Wenn die genannten Verfahren zum Austausch kryptographischer Schlüssel zur sicheren Kommunikation zwischen einem Server und einem Client in einem Netzwerk wie oben durchgeführt werden, sollen der Server und der Client denselben quantensicheren Schlüsselkapselungsmechanismus und denselben Combiner verwenden.
Die in diesem Handshake-Verfahren auf Server- und Client-Seite gebildeten symmetrischen Schlüssel können zur Verschlüsselung und/oder Signatur von Nachrichten in einer folgenden sicheren Kommunikationssitzung zwischen dem Server und dem Client verwendet werden.
Zusätzlich zu den genannten Schritten können die gesendeten Nachrichten, d.h. die Anforderungsnachricht und/oder die Antwortnachricht optional mittels weiterer asymmetrischer Schlüsselpaare verschlüsselt und/oder signiert sein, wobei die Verfahren dann weiter das Entschlüsseln der jeweiligen Nachricht und/oder das Verifizieren der Signatur der Nachricht umfasst.
Bevorzugt kann dabei der quantensichere Schlüssel in der Anforderungsnachricht bzw. der Geheimtext und/oder der Nachrichten-Authentifizierungscode in der Antwortnachricht im unverschlüsselten Sicherheitsheader der jeweiligen Nachricht untergebracht sein, so dass die zusätzlichen hybriden Elemente keinen erhöhten Aufwand bei der asymmetrischen Verschlüsselung mit sich bringen. Der Header kann dabei geeignete Felder für diese Elemente vorsehen.
Eine erfindungsgemäße Recheneinheit, z.B. ein kommunizierendes Endgerät in einer Client-Server-Architektur, ist, insbesondere programmtechnisch, dazu eingerichtet, ein erfindungsgemäßes Verfahren durchzuführen.
Auch die Implementierung eines erfindungsgemäßen Verfahrens in Form eines Computerprogramms oder Computerprogrammprodukts mit Programmcode zur Durchführung aller Verfahrensschritte ist vorteilhaft, da dies besonders geringe Kosten verursacht, insbesondere wenn ein ausführendes Endgerät noch für weitere Aufgaben genutzt wird und daher ohnehin vorhanden ist. Geeignete Datenträger zur Bereitstellung des Computerprogramms sind insbesondere magnetische, optische und elektrische Speicher, wie z.B. Festplatten, Flash-Speicher, EEPROMs, DVDs u.a.m. Auch ein Download eines Programms über Computernetze (Internet, Intranet usw.) ist möglich.
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und der beiliegenden Zeichnung.
Die Erfindung ist anhand von Ausführungsbeispielen in der Zeichnung schematisch dargestellt und wird im Folgenden unter Bezugnahme auf die Zeichnung beschrieben.
Figurenliste

1 zeigt ein Sequenzdiagramm für einen Handshake mit hybridem Schlüsselaustausch für ein modifiziertes OPC UA-Protokoll gemäß einer beispielhaften Ausführungsform.

Ausführungsform(en) der Erfindung
Um ein System, wie beispielsweise ein OPC UA-System mit begrenzten Ressourcen, gegen potentielle Angriffe unter Verwendung eines Quantencomputers zu schützen, können für den Schlüsselaustausch Hybridverfahren verwendet werden, so dass der kombinierte Schlüsselaustausch insgesamt sicher bleibt, solange eines der beiden verwendeten Verfahren sicher bleibt. Gemäß bevorzugten Ausführungsformen kann dabei als Grundlage das bisherige Sicherheitsprotokoll eines OPC UA-Systems verwendet werden und ein hybrides Schlüsselaustauschverfahren integriert werden.
Zu diesem Zweck kann ein Schlüsselkapselungsmechanismus (KEM, Key Encapsulation Mechanism) verwendet werden. Jeder Schlüsselkapselungsmechanismus umfasst die drei folgenden Funktionen, wobei jeweils der Eingangswert der Funktion in Klammern und der Ergebniswert hinter dem Doppelpunkt angegeben ist:

1. Die Erzeugung eines Schlüsselpaars, das aus einem öffentlichen Schlüssel pk_pq und einem geheimen Schlüssel sk_pq besteht, KeyGeneration(): sk_pq, pk_pq;
2. Die Kapselung, wobei ein zufälliges gemeinsames Geheimnis ss erzeugt wird, das dann unter Verwendung des öffentlichen Schlüssels pk_pq verschlüsselt wird, so dass man den verschlüsselten Geheimtext ct_pq erhält, Encapsulation(pk_pq): ct_pq, ss;
3. Die Entkapselungsfunktion bzw. Entfernung der Kapselung, wobei durch Entschlüsseln des Geheimtextes ct_pq unter Verwendung des geheimen Schlüssels sk_pq wiederum das gemeinsame Geheimnis ss erhalten wird, Decapsulation(ct_pq, sk_pq): ss

Um einen Kapselungsmechanismus in ein Kommunikationsprotokoll zu integrieren, muss dieser in einen Schlüsselaustauschalgorithmus umgewandelt werden.
Dabei bezeichnen hier und im Folgenden die mit dem Index „pq“ gekennzeichneten Elemente quantensichere (Post Quantum) Elemente, also z.B. das erzeugte quantensichere Schlüsselpaar aus geheimem Schlüssel sk_pq und öffentlichem Schlüssel pk_pq. Dieses kann unter Verwendung der Schlüsselerzeugungsfunktion eines quantensicheren Schlüsselkapselungsmechanismus, KEM, erzeugt werden. Dabei kann grundsätzlich jeder beliebige quantensichere Schlüsselkapselungsmechanismus eingesetzt werden; die hier beschriebenen beispielhaften Ausführungsformen sind nicht abhängig von der Wahl des Mechanismus.
Bei einem hybriden Schlüsselaustausch werden sogenannte Combiner für zwei Schlüssel-Kapselungs-Mechanismen bzw. Schlüsselerzeugungsmechanismen genutzt, mittels derer zwei gemeinsame Geheimnisse, die separat von den jeweiligen KEM erzeugt wurden, zu einem einzigen Satz von gemeinsamen geheimen Schlüsseln kombiniert werden. In den hier beschriebenen Ausführungsformen werden beispielhaft verschiedene Combiner genutzt, wobei in einer Ausführungsform ein XOR-then-MAC-Combiner verwendet werden kann und als Alternative beispielsweise eine kryptographisch sichere Hashfunktion zum Kombinieren der symmetrischen Schlüssel verwendet werden kann. Beide Alternativen werden nachstehend noch detaillierter beschrieben. Generell können beliebige geeignete Combiner eingesetzt werden.
1 zeigt einen Ausschnitt einer beispielhaften Ausführungsform eines Handshake-Verfahrens der Erfindung für den OPC UA-Standard. Dabei kann die bekannte Struktur zur Initialisierung eines sicheren Kanals mit dem OpenSecureChannel-Handshake-Verfahren und den verwendeten Nachrichten als Basis erhalten bleiben, aber um ein hybrides Schema erweitert werden. Insbesondere können dabei bevorzugt alle Schritte und Nachrichtenelemente des bisherigen standardgemäßen Handshakes erhalten bleiben. Auf der linken Seite in 1 sind die Verfahrensschritte auf Seite eines ersten Teilnehmers bzw. Clients 100 gezeigt, der die Anforderungsnachricht zum Aufbau eines sicheren Kanals versendet, während auf der rechten Seite ein zweiter Teilnehmer bzw. Server 200 dargestellt ist, der erhaltene Informationen verarbeitet und eine entsprechende Antwort an den Client 100 sendet. Die zwischen den beiden Teilnehmern 100, 200 gezeigten Pfeile stellen jeweils eine Datenübertragung in die angegebene Richtung dar.
Dabei versteht sich, dass die Begriffe Client und Server nur zur Beschreibung der ausgeführten Rollen dienen und den jeweiligen Kommunikationsteilnehmer bzw. das Endgerät an sich nicht einschränken. Insbesondere kann je nach Ausführungsform ein Endgerät auch beide Rollen in unterschiedlichen Verbindungen oder Diensten ausfüllen.
Die ersten Schritte zum Verbindungsaufbau und Zustellung des Server-Zertifikats sind im vorliegenden Beispiel nicht gezeigt und können wie üblich ausgeführt sein. Es wird also davon ausgegangen, dass dem Client 100 bereits ein validiertes Serverzertifikat vorliegt. Die Validierung des Zertifikats kann durch den Client 100 beispielsweise auch unter Einbindung einer vertrauenswürdigen Authentifizierungsstelle vorgenommen werden, die hier nicht gezeigt ist.
Der Client kann dann in Schritt 110 eine geheime Client-Nonce n_client bilden, sowie in Schritt 120 ein quantensicheres Schlüsselpaar aus einem öffentlichen und einem geheimen Schlüssel sk_pq, pk_pq unter Verwendung der Schlüsselerzeugungsfunktion eines quantenresistenten Schlüsselkapselungsmechanismus KEM erzeugen.
Im Folgenden werden einzelne Bestandteile beispielhafter Ausführungsformen als Algorithmen in der fachüblichen Form dargestellt. Es versteht sich jedoch, dass die Erfindung dabei nicht auf den jeweiligen exakten Algorithmus beschränkt ist und es sich nur um Beispiele zur Erläuterung handelt. Die einzelnen Schritte der beispielhaften Algorithmen werden im Folgenden zur eindeutigen Kennzeichnung nach dem Schema [Algorithmus].[Schritt] benannt, so dass beispielsweise Schritt 1.3 den 3. Schritt bzw. die 3. Zeile in Algorithmus 1 referenziert.
Algorithmus 1
Der gezeigte Algorithmus 1 beschreibt ein beispielhaftes Verfahren zum Erzeugen einer Anforderungsnachricht zum Initialisieren eines sicheren Kanals auf Seite eines ersten Teilnehmers, z.B. des Clients, als Erweiterung des üblichen OpenSecureChannel-Requests im OPC UA-Standard, entsprechend den Schritten 110 und 120 in 1. Dabei werden die Bestandteile des herkömmlichen OpenSecureChannel-Request übernommen und durch weitere Elemente erweitert. Zeile 1.1 zeigt den Aufruf der Prozedur zum Erzeugen der Anforderung unter Verwendung eines öffentlichen Schlüssels des Servers pk_server, der in dieser Ausführungsform zum Verschlüsseln der Anforderungsnachricht verwendet wird. Zeile 1.2 entspricht der Erzeugung einer lokalen Client-Nonce wie im herkömmlichen OpenSecureChannel-Request, beispielsweise durch Erzeugung einer kryptographisch sicheren Zufallszahl. In Schritt 1.3 bzw. 120 wird dann das quantensichere Schlüsselpaar sk_pq, pk_pq erzeugt. Aus der Client-Nonce n_client, dem zusätzlichen öffentlichen quantensicheren Schlüssel pk_pq und weiteren Einstellungen kann dann in Schritt 1.4 die Anforderungsnachricht gebildet werden. Dabei kann der quantensichere öffentliche Schlüssel zur Vereinfachung auch im Nachrichtenheader statt im Nachrichtentext untergebracht werden, da so rechenaufwändige asymmetrische Verschlüsselung vermieden wird. Zeile 1.5 beschreibt das Verschlüsseln und Signieren der so gebildeten Anforderungsnachricht gemäß vorgegebenen Sicherheitseinstellungen, die in vorhergehenden nicht gezeigten Schritten ausgetauscht wurden. Wie bereits beschrieben, kann der öffentliche Server-Schlüssel pk_server für die Verschlüsselung der Anforderungsnachricht genutzt werden, und anschließend kann die verschlüsselte Anforderungsnachricht mit einem geheimen Client-Schlüssel sk_client signiert werden. Schließlich wird in den Schritten 1.6 und 1.7 die verschlüsselte und signierte Anforderungsnachricht vom Client 100 an den Server 200 gesendet, beispielsweise entsprechend dem OPC UA-Nachrichten-Standard.
Algorithmus 2 beschreibt eine Ausführungsform eines komplementären Verfahrens zum Verarbeiten der in Algorithmus 1 gebildeten Anforderungsnachricht durch den empfangenden Server.
Sobald der Server die Anforderungsnachricht empfangen hat, kann er das Client-Zertifikat in Schritt 210 aus 1 bzw. in Zeile 2.2 validieren. Falls das Zertifikat nicht gültig ist, dann kann eine entsprechende Fehlermeldung ausgegeben werden. Erneut kann auch zur Validierung des Client-Zertifikats eine Authentifizierungsstelle eingebunden sein, an die eine entsprechende Nachricht gesendet wird.
Anschließend wird die Anforderungsnachricht in Zeile 2.4 und Schritt 220 abhängig von den angegebenen Sicherheitsregeln entschlüsselt, im vorliegenden Beispiel durch Anwendung des geheimen Server-Schlüssels sk_server, der zu dem Server-Schlüsselpaar gehört, dessen öffentlicher Schlüssel pk_server auf Client-Seite zur Verschlüsselung genutzt wurde. Ebenso kann eine vorhandene Signatur verifiziert werden, also passend zur Signatur in Schritt 1.5 durch Verwendung des öffentlichen Client-Schlüssels pk_client.
Zeile 2.7 bzw. Schritt 230 in 1 zeigt die Erzeugung einer weiteren kryptographischen Zufallszahl als Server-Nonce n_server.
Weiter wird in Schritt 240 bzw. Zeile 2.8 die Kapselungsfunktion des verwendeten quantensicheren Schlüssel-Kapselungsmechanismus aufgerufen, wobei der in der Anforderungsnachricht erhaltene öffentliche quantensichere Schlüssel pk_pq als Eingabewert verwendet wird. Diese Funktion kann daraus einen Geheimtext ct_pq und ein gemeinsames quantensicheres Geheimnis ss bilden, z.B. mit 32 Byte Länge.
Da im vorgegebenen OPC UA-Handshake zur Erzeugung diverser kryptographischer Schlüssel jeweils Nonces auf Server- und Client-Seite benötigt werden, kann im vorliegenden Beispiel eine zusätzliche pseudozufällige Funktion (PRF) verwendet werden, um aus dem in Schritt 240 gebildeten gemeinsamen Geheimnis ss weitere Nonce-Werte zu gewinnen. Diese Funktion wird in Zeile 2.9 bzw. Schritt 250 durch den Server aufgerufen. Als Eingangswerte für die pseudozufällige Funktion PRF können das gemeinsame Geheimnis ss sowie ein geeignetes Salt genutzt werden. Dabei kann als Salt hier beispielsweise ein Wert genutzt werden, der aus dem empfangenen quantensicheren öffentlichen Schlüssel pk_pq, statischen Serverinformationen und statischen Client-Informationen zusammengesetzt ist.
Damit werden gemäß Zeile 2.9 zwei weitere zufällige gemeinsame Geheimnisse erzeugt, beispielsweise mit jeweils 32 bytes, die zwei weiteren Nonces entsprechen, nämlich einer weiteren Server-Nonce n_pq,server und einer weiteren Client-Nonce n_pq,client. Die angewendeten pseudozufälligen Funktionen können beispielsweise intern Hashfunktionen wie SHA-256 verwenden, die eine ausreichende Länge aufweisen (in diesem Fall 256 bit), um Sicherheit gegen Quantencomputer-Angriffe zu bieten. Diese werden so oft iteriert, bis die notwendige Länge der Schlüssel bzw. Nonces erreicht ist. Insgesamt liegen also nun vier Nonces vor, die zur Schlüsselerzeugung genutzt werden können.
Alle Nonces können dann in Schritt 2.10 miteinander verkettet und in Schritt 2.11 bzw. 260 als Eingangswert für eine hybride Schlüssel-Erzeugungs-Funktion genutzt werden, die zur Bildung der symmetrischen Sitzungsschlüssel vorgesehen ist. Dies kann in einer beispielhaften Ausführungsform erreicht werden, indem die Nonces durch pseudozufällige Funktionen PRFs erweitert werden und dann auf die jeweiligen vorläufigen Schlüssel, die damit erzeugt werden, ein exklusives Oder (XOR) angewendet wird. Damit werden letztendlich hybride symmetrische Schlüssel erzeugt. Diese hybriden symmetrischen Sitzungsschlüssel dienen nach erfolgreicher Beendigung des Handshakes zur beidseitigen Verschlüsselung und Signatur der folgenden Nachrichten einer Sitzung. Dabei können beispielsweise für den Client und den Server jeweils ein Schlüssel zur Verschlüsselung und ein Schlüssel zur Signierung erstellt werden, so dass vier symmetrische Schlüssel k_sig,client, k_enc,client, k_sig,server und k_enc,Server erzeugt werden. Außerdem können auch Initialisierungsvektoren IV für jeden Teilnehmer erzeugt werden.
Nachdem die symmetrischen Sitzungsschlüssel erzeugt wurden, kann in Zeile 2.12 bzw. Schritt 270 durch den Server eine Message Authentication Code (MAC)-Funktion auf den zuvor durch die Kapselung erzeugten Geheimtext ct_pq sowie auf die ursprünglichen Client- und Server-Nonces n_client, n_server angewendet werden, wobei einer der erzeugten symmetrischen Sitzungsschlüssel, z.B. der erzeugte Signatur-Schlüssel des Servers, als Schlüssel k_MAC verwendet wird. Die grundsätzliche Funktionsweise einer MAC-Funktion, bei der aus zwei Eingabewerten, nämlich der zu schützenden Nachricht sowie einem geheimen Schlüssel, ein Authentifizierungscode in Form einer Prüfsumme gebildet wird, ist im Fach bekannt und wird hier nicht weiter ausgeführt.
Es handelt sich bei dieser Ausführungsform um die Integration eines XOR-then-MAC-Combiners als Grundlage für die Erzeugung der symmetrischen Sitzungsschlüssel. Diese hybride symmetrische Schlüsselerzeugung und auch alternative Verfahren zur Erzeugung der symmetrischen Sitzungsschlüssel werden im Folgenden mit Bezug auf die Algorithmen 4 bis 6 noch genauer erläutert.
Schließlich wird die Verarbeitung der Anforderungsnachricht abgeschlossen, indem eine entsprechende Antwortnachricht in Zeile 2.13 gebildet und versendet wird. Diese Antwortnachricht umfasst die Server-Nonce n_server, den bei der Kapselung erzeugten Geheimtext ct_pq, den Nachrichtenauthentifizierungscode MAC sowie eine aktualisierte Lebensdauer für das Sicherheitstoken, welche die Länge der folgenden Sitzung wiedergibt. Die so erzeugte Antwortnachricht kann wiederum gemäß Zeile 2.14 unter Verwendung des öffentlichen Schlüssels des Clients, pk_client, verschlüsselt und unter Verwendung des geheimen Schlüssels des Servers, sk_server, signiert werden, so dass eine verschlüsselte Antwortnachricht ct_resp mit entsprechender Signatur sig_resp erhalten wird. Ähnlich wie in der Anforderungsnachricht können der Geheimtext ct_pq sowie der MAC im Header der OPC UA-Antwort-Nachricht eingefügt werden, um den Rechenaufwand gering zu halten, der durch die asymmetrische Verschlüsselung des Nachrichtentextes und des Paddings hervorgerufen wird. Die Server-Nonce n_server befindet sich mit der Lebensdauer des Sicherheitstokens bevorzugt im Nachrichtentext selbst. Die so erzeugte verschlüsselte und signierte Antwortnachricht kann dann wie in Zeile 2.15 und 2.16 an den Client versendet werden.
Es versteht sich, dass die in Algorithmus 2 gezeigten Schritte bzw. die Schritte 210 bis 270 vom Server ausgeführt werden.
Algorithmus 3 beschreibt die Verarbeitung der vom Server gesendeten Antwortnachricht auf Seite des Clients gemäß einer möglichen Ausführungsform, wie sie in 1 durch die Schritte 130 bis 170 dargestellt ist.
In Schritt 130 bzw. Zeile 3.2 wird die empfangene Antwortnachricht zunächst entschlüsselt und ihre Signatur verifiziert. Falls die Signatur nicht verifiziert werden kann, kann wieder eine Fehlermeldung ausgegeben werden (Zeile 3.3).
Nach dem Entschlüsseln liegt dem Client in Zeile 3.5 damit der Geheimtext ct_pq, der Nachrichtenauthentifizierungscode MAC sowie die Server-Nonce n_server vor. Der Geheimtext ct_pq kann dann in Schritt 140 bzw. Zeile 3.6 zusammen mit dem geheimen quantensicheren Schlüssel sk_pq, der zuvor in Schritt 120 erzeugt wurde, in die Entkapselungsfunktion des verwendeten quantensicheren Schlüssel-Kapselungs-Mechanismus KEM eingesetzt werden. Die Entfernung der Kapselung ergibt wieder das gemeinsame Geheimnis ss.
Entsprechend wie beim Verarbeiten der Anforderungsnachricht auf Serverseite (siehe Schritt 250 in 1) kann dieses gemeinsame Geheimnis ss in Schritt 150 bzw. Zeile 3.7 wieder erweitert werden, um erneut zwei zusätzliche Nonces n_pq,server und n_pq,client zu erzeugen. Dafür muss dieselbe pseudozufällige Funktion wie in Zeile 2.9 des Algorithmus 2 auf Serverseite verwendet werden, d.h. als Eingangswerte werden das gemeinsame Geheimnis ss sowie ein geeignetes Salt verwendet, wobei auch das Salt auf dieselbe Weise wie auf der Server-Seite aus dem quantensicheren Schlüssel sowie statischen Informationen gebildet werden kann.
Aus den so erhaltenen vier Nonces n_server, n_client, n_pq,server, n_pq,client (Zeile 3.8) können in Schritt 160 bzw. Zeile 3.9 die hybriden symmetrischen Sitzungsschlüssel erzeugt werden. Es wird auch hier auf die detaillierte Erläuterung zur kombinierten Schlüsselerzeugung gemäß den Algorithmen 4 bis 6 verwiesen. Dabei sollte auf Server- und Clientseite derselbe hybride Combiner zur Schlüsselerzeugung verwendet werden.
Nach der Erzeugung der symmetrischen Schlüssel kann nun in Schritt 170 bzw. Zeile 3.10 der empfangene Nachrichtenauthentizifierungscode MAC auf übliche Weise verifiziert werden, indem der empfangene Geheimtext ct_pq, die ursprünglichen Client- und Server-Nonces n_client und n_server, und der erzeugte symmetrische Signatur-Schlüssel k'_MAC verwendet werden.
Im Folgenden werden mit den drei Algorithmen 4, 5 und 6 drei mögliche Alternativen für die Erzeugung der symmetrischen Sitzungsschlüssel, die in den Schritten 160 auf Client-Seite und 260 auf Server-Seite stattfindet, als Beispiele erläutert. Diese entsprechen der Funktion GenerateKeys, die in Zeile 2.11 des Algorithmus 2 bzw. Zeile 3.9 des Algorithmus 3 aufgerufen werden. Es sind jedoch auch andere hybride Combiner und damit andere Schlüsselerzeugungsfunktionen in Verbindung mit den hier beschriebenen Ausführungsformen einsetzbar.
Da diese folgenden Algorithmen zur symmetrischen Schlüsselerzeugung sowohl auf Server- als auch auf Client-Seite gleichwertig aufgerufen werden können, wird hier die Angabe von dient und server für die Variablen jeweils durch die Angaben remote (entfernt) und local (lokal) ersetzt. Wenn die Schlüsselerzeugung der Algorithmen 4 bis 6 also auf Serverseite durchgeführt wird, dann entspricht eine Variable mit der Angabe „local“ der serverseitigen Variable, während „remote“ der Client-Variable entspricht; wenn die Schlüsselerzeugung im Client angewendet wird, entspricht die Angabe „local“ der clientseitigen Variable, während „remote“ der Server-Variable entspricht.
Alle beispielhaften Algorithmen zur Schlüsselerzeugung erzeugen für jede Seite (d.h. für Client und Server) jeweils zwei kryptographische Schlüssel, die anschließend während der sicheren Sitzung zur Verschlüsselung und Signatur von Nachrichten verwendet werden können, sowie je einen Initialisierungsvektor IV.
Dazu muss zunächst in Schritten 4.2 und 4.3 in Algorithmus 4 die gewünschte Länge aller zu erzeugenden symmetrischen Schlüssel festgelegt bzw. aus einer entsprechenden Sicherheitsrichtlinie gewonnen werden. Da die Schlüssel aus dem Aufspalten von Ergebniswerten erhalten werden können, wird sowohl die Länge der einzelnen Schlüssel (einschließlich des Initialisierungsvektors) als auch die Gesamtlänge aller Schlüssel als Summe der Einzelschlüssel festgelegt.
In Schritt 4.4 werden die vorhandenen vier Nonces abhängig von ihrer Zugehörigkeit (z.B. Client/Server) und ihrer Erzeugung (klassisch oder quantensicher/post-quantum) geordnet. Anschließend werden in den Schritten 4.5 bis 4.8 diese Nonces als Eingangswerte für pseudozufällige Funktionen PRF verwendet, welche die Länge der vorliegenden Nonces (z.B. 32 Byte) auf die gewünschte Gesamtlänge des kryptographischen Materials erweitert, d.h. der beiden Schlüssel und des Initialisierungsvektors (z.B. 80 Byte).
In den Zeilen 4.5 und 4.6 werden die klassischen (ersten und zweiten) Nonces n_local und n_remote verwendet, also entsprechend den Client- und Server-Nonces n_client, n_server der vorhergehenden Algorithmen 1 bis 3. Dabei wird im ersten Aufruf in Zeile 4.5 die lokale Nonce als Startwert bzw. Seed verwendet und die entfernte Nonce als geheimer Eingangswert. Im zweiten Aufruf werden die beiden Nonces vertauscht.
Der Ausgabewert der pseudozufälligen Funktionen wird entsprechend der angegebenen Längen für die Schlüssel und den Initialisierungsvektor dreigeteilt und bildet so jeweils ein lokales und ein entferntes vorläufiges Schlüsselpaar mit je einem Schlüssel zur Signierung und zur Verschlüsselung von Nachrichten sowie jeweils einem Initialisierungsvektor.
Um ein hybrides Verfahren zu erreichen, müssen die pseudozufälligen Funktionen zwei zusätzliche Male aufgerufen werden; Zeilen 4.7 und 4.8 zeigen die Nutzung der quantensicheren Nonces, wobei erneut jede der beiden Nonces einmal als Startwert und einmal als Eingangswert verwendet wird und die Ausgabewerte wieder in je zwei Schlüssel und einen Initialisierungsvektor aufgeteilt werden.
Auf diese Weise können acht symmetrische vorläufige Schlüssel und vier Initialisierungsvektoren mit jeweils gleicher Länge erzeugt werden, wobei die Erzeugung der klassischen und der quantensicheren Schlüssel separat erfolgt ist. Daher wird nun zur Bildung der kombinierten hybriden Schlüssel ein Combiner angewendet. In dem Verfahren aus Algorithmus 4 ist ein XOR-then-MAC-Combiner vorgesehen. Auf die erzeugten Schlüssel wird daher in den Schritten 4.9 bis 4.14 eine XOR-Funktion (exclusive OR, exklusives Oder) angewendet, so dass für jeden Schlüssel der klassische und der quantensichere Schlüssel kombiniert werden und die endgültigen hybriden Schlüssel und Initialisierungsvektoren erzeugt werden, nämlich ein lokaler hybrider Signatur-Schlüssel k_sig,local (Zeile 4.9), ein lokaler hybrider Verschlüsselungs-Schlüssel k_enc,local (Zeile 4.10), ein lokaler Initialisierungsvektor IV_local (Zeile 4.11), ein entfernter hybrider Signatur-Schlüssel k_sig,remote (Zeile 4.12), ein entfernter hybrider Verschlüsselungs-Schlüssel k_enc,remote (Zeile 4.13), und ein entfernter Initialisierungsvektor IV_remote (Zeile 4.14).
Zur weiteren Verarbeitung und zum Abschluss des XOR-then-MAC-Combiners folgt die Anwendung der MAC-Funktion in Schritt 3.12 aus Algorithmus 3, wobei der soeben in Schritt 4.9 erzeugte lokale Signaturschlüssel k_sig,local als MAC-Schlüssel k_MAC verwendet werden kann. Die Anwendung der MAC-Funktion schützt den Geheimtext ct_pq vor Modifikationen. Wenn also auf Client-Seite mit Hilfe des empfangenen Nachrichtenauthentifizierungscode MAC die Schlüssel erfolgreich verifiziert werden können, können sie in der folgenden sicheren Sitzung zur Verschlüsselung und Signatur von Nachrichten angewendet werden.
In einer alternativen Ausführungsform wird die Erzeugung hybrider symmetrischer Schlüssel gemäß Algorithmus 4 durch eine andere beispielhafte Schlüsselerzeugungsfunktion ersetzt, die mit Bezug auf Algorithmus 5 erläutert wird.
Hier wird eine XOR-Funktion nicht wie im vorherigen Beispiel auf die erzeugten vorläufigen Schlüssel, sondern direkt auf die verwendeten Nonces angewendet. Die erzeugten Noncen werden dann wieder über pseudozufällige Funktionen zur Erzeugung der symmetrischen Schlüssel verwendet. Dabei ist in den Zeilen 5.2 und 5.3 erneut die Festlegung der Längen für Signaturschlüssel, Verschlüsselungsschlüssel und Initialisierungsvektor sowie die Gesamtlänge aller Schlüssel gezeigt. Auch die Einordnung der Nonces findet wie in Algorithmus 4 statt.
In Schritt 5.5 wird dann die entfernte Nonce und ihre quantensichere Entsprechung über eine XOR-Funktion zu einer endgültigen entfernten Nonce kombiniert. Schritt 5.6 beschreibt dasselbe Verfahren für die beiden lokalen Nonces.
Damit liegen also nur noch zwei endgültige Nonces vor, die dann in zwei Aufrufen in den Schritten 5.7 und 5.8 einer pseudozufälligen Funktion verwendet werden, wobei jede Nonce einmal als Startwert bzw. Seed und einmal als Eingangswert bzw. Input. Als Ausgabe erzeugen die pseudozufälligen Funktionen erneut kryptographisches Material in der vorgegebenen Gesamtlänge der Schlüssel, das dann in jeweils zwei Schlüssel und einen Initialisierungsvektor entsprechend der einzelnen Längenvorgaben aufgeteilt wird. Damit werden in Zeile 9 erneut zwei Signatur-Schlüssel, zwei Verschlüsselungs-Schlüssel und zwei Initialisierungsvektoren, jeweils ein Schlüssel bzw. Vektor für jeden Teilnehmer, erzeugt, die im folgenden als Sitzungsschlüssel für die gesicherte Kommunikation verwendet werden können.
Ebenso kann nach dieser Erzeugung der symmetrischen Schlüssel wie in Algorithmus 2 dargestellt nun auf Serverseite noch eine MAC-Funktion angewendet werden und entsprechende Antwortnachricht an den Client gesendet werden, bzw. auf Clientseite eine Überprüfung der Schlüssel auf Basis eines empfangenen MAC stattfinden.
Eine weitere Möglichkeit zur hybriden Erzeugung der symmetrischen Schlüssel ist in Algorithmus 6 dargestellt.
Anstelle einer XOR-Funktion wie in den Algorithmen 4 und 5 werden in diesem Beispiel kryptographisch sichere Hashfunktionen angewendet. Die vorläufigen Schlüssel können so wie in Algorithmus 4 aus den Nonces erzeugt werden, doch anschließend können die vorläufigen Schlüssel verkettet werden und als Eingangswert für kryptographische Hash-Funktionen wie etwa SHA-256 verwendet werden. Aufgrund der Eigenschaften solcher Hash-Funktionen, wie etwa die Tatsache, dass es sich um Einwegfunktionen mit hoher Kollisionsresistenz handelt, kann ein Angreifer selbst bei Verwendung von Quantencomputern den Eingang nicht ändern, ohne auch den Digest zu ändern.
In Algorithmus 6 sind also die Zeilen 6.1 bis 6. 8 identisch zu den entsprechenden Zeilen in Algorithmus 4 bis zur Erzeugung der vorläufigen Schlüssel, so dass diese Schritte nicht erneut beschrieben werden. Die Zeilen 6.9 bis 6.14 zeigen dann die separate Anwendung von Hashfunktionen auf jeweils einen vorläufigen Schlüssel und sein vorläufiges quantensicheres Pendant, also z.B. auf die vorläufigen lokalen Signaturschlüssel k_Sig,l und k_sig,l,pq in Zeile 6.9. Ebenso wird mit den übrigen Schlüsseln und Initialisierungswerten verfahren, so dass erneut die vier Schlüssel und zwei Initialisierungsvektoren als symmetrische Sitzungsschlüssel entstehen.
Wie auch in den Beispielen 4 und 5 kann dann optional eine MAC-Funktion zur Authentifizierung der gewonnenen Schlüssel angewendet werden.
Während vorstehend die einzelnen Verfahrensschritte so ausgelegt wurden, dass sie dem OPC UA-Protokoll vollständig entsprechen und damit als hybride Erweiterung der bekannten Protokollnachrichten eingesetzt werden können, versteht es sich, dass grundsätzlich auch nicht-wesentliche Verfahrensschritte wie z.B. die Signatur-Schritte von Client und Server ausgelassen werden könnten, wenn ein derartiges hybrides Schlüsselaustausch-Verfahren in einer anderen Umgebung angewendet wird. Ebenso könnten z.B. Nonces auf andere Weise gebildet werden als hier dargestellt, oder andere Funktionen zur Schlüsselerzeugung und/oder als Combiner genutzt werden.
Wie bereits festgehalten wurde, können die Ausführungsformen der Erfindung mit jedem ausreichend quantensicheren Schlüsselkapselungsmechanismus KEM verwendet werden; als Beispiele für potentielle Kandidaten seien die derzeit entwickelten KEM-Protokolle NewHope, NTRU-HRSS und Kyber genannt, deren Details im Fach bekannt sind. Da die gegenüber dem herkömmlichen OPC UA-Standard hinzugefügten Merkmale wie der Geheimtext und die quantensicheren Schlüssel jeweils bevorzugt in den (unverschlüsselten) Header der Handshake-Nachrichten eingefügt werden, wird kein erhöhter Rechenaufwand für die asymmetrische Verschlüsselung an sich notwendig, auch wenn die Nachrichtengröße sich verändert.

Claims

Verfahren, in einem Server (200), zum Austausch kryptographischer Schlüssel zur quantensicheren Kommunikation zwischen dem Server (200) und einem Client (100), umfassend: Empfangen, von einem Client (100), einer Anforderungsnachricht für einen sicheren Kommunikationskanal, wobei die Anforderungsnachricht mindestens einen quantensicheren öffentlichen Schlüssel und eine erste Nonce umfasst, wobei der quantensichere öffentliche Schlüssel Teil eines Schlüsselpaars ist, das mittels einer Schlüsselerzeugungsfunktion eines quantensicheren Schlüsselkapselungsmechanismus gebildet wurde; Erzeugen (230) einer zweiten Nonce; Kapseln (240) des quantensicheren öffentlichen Schlüssels mit einer Kapselungsfunktion des quantensicheren Schlüsselkapselungsmechanismus, wobei das Kapseln einen Geheimtext sowie ein gemeinsames Geheimnis erzeugt; Erzeugen (250) einer dritten und einer vierten Nonce unter Verwendung des erzeugten gemeinsamen Geheimnisses; Erzeugen (260) von hybriden symmetrischen Schlüsseln aus der ersten Nonce, der zweiten Nonce, der dritten Nonce und der vierten Nonce unter Verwendung eines Combiners, Senden einer Antwortnachricht (280) an den Client, wobei die Antwortnachricht mindestens den erzeugten Geheimtext und die zweite Nonce umfasst.
Verfahren nach Anspruch 1, weiter umfassend: Anwenden (270) einer MAC-Funktion auf den Geheimtext, die erste und die zweite Nonce, zum Bilden eines Nachrichten-Authentifizierungs-Codes, wobei die MAC-Funktion einen der erzeugten hybriden symmetrischen Schlüssel verwendet; und wobei die Antwortnachricht (280) an den Client zusätzlich den gebildeten Nachrichten-Authentifizierungs-Code umfasst.
Verfahren, in einem Client (100), zum Austausch kryptographischer Schlüssel zur quantensicheren Kommunikation zwischen dem Client (100) und einem Server (200), umfassend: Erzeugen (110) einer ersten Nonce; Bilden (120), mittels einer Schlüsselerzeugungsfunktion eines quantensicheren Schlüsselkapselungsmechanismus, eines asymmetrischen quantensicheren Schlüsselpaars mit einem quantensicheren öffentlichen Schlüssel und einem quantensicheren geheimen Schlüssel; Senden einer Anforderungsnachricht (180) an den Server, wobei die Anforderungsnachricht mindestens den quantensicheren öffentlichen Schlüssel und die erste Nonce umfasst; Empfangen, von dem Server, einer Antwortnachricht (280), die einen Geheimtext und eine zweite Nonce umfasst; Entkapseln (140) des empfangenen Geheimtextes mit einer Entkapselungsfunktion des quantensicheren Schlüsselkapselungsmechanismus unter Verwendung des geheimen quantensicheren Schlüssels, wobei das Entkapsein ein gemeinsames Geheimnis ergibt; Erzeugen (150) einer dritten und einer vierten Nonce unter Verwendung des gemeinsamen Geheimnisses; und Erzeugen (160) von hybriden symmetrischen Schlüsseln aus der ersten Nonce, der zweiten Nonce, der dritten Nonce und der vierten Nonce unter Verwendung eines Combiners.
Verfahren nach Anspruch 3, wobei die Antwortnachricht (280) einen Nachrichten-Authentifizierungs-Code umfasst, und wobei das Verfahren weiter das Validieren (170) der erzeugten hybriden symmetrischen Schlüssel unter Verwendung des Nachrichten-Authentifizierungscodes umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Erzeugen von hybriden symmetrischen Schlüsseln (160, 260) unter Verwendung eines Combiners die folgenden Schritte umfasst: Bilden von vorläufigen symmetrischen Schlüsseln durch Anwenden einer pseudozufälligen Funktion jeweils auf die erste und zweite Nonce sowie auf die dritte und vierte Nonce, wobei jede Nonce einmal als Startwert und einmal als Eingabewert für die jeweilige pseudozufällige Funktion gewählt wird; und Anwenden einer XOR-Funktion auf die gebildeten vorläufigen Schlüssel zum erhalten von hybriden symmetrischen Sitzungsschlüsseln.
Verfahren nach einem der Ansprüche 1 bis 4, wobei das Erzeugen von hybriden symmetrischen Schlüsseln (160, 260) unter Verwendung eines Combiners die folgenden Schritte umfasst: Anwenden einer XOR-Funktion auf die erste und die dritte Nonce zum Erhalten einer fünften Nonce, und Anwenden einer XOR-Funktion auf die zweite und die vierte Nonce zum Erhalten einer sechsten Nonce; und Bilden von hybriden symmetrischen Schlüsseln durch Anwenden von pseudozufälligen Funktionen auf die fünfte Nonce und die sechste Nonce.
Verfahren nach Anspruch 6, wobei die fünfte Nonce als Startwert und die sechste Nonce als Eingabewert für eine erste pseudozufällige Funktion gewählt wird, und wobei die sechste Nonce als Startwert und die fünfte Nonce als Eingabewert für eine zweite pseudozufällige Funktion gewählt wird.
Verfahren nach einem der Ansprüche 1 bis 4, wobei das Erzeugen von hybriden symmetrischen Schlüsseln (160, 260) unter Verwendung eines Combiners die folgenden Schritte umfasst: Bilden von vorläufigen symmetrischen Schlüsseln durch Anwenden einer pseudozufälligen Funktion jeweils auf die erste und zweite Nonce sowie auf die dritte und vierte Nonce, wobei jede Nonce einmal als Startwert und einmal als Eingabewert für die jeweilige pseudozufällige Funktion gewählt wird; und Anwenden von kryptographischen Hashfunktionen auf die vorläufigen symmetrischen Schlüssel zum Bilden von hybriden symmetrischen Schlüsseln.
Verfahren nach einem der Ansprüche 5 bis 8, wobei der Ausgabewert jeder der pseudozufälligen Funktionen in zwei symmetrische Schlüssel und einen Initialisierungsvektor aufgeteilt wird, in Abhängigkeit von vorgegebenen Längenparametern für die Schlüssel und den Initialisierungsvektor.
Verfahren nach einem der vorhergehenden Ansprüche wobei die Antwortnachricht eine modifizierte Response-Nachricht für einen OpenSecureChannel-Handshake in einem OPC UA-Protokoll bildet, und wobei die Anforderungsnachricht eine modifizierte Request-Nachricht für einen OpenSecureChannel-Handshake in einem OPC UA-Protokoll bildet.
Verfahren zum Austausch kryptographischer Schlüssel zur sicheren Kommunikation zwischen einem Server und einem Client in einem Netzwerk nach einem der vorhergehenden Ansprüche, wobei der Server und der Client denselben quantensicheren Schlüsselkapselungsmechanismus und denselben Combiner verwenden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die hybriden symmetrischen Schlüssel zur Verschlüsselung und/oder Signatur von Nachrichten in einer folgenden sicheren Kommunikationssitzung zwischen dem Server und dem Client verwendet werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Anforderungsnachricht und/oder die Antwortnachricht mittels asymmetrischer Schlüsselpaare verschlüsselt und/oder signiert ist, und wobei das Verfahren weiter das Entschlüsseln der Nachricht und/oder das Verifizieren der Signatur der Nachricht (220, 130) umfasst.
Recheneinheit (100, 200), die dazu eingerichtet ist, alle Verfahrensschritte eines Verfahrens nach einem der vorstehenden Ansprüche durchzuführen.
Computerprogramm, das eine Recheneinheit dazu veranlasst, alle Verfahrensschritte eines Verfahrens nach einem der Ansprüche 1 bis 13 durchzuführen, wenn es auf der Recheneinheit ausgeführt wird.
Maschinenlesbares Speichermedium mit einem darauf gespeicherten Computerprogramm nach Anspruch 15.