DE112021005237T5 - Verwaltung von privaten schlüsseln - Google Patents

Verwaltung von privaten schlüsseln Download PDF

Info

Publication number
DE112021005237T5
DE112021005237T5 DE112021005237.3T DE112021005237T DE112021005237T5 DE 112021005237 T5 DE112021005237 T5 DE 112021005237T5 DE 112021005237 T DE112021005237 T DE 112021005237T DE 112021005237 T5 DE112021005237 T5 DE 112021005237T5
Authority
DE
Germany
Prior art keywords
handshake
key
security proxy
message
context information
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
DE112021005237.3T
Other languages
English (en)
Inventor
Wei-Hsiang Hsiung
Chun-Shuo Lin
Wei-Jie Liau
Cheng-Ta Lee
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 DE112021005237T5 publication Critical patent/DE112021005237T5/de
Pending legal-status Critical Current

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/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/083—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) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • 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
    • 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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/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/0838—Key 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
    • 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/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • 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
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations

Abstract

Kontextinformationen eines Handshakes zwischen einer Quellenentität und einer Zielentität werden an einem Sicherheitsproxy erhalten. Die Kontextinformationen werden von dem Sicherheitsproxy an einen Schlüsselmanager gesendet. Der Schlüsselmanager verwaltet einen ersten privaten Schlüssel des Sicherheitsproxys. Eine erste Handshake-Nachricht wird von dem Schlüsselmanager empfangen. Die erste Handshake-Nachricht wird mindestens auf der Grundlage der Kontextinformationen erzeugt und mit dem ersten privaten Schlüssel signiert. Die erste Handshake-Nachricht wird dann an die Zielentität gesendet.

