DE112020004236B4 - Vorwärts gerichtete sicherheit in der transport layer security unter verwendung von ephemeren schlüsseln - Google Patents

Vorwärts gerichtete sicherheit in der transport layer security unter verwendung von ephemeren schlüsseln Download PDF

Info

Publication number
DE112020004236B4
DE112020004236B4 DE112020004236.7T DE112020004236T DE112020004236B4 DE 112020004236 B4 DE112020004236 B4 DE 112020004236B4 DE 112020004236 T DE112020004236 T DE 112020004236T DE 112020004236 B4 DE112020004236 B4 DE 112020004236B4
Authority
DE
Germany
Prior art keywords
server
key
ephemeral
certificate
public key
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.)
Active
Application number
DE112020004236.7T
Other languages
English (en)
Other versions
DE112020004236T5 (de
Inventor
Michael Gray
Narayana Aditya Madineni
Matthew Green
Simon McMahon
Leigh McLean
Stephen McKenzie
Luvita Burgess
Peter Waltenberg
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.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
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 International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112020004236T5 publication Critical patent/DE112020004236T5/de
Application granted granted Critical
Publication of DE112020004236B4 publication Critical patent/DE112020004236B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H04L9/3073—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves involving pairings, e.g. identity based encryption [IBE], bilinear mappings or bilinear pairings, e.g. Weil or Tate pairing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key 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/0825—Key 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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/3247—Cryptographic 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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/3263—Cryptographic 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/3265—Cryptographic 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3006—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters
    • H04L9/302—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters involving the integer factorization problem, e.g. RSA or quadratic sieve [QS] schemes

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Algebra (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)

Abstract

Verfahren zum Verhindern einer Beeinträchtigung eines Satzes von abgeleiteten Sitzungsschlüsseln für eine auf der Transport Layer Security,TLS, basierende Verbindung zwischen einem Client und einem Server, wobei der Server über ein öffentliches Schlüsselpaar verfügt, das einen öffentlichen Schlüssel des Servers und einen zugehörigen privaten Schlüssel des Servers aufweist, wobei das Verfahren umfasst:an dem Server:als Reaktion auf einen Empfang einer Anforderung, eine neue Sitzung aufzubauen, Erhalten eines ephemeren Schlüsselpaares des Servers, das einen ephemeren öffentlichen Schlüssel und einen zugehörigen ephemeren privaten Schlüssel aufweist;Erzeugen eines temporären Zertifikats, indem der ephemere öffentliche Schlüssel unter Verwendung des privaten Schlüssels des Servers signiert wird;Ausgeben einer Zertifikatskette an den Client, die mindestens das temporäre Zertifikat, das den ephemeren öffentlichen Schlüssel umfasst, zusammen mit einem Serverzertifikat aufweist, das den öffentlichen Schlüssel des Servers umfasst;Empfangen einer Nachricht von dem Client, wobei die Nachricht durch den Client erzeugt wurde, der den ephemeren öffentlichen Schlüssel des Servers auf einen Sitzungsschlüssel anwendet, welcher für die neue Sitzung abgeleitet wurde; undWiederherstellen des für die neue Sitzung abgeleiteten Sitzungsschlüssels, indem der ephemere private Schlüssel des Servers auf die Nachricht angewendet wird, um den Aufbau der neuen Sitzung abzuschließen;wobei eine Beeinträchtigung eines mit dem Aufbau der neuen Sitzung verbundenen Schlüssels einen oder mehrere andere abgeleitete Sitzungsschlüssel des Satzes nicht beeinträchtigt.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Erfindung betrifft allgemein die Informationssicherheit in einem Computernetzwerk.
  • HINTERGRUND
  • Da netzbasierte Sicherheitsbedrohungen ständig weiter zunehmen, ist die Verwendung einer auf Secure Sockets Layer (SSL) und/oder Transport Layer Security (TLS) basierenden Verschlüsselung für Netzübertragungen allgegenwärtig geworden. Tatsächlich wird nunmehr geschätzt, dass über zwei Drittel oder mehr des gesamten Unternehmensnetzverkehrs über SSL/TLS übertragen wird. In einem typischen Szenario nehmen Client- und Serveranwendungen untereinander einen Quittungsaustausch vor, um eine sichere Verbindung herzustellen. Während dieses Vorgangs wird von den Endpunkten üblicherweise ein Verschlüsselungsprotokoll mit einem öffentlichen RSA-(Rivest-Shamir-Adelman-)Schlüssel verwendet, um einen geheimen Schlüssel (S) gemeinsam zu nutzen, der im Anschluss an den Verbindungsaufbau von beiden Seiten verwendet wird, um Daten zu verschlüsseln und zu entschlüsseln.
  • In dem vorstehend beschriebenen Szenario gibt es ein hinlänglich bekanntes Problem. Da das RSA-Schlüsselpaar des Servers statischer Natur ist, führt insbesondere jede Beeinträchtigung des statischen privaten RSA-Schlüssels des Servers möglicherweise zu einem Verlust der Vertraulichkeit für alle Sitzungsdaten. Der Grund hierfür ist, dass die Daten einer jeden Sitzung mit dem geheimen Schlüssel (S) verschlüsselt werden, der unter dem statischen RSA-Schlüssel des Servers ausgetauscht wird. Ein Angriff dieses Typs ist einfach. Dazu zeichnet ein Angreifer einfach übertragenen verschlüsselten Verkehr zwischen dem Client und dem Server für alle Verbindungen auf. Obwohl der für jede Verbindung verwendete geheime Schlüssel anders ist, sind alle geheimen Schlüssel durch den privaten Schlüssel des Servers geschützt. Wenn der Angreifer Zugang zu diesem Schlüssel erlangt, z.B. durch Brute-Force- oder andere Angriffsvektoren, können die geheimen Schlüssel (S) für gemeinsame Nutzung von allen aufgezeichneten Verbindungen folglich entschlüsselt werden und dann können alle Anwendungsdaten wiederhergestellt und angezeigt werden. Diese Situation ist als eine Situation bekannt, in der man keine absolute vorwärts gerichtete Sicherheit (PFS, Perfect Forward Secrecy) hat.
  • Im Stand der Technik beschreibt US20190245695A1 eine sichere Kommunikation mit einer einzigen nicht zurückverfolgbaren Anforderungsnachricht von einem ersten Computer und einer einzigen nicht zurückverfolgbaren Antwortnachricht von einem zweiten Computer herstellen. US20160234177A1 beschreibt ein Verfahren und System zur sicheren Kommunikation mit einer Maschine-zu-Maschine (M2M)-Vorrichtung, das den Austausch eines Geheimnisses oder von dem Geheimnis abgeleiteter Daten zwischen der M2M-Vorrichtung und einem Server umfasst.
  • KU RZDARSTELLU NG
  • Die Erfindung wird durch die Merkmale der unabhängigen Ansprüche beschrieben. Ausführungsformen sind in den abhängigen Ansprüchen angegeben.
  • Diese Offenbarung beschreibt ein Verfahren, eine Vorrichtung und ein Computerprogrammprodukt, das eine Beeinträchtigung eines Satzes von abgeleiteten Sitzungsschlüsseln für eine auf der Transport Layer Security (TLS) basierende Verbindung zwischen einem Client und einem Server verhindert und auf diese Weise eine absolute vorwärts gerichtete Sicherheit ermöglicht. Der Server verfügt über ein öffentliches Schlüsselpaar, das einen öffentlichen Schlüssel des Servers und einen zugehörigen privaten Schlüssel des Servers aufweist.
  • Gemäß einem Aspekt dieser Offenbarung arbeitet der TLS-Verbindungsaufbau vorzugsweise wie folgt: Als Reaktion auf einen Empfang einer Anforderung an dem Server, eine neue Sitzung aufzubauen, wird ein ephemeres (temporäres) Schlüsselpaar, das einen ephemeren öffentlichen Schlüssel und einen zugehörigen ephemeren privaten Schlüssel aufweist, vorzugsweise aus einem Pool solcher Schlüsselpaare abgerufen, die im Voraus erzeugt werden. Der Server erzeugt ein temporäres Zertifikat, indem er den ephemeren öffentlichen Schlüssel unter Verwendung des eigenen privaten Schlüssels des Servers signiert. Der Server gibt dann eine Zertifikatskette an den Client aus, die mindestens das temporäre Zertifikat, das den ephemeren öffentlichen Schlüssel umfasst, zusammen mit einem Serverzertifikat aufweist, das den öffentlichen Schlüssel des Servers umfasst. Auf diese Weise hat der Server die Funktion einer untergeordneten Zertifizierungsstelle. Die Clientseite der TLS-Verbindung versucht dann, die Zertifikate auf Gültigkeit zu prüfen, und fährt nach einer solchen Gültigkeitsprüfung mit dem TLS-Verbindungsaufbau fort, indem sie einen Sitzungsschlüssel (einen geheimen Schlüssel (S) für gemeinsame Nutzung) erzeugt und den ephemeren öffentlichen Schlüssel (den sie von dem Server in dem temporären Zertifikat empfangen hat) anwendet. Danach empfängt der Server eine Nachricht von dem Client, wobei die Nachricht durch den Client erzeugt wurde, der den ephemeren öffentlichen Schlüssel auf den an dem Client für die neue Sitzung abgeleiteten Sitzungsschlüssel anwendet. Der Server stellt den für die neue Sitzung abgeleiteten Sitzungsschlüssel dann wieder her, indem er den ephemeren privaten Schlüssel auf die Nachricht anwendet. Dies schließt den Aufbau der neuen Sitzung ab und die Client- und die Server-Anwendung verwenden danach den Sitzungsschlüssel (den geheimen Schlüssel für gemeinsame Nutzung), um Daten über die TLS-Verbindung zu verschlüsseln und zu entschlüsseln. Das ephemere Schlüsselpaar wird nicht wiederverwendet. Bei Verwendung dieses Ansatzes wird eine absolute vorwärts gerichtete Sicherheit erreicht, da eine Beeinträchtigung eines mit dem Aufbau der neuen Sitzung verbundenen Schlüssels einen oder mehrere andere abgeleitete Sitzungsschlüssel des Satzes nicht beeinträchtigt.
  • Das Vorstehende gab einen Überblick über einige der relevanteren Merkmale des offenbarten Gegenstands. Diese Merkmale sollten als lediglich veranschaulichende Merkmale aufgefasst werden. Viele andere vorteilhafte Ergebnisse können erzielt werden, indem der offenbarte Gegenstand auf eine andere Weise angewendet oder indem der Gegenstand geändert wird, wie beschrieben werden wird.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Für ein vollständigeres Verständnis des Gegenstands und seiner Vorteile wird nun Bezug auf die folgenden Beschreibungen in Zusammenschau mit den beiliegenden Zeichnungen genommen, bei denen:
    • 1 ein beispielhaftes Blockschaubild einer verteilten Datenverarbeitungsumgebung darstellt, in der beispielhafte Aspekte der veranschaulichenden Ausführungsformen ausgeführt werden können;
    • 2 ein beispielhaftes Blockschaubild eines Datenverarbeitungssystems ist, in dem beispielhafte Aspekte der veranschaulichenden Ausführungsformen ausgeführt werden können;
    • 3 eine Zertifikatshierarchie veranschaulicht;
    • 4 den Transport Layer Security-(TLS-)Verbindungsaufbau darstellt; und
    • 5 eine Technik dieser Offenbarung darstellt, um eine Garantie einer absoluten vorwärts gerichteten Sicherheit bezogen auf einen Satz von für den Client und den Server abgeleiteten Sitzungsschlüsseln bereitzustellen.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Unter Bezugnahme auf die Zeichnungen und insbesondere unter Bezugnahme auf die 1 bis 2 sind beispielhafte Schaubilder von Datenverarbeitungsumgebungen bereitgestellt, in denen veranschaulichende Ausführungsformen der Erfindung ausgeführt werden können. Es sollte sich verstehen, dass die 1 bis 2 lediglich beispielhaft sind und dass sie in Bezug auf die Umgebungen, in denen Aspekte oder Ausführungsformen des offenbarten Gegenstands umgesetzt werden können, keinerlei Beschränkung bestätigen oder andeuten sollen. Viele Änderungen an den dargestellten Umgebungen können vorgenommen werden, ohne vom Umfang der vorliegenden Erfindung abzuweichen.
  • Client-Server-Technologien
  • Unter Bezugnahme auf die Zeichnungen ist 1 eine bildliche Darstellung eines beispielhaften verteilten Datenverarbeitungssystems, in dem Aspekte der veranschaulichenden Ausführungsformen umgesetzt werden können. Ein verteiltes Datenverarbeitungssystem 100 kann ein Netzwerk aus Computern umfassen, in dem Aspekte der veranschaulichenden Ausführungsformen umgesetzt werden können. Das verteilte Datenverarbeitungssystem 100 enthält mindestens ein Netzwerk 102, bei dem es sich um das Medium handelt, das zur Bereitstellung von Übertragungsverbindungen zwischen verschiedenen Einheiten und Computern verwendet wird, die in dem verteilten Datenverarbeitungssystem 100 miteinander verbunden sind. Das Netzwerk 102 kann Verbindungen wie beispielsweise Kabel, drahtlose Übertragungsverbindungen oder Lichtwellenleiter umfassen.
  • In dem dargestellten Beispiel sind ein Server 104 und ein Server 106 nebst einer Speichereinheit 108 mit dem Netzwerk 102 verbunden. Ferner sind Clients 110, 112 und 114 ebenfalls mit dem Netzwerk 102 verbunden. Diese Clients 110, 112 und 114 können zum Beispiel Personal Computer, Netzwerkcomputer oder dergleichen sein. In dem dargestellten Beispiel stellt der Server 104 den Clients 110, 112 und 114 Daten wie beispielsweise Bootdateien, Betriebssystem-Abbilder und Anwendungen bereit. Die Clients 110, 112 und 114 sind Clients des Servers 104 in dem dargestellten Beispiel. Das verteilte Datenverarbeitungssystem 100 kann zusätzliche Server, Clients und andere Einheiten umfassen, die nicht gezeigt sind.
  • In dem dargestellten Beispiel ist das verteilte Datenverarbeitungssystem 100 das Internet, wobei das Netzwerk 102 einen weltweiten Verbund von Netzwerken und Gateways darstellt, die die Transmission Control Protocol/Internet Protocol-(TCP/IP-)Folge von Protokollen verwenden, um untereinander Daten auszutauschen. Im Mittelpunkt des Internets befindet sich ein Backbone-Netz aus Hochgeschwindigkeits-Übertragungsleitungen zwischen Hauptknoten oder Hostcomputern, die aus Tausenden von kommerziellen, staatlichen, in Bildungseinrichtungen genutzten und anderen Computersystemen bestehen, welche Daten und Nachrichten weiterleiten. Natürlich kann das verteilte Datenverarbeitungssystem 100 auch so ausgeführt sein, dass es mehrere verschiedene Arten von Netzwerken wie zum Beispiel ein Intranet, ein lokales Netz (LAN), ein Weitverkehrsnetz (WAN) oder dergleichen umfasst. Wie vorstehend angegeben ist, ist 1 als ein Beispiel gedacht, nicht als eine architektonische Einschränkung für verschiedene Ausführungsformen des offenbarten Gegenstands, und daher sollten die jeweiligen in 1 gezeigten Elemente in Bezug auf die Umgebungen, in denen die veranschaulichenden Ausführungsformen der vorliegenden Erfindung ausgeführt werden können, nicht als einschränkend betrachtet werden.
  • Unter Bezugnahme auf 2 ist ein Blockschaubild eines beispielhaften Datenverarbeitungssystems gezeigt, in dem Aspekte der veranschaulichenden Ausführungsformen umgesetzt werden können. Das Datenverarbeitungssystem 200 ist ein Beispiel eines Computers wie beispielsweise des Clients 110 in 1, in dem sich durch einen Computer verwendbare(r) Code oder Anweisungen befinden können, welcher/welche die Prozesse für veranschaulichende Ausführungsformen der Offenbarung ausführt/ausführen.
  • Unter Bezugnahme auf 2 ist ein Blockschaubild eines Datenverarbeitungssystems gezeigt, in dem veranschaulichende Ausführungsformen ausgeführt werden können. Das Datenverarbeitungssystem 200 ist ein Beispiel eines Computers wie beispielsweise des Servers 104 oder des Clients 110 in 1, in dem sich durch einen Computer verwendbare(r) Programmcode oder Anweisungen, welcher/welche die Prozesse ausführt/ausführen, für die veranschaulichenden Ausführungsformen befinden können. In diesem veranschaulichenden Beispiel umfasst das Datenverarbeitungssystem 200 eine Übertragungsstruktur 202, die Übertragungen zwischen einer Prozessoreinheit 204, einem Hauptspeicher 206, einem persistenten Speicher 208, einer Übertragungseinheit 210, einer Eingabe-/Ausgabe-(E/A-)Einheit 212 und einem Bildschirm 214 bereitstellt.
  • Die Prozessoreinheit 204 dient zur Ausführung von Anweisungen für Software, die in den Hauptspeicher 206 geladen werden kann. Bei der Prozessoreinheit 204 kann es sich in Abhängigkeit von der jeweiligen Ausführung um einen Satz von einem oder mehreren Prozessoren oder um einen Mehrkernprozessor handeln. Des Weiteren kann die Prozessoreinheit 204 unter Verwendung von einem oder mehreren heterogenen Prozessorsystemen ausgeführt sein, bei denen sich ein Hauptprozessor mit sekundären Prozessoren auf einem einzelnen Chip befindet. Als ein weiteres veranschaulichendes Beispiel kann es sich bei der Prozessoreinheit 204 um ein symmetrisches Mehrprozessor-(SMP-)System handeln, das mehrere Prozessoren von demselben Typ enthält.
  • Der Hauptspeicher 206 und der persistente Speicher 208 sind Beispiele für Speichereinheiten. Eine Speichereinheit ist eine beliebige Hardwarekomponente, die Informationen entweder auf temporärer Basis und/oder auf permanenter Basis speichern kann. Der Hauptspeicher 206 in diesen Beispielen kann zum Beispiel ein Direktzugriffsspeicher oder eine beliebige andere geeignete flüchtige oder nicht flüchtige Speichereinheit sein. Der persistente Speicher 208 kann in Abhängigkeit von der jeweiligen Ausführung verschiedene Formen annehmen. Zum Beispiel kann der persistente Speicher 208 eine oder mehrere Komponenten oder Einheiten enthalten. Zum Beispiel kann der persistente Speicher 208 ein Festplattenlaufwerk, ein Flashspeicher, eine wieder beschreibbare optische Platte, ein wieder beschreibbares Magnetband oder eine Kombination des Vorstehenden sein. Die von dem persistenten Speicher 208 verwendeten Datenträger können auch austauschbar sein. Zum Beispiel kann ein austauschbares Festplattenlaufwerk für den persistenten Speicher 208 verwendet werden.
  • Die Übertragungseinheit 210 in diesen Beispielen sorgt für Übertragungen mit anderen Datenverarbeitungssystemen oder -einheiten. In diesen Beispielen ist die Übertragungseinheit 210 eine Netzschnittstellenkarte. Die Übertragungseinheit 210 kann durch die Verwendung von physischen oder drahtlosen oder aber von sowohl physischen als auch drahtlosen Übertragungsverbindungen Übertragungen bereitstellen.
  • Die Eingabe-/Ausgabeeinheit 212 ermöglicht die Ein- und Ausgabe von Daten mit anderen Einheiten, die mit dem Datenverarbeitungssystem 200 verbunden sein können. Zum Beispiel kann die Eingabe-/Ausgabeeinheit 212 eine Verbindung für eine Benutzereingabe durch eine Tastatur und eine Maus bereitstellen. Des Weiteren kann die Eingabe-/Ausgabeeinheit 212 eine Ausgabe an einen Drucker senden. Der Bildschirm 214 stellt einen Mechanismus bereit, um einem Benutzer Informationen anzuzeigen.
  • Anweisungen für das Betriebssystem und Anwendungen oder Programme befinden sich im persistenten Speicher 208. Diese Anweisungen können zur Ausführung durch die Prozessoreinheit 204 in den Hauptspeicher 206 geladen werden. Die Prozesse der verschiedenen Ausführungsformen können durch die Prozessoreinheit 204 unter Verwendung von durch einen Computer ausgeführten Anweisungen durchgeführt werden, welche sich in einem Hauptspeicher wie beispielsweise dem Hauptspeicher 206 befinden können. Diese Anweisungen werden als Programmcode, durch einen Computer verwendbarer Programmcode oder durch einen Computer lesbarer Programmcode bezeichnet, der durch einen Prozessor in der Prozessoreinheit 204 gelesen und ausgeführt werden kann. Der Programmcode in den verschiedenen Ausführungsformen kann auf verschiedenen physischen oder greifbaren, durch einen Computer lesbaren Datenträgern wie beispielsweise dem Hauptspeicher 206 oder dem persistenten Speicher 208 verkörpert sein.
  • Ein Programmcode 216 befindet sich in funktionaler Form auf einem durch einen Computer lesbaren Datenträger 218, der selektiv austauschbar ist, und er kann zur Ausführung durch die Prozessoreinheit 204 auf das Datenverarbeitungssystem 200 geladen oder an es übertragen werden. Der Programmcode 216 und der durch einen Computer lesbare Datenträger 218 bilden in diesen Beispielen ein Computerprogrammprodukt 220. In einem Beispiel kann der durch einen Computer lesbare Datenträger 218 in greifbarer Form wie zum Beispiel in Form einer optischen Platte oder Magnetplatte vorliegen, die in ein Laufwerk oder in eine andere Einheit eingelegt oder eingesetzt wird, das bzw. die Teil des persistenten Speichers 208 ist, um an eine Speichereinheit wie beispielsweise ein Festplattenlaufwerk übertragen zu werden, das Teil des persistenten Speichers 208 ist. In greifbarer Form kann der durch einen Computer lesbare Datenträger 218 auch die Form eines persistenten Speichers, wie beispielsweise eines Festplattenlaufwerks, eines Thumb-Drives oder eines Flashspeichers, annehmen, der mit dem Datenverarbeitungssystem 200 verbunden ist. Die greifbare Form des durch einen Computer lesbaren Datenträgers 218 wird auch als ein durch einen Computer beschreibbares Speichermedium bezeichnet. In einigen Fällen ist der durch einen Computer lesbare Datenträger 218 gegebenenfalls nicht auswechselbar.
  • Alternativ kann der Programmcode 216 von dem durch einen Computer lesbaren Datenträger 218 durch eine Übertragungsverbindung zu der Übertragungseinheit 210 und/oder durch eine Verbindung zu der Eingabe-/Ausgabeeinheit 212 an das Datenverarbeitungssystem 200 übertragen werden. Die Übertragungsverbindung und/oder die Verbindung kann in den veranschaulichenden Beispielen physisch oder drahtlos sein. Der durch einen Computer lesbare Datenträger kann auch die Form eines nicht greifbaren Datenträgers wie beispielsweise Übertragungsverbindungen oder drahtlose Übertragungen, die den Programmcode enthalten, annehmen. Die für das Datenverarbeitungssystem 200 veranschaulichten verschiedenen Komponenten sind nicht dazu gedacht, architektonische Einschränkungen für die Art und Weise, in der verschiedene Ausführungsformen ausgeführt werden können, vorzusehen. Die verschiedenen veranschaulichenden Ausführungsformen können in einem Datenverarbeitungssystem ausgeführt werden, das zusätzlich zu den oder anstelle der Komponenten, die für das Datenverarbeitungssystem 200 veranschaulicht sind, Komponenten umfasst. Andere in 2 gezeigte Komponenten können von den gezeigten veranschaulichten Beispielen abweichen. Als ein Beispiel ist eine Speichereinheit in dem Datenverarbeitungssystem 200 eine beliebige Hardware-Vorrichtung, die Daten speichern kann. Der Hauptspeicher 206, der persistente Speicher 208 und der durch einen Computer lesbare Datenträger 218 sind Beispiele für Speichereinheiten in einer greifbaren Form.
  • In einem weiteren Beispiel kann ein Bussystem verwendet werden, um die Übertragungsstruktur 202 auszuführen, und es kann aus einem oder mehreren Bussen bestehen, wie beispielsweise einem Systembus oder einem E/A-Bus. Natürlich kann das Bussystem unter Verwendung von einer beliebigen geeigneten Art von Architektur ausgeführt sein, die für eine Übertragung von Daten zwischen verschiedenen, an das Bussystem angeschlossenen Komponenten oder Einheiten sorgt. Ferner kann eine Übertragungseinheit eine oder mehrere Einheiten umfassen, die zum Senden und Empfangen von Daten verwendet werden, wie beispielsweise ein Modem oder einen Netzadapter. Des Weiteren kann ein Hauptspeicher zum Beispiel der Hauptspeicher 206 oder ein Cache sein, wie er beispielsweise in einer Schnittstelle und einem Hauptspeicher-Controller-Hub zu finden ist, die bzw. der in der Übertragungsstruktur 202 vorhanden sein kann.
  • Computerprogrammcode zur Durchführung von Operationen der vorliegenden Erfindung kann in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen, darunter einer objektorientierten Programmiersprache wie beispielsweise Java™, Smalltalk, C++, C#, Objective-C oder dergleichen, sowie in herkömmlichen prozeduralen Programmiersprachen geschrieben sein. Der Programmcode kann vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel durch das Internet unter Verwendung eines Internet-Dienstanbieters).
  • Der Fachmann versteht, dass die Hardware in den 1 bis 2 in Abhängigkeit von der Ausführung variieren kann. Andere interne Hardware oder periphere Einheiten wie beispielsweise ein Flashspeicher, ein gleichwertiger nicht flüchtiger Speicher oder optische Plattenlaufwerke und dergleichen können zusätzlich zu oder anstelle der in den 1 bis 2 dargestellten Hardware verwendet werden. Auch können die Prozesse der veranschaulichenden Ausführungsformen neben dem zuvor erwähnten SMP-System auch auf ein Datenverarbeitungssystem mit mehreren Prozessoren angewendet werden, ohne vom Umfang des offenbarten Gegenstands abzuweichen.
  • Wie zu sehen sein wird, können die hierin beschriebenen Techniken in Verbindung mit dem standardmäßigen Client-Server-Paradigma, wie beispielsweise dem in 1 veranschaulichten, arbeiten, bei dem Client-Maschinen mit einem über das Internet zugänglichen, webbasierten Portal Daten austauschen, das auf einem Satz aus einer oder mehreren Maschinen ausgeführt wird. Endbenutzer bedienen an das Internet anschließbare Einheiten (z.B. Desktop-Computer, Notebook-Computer, internetfähige mobile Geräte oder dergleichen), die auf das Portal zugreifen und mit dem Portal interagieren können. Üblicherweise ist jede Client- oder Server-Maschine ein Datenverarbeitungssystem, wie es beispielsweise in 2 veranschaulicht ist, das Hardware und Software aufweist, und diese Entitäten tauschen untereinander über ein Netzwerk wie beispielsweise das Internet, ein Intranet, ein Extranet, ein privates Netzwerk oder ein(e) beliebige(s) andere(s) Übertragungsmedium oder-verbindung Daten aus. Ein Datenverarbeitungssystem umfasst üblicherweise einen oder mehrere Prozessoren, ein Betriebssystem, eine oder mehrere Anwendungen und ein oder mehrere Dienstprogramme. Die Anwendungen auf dem Datenverarbeitungssystem stellen native Unterstützung für Web-Services bereit, darunter, ohne darauf beschränkt zu sein, Unterstützung für HTTP, SOAP, XML, WSDL, UDDI sowie WSFL u.a. Informationen zu SOAP, WSDL, UDDI und WSFL werden vom World Wide Web Consortium (W3C) zur Verfügung gestellt, das für die Entwicklung und die Pflege dieser Standards zuständig ist; weitere Informationen zu HTTP und XML werden von der Internet Engineering Task Force (IETF) zur Verfügung gestellt. Vertrautheit mit diesen Standards wird vorausgesetzt.
  • Verschlüsselungssysteme mit öffentlichem Schlüssel
  • Eine Verschlüsselung mit öffentlichem Schlüssel (PKC, public-key cryptography) ist ein Verschlüsselungsansatz, der die Verwendung von Algorithmen mit asymmetrischem Schlüssel einschließt. Im Gegensatz zu Algorithmen mit symmetrischem Schlüssel erfordert PKC keinen sicheren anfänglichen Austausch von einem oder mehreren geheimen Schlüsseln zwischen Sender und Empfänger. Die Algorithmen mit asymmetrischem Schlüssel werden verwendet, um ein mathematisch zusammengehörendes Schlüsselpaar zu erstellen: einen geheimen privaten Schlüssel und einen veröffentlichten öffentlichen Schlüssel. Eine Verwendung dieser Schlüssel ermöglicht den Schutz der Authentizität einer Nachricht, indem eine digitale Signatur einer Nachricht unter Verwendung des privaten Schlüssels erstellt wird, die unter Verwendung des öffentlichen Schlüssels überprüft werden kann. Sie ermöglicht auch einen Schutz der Vertraulichkeit und Integrität einer Nachricht durch eine Public-Key-Verschlüsselung, wobei die Nachricht unter Verwendung des öffentlichen Schlüssels verschlüsselt wird und nur unter Verwendung des privaten Schlüssels entschlüsselt werden kann.
  • Schlüsselerzeugung ist der Vorgang des Erzeugens von Schlüsseln für eine Verschlüsselung. Moderne Verschlüsselungssysteme umfassen Algorithmen mit symmetrischem Schlüssel (z.B. DES, AES und andere) sowie Algorithmen mit öffentlichem Schlüssel (z.B. RSA, D-H, EDH und andere). Algorithmen mit symmetrischem Schlüssel verwenden einen einzelnen gemeinsam genutzten Schlüssel; die Geheimhaltung der Daten bleibt unter der Voraussetzung gewahrt, dass der einzelne Schlüssel privat bleibt. Algorithmen mit öffentlichem Schlüssel verwenden Schlüsselpaare, die aus einem öffentlichen Schlüssel und einem privaten Schlüssel bestehen. Der öffentliche Schlüssel wird jedem zur Verfügung gestellt, üblicherweise mittels eines digitalen Zertifikats. Ein Sender verschlüsselt Daten mit dem öffentlichen Schlüssel; nur der Inhaber des privaten Schlüssels kann diese Daten entschlüsseln. Üblicherweise verwenden Computer ganze Zahlen für Schlüssel. Schlüssel können auch zufällig unter Verwendung eines Zufallszahlengenerators (RNG, random number generator) oder eines Pseudozufallszahlengenerators (PRNG, pseudorandom number generator) erzeugt werden. Ein PRNG ist ein Algorithmus, der Daten erzeugt, die bei einer Analyse zufällig erscheinen. PRNGs, die Systementropie verwenden, um Daten zu initialisieren, bringen im Allgemeinen bessere Ergebnisse hervor, da die Anfangsbedingungen des PRNG für einen Angreifer dadurch sehr viel schwieriger zu erraten sind. In anderen Situationen wird der Schlüssel deterministisch abgeleitet, z.B. unter Verwendung einer Schlüsselableitungsfunktion (KDF, key derivation function). Eine KDF verwendet üblicherweise eine Pseudozufallsfunktion, um einen oder mehrere geheime Schlüssel von einem geheimen Wert abzuleiten, wie beispielsweise einen Masterschlüssel, ein Kennwort oder eine Kennphrase.
  • Allgemeiner ausgedrückt, die Public-Key-Verschlüsselung ist für den Datenschutz (durch Verschlüsselung) und zur Authentifizierung (unter Verwendung von digitalen Signaturen) nützlich. Verschlüsselung ist die Umwandlung von Daten in eine Form, die ohne einen geheimen Entschlüsselungsschlüssel von niemandem gelesen werden kann; Verschlüsselung gewährleistet Datenschutz, indem sie den Inhalt der Informationen vor jedem verborgen hält, für den er nicht bestimmt ist, selbst vor jenen, die die verschlüsselten Daten sehen können. Authentifizierung ist ein Vorgang, bei dem dem Empfänger einer digitalen Nachricht die Identität des Senders und/oder die Integrität der Nachricht versichert wird. Als Beispiel (sowohl für Datenschutz als auch Authentifizierung) wird, wenn ein Sender eine Nachricht verschlüsselt, der öffentliche Schlüssel des Empfängers verwendet, um die Daten in der ursprünglichen Nachricht in den Inhalt der verschlüsselten Nachricht umzuwandeln. Ein Sender verwendet einen öffentlichen Schlüssel des vorgesehenen Empfängers, um Daten zu verschlüsseln, und der Empfänger verwendet seinen privaten Schlüssel, um die verschlüsselte Nachricht zu entschlüsseln. Bei der Authentifizierung von Daten können Daten signiert werden, indem unter Verwendung des privaten Schlüssels des Unterzeichners eine digitale Signatur aus den Daten berechnet wird. Sobald die Daten digital signiert sind, können sie mit der Identität des Unterzeichners gespeichert werden, und die Signatur beweist dann, dass die Daten von dem Unterzeichner stammen. Ein Unterzeichner verwendet seinen privaten Schlüssel, um Daten zu signieren, und ein Empfänger verwendet den öffentlichen Schlüssel des Unterzeichners, um die Signatur zu überprüfen.
  • Verschlüsselungssysteme mit öffentlichem Schlüssel können ganz oder teilweise mit physischen Authentifikatoren ausgeführt sein, die verwendet werden können, um einen Schlüssel mitzuführen oder zu schützen. Zu diesen physischen Authentifikatoren gehören zum Beispiel Sicherheitstoken, Hardwaretoken, USB-Authentifikatoren, Schlüsselanhänger und dergleichen, um einen Schlüssel mitzuführen. Solche Einheiten sorgen für eine verschlüsselungsbasierte Zwei-Faktor-Authentifizierung (2FA). Eine Zwei-Faktor-Authentifizierung ermöglicht eine Identifizierung von Benutzern mittels der Kombination von zwei verschiedenen Komponenten. Bei diesen Komponenten kann es sich um etwas handeln, das der Benutzer kennt, etwas, das der Benutzer besitzt, oder etwas, das untrennbar von dem Benutzer ist.
  • SSL/TLS
  • Als weiterer Hintergrund ist Secure Sockets Layer/Transport Layer Security (SSL/TLS) ein hinlänglich bekanntes Verschlüsselungsprotokoll, das verwendet wird, um Übertragungen über Netzwerke wie beispielsweise das Internet zu sichern. Verschlüsselungsprotokolle wie beispielsweise SSL/TLS beruhen oftmals auf Verschlüsselungssystemen mit öffentlichem Schlüssel, wie etwa dem Verschlüsselungsalgorithmus RSA (Rivest, Shamir und Adelman). Für eine herkömmliche RSA-basierte SSL/TLS-Sitzung einigen sich die beiden Seiten einer Verbindung auf einen „geheimen Pre-Master-Secret-Wert“ (PMS, pre-master secret), der verwendet wird, um die Parameter für die restliche Sitzung zu erzeugen. Üblicherweise verwenden die beiden Seiten eine asymmetrische RSA-Verschlüsselung, um den geheimen Pre-Master-Secret-Wert festzulegen, ohne den tatsächlichen Wert in Klartext auszutauschen. Im Betrieb erzeugt der SSL/TLS-Client den geheimen Pre-Master-Secret-Wert und verschlüsselt ihn mit dem öffentlich verfügbaren RSA-Schlüssel des SSL/TLS-Servers. Dadurch wird ein verschlüsselter geheimer Pre-Master-Secret-Wert (ePMS, encrypted pre-master secret) erzeugt, der dann dem SSL/TLS-Server bereitgestellt wird. Der SSL/TLS-Server hat einen privaten Entschlüsselungsschlüssel, der dann zur Entschlüsselung des verschlüsselten geheimen Pre-Master-Secret-Werts verwendet wird. An dieser Stelle verfügen sowohl der Client als auch der Server über den ursprünglichen geheimen Pre-Master-Secret-Wert und können ihn zur Erzeugung des symmetrischen Schlüssels verwenden, der für einen tatsächlichen verschlüsselten und sicheren Datenaustausch verwendet wird.
  • Zertifikate, Vertrauensketten
  • Ein Zertifikat ist ein digitales Dokument, das für die Identität und den Besitz eines Verschlüsselungsschlüssels durch eine bestimmte Entität wie beispielsweise eine Einzelperson, ein Computersystem, einen speziellen Server, der auf diesem System läuft, oder dergleichen bürgt. Zertifikate werden von Zertifizierungsstellen ausgegeben. Eine Zertifizierungsstelle (CA, certificate authority) ist eine Entität, gewöhnlich eine vertrauenswürdige Drittpartei bei einer Transaktion, der dahingehend vertraut wird, dass sie Zertifikate für andere Personen oder Entitäten signiert oder ausgibt. Üblicherweise übernimmt die CA eine rechtliche Verantwortung dafür, dass sie sich für die Bindung zwischen einem öffentlichen Schlüssel und seinem Eigentümer verbürgt, um es einem zu ermöglichen, der Entität zu vertrauen, die ein Zertifikat signiert hat. Es gibt viele kommerzielle Zertifizierungsstellen; diese Stellen sind dafür verantwortlich, die Identität und den Schlüsselbesitz einer Entität bei der Ausgabe des Zertifikats zu überprüfen. Wenn eine CA ein Zertifikat für eine Entität ausgibt, muss die Entität einen öffentlichen Schlüssel und einige Informationen über die Entität bereitstellen. Ein Software-Tool, z.B. ein Webbrowser, kann diese Informationen digital signieren und sie an die Zertifizierungsstelle senden. Die Zertifizierungsstelle könnte ein kommerzielles Unternehmen sein, das Zertifizierungsstellenservices von vertrauenswürdigen Drittparteien bereitstellt. Die CA erstellt ein digitales Zertifikat, indem sie den öffentlichen Schlüssel der anfordernden Entität (in das Zertifikat) einbettet, üblicherweise zusammen mit anderen Identifikationsinformationen, und das digitale Zertifikat dann mit dem privaten Schlüssel der Zertifizierungsstelle signiert. Jeder, der das digitale Zertifikat während einer Transaktion oder eines Datenaustauschs empfängt, kann den öffentlichen Schlüssel der Zertifizierungsstelle dann verwenden, um den signierten öffentlichen Schlüssel innerhalb des Zertifikats zu überprüfen. Die Signatur der Zertifizierungsstelle soll die Funktion eines manipulationssicheren Siegels auf dem digitalen Zertifikat haben und so die Integrität der Daten in dem Zertifikat sicherstellen.
  • Verschlüsselter Verkehr im Web findet durch eine Vertrauenskette statt. Jeder Webserver hat ein Zertifikat, das er jedem Client (gewöhnlich einem Webbrowser) vorlegt, aus dem hervorgeht, dass er derjenige ist, für den er sich ausgibt. Webserver erhalten diese Zertifikate oftmals von einer Stelle (der Zertifizierungsstelle oder CA), die für die Rechtmäßigkeit des Webservers bürgen kann. Das Zertifikat des Servers gibt die Stelle an, von der das Zertifikat erhalten wurde (den „Aussteller“). Webbrowser haben üblicherweise eine Liste von Ausstellern, denen sie vertrauen. Wenn einem Webbrowser ein Zertifikat von einem Webserver vorgelegt wird, prüft der Browser den Aussteller und vergleicht ihn mit seiner vertrauenswürdigen Liste. Wenn eine Übereinstimmung festgestellt wird, wird die Verbindung fortgesetzt; wenn keine Übereinstimmung festgestellt wird, gibt der Browser gewöhnlich eine Warnung aus und weist die Verbindung möglicherweise zurück. Abgesehen davon, dass sie vertrauenswürdig ist, ist eine CA nicht unbedingt eine besondere Entität. Jede beliebige Entität kann sich so einrichten, dass sie Zertifikaten vertraut oder Zertifikate signiert. Ein Zertifikat kann sich selbst vertrauen, was als ein selbst signiertes Zertifikat bezeichnet wird. Um mit einem Client unter Verwendung von SSL/TLS zusammenzuarbeiten, ist es notwendig, Zertifikate zu erstellen, denen der Client stillschweigend vertraut.
  • Wie vorstehend erwähnt wurde, signieren Zertifizierungsstellen die Zertifikate, die sie ausgeben, digital unter Verwendung ihres eignen privaten Schlüssels. Somit kann eine andere Partei die Informationen in einem Zertifikat einschließlich seiner Erweiterungen überprüfen, indem sie die Signatur auf dem Zertifikat mit dem eigenen öffentlichen Schlüssel der Zertifizierungsstelle auf Gültigkeit prüft. Die andere Partei erhält den öffentlichen Schlüssel der Zertifizierungsstelle aus einem an die Zertifizierungsstelle ausgegebenen Zertifikat und nimmt eine Signaturprüfung vor, die den öffentlichen Schlüssel von noch einem weiteren Zertifikat einschließen könnte. Die Überprüfungskette kann in Abhängigkeit von der Zertifikatshierarchie ziemlich lang sein. 3 ist ein Beispiel einer einfachen Zertifikatshierarchie, die ein Protokoll mit einem öffentlichen Schlüssel verwendet.
  • Wie dargestellt ist, enthält eine Zertifikatshierarchie 300 mehrere Entitäten, wobei ein Endentitätszertifikat 302 durch eine untergeordnete Zertifizierungsstelle (CA #2) 304 ausgegeben wird. Ein Zertifikat 303 der CA #2 304 wird durch eine untergeordnete Zertifizierungsstelle (CA #1) 306 ausgegeben. Ein Zertifikat 305 der CA #1 306 wird durch eine Stammzertifizierungsstelle 308 ausgegeben. Das Zertifikat 307 der Stammzertifizierungsstelle 308 ist selbst ausgestellt, was bedeutet, dass ihr Zertifikat durch ihren eigenen privaten Schlüssel signiert ist (ein selbst signiertes Zertifikat). Die Kette der Signaturüberprüfung beginnt mit dem Endentitätszertifikat 302. Insbesondere wird der öffentliche Schlüssel der CA #2 zur Überprüfung der Signatur des Endentitätszertifikats 302 verwendet. Wenn diese Signatur gültig ist, wird der öffentliche Schlüssel der CA #1 306 zur Überprüfung der Signatur des Zertifikats 303 der CA #2 verwendet. Wenn diese Signatur gültig ist, wird der öffentliche Schlüssel des Stammzertifikats zur Überprüfung der Signatur des Zertifikats 305 der CA #1 verwendet. Schließlich wird die Signatur des Stammzertifikats 307 unter Verwendung seines eigenen öffentlichen Schlüssels überprüft. Eine Signaturüberprüfung für das selbst signierte Stammzertifikat stellt einfach sicher, dass das Stammzertifikat unverändert ist. Sie gewährleistet nicht, dass die Informationen in dem Zertifikat oder die Zertifizierungsstelle selbst vertrauenswürdig sind/ist, da jeder ein selbst signiertes Zertifikat erstellen und behaupten kann, eine Zertifizierungsstelle zu sein. Folglich muss das Vertrauen in den eigenen ausgewählten Satz von Zertifizierungsstellen und einzelnen Zertifikaten einer Entität hergestellt werden, bevor Protokolle mit öffentlichem Schlüssel verwendet werden. Der ausgewählte Satz von vertrauenswürdigen Zertifikaten oder CAs wird zuweilen als vertrauenswürdige Roots, vertrauenswürdige Unterzeichner oder einfach als Trust-Richtlinie bezeichnet.
  • Server können konfigurierbar sein, um eine Trust-Richtlinie auszuführen und durchzusetzen. Ein Beispiel eines handelsüblichen Servers dieses Typs ist der IBM® z/OS® Security Server. Security Server ist ein optionales Merkmal von z/OS, das es einem Administrator ermöglicht, einen Zugriff auf geschützte Ressourcen zu kontrollieren. IBM Security Server umfasst IBM RACF® (Resource Access Control Facility). Für Java®-Benutzer stellt RACF einen Satz von Java Security Administration-APIs bereit, um eine Verwaltung von Benutzern und Gruppen in Sicherheitsrepositories aus z/OS RACF- oder anderen Nicht-z/OS-Sicherheitsmechanismen zu ermöglichen. RACF unterstützt Trust-Richtlinien, wie vorstehend beschrieben, durch RACF-Schlüsselringe. Wie andere Sicherheitssoftware, die digitale Zertifikate unterstützt, verfügt RACF über ein Verfahren, das dazu dient, einen vordefinierten Satz von vertrauenswürdigen Stammzertifikaten zu liefern. Dazu umfasst RACF einen Basissatz von Zertifikaten einer Zertifizierungsstelle, die immer, wenn das System erstmalig geladen wird, zu der RACF-Datenbank hinzugefügt werden.
  • Verallgemeinernd kann gesagt werden, dass sich Hierarchien einer Zertifizierungsstelle (CA) in Zertifikatsketten widerspiegeln. Eine Zertifikatskette überwacht einen Pfad von Zertifikaten, z.B. von einem Zweig in der Hierarchie zur Wurzel der Hierarchie. In einer Zertifikatskette folgt auf jedes Zertifikat das Zertifikat seines Ausstellers und jedes Zertifikat enthält den eindeutigen Namen (DN, distinguished name) des Ausstellers dieses Zertifikats. Dieser ist identisch mit dem Subjektnamen des nächsten Zertifikats in der Zertifikatskette. Jedes Zertifikat wird mit dem privaten Schlüssel seines Ausstellers signiert. Die Signatur kann mit dem öffentlichen Schlüssel in dem Zertifikat des Ausstellers überprüft werden, welches das nächste Zertifikat in der Zertifikatskette ist.
  • 4 stellt einen SSL/TLS-Handshake zwischen einem Client 400 und einem Server 402 ohne Bezugnahme auf die Technik dieser Offenbarung dar. Es wird davon ausgegangen, dass der Client 400 und der Server 402 einen geheimen Schlüssel (S) verwenden, den sie gemeinsam nutzen, um Daten zu verschlüsseln und zu entschlüsseln. Um den geheimen Schlüssel gemeinsam zu nutzen, wird des Weiteren davon ausgegangen, dass ein RSA-(Rivest-Shamir-Adelman-)Verschlüsselungssystem mit öffentlichem Schlüssel verwendet wird. Vertrautheit mit der normbasierten TLS 1.0, 1.1 und 1.2 wird im Folgenden vorausgesetzt.
  • Der Handshake beginnt im Schritt (1) damit, dass der Server 402 eine gültige TLS-ClientHello-Nachricht 401 von dem Client 400 empfängt. Im Schritt (2) antwortet der Server 402 mit einer ServerHello-Nachricht 403, auf die das Zertifikat 405 des Servers und beliebige andere Zertifikate in der Kette (wie durch TLS 1.0, 1.1 oder 1.2 definiert) folgen. Das Zertifikat 405 umfasst den öffentlichen Schlüssel des Servers, nämlich server-cert-key-pub. Im Schritt (3) prüft der Client das Zertifikat mit öffentlichem Schlüssel des Servers auf Gültigkeit. Wie dargestellt ist, erzeugt der Client 400 dann einen kryptografisch sicheren geheimen Schlüssel (S) und verschlüsselt diesen geheimen Schlüssel mit dem öffentlichen Schlüssel des Servers (server-cert-key-pub), der in dem Zertifikat mit öffentlichem Schlüssel des Servers bereitgestellt wurde. Im Schritt (4) sendet der Client 400 den verschlüsselten Schlüssel (C) an den Server 402 in einer ClientKeyExchangeMessage (wie durch TLS 1.0, 1.1 oder 1.2 definiert) 407. Im Schritt (5) entschlüsselt der Server 402 den geheimen Schlüssel (S) aus dem verschlüsselten Schlüssel (C) unter Verwendung des privaten Schlüssels des Servers, nämlich server-cert-key-priv. Im Schritt (6) antwortet der Server 402 dem Client 400, dass der Handshakeprozess beendet ist. Alle zukünftigen verschlüsselten Nachrichten in TLS (einschließlich Anwendungsdaten) werden dann unter Verwendung des geheimen Schlüssels (S) verschlüsselt, den jetzt beide Seiten des Datenaustauschs besitzen. Zum Beispiel verschlüsselt der Client 400 im Schritt (7) Anwendungsdaten unter Verwendung des geheimen Schlüssels (S). Die Anwendungsdaten werden dann z.B. im Schritt (8) vom Client 400 an den Server 402 gesendet. Auf dem Server und im Schritt (9) stellt der Server die Anwendungsdaten wieder her, indem er den geheimen Schlüssel (S) auf die von dem Client empfangenen Daten anwendet. Ebenso werden durch den Server gesendete Anwendungsdaten zuerst mit dem geheimen Schlüssel (S) verschlüsselt, z.B. im Schritt (10), an den Client übertragen, z.B. im Schritt (11), am Client unter Verwendung des geheimen Schlüssels (S) entschlüsselt, z.B. im Schritt (12), usw. Wenn der Client die Verbindung schließen möchte, benachrichtigt er den Server, z.B. im Schritt (13), um die Sitzung abzuschließen.
  • In dem vorstehend beschriebenen Szenario gibt es ein Problem. Insbesondere ist das RSA-Schlüsselpaar des Servers, nämlich server-cert-key-priv und server-cert-key-pub, statischer Natur und somit führt eine Beeinträchtigung des statischen privaten RSA-Schlüssels des Servers möglicherweise zu einem Verlust der Vertraulichkeit für alle Sitzungsdaten. Der Grund hierfür ist, dass die Daten einer jeden Sitzung mit dem geheimen Schlüssel (S) verschlüsselt werden, der unter dem statischen RSA-Schlüssel des Servers (server-cert-key-priv) ausgetauscht wird. Ein Angriff dieses Typs ist relativ einfach. Dazu zeichnet ein Angreifer einfach übertragenen verschlüsselten Verkehr zwischen dem Client 400 und dem Server 402 für alle Verbindungen auf. Obwohl der für jede Verbindung verwendete geheime Schlüssel anders ist, sind alle geheimen Schlüssel durch den privaten Schlüssel des Servers geschützt. Wenn der Angreifer Zugang zu dem Schlüssel erlangt, z.B. durch Brute-Force- oder andere Angriffsvektoren, können die geheimen Schlüssel (S) für gemeinsame Nutzung von allen aufgezeichneten Verbindungen folglich entschlüsselt werden und dann können alle Anwendungsdaten wiederhergestellt und angezeigt werden. Diese Situation ist als eine Situation bekannt, in der man keine absolute vorwärts gerichtete Sicherheit (PFS, Perfect Forward Secrecy) hat.
  • Verwenden von ephemeren Schlüsselpaaren in ephemeren Transportzertifikaten für vorwärts gerichtete Sicherheit
  • Mit dem Vorstehenden als Hintergrund wird die Technik dieser Offenbarung nun beschrieben.
  • Insbesondere wird die Technik in 4 erweitert, indem man den Server und den Client anstelle des statischen privaten RSA-Schlüssels des Servers ephemere Schlüssel verwenden lässt. In der Verwendung hierin wird ein Verschlüsselungsschlüssel als „ephemer“ (und somit als ein „ephemerer Schlüssel“) betrachtet, da er für jede Ausführung eines Schlüsselerstellungsprozesses erzeugt wird, wie zu sehen sein wird. Um gemäß der Technik hierin Perfect Forward Secrecy (PFS) zu erreichen, verwendet der Server ephemere private und öffentliche (vorzugsweise RSA-)Schlüssel anstelle seines statischen privaten Schlüssels. Die bevorzugte Technik wird nun unter Bezugnahme auf 5 beschrieben.
  • Insbesondere stellt 5 einen SSL/TLS-Handshake zwischen einem Client 500 und einem Server 502 gemäß dieser Offenbarung dar. Wie bei der vorherigen Ausführungsform wird davon ausgegangen, dass der Client 500 und der Server 502 einen geheimen Schlüssel (S) verwenden, den sie gemeinsam nutzen, um Daten zu verschlüsseln und zu entschlüsseln. Um den geheimen Schlüssel gemeinsam zu nutzen, wird des Weiteren davon ausgegangen, dass ein RSA-(Rivest-Shamir-Adelman-)Verschlüsselungssystem mit öffentlichem Schlüssel verwendet wird.
  • Erneut beginnt der Handshake im Schritt (1) damit, dass der Server 502 eine gültige TLS-ClientHello-Nachricht 501 von dem Client 500 empfängt. Anstatt dass der Server wie zuvor einfach mit seinem Serverzertifikat (und dem öffentlichen Schlüssel des Servers) antwortet, wird die folgende zusätzliche Verarbeitung durchgeführt. Insbesondere erhält der Server 502 im Schritt (2) ein ephemeres öffentliches RSA-Schlüsselpaar (temporary-keys) und erstellt ein temporäres Zertifikat (temporary-cert). Der Begriff „temporär“ bezieht sich hier auf die Lebensdauer einer einzelnen Sitzung im Vergleich zur herkömmlichen Verwendung von RSA, bei der für Schlüssel bei der Ausgabe gewöhnlich ein Ablaufdatum festgelegt wird (üblicherweise im Bereich von Jahren) oder sie aufgrund einer Beeinträchtigung manuell widerrufen werden. Das ephemere öffentliche Schlüsselpaar (das einen ephemeren öffentlichen Schlüssel und seinen zugehörigen privaten Schlüssel aufweist) kann während des Betriebs (d.h. zum Zeitpunkt des Handshakes) erzeugt werden, ein bevorzugter Ansatz ist jedoch, dass der Server ein Schlüsselpaar aus einem Pool von vorab erzeugten ephemeren Schlüsselpaaren abruft. Um als ephemer betrachtet zu werden, werden die ephemeren Schlüssel (temporary-keys) nur ein Mal pro Sitzung verwendet. Vorzugsweise werden die Schlüsselpaare zufällig oder pseudozufällig erzeugt, so dass der Schlüsselwert nicht vorhersehbar ist oder aus bekannten Daten abgeleitet werden kann.
  • Im Schritt (2) und wie dargestellt ist, signiert der Server 502 den ephemeren öffentlichen Schlüssel (temporary-key-pub) digital (d.h., er erstellt eine digitale Signatur) unter Verwendung des privaten Schlüssels des Servers (server-cert-key-priv), um das temporäre Zertifikat (temporary-cert) zu erstellen. Im Schritt (3) antwortet der Server auf die ClientHello-Nachricht 501 mit einer ServerHello-Nachricht 503, die das temporäre Zertifikat (das den ephemeren öffentlichen Schlüssel umfasst), das Zertifikat des Servers (das den öffentlichen Schlüssel des Servers umfasst) und beliebige andere Zertifikate in der Kette (wie durch TLS 1.0, 1.1 oder 1.2 definiert) umfasst. Diese Operationen (das Erhalten des ephemeren Schlüsselpaares durch den Server und das Signieren des ephemeren öffentlichen Schlüssels mit dem privaten Schlüssel des Servers, um das temporäre Zertifikat zu erstellen, sowie das anschließende Aufnehmen des temporären Zertifikats in die Server-Antwort) unterscheiden diesen Ablauf von dem in 4 gezeigten. Im Schritt (4) führt der Client 500 dann eine Gültigkeitsprüfung durch. Diese Gültigkeitsprüfung unterscheidet sich von derjenigen in dem früheren Ablauf dahingehend, dass der Client 500 nicht nur das Zertifikat mit öffentlichem Schlüssel des Servers auf Gültigkeit prüft, sondern auch versucht, das temporäre Zertifikat auf Gültigkeit zu prüfen. Wenn alle Zertifikate (in der Kette) auf Gültigkeit geprüft sind, erzeugt der Client 500 den kryptografisch sicheren geheimen Schlüssel (S) und verschlüsselt in diesem Ablauf diesen geheimen Schlüssel mit dem ephemeren öffentlichen Schlüssel (temporary-cert-key-pub), anstatt wie in dem vorherigen Ablauf den öffentlichen Schlüssel des Servers zu verwenden. Im Schritt (5) sendet der Client 500 den verschlüsselten Schlüssel (C) in der ClientKeyExchangeMessage 507 an den Server 502. Im Schritt (6) entschlüsselt der Server 502 den geheimen Schlüssel (S) aus dem verschlüsselten Schlüssel (C), wobei er in diesem Ablauf den temporären privaten Schlüssel des ephemeren öffentlichen Schlüsselpaares, nämlich temporary-cert-key-priv, anstelle des privaten Schlüssels des Servers (wie in 4) verwendet. Im Schritt (7) antwortet der Server 502 dem Client 500, dass der Handshakeprozess beendet ist.
  • Alle zukünftigen verschlüsselten Nachrichten in TLS (einschließlich Anwendungsdaten) werden dann unter Verwendung des geheimen Schlüssels (S) verschlüsselt, den jetzt beide Seiten des Datenaustauschs besitzen. Zum Beispiel verschlüsselt der Client 500 im Schritt (8) Anwendungsdaten unter Verwendung des geheimen Schlüssels (S). Die Anwendungsdaten werden dann z.B. im Schritt (9) vom Client 500 an den Server 502 gesendet. Auf dem Server und im Schritt (10) stellt der Server die Anwendungsdaten wieder her, indem er den geheimen Schlüssel (S) auf die von dem Client empfangenen Daten anwendet. Ebenso werden durch den Server gesendete Anwendungsdaten zuerst mit dem geheimen Schlüssel (S) verschlüsselt, z.B. im Schritt (11), an den Client übertragen, z.B. im Schritt (12), am Client unter Verwendung des geheimen Schlüssels (S) entschlüsselt, z.B. im Schritt (13), usw. Wenn der Client die Verbindung schließen möchte, benachrichtigt er den Server, z.B. im Schritt (14), um die Sitzung abzuschließen.
  • Wie der Fachmann versteht, werden durch Verwendung von ephemeren Schlüsseln während des Handshakes mehrere Vorteile erzielt. Insbesondere wird der statische private Schlüssel des Endentitätszertifikat des Servers nur zur Ausgabe der temporären Zertifikate verwendet, jedoch wird dieser statische private Schlüssel in dem physikalischen Austausch des geheimen Schlüssels über die Leitung nicht mehr verwendet. Die vorstehend beschriebene Verwendung des privaten Schlüssels des Servers ist gleichbedeutend mit einer digitalen Signaturoperation und nicht mit einer Verschlüsselung und somit gibt eine zukünftige Offenlegung des privaten Schlüssels des Servers den verwendeten ephemeren Schlüssel selbst nicht preis, wodurch eine absolute vorwärts gerichtete Sicherheit sichergestellt wird. Wenn ein Angreifer Zugang zu dem privaten Schlüssel des Servers erlangt, sind die Nachrichten somit immer noch sicher, da der ephemere private Schlüssel unbekannt ist und es für den Angreifer keine Möglichkeit gibt, den geheimen Sitzungsschlüssel (S) zu erhalten. Anders ausgedrückt, die ephemeren Schlüsselpaare werden vorzugsweise zufällig erzeugt und sind per definitionem kurzlebig, was eine vorwärts gerichtete Sicherheit selbst dann ermöglicht, wenn der private Schlüssel des Servers offengelegt wird. Das Zertifikat der Serverentität wird lediglich zum Signieren des kurzlebigen Schlüssels verwendet, um das temporäre Zertifikat zu erstellen und es dem Client zu ermöglichen (unter Verwendung dieses Zertifikats der Serverentität), das ephemere Transportzertifikat auf Gültigkeit zu prüfen. Der Ansatz hat einen weiteren Vorteil, der darin besteht, eine Neuverhandlung bei Bedarf zu vermeiden, um die Verbindung zwischen dem Client und dem Server herabzustufen.
  • Bei dem Ansatz hierin wird das Server-Endentitätszertifikat als eine untergeordnete Zertifizierungsstelle verwendet. Wie erwähnt wurde, erstellt der Server das temporäre Zertifikat unter Verwendung des ephemeren Schlüsselpaares für die Sitzung, signiert und sendet dieses temporäre Zertifikat als Teil der Zertifikatskette, die das Serverzertifikat umfasst, welches dann wiederum an dem Client verwendet wird, um das Transportzertifikat auf Gültigkeit zu prüfen. Wenn die Gültigkeitsprüfungen erfolgreich sind, verwendet der Client den ephemeren öffentlichen Schlüssel, den er in dem Transportzertifikat empfangen hat, um den durch den Client erzeugten geheimen Schlüssel (S) für gemeinsame Nutzung zu verschlüsseln, der an dem Server benötigt wird, um den Handshake abzuschließen. Der geheime Schlüssel (S) hat dann die Funktion des symmetrischen Sitzungsschlüssels, um Daten für die hergestellte Verbindung zu verschlüsseln und zu entschlüsseln. Eine Verwendung von ephemeren Schlüsseln zum Austausch des Sitzungsschlüssels stellt eine absolute vorwärts gerichtete Sicherheit bereit. Tatsächlich wirkt sich keine Beeinträchtigung des privaten Schlüssels des Servers dahingehend aus, dass viele TLS-Sitzungsschlüssel beeinträchtigt werden. Eine Beeinträchtigung eines ephemeren privaten RSA-Schlüssels beeinträchtigt nur die Sitzung, zu deren Aufbau er verwendet wird, und eine Beeinträchtigung des statischen privaten RSA-Schlüssels des Servers lässt nur eine Erstellung von ungültigen Signaturen zu, beeinträchtigt aber keine vorherigen TLS-Sitzungen.
  • Zwar wird der Ansatz unter Verwendung von RSA als dem bevorzugten Verschlüsselungsschema mit öffentlichem Schlüssel beschrieben, doch ist dies keine Voraussetzung, da das statische Schlüsselpaar durch andere asymmetrische Verschlüsselungsalgorithmen, die digitale Signaturoperationen unterstützen, ersetzt werden kann, und die ephemeren Schlüsselpaare durch andere asymmetrische Verschlüsselungsalgorithmen, die eine Verschlüsselung/Entschlüsselung unterstützen, ersetzt werden können. Verallgemeinernd kann gesagt werden, dass die Technik hierin mit einem beliebigen Protokoll verwendet werden kann, das Public Key Infrastructure (PKI) verwendet und bei dem insbesondere ein Schlüsselpaar (a) für eine statische digitale Signatur ein ephemeres asymmetrisches Verschlüsselungsschlüsselpaar (e) signiert, das verwendet wird, um (einen) geheime(n) Schlüssel für gemeinsame Nutzung auszutauschen.
  • Während eine bevorzugte Betriebsumgebung und ein bevorzugter Anwendungsfall beschrieben wurden, können die Techniken hierin in jeder beliebigen anderen Betriebsumgebung verwendet werden, in der Netzverkehr an ein(e) und/oder von einem/einer Datenverarbeitungssystem oder Datenverarbeitungseinheit auf Wunsch geschützt werden soll.
  • Wie beschrieben wurde, kann die vorstehend beschriebene Funktionalität als ein eigenständiger Ansatz, z.B. eine durch einen Prozessor ausgeführte softwarebasierte Funktion, ausgeführt werden oder sie kann als ein Service (darunter ein Web-Service über eine SOAP/XML-Schnittstelle) zur Verfügung stehen. Die hierin beschriebenen jeweiligen Einzelheiten der Hardware- und Software-Ausführung dienen lediglich dem Zweck der Veranschaulichung und sind nicht dazu gedacht, den Umfang des beschriebenen Gegenstands einzuschränken.
  • Allgemeiner ausgedrückt, bei jeder der Datenverarbeitungseinheiten im Kontext des offenbarten Gegenstands handelt es sich um ein Datenverarbeitungssystem (wie es beispielsweise in 2 gezeigt ist), das Hardware und Software aufweist, und diese Entitäten tauschen untereinander über ein Netzwerk wie beispielsweise das Internet, ein Intranet, ein Extranet, ein privates Netzwerk oder ein(e) beliebige(s) andere(s) Übertragungsmedium oder -verbindung Daten aus. Die Anwendungen auf dem Datenverarbeitungssystem stellen native Unterstützung für Web- und andere bekannte Services und Protokolle bereit, darunter, ohne darauf beschränkt zu sein, Unterstützung für HTTP, FTP, SMTP, SOAP, XML, WSDL, UDDI sowie WSFL u.a. Informationen zu SOAP, WSDL, UDDI und WSFL werden vom World Wide Web Consortium (W3C) zur Verfügung gestellt, das für die Entwicklung und die Pflege dieser Standards zuständig ist; weitere Informationen zu HTTP, FTP, SMTP und XML werden von der Internet Engineering Task Force (IETF) zur Verfügung gestellt. Vertrautheit mit diesen bekannten Standards und Protokollen wird vorausgesetzt.
  • Die hierin beschriebenen Techniken können in oder in Verbindung mit verschiedenen clientseitigen Architekturen (z.B. Firewalls, NAT-Einheiten) und in oder in Verbindung mit verschiedenen serverseitigen Architekturen, darunter einfachen n-schichtigen Architekturen, Webportalen, föderierten Systemen und dergleichen, ausgeführt werden. Die Techniken hierin können in einem lose verbundenen Server (darunter einer „cloudbasierten“) Umgebung in die Praxis umgesetzt werden.
  • Noch allgemeiner ausgedrückt, der hierin beschriebene Gegenstand kann die Form einer reinen Hardware-Ausführung, einer reinen Software-Ausführung oder einer Ausführung annehmen, die sowohl Hardware- als auch Software-Elemente enthält. In einer bevorzugten Ausführungsform ist die vertrauenswürdige Plattformmodul-Funktion in Software ausgeführt, die, ohne darauf beschränkt zu sein, Firmware, residente Software, Mikrocode und dergleichen umfasst. Darüber hinaus können die Download- und Lösch-Schnittstellen und -Funktionalität die Form eines Computerprogrammprodukts annehmen, auf das von einem durch einen Computer verwendbaren oder durch einen Computer lesbaren Datenträger zugegriffen werden kann, welcher Programmcode zur Verwendung durch einen Computer oder ein beliebiges Anweisungsausführungssystem oder in Verbindung mit einem Computer oder einem beliebigen Anweisungsausführungssystem bereitstellt. Für die Zwecke dieser Beschreibung kann ein durch einen Computer verwendbarer oder durch einen Computer lesbarer Datenträger eine beliebige Vorrichtung sein, die das Programm zur Verwendung durch das Anweisungsausführungssystem, die Anweisungsausführungsvorrichtung oder -einheit oder zur Verwendung in Verbindung mit dem Anweisungsausführungssystem, der Anweisungsausführungsvorrichtung oder -einheit enthalten oder speichern kann. Bei dem Datenträger kann es sich um ein(e) elektronische(s), magnetische(s), optische(s), elektromagnetische(s), Infrarot- oder Halbleitersystem (oder - vorrichtung oder -einheit) handeln. Zu Beispielen für einen durch einen Computer lesbaren Datenträger gehören ein Halbleiter- oder Solid-State-Speicher, ein Magnetband, eine entfernbare Computerdiskette, ein Arbeitsspeicher (RAM), ein Nur-Lese-Speicher (ROM), eine magnetische Festplatte und eine optische Platte. Zu aktuellen Beispielen für optische Platten gehören Compact-Disk-Nur-Lese-Speicher (CD-ROM), Compact-Disk-R/W (CD-R/W) und DVD. Der durch einen Computer lesbare Datenträger ist ein greifbarer, nicht flüchtiger Gegenstand.
  • Bei dem Computerprogrammprodukt kann es sich um ein Produkt handeln, das über Programmanweisungen (oder Programmcode) verfügt, um eine oder mehrere der beschriebenen Funktionen auszuführen. Diese Anweisungen bzw. dieser Code können/kann auf einem nicht flüchtigen, durch einen Computer lesbaren Speichermedium in einem Datenverarbeitungssystem gespeichert werden, nachdem sie/er über ein Netzwerk von einem fernen Datenverarbeitungssystem heruntergeladen wurde(n). Oder diese Anweisungen bzw. dieser Code kann auf einem durch einen Computer lesbaren Speichermedium in einem Server-Datenverarbeitungssystem gespeichert und so angepasst werden, dass sie/er über ein Netzwerk auf ein fernes Datenverarbeitungssystem zur Verwendung in einem durch einen Computer lesbaren Speichermedium in dem fernen System heruntergeladen werden können/kann.
  • In einer repräsentativen Ausführungsform sind die Schnittstellen und das Dienstprogramm in einer Spezialdatenverarbeitungsplattform ausgeführt, vorzugsweise in Software, die durch einen oder mehrere Prozessoren ausgeführt wird. Die Software wird in einem oder mehreren Datenspeichern oder Hauptspeichern, die zu dem einen oder den mehreren Prozessoren gehören, verwaltet und die Software kann als ein oder mehrere Computerprogramme ausgeführt sein. Gemeinsam weist diese Spezialhardware und - software die vorstehend beschriebene Funktionalität auf.
  • Während das Vorstehende eine bestimmte Reihenfolge von Operationen beschreibt, die durch bestimmte Ausführungsformen der Erfindung durchgeführt werden, sollte klar sein, dass eine solche Reihenfolge beispielhaft ist, da alternative Ausführungsformen die Operationen in einer anderen Reihenfolge durchführen, bestimmte Operationen kombinieren, bestimmte Operationen überlappen oder dergleichen können. Verweise in der Spezifikation auf eine bestimmte Ausführungsform zeigen an, dass die beschriebene Ausführungsform ein(e) bestimmte(s) Merkmal, Struktur oder Eigenschaft umfassen kann, jede Ausführungsform das/die bestimmte Merkmal, Struktur oder Eigenschaft gegebenenfalls aber nicht unbedingt umfasst.
  • Schließlich, während bestimmte Komponenten des Systems getrennt beschrieben wurden, versteht der Fachmann, dass einige der Funktionen in bestimmten Anweisungen, Programmabfolgen, Codeteilen und dergleichen kombiniert oder gemeinsam genutzt werden können.
  • Die Techniken hierin sorgen allgemein für die vorstehend beschriebenen Verbesserungen an einer Technologie oder einem technischen Gebiet sowie die spezifischen technologischen Verbesserungen an kryptografisch sicheren Netzübertragungen, wie sie vorstehend beschrieben wurden.

Claims (18)

  1. Verfahren zum Verhindern einer Beeinträchtigung eines Satzes von abgeleiteten Sitzungsschlüsseln für eine auf der Transport Layer Security,TLS, basierende Verbindung zwischen einem Client und einem Server, wobei der Server über ein öffentliches Schlüsselpaar verfügt, das einen öffentlichen Schlüssel des Servers und einen zugehörigen privaten Schlüssel des Servers aufweist, wobei das Verfahren umfasst: an dem Server: als Reaktion auf einen Empfang einer Anforderung, eine neue Sitzung aufzubauen, Erhalten eines ephemeren Schlüsselpaares des Servers, das einen ephemeren öffentlichen Schlüssel und einen zugehörigen ephemeren privaten Schlüssel aufweist; Erzeugen eines temporären Zertifikats, indem der ephemere öffentliche Schlüssel unter Verwendung des privaten Schlüssels des Servers signiert wird; Ausgeben einer Zertifikatskette an den Client, die mindestens das temporäre Zertifikat, das den ephemeren öffentlichen Schlüssel umfasst, zusammen mit einem Serverzertifikat aufweist, das den öffentlichen Schlüssel des Servers umfasst; Empfangen einer Nachricht von dem Client, wobei die Nachricht durch den Client erzeugt wurde, der den ephemeren öffentlichen Schlüssel des Servers auf einen Sitzungsschlüssel anwendet, welcher für die neue Sitzung abgeleitet wurde; und Wiederherstellen des für die neue Sitzung abgeleiteten Sitzungsschlüssels, indem der ephemere private Schlüssel des Servers auf die Nachricht angewendet wird, um den Aufbau der neuen Sitzung abzuschließen; wobei eine Beeinträchtigung eines mit dem Aufbau der neuen Sitzung verbundenen Schlüssels einen oder mehrere andere abgeleitete Sitzungsschlüssel des Satzes nicht beeinträchtigt.
  2. Verfahren gemäß Anspruch 1, das vor dem Empfang der Anforderung des Weiteren ein Erzeugen eines Pools von ephemeren Schlüsselpaaren umfasst, wobei das ephemere Schlüsselpaar aus dem Pool abgerufen wird.
  3. Verfahren gemäß Anspruch 1, wobei das ephemere Schlüsselpaar im Anschluss an ein Schließen der neuen Sitzung verworfen und nicht wieder verwendet wird.
  4. Verfahren gemäß Anspruch 1, wobei das Serverzertifikat als eine untergeordnete Zertifizierungsstelle dient.
  5. Verfahren gemäß Anspruch 1, wobei jedes der Schlüsselpaare ein Rivest-Shamir-Adelman-,RSA-,Schlüsselpaar ist.
  6. Verfahren gemäß Anspruch 1, wobei das ephemere Schlüsselpaar des Servers zufällig erzeugt wird.
  7. Als Server konfigurierte Vorrichtung, die aufweist: einen Prozessor; Computerspeicher, der Computerprogrammanweisungen enthält, die durch den Prozessor ausgeführt werden, wobei die Computerprogrammanweisungen Programmcode aufweisen, der so konfiguriert ist, dass er eine Beeinträchtigung eines Satzes von abgeleiteten Sitzungsschlüsseln für eine auf der Transport Layer Security (TLS) basierende Verbindung zwischen einem Client und dem Server verhindert, wobei der Server über ein öffentliches Schlüsselpaar verfügt, das einen öffentlichen Schlüssel des Servers und einen zugehörigen privaten Schlüssel des Servers aufweist, wobei der Programmcode so konfiguriert ist, dass er an dem Server: als Reaktion auf einen Empfang einer Anforderung, eine neue Sitzung aufzubauen, ein ephemeres Schlüsselpaar des Servers erhält, das einen ephemeren öffentlichen Schlüssel und einen zugehörigen ephemeren privaten Schlüssel aufweist; ein temporäres Zertifikat erzeugt, indem er den ephemeren öffentlichen Schlüssel unter Verwendung des privaten Schlüssels des Servers signiert; eine Zertifikatskette an den Client ausgibt, die mindestens das temporäre Zertifikat, das den ephemeren öffentlichen Schlüssel umfasst, zusammen mit einem Serverzertifikat aufweist, das den öffentlichen Schlüssel des Servers umfasst; eine Nachricht von dem Client empfängt, wobei die Nachricht durch den Client erzeugt wurde, der den ephemeren öffentlichen Schlüssel des Servers auf einen Sitzungsschlüssel anwendet, welcher für die neue Sitzung abgeleitet wurde; und den für die neue Sitzung abgeleiteten Sitzungsschlüssel wiederherstellt, indem er den ephemeren privaten Schlüssel des Servers auf die Nachricht anwendet, um den Aufbau der neuen Sitzung abzuschließen; wobei eine Beeinträchtigung eines mit dem Aufbau der neuen Sitzung verbundenen Schlüssels einen oder mehrere andere abgeleitete Sitzungsschlüssel des Satzes nicht beeinträchtigt.
  8. Vorrichtung gemäß Anspruch 7, wobei der Programmcode des Weiteren so konfiguriert ist, dass er vor dem Empfang der Anforderung einen Pool von ephemeren Schlüsselpaaren erzeugt, wobei das ephemere Schlüsselpaar aus dem Pool abgerufen wird.
  9. Vorrichtung gemäß Anspruch 7, wobei der Programmcode des Weiteren so konfiguriert ist, dass er das ephemere Schlüsselpaar verwirft und dessen Wiederverwendung verhindert, nachdem die neue Sitzung geschlossen wurde.
  10. Vorrichtung gemäß Anspruch 7, wobei das Serverzertifikat als eine untergeordnete Zertifizierungsstelle dient.
  11. Vorrichtung gemäß Anspruch 7, wobei jedes der Schlüsselpaare ein Rivest-Shamir-Adelman-,RSA-,Schlüsselpaar ist.
  12. Vorrichtung gemäß Anspruch 7, wobei der Programmcode so konfiguriert ist, dass er das ephemere Schlüsselpaar des Servers zufällig erzeugt.
  13. Computerprogrammprodukt in einem nicht flüchtigen, durch einen Computer lesbaren Datenträger zur Verwendung in einem Datenverarbeitungssystem, wobei das Computerprogrammprodukt Computerprogrammanweisungen enthält, die durch das Datenverarbeitungssystem ausgeführt werden, um eine Beeinträchtigung eines Satzes von abgeleiteten Sitzungsschlüsseln für eine auf der Transport Layer Security ,TLS, basierende Verbindung zwischen einem Client und einem Server zu verhindern, wobei der Server dem Datenverarbeitungssystem entspricht und über ein öffentliches Schlüsselpaar verfügt, das einen öffentlichen Schlüssel des Servers und einen zugehörigen privaten Schlüssel des Servers aufweist, wobei die Computerprogrammanweisungen Programmcode aufweisen, der so konfiguriert ist, dass er an dem Server: als Reaktion auf einen Empfang einer Anforderung, eine neue Sitzung aufzubauen, ein ephemeres Schlüsselpaar des Servers erhält, das einen ephemeren öffentlichen Schlüssel und einen zugehörigen ephemeren privaten Schlüssel aufweist; ein temporäres Zertifikat erzeugt, indem er den ephemeren öffentlichen Schlüssel unter Verwendung des privaten Schlüssels des Servers signiert; eine Zertifikatskette an den Client ausgibt, die mindestens das temporäre Zertifikat, das den ephemeren öffentlichen Schlüssel umfasst, zusammen mit einem Serverzertifikat aufweist, das den öffentlichen Schlüssel des Servers umfasst; eine Nachricht von dem Client empfängt, wobei die Nachricht durch den Client erzeugt wurde, der den ephemeren öffentlichen Schlüssel des Servers auf einen Sitzungsschlüssel anwendet, welcher für die neue Sitzung abgeleitet wurde; und den für die neue Sitzung abgeleiteten Sitzungsschlüssel wiederherstellt, indem er den ephemeren privaten Schlüssel des Servers auf die Nachricht anwendet, um den Aufbau der neuen Sitzung abzuschließen; wobei eine Beeinträchtigung eines mit dem Aufbau der neuen Sitzung verbundenen Schlüssels einen oder mehrere andere abgeleitete Sitzungsschlüssel des Satzes nicht beeinträchtigt.
  14. Computerprogrammprodukt gemäß Anspruch 13, wobei der Programmcode des Weiteren so konfiguriert ist, dass er vor dem Empfang der Anforderung einen Pool von ephemeren Schlüsselpaaren erzeugt, wobei das ephemere Schlüsselpaar aus dem Pool abgerufen wird.
  15. Computerprogrammprodukt gemäß Anspruch 13, wobei der Programmcode des Weiteren so konfiguriert ist, dass er das ephemere Schlüsselpaar des Servers verwirft und dessen Wiederverwendung verhindert, nachdem die neue Sitzung geschlossen wurde.
  16. Computerprogrammprodukt gemäß Anspruch 13, wobei das Serverzertifikat als eine untergeordnete Zertifizierungsstelle dient.
  17. Computerprogrammprodukt gemäß Anspruch 13, wobei jedes der Schlüsselpaare ein Rivest-Shamir-Adelman-,RSA-,Schlüsselpaar ist.
  18. Computerprogrammprodukt gemäß Anspruch 17, wobei der Programmcode so konfiguriert ist, dass er das ephemere Schlüsselpaar des Servers zufällig erzeugt.
DE112020004236.7T 2019-11-11 2020-10-29 Vorwärts gerichtete sicherheit in der transport layer security unter verwendung von ephemeren schlüsseln Active DE112020004236B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/679,422 US11206135B2 (en) 2019-11-11 2019-11-11 Forward secrecy in Transport Layer Security (TLS) using ephemeral keys
US16/679,422 2019-11-11
PCT/IB2020/060142 WO2021094863A1 (en) 2019-11-11 2020-10-29 Forward secrecy in transport layer security using ephemeral keys

Publications (2)

Publication Number Publication Date
DE112020004236T5 DE112020004236T5 (de) 2022-06-15
DE112020004236B4 true DE112020004236B4 (de) 2023-10-05

Family

ID=75847197

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112020004236.7T Active DE112020004236B4 (de) 2019-11-11 2020-10-29 Vorwärts gerichtete sicherheit in der transport layer security unter verwendung von ephemeren schlüsseln

Country Status (6)

Country Link
US (2) US11206135B2 (de)
JP (1) JP2023501449A (de)
CN (1) CN114651421B (de)
DE (1) DE112020004236B4 (de)
GB (1) GB2603096B (de)
WO (1) WO2021094863A1 (de)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9531685B2 (en) * 2011-12-16 2016-12-27 Akamai Technologies, Inc. Providing forward secrecy in a terminating SSL/TLS connection proxy using Ephemeral Diffie-Hellman key exchange
US11991273B2 (en) * 2018-09-04 2024-05-21 International Business Machines Corporation Storage device key management for encrypted host data
US11038698B2 (en) 2018-09-04 2021-06-15 International Business Machines Corporation Securing a path at a selected node
US11088829B2 (en) 2018-09-04 2021-08-10 International Business Machines Corporation Securing a path at a node
US11405191B2 (en) * 2020-05-13 2022-08-02 Apple Inc. Guaranteed encryptor authenticity
US20210367767A1 (en) * 2020-05-21 2021-11-25 Marvell Asia Pte. Ltd. Methods and systems for secure network communication
US20210377309A1 (en) * 2020-06-02 2021-12-02 Hid Global Cid Sas System and method for establishing secure session with online disambiguation data
CN113411345B (zh) * 2021-06-29 2023-10-10 中国农业银行股份有限公司 一种安全会话的方法和装置
CN113556332A (zh) * 2021-07-09 2021-10-26 深圳市高德信通信股份有限公司 一种数据加密传输方法
CN113591109B (zh) * 2021-07-23 2023-05-02 上海瓶钵信息科技有限公司 可信执行环境与云端通信的方法及系统
US11930009B2 (en) 2021-10-17 2024-03-12 Oversec, Uab Optimized authentication mechanism
US20230153398A1 (en) * 2021-11-18 2023-05-18 DUDU Information Technologies, Inc. Apparatus and method for maintaining security of video data
US20230254111A1 (en) * 2022-02-09 2023-08-10 Ivanti, Inc. Automated validation of data sources in a managed network
CN115150099B (zh) * 2022-07-06 2023-02-17 渔翁信息技术股份有限公司 数据抗抵赖传输方法、数据发送端及数据接收端
CN115589305A (zh) * 2022-08-25 2023-01-10 重庆长安汽车股份有限公司 一种车控数据的处理方法、装置、设备及介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160234177A1 (en) 2013-09-13 2016-08-11 Vodafone Ip Licensing Ltd Secure communication with a mobile device
US20190245695A1 (en) 2017-06-21 2019-08-08 Visa International Service Association Secure communications providing forward secrecy

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2822002B1 (fr) 2001-03-12 2003-06-06 France Telecom Authentification cryptographique par modules ephemeres
JP3842100B2 (ja) 2001-10-15 2006-11-08 株式会社日立製作所 暗号化通信システムにおける認証処理方法及びそのシステム
US7409545B2 (en) * 2003-09-18 2008-08-05 Sun Microsystems, Inc. Ephemeral decryption utilizing binding functions
JP4406263B2 (ja) 2003-11-10 2010-01-27 独立行政法人産業技術総合研究所 管理装置、クライアント装置、およびそれらの装置を含むシステム
CN101479984B (zh) 2006-04-25 2011-06-08 斯蒂芬·L.·博伦 用于身份管理、验证服务器、数据安全和防止中间人攻击的动态分发密钥系统和方法
CN101459506B (zh) * 2007-12-14 2011-09-14 华为技术有限公司 密钥协商方法、用于密钥协商的系统、客户端及服务器
US8837741B2 (en) 2011-09-12 2014-09-16 Qualcomm Incorporated Systems and methods for encoding exchanges with a set of shared ephemeral key data
US9531685B2 (en) 2011-12-16 2016-12-27 Akamai Technologies, Inc. Providing forward secrecy in a terminating SSL/TLS connection proxy using Ephemeral Diffie-Hellman key exchange
US9531691B2 (en) 2011-12-16 2016-12-27 Akamai Technologies, Inc. Providing forward secrecy in a terminating TLS connection proxy
CN102510387B (zh) 2011-12-29 2014-06-04 西安西电捷通无线网络通信股份有限公司 一种安全传输层协议tls握手方法和装置及ttp
US9565180B2 (en) 2012-09-28 2017-02-07 Symantec Corporation Exchange of digital certificates in a client-proxy-server network configuration
US8782774B1 (en) 2013-03-07 2014-07-15 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
US9768921B2 (en) * 2015-01-08 2017-09-19 Marvell World Trade Ltd. Downlink signaling in a high efficiency wireless local area network (WLAN)
US11316666B2 (en) * 2017-07-12 2022-04-26 Amazon Technologies, Inc. Generating ephemeral key pools for sending and receiving secure communications

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160234177A1 (en) 2013-09-13 2016-08-11 Vodafone Ip Licensing Ltd Secure communication with a mobile device
US20190245695A1 (en) 2017-06-21 2019-08-08 Visa International Service Association Secure communications providing forward secrecy

Also Published As

Publication number Publication date
CN114651421B (zh) 2022-12-27
GB2603096A (en) 2022-07-27
GB202207323D0 (en) 2022-07-06
WO2021094863A1 (en) 2021-05-20
US20210144004A1 (en) 2021-05-13
US20220038278A1 (en) 2022-02-03
CN114651421A (zh) 2022-06-21
US11206135B2 (en) 2021-12-21
JP2023501449A (ja) 2023-01-18
US11985239B2 (en) 2024-05-14
GB2603096B (en) 2022-11-02
DE112020004236T5 (de) 2022-06-15

Similar Documents

Publication Publication Date Title
DE112020004236B4 (de) Vorwärts gerichtete sicherheit in der transport layer security unter verwendung von ephemeren schlüsseln
DE602005001613T2 (de) Einrichten eines sicheren kontexts zur übermittlung von nachrichten zwischen computersystemen
USRE49673E1 (en) Systems and methods for secure data exchange
DE112018001559B4 (de) Cachespeicherlose sitzungsticket-unterstützung bei tls-prüfung
US9800556B2 (en) Systems and methods for providing data security services
EP2289222B1 (de) Verfahren, authentikationsserver und diensteserver zum authentifizieren eines client
DE102018216915A1 (de) System und Verfahren für sichere Kommunikationen zwischen Steuereinrichtungen in einem Fahrzeugnetzwerk
DE112011101729T5 (de) Verwaltung von Ressourcenzugriff
DE112015000213T5 (de) Passwortgestützte Berechtigungsprüfung
KR20060100920A (ko) 웹 서비스를 위한 신뢰되는 제3자 인증
US20130019090A1 (en) Method and apparatus for certificate-based cookie security
EP1777907A1 (de) Vorrichtungen und Verfahren zum Durchführen von kryptographischen Operationen in einem Server-Client-Rechnernetzwerksystem
DE102015122518A1 (de) Authentifizierung von Datenkommunikationen
EP2929648A1 (de) Verfahren zum aufbau einer sicheren verbindung zwischen clients
EP3672142B1 (de) Verfahren und system zur sicheren übertragung eines datensatzes
Balusamy et al. Collective advancements on access control scheme for multi-authority cloud storage system
Zwattendorfer et al. Privacy-preserving realization of the STORK framework in the public cloud
DE112007000419B4 (de) Digitale-Rechte-Managementsystem mit diversifiziertem Inhaltsschutzprozess
Chakaravarthi et al. An intelligent agent based privacy preserving model for Web Service security
Guziur et al. Light blockchain communication protocol for secure data transfer integrity
DE102017101906A1 (de) Verfahren und System zur Authentisierung eines Benutzers
DE102016207635A1 (de) Verfahren und Vorrichtung zur Absicherung von Gerätezugriffen
EP4270863A1 (de) Sichere wiederherstellung privater schlüssel
DE202023105042U1 (de) Ein erweitertes Proxy-Neuverschlüsselungssystem zur Gewährleistung effizienter Sicherheit in Fog- und IoT-Netzwerken
DE102021205419A1 (de) Verfahren zur Verschlüsselung von Daten und Vorrichtung mit einer Applikation zur Verschlüsselung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R083 Amendment of/additions to inventor(s)
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R084 Declaration of willingness to licence