DE112020006159T5 - Protokoll zur gegenseitigen authentifizierung für systeme mit kommunikationsverbindungen mit niedrigem durchsatz und vorrichtungen zum durchführen desselben - Google Patents

Protokoll zur gegenseitigen authentifizierung für systeme mit kommunikationsverbindungen mit niedrigem durchsatz und vorrichtungen zum durchführen desselben Download PDF

Info

Publication number
DE112020006159T5
DE112020006159T5 DE112020006159.0T DE112020006159T DE112020006159T5 DE 112020006159 T5 DE112020006159 T5 DE 112020006159T5 DE 112020006159 T DE112020006159 T DE 112020006159T DE 112020006159 T5 DE112020006159 T5 DE 112020006159T5
Authority
DE
Germany
Prior art keywords
signed
device certificate
message
party
certificate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112020006159.0T
Other languages
English (en)
Inventor
Paolo Trere
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microchip Technology Inc
Original Assignee
Microchip Technology Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microchip Technology Inc filed Critical Microchip Technology Inc
Publication of DE112020006159T5 publication Critical patent/DE112020006159T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • H04L63/1466Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H04L9/16Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms the keys or algorithms being changed during operation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50Secure pairing of devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Erörtert werden ein Protokoll zur gegenseitigen Authentifizierung und Systeme, Verfahren und Vorrichtungen, die dasselbe implementieren. Ein solches Protokoll kann als ein nicht einschränkendes Beispiel durch Vorrichtungen, die durch Verbindungen mit niedrigem Durchsatz gekoppelt sind, zur schnellen Authentifizierung verwendet werden, um eine sichere Kommunikationssitzung herzustellen.