Description

  • HINTERGRUND
  • Die vorliegende Erfindung betrifft eine Datenverschlüsselung und insbesondere Verfahren, Systeme und Computerprogrammprodukte zur Verwaltung von privaten Schlüsseln.
  • Derzeit werden Anwendungen containerisiert und in einer Cloudumgebung eingesetzt, was Sicherheitsanforderungen mit sich bringt. Verschlüsselung ist eine gebräuchliche Strategie. Zum Beispiel wird der Netzwerkverkehr zwischen einem Client für eine Anwendung und einem Server für die Anwendung im Allgemeinen verschlüsselt.
  • KURZDARSTELLUNG
  • Einige Ausführungsformen der vorliegenden Offenbarung können als ein Verfahren veranschaulicht werden. Gemäß dem Verfahren werden Kontextinformationen eines Handshakes zwischen einer Quellenentität und einer Zielentität an einem Sicherheitsproxy erhalten. Die Kontextinformationen werden von dem Sicherheitsproxy an einen Schlüsselmanager gesendet. Hier verwaltet der Schlüsselmanager einen ersten privaten Schlüssel des Sicherheitsproxys. Eine erste Handshake-Nachricht wird dann von dem Schlüsselmanager empfangen. Hier wird die erste Handshake-Nachricht mindestens auf der Grundlage der Kontextinformationen erzeugt und mit dem ersten privaten Schlüssel signiert. Die erste Handshake-Nachricht wird dann an die Zielentität gesendet.
  • Einige Ausführungsformen der vorliegenden Offenbarung können als ein zweites Verfahren veranschaulicht werden. Gemäß dem zweiten Verfahren werden Kontextinformationen eines Handshakes zwischen einer Quellenentität und einer Zielentität von einem Sicherheitsproxy an einem Schlüsselmanager empfangen. Hier verwaltet der Schlüsselmanager einen ersten privaten Schlüssel des Sicherheitsproxys. Dann wird eine erste an die Zielentität geleitete Handshake-Nachricht mindestens auf der Grundlage der Kontextinformationen an dem Schlüsselmanager erzeugt. Hier wird die erste Handshake-Nachricht mit dem ersten privaten Schlüssel des Sicherheitsproxys signiert. Als Nächstes wird die erste Handshake-Nachricht an den Sicherheitsproxy gesendet.
  • Einige Ausführungsformen der vorliegenden Offenbarung können als ein System veranschaulicht werden. Das System weist eine Verarbeitungseinheit und einen mit der Verarbeitungseinheit verbundenen Arbeitsspeicher auf. Der Arbeitsspeicher speichert Anweisungen, die, wenn sie durch die Verarbeitungseinheit ausgeführt werden, Aktionen durchführen. Die Aktionen weisen ein Erhalten von Kontextinformationen eines Handshakes zwischen einer Quellenentität und einer Zielentität an einem Sicherheitsproxy auf. Die Aktionen weisen auch ein Senden der Kontextinformationen von dem Sicherheitsproxy an einen Schlüsselmanager auf. Hier verwaltet der Schlüsselmanager einen ersten privaten Schlüssel des Sicherheitsproxys. Die Aktionen weisen auch ein Empfangen einer ersten Handshake-Nachricht von dem Schlüsselmanager auf. Hier wird die erste Handshake-Nachricht mindestens auf der Grundlage der Kontextinformationen erzeugt und mit dem ersten privaten Schlüssel signiert. Die Aktionen weisen des Weiteren ein Senden der ersten Handshake-Nachricht an die Zielentität auf.
  • Einige Ausführungsformen der vorliegenden Offenbarung können als ein Computerprogrammprodukt veranschaulicht werden. Das Computerprogrammprodukt ist auf einem nicht transienten, maschinenlesbaren Datenträger greifbar gespeichert und weist Anweisungen in Maschinensprache auf. Die Anweisungen in Maschinensprache, wenn sie auf einer Einheit ausgeführt werden, veranlassen die Einheit dazu, Aktionen durchzuführen. Die Aktionen weisen ein Erhalten von Kontextinformationen eines Handshakes zwischen einer Quellenentität und einer Zielentität an einem Sicherheitsproxy auf. Die Aktionen weisen auch ein Senden der Kontextinformationen von dem Sicherheitsproxy an einen Schlüsselmanager auf. Hier verwaltet der Schlüsselmanager einen ersten privaten Schlüssel des Sicherheitsproxys. Die Aktionen weisen auch ein Empfangen einer ersten Handshake-Nachricht von dem Schlüsselmanager auf. Hier wird die erste Handshake-Nachricht mindestens auf der Grundlage der Kontextinformationen erzeugt und mit dem ersten privaten Schlüssel signiert. Die Aktionen weisen des Weiteren ein Senden der ersten Handshake-Nachricht an die Zielentität auf.
  • Die vorstehende Kurzdarstellung zielt nicht darauf ab, jede veranschaulichte Ausführungsform oder jede Ausführung der vorliegenden Offenbarung zu beschreiben.
  • Figurenliste
  • Die zu der vorliegenden Anmeldung gehörenden Zeichnungen sind in die Spezifikation aufgenommen und bilden einen Teil der Spezifikation. Sie veranschaulichen Ausführungsformen der vorliegenden Offenbarung und dienen zusammen mit der Beschreibung dazu, die Grundgedanken der Offenbarung zu erklären. Die Zeichnungen veranschaulichen lediglich bestimmte Ausführungsformen und stellen keine Einschränkung der Offenbarung dar. Merkmale und Vorteile von verschiedenen Ausführungsformen des beanspruchten Gegenstands werden im Verlauf der folgenden Ausführlichen Beschreibung und bei Bezugnahme auf die Zeichnungen ersichtlich, in denen gleiche Bezugszahlen gleiche Teile angeben und bei denen:
    • 1 einen Cloud-Computing-Knoten gemäß einer Ausführungsform der vorliegenden Erfindung darstellt.
    • 2 stellt eine Cloud-Computing-Umgebung gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 3 stellt Abstraktionsmodellschichten gemäß einer Ausführungsform der vorliegenden Erfindung dar.
    • 4 stellt eine Umgebung dar, in der Ausführungsformen der vorliegenden Offenbarung ausgeführt werden können.
    • 5 stellt ein Schaubild eines beispielhaften Prozesses zur Verwaltung von privaten Schlüsseln gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar.
    • 6 stellt ein Schaubild eines beispielhaften Prozesses zur Verwaltung von privaten Schlüsseln gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar.
    • 7 stellt ein Schaubild eines beispielhaften Prozesses zur Verwaltung von privaten Schlüsseln gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar.
    • 8 stellt einen Ablaufplan eines beispielhaften Verfahrens gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar.
    • 9 stellt einen Ablaufplan eines beispielhaften Verfahrens gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar.
    • 10 veranschaulicht ein Übersichtsblockschaubild eines beispielhaften Computersystems, das bei der Ausführung von Ausführungsformen der vorliegenden Offenbarung verwendet werden kann.
  • Während die Erfindung offen für verschiedene Modifikationen und alternative Formen ist, wurden Einzelheiten der Erfindung beispielhalber in den Zeichnungen gezeigt und werden ausführlich beschrieben. Es sollte jedoch klar sein, dass nicht beabsichtigt ist, die Erfindung auf die jeweiligen beschriebenen Ausführungsformen zu beschränken. Im Gegenteil ist beabsichtigt, alle Modifikationen, Äquivalente und Alternativen, die unter den Umfang der Erfindung fallen, abzudecken.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Einige Ausführungsformen werden unter Bezugnahme auf die beiliegenden Zeichnungen ausführlicher beschrieben, in denen die Ausführungsformen der vorliegenden Offenbarung veranschaulicht sind. Die vorliegende Offenbarung kann jedoch auf verschiedene Arten ausgeführt werden und sollte somit nicht als auf die hierin offenbarten Ausführungsformen beschränkt ausgelegt werden.
  • Es sei von vornherein klargestellt, dass das Umsetzen der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist, obwohl diese Offenbarung eine ausführliche Beschreibung von Cloud-Computing umfasst. Stattdessen können Ausführungsformen der vorliegenden Erfindung gemeinsam mit jeder beliebigen weiteren Art von jetzt bekannter oder später erfundener Datenverarbeitungsumgebung umgesetzt werden.
  • Cloud-Computing ist ein Servicebereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerken, Netzwerkbandbreite, Servern, Verarbeitung, Arbeitsspeichern, Speichern, Anwendungen, virtuellen Maschinen und Services), die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Service schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften umfassen, mindestens drei Dienstmodelle und mindestens vier Implementierungsmodelle.
  • Bei den Eigenschaften handelt es sich um die folgenden:
  • On-Demand Self-Service: Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher sorgen, ohne dass eine menschliche Interaktion mit dem Anbieter der Dienste erforderlich ist.
  • Broad Network Access: Es sind Funktionen über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, welche die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
  • Resource-Pooling: Die Datenverarbeitungsressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
  • Rapid Elasticity: Funktionen können für eine schnelle horizontale Skalierung (scale out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
  • Measured Service: Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Die Nutzung von Ressourcen kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz geschaffen wird.
  • Bei den Servicemodellen handelt es sich um die folgenden:
  • Software as a Service (SaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin-Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende E-Mail) von verschiedenen Client-Einheiten her zugänglich. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher bzw. sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten benutzerspezifischen Anwendungskonfigurationseinstellungen.
  • Platform as a Service (PaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Tools erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme bzw. Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen des Application Hosting Environment.
  • Infrastructure as a Service (laaS): Die dem Nutzer bereitgestellte Funktion besteht darin, das Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).
  • Bei den Einsatzmodellen handelt es sich um die folgenden:
  • Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
  • Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Angelegenheiten hat (z.B. Mission, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
  • Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und sie gehört einer Cloud-Dienste verkaufenden Organisation.
  • Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (privat, Benutzergemeinschaft oder öffentlich), die zwar einzelne Einheiten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden sind, die Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).
  • Eine Cloud-Computing-Umgebung ist dienstorientiert mit Fokus auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität. Im Herzen von Cloud-Computing liegt eine Infrastruktur, die ein Netzwerk aus zusammengeschalteten Knoten umfasst.
  • Unter Bezugnahme auf 1 ist eine schematische Darstellung eines Beispiels eines Cloud-Computing-Knotens gezeigt. Der Cloud-Computing-Knoten 10 stellt lediglich ein Beispiel eines geeigneten Cloud-Computing-Knotens dar und soll keine Einschränkung hinsichtlich des Nutzungsumfangs oder der Funktionalität von hierin beschriebenen Ausführungsformen der Erfindung bedeuten. Ungeachtet dessen kann der Cloud-Computing-Knoten 10 ausgeführt werden und/oder jedwede der vorstehend dargelegten Funktionalität durchführen.
  • In dem Cloud-Computing-Knoten 10 gibt es ein(en) Computersystem/Server 12 oder eine mobile elektronische Einheit wie beispielsweise eine Übertragungseinheit, die mit zahlreichen weiteren Universal- oder Spezial-Datenverarbeitungssystemumgebungen oder -konfigurationen betrieben werden kann. Zu Beispielen für hinlänglich bekannte Datenverarbeitungssysteme, -umgebungen und/oder -konfigurationen, die gegebenenfalls zur Verwendung mit dem Computersystem/Server 12 geeignet sind, gehören, ohne darauf beschränkt zu sein, Personal-Computer-Systeme, Server-Computersysteme, Thin Clients, Thick Clients, Handheld- oder Laptop-Einheiten, Mehrprozessorsysteme, auf einem Mikroprozessor beruhende Systeme, Set-Top-Boxen, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputersysteme, Mainframe-Computersysteme und verteilte Cloud-Computing-Umgebungen, die beliebige der vorstehenden Systeme oder Einheiten umfassen, und dergleichen.
  • Das Computersystem/der Server 12 kann in dem allgemeinen Kontext von durch ein Computersystem ausführbaren Anweisungen, wie beispielsweise Programmmodulen, die durch ein Computersystem ausgeführt werden, beschrieben werden. Im Allgemeinen können Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen und so weiter umfassen, die bestimmte Tasks durchführen oder bestimmte abstrakte Datentypen ausführen. Das Computersystem/der Server 12 kann in verteilten Cloud-Computing-Umgebungen in die Praxis umgesetzt werden, in denen Tasks durch ferne Verarbeitungseinheiten durchgeführt werden, die durch ein Übertragungsnetzwerk verbunden sind. In einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl in lokalen als auch in fernen Speichermedien eines Computersystems, zu denen auch Arbeitsspeichereinheiten gehören, befinden.
  • Wie in 1 gezeigt ist, ist das Computersystem/der Server 12 in dem Cloud-Computing-Knoten 10 in Form einer Universal-Datenverarbeitungseinheit gezeigt. Zu den Komponenten des Computersystems/Servers 12 können, ohne darauf beschränkt zu sein, ein Satz von einem oder mehreren Prozessoren oder Verarbeitungseinheiten 16, ein Systemspeicher 28 und ein Bus 18 gehören, der verschiedene Systemkomponenten, darunter den Systemspeicher 28, mit dem Prozessor 16 verbindet.
  • Der Bus 18 stellt eine oder mehrere von beliebigen Busstrukturen von mehreren Arten von Busstrukturen dar, darunter einen Speicherbus oder einen Speichercontroller, einen peripheren Bus, einen Accelerated Graphics Port und einen Prozessor- oder lokalen Bus, der beliebige einer Vielfalt an Busarchitekturen verwendet. Beispielhaft, und nicht als Einschränkung, gehören zu solchen Architekturen der Bus „Industry Standard Architecture (ISA)“, der Bus „Micro Channel Architecture (MCA)“, der Bus „Enhanced ISA (EISA)“, der lokale Bus „Video Electronics Standards Association (VESA)“ und der Bus „Peripheral Component Interconnect (PCI)“.
  • Das Computersystem/der Server 12 umfasst üblicherweise eine Vielfalt an durch ein Computersystem lesbaren Datenträgern. Bei diesen Datenträgern kann es sich um jedwede verfügbaren Datenträger handeln, auf die durch das Computersystem/den Server 12 zugegriffen werden kann, und zu ihnen gehören sowohl flüchtige und nicht flüchtige als auch austauschbare und nicht austauschbare Datenträger.
  • Der Systemspeicher 28 kann durch ein Computersystem lesbare Datenträger in Form von flüchtigem Speicher, wie beispielsweise einen Direktzugriffsspeicher (RAM) 30 und/oder einen Cache 32, umfassen. Das Computersystem/der Server 12 kann des Weiteren weitere auswechselbare/nicht auswechselbare, flüchtige/nicht flüchtige Speichermedien eines Computersystems umfassen. Lediglich als Beispiel kann das Speichersystem 34 für das Lesen von und das Schreiben auf einen nicht austauschbaren, nicht flüchtigen Magnetdatenträger (nicht gezeigt und üblicherweise als „Festplattenlaufwerk“ bezeichnet) bereitgestellt werden. Obgleich nicht gezeigt, können ein Magnetplattenlaufwerk für das Lesen von und das Schreiben auf eine austauschbare, nicht flüchtige Magnetplatte (z.B. eine „Diskette“) und ein optisches Plattenlaufwerk für das Lesen von oder das Schreiben auf eine austauschbare, nicht flüchtige optische Platte, wie beispielsweise ein CD-ROM, DVD-ROM oder andere optische Datenträger, bereitgestellt sein. In diesen Fällen kann jedes Laufwerk durch eine oder mehrere Datenträgerschnittstellen mit dem Bus 18 verbunden sein. Wie weiter dargestellt und nachstehend beschrieben wird, kann der Speicher 28 mindestens ein Programmprodukt umfassen, das über einen Satz (z.B. zumindest einen) von Programmmodulen verfügt, die so konfiguriert sind, dass sie die Funktionen von Ausführungsformen der Erfindung ausführen.
  • Ein Programm/Dienstprogramm 40, das über einen Satz (zumindest einen) von Programmmodulen 42 verfügt, kann beispielhaft, und nicht als Einschränkung, im Speicher 28 gespeichert sein, ebenso wie ein Betriebssystem, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten. Das Betriebssystem, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten oder eine Kombination daraus können jeweils eine Ausführung einer Netzwerkumgebung umfassen. Die Programmmodule 42 führen im Allgemeinen die Funktionen und/oder die Vorgehensweisen von Ausführungsformen der Erfindung aus, die hierin beschrieben sind.
  • Das Computersystem/der Server 12 kann auch mit einer oder mehreren externen Einheiten 14 wie beispielsweise einer Tastatur, einer Zeigereinheit, einem Bildschirm 24 usw.; mit einer oder mehreren Einheiten, die es einem Benutzer ermöglicht/ermöglichen, mit dem Computersystem/Server 12 zu interagieren; und/oder beliebigen Einheiten (z.B. Netzwerkkarte, Modem usw.), die dem Computersystem/Server 12 einen Datenaustausch mit einer oder mehreren anderen Datenverarbeitungseinheiten ermöglichen, Daten austauschen. Ein solcher Datenaustausch kann über Eingabe-/Ausgabe-(E/A-)Schnittstellen 22 erfolgen. Dennoch kann das Computersystem/der Server 12 mit einem oder mehreren Netzwerken wie beispielsweise einem lokalen Netz (LAN), einem allgemeinen Weitverkehrsnetz (WAN) und/oder einem öffentlichen Netz (z.B. dem Internet) über einen Netzwerkadapter 20 Daten austauschen. Wie dargestellt ist, tauscht der Netzwerkadapter 20 mit den anderen Komponenten des Computersystems/Servers 12 über den Bus 18 Daten aus. Es sollte klar sein, dass auch andere Hardware- und/oder SoftwareKomponenten in Verbindung mit dem Computersystem/Server 12 verwendet werden könnten, obgleich diese nicht gezeigt sind. Zu Beispielen gehören, ohne darauf beschränkt zu sein: Mikrocode, Einheitentreiber, redundante Verarbeitungseinheiten, externe Anordnungen von Plattenlaufwerken, RAID-Systeme, Bandlaufwerke sowie Speichersysteme zur Datenarchivierung usw.
  • Unter Bezugnahme auf 2 ist eine veranschaulichende Cloud-Computing-Umgebung 50 dargestellt. Wie gezeigt ist, umfasst die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 10, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie beispielsweise ein elektronischer Assistent (PDA, personal digital assistant) oder ein Mobiltelefon 54A, ein Desktop-Computer 54B, ein Laptop-Computer 54C und/oder ein Automobil-Computer-System 54N Daten austauschen können. Die Knoten 10 können miteinander Daten austauschen. Sie können physisch oder virtuell in ein oder mehrere Netzwerke wie private, Benutzergemeinschafts-, öffentliche oder hybride Clouds gruppiert werden (nicht gezeigt), wie vorstehend beschrieben wurde, oder in eine Kombination daraus. Dies ermöglicht es der Cloud-Computing-Umgebung 50, Infrastruktur, Plattformen und/oder Software als Dienste anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es sei darauf hingewiesen, dass die Arten der in 2 gezeigten Datenverarbeitungseinheiten 54A bis N lediglich veranschaulichend sein sollen und dass die Datenverarbeitungsknoten 10 und die Cloud-Computing-Umgebung 50 über eine beliebige Art Netzwerk und/oder über eine beliebige Art von über ein Netzwerk aufrufbarer Verbindung (z.B. unter Verwendung eines Web-Browsers) mit einer beliebigen Art von computergestützter Einheit Daten austauschen können.
  • Unter Bezugnahme auf 3 ist ein Satz von funktionalen Abstraktionsschichten gezeigt, die von der Cloud-Computing-Umgebung 50 (2) bereitgestellt werden. Es sollte von vornherein klar sein, dass die in 3 gezeigten Komponenten, Schichten und Funktionen lediglich veranschaulichend sein sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie dargestellt ist, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:
  • Eine Hardware- und Softwareschicht 60 umfasst Hardware- und Softwarekomponenten. Zu Beispielen für Hardwarekomponenten gehören: Mainframe-Computer 61; auf der RISC- (Reduced Instruction Set Computer) Architektur beruhende Server 62; Server 63; Blade-Server 64; Speichereinheiten 65; und Netzwerke sowie Netzwerkkomponenten 66. In einigen Ausführungsformen umfassen Softwarekomponenten eine Netzwerk-Anwendungsserver-Software 67 und eine Datenbanksoftware 68.
  • Eine Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Einheiten bereitgestellt werden können: virtuelle Server 71; virtueller Speicher 72; virtuelle Netzwerke 73, darunter virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme 74; und virtuelle Clients 75.
  • In einem Beispiel kann eine Verwaltungsschicht 80 die nachstehend beschriebenen Funktionen bereitstellen. Eine Ressourcen-Bereitstellung 81 stellt die dynamische Beschaffung von Datenverarbeitungsressourcen sowie anderen Ressourcen bereit, die zum Durchführen von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Ein Messen und eine Preisfindung 82 stellen die Kostenverfolgung beim Verwenden von Ressourcen innerhalb der Cloud-Computing-Umgebung sowie die Abrechnung oder Rechnungsstellung für den Verbrauch dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Anwendungssoftwarelizenzen umfassen. Eine Sicherheit stellt die Identitätsüberprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 83 stellt Nutzern und Systemadministratoren den Zugang zu der Cloud-Computing-Umgebung bereit. Eine Verwaltung des Dienstumfangs 84 stellt die Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, so dass die benötigten Dienstziele erreicht werden. Ein Planen und Erfüllen von Vereinbarungen zum Dienstumfang (SLA, Service Level Agreement) 85 stellt die Anordnung vorab und die Beschaffung von Cloud-Computing-Ressourcen, für die eine zukünftige Anforderung vorausgesehen wird, gemäß einem SLA bereit.
  • Eine Arbeitslastschicht 90 stellt Beispiele für die Funktionalität bereit, für welche die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 91; Software-Entwicklung und Lebenszyklusverwaltung 92; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 93; Datenanalytikverarbeitung 94; Transaktionsverarbeitung 95; und Verwaltung von privaten Schlüsseln 96.
  • In der Cloudumgebung wird Verkehr im Allgemeinen verschlüsselt. Jedoch führt dies zu deren eigenen Sicherheitsproblemen: Schädlicher Verkehr ist oftmals ebenfalls verschlüsselt und kann einen Server angreifen, ohne beobachtet zu werden. Ein Cloud-Sicherheitsproxy kann eingeführt werden, um eine solche Sicherheitsbedrohung zu verringern. Bei dem Cloud-Sicherheitsproxy kann es sich um ein containerisiertes Proxy-Produkt handeln, das sich zwischen dem Client und dem Server befindet. Der Cloud-Sicherheitsproxy kann verschlüsselten Verkehr beobachten und überwachen, um schädliches Verhalten und schädlichen Inhalt zu erkennen. Zu diesem Zweck und um für den Client transparent zu sein, muss ein öffentlicher Schlüssel des Cloud-Sicherheitsproxys gegebenenfalls für den Client vertrauenswürdig sein, und der Cloud-Sicherheitsproxy muss einen privaten Zuordnungsschlüssel verwenden, um sich selbst gegenüber dem Client zu authentifizieren.
  • Derweil kann der Cloud-Sicherheitsproxy in der Cloudumgebung durch eine oder mehrere Containerinstanzen ausgeführt werden. Jedoch kann ein Verwalten des privaten Schlüssels in den Containerinstanzen ein Risiko erhöhen, dass der private Schlüssel preisgegeben wird. Überdies kann ein Verteilen von privaten Schlüsseln an die Containerinstanzen verhältnismäßig komplex sein, da sich die Containerinstanzen in der Cloudumgebung häufig ändern können, um der sich ständig ändernden Arbeitslast Rechnung zu tragen.
  • Ausführungsformen der vorliegenden Offenbarung stellen eine Lösung für eine Verwaltung von privaten Schlüsseln bereit. Im Allgemeinen, gemäß Ausführungsformen der vorliegenden Offenbarung, verwaltet ein Schlüsselmanager anstelle eines Sicherheitsproxys einen privaten Schlüssel des Sicherheitsproxys und bearbeitet Handshake-Nachrichten, die den privaten Schlüssel erforderlich machen. Kontextinformationen eines Handshakes zwischen einer Quellenentität und einer Zielentität werden an dem Sicherheitsproxy erhalten und an den Schlüsselmanager gesendet. Eine Handshake-Nachricht wird mindestens auf der Grundlage der Kontextinformationen durch den Schlüsselmanager erzeugt und mit dem privaten Schlüssel des Sicherheitsproxys signiert. Die Handshake-Nachricht wird dann an den Sicherheitsproxy gesendet und durch den Sicherheitsproxy an die Zielentität weitergeleitet.
  • In den Ausführungsformen der vorliegenden Offenbarung wird ein zentralisiertes System mit erweiterter Sicherheit vorgeschlagen. Auf diese Weise braucht der Sicherheitsproxy den privaten Schlüssel nicht zu speichern, zu verwalten und zu schützen. Der private Schlüssel des Sicherheitsproxys kann zentralisiert aufbewahrt werden, ohne an Containerinstanzen verteilt zu werden. Dies kann ein Risiko, dass der private Schlüssel preisgegeben wird, vorteilhaft verringern. Mit der vorgeschlagenen Lösung kann eine sicherere Cloudumgebung erreicht werden. Überdies wird bei dem zentralisierten System keine individuelle Konfiguration für den privaten Schlüssel des Sicherheitsproxys benötigt und eine Änderung der Konfiguration des Sicherheitsproxys kann an dem Schlüsselmanager vorgenommen werden. Auf diese Weise kann der private Schlüssel des Sicherheitsproxys leichter aktualisiert und verwaltet werden.
  • In einigen Ausführungsformen können die Handshake-Nachricht betreffende Informationen im Voraus an dem Sicherheitsproxy und dem Schlüsselmanager vorbereitet werden. Protokollierte Kontextinformationen eines protokollierten Handshakes, an dem die Quellenentität beteiligt ist, können im Voraus erhalten werden. Sobald der Handshake durch die Zielentität eingeleitet wird, kann der Schlüsselmanager die Handshake-Nachricht erzeugen, ohne auf eine Antwort von der Quellenentität zu warten. In solchen Ausführungsformen kann die für den Handshake benötigte Zeit verringert und der Transaktionsfluss zwischen der Quellen- und der Zielentität somit verbessert werden. Auf diese Weise lässt sich ein effizienterer Handshake erreichen.
  • Selbst wenn der Sicherheitsproxy nicht in der Cloudumgebung eingesetzt wird, können die vorstehenden Vorteile der vorliegenden Offenbarung ebenfalls erzielt werden. Weitere Vorteile der vorliegenden Offenbarung werden unter Bezugnahme auf die beispielhaften Ausführungsformen und die nachfolgenden beigefügten Zeichnungen beschrieben.
  • 4 stellt eine Umgebung 400 dar, in der Ausführungsformen der vorliegenden Offenbarung ausgeführt werden können. Es sei von vornherein klargestellt, dass die Struktur und die Funktionalität der Umgebung 400 nur zum Zweck der Veranschaulichung beschrieben werden, ohne Einschränkungen hinsichtlich des Umfangs der vorliegenden Offenbarung anzudeuten. Im Allgemeinen weist die Umgebung 400 eine Zielentität 410, eine Quellenentität 420, einen Sicherheitsproxy 430 und einen Schlüsselmanager 440 auf.
  • Wie in 4 gezeigt ist, befindet sich der Sicherheitsproxy 430 zwischen der Zielentität 410 und der Quellenentität 420. Insbesondere kann der Sicherheitsproxy 430 als eine autorisierte Entität dienen, die eine erste sichere Verbindung zwischen der Zielentität 410 und dem Sicherheitsproxy 430 und eine zweite sichere Verbindung zwischen dem Sicherheitsproxy 430 und der Quellenentität 420 herstellt. Mit diesen beiden sicheren Verbindungen kann der Sicherheitsproxy 430 verschlüsselte Übertragungen von der Zielentität 410 über die erste sichere Verbindung empfangen. Wenn die verschlüsselten Übertragungen an die Quellenentität 420 geleitet werden, kann der Sicherheitsproxy 430 die Übertragungen an die Quellenentität 420 über die zweite sichere Verbindung weiterleiten. Ein umgekehrter Prozess kann durchgeführt werden, wenn verschlüsselte Übertragungen von der Quellenentität 420 über die zweite sichere Verbindung empfangen werden. Als Beispiel kann der Sicherheitsproxy 430 so konfiguriert sein, dass er eine Transport Layer Security (TLS) bereitstellt. In einem solchen Beispiel kann der Sicherheitsproxy 430 ein TLS-Proxy sein.
  • In einigen Ausführungsformen kann der Sicherheitsproxy 430 in einer Cloudumgebung ausgeführt werden. Zum Beispiel kann der Sicherheitsproxy 430 durch eine oder mehrere Containerinstanzen ausgeführt werden. In einigen Ausführungsformen kann der Sicherheitsproxy 430 in einer oder mehreren lokalen Einheiten ausgeführt werden.
  • Bei der Zielentität 410 und der Quellenentität 420 kann es sich um beliebige geeignete Entitäten handeln, die über den Sicherheitsproxy 430 miteinander Daten austauschen. In einigen Ausführungsformen kann die Zielentität 410 oder die Quellenentität 420 ein Client sein und die jeweils andere kann ein Server sein. Als Beispiel, ohne jedwede Einschränkung hinsichtlich des Umfangs der vorliegenden Offenbarung, kann es sich bei der Zielentität 410 um einen TLS-Client und bei der Quellenentität 420 um einen TLS-Server handeln.
  • Um miteinander Daten auszutauschen, zum Beispiel, um Anwendungsdaten auszutauschen, ist ein Handshake zwischen der Zielentität 410 und der Quellenentität 420 erforderlich. Aufgrund des Vorhandenseins des Sicherheitsproxys 430 kann der Handshake eine Handshake-Abfolge zwischen der Zielentität 410 und dem Sicherheitsproxy 430 sowie eine weitere Handshake-Abfolge zwischen der Quellenentität 420 und dem Sicherheitsproxy 430 aufweisen. Eine oder mehrere Handshake-Nachrichten, die zwischen der Zielentität 410, dem Sicherheitsproxy 430 und der Quellenentität 420 übertragen werden, müssen gegebenenfalls mit einem privaten Schlüssel eines Senders der Handshake-Nachrichten signiert werden. Zum Beispiel muss eine Handshake-Nachricht für eine Zertifikatsprüfung mit dem privaten Schlüssel des Senders signiert werden.
  • In der Verwendung hierin wird der Begriff „Quelle“ in Bezug auf einen Ursprung einer Nachricht (z.B. einer Handshake-Nachricht) verwendet, während der Begriff „Ziel“ in Bezug auf ein Ziel der Nachricht verwendet wird. Im Folgenden können die Zielentität 410 und die Quellenentität 420 zusammen als „Entitäten“ oder einzeln als „Entität“ bezeichnet werden.
  • Wie in 4 gezeigt ist, kann der Schlüsselmanager 440 mit dem Sicherheitsproxy 430 über eine sichere Verbindung Daten austauschen. Der Schlüsselmanager 440 ist so konfiguriert, dass er einen privaten Schlüssel 450 des Sicherheitsproxys 430 verwaltet und eine Nachricht bearbeitet, die anstelle des Sicherheitsproxys 430 den privaten Schlüssel 450 erforderlich macht. Der Schlüsselmanager 440 kann auf jede beliebige geeignete Weise ausgeführt sein. Zum Beispiel kann der Schlüsselmanager 440 durch eine Komponente in der Cloudumgebung ausgeführt sein. Alternativ kann der Schlüsselmanager 440 durch eine oder mehrere Einheiten, zum Beispiel einen Server, ausgeführt sein.
  • Der Schlüsselmanager 440 ist so konfiguriert, dass er Kontextinformationen des Handshakes zwischen der Quellenentität 420 und der Zielentität 410 von dem Sicherheitsproxy 430 empfängt und eine Handshake-Nachricht mindestens auf der Grundlage der Kontextinformationen und des privaten Schlüssels 450 erzeugt. In der Verwendung hierin bezieht sich der Begriff „Kontextinformationen“ des Handshakes auf mindestens einen Teil von Informationen, die während des Handshakes ausgetauscht wurden, zum Beispiel Nachrichten, die zwischen der Zielentität 410, dem Sicherheitsproxy 430 und der Quellenentität 420 übertragen wurden.
  • In einigen Ausführungsformen kann der Schlüsselmanager 440 protokollierte Kontextinformationen 460 eines protokollierten Handshakes speichern, an dem die Quellenentität 420 beteiligt ist. Insbesondere können die protokollierten Kontextinformationen auf die Quellenentität 420 bezogen sein. Der Schlüsselmanager 440 kann die Handshake-Nachricht des Weiteren auf der Grundlage der protokollierten Kontextinformationen erzeugen. Obgleich nicht gezeigt, kann der Sicherheitsproxy 430 in einigen Ausführungsformen auch die protokollierten Kontextinformationen 460 speichern.
  • Die Anzahl der in 4 gezeigten Elemente wird lediglich zum Zweck der Veranschaulichung angegeben; jede geeignete Anzahl von Elementen kann vorhanden sein. Zum Beispiel kann es mehr Entitäten geben, die durch den Sicherheitsproxy 430 bedient werden. Der Schlüsselmanager 440 kann private Schlüssel von mehr als einem Sicherheitsproxy verwalten.
  • 5 stellt ein Schaubild eines beispielhaften Prozesses 500 zur Verwaltung von privaten Schlüsseln gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar. Wie in 5 gezeigt ist, können an dem Prozess 500 eine Zielentität 511, ein Sicherheitsproxy 531, ein Schlüsselmanager 541 und eine Quellenentität 521 beteiligt sein. Diese Komponenten können der Zielentität 410, dem Sicherheitsproxy 430, dem Schlüsselmanager 440 bzw. der Quellenentität 420 entsprechen, die in 4 gezeigt sind.
  • Ein Handshake zwischen der Zielentität 511 und der Quellenentität 521 kann zur gegenseitigen Authentifizierung eingeleitet werden. Handshake-Nachrichten werden zwischen der Zielentität 511 und der Quellenentität 521 über den Sicherheitsproxy 531 übertragen. Eine Handshake-Nachricht (die auch als „erste Handshake-Nachricht“ bezeichnet wird), zum Beispiel eine Nachricht zur Zertifikatsprüfung, kann einen privaten Schlüssel (der auch als „erster privater Schlüssel“ bezeichnet wird) des Sicherheitsproxys 531 erforderlich machen.
  • Der Sicherheitsproxy 531 erhält 510 Kontextinformationen des Handshakes zwischen der Quellenentität 521 und der Zielentität 511 und sendet 515 die Kontextinformationen dann an den Schlüsselmanager 541. Die Kontextinformationen können einen Teil oder alle der Informationen aufweisen, die während des Handshakes ausgetauscht wurden. Zum Beispiel können die Kontextinformationen Nachrichten 505, 506 aufweisen, die zwischen der Zielentität 511, dem Sicherheitsproxy 531 und der Quellenentität 521 während des Handshakes übertragen wurden.
  • In einigen Ausführungsformen kann der Sicherheitsproxy 531 eine Handshake-Nachricht (die auch als „zweite Handshake-Nachricht“ bezeichnet wird) von der Quellenentität 521 als mindestens einen Teil der Kontextinformationen empfangen. Die zweite Handshake-Nachricht wird an die Zielentität 511 geleitet und mit einem privaten Schlüssel (der auch als „zweiter privater Schlüssel“ bezeichnet wird) der Quellenentität 521 signiert. Als Beispiel kann es sich bei der zweiten Handshake-Nachricht um eine Certificate-Verify-(CV-)Nachricht zur Prüfung eines Zertifikats handeln. Die CV-Nachricht kann eine Signatur der Quellenentität 521 aufweisen, die auf der Grundlage des privaten Schlüssels der Quellenentität 521 erzeugt wird.
  • Nach dem Empfangen der zweiten Handshake-Nachricht kann der Sicherheitsproxy 531 die zweite Handshake-Nachricht an den Schlüsselmanager 541 senden. Zudem kann der Sicherheitsproxy 531 in einigen Ausführungsformen des Weiteren einen zwischen der Zielentität 511 und dem Sicherheitsproxy 531 verwendeten Handshake-Schlüssel an den Schlüsselmanager 541 senden. Der Handshake-Schlüssel kann auf der Grundlage der Schlüsselaustauschinformationen von der Zielentität 511 festgelegt werden. Auf diese Weise kann der Schlüsselmanager 541 die erste Handshake-Nachricht mit dem Handshake-Schlüssel verschlüsseln. Ein Beispiel dieser Ausführungsformen wird nachstehend unter Bezugnahme auf 6 beschrieben.
  • In einigen Ausführungsformen kann der Sicherheitsproxy 531 eine „Hello“-Nachricht (die auch als „erste Hello-Nachricht“ bezeichnet wird) von der Zielentität 511 als mindestens einen Teil der Kontextinformationen empfangen. Die erste Hello-Nachricht kann an die Quellenentität 521 geleitet werden, um den Handshake einzuleiten. In dem Fall, in dem die Zielentität 511 ein Client ist, kann es sich bei der ersten Hello-Nachricht um eine Client-Hello-Nachricht handeln. Die erste Hello-Nachricht kann Schlüsselaustauschinformationen aufweisen, um die Handshake-Abfolge zwischen der Zielentität 511 und dem Sicherheitsproxy 531 zu verschlüsseln. Zum Beispiel kann die erste Hello-Nachricht mindestens einen Eintrag für eine gemeinsame Nutzung des Schlüssels aufweisen, der Parameter für einen Schlüsselaustausch mit dem Sicherheitsproxy 531 angibt.
  • Nach dem Empfangen der ersten Hello-Nachricht von der Zielentität 511 kann der Sicherheitsproxy 531 die erste Hello-Nachricht an den Schlüsselmanager 541 senden. Ferner hat der Sicherheitsproxy 531 in einigen Ausführungsformen einige der Informationen, die erforderlich sind, um die erste Handshake-Nachricht zu erzeugen, gegebenenfalls im Voraus erzeugt. Der Sicherheitsproxy 531 kann protokollierte Kontextinformationen (wie zum Beispiel protokollierte Kontextinformationen 460, die in 4 dargestellt sind) eines protokollierten Handshakes, an dem die Quellenentität 521 beteiligt ist, erhalten, bevor er die erste Hello-Nachricht empfängt. Die protokollierten Kontextinformationen können eine Hello-Nachricht von der Quellenentität 521, ein Zertifikat der Quellenentität 521, eine beliebige zugehörige Handshake-Nachricht von der Quellenentität 521 aufweisen.
  • Die protokollierten Kontextinformationen können während eines beliebigen geeigneten protokollierten Handshakes erhalten werden, an dem die Quellenentität 521 beteiligt ist. Als Beispiel können die protokollierten Kontextinformationen erhalten werden, wenn der Sicherheitsproxy 531 den Handshake, an dem die Quellenentität 521 beteiligt ist, erstmalig bedient. Als ein weiteres Beispiel können die protokollierten Kontextinformationen während des letzten Handshakes, an dem die Quellenentität 521 beteiligt ist, erhalten werden.
  • In einigen Ausführungsformen können die protokollierten Kontextinformationen an den Schlüsselmanager 541 gesendet werden, sobald die protokollierten Kontextinformationen erhalten werden. In einigen Ausführungsformen können die protokollierten Kontextinformationen an den Schlüsselmanager 541 zusammen mit der ersten Hello-Nachricht gesendet werden. Ein Beispiel dieser Ausführungsformen wird nachstehend unter Bezugnahme auf 7 beschrieben.
  • Nach dem Empfangen 515 der Kontextinformationen von dem Sicherheitsproxy 531 erzeugt 520 der Schlüsselmanager 541 die erste Handshake-Nachricht mindestens auf der Grundlage der Kontextinformationen. Die erste Handshake-Nachricht wird mit einem ersten privaten Schlüssel (nicht gezeigt) des Sicherheitsproxys 531 signiert. Der private Schlüssel kann zum Beispiel dem privaten Schlüssel 450 entsprechen, der in 4 dargestellt ist. Zum Beispiel kann der Schlüsselmanager 541 eine Signatur des Sicherheitsproxys 531 auf der Grundlage des ersten privaten Schlüssels erzeugen und die Signatur in die erste Handshake-Nachricht aufnehmen.
  • In den vorstehenden Ausführungsformen, bei denen die zweite Handshake-Nachricht von der Quellenentität 521 als die Kontextinformationen empfangen werden, kann der Schlüsselmanager 541 die erste Handshake-Nachricht auf der Grundlage der zweiten Handshake-Nachricht und des ersten privaten Schlüssels erzeugen 520. Zum Beispiel kann der Schlüsselmanager 541 die Signatur der Quellenentität 521 in der zweiten Handshake-Nachricht durch die Signatur des Sicherheitsproxys 531 ersetzen.
  • Ferner kann der Schlüsselmanager 541, wenn der zwischen der Zielentität 511 und dem Sicherheitsproxy 531 verwendete Handshake-Schlüssel an den Schlüsselmanager 541 gesendet wird, die erste Handshake-Nachricht mit dem Handshake-Schlüssel verschlüsseln.
  • In den vorstehenden Ausführungsformen, bei denen die erste Hello-Nachricht von der Zielentität 511 als die Kontextinformationen empfangen werden 515, kann der Schlüsselmanager 541 die erste Handshake-Nachricht auf der Grundlage der ersten Hello-Nachricht und der protokollierten Kontextinformationen erzeugen 520. Der Schlüsselmanager 541 kann die Signatur des Sicherheitsproxys 531 auf der Grundlage des ersten privaten Schlüssels erzeugen und die Signatur in die erste Handshake-Nachricht aufnehmen. In diesen Ausführungsformen kann die erste Hello-Nachricht die Zielentität 511 betreffende Informationen bereitstellen, während die protokollierten Kontextinformationen die Quellenentität 521 betreffende Informationen bereitstellen können.
  • Ferner kann der Schlüsselmanager 541, wenn ein Satz von Parametern zur Festlegung des zwischen der Zielentität 511 und dem Sicherheitsproxy 531 verwendeten Handshake-Schlüssels von dem Sicherheitsproxy 531 an den Schlüsselmanager 541 gesendet wird, den Handshake-Schlüssel auf der Grundlage des Satzes von Parametern und der ersten Hello-Nachricht festlegen. Zum Beispiel kann der Satz von Parametern einen durch den Sicherheitsproxy 531 festgelegten Eintrag für eine gemeinsame Nutzung des Schlüssels aufweisen, und die erste Hello-Nachricht kann einen weiteren durch die Zielentität 511 festgelegten Eintrag für eine gemeinsame Nutzung des Schlüssels aufweisen. Der Handshake-Schlüssel kann auf der Grundlage dieser Einträge für eine gemeinsame Nutzung des Schlüssels festgelegt werden. Dann kann der Schlüsselmanager 541 die erste Handshake-Nachricht mit dem Handshake-Schlüssel verschlüsseln.
  • Nach dem Erzeugen 520 der ersten Handshake-Nachricht sendet 525 der Schlüsselmanager 541 die erste Handshake-Nachricht an den Sicherheitsproxy 531. Dann sendet 530 der Sicherheitsproxy 531 die erste Handshake-Nachricht an die Zielentität 511. Wenn die erste von dem Schlüsselmanager 541 empfangene Handshake-Nachricht mit dem Handshake-Schlüssel verschlüsselt wurde, kann der Sicherheitsproxy 531 die erste Handshake-Nachricht direkt an die Zielentität 511 weiterleiten 530. Wenn die von dem Schlüsselmanager 541 empfangene erste Handshake-Nachricht nicht mit dem Handshake-Schlüssel verschlüsselt wurde, kann der Sicherheitsproxy 531 die erste Handshake-Nachricht zuerst mit dem Handshake-Schlüssel verschlüsseln und die verschlüsselte erste Handshake-Nachricht an die Zielentität 511 senden 530.
  • Wie in 5 gezeigt ist, wird der Handshake zwischen der Quellenentität 521 und der Zielentität 511 mit nachfolgenden Prozeduren fortgesetzt. Zum Beispiel kann die Handshake-Abfolge zwischen der Zielentität 511 und dem Sicherheitsproxy 531 durchgeführt werden 535. Die Handshake-Abfolge zwischen der Quellenentität 521 und dem Sicherheitsproxy 531 kann durchgeführt werden 540.
  • In den Ausführungsformen der vorliegenden Offenbarung braucht der Sicherheitsproxy den privaten Schlüssel nicht zu speichern, zu verwalten und zu schützen. Der private Schlüssel des Sicherheitsproxys kann zentralisiert aufbewahrt werden, ohne an Containerinstanzen verteilt zu werden. Das Risiko, den privaten Schlüssel preiszugeben, kann somit verringert und sogar vermieden werden. Daher wird eine sicherere Cloudumgebung erreicht. Überdies kann bei dem zentralisierten System eine Aktualisierung und Verwaltung des Sicherheitsproxys an dem Schlüsselmanager vorgenommen werden. Auf diese Weise kann der private Schlüssel des Sicherheitsproxys leichter aktualisiert und verwaltet werden.
  • Wie vorstehend erwähnt wurde, kann die zweite Handshake-Nachricht von der Quellenentität 521 in einigen Ausführungsformen als die Kontextinformationen verwendet werden. Nun wird auf 6 Bezug genommen. 6 stellt ein Schaubild eines beispielhaften Prozesses 600 zur Verwaltung von privaten Schlüsseln gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar. Der Prozess 600 kann als eine mögliche Ausführung des Prozesses 500 betrachtet werden. Wie in 6 gezeigt ist, können an dem Prozess 600 eine Zielentität 611, ein Sicherheitsproxy 631, ein Schlüsselmanager 641 und eine Quellenentität 621 beteiligt sein. Diese Komponenten können der Zielentität 410, dem Sicherheitsproxy 430, dem Schlüsselmanager 440 bzw. der Quellenentität 420 entsprechen, die in 4 gezeigt sind. Lediglich zum Zweck der Erläuterung, ohne jedwede Einschränkung hinsichtlich des Umfangs der vorliegenden Offenbarung, ist die Quellenentität 621 in dem Prozess 600 ein Server, die Zielentität 611 ist ein Client und die erste und die zweite Handshake-Nachricht sind CV-Nachrichten.
  • Wie in 6 gezeigt ist, kann die Zielentität 611 eine Client-Hello-Nachricht (die auch als „erste Client-Hello-Nachricht“ bezeichnet wird) an den Sicherheitsproxy 631 senden 605, um den Handshake zwischen der Zielentität 611 und der Quellenentität 621 einzuleiten. Die erste Client-Hello-Nachricht kann mindestens einen Eintrag für eine gemeinsame Nutzung des Schlüssels (der auch als „erster Eintrag für eine gemeinsame Nutzung des Schlüssels“ bezeichnet wird) aufweisen, der Parameter für einen Schlüsselaustausch mit dem Sicherheitsproxy 631 angibt. Die erste Client-Hello-Nachricht kann des Weiteren weitere Schlüsselaustauschinformationen aufweisen, zum Beispiel eine Protokollversion, Verschlüsselungsalgorithmen.
  • Der Sicherheitsproxy 631 kann einen weiteren Eintrag für eine gemeinsame Nutzung des Schlüssels (der auch als „zweiter Eintrag für eine gemeinsame Nutzung des Schlüssels“ bezeichnet wird) festlegen 610, der Parameter für einen Schlüsselaustausch mit der Quellenentität 621 angibt. Der Sicherheitsproxy 631 kann eine aktualisierte Client-Hello-Nachricht (die auch als „zweite Client-Hello-Nachricht“ bezeichnet wird) erzeugen, indem er den ersten Eintrag für eine gemeinsame Nutzung des Schlüssels durch den zweiten Eintrag für eine gemeinsame Nutzung des Schlüssels ersetzt und die zweite Client-Hello-Nachricht dann an die Quellenentität 621 sendet 615.
  • Nach dem Empfangen der zweiten Client-Hello-Nachricht kann die Quellenentität 621 als Antwort eine Server-Hello-Nachricht (die auch als „erste Server-Hello-Nachricht“ bezeichnet wird) an den Sicherheitsproxy 631 senden 620. Die erste Server-Hello-Nachricht kann mindestens einen Eintrag für eine gemeinsame Nutzung des Schlüssels (der auch als „dritter Eintrag für eine gemeinsame Nutzung des Schlüssels“ bezeichnet wird) aufweisen, der Parameter für einen Schlüsselaustausch mit dem Sicherheitsproxy 631 angibt.
  • Der Sicherheitsproxy 631 kann einen weiteren Eintrag für eine gemeinsame Nutzung des Schlüssels (der auch als „vierter Eintrag für eine gemeinsame Nutzung des Schlüssels“ bezeichnet wird) festlegen 625, der Parameter für einen Schlüsselaustausch mit der Zielentität 611 angibt. Der Sicherheitsproxy 631 kann einen zwischen der Zielentität 611 und dem Sicherheitsproxy 631 verwendeten ersten Handshake-Schlüssel auf der Grundlage des ersten und des vierten Eintrags für eine gemeinsame Nutzung des Schlüssels sowie einen zwischen der Quellenentität 621 und dem Sicherheitsproxy 631 verwenden zweiten Handshake-Schlüssel auf der Grundlage des zweiten und des dritten Eintrags für eine gemeinsame Nutzung des Schlüssels festlegen 630. Der Sicherheitsproxy 631 kann eine weitere Server-Hello-Nachricht (die als „zweite Server-Hello-Nachricht“ bezeichnet wird) an die Zielentität 611 senden 635. Die zweite Hello-Nachricht kann mindestens den vierten Eintrag für eine gemeinsame Nutzung des Schlüssels aufweisen.
  • Nachdem die erste Server-Hello-Nachricht an den Sicherheitsproxy 631 gesendet wurde 620, kann die Quellenentität 621 ein Zertifikat der Quellenentität 621, bei dem es sich in diesem Beispiel um ein Serverzertifikat handelt, an den Sicherheitsproxy 631 senden 640. Dann kann der Sicherheitsproxy 631 das Serverzertifikat an die Zielentität 611 weiterleiten 645.
  • Die Quellenentität 621 kann des Weiteren eine Nachricht (die auch als eine „ursprüngliche CV-Nachricht“ bezeichnet wird) senden 650, um dem Sicherheitsproxy 631 das Serverzertifikat zu bestätigen. Der Sicherheitsproxy 631 kann mindestens die ursprüngliche CV-Nachricht als die Kontextinformationen an den Schlüsselmanager 641 senden 655. In einigen Ausführungsformen kann der Sicherheitsproxy 631 des Weiteren den zwischen der Zielentität 611 und dem Sicherheitsproxy 631 verwendeten ersten Handshake-Schlüssel an den Schlüsselmanager 641 senden. Der Sicherheitsproxy 631 kann weitere zugehörige Kontextinformationen an den Schlüsselmanager 641 senden.
  • Der Schlüsselmanager 641 kann dann eine neue CV-Nachricht auf der Grundlage der ursprünglichen CV-Nachricht und eines privaten Schlüssels (nicht gezeigt) erzeugen 660. Der private Schlüssel kann zum Beispiel dem privaten Schlüssel 450 entsprechen, der in 4 dargestellt ist. Zum Beispiel kann die neue CV-Nachricht eine auf der Grundlage des privaten Schlüssels erzeugte Signatur aufweisen. Wenn der erste Handshake-Schlüssel ebenfalls an den Schlüsselmanager 641 gesendet wird, kann der Schlüsselmanager 641 die neue CV-Nachricht mit dem privaten Schlüssel verschlüsseln.
  • Der Schlüsselmanager 641 kann die neue CV-Nachricht dann an den Sicherheitsproxy 631 senden 665. Der Sicherheitsproxy 631 kann die neue CV-Nachricht an die Zielentität 611 weiterleiten 670. Wie in 6 gezeigt ist, wird der Handshake zwischen der Quellenentität 621 und der Zielentität 611 mit nachfolgenden Prozeduren fortgesetzt. Zum Beispiel kann die Handshake-Abfolge zwischen der Zielentität 611 und dem Sicherheitsproxy 631 durchgeführt werden 675. Die Handshake-Abfolge zwischen der Quellenentität 621 und dem Sicherheitsproxy 631 kann durchgeführt werden 680.
  • Es wurde erkannt, dass die Quellenentität und die Zielentität, zum Beispiel ein TLS-Server und ein TLS-Client, im Grunde unverändert sein können, und somit sind die einzigen Unterschiede zwischen Handshakes Parameter für einen Schlüsselaustausch, zum Beispiel Einträge für eine gemeinsame Nutzung des Schlüssels. Daher können in einigen Ausführungsformen einige der Informationen, die erforderlich sind, um die erste Handshake-Nachricht zu erzeugen, im Voraus vorbereitet werden.
  • 7 stellt ein Schaubild eines beispielhaften Prozesses 700 zur Verwaltung von privaten Schlüsseln gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar. Der Prozess 700 kann als eine weitere mögliche Ausführung des Prozesses 500 betrachtet werden. Wie in 7 gezeigt ist, können an dem Prozess 700 eine Zielentität 711, ein Sicherheitsproxy 731, ein Schlüsselmanager 741 und eine Quellenentität 721 beteiligt sein. Diese Komponenten können der Zielentität 410, dem Sicherheitsproxy 430, dem Schlüsselmanager 440 bzw. der Quellenentität 420 entsprechen, die in 4 gezeigt sind. Lediglich zum Zweck der Erläuterung, ohne jedwede Einschränkung des Umfangs, kann die Quellenentität 721 in dem Prozess 700 ein Server, die Zielentität 711 kann ein Client und die erste und die zweite Handshake-Nachricht können CV-Nachrichten sein.
  • Wie in 7 gezeigt ist, kann der Sicherheitsproxy 731 protokollierte Kontextinformationen (wie zum Beispiel protokollierte Kontextinformationen 460, die in 4 dargestellt sind) eines protokollierten Handshakes, an dem die Quellenentität 721 beteiligt ist, erhalten 705. In diesem Beispiel können die protokollierten Kontextinformationen eine Server-Hello-Nachricht (die auch als „vorherige Server-Hello-Nachricht“ bezeichnet wird) von der Quellenentität 721 und ein Serverzertifikat (das auch als „vorheriges Serverzertifikat“ bezeichnet wird) der Quellenentität 721 aufweisen. Zum Beispiel kann der Sicherheitsproxy 731 die vorherige Server-Hello-Nachricht und das vorherige Serverzertifikat von der Quellenentität 721 empfangen, wenn der Sicherheitsproxy 731 einen Handshake, an dem die Quellenentität 721 beteiligt ist, erstmalig bedient, oder während des letzten Handshakes, an dem die Quellenentität 721 beteiligt ist.
  • Der Sicherheitsproxy 731 kann die protokollierten Kontextinformationen an den Schlüsselmanager 741 senden 710. Der Schlüsselmanager 741 kann die protokollierten Kontextinformationen zum Beispiel in einem Cache oder in einer beliebigen geeigneten Speichereinheit speichern 715.
  • In einigen Ausführungsformen kann der Sicherheitsproxy 731 Einträge für eine gemeinsame Nutzung des Schlüssels, die Parameter für einen Schlüsselaustausch mit der Quellenentität 721 und der Zielentität 711 angeben, im Voraus festlegen. Zum Beispiel kann ein fünfter Eintrag für eine gemeinsame Nutzung des Schlüssels, der Parameter für einen Schlüsselaustausch mit der Quellenentität 721 angibt, und ein sechster Eintrag für eine gemeinsame Nutzung des Schlüssels, der Parameter für einen Schlüsselaustausch mit der Zielentität 711 angibt, durch den Sicherheitsproxy 731 im Voraus vorbereitet werden. Zudem kann der Sicherheitsproxy 731 die vorbereiteten Einträge für eine gemeinsame Nutzung des Schlüssels an den Schlüsselmanager 741 senden.
  • Somit sind der Sicherheitsproxy 731 und der Schlüsselmanager 741 gegebenenfalls auf einen Handshake zwischen der Zielentität 711 und der Quellenentität 721 vorbereitet. Wie in 7 gezeigt ist, kann die Zielentität 711 eine Client-Hello-Nachricht (die auch als eine „ursprüngliche Client-Hello-Nachricht“ bezeichnet wird) an den Sicherheitsproxy 731 senden 720, um den Handshake zwischen der Zielentität 711 und der Quellenentität 721 einzuleiten. Die ursprüngliche Client-Hello-Nachricht kann mindestens einen siebten Eintrag für eine gemeinsame Nutzung des Schlüssels aufweisen, der Parameter für einen Schlüsselaustausch mit dem Sicherheitsproxy 731 angibt.
  • Nach dem Empfangen 720 der ursprünglichen Client-Hello-Nachricht von der Zielentität 711 können zwei Unterprozesse 701 und 702 durchgeführt werden. Zwar sind die Unterprozesse 701 und 702 in 7 in Folge dargestellt, doch dient dies lediglich der Vereinfachung der Darstellung; 701 und 702 können parallel durchgeführt werden. In dem Unterprozess 701 kann der Sicherheitsproxy 731 die ursprüngliche Client-Hello-Nachricht direkt an den Schlüsselmanager 741 senden 725. Der Schlüsselmanager 741 kann eine mit einem privaten Schlüssel (nicht gezeigt) signierte erste CV-Nachricht erzeugen 730. Der private Schlüssel kann zum Beispiel dem privaten Schlüssel 450 entsprechen, der in 4 dargestellt ist. Zum Beispiel kann die erste CV-Nachricht auf der Grundlage der ursprünglichen Client-Hello-Nachricht, der vorherigen Server-Hello-Nachricht und des vorherigen Serverzertifikats erzeugt werden. Die erste CV-Nachricht kann eine auf der Grundlage des ersten privaten Schlüssels erzeugte Signatur des Sicherheitsproxys 731 aufweisen.
  • In einigen Ausführungsformen kann der Schlüsselmanager 741, wenn der sechste Eintrag für eine gemeinsame Nutzung des Schlüssels, der Parameter für einen Schlüsselaustausch mit der Zielentität 711 angibt, an den Schlüsselmanager 741 gesendet wird, einen zwischen der Zielentität 711 und dem Sicherheitsproxy 731 verwendeten Handshake-Schlüssel (der auch als „dritter Handshake-Schlüssel“ bezeichnet wird) auf der Grundlage des sechsten Eintrags für eine gemeinsame Nutzung des Schlüssels und des siebten Eintrags für eine gemeinsame Nutzung des Schlüssels in der ursprünglichen Client-Hello-Nachricht festlegen. Der Schlüsselmanager 741 kann die erste CV-Nachricht mit dem dritten Handshake-Schlüssel verschlüsseln. Als Nächstes kann der Schlüsselmanager 741 die erste CV-Nachricht an den Sicherheitsproxy 731 senden 735.
  • Wie in 7 gezeigt ist, kann der Sicherheitsproxy 731 nach dem Empfangen 720 der ursprünglichen Client-Hello-Nachricht von der Zielentität 711 den dritten Handshake-Schlüssel auf der Grundlage des sechsten Eintrags für eine gemeinsame Nutzung des Schlüssels und des siebten Eintrags für eine gemeinsame Nutzung des Schlüssels in der ursprünglichen Client-Hello-Nachricht festlegen 740. In einigen Ausführungsformen kann der Sicherheitsproxy 731 als Antwort auf die ursprüngliche Client-Hello-Nachricht eine Server-Hello-Nachricht (die als „eine zweite Hello-Nachricht“ bezeichnet werden kann) erzeugen. Diese Server-Hello-Nachricht kann auf der Grundlage der vorherigen Server-Hello-Nachricht erzeugt werden und den sechsten Eintrag für eine gemeinsame Nutzung des Schlüssels aufweisen, der im Voraus vorbereitet wurde. Dann kann der Sicherheitsproxy 731 diese Server-Hello-Nachricht an die Zielentität 711 senden 745. Der Sicherheitsproxy 731 kann die erste CV-Nachricht und das vorherige Serverzertifikat auch an die Zielentität 711 senden 750.
  • Der Unterprozess 702 wird nun beschrieben. Nach dem Empfangen 720 der ursprünglichen Client-Hello-Nachricht von der Zielentität 711 kann der Sicherheitsproxy 731 eine neue Client-Hello-Nachricht auf der Grundlage der ursprünglichen Client-Hello-Nachricht und des fünften Eintrags für eine gemeinsame Nutzung des Schlüssels erzeugen, der im Voraus erzeugt wird. Die neue Client-Hello-Nachricht kann erzeugt werden, indem der siebte Eintrag für eine gemeinsame Nutzung des Schlüssels in der ursprünglichen Client-Hello-Nachricht durch den fünften Eintrag für eine gemeinsame Nutzung des Schlüssels ersetzt wird. Dann kann der Sicherheitsproxy 731 die neue Client-Hello-Nachricht an die Quellenentität 721 senden 755.
  • Die Quellenentität 721 kann als Antwort eine Server-Hello-Nachricht an den Sicherheitsproxy 731 senden 760. Diese Server-Hello-Nachricht kann einen achten Eintrag für eine gemeinsame Nutzung des Schlüssels aufweisen, der Parameter für einen Schlüsselaustausch mit dem Sicherheitsproxy 731 angibt. Der Sicherheitsproxy 731 kann einen zwischen der Quellenentität 721 und dem Sicherheitsproxy 731 verwendeten Handshake-Schlüssel auf der Grundlage des fünften Eintrags für eine gemeinsame Nutzung des Schlüssels und des achten Eintrags für eine gemeinsame Nutzung des Schlüssels festlegen 765. Daraufhin kann die Quellenentität 721 an den Sicherheitsproxy 731 ein neues Serverzertifikat senden 770 und eine neue CV-Nachricht senden 775. In einigen Ausführungsformen können diese Server-Hello-Nachricht und das neue Serverzertifikat zur Aktualisierung der protokollierten Kontextinformationen verwendet werden. Zum Beispiel kann das neue Serverzertifikat das vorherige Serverzertifikat ersetzen. Somit kann der Unterprozess 702 als abgeschlossen betrachtet werden.
  • Wie in 7 gezeigt ist, wird der Handshake zwischen der Quellenentität 721 und der Zielentität 711 mit nachfolgenden Prozeduren fortgesetzt, nachdem beide Unterprozesse 701 und 702 abgeschlossen sind. Zum Beispiel kann die Handshake-Abfolge zwischen der Zielentität 711 und dem Sicherheitsproxy 731 durchgeführt werden 780. Die Handshake-Abfolge zwischen der Quellenentität 721 und dem Sicherheitsproxy 731 kann durchgeführt werden 785.
  • In solchen Ausführungsformen kann eine Handshake-Abfolge, wie sie im Unterprozess 701 zwischen der Zielentität 711 und dem Sicherheitsproxy 731 gezeigt ist, mit Hilfe der vorherigen Server-Hello-Nachricht und dem vorherigen Serverzertifikat durchgeführt werden. Der Sicherheitsproxy 731 muss gegebenenfalls nicht auf die neue Server-Hello-Nachricht und die neue CV-Nachricht von der Quellenentität 721 warten. Auf diese Weise kann die für den Handshake benötigte Zeit verringert und die Effizienz des Handshakes verbessert werden.
  • 8 stellt einen Ablaufplan eines beispielhaften Verfahrens 800 gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar. Zum Beispiel kann das Verfahren 800 an dem Sicherheitsproxy 430 ausgeführt werden, der in 4 gezeigt ist. Es sei von vornherein klargestellt, dass das Verfahren 800 auch zusätzliche Blöcke (nicht gezeigt) umfassen und/oder die veranschaulichten Blöcke weglassen kann. Der hierin beschriebene Umfang der vorliegenden Offenbarung ist in dieser Hinsicht nicht beschränkt.
  • Am Block 810 erhält der Sicherheitsproxy 430 Kontextinformationen eines Handshakes zwischen einer Quellenentität und einer Zielentität. Am Block 820 sendet der Sicherheitsproxy die Kontextinformationen an einen Schlüsselmanager. Der Schlüsselmanager verwaltet einen ersten privaten Schlüssel des Sicherheitsproxys. Am Block 830 empfängt der Sicherheitsproxy eine erste Handshake-Nachricht von dem Schlüsselmanager. Die erste Handshake-Nachricht wird mindestens auf der Grundlage der Kontextinformationen erzeugt und mit dem ersten privaten Schlüssel signiert. Am Block 840 sendet der Sicherheitsproxy 430 die erste Handshake-Nachricht an die Zielentität.
  • In einigen Ausführungsformen kann der Sicherheitsproxy eine zweite Handshake-Nachricht von der Quellenentität als mindestens einen Teil der Kontextinformationen empfangen. Die zweite Handshake-Nachricht kann an die Zielentität geleitet und mit einem zweiten privaten Schlüssel der Quellenentität signiert werden. Zum Beispiel kann eine CV-Nachricht von der Quellenentität als mindestens ein Teil der Kontextinformationen empfangen werden. In einigen Ausführungsformen kann der Sicherheitsproxy des Weiteren einen zwischen dem Sicherheitsproxy und der Zielentität verwendeten Handshake-Schlüssel an den Schlüsselmanager senden. Die erste Handshake-Nachricht kann mit dem Handshake-Schlüssel verschlüsselt werden.
  • In einigen Ausführungsformen kann der Sicherheitsproxy eine erste Hello-Nachricht von der Zielentität als mindestens einen Teil der Kontextinformationen empfangen. Die erste Hello-Nachricht wird an die Quellenentität geleitet, um den Handshake einzuleiten. In einigen Ausführungsformen kann der Sicherheitsproxy des Weiteren protokollierte Kontextinformationen eines protokollierten Handshakes erhalten, an dem die Quellenentität beteiligt ist, und die protokollierten Kontextinformationen an den Schlüsselmanager senden. Zum Beispiel können die protokollierten Kontextinformationen ein Server-Hello und ein Serverzertifikat von der Quellenentität aufweisen. In diesen Ausführungsformen kann die erste Handshake-Nachricht auf der Grundlage der protokollierten Kontextinformationen und der ersten Hello-Nachricht erzeugt werden.
  • In einigen Ausführungsformen kann der Sicherheitsproxy des Weiteren eine zweite Hello-Nachricht als Antwort auf die erste Hello-Nachricht auf der Grundlage der protokollierten Kontextinformationen festlegen. Der Sicherheitsproxy kann die zweite Hello-Nachricht an die Zielentität senden.
  • In einigen Ausführungsformen kann der Sicherheitsproxy des Weiteren einen Satz von Parametern an den Schlüsselmanager senden, um einen zwischen dem Sicherheitsproxy und der Zielentität verwendeten Handshake-Schlüssel festzulegen. In diesen Ausführungsformen kann die erste Handshake-Nachricht mit dem Handshake-Schlüssel verschlüsselt werden, der auf der Grundlage des Satzes von Parametern und der ersten Hello-Nachricht festgelegt wird.
  • 9 stellt einen Ablaufplan eines beispielhaften Verfahrens 900 gemäß einigen Ausführungsformen der vorliegenden Offenbarung dar. Zum Beispiel kann das Verfahren 900 an einem Schlüsselmanager ausgeführt werden, wie beispielsweise dem in 4 gezeigten Schlüsselmanager 440. Es sei von vornherein klargestellt, dass das Verfahren 900 auch zusätzliche Blöcke (nicht gezeigt) umfassen und/oder die veranschaulichten Blöcke weglassen kann. Der hierin beschriebene Umfang der vorliegenden Offenbarung ist in dieser Hinsicht nicht beschränkt.
  • Am Block 910 empfängt der Schlüsselmanager Kontextinformationen eines Handshakes zwischen einer Quellenentität und einer Zielentität von einem Sicherheitsproxy. Am Block 920 erzeugt der Schlüsselmanager mindestens auf der Grundlage der Kontextinformationen eine an die Zielentität geleitete erste Handshake-Nachricht. Die erste Handshake-Nachricht wird mit einem durch den Schlüsselmanager verwalteten ersten privaten Schlüssel des Sicherheitsproxys signiert. Am Block 930 sendet der Schlüsselmanager die erste Handshake-Nachricht an den Sicherheitsproxy.
  • In einigen Ausführungsformen kann der Schlüsselmanager eine zweite Handshake-Nachricht von dem Sicherheitsproxy als mindestens einen Teil der Kontextinformationen empfangen. Die zweite Handshake-Nachricht kann an die Zielentität geleitet und mit einem zweiten privaten Schlüssel der Quellenentität signiert werden. Zum Beispiel kann eine CV-Nachricht als mindestens ein Teil der Kontextinformationen empfangen werden. In einigen Ausführungsformen kann der Schlüsselmanager des Weiteren einen zwischen dem Sicherheitsproxy und der Zielentität verwendeten Handshake-Schlüssel von dem Sicherheitsproxy empfangen. Der Schlüsselmanager kann die erste Handshake-Nachricht mit dem Handshake-Schlüssel verschlüsseln.
  • In einigen Ausführungsformen kann der Schlüsselmanager eine erste Hello-Nachricht von dem Sicherheitsproxy als mindestens einen Teil der Kontextinformationen empfangen. Die erste Hello-Nachricht kann an die Quellenentität geleitet werden, um den Handshake einzuleiten. In einigen Ausführungsformen kann der Schlüsselmanager des Weiteren protokollierte Kontextinformationen eines protokollierten Handshakes, an dem die Quellenentität beteiligt ist, von dem Sicherheitsproxy empfangen. Zum Beispiel können die protokollierten Kontextinformationen ein Server-Hello und ein Serverzertifikat von der Quellenentität aufweisen. Der Schlüsselmanager kann die erste Handshake-Nachricht auf der Grundlage der protokollierten Kontextinformationen und der ersten Hello-Nachricht erzeugen.
  • In einigen Ausführungsformen kann der Schlüsselmanager des Weiteren einen Satz von Parametern von dem Sicherheitsproxy empfangen, um einen zwischen dem Sicherheitsproxy und der Zielentität verwendeten Handshake-Schlüssel festzulegen, und den Handshake-Schlüssel auf der Grundlage des Satzes von Parametern und der ersten Hello-Nachricht festlegen. Der Schlüsselmanager kann die erste Handshake-Nachricht mit dem Handshake-Schlüssel verschlüsseln.
  • Das Verarbeiten der Verwaltung von privaten Schlüsseln oder des Sicherheitsproxys / des Schlüsselmanagers gemäß Ausführungsformen dieser Offenbarung könnte durch das Computersystem/den Server 12 von 1 ausgeführt werden.
  • Unter Bezugnahme auf 10 ist ein Übersichtsblockschaubild eines beispielhaften Computersystems 1000 gezeigt, das so konfiguriert sein kann, dass es verschiedene Aspekte der vorliegenden Offenbarung durchführt, darunter, zum Beispiel, die Prozesse 800 und 900. Das beispielhafte Computersystem 1000 kann beim Ausführen von einem oder mehreren der Verfahren oder Module sowie beliebigen zugehörigen Funktionen oder Operationen, die hierin beschrieben sind (z.B. unter Verwendung eines Satzes von Prozessoren, der eine oder mehrere Prozessorschaltungen oder Computerprozessoren des Computers aufweist), gemäß Ausführungsformen der vorliegenden Offenbarung verwendet werden. Durch einen Satz von Prozessoren durchgeführte Aktionen können durch einen einzelnen Prozessor, einen aus einer Gruppe von Prozessoren, alle einer Gruppe von Prozessoren oder einer beliebigen dazwischenliegenden Menge durchgeführt werden. In einigen Ausführungsformen können die Hauptkomponenten des Computersystems 1000 eine oder mehrere CPUs 1002, ein Speichersubsystem 1008, eine Terminalschnittstelle 1016, eine Speicherschnittstelle 1018, eine E/A-(Eingabe-/Ausgabe-)Einheitenschnittstelle 1020 und eine Netzschnittstelle 1022 aufweisen, von denen alle direkt oder indirekt für eine komponentenübergreifende Übertragung über einen Speicherbus 1006, einen E/A-Bus 1014 und eine E/A-Busschnittstelleneinheit 1012 per Datenaustausch verbunden sein können.
  • Das Computersystem 1000 kann eine oder mehrere programmierbare, zentrale Universalverarbeitungseinheiten (CPUs) 1002 enthalten, von denen einige oder alle einen oder mehrere Kerne 1004A, 1004B, 1004C und 10004D umfassen können, die hierin allgemein als CPU 1002 bezeichnet werden. In einigen Ausführungsformen kann das Computersystem 1000 mehrere Prozessoren enthalten, die typisch für ein verhältnismäßig großes System sind; in anderen Ausführungsform kann das Computersystem 1000 alternativ jedoch ein einzelnes CPU-System sein. Jede CPU 1002 kann in dem Speichersubsystem 1008 gespeicherte Anweisungen auf einem CPU-Kern 1004 ausführen und eine oder mehrere Ebenen von integriertem Cache aufweisen.
  • In einigen Ausführungsformen kann das Speichersubsystem 1008 einen Direktzugriff-Halbleiterspeicher, eine Speichereinheit oder ein Speichermedium (entweder flüchtig oder nicht flüchtig) zur Speicherung von Daten und Programmen aufweisen. In einigen Ausführungsformen kann das Speichersubsystem 1008 den ganzen virtuellen Speicher des Computersystems 1000 darstellen und auch den virtuellen Speicher von anderen Computersystemen umfassen, die mit dem Computersystem 1000 verbunden oder über ein Netzwerk angeschlossen sind. Das Speichersubsystem 1008 kann konzeptionell eine einzelne monolithische Entität sein, in einigen Ausführungsformen kann das Speichersubsystem 1008 jedoch komplexer aufgebaut sein, beispielsweise als eine Hierarchie von Caches und anderen Arbeitsspeichereinheiten. Zum Beispiel kann Arbeitsspeicher in mehreren Ebenen von Caches vorhanden sein und diese Caches können des Weiteren nach ihrer Funktion unterteilt sein, so dass ein Cache Anweisungen enthält, während ein anderer Daten, bei denen es sich nicht um Anweisungen handelt, enthält, welche von dem Prozessor oder den Prozessoren verwendet werden. Der Arbeitsspeicher kann des Weiteren verteilt und verschiedenen CPUs oder Sätzen von CPUs zugeordnet sein, wie dies bei beliebigen von verschiedenen Computerarchitekturen mit so genanntem nicht einheitlichem Speicherzugriff (non-uniform memory access (NUMA)) bekannt ist. In einigen Ausführungsformen kann der Hauptspeicher oder das Speichersubsystem 804 Elemente zur Steuerung und für den Fluss des durch die CPU 1002 verwendeten Arbeitsspeichers enthalten. Dazu kann ein Speichercontroller 1010 gehören.
  • Obgleich der Speicherbus 1006 in 10 als eine Struktur mit einem einzelnen Bus gezeigt ist, die einen direkten Übertragungspfad zwischen der CPU 1002, dem Speichersubsystem 1008 und der E/A-Busschnittstelle 1012 bereitstellt, kann der Speicherbus 1006 in einigen Ausführungsformen mehrere unterschiedliche Busse oder Übertragungspfade aufweisen, die in beliebigen von verschiedenen Formen angeordnet sein können, wie beispielsweise als Punkt-zu-Punkt-Verbindungen in hierarchischen, Stern- oder Netzkonfigurationen, als mehrere hierarchische Busse, parallele und redundante Pfade oder in einer beliebigen anderen geeigneten Art der Konfiguration. Während die E/A-Busschnittstelle 1012 und der E/A-Bus 1014 als einzelne jeweilige Einheiten gezeigt sind, kann das Computersystem 1000 in einigen Ausführungsformen darüber hinaus mehrere E/A-Busschnittstelleneinheiten 1012, mehrere E/A-Busse 1014 oder beides enthalten. Zwar sind mehrere E/A-Schnittstelleneinheiten gezeigt, die den E/A-Bus 1014 von verschiedenen Übertragungspfaden trennen, die zu den verschiedenen E/A-Einheiten führen, doch können einige oder alle der E/A-Einheiten in weiteren Ausführungsformen des Weiteren direkt mit einem oder mehreren System-E/A-Bussen verbunden sein.
  • In einigen Ausführungsformen kann es sich bei dem Computersystem 1000 um ein Mehrbenutzer-Mainframe-Computersystem, ein Einzelbenutzersystem oder einen Server-Computer oder eine ähnliche Einheit handeln, die nur eine kleine oder gar keine direkte Benutzerschnittstelle hat, aber Anforderungen von anderen Computersystemen (Clients) empfängt. Des Weiteren kann das Computersystem 1000 in einigen Ausführungsformen als ein Desktop-Computer, ein tragbarer Computer, ein Laptop- oder Notebook-Computer, ein Tablet-Computer, ein Taschenrechner, ein Telefon, ein Smartphone, als mobile Einheit oder als eine beliebige andere geeignete Art von elektronischer Einheit ausgeführt sein.
  • Es sei angemerkt, dass 10 die repräsentativen Hauptkomponenten eines beispielhaften Computersystems 1000 darstellen soll. In einigen Ausführungsformen jedoch können einzelne Komponenten eine größere oder geringere Komplexität als die in 10 dargestellte aufweisen, es können andere Komponenten als die in 10 gezeigten oder zusätzliche zu den in 10 gezeigten Komponenten vorhanden sein, und die Anzahl, die Art und die Konfiguration von diesen Komponenten kann variieren.
  • Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf jeder möglichen Integrationsstufe technischer Details handeln. Das Computerprogrammprodukt kann ein durch einen Computer lesbares Speichermedium (oder -medien) mit durch einen Computer lesbaren Programmanweisungen darauf umfassen, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
  • Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die folgenden: eine auswechselbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein auswechselbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch kodierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. Lichtwellenleiterkabel durchlaufende Lichtimpulse) oder durch einen Draht übermittelte elektrische Signale.
  • Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Switches, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
  • Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmwareanweisungen, zustandssetzende Daten, Konfigurationsdaten für eine integrierte Schaltung oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, 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 einen beliebigen Typ 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). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, vor Ort programmierbare Gatter-Anordnungen (FPGA, field-programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
  • Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaltbildern bzw. Schaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
  • Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktion/Schritts umsetzen.
  • Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
  • Die Ablaufpläne und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in dem Ablaufplan oder in den Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, das bzw. der eine oder mehrere ausführbare Anweisungen zur Ausführung der festgelegten logischen Funktion(en) aufweist. In einigen alternativen Ausführungen können die in den Blöcken angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit als ein Schritt durchgeführt, gleichzeitig ausgeführt, im Wesentlichen gleichzeitig ausgeführt, in einer sich teilweise oder ganz zeitlich überlappenden Weise ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaltbilder bzw. Schaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern bzw. Schaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
  • Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Offenbarung erfolgten zum Zweck der Veranschaulichung, sollen jedoch nicht erschöpfend oder auf die offenbarten Ausführungsformen beschränkt sein. Viele Modifikationen und Varianten sind für den Fachmann erkennbar, ohne vom Umfang und Wesen der beschriebenen Ausführungsformen abzuweichen. Die hierin verwendete Terminologie wurde gewählt, um die Grundgedanken der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber auf dem Markt befindlichen Technologien zu erklären bzw. um anderen Fachleuten das Verständnis der hierin offenbarten Ausführungsformen zu ermöglichen.

Claims (23)

  1. Verfahren, das umfasst: Erhalten, durch einen Satz von Prozessoren an einem Sicherheitsproxy, von Kontextinformationen eines Handshakes zwischen einer Quellenentität und einer Zielentität; Senden, durch den Satz von Prozessoren an dem Sicherheitsproxy, der Kontextinformationen von dem Sicherheitsproxy an einen Schlüsselmanager, wobei der Schlüsselmanager einen ersten privaten Schlüssel des Sicherheitsproxys verwaltet; Empfangen, durch den Satz von Prozessoren an dem Sicherheitsproxy, einer ersten Handshake-Nachricht von dem Schlüsselmanager, wobei die erste Handshake-Nachricht mindestens auf der Grundlage der Kontextinformationen erzeugt und mit dem ersten privaten Schlüssel signiert wird; und Senden, durch den Satz von Prozessoren an dem Sicherheitsproxy, der ersten Handshake-Nachricht an die Zielentität.
  2. Verfahren nach Anspruch 1, wobei das Erhalten der Kontextinformationen aufweist: Empfangen, durch den Satz von Prozessoren an dem Sicherheitsproxy, einer zweiten Handshake-Nachricht von der Quellenentität als mindestens einen Teil der Kontextinformationen, wobei die zweite Handshake-Nachricht an die Zielentität geleitet und mit einem zweiten privaten Schlüssel der Quellenentität signiert wird.
  3. Verfahren nach Anspruch 2, das des Weiteren umfasst: Senden, durch den Satz von Prozessoren an dem Sicherheitsproxy, eines zwischen dem Sicherheitsproxy und der Zielentität verwendeten Handshake-Schlüssels an den Schlüsselmanager, wobei die erste Handshake-Nachricht mit dem Handshake-Schlüssel verschlüsselt wird.
  4. Verfahren nach Anspruch 1, wobei das Erhalten der Kontextinformationen aufweist: Empfangen, durch den Satz von Prozessoren an dem Sicherheitsproxy, einer ersten Hello-Nachricht von der Zielentität als mindestens einen Teil der Kontextinformationen, wobei die erste Hello-Nachricht an die Quellenentität geleitet wird, um den Handshake einzuleiten.
  5. Verfahren nach Anspruch 4, das des Weiteren umfasst: Erhalten, durch den Satz von Prozessoren an dem Sicherheitsproxy, von protokollierten Kontextinformationen eines protokollierten Handshakes, an dem die Quellenentität beteiligt ist; und Senden, durch den Satz von Prozessoren an dem Sicherheitsproxy, der protokollierten Kontextinformationen an den Schlüsselmanager, wobei die erste Handshake-Nachricht auf der Grundlage der protokollierten Kontextinformationen und der ersten Hello-Nachricht erzeugt wird.
  6. Verfahren nach Anspruch 5, das des Weiteren umfasst: Festlegen, durch den Satz von Prozessoren an dem Sicherheitsproxy, einer zweiten Hello-Nachricht als Antwort auf die erste Hello-Nachricht auf der Grundlage der protokollierten Kontextinformationen; und Senden, durch den Satz von Prozessoren an dem Sicherheitsproxy, der zweiten Hello-Nachricht an die Zielentität.
  7. Verfahren nach Anspruch 4, das des Weiteren umfasst: Senden, durch den Satz von Prozessoren an dem Sicherheitsproxy, eines Satzes von Parametern an den Schlüsselmanager, um einen zwischen dem Sicherheitsproxy und der Zielentität verwendeten Handshake-Schlüssel festzulegen, wobei die erste Handshake-Nachricht mit dem Handshake-Schlüssel verschlüsselt wird, der auf der Grundlage des Satzes von Parametern und der ersten Hello-Nachricht festgelegt wird.
  8. Verfahren, das umfasst: Empfangen, durch einen Satz von Prozessoren an einem Schlüsselmanager, von Kontextinformationen eines Handshakes zwischen einer Quellenentität und einer Zielentität von einem Sicherheitsproxy; Erzeugen, durch den Satz von Prozessoren an dem Schlüsselmanager, einer an die Zielentität geleiteten ersten Handshake-Nachricht mindestens auf der Grundlage der Kontextinformationen, wobei die erste Handshake-Nachricht mit einem durch den Schlüsselmanager verwalteten ersten privaten Schlüssel des Sicherheitsproxys signiert wird; und Senden, durch den Satz von Prozessoren an dem Schlüsselmanager, der ersten Handshake-Nachricht an den Sicherheitsproxy.
  9. Verfahren nach Anspruch 8, wobei das Empfangen der Kontextinformationen aufweist: Empfangen, durch den Satz von Prozessoren an dem Schlüsselmanager, einer zweiten Handshake-Nachricht von dem Sicherheitsproxy als mindestens einen Teil der Kontextinformationen, wobei die zweite Handshake-Nachricht an die Zielentität geleitet und mit einem zweiten privaten Schlüssel der Quellenentität signiert wird.
  10. Verfahren nach Anspruch 9, das des Weiteren umfasst: Empfangen, durch den Satz von Prozessoren an dem Schlüsselmanager, eines zwischen dem Sicherheitsproxy und der Zielentität verwendeten Handshake-Schlüssels von dem Sicherheitsproxy; wobei das Erzeugen der ersten Handshake-Nachricht ein Verschlüsseln, durch den Satz von Prozessoren an dem Schlüsselmanager, der ersten Handshake-Nachricht mit dem Handshake-Schlüssel aufweist.
  11. Verfahren nach Anspruch 8, wobei das Empfangen der Kontextinformationen aufweist: Empfangen, durch den Satz von Prozessoren an dem Schlüsselmanager, einer ersten Hello-Nachricht von dem Sicherheitsproxy als mindestens einen Teil der Kontextinformationen, wobei die erste Hello-Nachricht an die Quellenentität geleitet wird, um den Handshake einzuleiten.
  12. Verfahren nach Anspruch 11, das des Weiteren umfasst: Empfangen, durch den Satz von Prozessoren an dem Schlüsselmanager, von protokollierten Kontextinformationen eines protokollierten Handshakes, an dem die Quellenentität beteiligt ist, von dem Sicherheitsproxy; wobei das Erzeugen der ersten Handshake-Nachricht ein Erzeugen, durch den Satz von Prozessoren an dem Schlüsselmanager, der ersten Handshake-Nachricht auf der Grundlage der protokollierten Kontextinformationen und der ersten Hello-Nachricht aufweist.
  13. Verfahren nach Anspruch 11, das des Weiteren umfasst: Empfangen, durch den Satz von Prozessoren an dem Schlüsselmanager, eines Satzes von Parametern von dem Sicherheitsproxy, um einen zwischen dem Sicherheitsproxy und der Zielentität verwendeten Handshake-Schlüssel festzulegen; und Festlegen, durch den Satz von Prozessoren an dem Schlüsselmanager, des Handshake-Schlüssels auf der Grundlage des Satzes von Parametern und der ersten Hello-Nachricht; wobei das Erzeugen der ersten Handshake-Nachricht ein Verschlüsseln, durch den Satz von Prozessoren an dem Schlüsselmanager, der ersten Handshake-Nachricht mit dem Handshake-Schlüssel aufweist.
  14. System, das aufweist: einen Prozessor; und einen Arbeitsspeicher, der mit dem Prozessor in Verbindung steht, wobei der Arbeitsspeicher Programmanweisungen enthält, die, wenn sie durch den Prozessor ausgeführt werden, so konfiguriert sind, dass sie den Prozessor dazu veranlassen: Kontextinformationen eines Handshakes zwischen einer Quellenentität und einer Zielentität an einem Sicherheitsproxy zu erhalten; die Kontextinformationen von dem Sicherheitsproxy an einen Schlüsselmanager zu senden, wobei der Schlüsselmanager einen ersten privaten Schlüssel des Sicherheitsproxys verwaltet; eine erste Handshake-Nachricht von dem Schlüsselmanager zu empfangen, wobei die erste Handshake-Nachricht mindestens auf der Grundlage der Kontextinformationen erzeugt und mit dem ersten privaten Schlüssel signiert wird; und die erste Handshake-Nachricht an die Zielentität zu senden.
  15. System nach Anspruch 14, wobei das Erhalten der Kontextinformationen ein Empfangen einer zweiten Handshake-Nachricht von der Quellenentität als mindestens einen Teil der Kontextinformationen aufweist, wobei die zweite Handshake-Nachricht an die Zielentität geleitet und mit einem zweiten privaten Schlüssel der Quellenentität signiert wird.
  16. System nach Anspruch 15, wobei die CPU des Weiteren so konfiguriert ist, dass sie einen zwischen dem Sicherheitsproxy und der Zielentität verwendeten Handshake-Schlüssel an den Schlüsselmanager sendet, wobei die erste Handshake-Nachricht mit dem Handshake-Schlüssel verschlüsselt wird.
  17. System nach Anspruch 14, wobei das Erhalten der Kontextinformationen ein Empfangen einer ersten Hello-Nachricht von der Zielentität als mindestens einen Teil der Kontextinformationen aufweist, wobei die erste Hello-Nachricht an die Quellenentität geleitet wird, um den Handshake einzuleiten.
  18. System nach Anspruch 17, wobei die CPU des Weiteren so konfiguriert ist, dass sie: protokollierte Kontextinformationen eines protokollierten Handshakes, an dem die Quellenentität beteiligt ist, erhält; und die protokollierten Kontextinformationen an den Schlüsselmanager sendet, wobei die erste Handshake-Nachricht auf der Grundlage der protokollierten Kontextinformationen und der ersten Hello-Nachricht erzeugt wird.
  19. System nach Anspruch 18, wobei die CPU des Weiteren so konfiguriert ist, dass sie: als Antwort auf die erste Hello-Nachricht auf der Grundlage der protokollierten Kontextinformationen eine zweite Hello-Nachricht festlegt; und die zweite Hello-Nachricht an die Zielentität sendet.
  20. System nach Anspruch 17, wobei die CPU des Weiteren so konfiguriert ist, dass sie: einen Satz von Parametern an den Schlüsselmanager sendet, um einen zwischen dem Sicherheitsproxy und der Zielentität verwendeten Handshake-Schlüssel festzulegen, wobei die erste Handshake-Nachricht mit dem Handshake-Schlüssel verschlüsselt wird, der auf der Grundlage des Satzes von Parametern und der ersten Hello-Nachricht festgelegt wird.
  21. System, das aufweist: einen Prozessor; und einen Arbeitsspeicher, der mit dem Prozessor in Verbindung steht, wobei der Arbeitsspeicher Programmanweisungen enthält, die, wenn sie durch den Prozessor ausgeführt werden, so konfiguriert sind, dass sie den Prozessor dazu veranlassen: an einem Schlüsselmanager Kontextinformationen eines Handshakes zwischen einer Quellenentität und einer Zielentität von einem Sicherheitsproxy zu empfangen; an dem Schlüsselmanager eine an die Zielentität geleitete erste Handshake-Nachricht mindestens auf der Grundlage der Kontextinformationen zu erzeugen, wobei die erste Handshake-Nachricht mit einem durch den Schlüsselmanager verwalteten ersten privaten Schlüssel des Sicherheitsproxys signiert wird; und an dem Schlüsselmanager die erste Handshake-Nachricht an den Sicherheitsproxy zu senden.
  22. Computerprogramm, das Programmcode aufweist, der so ausgelegt ist, dass er die Verfahrensschritte nach einem der Ansprüche 1 bis 7 durchführt, wenn das Programm auf einem Computer ausgeführt wird.
  23. Computerprogramm, das Programmcode aufweist, der so ausgelegt ist, dass er die Verfahrensschritte nach einem der Ansprüche 8 bis 13 durchführt, wenn das Programm auf einem Computer ausgeführt wird.
DE112021005237.3T 2020-11-18 2021-11-04 Verwaltung von privaten schlüsseln Pending DE112021005237T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/950,993 2020-11-18
US16/950,993 US11968293B2 (en) 2020-11-18 2020-11-18 Private key management
PCT/CN2021/128729 WO2022105617A1 (en) 2020-11-18 2021-11-04 Private key management

Publications (1)

Publication Number Publication Date
DE112021005237T5 true DE112021005237T5 (de) 2023-08-24

Family

ID=81588064

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021005237.3T Pending DE112021005237T5 (de) 2020-11-18 2021-11-04 Verwaltung von privaten schlüsseln

Country Status (6)

Country Link
US (1) US11968293B2 (de)
JP (1) JP2023549598A (de)
CN (1) CN116491101A (de)
DE (1) DE112021005237T5 (de)
GB (1) GB2615676B (de)
WO (1) WO2022105617A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10666640B2 (en) * 2017-12-20 2020-05-26 Cisco Technology, Inc. Semi-active probing framework to gather threat intelligence for encrypted traffic and learn about devices

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5657390A (en) * 1995-08-25 1997-08-12 Netscape Communications Corporation Secure socket layer application program apparatus and method
JP3595109B2 (ja) * 1997-05-28 2004-12-02 日本ユニシス株式会社 認証装置、端末装置、および、それら装置における認証方法、並びに、記憶媒体
US7065642B2 (en) * 2000-12-19 2006-06-20 Tricipher, Inc. System and method for generation and use of asymmetric crypto-keys each having a public portion and multiple private portions
US20020116637A1 (en) * 2000-12-21 2002-08-22 General Electric Company Gateway for securely connecting arbitrary devices and service providers
US20040218762A1 (en) 2003-04-29 2004-11-04 Eric Le Saint Universal secure messaging for cryptographic modules
US8601566B2 (en) * 2001-10-23 2013-12-03 Intel Corporation Mechanism supporting wired and wireless methods for client and server side authentication
US8028329B2 (en) * 2005-06-13 2011-09-27 Iamsecureonline, Inc. Proxy authentication network
US8316429B2 (en) * 2006-01-31 2012-11-20 Blue Coat Systems, Inc. Methods and systems for obtaining URL filtering information
US9055107B2 (en) 2006-12-01 2015-06-09 Microsoft Technology Licensing, Llc Authentication delegation based on re-verification of cryptographic evidence
US8862889B2 (en) 2011-07-02 2014-10-14 Eastcliff LLC Protocol for controlling access to encryption keys
US9264892B2 (en) * 2013-07-03 2016-02-16 Verizon Patent And Licensing Inc. Method and apparatus for attack resistant mesh networks
US10178181B2 (en) * 2014-04-02 2019-01-08 Cisco Technology, Inc. Interposer with security assistant key escrow
US9184911B2 (en) * 2014-04-08 2015-11-10 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
KR101563562B1 (ko) 2014-07-11 2015-10-27 숭실대학교산학협력단 Ssl/tls 인증 장치 및 방법
US9854000B2 (en) * 2014-11-06 2017-12-26 Cisco Technology, Inc. Method and apparatus for detecting malicious software using handshake information
CN109302369B (zh) 2017-07-24 2021-03-16 贵州白山云科技股份有限公司 一种基于密钥验证的数据传输方法及装置
CN110247803B (zh) 2019-06-20 2022-05-20 成都积微物联集团股份有限公司 一种针对网络管理协议SNMPv3的协议优化架构及其方法
CN113595967A (zh) * 2020-04-30 2021-11-02 深信服科技股份有限公司 数据识别方法、设备、存储介质及装置

Also Published As

Publication number Publication date
US11968293B2 (en) 2024-04-23
US20220158824A1 (en) 2022-05-19
WO2022105617A1 (en) 2022-05-27
GB2615676A (en) 2023-08-16
JP2023549598A (ja) 2023-11-28
GB2615676B (en) 2024-01-03
CN116491101A (zh) 2023-07-25
GB202306194D0 (en) 2023-06-14

Similar Documents

Publication Publication Date Title
DE102016222034A1 (de) Dynamische Kennworterzeugung
DE112021002245T5 (de) Verhindern einer unberechtigten bereitstellung von paketen in clustern
DE112016001657T5 (de) Multi-Tenant-Sensitiver DHCP-Mechanismus für Cloud-Netzwerke
DE102012215219A1 (de) Ermitteln von Verteilungen von Abbildmustern von virtuellen Maschinen in einer vernetzten Datenverarbeitungsumgebung
DE112018004390B4 (de) Sichere zugriffsverwaltung für werkzeuge innerhalb einer sicheren umgebung
DE102016105062A1 (de) Nähengestützte Berechtigungsprüfung für einheitenübergreifend verteilte Daten
DE112021004937T5 (de) Sicheres erneutes verschlüsseln von homomorph verschlüsselten daten
DE112021002487T5 (de) Teilen einer geografisch konzentrierten arbeitslast zwischen benachbarten mec-hosts mehrerer netzbetreiber
DE102021125182A1 (de) Gemeinsam genutzte unternehmenscloud
DE112021006372T5 (de) Sichere bereitstellung einer datenverarbeitungsressource unter verwendung einer homomorphen verschlüsselung
DE112016000790T5 (de) Instanziierung von Broadcast-Verschlüsselungsschemata zur Laufzeit
DE112022002736T5 (de) Übertragen von aufgabendaten zwischen edge-einheiten beim edge computing
DE112020002343T5 (de) Verteilung von Sicherheitsberechtigungsnachweisen
DE112020005373T5 (de) Mechanismus zur authentifizierung durch nutzung von positionsbestätigung
DE102021130396A1 (de) Datenzugriffsüberwachung und -steuerung
DE112021005636T5 (de) Migrieren von komplexen legacy-anwendungen
DE112022002615T5 (de) Kontinuierliche funktionsfähigkeit und integrität von anwendungen während eines migrationsvorgangs
DE112021004770T5 (de) Ultraschallübertragung von aufgeteilten schlüsseln für verbesserte sicherheit
DE112019002052T5 (de) Datenschutzsensibilisierung bei der bereitstellung von arbeitslasten
DE102021130942A1 (de) Mehrstufiger schutz für datenzentrierte objekte
DE102014116744A1 (de) Management von Informationstechnologieressourcen
DE112021006008T5 (de) Sichere übertragung grosser datenmengen
DE112021004695T5 (de) Umgang mit zurückstellbaren netzwerkanforderungen
DE112021005237T5 (de) Verwaltung von privaten schlüsseln
DE112021003864T5 (de) Durchsetzung von signaturen für die konfiguration von softwarebereitstellung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R083 Amendment of/additions to inventor(s)
R084 Declaration of willingness to licence