Description

  • QUERVERWEIS AUF VERWANDTE ANMELDUNG
  • Diese Patentanmeldung beansprucht die Priorität der am 17. Dezember 2019 eingereichten vorläufigen US-Patentanmeldung Nr. 62/948.951 mit dem Titel „MUTUAL AUTHENTICATION PROTOCOL FOR SYSTEMS WITH LOW-THROUGHPUT COMMUNICATION LINKS AND DEVICES FOR PERFORMING THE SAME“, wobei die gesamte Offenbarung hiermit durch diese Bezugnahme hierin aufgenommen wird.
  • PATENTBEREICH
  • Hierin erörterte Ausführungsformen beziehen sich allgemein auf eine Authentifizierung zwischen Vorrichtungen. Genauer beziehen sich einige Ausführungsformen auf Protokolle zur gegenseitigen Authentifizierung zwischen Vorrichtungen unter Verwendung von Techniken öffentlicher/privater Schlüssel.
  • STAND DER TECHNIK
  • Gegenseitige Authentifizierung bezieht sich auf einen Prozess, durch den sich zwei Parteien im Wesentlichen gleichzeitig gegenseitig authentifizieren. Eine gegenseitige Authentifizierung wird üblicherweise verwendet, sodass zwei Parteien an einer Aktivität teilnehmen können, bei der Vertrauen wichtig ist, wie einer Kommunikation oder Zusammenarbeit zwischen zwei Rechenvorrichtungen (z. B. mobilen Vorrichtungen, am Körper tragbaren Vorrichtungen, Autos, Steuerungen, Infrastrukturvorrichtungen, medizinischen Vorrichtungen, Servern und Server-Clients, ohne darauf beschränkt zu sein). Spezifische Regeln zum Durchführen einer gegenseitigen Authentifizierung sind üblicherweise in Protokollen zur gegenseitigen Authentifizierung definiert. Bei der Datenverarbeitung definieren solche Protokolle üblicherweise eine spezifische Menge und Qualität von Nachrichten und Daten, die durch die Parteien ausgetauscht werden, wenn die Parteien versuchen, sich zu authentifizieren. Der Erfinder dieser Offenbarung erkennt, dass bei der Datenverarbeitung eine gegenseitige Authentifizierung über Verbindungen mit niedrigem Durchsatz schwierig sein kann, wie die Typen, die manchmal in Rändern von Internet-der-Dinge-Netzwerken (IdD-Netzwerken) gefunden werden, wo sich Parteien als nicht einschränkende Beispiele vor einer Übertragung, Verarbeitung, Leitung, Filterung, Translation oder Speicherung von Daten, die sich zwischen Netzwerken bewegen, gegenseitig authentifizieren.
  • Figurenliste
  • Während diese Offenbarung mit Ansprüchen endet, die bestimmte Ausführungsformen besonders hervorheben und eindeutig beanspruchen, können verschiedene Merkmale und Vorteile von Ausführungsformen innerhalb des Schutzumfangs dieser Offenbarung leichter aus der folgenden Beschreibung ermittelt werden, wenn sie in Verbindung mit den beigefügten Zeichnungen gelesen werden, in denen:
    • 1 ein Authentifizierungsprotokoll gemäß einer oder mehreren Ausführungsformen veranschaulicht.
    • 2 einen Prozess gemäß einer oder mehreren Ausführungsformen veranschaulicht.
    • 3 einen Prozess gemäß einer oder mehreren Ausführungsformen veranschaulicht.
    • 4 ein Rechensystem gemäß einer oder mehreren Ausführungsformen veranschaulicht.
    • 5 eine kryptografische Information gemäß einer oder mehreren Ausführungsformen veranschaulicht.
    • 6 ein Zertifikat gemäß einer oder mehreren Ausführungsformen veranschaulicht.
    • 7 ein System zur gegenseitigen Authentifizierung gemäß einer oder mehreren Ausführungsformen veranschaulicht.
    • 8 eine beispielhafte Nachrichtenübermittlung für eine Handshake-Nachrichtenübermittlungs-Phase eines Authentifizierungsprotokolls veranschaulicht.
    • 9 einen Gesichtspunkt des Gegenstands gemäß einer oder mehreren Ausführungsformen veranschaulicht.
  • ART(EN) ZUM AUSFÜHREN DER ERFINDUNG
  • In der folgenden detaillierten Beschreibung wird auf die beigefügten Zeichnungen Bezug genommen, die einen Teil hiervon bilden und in denen zur Veranschaulichung spezifische Beispiele von Ausführungsformen gezeigt sind, in denen die vorliegende Offenbarung ausgeführt werden kann. Diese Ausführungsformen werden ausreichend detailliert beschrieben, um es einem Durchschnittsfachmann zu ermöglichen, die vorliegende Offenbarung auszuführen. Es können jedoch auch andere hierin ermöglichte Ausführungsformen verwendet werden, und Änderungen der Struktur, des Materials und des Prozesses können vorgenommen werden, ohne vom Schutzumfang der Offenbarung abzuweichen.
  • Die hierin dargestellten Veranschaulichungen sollen keine tatsächlichen Ansichten eines bestimmten Verfahrens oder Systems oder einer bestimmten Vorrichtung oder Struktur sein, sondern sind lediglich idealisierte Darstellungen, die zur Beschreibung der Ausführungsformen der vorliegenden Offenbarung verwendet werden. Ähnliche Strukturen oder Komponenten in den verschiedenen Zeichnungen können in einigen Fällen zur Vereinfachung für den Leser die gleiche oder eine ähnliche Nummerierung beibehalten; die Ähnlichkeit in der Nummerierung bedeutet jedoch nicht notwendigerweise, dass die Strukturen oder Komponenten in Größe, Zusammensetzung, Konfiguration oder einer anderen Eigenschaft identisch sind.
  • Die folgende Beschreibung kann Beispiele einschließen, um es einem Durchschnittsfachmann zu ermöglichen, die offenbarten Ausführungsformen auszuführen. Die Verwendung der Begriffe „beispielhaft“, „als Beispiel“ und „zum Beispiel“ bedeutet, dass die zugehörige Beschreibung erläuternd ist, und obwohl der Schutzumfang der Offenbarung die Beispiele und ihre rechtlichen Äquivalente umfassen soll, ist die Verwendung solcher Begriffe nicht dazu bestimmt, den Schutzumfang einer Ausführungsform oder dieser Offenbarung auf die spezifizierten Komponenten, Schritte, Merkmale, Funktionen oder dergleichen einzuschränken.
  • Es versteht sich, dass die Komponenten der Ausführungsformen, wie sie hierin allgemein beschrieben und in den Zeichnungen veranschaulicht sind, in einer großen Vielfalt unterschiedlicher Konfigurationen angeordnet und ausgelegt werden könnten. Somit soll die folgende Beschreibung verschiedener Ausführungsformen den Schutzumfang der vorliegenden Offenbarung nicht einschränken, sondern ist lediglich repräsentativ für verschiedene Ausführungsformen. Während die verschiedenen Gesichtspunkte der Ausführungsformen in den Zeichnungen dargestellt sein können, sind die Zeichnungen nicht notwendigerweise maßstabsgetreu gezeichnet, sofern nicht ausdrücklich angegeben.
  • Des Weiteren sind die gezeigten und beschriebenen spezifischen Implementierungen nur Beispiele und sollten nicht als die einzige Möglichkeit zur Implementierung der vorliegenden Offenbarung ausgelegt werden, sofern hierin nicht anders angegeben. Elemente, Schaltungen und Funktionen können in Blockdiagrammform gezeigt sein, um die vorliegende Offenbarung nicht durch unnötige Details undeutlich werden zu lassen. Umgekehrt sind gezeigte und beschriebene spezifische Implementierungen nur beispielhaft und sollten nicht als die einzige Möglichkeit zur Implementierung der vorliegenden Offenbarung ausgelegt werden, sofern hierin nicht anders angegeben. Außerdem sind Blockdefinitionen und die Aufteilung von Logik zwischen verschiedenen Blöcken beispielhaft für eine spezifische Implementierung. Es ist für den Fachmann ohne Weiteres ersichtlich, dass die vorliegende Offenbarung durch zahlreiche andere Aufteilungslösungen ausgeführt werden kann. Auf Details zu zeitlichen Erwägungen und dergleichen wurde größtenteils verzichtet, soweit solche Details für ein vollständiges Verständnis der vorliegenden Offenbarung nicht erforderlich sind und innerhalb der Fähigkeiten eines Durchschnittsfachmanns liegen.
  • Der Durchschnittsfachmann würde verstehen, dass Informationen und Signale unter Verwendung einer Vielfalt verschiedener Technologien und Techniken dargestellt werden können. Einige Zeichnungen können Signale zur Übersichtlichkeit der Darstellung und Beschreibung als ein einzelnes Signal veranschaulichen. Es ist für einen Durchschnittsfachmann ersichtlich, dass das Signal einen Bus von Signalen darstellen kann, wobei der Bus eine Vielfalt von Bitbreiten aufweisen kann und die vorliegende Offenbarung auf einer beliebigen Anzahl von Datensignalen, einschließlich eines einzelnen Datensignals, implementiert werden kann.
  • Die verschiedenen veranschaulichenden logischen Blöcke, Module und Schaltungen, die in Verbindung mit den hierin offenbarten Ausführungsformen beschrieben sind, können mit einem Universalprozessor, einem Spezialprozessor, einem Digitalsignalprozessor (DSP), einer integrierten Schaltung (IC), einer anwendungsspezifischen integrierten Schaltung (ASIC), einer feldprogrammierbaren Gatteranordnung (FPGA) oder einer anderen programmierbaren Logikvorrichtung, einer diskreten Gatter- oder Transistorlogik, diskreten Hardwarekomponenten oder einer beliebigen Kombination davon, die zum Durchführen der hierin beschriebenen Funktionen ausgelegt sind, implementiert oder durchgeführt werden. Ein Universalprozessor (der hierin auch als Hostprozessor oder einfach als Host bezeichnet werden kann) kann ein Mikroprozessor sein, alternativ kann der Prozessor jedoch ein beliebiger herkömmlicher Prozessor, eine Steuerung, Mikrosteuerung oder Zustandsautomat sein. Ein Prozessor kann auch als eine Kombination von Rechenvorrichtungen, wie eine Kombination aus einem DSP und einem Mikroprozessor, eine Vielzahl von Mikroprozessoren, ein oder mehrere Mikroprozessoren in Verbindung mit einem DSP-Kern oder eine beliebige andere derartige Konfiguration implementiert sein. Ein Universalcomputer einschließlich eines Prozessors wird als Spezialcomputer angesehen, während der Universalcomputer so konfiguriert ist, dass er Rechenanweisungen (z. B. einen Softwarecode) ausführt, die sich auf Ausführungsformen der vorliegenden Offenbarung beziehen.
  • Die Ausführungsformen können in Bezug auf einen Prozess beschrieben sein, der als ein Flussdiagramm, ein Fließschema, ein Strukturdiagramm oder ein Blockdiagramm dargestellt ist. Obwohl ein Flussdiagramm operationale Handlungen als einen sequentiellen Prozess beschreiben kann, können viele dieser Handlungen in einer anderen Abfolge, parallel oder im Wesentlichen gleichzeitig durchgeführt werden. Außerdem kann die Reihenfolge der Handlungen geändert werden. Ein Prozess kann einem Verfahren, einem Thread, einer Funktion, einer Prozedur, einer Subroutine, einem Unterprogramm, einer anderen Struktur oder Kombinationen davon entsprechen. Des Weiteren können die hierin offenbarten Verfahren in Hardware, Software oder beidem implementiert werden. Bei Implementierung in Software können die Funktionen als eine oder mehrere Anweisungen oder ein Code auf computerlesbaren Medien gespeichert oder übertragen werden. Computerlesbare Medien schließen sowohl Computerspeichermedien als auch Kommunikationsmedien, einschließlich aller Medien, welche die Übertragung eines Computerprogramms von einem Ort zu einem anderen unterstützen, ein.
  • Jede Bezugnahme auf ein Element hierin unter Verwendung einer Bezeichnung, wie „erste/r/s“, „zweite/r/s“ usw. schränkt die Menge oder Reihenfolge dieser Elemente nicht ein, es sei denn, eine solche Einschränkung wird ausdrücklich angegeben. Vielmehr können diese Bezeichnungen hierin als ein zweckmäßiges Verfahren zum Unterscheiden zwischen zwei oder mehr Elementen oder Instanzen eines Elements verwendet werden. Eine Bezugnahme auf ein erstes und ein zweites Element bedeutet also nicht, dass dort nur zwei Elemente eingesetzt werden dürfen oder dass das erste Element dem zweiten Element in irgendeiner Weise vorausgehen muss. Außerdem kann ein Satz von Elementen, sofern nicht anders angegeben, ein oder mehrere Elemente umfassen.
  • Wie hierin verwendet, bedeutet der Begriff „im Wesentlichen“ in Bezug auf einen gegebenen Parameter, eine gegebene Eigenschaft oder eine gegebene Bedingung und schließt in einem für den Durchschnittsfachmann verständlichen Ausmaß ein, dass der gegebene Parameter, die gegebene Eigenschaft oder die gegebene Bedingung mit einem geringen Maß an Varianz, wie zum Beispiel innerhalb annehmbarer Fertigungstoleranzen, erfüllt ist. Beispielhaft kann in Abhängigkeit von dem bestimmten Parameter, der bestimmten Eigenschaft oder der bestimmten Bedingung, der bzw. die im Wesentlichen erfüllt ist, der Parameter, die Eigenschaft oder die Bedingung zu mindestens 90 % erfüllt, zu mindestens 95 % erfüllt oder sogar zu mindestens 99 % erfüllt sein.
  • Wie hierin verwendet, werden relationale Begriffe, wie „über“, „unter“, „auf‟, „unterliegend“ „oberhalb“, „unterhalb“ usw. aus Gründen der Klarheit und Zweckmäßigkeit für das Verständnis der Offenbarung und der begleitenden Zeichnungen verwendet und sind nicht mit einer bestimmten Präferenz, Ausrichtung oder Reihenfolge verbunden oder davon abhängig, es sei denn, aus dem Kontext geht eindeutig etwas anderes hervor.
  • Hierin können der Begriff „gekoppelt“ und Derivate davon verwendet werden, um anzugeben, dass zwei oder mehr Elemente zusammenwirken oder miteinander interagieren. Wenn ein Element als mit einem anderen Element „gekoppelt“ beschrieben wird, können die Elemente in direktem physischem oder elektrischem Kontakt sein oder es können Zwischenelemente oder -schichten vorhanden sein. Wenn dagegen ein Element als mit einem anderen Element „direkt gekoppelt“ bezeichnet wird, sind keine Zwischenelemente oder -schichten vorhanden. Der Begriff „verbunden“ kann in dieser Beschreibung austauschbar mit dem Begriff „gekoppelt“ verwendet werden und hat die gleiche Bedeutung, sofern nicht ausdrücklich etwas anderes angegeben ist oder der Kontext einem Fachmann etwas anderes angeben würde.
  • Wenn hierin verwendet, schließt der Begriff „Nachricht“, ohne darauf beschränkt zu sein, eine Nachricht ein, die unter Verwendung eines oder mehrerer Pakete kommuniziert wird.
  • Drahtverbundene und drahtlose Verbindungen mit niedrigem Durchsatz („Verbindungen mit niedrigem Durchsatz“) sind in Systemen mit „einfachen“ Vorrichtungen (z. B. beschränkt in Bezug auf Verarbeitungskerne, Stromversorgung oder verfügbaren Speicher, ohne darauf beschränkt zu sein) vorteilhaft, da sie eine weniger intensive Verarbeitung erfordern und mit geringerer Leistung arbeiten als Verbindungen mit höherem Durchsatz. Deshalb werden Verbindungen mit niedrigem Durchsatz üblicherweise zwischen Vorrichtungen verwendet, die als ein nicht einschränkendes Beispiel mit geringerer Batterieleistung, einfacheren Kernen und größerer Skalierung als Vorrichtungen arbeiten, die für Verbindungen mit höherem Durchsatz konfiguriert sind.
  • Kommunikationen auf Verbindungen mit niedrigem Durchsatz sind für Cyberangriffe anfällig, da die verbundenen Vorrichtungen üblicherweise keine gegenseitige Vorrichtungsauthentifizierung unterstützen. Eine gegenseitige Authentifizierung erfordert üblicherweise eine komplexe Verarbeitung, die über die angemessene Fähigkeit der Vorrichtungen hinausgeht, und hohe Nachrichtennutzlasten, die für Verbindungen mit niedrigem Durchsatz ungeeignet sind. Deshalb sind Systeme von Vorrichtungen, die durch Verbindungen mit niedrigem Durchsatz gekoppelt sind, möglicherweise nicht für Anwendungen geeignet, die eine gegenseitige Authentifizierung erfordern, während Systeme von Vorrichtungen, die durch Verbindungen mit hohem Durchsatz gekoppelt sind und mehr komplexe Kerne und verfügbaren Speicher aufweisen, für Anwendungen geeignet sind, die eine gegenseitige Authentifizierung erfordern.
  • Der Erfinder dieser Offenbarung verstehen, dass Systeme von Vorrichtungen im Zusammenhang mit niedrigem Durchsatz und Kommunikationen, die sich darauf bewegen, für Cyberangriffe anfällig sind, einschließlich, ohne darauf beschränkt zu sein, sogenannte Man-in-the-Middle-Angriffe (MITM-Angriffe), bei denen ein Angreifer legitime Kommunikationen zwischen zwei Vorrichtungen weiterleitet und modifiziert und die Modifikationen es dem Angreifer ermöglichen können, Zugriff auf ein System, ein Netzwerk oder eine Vorrichtung, ohne darauf beschränkt zu sein, zu erlangen.
  • Einige dem Erfinder dieser Offenbarung bekannte herkömmliche Protokolle, die angeblich eine gegenseitige Authentifizierung von Vorrichtungen, die durch Verbindungen mit niedrigem Durchsatz gekoppelt sind, unterstützen, verzichten im Allgemeinen auf mindestens eine der akzeptierten Sicherheitssäulen: Authentifizierung, Integrität oder Vertraulichkeit. Andere dem Erfinder dieser Offenbarung bekannte herkömmliche Protokolle, die angeblich eine gegenseitige Authentifizierung von Vorrichtungen, die durch Verbindungen mit niedrigem Durchsatz gekoppelt sind, unterstützen, können zu langsam sein, um eine geeignete Anwendbarkeit sicherzustellen.
  • Der Erfinder dieser Offenbarung erkennt, dass ein Bedarf an Protokollen zur gegenseitigen Authentifizierung und Vorrichtungen zur Implementierung derselben besteht, die in Systemen von Vorrichtungen im Zusammenhang mit niedrigem Durchsatz verwendet werden können. Genauer erkennt der Erfinder dieser Offenbarung einen Bedarf an einem Protokoll zur gegenseitigen Authentifizierung, das in Verbindungen mit niedrigem Durchsatz und Anwendungen, die Verbindungen mit niedrigem Durchsatz einschließen, verwendbar ist, wobei zwei Parteien (z. B. zwei Vorrichtungen, ohne darauf beschränkt zu sein) die Identität der Partei, mit der sie in Kommunikation sind, sicherstellen und eine sichere Sitzung für das Austauschen von verschlüsselten Daten herstellen können. Obwohl Verbindungen mit niedrigem Durchsatz eine spezifische Anwendung sind, geht die hierin erörterte Verwendung von Protokollen zur gegenseitigen Authentifizierung bei Verbindungen, bei denen der Durchsatz keine beschränkende Designüberlegung ist (z. B. Verbindungen mit schnellem Durchsatz, ohne darauf beschränkt zu sein), nicht über den Schutzumfang dieser Offenbarung hinaus.
  • In einer oder mehreren Ausführungsformen, wenn zwei oder mehr Parteien kommunizieren möchten, wird die Identität jeder Partei durch einen Elliptic-Curve-Digital Signature Algorithm-Verifizierungsprozess (ECDSA-Verifizierungsprozess) verifiziert. Als Teil des ECDSA-Verifizierungsprozesses tauschen die Parteien vorteilhafterweise Identitätsinformationen auf begrenzte Weise aus (d. h. in Bezug auf die Anzahl von Nachrichten und die Größe ausgetauschter Daten (in Bytes)). Während die Identitätsinformationen begrenzt sind, sind sie allein oder in Kombination mit anderen den Parteien bekannten Informationen ausreichend, um den ECDSA-Verifizierungsprozess erfolgreich durchzuführen. Nach der Verifizierung tauschen die Parteien (einen) ordnungsgemäß signierten Elliptic Curve Diffie-Hellman-Sitzungsschlüssel (ECDH-Sitzungsschlüssel) aus (z. B. führen ein Schlüsselaustauschvereinbarungsprotokoll durch, ohne darauf beschränkt zu sein), der verwendet wird, um Sitzungsschlüssel für eine Kommunikation abzuleiten. Die Sitzungsschlüssel können verwendet werden, um eine Kommunikation (z. B. Nachrichten, Zertifikate, Codes, ohne darauf beschränkt zu sein) gemäß einer Verschlüsselung, wie einem symmetrischen Verschlüsselungsalgorithmus (z. B. Advanced Encryption Standard (AES) 128, AES 256, ohne darauf beschränkt zu sein), einer Stromverschlüsselung (z. B. Salsa20, Rivest Cipher (RC) 4, RC5 oder RC6, ohne darauf beschränkt zu sein) oder einer Tweakable Block Cipher mit symmetrischem Schlüssel (z. B. ThreeFisch, ohne darauf beschränkt zu sein), ohne darauf beschränkt zu sein, zu verschlüsseln.
  • 1 ist ein Swimlane-Diagramm, das ein Authentifizierungsprotokoll 100 gemäß einer oder mehreren Ausführungsformen darstellt. In dem spezifischen nicht einschränkenden Beispiel, das durch 1 dargestellt ist, führen eine erste Partei 102 und eine zweite Partei 104 das Authentifizierungsprotokoll 100 durch, das zwei Phasen einschließen kann: eine Handshake-Nachrichtenübermittlungs-Phase 118 und eine Phase der verschlüsselten Kommunikation 130 nach erfolgreichem Durchführen der Handshake-Nachrichtenübermittlungs-Phase 118.
  • Während der Handshake-Nachrichtenübermittlungs-Phase 118 tauschen die erste Partei 102 und die zweite Partei 104 Informationen als Teil eines Versuchs aus, einen Satz (oder Sätze) kryptografischer Schlüssel zu vereinbaren, den die Parteien zum Verschlüsseln und Entschlüsseln von Nachrichten während einer sicheren Kommunikationssitzung zwischen den Parteien verwenden. Solche kryptografischen Schlüssel können hierin als „Sitzungsschlüssel“ bezeichnet werden. Genauer versuchen die Parteien, einen Zwischenschlüssel zu vereinbaren, aus dem mehrere Sitzungsschlüssel abgeleitet werden können, wobei ein solcher Zwischenschlüssel als „Sitzungsgeheimnis“ bezeichnet wird.
  • Das Durchführen der Handshake-Nachrichtenübermittlungs-Phase 118 kann hierin auch als Austauschen von Nachrichten zum „Herstellen einer sicheren Kommunikationssitzung“ zwischen Parteien, hier der ersten Partei 102 und der zweiten Partei 104, gekennzeichnet sein.
  • Bei Vorgang 106 tauschen die erste Partei 102 und die zweite Partei 104 jeweilige Identitätsinformationen durch Durchführen einer ersten Nachrichtenübermittlung der Handshake-Nachrichtenübermittlungs-Phase 118 aus. Die erste Nachrichtenübermittlung kann einschließen, dass jede von der ersten Partei 102 und der zweiten Partei 104 eine Nachricht (eine erste bzw. zweite Nachricht) mit ihren jeweiligen Identifizierungsinformationen (die eine optionale kryptografische Nonce einschließen können) sendet, wobei die Nachricht durch die andere Partei empfangen wird.
  • Identitätsinformationen können ein oder mehrere digitale Zertifikate zum Teilen von Informationen über die Partei, über den öffentlichen Schlüssel der Partei, über einen Unterzeichner des Zertifikats einer Partei und über eine Zertifizierungsstelle, die den Unterzeichner authentifiziert, einschließen oder in Form davon sein. Ein Zertifikat eines öffentlichen Schlüssels ist ein digitales Zertifikat, das die Inhaberschaft eines öffentlichen Schlüssels authentifiziert. Das Zertifikat eines öffentlichen Schlüssels der Partei kann hierin als „Vorrichtungszertifikat“ bezeichnet werden. Die Verwendung digitaler Zertifikate, die die Identität einer Entität aus anderen Gründen als zum Authentifizieren der Inhaberschaft eines öffentlichen Schlüssels authentifizieren, geht nicht über den Schutzumfang dieser Offenbarung hinaus.
  • Im Allgemeinen besteht die Rolle eines Unterzeichners darin, eine Entität aufzunehmen, die von einer Zertifizierungsstelle authentifiziert (signiert) wurde und es somit ermöglicht, dass Vorrichtungen, wie eine erste Partei 102 und eine zweite Partei 104, mit einem durch den Unterzeichner bereitgestellten privaten Schlüssel signiert (authentifiziert) werden, der von solchen Vorrichtungen mit weniger Risiko getragen (z. B. gespeichert, ohne darauf beschränkt zu sein) wird, als beim Tragen eines privaten Schlüssels einer Zertifizierungsstelle besteht, wobei umfangreiche Anstrengungen unternommen werden müssten, um ihn zu schützen und sicher zu halten.
  • Ein Zertifikat eines Unterzeichners kann durch eine Zertifizierungsstelle signiert (d. h. authentifiziert) werden, und ein Vorrichtungszertifikat kann durch den Unterzeichner signiert (d. h. authentifiziert) werden. In einigen Ausführungsformen können Identitätsinformationen einen Abschnitt eines signierten Vorrichtungszertifikats und ein signiertes Zertifikat eines öffentlichen Schlüssels eines in einer Zertifikatkette angeordneten Unterzeichners einschließen.
  • Identitätsinformationen, die durch die Parteien ausgetauscht werden, können einen Abschnitt eines Vorrichtungszertifikats einschließen, wobei der Abschnitt durch einen Unterzeichner signiert ist, der durch eine Zertifizierungsstelle authentifiziert ist. Als nicht einschränkendes Beispiel können Identitätsinformationen in einem X.509-formatierten Zertifikat enthalten sein, das einem Abschnitt eines Vorrichtungszertifikats entspricht. X.509 wird derzeit durch den ITU Telecommunication Standardization Sector (ITU-T) definiert. In verschiedenen Ausführungsformen kann ein Abschnitt eines signierten Vorrichtungszertifikats einige, aber nicht alle der Informationen einschließen, die in einem Transportschichtsicherheitszertifikat (TLS-Zertifikat), einem Secure Socket Layer-Zertifikat (SSL-Zertifikat) oder einem Zertifikat eines ähnlichen Typs verwendet werden. Ein Abschnitt eines Vorrichtungszertifikats, signiert oder unsigniert, kann das Format eines Zertifikats eines öffentlichen Schlüssels, wie gemäß dem X.509-Format (einschließlich Erweiterungen davon), aufweisen. Ein solches Format eines Zertifikats eines öffentlichen Schlüssels kann eine spezifische Zertifikatstruktur einschließen, die spezifische Felder für spezifische Informationen und eine Größe eines jeweiligen Felds in Bytes definiert. Während einige oder eine Gesamtheit von Informationen eines Abschnitts eines signierten Vorrichtungszertifikats, der durch die Parteien ausgetauscht wird, komprimiert sein können, steht ein Abschnitt eines Vorrichtungszertifikats, signiert oder unsigniert, im Gegensatz zu einem komprimierten Zertifikat eines öffentlichen Schlüssels, wobei eine Gesamtheit eines Zertifikats eines öffentlichen Schlüssels nur durch Decodieren der Bits des komprimierten Zertifikats eines öffentlichen Schlüssels wiederherstellbar ist.
  • Jede Partei kann das Vorrichtungszertifikat der anderen Partei aus einem Abschnitt eines signierten Vorrichtungszertifikats wiederherstellen, wie weiter unten beschrieben, und jeweilige wiederhergestellte Vorrichtungszertifikate verwenden, um die Identität der anderen Partei als ein nicht einschränkendes Beispiel unter Verwendung eines ECDSA-Verifizierungsprozesses zu verifizieren.
  • In einigen Ausführungsformen kann ein Vorrichtungszertifikat oder Vorrichtungszertifikatabschnitt, signiert oder unsigniert, Anweisungen zum Anfordern eines öffentlichen Schlüssels von einem Sender einschließen, das heißt, ein Abschnitt eines Vorrichtungszertifikats, der durch die erste Partei 102 bereitgestellt wird, kann Anweisungen zum Anfordern eines öffentlichen Schlüssels von der ersten Partei 102 einschließen, und ein Vorrichtungszertifikatabschnitt, der durch die zweite Partei 104 bereitgestellt wird, kann Anweisungen zum Anfordern eines öffentlichen Schlüssels von der zweiten Partei 104 einschließen. In einigen Ausführungsformen können die Anweisungen mit einem Vorrichtungszertifikat oder Vorrichtungszertifikatabschnitt codiert sein und können als ein nicht einschränkendes Beispiel als Teil eines ECDSA-Verifizierungsprozesses wiederhergestellt und/oder durchgeführt werden.
  • Bei Vorgang 108 und Vorgang 110 verifiziert jede Partei die Identität der anderen Partei unter Verwendung der ausgetauschten Identitätsinformationen als ein nicht einschränkendes Beispiel unter Verwendung eines ECDSA-Verifizierungsprozesses. In einem Fall eines Vorrichtungszertifikats und eines Unterzeichnerzertifikats, die in einer Zertifikatkette angeordnet sind, kann die Verifizierung, für jede Partei, bei Vorgängen 108 und 110, ein Verifizieren einer Signatur eines Unterzeichers, die unter Verwendung einer ECDSA-Verifizierung an den Abschnitt eines signierten Vorrichtungszertifikats angebracht wird, und eines öffentlichen Schlüssels eines Unterzeichners, der in einem durch eine Zertifizierungsstelle signierten Zertifikat eines öffentlichen Schlüssels eines Unterzeichners enthalten ist, einschließen. Die Unterschrift der Zertifizierungsstelle, die an das Zertifikat eines öffentlichen Schlüssels des Unterzeichners angebracht ist, kann unter Verwendung einer ECDSA-Verifizierung und eines öffentlichen Schlüssels einer Zertifizierungsstelle, der unter Verwendung eines vertrauenswürdigen Bereitstellungsvorgangs getrennt von dem Authentifizierungsprotokoll 100 bereitgestellt wird, verifiziert werden.
  • Wenn sowohl die erste Partei 102 als auch die zweite Partei 104 die andere Partei verifizieren, erhalten sie den jeweiligen öffentlichen Schlüssel der anderen Partei (in dem Abschnitt eines signierten Vorrichtungszertifikats der anderen Partei gesendet) und können mit Vorgang 112 fortfahren. Wenn eine der Parteien die andere Partei nicht verifiziert, kann das Authentifizierungsprotokoll 100 die Vorgänge 108, 110 und 112 erneut durchführen, bis die jeweiligen Identitäten beider Parteien verifiziert sind (oder eine gewisse Schwellenwertanzahl von Verifizierungsversuchen durchgeführt wurde), oder das Authentifizierungsprotokoll 100 kann enden.
  • Bei Vorgang 112 tauschen die erste Partei 102 und die zweite Partei 104 Informationen über einen signierten Schlüsselvereinbarungsaustausch eines signierten Schlüsselvereinbarungsaustauschs über eine zweite Nachrichtenübermittlung der Handshake-Nachrichtenübermittlungs-Phase 118 aus. Die zweite Nachrichtenübermittlung kann einschließen, dass jede Partei eine Nachricht (eine dritte bzw. vierte Nachricht) mit ihren Informationen über einen signierten Schlüsselvereinbarungsaustausch sendet, wobei die Nachricht durch die andere Partei empfangen wird. Informationen über einen signierten Schlüsselvereinbarungsaustausch können einen signierten flüchtigen öffentlichen Schlüssel jeder Partei einschließen, dessen Erzeugung nachstehend erörtert wird.
  • In einigen Ausführungsformen können die erste und die zweite kryptografische Nonce, die bei Vorgang 106 und Prozess 200 ausgetauscht werden, durch die Parteien verwendet werden, um einige der Vorgänge eines signierten Schlüsselvereinbarungsaustauschs durchzuführen. Als nicht einschränkendes Beispiel kann eine kryptografische Nonce, einschließlich, ohne darauf beschränkt zu sein, die erste und die zweite kryptografische Nonce des Prozesses 200 eine Nummer für den Einmalgebrauch (z. B. eine beliebige Anzahl, wie eine zeitvariante Nummer, eine Zufallszahl, eine Pseudozufallszahl oder Kombinationen davon, ohne darauf beschränkt zu sein) sein, die durch die erste Partei 102 bzw. die zweite Partei 104 bereitgestellt wird. Die erste Partei 102 und die zweite Partei 104 verwenden die erste bzw. die zweite kryptografische Nonce, um eine spezifische Authentifizierungssitzung (d. h. eine Authentifizierungssitzung, die einer bestimmten Ausführung des Authentifizierungsprotokolls 100 entspricht), eine spezifische Kommunikation oder eine spezifische sichere Kommunikationssitzung zu identifizieren und Nachrichten zu diesen zuzuordnen. Ein Angreifer kann verschlüsselte Nachrichten, die eine Partei akzeptiert, nicht kopieren und neu senden oder dies ist für ihn jedenfalls schwieriger - d. h. ein sogenannter „Replay-Angriff‟, wobei ein Empfänger eine Nachricht eines Angreifers behandelt, als ob sie durch einen authentifizierten Sender gesendet wurde.
  • Bei Vorgang 114 und Vorgang 116 führen die erste Partei 102 und die zweite Partei 104 jeweils eine oder mehrere Berechnungen eines Protokolls für den signierten Schlüsselvereinbarungsaustauschs durch. In einigen Ausführungsformen schließen Berechnungen von Vorgang 114 und von Vorgang 116 ein Erhalten eines Sitzungsgeheimnisses ein. In verschiedenen Ausführungsformen kann das Sitzungsgeheimnis durch eine oder beide Parteien verwendbar sein, um Sitzungsschlüssel zu erhalten oder wiederherzustellen. Als nicht einschränkendes Beispiel kann ein Sitzungsgeheimnis erhalten werden, indem ein Elliptic Curve Diffie-Hellman-Algorithmus (ECDH-Algorithmus) durchgeführt wird, und als „ECDH-Sitzungsschlüssel“ bezeichnet werden. Ein nicht einschränkendes Beispiel für ein Sitzungsgeheimnis des ECDH-Sitzungsschlüssel-Typs ist ein Vormasterschlüssel, der durch Durchführen eines spezifischen ECDH-Algorithmus unter Verwendung einer Kombination von signierten öffentlichen flüchtigen Schlüsseln, die durch die erste Partei 102 und die zweite Partei 104 bei Vorgang 112 ausgetauscht werden, und privaten flüchtigen Schlüsseln, die durch die erste Partei 102 und die zweite Partei 104 erzeugt werden, erhaltbar ist.
  • In einigen Ausführungsformen erhält das Authentifizierungsprotokoll 100 einen oder mehrere Sitzungsschlüssel durch Durchführen eines spezifischen ECDH-Algorithmus (z. B. eines ECDH-Schlüsselvereinbarungsprotokolls) unter Verwendung einer Kombination von signierten öffentlichen Schlüsseln und jeweiligen privaten Schlüsseln an der ersten Partei 102 und der zweiten Partei 104. Nicht einschränkende Beispiele für Sitzungsschlüssel, die von einem ECDH-Sitzungsschlüssel erhaltbar sind, schließen einen AES-kombinierten 32-Byte-Schlüssel, der durch Durchführen einer HKDF-Ableitungsfunktion am ECDH-Sitzungsschlüssel erhalten wird, 16-Byte-AES- und 16-Byte-AESIV-Schlüssel, die aus dem AES-kombinierten 32-Byte-Schlüssel abgeleitet sind, und einen HMAC-32-Byte-Schlüssel ein.
  • In einigen Ausführungsformen kann jede Partei, die das Authentifizierungsprotokoll 100 durchführt, konfiguriert sein, um einen Schlüssel eines Hash-basierten Nachrichtenauthentifizierungscodes (HMAC-Schlüssel) oder einen Salted-HMAC-Schlüssel zu erhalten, indem eine Hash-basierte einfache Schlüsselableitungsfunktion (HKDF) auf ein Sitzungsgeheimnis (z. B. EDCH-Sitzungsschlüssel) und eine oder beide von der ersten und der zweiten kryptografischen Nonce, die während des Prozesses 200 erhalten werden, angewendet wird. Nach dem Erhalten eines oder mehrerer der Sitzungsschlüssel und des HMAC-Schlüssels können jede von der ersten Partei 102 und der zweiten Partei 104 diese Sitzungsschlüssel und HMAC-Schlüssel verwenden, um Daten zu verschlüsseln und eine verschlüsselte Kommunikation als Teil einer sicheren Kommunikationssitzung durchzuführen.
  • Insbesondere können Vorgänge der Handshake-Nachrichtenübermittlungs-Phase 118 des Authentifizierungsprotokolls 100 durch Austauschen einer spezifischen oder maximalen Anzahl von Nachrichten und Bytes zwischen der ersten Partei 102 und der zweiten Partei 104 durchgeführt werden. In dem spezifischen nicht einschränkenden Beispiel, das durch 1 dargestellt ist, werden vier Nachrichten (d. h., jede Partei sendet eine Nachricht, einschließlich Identitätsinformationen und einer kryptografische Nonce, und jede Partei sendet eine Nachricht, einschließlich signierter flüchtiger öffentlicher Schlüssel) und insgesamt 960 Bytes (erste und zweite Nachricht, jeweils: 320 Byte Zertifikatkette + 32 Byte kryptografische Nonce; und zweite und dritte Nachricht, jeweils: 64 Byte flüchtiger öffentlicher Schlüssel und 64 Byte digitale Signatur - zusammen den signierten flüchtigen öffentlichen Schlüssel bildend) während Vorgang 106 und Vorgang 112 zwischen der ersten Partei 102 und der zweiten Partei 104 ausgetauscht. Ein typisches TLS-Protokoll, das dem Erfinder dieser Offenbarung bekannt ist, verwendet mehrere Kilobyte von Daten, um eine zu der Handshake-Nachrichtenübermittlungs-Phase 118 äquivalente Handshake-Phase durchzuführen.
  • Insbesondere können mindestens drei Sitzungsschlüssel für jede sichere Kommunikationssitzung in Ausführungsformen des Authentifizierungsprotokolls 100 erhalten werden.
  • Wie vorstehend erörtert, bilden Vorgang 106, Vorgang 108, Vorgang 110, Vorgang 112, Vorgang 114 und Vorgang 116 einen Teil oder eine Gesamtheit der Handshake-Nachrichtenübermittlungs-Phase 118 des Authentifizierungsprotokolls 100. Vorgang 120, Vorgang 122, Vorgang 124 und Vorgang 126 und Vorgang 128, die weiter unten beschrieben werden, schließen einen Teil oder eine Gesamtheit von Vorgängen einer Phase der verschlüsselten Kommunikation 130 des Authentifizierungsprotokolls 100 ein.
  • Bei Vorgang 120 stellt das Authentifizierungsprotokoll 100 eine sichere Kommunikationssitzung zwischen der ersten Partei 102 und der zweiten Partei 104 her. Als ein nicht einschränkendes Beispiel kann die sichere Kommunikationssitzung als Reaktion darauf, dass die erste Partei 102 und die zweite Partei 104 die Handshake-Nachrichtenübermittlungs-Phase 118 erfolgreich durchführen, als hergestellt betrachtet werden.
  • Bei Vorgang 122 kommunizieren die erste Partei 102 und die zweite Partei 104 unter Verwendung einer sicheren Kommunikationsverbindung und genauer unter Verwendung von Nachrichten, die unter Verwendung eines Verschlüsselungsalgorithmus und der Sitzungsschlüssel, die durch Durchführen von Vorgang 112, von Vorgang 114 und von Vorgang 116 abgeleitet werden, verschlüsselt werden. Jede Partei kann die abgeleiteten Sitzungsschlüssel verwenden, um die verschlüsselten Nachrichten, die von der anderen Partei empfangen werden, zu entschlüsseln.
  • In einigen Ausführungsformen werden Nachrichten unter Verwendung von AES 128 verschlüsselt. In einigen Ausführungsformen kann Cipher Block Chaining (CBC) (oder ein anderer Verkettungsmechanismus) verwendet werden, um eine Nachrichtenabhängigkeit in die Codierung einzuführen, und dann kann jeder Verschlüsselungstextblock unter Verwendung des ausgewählten Verschlüsselungsalgorithmus (z. B. AES 128, ohne darauf beschränkt zu sein) verschlüsselt werden.
  • Bei dem optionalen Vorgang 124 kann das Authentifizierungsprotokoll 100 die Nachrichten verschlüsselt kommunizieren, wie unter Bezugnahme auf Vorgang 122 beschrieben, wobei die Nachrichten optional HMACs einschließen.
  • Bei dem optionalen Vorgang 126 kann das Authentifizierungsprotokoll 100 periodisch oder zufällig eine Schlüsseldrehung eines oder mehrerer der Codes und/oder Schlüssel, die während des Authentifizierungsprotokolls 100 erhalten werden, durchführen, einschließlich, ohne darauf beschränkt zu sein, einer Drehung der Sitzungsgeheimnis- und Sitzungsschlüssel, einer Drehung des Sitzungsschlüssels, einer Drehung der ersten und der zweiten kryptografischen Nonce und einer Drehung des HMAC-Schlüssels und der HMACs. Eine solche Drehung der Sitzungsgeheimnis- und Sitzungsschlüssel, Drehung des Sitzungsschlüssels, Drehung der ersten und der zweiten kryptografischen Nonce und Drehung des HMAC-Schlüssels und von HMACs kann erreicht werden, indem eine zweite Instanz mindestens eines Abschnitts der Handshake-Nachrichtenübermittlungs-Phase 118, insbesondere der Vorgänge 112, 114 und 116, initiiert wird.
  • In einigen Ausführungsformen können die Vorgänge 124 oder 126 eine Anzahl von Vorgängen zum Sicherstellen eines „progressiven“ und „eindeutigen“ HMAC-Schlüssels für jede Nachricht einschließen. Ein HMAC kann als ein Signaturtyp verwendet werden: Bei einer Nachricht beliebiger Länge wird die Nachricht zuerst mit einem Hash-Algorithmus (z. B. SHA256, ohne darauf beschränkt zu sein) gehasht und dann mit einem Sitzungsgeheimnis und einer oder mehreren von der ersten und der zweiten kryptografischen Nonce kombiniert, um einen Fingerabdrucktyp zu erhalten, der dieser spezifischen Nachricht zugeordnet ist - den HMAC. Der Fingerabdruck ist einer spezifischen Nachricht zugeordnet, da der Hash-Algorithmus den Fingerabdruck dem Inhalt der Nachricht selbst (ähnlich einem reinen SHA) und optional einem HMAC-Schlüssel (was eine gewisse Stärke hinzufügt, weil zur korrekten Berechnung der Nachricht der HMAC-Schlüssel erforderlich ist) zuordnet.
  • Bei einer konstanten Nachricht ist ein mit einem gegebenen HMAC-Schlüssel berechneter HMAC immer gleich. Um eine andere HMAC für jede Nachricht (selbst für Nachrichten mit demselben Inhalt) zu erhalten, wird deshalb ein „Salt“ zur Berechnung des HMAC hinzugefügt, sodass der HMAC von dem Salt, der Nachricht und dem HMAC-Schlüssel abhängt. Um ein „Salt“ zu verwenden, ist die Art des Berechnens des Salts jeder Partei vorab bekannt. Deshalb wird in einigen Ausführungsformen ein bekanntes „Salt“ (z. B. das Sitzungsgeheimnis, ohne darauf beschränkt zu sein) auf die erste Berechnung des HMAC angewendet, und dann wird jeder nachfolgende HMAC unter Verwendung des vorherigen HMAC und HMAC-Schlüssels berechnet - hierin als „progressive“ HMAC-Erzeugung bezeichnet. Bei Vorgang 128 beendet das Authentifizierungsprotokoll 100 die in der Handshake-Nachrichtenübermittlungs-Phase 118 hergestellte sichere Kommunikationssitzung. Als ein nicht einschränkendes Beispiel kann die sichere Kommunikationssitzung als Reaktion auf eine affirmative Nachricht durch eine der Parteien enden, die die andere Partei anweist (z. B. anweist oder informiert, ohne darauf beschränkt zu sein), die Kommunikationssitzung zu beenden. Als ein weiteres nicht einschränkendes Beispiel kann die sichere Kommunikationssitzung als Reaktion darauf enden, dass eine Schwellenwertanzahl von Nachrichten zwischen den Parteien kommuniziert wird. Als ein weiteres nicht einschränkendes Beispiel kann die sichere Kommunikationssitzung als Reaktion darauf enden, dass eine Partei den Ablauf (z. B. unter Verwendung eines Zeit- oder Nachrichtenzählers, ohne darauf beschränkt zu sein) kryptografischer Informationen ohne Drehung durch eine oder mehrere der Parteien, wie den Ablauf eines Sitzungsgeheimnisses, Sitzungsschlüssels, HMAC-Schlüssels oder HMAC, erfasst.
  • 2 ist ein Flussdiagramm, das einen Prozess 200 zum Austauschen von Identitätsinformationen und zum Verifizieren der Identität als Teil einer Handshake-Nachrichtenübermittlungs-Phase eines Authentifizierungsprotokolls gemäß einer oder mehreren Ausführungsformen, wie bei Vorgang 106, Vorgang 108 und Vorgang 110 des Authentifizierungsprotokolls 100, ohne darauf beschränkt zu sein, darstellt.
  • Bei Vorgang 202 wählt der Prozess 200 Informationen aus, die in einem oder mehreren spezifischen Feldern eines ersten Vorrichtungszertifikats einer Partei gespeichert sind.
  • Bei Vorgang 204 erzeugt der Prozess 200 einen ersten Vorrichtungszertifikatabschnitt, der die ausgewählten Informationen umfasst, einen eigenen öffentlichen Schlüssel (d. h. einen ersten öffentlichen Schlüssel) einer Partei, der aus dem privaten Schlüssel der Partei erzeugt wird, und Informationen über die Partei. Die ausgewählten Informationen, der erste öffentliche Schlüssel und Informationen über die Partei können in Feldern gespeichert werden, die dem einen oder den mehreren spezifischen Feldern des ersten Vorrichtungszertifikats von Vorgang 202 entsprechen.
  • Bei Vorgang 206 signiert der Prozess 200 den ersten Vorrichtungszertifikatabschnitt als Reaktion auf eine digitale Signatur einer vertrauenswürdigen Drittpartei, wie eines durch eine Zertifizierungsstelle authentifizierten Unterzeichners, um einen ersten Abschnitt eines signierten Vorrichtungszertifikats zu erhalten.
  • Bei Vorgang 208 sendet der Prozess 200 eine erste Nachricht einer Handshake-Nachrichtenübermittlungs-Phase des Authentifizierungsprotokolls (z. B. der Handshake-Nachrichtenübermittlungs-Phase 118). Die erste Nachricht schließt die eigene kryptografische Nonce der Partei (d. h. eine erste kryptografische Nonce) und den bei Vorgang 206 erhaltenen ersten Abschnitt eines signierten Vorrichtungszertifikats ein.
  • Bei Vorgang 210 empfängt der Prozess 200 eine zweite Nachricht einer Handshake-Nachrichtenübermittlungs-Phase des Authentifizierungsprotokolls (z. B. der Handshake-Nachrichtenübermittlungs-Phase 118). Die zweite Nachricht schließt eine zweite kryptografische Nonce und einen zweiten Abschnitt eines signierten Vorrichtungszertifikats einer zweiten (anderen) Partei der Handshake-Nachrichtenübermittlungs-Phase ein. Die Vorgänge 210 und 210 tauschen dadurch Identitätsinformationen zwischen der ersten und der zweiten Partei aus.
  • Bei Vorgang 212 erhält der Prozess 200 das Vorrichtungszertifikat der zweiten Partei durch Kombinieren des zweiten Abschnitts eines signierten Vorrichtungszertifikats der empfangenen zweiten Nachricht von Vorgang 210 mit einem teilweise vorausgefüllten Vorrichtungszertifikat, das lokal gespeichert und mit mindestens einigen Informationen vorausgefüllt ist. In einigen Ausführungsformen kann das Kombinieren ein Übertragen von Informationen vom zweiten Abschnitt eines signierten Vorrichtungszertifikats an das teilweise vorausgefüllte Vorrichtungszertifikat einschließen, bis ein geeignetes vollständiges Vorrichtungszertifikat erhalten wird. Das vorausgefüllte Vorrichtungszertifikat kann hierin mindestens teilweise basierend auf den Feldern der Vorrichtungszertifikatabschnitte, die leeren Feldern des vorausgefüllten Vorrichtungszertifikats entsprechen, als „komplementär“ zu dem ersten Abschnitt eines signierten Vorrichtungszertifikats und dem zweiten Abschnitt eines signierten Vorrichtungszertifikats gekennzeichnet sein.
  • Bei Vorgang 214 verifiziert der Prozess 200 die Identität der zweiten Partei als Reaktion auf die Identitätsinformationen in dem bei Vorgang 212 erhaltenen Vorrichtungszertifikat und erhält dadurch den öffentlichen Schlüssel der zweiten Partei, der, wie bei Vorgang 204 angegeben, im Vorrichtungszertifikatabschnitt der zweiten Partei enthalten war.
  • 3 ist ein Flussdiagramm, das einen Prozess 300 zum Durchführen eines signierten Schlüsselvereinbarungsaustauschs gemäß einer oder mehreren Ausführungsformen, wie Vorgang 112, Vorgang 114 und/oder Vorgang 116 des Authentifizierungsprotokolls 100, darstellt.
  • Bei Vorgang 302 erzeugt der Prozess 300 einen ersten flüchtigen privaten Schlüssel und einen ersten flüchtigen öffentlichen Schlüssel, indem er einen Algorithmus zur Erzeugung privater/öffentlicher Schlüssel durchführt, der durch das Protokoll für einen signierten Schlüsselvereinbarungsaustausch, der durch die Parteien durchgeführt wird (z. B. Diffie-Hellman, ohne darauf beschränkt zu sein), angegeben ist.
  • Bei Vorgang 304 signiert der Prozess 300 den ersten flüchtigen öffentlichen Schlüssel unter Verwendung eines privaten Schlüssels der ersten Partei, um einen ersten signierten flüchtigen öffentlichen Schlüssel zu erhalten. Jede Partei kann ihren eigenen privaten Schlüssel verwenden, um ihre digitale Signatur zu erzeugen und dadurch den ersten flüchtigen öffentlichen Schlüssel zu „signieren“, vorausgesetzt, dass eine jeweilige Partei durch den Prozess 200 authentifiziert wurde. Optional kann der Prozess 200 eine codierte digitale Signatur erzeugen, indem er die erzeugte digitale Signatur unter Verwendung der kryptografischen Nonce der zweiten Partei (d. h. der zweiten kryptografischen Nonce, die mit der zweiten Nachricht bei Vorgang 210 empfangen wurde) codiert, und den ersten flüchtigen öffentlichen Schlüssel unter Verwendung der codierten digitalen Signatur signieren, wodurch eine höhere Sicherheit erhalten wird.
  • Bei Vorgang 306 sendet der Prozess 300 eine dritte Nachricht, die den ersten signierten flüchtigen öffentlichen Schlüssel einschließt.
  • Bei Vorgang 308 empfängt der Prozess 300 eine vierte Nachricht, die einen zweiten signierten flüchtigen öffentlichen Schlüssel einschließt, der durch eine zweite (andere) Partei unter Verwendung ihres eigenen privaten Schlüssels signiert wird. Der zweite signierte flüchtige öffentliche Schlüssel kann verwendet werden, da der Empfänger den öffentlichen Schlüssel der zweiten Partei bei Prozess 200 erhalten hat.
  • Insbesondere bilden die dritte und die vierte Nachricht von Vorgängen 306 und 308 einen Austausch von Informationen über einen signierten Schlüsselvereinbarungsaustausch eines signierten Schlüsselvereinbarungsaustauschs, der mit einer Partei einer Handshake-Nachrichtenübermittlungs-Phase durchgeführt wird.
  • In einigen Ausführungsformen kann eine Partei den ersten und den zweiten signierten flüchtigen öffentlichen Schlüssel in Abschnitten eines signierten Vorrichtungszertifikats übertragen. Einige Felder solcher Vorrichtungszertifikatabschnitte können Feldern entsprechen, die durch ein Protokoll für den signierten Schlüsselvereinbarungsaustausch, der durch die Parteien durchgeführt wird, angegeben ist.
  • Bei Vorgang 310 erzeugen der Prozess 300 ein Sitzungsgeheimnis als Reaktion auf den zweiten flüchtigen öffentlichen Schlüssel (der dem zweiten signierten flüchtigen öffentlichen Schlüssel entspricht) der zweiten Partei und den ersten flüchtigen privaten Schlüssel der ersten Partei.
  • Bei Vorgang 312 erhält der Prozess 300 Sitzungsschlüssel als Reaktion auf das Sitzungsgeheimnis. Diese Sitzungsschlüssel sind einer spezifischen Kommunikationssitzung durch den ersten signierten und den zweiten flüchtigen Schlüssel zugeordnet, die durch die Parteien ausgetauscht wurden und jeweils durch beide Parteien verwendet wurden, um ein Sitzungsgeheimnis zu erzeugen. Der Vorgang 310, 312 stellen Schlüsselvereinbarungsaustauschberechnungen dar, wie vorstehend in Bezug auf Vorgänge 114, 116 beschrieben.
  • Bei dem optionalen Vorgang 314 dreht der Prozess 300 die Sitzungsschlüssel einer aktuellen sicheren Kommunikationssitzung durch Verwerfen des aktuellen Sitzungsgeheimnisses, der flüchtigen privaten und öffentlichen Schlüssel und der Sitzungsschlüssel und Initiieren mindestens eines Abschnitts der zweiten Handshake-Nachrichtenübermittlungs-Phase 118 des Authentifizierungsprotokolls. Neue öffentliche/private flüchtige Schlüssel, Sitzungsgeheimnisse oder Sitzungsschlüssel können durch erfolgreiches Durchführen der zweiten Handshake-Nachrichtenübermittlungs-Phase, Prozess 200 und Prozess 300, erhalten werden.
  • 4 ist ein Blockdiagramm, das ein beispielhaftes Rechensystem 400 (oder eine Recheneinrichtung) zum Durchführen von Vorgängen eines Authentifizierungsprotokolls 100 gemäß einer oder mehreren Ausführungsformen darstellt. Das Rechensystem 400 kann einen System-on-a-chip-Prozessor (SoC-Prozessor) oder Mikrocontroller 402 einschließen, der über eine E/A-geschützte Verbindung 436 mit einem Kryptoelement 408 gekoppelt ist.
  • In dem spezifischen nicht einschränkenden Beispiel, das durch 4 dargestellt ist, schließt der SoC-Prozessor oder -Mikrocontroller 402 maschinenausführbare Anweisungen für benutzerdefinierte Anwendungen 414 einer unsicheren Firmware 404 und maschinenausführbare Anweisungen für Kommunikationsprotokolle 412, Systemanwendungen 416, sichere Speicherung 418 und Kryptografiealgorithmen (Verifizierung, Signaturen) und Anwendungsprogrammierschnittstellen (APIs) 410 einer sicheren Firmware 406 ein.
  • Kryptografiealgorithmen (Verifizierung, Signaturen) und APIs 410 können maschinenausführbare Anweisungen von Protokollen zum Kommunizieren mit einem Kryptoelement 408 zur Unterstützung der Kommunikationsprotokolle 412 sein. Die Kommunikationsprotokolle 412 können maschinenausführbare Anweisungen zum Kommunizieren gemäß dem Protokoll zur gegenseitigen Authentifizierung 420 und zur Nachrichtenverschlüsselung/-entschlüsselung 422 einschließen. In einigen Ausführungsformen kann die Nachrichtenverschlüsselung/-entschlüsselung 422 maschinenausführbare Anweisungen zum Durchführen einer sicheren E/A-Kommunikation mit einer Vorrichtung, wie dem Kryptoelement 408, ohne darauf beschränkt zu sein, einschließen.
  • Das Kryptoelement 408 kann im Allgemeinen konfiguriert sein, um verschiedene kryptografische Funktionen, wie sichere Speicherung und kryptografische Berechnungen, ohne darauf beschränkt zu sein, zu unterstützen. Wie durch 4 dargestellt, schließt das Kryptoelement 408 eine Schlüsselspeicherung 426 und Hardware-beschleunigte mathematische Funktionen 424 ein.
  • Die Schlüsselspeicherung 426 kann Speicher und maschinenausführbare Anweisungen zum Speichern von einem oder mehreren von flüchtigen privaten Schlüsseln, Sitzungsschlüsseln und Sitzungsgeheimnissen des Authentifizierungsprotokolls 100, Prozess 200 und Prozess 300, wie hierin erörtert, umfassen. Hardware-beschleunigte mathematische Funktionen 424 können maschinenausführbare Anweisungen zum Durchführen einer Kryptoverifizierung 428, einer Berechnung flüchtiger Schlüssel 430 (z. B. eine Schlüsselableitungsfunktion zum Erzeugen eines flüchtigen öffentlichen Schlüssels gemäß einem Diffie-Hellman-Protokoll), einer HKDF-Ableitungsfunktion 432 (d. h. einer Schlüsselableitungsfunktion, die eine Hash-basierte einfache Schlüsselableitungsfunktion verwendet) und optional anderer algorithmusspezifischer Ableitungen 434 gemäß offenbarten Ausführungsformen einschließen.
  • Obwohl in dem durch 4 dargestellten spezifischen nicht einschränkenden Beispiel nicht enthalten, können in einigen Ausführungsformen maschinenausführbare Anweisungen für eine Hash-basierte Funktion zum Erzeugen von Hash-basierten Nachrichtenauthentifizierungscodes (HMACs), die für Nachrichtenauthentifizierungsberechnungen basierend auf einer Nachricht und einem HMAC-Schlüssel verwendet werden, in der sicheren Firmware 406 oder den Hardware-beschleunigten mathematischen Funktionen 424 enthalten sein.
  • 5 ist ein Blockdiagramm, das Beispiele für kryptografische Informationen 500 darstellt, die gemäß einer oder mehreren Ausführungsformen gespeichert, erzeugt oder verwendet werden. Eine oder mehrere der Informationen der kryptografischen Informationen 500 können in einem flüchtigen oder nichtflüchtigen Speicher gespeichert werden, der durch eine unsichere Firmware 404 oder eine sichere Firmware 406 oder einen sicheren Speicher des Kryptoelements 408, das der Schlüsselspeicherung 426 zugeordnet ist, verwendet wird. Wie durch 5 dargestellt, können Vorrichtungsinformationen einen vorgespeicherten Zertifikatabschnitt 502, ein signiertes Zertifikat 504 und E/A-Schutzschlüssel 506 (z. B. zum Herstellen der E/A-geschützten Verbindung 436 verwendet) einer Vorrichtung einschließen.
  • Sitzungsspezifische Informationen können kryptografische Informationen einschließen, die einer spezifischen Kommunikationssitzung (z. B. der Phase der verschlüsselten Kommunikation 130) zugeordnet sind, die als Reaktion auf die Handshake-Nachrichtenübermittlungs-Phase 118 des Authentifizierungsprotokolls 100 hergestellt wird. Wie durch 5 dargestellt, können kryptografische Informationen von sitzungsspezifischen Informationen das abgeschlossene signierte Vorrichtungszertifikat 510 der anderen Partei, einen eigenen signierten Zertifikatabschnitt 516 einer Vorrichtung, die kryptografische Nonce 520 der anderen Partei, einen eigenen flüchtigen privaten Schlüssel 524, den flüchtigen öffentlichen Schlüssel 526 der anderen Partei, ein Sitzungsgeheimnis 528, Sitzungsschlüssel 530 und einen HMAC-Schlüssel 522 einschließen.
  • Wie durch 5 dargestellt, kann ein abgeschlossenes signiertes Vorrichtungszertifikat 510 einer anderen Partei vorausgefüllte Felder 512 - d. h. mit Informationen vorausgefüllt, die bereits lokal gespeichert sind - einschließen. In dem spezifischen Beispiel, das durch 5 dargestellt ist, werden die vorausgefüllten Felder 512 unter Verwendung von Informationen entsprechender Felder des vorgespeicherten Zertifikatabschnitts 502 gefüllt, und abgeschlossene Felder 514 werden unter Verwendung von Informationen aus dem Abschnitt eines signierten Vorrichtungszertifikats 508, der von der anderen Partei einer Handshake-Nachrichtenübermittlungs-Phase eines Authentifizierungsprotokolls empfangen wird, gefüllt. Der eigene signierte Vorrichtungszertifikatabschnitt 516 der lokalen Vorrichtung kann Felder 518 einschließen, die unter Verwendung von Informationen aus dem signierten Zertifikat 504 einer Vorrichtung gefüllt werden. Die verbleibenden kryptografischen Informationen von sitzungsspezifischen Informationen können gemäß Vorgängen des Authentifizierungsprotokolls 100, Prozess 200 und Prozess 300, wie vorstehend erörtert, erzeugt werden.
  • 6 ist ein Blockdiagramm, das ein nicht einschränkendes Beispiel eines Vorrichtungszertifikats 600 darstellt. Das beispielhafte Vorrichtungszertifikat 600 schließt Felder und darin angegebene Informationen ein, die an einen Vorrichtungszertifikatabschnitt übertragen werden können, wie Felder zum Angeben von Ausstellerinformationen 606, Informationen über eine Partei 610 (d. h. Inhaberinformationen) und den öffentlichen Schlüssel 614 einer Partei (d. h. den öffentlichen Schlüssel des Inhabers). Felder zum Angeben anderer Informationen, die nicht notwendigerweise an einen Zertifikatabschnitt übertragen werden, schließen Felder für Versionsinformationen 602, Signaturalgorithmus 604, Gültigkeitsdauer 608 und Algorithmus des öffentlichen Schlüssels des Inhabers 612 ein.
  • 7 zeigt ein Blockdiagramm eines Systems zur gegenseitigen Authentifizierung 700 gemäß einer oder mehreren Ausführungsformen. In diesem Beispiel steht der Client 702 in Kommunikation mit einem Bereitstellungsserver 704, der konfiguriert ist, um Bereitstellungsinformationen zum Verbinden eines Systems zugehöriger Vorrichtungen gemäß einem Bereitstellungsprozess 708 nach dem Durchführen eines Authentifizierungsprozesses 706 (z. B. des Authentifizierungsprotokolls 100), beide über die Kommunikationsverbindung 710, an den Client 702 bereitzustellen. Bereitstellungsinformationen können als ein nicht einschränkendes Beispiel Konfigurationsinformationen für Vorrichtungen einschließen, die ein System zugehöriger Vorrichtungen mit niedrigem Durchsatz verbinden oder Teil davon sind.
  • Die Kommunikationsverbindung 710 kann eine Verbindung für eine Datenübertragung mit niedrigem Durchsatz (z. B. eine Verbindung mit niedrigem Durchsatz), wie eine drahtverbundene Punkt-zu-Punkt-Verbindung (P2P-Verbindung), eine drahtlose P2P-Verbindung oder Kombinationen davon sein, ohne darauf beschränkt zu sein. Drahtverbundene und/oder drahtlose Verbindungen für eine Datenübertragung mit niedrigem Durchsatz können eines oder mehrere einschließen von: Bluetooth Low Energy (BLE), Lora, 2,4 GHz-Funk, subGHz-Funk, einem Universal Asynchronous Receiver Transmitter-Bus (USART-Bus), einem Serial Peripheral Interface-Bus (SPI-Bus), einem Inter-Inter Connect-Bus (I2C-Bus), einem Controller Area Network-Bus (CAN-Bus), einem Local Interconnect Network-Bus (LIN-Bus) und einem Universal Serial Bus (USB), ohne darauf beschränkt zu sein. Als ein nicht einschränkendes Beispiel kann eine Kommunikationsverbindung mit niedrigem Durchsatz eine Kommunikationsverbindung sein, die für 10 Kilobyte pro Sekunde oder weniger konfiguriert ist.
  • Während des Durchführens des Authentifizierungsprozesses 706 kann die Kommunikationsverbindung 710 eine unsichere Verbindung während der Handshake-Nachrichtenübermittlungs-Phase 118 und dann eine sichere Verbindung während der Phase der verschlüsselten Kommunikation 130 sein. Der Bereitstellungsprozess 708 kann während mindestens eines Teils der Phase der verschlüsselten Kommunikation 130 durchgeführt werden. Nach Abschluss des Bereitstellungsprozesses 708 kann die Phase der verschlüsselten Kommunikation 130 enden (z. B. die sichere Kommunikationssitzung, die der Phase der verschlüsselten Kommunikation 130 zugeordnet ist, beenden).
  • Als nicht einschränkendes Beispiel für einen Nachteil eines herkömmlichen Ansatzes, der den Erfindern dieser Offenbarung bekannt ist, sind solche Ansätze komplex und erfordern eine Geschwindigkeit (z. B. Datendurchsätze, ohne darauf beschränkt zu sein), die darüber hinausgeht, wozu Mikrocontroller mit niedriger Leistung und Verbindungen mit niedrigem Durchsatz, die den Erfindern dieser Offenbarung bekannt sind, in der Lage sind. Als ein weiteres nicht einschränkendes Beispiel für einen Nachteil eines herkömmlichen Ansatzes, der den Erfindern dieser Offenbarung bekannt ist, können sichere Elemente, wie Elliptical-Curve Cryptography (ECC), mathematische Operationen und die Speicherung unterstützen, werden jedoch nicht verwendet, um ein System selbst zu sichern - sie werden üblicherweise zur Beschleunigung und zum Schutz von Vorgängen verwendet und müssen auf geeignete Weise durch ein Protokoll verwendet werden.
  • Es versteht sich für den Durchschnittsfachmann, dass Funktionselemente von hierin offenbarten Ausführungsformen (z. B. Funktionen, Operationen, Handlungen und/oder Verfahren) in jeder geeigneten Hardware, Software, Firmware oder Kombinationen davon implementiert werden können. 8 veranschaulicht nicht einschränkende Beispiele für Implementierungen von hierin offenbarten Funktionselementen. In einigen Ausführungsformen können einige oder alle Teile der hierin offenbarten Funktionselemente durch Hardware ausgeführt werden, die speziell zum Ausführen der Funktionselemente konfiguriert ist.
  • 8 ist ein Blockdiagramm, das eine beispielhafte Nachrichtenübermittlung 800 für eine Handshake-Nachrichtenübermittlungs-Phase eines Authentifizierungsprotokolls darstellt. Die erste Nachricht 802 und die zweite Nachricht 804 werden als Teil eines Identifizierungsinformationsaustauschs, wie des Identitätsinformationsaustauschs von Vorgang 106 von 1, gesendet. Wie dargestellt, schließt jede Nachricht einen Vorrichtungszertifikatabschnitt (hier ein Telefonzertifikat), das durch einen „Unterzeichner“ signiert ist, ein Unterzeichnerzertifikat, das durch eine Zertifizierungsstelle signiert ist, und eine kryptografische Nonce (hier eine 32-Byte-Zufallszahl) ein. Die dritte Nachricht 806 und die vierte Nachricht 808 werden als Teil eines Austauschs von Schlüsselvereinbarungsinformationen eines signierten Schlüsselvereinbarungsaustauschprotokolls von Vorgang 112 von 1 gesendet. Wie dargestellt, schließt jede Nachricht einen signierten flüchtigen öffentlichen Schlüssel (d. h. mit einer digitalen Signatur signiert, die unter Verwendung des flüchtigen privaten Schlüssels des Senders erzeugt wird) ein.
  • 9 ist ein Blockdiagramm einer Schaltlogik 900, die in einigen Ausführungsformen verwendet werden kann, um verschiedene hierin offenbarte Funktionen, Vorgänge, Aktionen, Prozesse und/oder Verfahren zu implementieren. Die Schaltlogik 900 schließt einen oder mehrere Prozessoren 902 (hierin manchmal als „Prozessoren 902“ bezeichnet) ein, die betriebsfähig mit einer oder mehreren Datenspeicherungsvorrichtungen (hierin manchmal als „Speicherung 904“ bezeichnet) gekoppelt sind. Die Speicherung 904 schließt einen darauf gespeicherten maschinenausführbaren Code 906 ein, und die Prozessoren 902 schließen die Logikschaltlogik 908 ein. Der maschinenausführbare Code 906 schließt Informationen ein, die Funktionselemente beschreiben, die durch die Logikschaltlogik 908 implementiert (z. B. durchgeführt) werden können. Die Logikschaltlogik 908 ist dafür ausgelegt, die durch den maschinenausführbaren Code 906 beschriebenen Funktionselemente zu implementieren (z. B. durchzuführen). Die Schaltlogik 900 sollte beim Ausführen der durch den maschinenausführbaren Code 906 beschriebenen Funktionselemente als Spezialhardware betrachtet werden, die zum Ausführen von hierin offenbarten Funktionselementen konfiguriert ist. In einigen Ausführungsformen können die Prozessoren 902 konfiguriert sein, um die durch den maschinenausführbaren Code 906 beschriebenen Funktionselemente sequentiell, gleichzeitig (z. B. auf einer oder mehreren unterschiedlichen Hardwareplattformen) oder in einem oder mehreren parallelen Prozessströmen durchzuführen.
  • Wenn er durch die Logikschaltlogik 908 der Prozessoren 902 implementiert wird, ist der maschinenausführbare Code 906 konfiguriert, um die Prozessoren 902 anzupassen, um Vorgänge der hierin offenbarten Ausführungsformen durchzuführen. Zum Beispiel kann der maschinenausführbare Code 906 konfiguriert sein, um die Prozessoren 902 anzupassen, um mindestens einen Abschnitt oder eine Gesamtheit der Merkmale und Funktionen, die unter Bezugnahme auf das Rechensystem 400 und genauer den SoC-Prozessor oder -Mikrocontroller 402, die unsichere Firmware 404, die sichere Firmware 406, die benutzerdefinierten Anwendungen 414, die Systemanwendungen 416, die sichere Speicherung 418, die Kommunikationsprotokolle 412, das Protokoll zur gegenseitigen Authentifizierung 420, die Nachrichtenverschlüsselung/-entschlüsselung 422, die Kryptografiealgorithmen (Verifizierung, Signaturen) und APIs 410, das Kryptoelement 408, die Schlüsselspeicherung 426, die Hardware-beschleunigten mathematischen Funktionen 424, die Kryptoverifizierung 428, die Berechnung flüchtiger Schlüssel 430, den HMAC-Schlüssel 434 und andere algorithmus spezifische Ableitungen erörtert werden, durchzuführen. Als weiteres Beispiel kann der maschinenausführbare Code 906 konfiguriert sein, um die Prozessoren 902 anzupassen, um mindestens einen Abschnitt oder eine Gesamtheit der für das Authentifizierungsprotokoll 100, Prozess 200 und Prozess 300, erörterten Vorgänge durchzuführen. Als weiteres Beispiel kann der maschinenausführbare Code 906 konfiguriert sein, um die Prozessoren 902 anzupassen, um mindestens einen Abschnitt oder eine Gesamtheit der für das System zur gegenseitigen Authentifizierung 700, den Client 702 und den Bereitstellungsserver 704 erörterten Vorgänge durchzuführen.
  • Die Prozessoren 902 können einen Universalprozessor, einen Spezialprozessor, eine Zentralverarbeitungseinheit (CPU), einen Mikrocontroller, eine speicherprogrammierbare Steuerung (SPS), einen Digitalsignalprozessor (DSP), eine anwendungsspezifische integrierte Schaltung (ASIC), eine feldprogrammierbare Gatteranordnung (FPGA) oder eine andere programmierbare Logikvorrichtung, diskrete Gatter- oder Transistorlogik, diskrete Hardwarekomponenten, eine andere programmierbare Vorrichtung oder eine beliebige Kombination davon, die zum Durchführen der hierin offenbarten Funktionen ausgelegt ist, einschließen. Ein Universalcomputer, einschließlich eines Prozessors, wird als Spezialcomputer angesehen, während der Universalcomputer so konfiguriert ist, dass dieser Funktionselemente entsprechend dem maschinenausführbaren Code 906 (z. B. Softwarecode, Firmwarecode, Hardwarebeschreibungen) ausführt, der sich auf Ausführungsformen der vorliegenden Offenbarung bezieht. Es wird darauf hingewiesen, dass ein Universalprozessor (der hierin auch als Host-Prozessor oder einfach als Host bezeichnet werden kann) ein Mikroprozessor sein kann, aber alternativ können die Prozessoren 902 eine(n) beliebige(n) herkömmliche(n) Prozessor, Steuerung, Mikrocontroller oder Zustandsautomat einschließen. Die Prozessoren 902 können auch als eine Kombination von Rechenvorrichtungen, wie eine Kombination aus einem DSP und einem Mikroprozessor, eine Vielzahl von Mikroprozessoren, einen oder mehrere Mikroprozessoren in Verbindung mit einem DSP-Kern oder eine beliebige andere derartige Konfiguration implementiert sein.
  • In einigen Ausführungsformen schließt die Speicherung 904 eine flüchtige Datenspeicherung (z. B. Direktzugriffsspeicher (RAM)), eine nichtflüchtige Datenspeicherung (z. B. Flash-Speicher, ein Festplattenlaufwerk, ein Solid-State-Laufwerk, löschbaren programmierbaren Nur-Lese-Speicher (EPROM) usw.) ein. In einigen Ausführungsformen können die Prozessoren 902 und die Speicherung 904 in einer einzelnen Vorrichtung implementiert sein (z. B. einem Halbleitervorrichtungsprodukt, einem System-on-Chip (SOC) usw.). In einigen Ausführungsformen können die Prozessoren 902 und die Speicherung 904 in separaten Vorrichtungen implementiert sein.
  • In einigen Ausführungsformen kann der maschinenausführbare Code 906 computerlesbare Anweisungen (z. B. Softwarecode, Firmwarecode) einschließen. Als nicht einschränkendes Beispiel können die computerlesbaren Anweisungen durch die Speicherung 904 gespeichert werden, es kann direkt durch die Prozessoren 902 auf diese zugegriffen werden und diese können durch die Prozessoren 902 unter Verwendung mindestens der Logikschaltlogik 908 ausgeführt werden. Ebenfalls als nicht einschränkendes Beispiel können die computerlesbaren Anweisungen auf der Speicherung 904 gespeichert, zur Ausführung an eine Speichervorrichtung (nicht gezeigt) übertragen und durch die Prozessoren 902 unter Verwendung mindestens der Logikschaltlogik 908 ausgeführt werden. Dementsprechend schließt die Logikschaltlogik 908 in einigen Ausführungsformen eine elektrisch konfigurierbare Logikschaltlogik 908 ein.
  • In einigen Ausführungsformen kann der maschinenausführbare Code 906 Hardware (z. B. Schaltlogik) beschreiben, die in der Logikschaltlogik 908 implementiert werden soll, um die Funktionselemente durchzuführen. Diese Hardware kann auf einer Vielzahl von Abstraktionsebenen beschrieben werden, von Low-Level-Transistor-Layouts bis zu High-Level-Beschreibungssprachen. Auf einer hohen Abstraktionsstufe kann eine Hardwarebeschreibungssprache (HDL), wie beispielsweise eine IEEE-Standard-Hardwarebeschreibungssprache (HDL), verwendet werden. Als nicht einschränkende Beispiele können Verilog™, SystemVerilog™ oder Hardwarebeschreibungssprachen (VHDL™) mit Very Large Scale Integration (VLSI) verwendet werden.
  • HDL-Beschreibungen können nach Belieben in Beschreibungen auf einer beliebigen von zahlreichen anderen Abstraktionsebenen umgewandelt werden. Als nicht einschränkendes Beispiel kann eine Beschreibung auf hoher Ebene in eine Beschreibung auf Logikebene umgewandelt werden, wie beispielsweise eine Register-Übertragungssprache (RTL), eine Beschreibung auf Gate-Ebene (GL), eine Beschreibung auf Layout-Ebene oder eine Beschreibung auf Masken-Ebene. Als ein nicht einschränkendes Beispiel können Mikrooperationen, die durch Hardwarelogikschaltlogiken (z. B. Gatter, Flip-Flops, Register, ohne darauf beschränkt zu sein) der Logikschaltlogik 908 durchgeführt werden sollen, in einer RTL beschrieben und dann durch ein Synthesewerkzeug in eine GL-Beschreibung umgewandelt werden, und die GL-Beschreibung kann durch ein Platzierungs- und Routing-Werkzeug in eine Beschreibung auf Layout-Ebene umgewandelt werden, die einem physischen Layout einer integrierten Schaltung einer programmierbaren Logikvorrichtung, diskreter Gatter- oder Transistorlogik, diskreten Hardwarekomponenten oder Kombinationen davon entspricht. Dementsprechend kann der maschinenausführbare Code 906 in einigen Ausführungsformen eine HDL, eine RTL, eine GL-Beschreibung, eine Maskenebenenbeschreibung, eine andere Hardwarebeschreibung oder eine beliebige Kombination davon einschließen.
  • In Ausführungsformen, in denen der maschinenausführbare Code 906 eine Hardwarebeschreibung (auf beliebiger Abstraktionsebene) einschließt, kann ein System (nicht gezeigt, aber die Speicherung 904 einschließend) konfiguriert sein, um die durch den maschinenausführbaren Code 906 beschriebene Hardwarebeschreibung zu implementieren. Als nicht einschränkendes Beispiel können die Prozessoren 902 eine programmierbare Logikvorrichtung (z. B. eine FPGA oder eine SPS) einschließen, und die Logikschaltlogik 908 kann elektrisch gesteuert werden, um eine der Hardwarebeschreibung entsprechende Schaltlogik in der Logikschaltlogik 908 zu implementieren. Ebenfalls als nicht einschränkendes Beispiel kann die Logikschaltlogik 908 eine festverdrahtete Logik einschließen, die durch ein Fertigungssystem (nicht gezeigt) hergestellt wird, jedoch einschließlich der Speicherung 904 gemäß der Hardwarebeschreibung des maschinenausführbaren Codes 906.
  • Ungeachtet dessen, ob der maschinenausführbare Code 906 computerlesbare Anweisungen oder eine Hardwarebeschreibung einschließt, ist die Logikschaltlogik 908 dafür ausgelegt, die durch den maschinenausführbaren Code 906 beschriebenen Funktionselemente durchzuführen, wenn die Funktionselemente des maschinenausführbaren Codes 906 implementiert werden. Es sei darauf hingewiesen, dass, obwohl eine Hardwarebeschreibung Funktionselemente möglicherweise nicht direkt beschreibt, eine Hardwarebeschreibung indirekt Funktionselemente beschreibt, welche die durch die Hardwarebeschreibung beschriebenen Hardwareelemente ausführen können.
  • Ein Durchschnittsfachmann wird viele Nutzwirkungen und Vorteile der offenbarten Ausführungsformen erkennen. Als nicht einschränkendes Beispiel können offenbarte Ausführungsformen verwendet werden, um komplexe Stapel über Hardware mit niedrigem Durchsatz (z. B. eine Netzwerkausrüstung) zu übertragen. Als ein weiteres nicht einschränkendes Beispiel können offenbarte Ausführungsformen ein Komprimieren (z. B. Verringern, ohne darauf beschränkt zu sein) der Anzahl und Länge von Nachrichten, die für die Handshake-Phase ausgetauscht werden, im Vergleich zu herkömmlichen Protokollen, die den Erfindern dieser Offenbarung bekannt sind (z. B. TLS, ohne darauf beschränkt zu sein), einschließen. Als ein weiteres nicht einschränkendes Beispiel können offenbarte Ausführungsformen eine gegenseitige Authentifizierung und einen sicheren Vormastergeheimnisaustausch über ECDH in, als ein spezifisches nicht einschränkendes Beispiel, im Wesentlichen einer Sekunde über eine Verbindung mit 80 Kilobits pro Sekunde sicherstellen. Als ein weiteres nicht einschränkendes Beispiel können nur zwei X.509-Zertifikate gesendet werden, um die Identität jeder Partei zu bestimmen. Als ein weiteres nicht einschränkendes Beispiel können offenbarte Ausführungsformen einen Satz von drei (3) abgeleiteten Schlüsseln erzeugen, die für jede sichere Kommunikationssitzung unterschiedlich sind, um AES, CBC und Salted-HMAC für Vertraulichkeit und Integrität durchzuführen. Als ein weiteres nicht einschränkendes Beispiel können offenbarte Ausführungsformen automatisch eine Sitzungsschlüsseldrehung in periodischen oder zufälligen Intervallen durchführen. Als ein weiteres nicht einschränkendes Beispiel können offenbarte Ausführungsformen in Netzwerken verwendet werden für: Zugangskontrolle, medizinische Vorrichtungen, Patientenüberwachung, digitale Gesundheit, Haus- und Gebäudeautomation, Alarmanlagen, Kraftfahrzeuge und militärische Anwendungen ohne darauf beschränkt zu sein.
  • Wie in der vorliegenden Offenbarung verwendet, können die Begriffe „Modul“ oder „Komponente“ auf spezifische Hardware-Implementierungen Bezug nehmen, die konfiguriert sind, um die Aktionen des Moduls oder der Komponente und/oder Softwareobjekte oder Softwareroutinen, die auf Universalhardware (z. B. computerlesbaren Medien, Verarbeitungsvorrichtungen, ohne darauf beschränkt zu sein) des Rechensystems gespeichert und/oder durch diese ausgeführt werden können, durchzuführen. In einigen Ausführungsformen können die verschiedenen Komponenten, Module, Engines und Dienste, die in der vorliegenden Offenbarung beschrieben sind, als Objekte oder Prozesse implementiert werden, die auf dem Rechensystem ausgeführt werden (z. B. als separate Threads, ohne darauf beschränkt zu sein). Obwohl einige der in der vorliegenden Offenbarung beschriebenen Systeme und Verfahren allgemein als in Software implementiert (gespeichert auf und/oder ausgeführt durch Universalhardware) beschrieben sind, sind spezifische Hardware-Implementierungen oder eine Kombination von Software und spezifischen Hardware-Implementierungen ebenfalls möglich und werden in Betracht gezogen.
  • Wie in der vorliegenden Offenbarung verwendet, kann der Begriff „Kombination“ in Bezug auf eine Vielzahl von Elementen eine Kombination aller Elemente oder eine beliebige von verschiedenen unterschiedlichen Unterkombinationen einiger der Elemente einschließen. Zum Beispiel kann die Phrase „A, B, C, D oder Kombinationen davon“ Bezug nehmen auf eines von A, B, C oder D; die Kombination von jedem von A, B, C und D; und jede Unterkombination von A, B, C oder D, wie A, B und C; A, B und D; A, C und D; B, C und D; A und B, A und C; A und D; B und C; B und D; oder C und D.
  • Begriffe, die in der vorliegenden Offenbarung und insbesondere in den beiliegenden Ansprüchen (z. B. Hauptteilen der beiliegenden Ansprüche, ohne darauf beschränkt zu sein) verwendet werden, sind allgemein als „offene“ Begriffe gedacht (z. B. sollte der Begriff „einschließlich“ als „einschließlich, ohne darauf beschränkt zu sein“ interpretiert werden, der Begriff „aufweisend“ sollte als „mindestens aufweisend“ interpretiert werden, der Begriff „schließt ein“ sollte als „schließt ein, ohne darauf beschränkt zu sein“ interpretiert werden, ohne darauf beschränkt zu sein). Wie hierin verwendet, bedeutet der Begriff „jedes“ einige oder eine Gesamtheit. Wie hierin verwendet, bedeutet der Begriff „alle“ eine Gesamtheit.
  • Darüber hinaus wird, wenn eine bestimmte Anzahl von einer eingeführten Anspruchsangabe beabsichtigt ist, diese Absicht ausdrücklich im Anspruch genannt, und in Ermangelung dieser Nennung liegt keine solche Absicht vor. Als Verständnishilfe können zum Beispiel die folgenden beiliegenden Ansprüche die Verwendung der einleitenden Phrasen „mindestens eine/r/s“ und „eine/r/s oder mehrere“ zum Einführen von Anspruchsangaben enthalten. Die Verwendung solcher Formulierungen sollte jedoch nicht dahin gehend ausgelegt werden, dass sie impliziert, dass die Einführung einer Anspruchsangabe durch die unbestimmten Artikel „ein“ oder „eine“ einen bestimmten Anspruch, der eine solche eingeführte Anspruchsangabe enthält, auf Ausführungsformen beschränkt, die nur eine solche Angabe enthalten, selbst wenn derselbe Anspruch die einleitenden Phrasen „eine/r/s oder mehrere“ oder „mindestens eine/r/s“ und unbestimmte Artikel wie „ein“ und/oder „eine“ einschließt (z. B. soll „ein“ und/oder „eine“ so interpretiert werden, dass es „mindestens ein/e“ oder „ein/e oder mehrere“ bedeutet); gleiches gilt für die Verwendung von bestimmten Artikeln, die zur Einführung von Anspruchsangaben verwendet werden.
  • Auch wenn eine bestimmte Anzahl einer eingeführten Anspruchsangabe explizit angegeben wird, wird der Fachmann zusätzlich erkennen, dass eine solche Angabe dahin gehend interpretiert werden sollte, dass sie mindestens die angegebene Anzahl bedeutet (z. B. bedeutet die bloße Angabe von „zwei Angaben“ ohne andere Modifikatoren mindestens zwei Angaben oder zwei oder mehr Angaben). Des Weiteren ist in den Fällen, in denen eine Konvention analog zu „mindestens eines von A, B und C usw.“ oder „eines oder mehrere von A, B und C usw.“ verwendet wird, eine solche Konstruktion im Allgemeinen, A allein, B allein, C allein, A und B zusammen, A und C zusammen, B und C zusammen oder A, B und C zusammen usw. bedeuten soll.
  • Ferner sollte jedes disjunkte Wort oder jede disjunkte Formulierung, das bzw. die zwei oder mehr alternative Begriffe darstellt, sei es in der Beschreibung, den Ansprüchen oder den Zeichnungen, dahin gehend verstanden werden, dass die Möglichkeit des Einschließens eines der Begriffe, des einen oder des anderen Begriffs oder beider Begriffe in Betracht gezogen wird. Zum Beispiel sollte die Formulierung „A oder B“ so verstanden werden, dass sie die Möglichkeiten „A“ oder „B“ oder „A und B“ einschließt.
  • Zusätzliche, nicht einschränkende Ausführungsformen der Offenbarung schließen ein:
    • Ausführungsform 1: Verfahren zum Durchführen einer Seite eines Handshakes zur gegenseitigen Authentifizierung, das Verfahren umfassend: Austauschen von Identitätsinformationen mit einer Partei über eine erste Nachrichtenübermittlung einer Handshake-Nachrichtenübermittlungs-Phase, wobei die erste Nachrichtenübermittlung umfasst: Senden einer ersten Nachricht, wobei die erste Nachricht eine erste kryptografische Nonce und einen ersten Abschnitt eines signierten Vorrichtungszertifikats umfasst; und Empfangen einer zweiten Nachricht, wobei die zweite Nachricht eine zweite kryptografische Nonce und einen zweiten Abschnitt eines signierten Vorrichtungszertifikats umfasst, und Austauschen von Informationen über einen signierten Schlüsselvereinbarungsaustausch eines signierten Schlüsselvereinbarungsaustauschs mit der Partei über eine zweite Nachrichtenübermittlung der Handshake-Nachrichtenübermittlungs-Phase, wobei die zweite Nachrichtenübermittlung umfasst:
      • Senden einer dritten Nachricht, wobei die dritte Nachricht einen ersten signierten flüchtigen öffentlichen Schlüssel umfasst; und Empfangen einer vierten Nachricht, wobei die vierte Nachricht einen zweiten signierten flüchtigen öffentlichen Schlüssel umfasst.
      • Ausführungsform 2: Verfahren nach Ausführungsform 1, ferner umfassend: Auswählen von Informationen, die in einem oder mehreren spezifischen Feldern eines ersten Vorrichtungszertifikats gespeichert sind; Erzeugen eines ersten
      • Vorrichtungszertifikatabschnitts, der die ausgewählten Informationen umfasst; und Signieren des ersten Vorrichtungszertifikatabschnitts als Reaktion auf eine digitale Signatur einer vertrauenswürdigen Drittpartei, um den ersten Abschnitt eines signierten Vorrichtungszertifikats zu erzeugen.
    • Ausführungsform 3: Verfahren nach einer der Ausführungsformen 1 und 2, ferner umfassend: Erhalten eines Vorrichtungszertifikats der Partei durch Kombinieren des zweiten Abschnitts eines signierten Vorrichtungszertifikats und eines teilweise vorausgefüllten Vorrichtungszertifikats.
    • Ausführungsform 4: Verfahren nach einer der Ausführungsformen 1 bis 3, wobei das Kombinieren des zweiten Abschnitts eines signierten Vorrichtungszertifikats und des teilweise vorausgefüllten Vorrichtungszertifikats umfasst: Kombinieren des zweiten Abschnitts eines signierten Vorrichtungszertifikats mit einem Abschnitt des vorausgefüllten Vorrichtungszertifikats, der komplementär zu dem zweiten Abschnitt eines signierten Vorrichtungszertifikats eines öffentlichen Schlüssels ist.
    • Ausführungsform 5: Verfahren nach einer der Ausführungsformen 1 bis 4, ferner umfassend: Verifizieren der Identität der Partei als Reaktion auf das erhaltene Vorrichtungszertifikat der Partei.
    • Ausführungsform 6: Verfahren nach einer der Ausführungsformen 1 bis 5, ferner umfassend: Erzeugen einer codierten ersten digitalen Signatur durch Codieren einer ersten digitalen Signatur als Reaktion auf die zweite kryptografische Nonce und Signieren der dritten Nachricht als Reaktion auf die codierte erste digitale Signatur.
    • Ausführungsform 7: Verfahren nach einer der Ausführungsformen 1 bis 6, ferner umfassend: Erzeugen eines Sitzungsgeheimnisses als Reaktion auf den zweiten signierten flüchtigen öffentlichen Schlüssel und einen flüchtigen privaten Schlüssel.
    • Ausführungsform 8: Verfahren nach einer der Ausführungsformen 1 bis 7, ferner umfassend: Drehen von Sitzungsschlüsseln der sicheren Kommunikationssitzung als Reaktion auf das Initiieren einer zweiten Handshake-Nachrichtenübermittlungs-Phase.
    • Ausführungsform 9: Recheneinrichtung, umfassend: einen Prozessor und einen Speicher, in dem sich maschinenausführbare Anweisungen befinden, die bei Ausführung durch den Prozessor die Recheneinrichtung konfigurieren zum: Austauschen von Identitätsinformationen mit einer Partei über erste Handshake-Nachrichten, wobei die ersten Handshake-Nachrichten umfassen: eine erste Nachricht, wobei die erste Nachricht eine erste kryptografische Nonce und einen ersten signierten Vorrichtungszertifikatabschnitt umfasst; und eine zweite Nachricht, wobei die zweite Nachricht eine zweite kryptografische Nonce und einen zweiten Abschnitt eines signierten Vorrichtungszertifikats umfasst, und Austauschen von ersten Informationen über einen signierten Schlüsselvereinbarungsaustausch mit der Partei über zweite Handshake-Nachrichten, die zweiten Handshake-Nachrichten umfassend: eine dritte Nachricht, wobei die dritte Nachricht einen ersten signierten flüchtigen öffentlichen Schlüssel umfasst; und eine vierte Nachricht, wobei die vierte Nachricht einen zweiten signierten flüchtigen öffentlichen Schlüssel umfasst.
    • Ausführungsform 10: Rechenvorrichtung nach Ausführungsform 9, wobei die maschinenausführbaren Anweisungen weitere maschinenausführbare Anweisungen umfassen, die bei Ausführung durch den Prozessor die Einrichtung konfigurieren zum: Auswählen von Informationen, die in einem oder mehreren spezifischen Feldern eines ersten Vorrichtungszertifikats gespeichert sind; Erzeugen eines ersten Vorrichtungszertifikatabschnitts, der die ausgewählten Informationen umfasst; und Signieren des ersten Vorrichtungszertifikatabschnitts als Reaktion auf eine digitale Signatur einer vertrauenswürdigen Drittpartei, um den ersten Abschnitt eines signierten Vorrichtungszertifikats zu erzeugen.
    • Ausführungsform 11: Rechenvorrichtung nach einer der Ausführungsformen 9 und 10, wobei die maschinenausführbaren Anweisungen weitere maschinenausführbare Anweisungen umfassen, die bei Ausführung durch den Prozessor die Einrichtung konfigurieren zum: Erhalten des Vorrichtungszertifikats der Partei durch Kombinieren des zweiten Abschnitts eines signierten Vorrichtungszertifikats und eines teilweise vorausgefüllten Vorrichtungszertifikats.
    • Ausführungsform 12: Rechenvorrichtung nach einer der Ausführungsformen 9 bis 11, wobei das teilweise vorausgefüllte Vorrichtungszertifikat komplementär zu dem zweiten Abschnitt eines signierten Vorrichtungszertifikats ist.
    • Ausführungsform 13: Rechenvorrichtung nach einer der Ausführungsformen 9 bis 12, wobei die maschinenausführbaren Anweisungen weitere maschinenausführbare Anweisungen umfassen, die bei Ausführung durch den Prozessor die Einrichtung konfigurieren zum: Verifizieren der Identität der Partei als Reaktion auf das erhaltene Vorrichtungszertifikat der Partei.
    • Ausführungsform 14: Rechenvorrichtung nach einer der Ausführungsformen 9 bis 13, wobei die maschinenausführbaren Anweisungen weitere maschinenausführbare Anweisungen umfassen, die bei Ausführung durch den Prozessor die Einrichtung konfigurieren zum: Erzeugen einer codierten ersten digitalen Signatur durch Codieren einer ersten digitalen Signatur als Reaktion auf die zweite kryptografische Nonce und Signieren der dritten Nachricht als Reaktion auf die codierte erste digitale Signatur.
    • Ausführungsform 15: Rechenvorrichtung nach einer der Ausführungsformen 9 bis 14, wobei die maschinenausführbaren Anweisungen weitere maschinenausführbare Anweisungen umfassen, die bei Ausführung durch den Prozessor die Einrichtung konfigurieren zum: Erzeugen eines Sitzungsgeheimnisses als Reaktion auf den zweiten signierten flüchtigen öffentlichen Schlüssel und einen flüchtigen privaten Schlüssel.
    • Ausführungsform 16: Rechenvorrichtung nach einer der Ausführungsformen 9 bis 15, wobei die maschinenausführbaren Anweisungen weitere maschinenausführbare Anweisungen umfassen, die bei Ausführung durch den Prozessor die Einrichtung konfigurieren zum: Drehen des Sitzungsschlüssels der sicheren Kommunikationssitzung als Reaktion auf die Initiierung einer zweiten Handshake-Nachrichtenübermittlungs-Phase.
    • Ausführungsform 17: Datenspeicherungsvorrichtung, wobei die Datenspeicherungsvorrichtung Anweisungen einschließt, die bei Ausführung durch den Prozessor den Prozessor veranlassen zum: Austauschen von Identitätsinformationen mit einer Partei über erste Handshake-Nachrichten, die ersten Handshake-Nachrichten umfassend: eine erste Nachricht, die eine erste kryptografische Nonce und einen ersten signierten Vorrichtungszertifikatabschnitt umfasst; und eine zweite Nachricht, die eine zweite kryptografische Nonce und einen zweiten Abschnitt eines signierten Vorrichtungszertifikats umfasst, und Austauschen von ersten Informationen über einen signierten Schlüsselvereinbarungsaustausch mit der Partei über zweite Handshake-Nachrichten, die zweiten Handshake-Nachrichten umfassend: eine dritte Nachricht, die einen ersten signierten flüchtigen öffentlichen Schlüssel umfasst; und eine vierte Nachricht, die einen zweiten signierten flüchtigen öffentlichen Schlüssel umfasst.
  • Während die vorliegende Offenbarung hierin in Bezug auf bestimmte veranschaulichte Ausführungsformen beschrieben wurde, wird der Fachmann erkennen und anerkennen, dass die vorliegende Erfindung nicht darauf beschränkt ist. Vielmehr können viele Ergänzungen, Streichungen und Modifikationen an den veranschaulichten und beschriebenen Ausführungsformen vorgenommen werden, ohne vom Schutzumfang der Erfindung, wie er nachfolgend zusammen mit ihren rechtlichen Äquivalenten beansprucht wird, abzuweichen. Zusätzlich können Merkmale von einer Ausführungsform mit Merkmalen einer anderen Ausführungsform kombiniert werden, während sie immer noch innerhalb des Schutzumfangs der Erfindung enthalten sind, wie er vom Erfinder in Betracht gezogen wird.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 62948951 [0001]

Claims (17)

  1. Verfahren zum Durchführen einer Seite eines Handshakes zur gegenseitigen Authentifizierung, das Verfahren umfassend: Austauschen von Identitätsinformationen mit einer Partei über eine erste Nachrichtenübermittlung einer Handshake-Nachrichtenübermittlungs-Phase, wobei die erste Nachrichtenübermittlung umfasst: Senden einer ersten Nachricht, wobei die erste Nachricht eine erste kryptografische Nonce und einen ersten Abschnitt eines signierten Vorrichtungszertifikats umfasst; und Empfangen einer zweiten Nachricht, wobei die zweite Nachricht eine zweite kryptografische Nonce und einen zweiten Abschnitt eines signierten Vorrichtungszertifikats umfasst, und Austauschen von Informationen über einen signierten Schlüsselvereinbarungsaustausch eines signierten Schlüsselvereinbarungsaustauschs mit der Partei über eine zweite Nachrichtenübermittlung der Handshake-Nachrichtenübermittlungs-Phase, wobei die zweite Nachrichtenübermittlung umfasst: Senden einer dritten Nachricht, wobei die dritte Nachricht einen ersten signierten flüchtigen öffentlichen Schlüssel umfasst; und Empfangen einer vierten Nachricht, wobei die vierte Nachricht einen zweiten signierten flüchtigen öffentlichen Schlüssel umfasst.
  2. Verfahren nach Anspruch 1, ferner umfassend: Auswählen von Informationen, die in einem oder mehreren spezifischen Feldern eines ersten Vorrichtungszertifikats gespeichert sind; Erzeugen eines ersten Vorrichtungszertifikatabschnitts, der die ausgewählten Informationen umfasst; und Signieren des ersten Vorrichtungszertifikatabschnitts als Reaktion auf eine digitale Signatur einer vertrauenswürdigen Drittpartei, um den ersten Abschnitt eines signierten Vorrichtungszertifikats zu erzeugen.
  3. Verfahren nach Anspruch 1, ferner umfassend: Erhalten eines Vorrichtungszertifikats der Partei durch Kombinieren des zweiten Abschnitts eines signierten Vorrichtungszertifikats und eines teilweise vorausgefüllten Vorrichtungszertifikats.
  4. Verfahren nach Anspruch 3, wobei das Kombinieren des zweiten Abschnitts eines signierten Vorrichtungszertifikats und des teilweise vorausgefüllten Vorrichtungszertifikats umfasst: Kombinieren des zweiten Abschnitts eines signierten Vorrichtungszertifikats mit einem Abschnitt des teilweise vorausgefüllten Vorrichtungszertifikats, der komplementär zu dem zweiten signierten flüchtigen öffentlichen Schlüssel und dem zweiten Abschnitt eines signierten Vorrichtungszertifikats ist.
  5. Verfahren nach Anspruch 3, ferner umfassend: Verifizieren der Identität der Partei als Reaktion auf das erhaltene Vorrichtungszertifikat der Partei.
  6. Verfahren nach Anspruch 1, ferner umfassend: Erzeugen einer codierten ersten digitalen Signatur durch Codieren einer ersten digitalen Signatur als Reaktion auf die zweite kryptografische Nonce und Signieren der dritten Nachricht als Reaktion auf die codierte erste digitale Signatur.
  7. Verfahren nach Anspruch 1, ferner umfassend: Erzeugen eines Sitzungsgeheimnisses als Reaktion auf den zweiten signierten flüchtigen öffentlichen Schlüssel und einen flüchtigen privaten Schlüssel.
  8. Verfahren nach Anspruch 1, ferner umfassend: Drehen von Sitzungsschlüsseln einer sicheren Kommunikationssitzung als Reaktion auf das Initiieren einer zweiten Handshake-Nachrichtenübermittlungs-Phase.
  9. Recheneinrichtung, umfassend: einen Prozessor; und einen Speicher, in dem sich maschinenausführbare Anweisungen befinden, die bei Ausführung durch den Prozessor die Recheneinrichtung konfigurieren zum: Austauschen von Identitätsinformationen mit einer Partei über erste Handshake-Nachrichten, die ersten Handshake-Nachrichten umfassend: eine erste Nachricht, wobei die erste Nachricht eine erste kryptografische Nonce und einen ersten Abschnitt eines signierten Vorrichtungszertifikats umfasst; und eine zweite Nachricht, wobei die zweite Nachricht eine zweite kryptografische Nonce und einen zweiten Abschnitt eines signierten Vorrichtungszertifikats umfasst, und Austauschen von ersten Informationen über einen signierten Schlüsselvereinbarungsaustausch mit der Partei über zweite Handshake-Nachrichten, die zweiten Handshake-Nachrichten umfassend: eine dritte Nachricht, die einen ersten signierten flüchtigen öffentlichen Schlüssel umfasst; und eine vierte Nachricht, wobei die vierte Nachricht einen zweiten signierten flüchtigen öffentlichen Schlüssel umfasst.
  10. Recheneinrichtung nach Anspruch 9, wobei die maschinenausführbaren Anweisungen weitere maschinenausführbare Anweisungen umfassen, die bei Ausführung durch den Prozessor die Einrichtung konfigurieren zum: Auswählen von Informationen, die in einem oder mehreren spezifischen Feldern eines ersten Vorrichtungszertifikats gespeichert sind; Erzeugen eines ersten Vorrichtungszertifikatabschnitts, der die ausgewählten Informationen umfasst; und Signieren des ersten Vorrichtungszertifikatabschnitts als Reaktion auf eine digitale Signatur einer vertrauenswürdigen Drittpartei, um den ersten Abschnitt eines signierten Vorrichtungszertifikats zu erzeugen.
  11. Recheneinrichtung nach Anspruch 9, wobei die maschinenausführbaren Anweisungen weitere maschinenausführbare Anweisungen umfassen, die bei Ausführung durch den Prozessor die Einrichtung konfigurieren zum: Erhalten eines Vorrichtungszertifikats der Partei durch Kombinieren des zweiten Abschnitts eines signierten Vorrichtungszertifikats und eines teilweise vorausgefüllten Vorrichtungszertifikats.
  12. Rechenvorrichtung nach Anspruch 11, wobei das teilweise vorausgefüllte Vorrichtungszertifikat komplementär zu dem zweiten Abschnitt eines signierten Vorrichtungszertifikats ist.
  13. Recheneinrichtung nach Anspruch 11, wobei die maschinenausführbaren Anweisungen weitere maschinenausführbare Anweisungen umfassen, die bei Ausführung durch den Prozessor die Einrichtung konfigurieren zum: Verifizieren der Identität der Partei als Reaktion auf das erhaltene Vorrichtungszertifikat der Partei.
  14. Recheneinrichtung nach Anspruch 9, wobei die maschinenausführbaren Anweisungen weitere maschinenausführbare Anweisungen umfassen, die bei Ausführung durch den Prozessor die Einrichtung konfigurieren zum: Erzeugen einer codierten ersten digitalen Signatur durch Codieren einer ersten digitalen Signatur als Reaktion auf die zweite kryptografische Nonce und Signieren der dritten Nachricht als Reaktion auf die codierte erste digitale Signatur.
  15. Recheneinrichtung nach Anspruch 9, wobei die maschinenausführbaren Anweisungen weitere maschinenausführbare Anweisungen umfassen, die bei Ausführung durch den Prozessor die Einrichtung konfigurieren zum: Erzeugen eines Sitzungsgeheimnisses als Reaktion auf den zweiten signierten flüchtigen öffentlichen Schlüssel und einen flüchtigen privaten Schlüssel.
  16. Recheneinrichtung nach Anspruch 9, wobei die maschinenausführbaren Anweisungen weitere maschinenausführbare Anweisungen umfassen, die bei Ausführung durch den Prozessor die Einrichtung konfigurieren zum: Drehen von Sitzungsschlüsseln einer sicheren Kommunikationssitzung als Reaktion auf die Initiierung einer zweiten Handshake-Nachrichtenübermittlungs-Phase.
  17. Datenspeicherungsvorrichtung, wobei die Datenspeicherungsvorrichtung Anweisungen einschließt, die bei Ausführung durch den Prozessor den Prozessor veranlassen zum: Austauschen von Identitätsinformationen mit einer Partei über erste Handshake-Nachrichten, die ersten Handshake-Nachrichten umfassend: eine erste Nachricht, die eine erste kryptografische Nonce und einen ersten Abschnitt eines signierten Vorrichtungszertifikats umfasst; und eine zweite Nachricht, die eine zweite kryptografische Nonce und einen zweiten Abschnitt eines signierten Vorrichtungszertifikats umfasst, und Austauschen von ersten Informationen über einen signierten Schlüsselvereinbarungsaustausch mit der Partei über zweite Handshake-Nachrichten, die zweiten Handshake-Nachrichten umfassend: eine dritte Nachricht, die einen ersten signierten flüchtigen öffentlichen Schlüssel umfasst; und eine vierte Nachricht, die einen zweiten signierten flüchtigen öffentlichen Schlüssel umfasst.
DE112020006159.0T 2019-12-17 2020-09-03 Protokoll zur gegenseitigen authentifizierung für systeme mit kommunikationsverbindungen mit niedrigem durchsatz und vorrichtungen zum durchführen desselben Pending DE112020006159T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201962948951P 2019-12-17 2019-12-17
US62/948,951 2019-12-17
PCT/US2020/070489 WO2021127666A1 (en) 2019-12-17 2020-09-03 Mutual authentication protocol for systems with low-throughput communication links, and devices for performing the same

Publications (1)

Publication Number Publication Date
DE112020006159T5 true DE112020006159T5 (de) 2022-11-03

Family

ID=72603552

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112020006159.0T Pending DE112020006159T5 (de) 2019-12-17 2020-09-03 Protokoll zur gegenseitigen authentifizierung für systeme mit kommunikationsverbindungen mit niedrigem durchsatz und vorrichtungen zum durchführen desselben

Country Status (4)

Country Link
US (1) US20210184869A1 (de)
CN (1) CN114830602A (de)
DE (1) DE112020006159T5 (de)
WO (1) WO2021127666A1 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021119728A1 (de) * 2020-07-31 2022-02-03 Technische Universität Darmstadt, Körperschaft des öffentlichen Rechts Anonymes verteiltes System zur Kontaktverfolgung und -verifizierung
US11856113B2 (en) * 2020-12-10 2023-12-26 The Alfred E. Mann Foundation For Scientific Research Single-certificate multi-factor authentication
US11902271B2 (en) * 2021-04-07 2024-02-13 EMC IP Holding Company LLC Two-way secure channels between multiple services across service groups
US11792644B2 (en) * 2021-06-21 2023-10-17 Motional Ad Llc Session key generation for autonomous vehicle operation
US20220408245A1 (en) * 2021-06-21 2022-12-22 Motional Ad Llc Session key generation for autonomous vehicle operation
CN114172679B (zh) * 2021-06-23 2023-12-01 上海电力大学 一种基于国密算法的电力数据安全加密传输方法
US20230078954A1 (en) * 2021-09-10 2023-03-16 Assa Abloy Ab Fast bilateral key confirmation
US20230155811A1 (en) * 2021-11-12 2023-05-18 Micron Technology, Inc. Encrypted information sharing with lightweight devices
CN114745180A (zh) * 2022-04-11 2022-07-12 中国南方电网有限责任公司 接入认证方法、装置和计算机设备

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7600113B2 (en) * 2004-02-20 2009-10-06 Microsoft Corporation Secure network channel
US7574600B2 (en) * 2004-03-24 2009-08-11 Intel Corporation System and method for combining user and platform authentication in negotiated channel security protocols
US7676676B2 (en) * 2005-11-14 2010-03-09 Motorola, Inc. Method and apparatus for performing mutual authentication within a network
US7882356B2 (en) * 2006-10-13 2011-02-01 Microsoft Corporation UPnP authentication and authorization
CN101516090B (zh) * 2008-02-20 2013-09-11 华为技术有限公司 网络认证通信方法及网状网络系统
US8001381B2 (en) * 2008-02-26 2011-08-16 Motorola Solutions, Inc. Method and system for mutual authentication of nodes in a wireless communication network
US8327146B2 (en) * 2008-03-31 2012-12-04 General Motors Llc Wireless communication using compact certificates
EP2504973B1 (de) * 2009-11-25 2016-11-16 Security First Corp. Systeme und verfahren zur sicherung von daten in bewegung
DE102014204252A1 (de) * 2014-03-07 2015-09-10 Bundesdruckerei Gmbh Sicherheitssystem mit Zugriffskontrolle
FR3030821B1 (fr) * 2014-12-22 2017-01-13 Oberthur Technologies Procede d'authentification d'une application, appareil electronique et programme d'ordinateur associes
US9565172B2 (en) * 2015-06-17 2017-02-07 Telefonaktiebolaget Lm Ericsson (Publ) Method for enabling a secure provisioning of a credential, and related wireless devices and servers
CA2990651A1 (en) * 2015-06-30 2017-01-05 Visa International Service Association Confidential authentication and provisioning
DE102015214267A1 (de) * 2015-07-28 2017-02-02 Siemens Aktiengesellschaft Verfahren und System zum Erzeugen eines sicheren Kommunikationskanals für Endgeräte
CN106533689B (zh) * 2015-09-15 2019-07-30 阿里巴巴集团控股有限公司 一种在ssl/tls通信中加载数字证书的方法和装置
EP3395034B1 (de) * 2015-12-21 2019-10-30 Koninklijke Philips N.V. Netzwerksystem für sichere kommunikation
CN107396350B (zh) * 2017-07-12 2021-04-27 西安电子科技大学 基于sdn-5g网络架构的sdn组件间安全保护方法
CN108366069B (zh) * 2018-02-26 2020-11-13 北京赛博兴安科技有限公司 一种双向认证方法和系统
CN110190955B (zh) * 2019-05-27 2022-05-24 新华三信息安全技术有限公司 基于安全套接层协议认证的信息处理方法及装置

Also Published As

Publication number Publication date
US20210184869A1 (en) 2021-06-17
WO2021127666A9 (en) 2022-03-31
CN114830602A (zh) 2022-07-29
WO2021127666A1 (en) 2021-06-24

Similar Documents

Publication Publication Date Title
DE112020006159T5 (de) Protokoll zur gegenseitigen authentifizierung für systeme mit kommunikationsverbindungen mit niedrigem durchsatz und vorrichtungen zum durchführen desselben
DE102013225742B4 (de) Verfahren und system für eine geschützte und autorisierte kommunikation zwischen einem fahrzeug und drahtlosen kommunikationsgeräten oder schlüsselanhängern
DE102009061045B4 (de) Erzeugung eines Session-Schlüssels zur Authentisierung und sicheren Datenübertragung
DE60024319T2 (de) Vereinter einloggungsprozess
DE60314060T2 (de) Verfahren und Vorrichtung zur Schlüsselverwaltung für gesicherte Datenübertragung
DE60302276T2 (de) Verfahren zur ferngesteuerten Änderung eines Kommunikationspasswortes
DE102013202001B4 (de) Verfahren zum Versehen eines mobilen Endgeräts mit einem Authentisierungszertifikat
DE102010002241B4 (de) Vorrichtung und Verfahren zur effizienten einseitigen Authentifizierung
EP1125395B1 (de) Verfahren und anordnung zur authentifikation von einer ersten instanz und einer zweiten instanz
DE102018216915A1 (de) System und Verfahren für sichere Kommunikationen zwischen Steuereinrichtungen in einem Fahrzeugnetzwerk
DE112016002319T5 (de) Verfahren und vorrichtung zur initialzertifikatregistrierung in einem drahtlosen kommunikationssystem
EP1080557B1 (de) Verfahren und anordnung zum rechnergestützten austausch kryptographischer schlüssel zwischen einer ersten computereinheit und einer zweiten computereinheit
CN108886468A (zh) 用于分发基于身份的密钥资料和证书的系统和方法
DE19622630C1 (de) Verfahren zum gruppenbasierten kryptographischen Schlüsselmanagement zwischen einer ersten Computereinheit und Gruppencomputereinheiten
EP3562115A1 (de) Geschützte übertragung von daten mit hilfe post-quanten kryptographie
DE102017118164A1 (de) Kryptographische schaltung und datenverarbeitung
DE112020000244T5 (de) Initialisierung einer Datenspeicherungsvorrichtung mit einer Managervorrichtung
EP3220575B1 (de) Verfahren zur herstellung einer sicheren kommunikation zwischen einem client und einem server
EP3206154B1 (de) Verfahren und vorrichtungen zum sicheren übermitteln von nutzdaten
EP2684312A1 (de) Verfahren zur authentisierung, rf-chip-dokument, rf-chip-lesegerät und computerprogrammprodukte
EP4162661A1 (de) Vorbereiten einer steuervorrichtung zur sicheren kommunikation
DE112013001180B4 (de) Kommunikationsprotokoll für sichere Kommunikationssysteme
EP3050244B1 (de) Bereitstellung und verwendung pseudonymer schlüssel bei hybrider verschlüsselung
DE102021113263A1 (de) Extreme-High-Throughput-Fast-Initial-Link-Setup-Unterstützung in einem Mehrfachverbindungsbetrieb in Funkkommunikationen
DE10216396A1 (de) Verfahren zur Authentisierung

Legal Events

Date Code Title Description
R012 Request for examination validly filed