DE602005001613T2 - Einrichten eines sicheren kontexts zur übermittlung von nachrichten zwischen computersystemen - Google Patents

Einrichten eines sicheren kontexts zur übermittlung von nachrichten zwischen computersystemen Download PDF

Info

Publication number
DE602005001613T2
DE602005001613T2 DE602005001613T DE602005001613T DE602005001613T2 DE 602005001613 T2 DE602005001613 T2 DE 602005001613T2 DE 602005001613 T DE602005001613 T DE 602005001613T DE 602005001613 T DE602005001613 T DE 602005001613T DE 602005001613 T2 DE602005001613 T2 DE 602005001613T2
Authority
DE
Germany
Prior art keywords
key
message
certificate
public key
public
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE602005001613T
Other languages
English (en)
Other versions
DE602005001613D1 (de
Inventor
Paul Anthony Bardon ASHLEY
Robert Andrew Broadbeach FYFE
Michael James Bonogin THOMAS
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 DE602005001613D1 publication Critical patent/DE602005001613D1/de
Application granted granted Critical
Publication of DE602005001613T2 publication Critical patent/DE602005001613T2/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • 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
    • 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/3234—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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • 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/56—Financial cryptography, e.g. electronic payment or e-cash
    • 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/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • 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/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • 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/164—Implementing security features at a particular protocol layer at the network layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)
  • Communication Control (AREA)

Description

  • Gebiet der Technik
  • Die vorliegende Erfindung betrifft ein verbessertes Datenverarbeitungssystem und insbesondere ein Verfahren und eine Vorrichtung zur Übertragung von Daten zwischen mehreren Rechnern. Genauer gesagt, die vorliegende Erfindung stellt ein Verfahren und eine Vorrichtung zum Austausch von Daten zwischen mehreren Rechnern mit Hilfe der Kryptographie bereit.
  • Stand der Technik
  • Websites für den Handel im Internet (eCommerce) und andere Arten von Anwendungen führen im Namen von Benutzern und Clients Transaktionen über Rechnernetzwerke aus. Vor der Durchführung einer angeforderten Operationen im Namen eines Client muss der Client häufig eine Identitätsprüfungsprozedur durchlaufen, um seine Identität aus Sicherheitsgründen mit einem entsprechenden Maß an Sicherheit nachzuweisen.
  • Viele Datenverarbeitungssysteme unterstützen Operationen zum Nachweis der Identität von Clients über die Anwendungsprogrammierschnittstelle Generic Security Service (GSS-API), die in "Generic Security Services Application Program Interface" von Linn, Internet Engineering Task Force (IETF) Request for Comments (RFC) 1508, September 1993, von Linn für veraltet erklärt, "Generic Security Services Application Program Interface, Version 2", IETF RFC 2078, Januar 1997, beschrieben ist. Wie in diesen Schriftstücken dargelegt ist, stellt die GSS-API Aufrufenden allgemein Sicherheitsdienste bereit. Die GSS-API unterstützt unterschiedliche zugrunde liegende Mechanismen und Technologien durch festgelegte Dienste und Grundelemente und ermöglicht dadurch eine Übertragbarkeit von Anwendungen auf Quellebene auf verschiedene Betriebs- und Programmiersprachenumgebungen.
  • Alternative vorhandene GSS-API-Mechanismen werden in "The Simple Public-Key GSS-API Mechanism (SPKM)" von Adams, IETF RFC 2025, Oktober 1996 und in "LIPKEY – A Low Infrastructure Public Key Mechanisms Using SPKM" von Eisler, IETF RFC 2847, Juni 2000, vorgestellt. Wie in diesen Schriftstücken beschrieben ist, ermöglicht SPKM die Identitätsprüfung, die Festlegung von Schlüsseln, die Unversehrtheit und Vollständigkeit der Daten (Datenintegrität) und die Vertraulichkeit der Daten in einer verteilten Online-Anwendungsumgebung unter Verwendung einer Infrastruktur mit öffentlichem Schlüssel. Da es die Anforderungen der GSS-API erfüllt, kann SPKM von jeder Anwendung genutzt werden, die für den Zugriff auf Sicherheitsdienste GSS-API-Aufrufe verwendet. Alternativ dazu stellt LIPKEY auch ein Verfahren bereit, um einen sicheren Kanal zwischen einem Client und einem Server zur Verfügung zu stellen. LIPKEY entspricht ungefähr der allgemeinen, mit geringeren Ansprüchen an die Infrastruktur verbundenen Verwendung der Transport Layer Security (TLS), bei der es sich um ein alternatives Verfahren zur GSS-API handelt, um Sicherheitsfunktionen wie Identitätsprüfung, Datenintegrität und Datenschutz zu realisieren; TLS ist in "The TLS Protocol, Version 1.0" von Dierks u.a., IETF RFC 2246, Januar 1999, beschrieben. LIPKEY setzt SPKM wirksam als einen gesonderten GSS-API-Mechanismus ein, der oberhalb von SPKM angesiedelt ist.
  • Berücksichtigt man die Anforderungen von sehr aktiven Serversystemen an die Rechenleistung, besteht ein Bedarf an flexiblen und einfachen Sicherheitsoperationen. Es wäre folglich vorteilhaft, wenn man über einen Mechanismus verfügen würde, der der GSS-API entspricht und der mehrere Arten der Identitätsprüfung von Clients durchführt.
  • Offenbarung der Erfindung
  • Ein Verfahren nach den Ansprüchen 1 und 2, ein Rechnerprogrammprodukt nach den Ansprüchen 2 und 3 und eine Vorrichtung nach den Ansprüchen 5 und 6 zum Aufbau eines sicheren Kontexts werden vorgestellt, um Nachrichten zwischen einem Client und einem Server auszutauschen, wobei der Kontext der Anwendungsprogrammierschnittstelle Generic Security Service (GSS-API) entspricht. Der Client sendet eine erste Nachricht an den Server, die einen vom Client erzeugten ersten symmetrischen geheimen Schlüssel und ein Identitätsprüfungselement (authentication token) enthält; wobei die erste Nachricht mit dem öffentlichen Schlüssel von einem Zertifikat mit öffentlichem Schlüssel, das zu dem Server gehört, gesichert wird. Unter der Annahme, dass der Server die Identität des Client auf der Grundlage des Identitätsprüfungselements nachweisen kann, empfängt der Client dann vom Server eine zweite Nachricht, die mit dem ersten symmetrischen Schlüssel gesichert wurde und einen zweiten symmetrischen geheimen Schlüssel enthält. Der Client und der Server verwenden den zweiten symmetrischen geheimen Schlüssel, um nachfolgende Nachrichten zu sichern, die zwischen dem Client und dem Server gesendet werden. Das Identitätsprüfungselement kann ein Zertifikat mit öffentlichem Schlüssel, das zu dem Client gehört, ein aus Benutzername und Passwort bestehendes Paar oder ein sicheres Ticket sein.
  • Kurze Beschreibung der Zeichnungen
  • Eine bevorzugte Ausführungsform der vorliegenden Erfindung wird nun lediglich anhand eines Beispiels und mit Bezug auf die folgenden Figuren ausführlich beschrieben, bei denen:
  • 1A ein typisches Netzwerk aus Datenverarbeitungssystemen zeigt, von denen jedes bevorzugte Ausführungsformen der vorliegenden Erfindung realisieren kann;
  • 1B eine typische Rechnerarchitektur zeigt, die in einem Datenverarbeitungssystem verwendet werden kann, in dem bevorzugte Ausführungsformen der vorliegenden Erfindung realisiert werden können;
  • 2 ein Blockschaubild ist, das eine typische Art und Weise zeigt, in der eine Person ein digitales Zertifikat abruft;
  • 3 ein Blockschaubild ist, das eine typische Art und Weise zeigt, in der eine Instanz ein digitales Zertifikat verwenden kann, dessen Echtheit gegenüber einem Datenverarbeitungssystem nachgewiesen werden muss;
  • 4 ein Datenflussdiagramm ist, das einen typischen, der GSS-API entsprechenden Mechanismus zum Aufbau eines sicheren Datenübertragungskontexts zwischen einem Client und einem Server zeigt; und
  • 5 ein Datenflussdiagramm ist, das einen typischen, der GSS-API entsprechenden Mechanismus zum Aufbau eines sicheren Datenübertragungskontexts zwischen einem Client und einem Server gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
  • Betriebsweise für die Erfindung
  • Im Allgemeinen enthalten die Einheiten, die bevorzugte Ausführungsformen der vorliegenden Erfindung umfassen oder zu diesen gehören können, ein breites Spektrum an Datenverarbeitungstechnologie. Als Hintergrund wird deshalb eine typische Anordnung von Hardware- und Software-Komponenten in einem verteilten Datenverarbeitungssystem beschrieben, bevor bevorzugte Ausführungsformen der vorliegenden Erfindung ausführlicher beschrieben werden.
  • Nun Bezug nehmend auf die Figuren zeigt 1A ein typisches Netzwerk aus Datenverarbeitungssystemen, von denen jedes einen Teil von bevorzugten Ausführungsformen der vorliegenden Erfindung realisieren kann. Das verteilte Datenverarbeitungssystem 100 enthält ein Netzwerk 101, bei dem es sich um ein Medium handelt, das zur Bereitstellung von Datenübertragungsverbindungen zwischen verschiedenen Einheiten und Rechnern verwendet werden kann, die in dem verteilten Datenverarbeitungssystem 100 miteinander verbunden sind. Das Netzwerk 101 kann feste Verbindungen wie zum Beispiel Drahtkabel oder Lichtwellenleiterkabel oder zeitweilige Verbindungen enthalten, die über Telefon- oder drahtlose Verbindungen hergestellt werden. In dem gezeigten Beispiel sind der Server 102 und der Server 103 zusammen mit der Speichereinheit 104 mit dem Netzwerk 101 verbunden. Ferner sind auch die Clients 105 bis 107 mit dem Netzwerk 101 verbunden. Die Clients 105 bis 107 und die Server 102 und 103 können durch viele verschiedene Datenverarbeitungseinheiten dargestellt werden, zum Beispiel durch Großrechner, Personal Computer, persönliche digitale Assistenten (PDAs) usw. Das verteilte Datenverarbeitungssystem 100 kann zusätzliche Server, Clients, Router, andere Einheiten und Architekturen mit gleichberechtigten Einheiten (Peer-zu-Peer-Architekturen) enthalten, die nicht gezeigt sind.
  • In dem gezeigten Beispiel kann das verteilte Datenverarbeitungssystem 100 mit dem Netzwerk 101 das Internet beinhalten, das einen weltweiten Verbund von Netzwerken und Netzübergängen (Gateways) darstellt, die verschiedene Protokolle einsetzen, um miteinander Daten auszutauschen, wie zum Beispiel das Lightweight Directory Access Protocol (LDAP), das Transport Control Protocol/Internet Protocol (TCP/IP), das Hypertext Transport Protocol (HTTP), das Wireless Application Protocol (WAP) usw. Natürlich kann das verteilte Datenverarbeitungssystem 100 auch mehrere verschiedene Arten von Netzwerken wie zum Beispiel ein Intranet, ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN) enthalten. Zum Beispiel unterstützt der Server 102 direkt den Client 109 und das Netzwerk 110, das drahtlose Datenübertragungsverbindungen enthält. Das netzwerkfähige Telefon 111 ist über eine drahtlose Verbindung 112 mit dem Netzwerk 110 verbunden, und der PDA 113 ist über eine drahtlose Verbindung 114 mit dem Netzwerk 110 verbunden. Das Telefon 111 und der PDA 113 können Daten über die drahtlose Verbindung 115 auch direkt untereinander übertragen, wobei sie eine entsprechende Technologie wie zum Beispiel die drahtlose Technologie BluetoothTM nutzen, um so genannte Personal Area Networks (PANs) oder persönliche Ad-hoc-Netzwerke aufzubauen. Auf ähnliche Weise kann der PDA 113 über die drahtlose Datenübertragungsverbindung 116 Daten an den PDA 107 übertragen.
  • Bevorzugte Ausführungsformen der vorliegenden Erfindung könnten auf vielen verschiedenen Hardware-Plattformen realisiert werden; 1A soll als Beispiel für eine heterogene Datenverarbeitungsumgebung dienen und ist nicht als architektonische Beschränkung bei bevorzugten Ausführungsformen der vorliegenden Erfindung zu verstehen.
  • Nun Bezug nehmend auf 1B zeigt ein Blockschaltbild eine typische Rechnerarchitektur eines Datenverarbeitungssystems wie zum Beispiel der in 1A gezeigten Datenverarbeitungssysteme, in denen bevorzugte Ausführungsformen der vorliegenden Erfindung realisiert werden können. Das Datenverarbeitungssystem 120 enthält eine oder mehrere Zentraleinheiten (CPUs) 122, die an den internen Systembus 123 angeschlossen sind, der den Direktzugriffspeicher (RAM) 124, den Nur-Lese-Speicher 126 und den Eingabe-/Ausgabe-Adapter 128 miteinander verbindet, welcher verschiedene E/A-Einheiten wie den Drucker 130, die Platteneinheiten 132 oder andere Einheiten, die nicht gezeigt sind, wie zum Beispiel ein Audioausgabesystem usw. unterstützt. An den Systembus 123 ist auch der Datenübertragungsadapter 134 angeschlossen, der Zugriff auf die Datenübertragungsverbindung 136 ermöglicht. Der Benutzerschnittstellenadapter 148 verbindet verschiedene Benutzereinheiten wie zum Beispiel die Tastatur 140 und die Maus 142 oder andere Einheiten, die nicht gezeigt sind, wie zum Beispiel einen berührungsempfindlichen Bildschirm, einen Stift, ein Mikrofon usw. Der Bildschirmadapter 144 verbindet den Systembus 123 mit dem Bildschirm 146.
  • Der Fachmann versteht, dass die Hardware in 1B in Abhängigkeit von der Ausführung des Systems unterschiedlich ausgestaltet sein kann. Zum Beispiel kann das System über einen oder mehrere Prozessoren wie zum Beispiel einen Prozessor, der auf dem Pentium®-Prozessor von Intel® beruht, sowie einen digitalen Signalprozessor (DSP) und über eine oder mehrere Arten von flüchtigem oder nichtflüchtigem Speicher verfügen. Andere periphere Einheiten können zusätzlich zu der oder anstelle von der in 1B gezeigten Hardware verwendet werden. Die gezeigten Beispiele sind nicht als architektonische Beschränkungen in Bezug auf bevorzugte Ausführungsformen der vorliegenden Erfindung zu verstehen.
  • Bevorzugte Ausführungsformen der vorliegenden Erfindung können nicht nur auf vielen verschiedenen Hardware-Plattformen, sondern auch in vielen verschiedenen Software-Umgebungen realisiert werden. Ein typisches Betriebssystem kann zur Steuerung der Programmausführung in jedem Datenverarbeitungssystem eingesetzt werden. Eine Einheit kann zum Beispiel ein Unix®-Betriebssystem ausführen, während eine andere Einheit eine einfache Java®-Laufzeitumgebung enthält. Eine repräsentative Rechnerplattform kann einen Browser enthalten, bei dem es sich um eine bekannte Software-Anwendung zum Zugriff auf Hypertext-Dokumente in vielen verschiedenen Formaten wie zum Beispiel Grafikdateien, Textverarbeitungsdateien, Extensible Markup Language (XML), Hypertext Markup Language (HTML), Handheld Device Markup Language (HDML), Wireless Markup Language (WML) sowie verschiedene andere Formate und Dateitypen handelt.
  • Die Beschreibungen der hier gezeigten Figuren schließen bestimmte Aktionen ein, die entweder von einer Client-Einheit oder einem Benutzer der Client-Einheit durchgeführt werden. Der Fachmann versteht, dass Antworten und/oder Anforderungen an den/von dem Client manchmal von einem Benutzer veranlasst und manchmal automatisch von einem Client, oftmals im Namen des Benutzers des Client, veranlasst werden. Wenn ein Client oder ein Benutzer eines Client in der Beschreibung der Figuren erwähnt wird, sollte es sich folglich verstehen, dass die Begriffe "Client" und "Benutzer" austauschbar verwendet werden können, ohne dass sich dies spürbar auf die Bedeutung der beschriebenen Prozesse auswirkt.
  • Bevorzugte Ausführungsformen der vorliegenden Erfindung können auf vielen verschiedenen Hardware- und Software-Plattformen ausgeführt werden, wie vorstehend mit Bezug auf 1A und 1B beschrieben wurde. Im Einzelnen betreffen bevorzugte Ausführungsformen der vorliegenden Erfindung jedoch einen verbesserten, auf einem öffentlichen Schlüssel beruhenden Mechanismus zum Aufbau eines sicheren Kontexts für den Austausch von Daten zwischen einem Client und einem Server, der der Generic Security Services Application Programm Interface (GSS-API) entspricht; ein sicherer Kontext umfasst Informationen, die zwischen zwei oder mehr Instanzen, die Daten austauschen, für die Dauer einer Datenübertragungssitzung gemeinsam benutzt werden, während derer mehrere sichere Nachrichten zwischen den miteinander kommunizierenden Instanzen ausgetauscht werden können. Bevor eine bevorzugte Ausführungsform der vorliegenden Erfindung jedoch ausführlicher beschrieben wird, werden einige Hintergrundinformationen über digitale Zertifikate gegeben, um die Leistungsfähigkeit sowie weitere Vorteile von bevorzugten Ausführungsformen der vorliegenden Erfindung beurteilen zu können.
  • Digitale Zertifikate unterstützen die Kryptographie mit einem öffentlichen Schlüssel, bei der jeder Teilnehmer, der an einer Datenaustauschoperation oder einer Transaktion beteiligt ist, ein Paar Schlüssel hat, die als öffentlicher Schlüssel und privater Schlüssel bezeichnet werden. Der öffentliche Schlüssel eines jeden Teilnehmers wird veröffentlicht, während der private Schlüssel geheim gehalten wird. Öffentliche Schlüssel sind Ziffern, die einer bestimmten Instanz zugeordnet werden und jedem bekannt sein sollen, der eine vertrauenswürdige interaktive Kommunikation mit dieser Instanz führen möchte. Private Schlüssel sind Ziffern, die nur einer bestimmten Instanz bekannt sein sollen, d.h., sie sollen geheim gehalten werden. In einem typischen asymmetrischen kryptographischen System entspricht ein privater Schlüssel genau einem öffentlichen Schlüssel.
  • Da an dem gesamten Datenaustausch nur öffentliche Schlüssel beteiligt sind und ein privater Schlüssel niemals übertragen oder mit anderen gemeinsam benutzt wird, können vertrauliche Nachrichten in einem kryptographischen System, das mit einem öffentlichen Schlüssel arbeitet, erzeugt werden, indem nur öffentliche Informationen verwendet werden, und entschlüsselt werden, indem nur ein privater Schlüssel verwendet wird, der sich im alleinigen Besitz des vorgesehenen Empfängers befindet. Außerdem kann die Kryptographie mit öffentlichem Schlüssel zum Nachweis der Identität, d.h. für digitale Signaturen, und auch zum Datenschutz, d.h. zur Verschlüsselung, eingesetzt werden.
  • Bei der Verschlüsselung werden Daten in eine Form umgewandelt, die von einer Person, die nicht über einen geheimen Entschlüsselungsschlüssel verfügt, nicht gelesen werden kann; die Verschlüsselung gewährleistet Vertraulichkeit, indem der Inhalt der Information vor jeder Person, für die er nicht bestimmt ist, verborgen wird, selbst vor denjenigen, die die verschlüsselten Daten sehen können. Der Nachweis der Identität ist ein Prozess, durch den sich der Empfänger einer digitalen Nachricht der Identität des Senders und/oder der Unversehrtheit der Nachricht sicher sein kann.
  • Wenn ein Sender zum Beispiel eine Nachricht verschlüsselt, wird der öffentliche Schlüssel des Empfängers dazu verwendet, die Daten in der ursprünglichen Nachricht in den Inhalt der verschlüsselten Nachricht umzuwandeln. Ein Sender verwendet einen öffentlichen Schlüssel des vorgesehenen Empfängers, um Daten zu entschlüsseln, und der Empfänger verwendet seinen privaten Schlüssel, um die verschlüsselte Nachricht zu entschlüsseln.
  • Bei der Bestätigung der Echtheit von Daten können Daten signiert werden, indem auf der Grundlage der Daten unter Verwendung des privaten Schlüssels des Unterzeichners eine digitale Signatur berechnet wird. Sobald die Daten digital signiert wurden, können sie mit der Kennung des Unterzeichners und der Signatur, die als Nachweis dafür dient, dass die Daten von dem Unterzeichner stammen, gespeichert werden. Ein Unterzeichner verwendet seinen privaten Schlüssel, um Daten zu signieren, und ein Empfänger verwendet den öffentlichen Schlüssel des Unterzeichners, um die Echtheit der Signatur zu prüfen.
  • Ein Zertifikat ist ein digitales Dokument, das dafür bürgt, dass die Instanzen wie zum Beispiel eine einzelne Person, ein Rechnersystem, ein bestimmter Server, der auf diesem System läuft, usw. über die jeweilige Identität und den jeweiligen Schlüssel verfügen. Zertifikate werden von Zertifizierungsstellen ausgegeben. Eine Zertifizierungsstelle (certificate authority, CA) ist eine Instanz, gewöhnlich eine an einer Transaktion beteiligte vertrauenswürdige dritte Partei, die zuverlässig Zertifikate für andere Personen oder Instanzen signiert oder ausgibt. Die CA ist gewöhnlich in einer bestimmten Weise rechtlich dafür verantwortlich, dass sie sich für die Bindung zwischen einem öffentlichen Schlüssel und seinem Eigner verbürgt, die es einem ermöglichen, der Instanz, die ein Zertifikat signiert hat, zu vertrauen. Es gibt viele gewerbliche Zertifizierungsstellen; diese Stellen sind bei der Ausgabe des Zertifikats für den Nachweis der Identität einer Instanz und deren Eignerschaft an dem Schlüssel zuständig.
  • Wenn eine Zertifizierungsstelle ein Zertifikat für eine Instanz ausgibt, muss die Instanz einen öffentlichen Schlüssel und einige Informationen über die Instanz zur Verfügung stellen. Ein Software-Werkzeug wie zum Beispiel speziell ausgestattete Webbrowser können diese Informationen digital signieren und sie an die Zertifizierungsstelle senden. Die Zertifizierungsstelle kann ein gewerblich tätiges Unternehmen sein, das Dienste einer vertrauenswürdigen dritten Partei in Form der Zertifizierungsstelle bereitstellt. Die Zertifizierungsstelle erzeugt dann das Zertifikat und schickt es zurück. Das Zertifikat kann andere Informationen wie zum Beispiel eine Seriennummer und Datumsangaben enthalten, während derer das Zertifikat gültig ist. Ein Teil des Wertes, den eine Zertifizierungsstelle bietet, besteht darin, dass sie die Funktion eines neutralen und vertrauenswürdigen Bekanntmachungsdienstes übernimmt, der zum Teil auf den Prüfungsanforderungen der Zertifizierungsstellen beruht, die in ihren Certification Service Practices (CSP) veröffentlicht sind.
  • Eine CA erstellt ein neues digitales Zertifikat, indem sie den öffentlichen Schlüssel der anfordernden Instanz zusammen mit anderen der Identifikation dienenden Informationen in das Zertifikat einbettet und das digitale Zertifikat dann mit dem privaten Schlüssel der CA signiert. Jeder, der das digitale Zertifikat während einer Transaktion oder einer Datenaustauschoperation empfängt, kann dann den öffentlichen Schlüssel der CA zur Prüfung der Echtheit des zur Signierung verwendeten öffentlichen Schlüssels in dem Zertifikat verwenden. Beabsichtigt ist, dass die Signatur der CA als fälschungssicheres Siegel auf dem digitalen Zertifikat dient, wodurch die Unversehrtheit der Daten in dem Zertifikat gewährleistet wird.
  • Andere Aspekte der Verarbeitung von Zertifikaten werden ebenfalls standardisiert. Das Certificate Request Message Format (RFC 2511) legt ein Format fest, dessen Verwendung immer empfohlen wird, wenn ein Teilnehmer, der sich auf die Vertrauenswürdigkeit eines Zertifikats verlässt (relying party), ein Zertifikat von einer CA anfordert. Zertifikat-Verwaltungsprotokolle (Certificate Management Protocols) wurden zur Übertragung von Zertifikaten ebenfalls veröffentlicht. Eine bevorzugte Ausführungsform der vorliegenden Erfindung befindet sich in einem verteilten Datenverarbeitungssystem, das digitale Zertifikate verwendet; die Beschreibung der 2 und 3 vermittelt Hintergrundinformationen über typische Operationen, die digitale Zertifikate einschließen.
  • Nun Bezug nehmend auf 2 zeigt ein Blockschaubild eine typische Art und Weise, in der eine Person ein digitales Zertifikat erhält. Der Benutzer 202, der Operationen an irgendeiner Art eines Client-Rechners ausführt, hat zuvor ein aus einem öffentlichen Schlüssel und einem privaten Schlüssel bestehendes Schlüsselpaar abgerufen oder erzeugt, zum Beispiel den öffentlichen Schlüssel 204 des Benutzers und den privaten Schlüssel 206 des Benutzers. Der Benutzer 202 erzeugt eine Anforderung für ein Zertifikat 208, das den öffentlichen Schlüssel 204 des Benutzers enthält, und sendet die Anforderung an die Zertifizierungsstelle 210, die sich im Besitz des öffentlichen Schlüssels 212 der CA und des privaten Schlüssels 214 der CA befindet. Die Zertifizierungsstelle 210 prüft die Identität des Benutzers 202 in einer bestimmten Weise und erzeugt das digitale X.509-Zertifikat 216, das den öffentlichen Schlüssel 218 des Benutzers enthält. Das ganze Zertifikat wird mit dem privaten Schlüssel 214 der CA signiert; das Zertifikat enthält den öffentlichen Schlüssel des Benutzers, den zu dem Benutzer gehörenden Namen und andere Attribute. Der Benutzer 202 empfängt das neu erzeugte digitale Zertifikat 216, und der Benutzer 202 kann das digitale Zertifikat 216 dann bei Bedarf vorlegen, um an vertrauenswürdigen Transaktionen oder vertrauenswürdigen Datenaustauschoperationen teilzunehmen. Eine Instanz, die das digitale Zertifikat 216 vom Benutzer 202 empfängt, kann die Echtheit der Signatur der CA prüfen, indem sie den öffentlichen Schlüssel 212 der CA verwendet, der veröffentlicht wird und der Instanz zur Verfügung steht, die die Echtheit prüft.
  • Nun Bezug nehmend auf 3 zeigt ein Blockschaubild eine typische Art und Weise, in der eine Instanz ein digitales Zertifikat verwenden kann, dessen Echtheit gegenüber einem Datenverarbeitungssystem nachgewiesen werden muss. Der Benutzer 302 ist im Besitz des digitalen X.509-Zertifikats 304, das an eine Internet- oder Intranet-Anwendung 306 auf dem Host-System 308 übertragen wird; die Anwendung 306 umfasst X.509-Funktionalität zur Verarbeitung und Verwendung von digitalen Zertifikaten. Der Benutzer 302 signiert oder verschlüsselt Daten, die er an die Anwendung 306 sendet, mit seinem privaten Schlüssel.
  • Die Instanz, die das Zertifikat 304 empfängt, kann eine Anwendung, ein System, ein Teilsystem usw. sein. Das Zertifikat 304 enthält den Namen des Zertifikatinhabers oder eine Kennung des Zertifikatinhabers, die den Benutzer 302 gegenüber der Anwendung 306 ausweist, die einen Dienst irgendeiner Art für den Benutzer 302 ausführen kann. Die Instanz, die das Zertifikat 304 verwendet, prüft die Echtheit des Zertifikats, bevor sie es in Bezug auf die signierten oder verschlüsselten Daten vom Benutzer 302 verwendet.
  • Das Host-System 308 kann auch eine System-Registrierdatenbank 310 enthalten, die dazu dient, dem Benutzer 302 eine Berechtigung für den Zugriff auf Dienste und Ressourcen in dem System 308 zu erteilen, d.h., die Identität eines Benutzers mit Benutzerrechten in Einklang zu bringen. Beispielsweise hat ein System-Administrator die Identität eines Benutzers so konfiguriert, dass er zu einer bestimmten Sicherheitsgruppe gehört, und der Benutzer hat nur eingeschränkten Zugriff auf diejenigen Ressourcen, die so konfiguriert sind, dass sie der Sicherheitsgruppe als Ganzes zur Verfügung stehen. Verschiedene bekannte Verfahren zur Einführung eines Berechtigungzuweisungsschemas können in dem System zur Anwendung kommen.
  • Um die Echtheit eines digitalen Zertifikats ordnungsgemäß auf Gültigkeit zu prüfen beziehungsweise zu bestätigen, muss eine Anwendung prüfen, ob das Zertifikat widerrufen worden ist. Wenn die Zertifizierungsstelle das Zertifikat ausgibt, erzeugt sie eine eindeutige Seriennummer, anhand der das Zertifikat erkannt werden soll, und diese Seriennummer wird in dem Feld "Seriennummer ("Serial Numer") in einem X.509-Zertifikat gespeichert. Üblicherweise wird ein widerrufenes X.509-Zertifikat in einer Liste der widerrufenen Zertifikate (CRL) anhand der Seriennummer des Zertifikats erkannt; die Seriennummer eines widerrufenen Zertifikats erscheint in einer Liste der Seriennummern in der CRL.
  • Um festzustellen, ob das Zertifikat 304 immer noch gültig ist, ruft die Anwendung 306 eine Liste der widerrufenen Zertifikate aus der CRL-Datenablage 312 ab und prüft die CRL auf Gültigkeit. Die Anwendung 306 vergleicht die Seriennummer in dem Zertifikat 304 mit der Liste der Seriennummern in der abgerufenen CRL, und wenn es keine übereinstimmenden Seriennummern gibt, erklärt die Anwendung 306 das Zertifikat 304 für gültig. Wenn die CRL eine Seriennummer enthält, die mit einer anderen Seriennummer übereinstimmt, muss das Zertifikat 304 zurückgewiesen werden, und die Anwendung 306 kann geeignete Maßnahmen ergreifen, um die Anforderung des Benutzers für den Zugriff auf gesteuerte Ressourcen zurückzuweisen.
  • Während 3 ein allgemeines Verfahren zeigt, mittels dessen ein Client ein digitales Zertifikat für den Zugriff auf einen Server verwenden kann, zeigt 4 Einzelheiten der Übertragung von Informationen zwischen dem Client und dem Server, um einen sicheren Datenübertragungskontext aufzubauen, was mit Bezug auf 3 nicht beschrieben worden ist.
  • Nun Bezug nehmend auf 4 zeigt ein Datenflussdiagramm einen typischen Mechanismus, der der GSS-API entspricht und zum Aufbau eines sicheren Datenübertragungskontexts zwischen einem Client und einem Server dient. Der Prozess beginnt damit, dass der Client 402 das Zertifikat mit dem öffentlichem Schlüssel vom Server 404 anfordert (Schritt 406). Der Server verarbeitet die Anforderung und erzeugt eine Antwort (Schritt 408), die eine Kopie des Zertifikats des Servers mit dem öffentlichem Schlüssel enthält oder der Kopie beigefügt ist, und diese Kopie des Zertifikats wird an den anfordernden Client zurückgeschickt (Schritt 410).
  • Der Client prüft das Zertifikat des Servers mit dem öffentlichen Schlüssel auf Gültigkeit und erzeugt einen Sitzungsschlüssel (Schritt 412); der Sitzungsschlüssel ist vorzugsweise ein symmetrischer geheimer Schlüssel. Der Client sendet den Sitzungsschlüssel dann sicher an den Server (Schritt 414). Der Client kann den Sitzungsschlüssel beispielsweise mit dem öffentlichen Schlüssel des Servers verschlüsseln, der zuvor dem Zertifikat des Servers mit dem öffentlichen Schlüssel entnommen wurde. Der verschlüsselte Sitzungsschlüssel wird dann in eine Nachricht gestellt, die mit dem privaten Schlüssel des Client digital signiert wird. Der Server kann die Echtheit der digitalen Signatur auf der Nachricht mit dem öffentlichen Schlüssel des Client prüfen, um sicherzustellen, dass die Nachricht von dem Client erzeugt und signiert wurde, und der Sitzungsschlüssel kann nur vom Server entschlüsselt werden. Eine Beschreibung von anwendbaren Formaten für digitale Umschläge und digitale Signaturen findet sich in "PKCS #7: Cryptographic Message Syntax Standard", Version 1.5, RSA Laboratories Technical Note, 11/01/1993.
  • Der Server nimmt daraufhin den Sitzungsschlüssel an, zum Beispiel, nachdem er die Echtheit der digitalen Signatur des Client geprüft hat und den Sitzungsschlüssel entschlüsselt hat, und erzeugt dann eine sichere Antwort (Schritt 416), die an den Client zurückgeschickt wird (Schritt 418). Anschließend erzeugt und verschlüsselt der Client ein Client-Identitätsprüfungselement (Schritt 420) und sendet dieses sicher an den Server (Schritt 422). Nachdem er der empfangenen Nachricht das Client-Identitätsprüfungselement entnommen hat, bestätigt der Server die Identität des Client und erzeugt eine Antwort (Schritt 424), die sicher an den Client zurückgeschickt wird (Schritt 426). Der Client wertet die Nachricht anschließend aus, um festzustellen, ob die Identität des Client vom Server positiv geprüft wurde oder ob der Server die Anforderung auf Prüfung der Identität des Client zurückgewiesen hat (Schritt 428), und der Prozess wird beendet.
  • Wie vorstehend erwähnt wurde, zeigt 4 ein typisches Verfahren zum Aufbau eines sicheren Datenübertragungskontexts gemäß einem bekannten Mechanismus, der der GSS-API entspricht. Im Gegensatz dazu bezieht sich der vorliegende Ansatz auf einen verbesserten Mechanismus, der der GSS-API entspricht und auf einem öffentlichen Schlüssel beruht, um einen sicheren Datenübertragungskontext aufzubauen, wie hier nachstehend mit Bezug auf die restlichen Figuren beschrieben wird.
  • Nun Bezug nehmend auf 5 zeigt ein Datenflussdiagramm einen typischen Mechanismus, der der GSS-API entspricht, um einen sicheren Datenübertragungskontext zwischen einem Client und einem Server gemäß einer Ausführungsform der vorliegenden Erfindung aufzubauen. Der Prozess beginnt damit, dass der Client 502 eine Anforderung an den Server 504 sendet, um das Zertifikat des Servers mit dem öffentlichen Schlüssel zu erhalten (Schritt 506), zum Beispiel, wenn der Client versucht, eine Verbindung mit der Server-Anwendung herzustellen. Nach dem Empfang der Anforderung verarbeitet der Server die Anforderung und erzeugt eine Antwort (Schritt 508), die eine Kopie des Zertifikats des Servers mit dem öffentlichem Schlüssel enthält oder der Kopie beigefügt ist, und diese Antwort wird an den anfordernden Client zurückgeschickt (Schritt 510).
  • Nach dem Empfang des digitalen Zertifikats des Servers prüft der Client das Zertifikat des Servers mit dem öffentlichen Schlüssel auf Gültigkeit, um sicherzustellen, dass es von einer vertrauenswürdigen Zertifizierungsstelle signiert worden ist (Schritt 512). Es sei angemerkt, dass der Client erkennen kann, dass er zuvor eine Kopie dieses Zertifikats des Servers mit dem öffentlichen Schlüssel auf Gültigkeit geprüft und gespeichert hat, wodurch es dem Client möglich wurde, das Zertifikat des Servers durch Abruf aus einem lokalen Cachespeicher zu erhalten. Alternativ dazu kann das Zertifikat des Servers mit dem öffentlichen Schlüssel dem Client auf eine andere Weise bereitgestellt werden, zum Beispiel, indem der Client das Zertifikat des Servers mit dem öffentlichen Schlüssel aus einem Verzeichnis oder einem ähnlichen Datenspeicher abruft.
  • Unter der Annahme, dass das Zertifikat des Servers zuvor positiv auf Gültigkeit geprüft wurde, entnimmt der Client dem Zertifikat den öffentlichen Schlüssel des Servers und legt ihn im Cachespeicher ab. Der Client erzeugt dann zusammen mit einem Identitätsprüfungselement einen zufälligen symmetrischen geheimen Schlüssel (Schritt 514); dieser ganz bestimmte geheime Schlüssel wird hier als der Transportschlüssel bezeichnet. Das Identitätsprüfungselement kann ein aus Benutzername und Passwort bestehendes Paar, ein mit einem Zeitstempel versehenes sicheres Ticket von einem Hauptidentitätsprüfer, ein Zertifikat mit einem öffentlichen Schlüssel, das zu dem Client gehört, oder eine andere Information, mit der sich die Identität prüfen lässt, umfassen; der Client kann das Identitätsprüfungselement gegebenenfalls erzeugen, indem er lediglich ein Datenelement wie zum Beispiel ein sicheres Ticket kopiert.
  • Anschließend sendet der Client den Transportschlüssel und das Identitätsprüfungselement sicher an den Server (Schritt 516). Die Übertragung des Transportschlüssels und des Identitätsprüfungselements vom Client an den Server wird auf eine bestimmte Weise durch Verschlüsselung unter Verwendung des öffentlichen Schlüssels des Servers gesichert. Zum Beispiel können der Transportschlüssel und das Identitätsprüfungselement mit Hilfe des öffentlichen Schlüssels des Servers verschlüsselt werden, um einen digitalen Umschlag für die Nachricht zu erzeugen, die an den Server gesendet wird. Alternativ dazu können der Transportschlüssel und das Identitätsprüfungselement einzeln zur Einbindung in eine Nachricht an den Server verschlüsselt werden.
  • Nach dem Empfang der sicheren Nachricht von dem Client entschlüsselt der Server den digitalen Umschlag mit dem privaten Schlüssel des Servers. Der Server bestätigt dann die Identität des Client oder des Benutzers des Client (Schritt 518), wobei er von einem Prozess Gebrauch macht, der für die Art des Identitätsprüfungselements, das an den Server gesendet wurde, geeignet ist, d.h. auf der Grundlage der Art des Identitätsprüfungselements, das vom Client an den Server gesendet wurde. Beispielsweise kann der Server in einem LDAP nach einem aus Benutzernamen und Passwort bestehenden Paar nachschlagen oder ein sicheres Ticket, zum Beispiel ein Kerberos-Ticket, auf Gültigkeit prüfen. In dem Fall, in dem das Identitätsprüfungselement ein Zertifikat des Client ist, ist der Identitätsnachweis erreicht, wenn der Server mit einem zufälligen Sitzungsschlüssel antwortet, der mit dem öffentlichen Schlüssel des Client (einem digitalen Umschlag) verschlüsselt wird, den nur der legitime Client mit Hilfe des privaten Schlüssels entschlüsseln kann, welcher zu dem öffentlichen Schlüssel in dem Zertifikat des Client gehört; der digitale Umschlag wird noch mit dem Transportschlüssel verschlüsselt gesendet, den der Client an den Server sendet, um einen Angriff durch einen Unbekannten ("man in the middle attack") zu verhindern. Unter der Annahme, dass die Identität des Client nachgewiesen wurde, erzeugt der Server dann einen zufälligen symmetrischen geheimen Schlüssel (Schritt 520), der zur Sicherung von Nachrichten in dem zwischen dem Client und dem Server aufgebauten Datenübertragungskontext verwendet wird; dieser ganz bestimmte geheime Schlüssel wird hier als der Sitzungsschlüssel bezeichnet.
  • Der Server sendet dann den Sitzungsschlüssel sicher an den Client (Schritt 522). Die Übertragung des Sitzungsschlüssels vom Server an den Client wird auf eine bestimmte Weise durch Verschlüsselung unter Verwendung des Transportschlüssels sichergestellt. Der Server kann den Sitzungsschlüssel zum Beispiel in ein Sitzungssymbol (session token) stellen, das der Server mit dem Transportschlüssel verschlüsselt; anschließend kann der Server das verschlüsselte Sitzungssymbol in eine Nachricht stellen, die der Server mit dem öffentlichen Schlüssel des Client versiegelt, und daraufhin verschlüsselt er den resultierenden Umschlag mit dem Transportschlüssel. Alternativ dazu kann der Server den Transportschlüssel verwenden, um den Sitzungsschlüssel einzeln zu verschlüsseln, bevor er den verschlüsselten Sitzungsschlüssel in eine Nachricht stellt, die an den Client gesendet werden soll. Als ein weiteres Beispiel für die Erzeugung einer sicheren Nachricht kann der Server den Transportschlüssel zur Erzeugung eines digitalen Umschlags für eine Nachricht verwenden, die den Sitzungsschlüssel enthält.
  • Nach dem Empfang der Nachricht verwendet der Client den Transportschlüssel, um den entsprechenden Teil der Nachricht zu entschlüsseln und um den Sitzungsschlüssel zu entnehmen (Schritt 524), wodurch der Prozess beendet wird. In Abhängigkeit von dem verwendeten Mechanismus zur Identitätsprüfung hat der Server die Nachricht gegebenenfalls in verschiedenen Formaten erzeugt; daher kann der Client den Sitzungsschlüssel direkt von einem Sitzungssymbol erhalten, oder er muss den Sitzungsschlüssel gegebenenfalls mit dem privaten Schlüssel des Client entschlüsseln, wenn der Server den öffentlichen Schlüssel des Client auch zur Verschlüsselung des Sitzungsschlüssels oder zur Verschlüsselung eines Teils der Nachricht verwendet hat, die den Sitzungsschlüssel enthält. Überdies können Nachrichten zwischen dem Client und dem Server eine Folgenummer enthalten, um sich gegen Angriffe durch Wiedereinspielung zu schützen.
  • Nachdem der Prozess abgeschlossen ist, sind sowohl der Client als auch der Server im Besitz einer Kopie des Sitzungsschlüssels, der anschließend zur Sicherung von zwischen dem Client und dem Server ausgetauschten Nachrichten verwendet werden kann, wodurch die Vertraulichkeit und die Unversehrtheit der Daten für den Datenübertragungskontext zwischen dem Client und dem Server zuverlässig sichergestellt wird. Der Client kann den Sitzungsschlüssel zum Beispiel verwenden, um Anforderungsnachrichten für den Zugriff auf Ressourcen, die vom Server gesteuert werden, sicher an den Server zu senden. Der Fachmann dürfte verstehen, dass der Sitzungsschlüssel für eine bestimmte Datenübertragungssitzung zwischen dem Client und dem Server verwendet werden kann, dass die bestimmte Datenübertragungssitzung zwischen dem Client und dem Server gleichzeitig mit anderen sicheren Datenübertragungssitzungen zwischen dem Client und dem Server und/oder anderen Servern im Rahmen von sicheren Kontexten, die von dem GSS-API-konformen Mechanismus einer bevorzugten Ausführungsform der vorliegenden Erfindung bereitgestellt werden, oder im Rahmen von sicheren Kontexten, die von einem anderen Mechanismus bereitgestellt werden, stattfinden kann und dass die bestimmte Datenübertragungssitzung beendet werden kann, während diese gleichzeitig stattfindenden Sitzungen fortgesetzt werden können.
  • Die Vorteile dieses Ansatzes dürften in Anbetracht der vorstehenden ausführlichen Beschreibung offensichtlich sein. Verglichen mit GSS-API-konformen Mechanismen nach dem Stand der Technik zum Aufbau eines sicheren Datenübertragungskontexts bieten bevorzugte Ausführungsformen der vorliegenden Erfindung die Möglichkeit, einen aus Benutzernamen und Passwort bestehenden Typ der Client-Server-Identitätsprüfungsoperation nach Bedarf auf eine vollständige Lösung mit einer auf einem öffentlichen Schlüssel beruhenden Infrastruktur (public-key infrastructure, PKI) zu erweitern, während dieselben einer GSS-API entsprechenden Mechanismen wie die zuvor ausgeführte, aus Benutzernamen und Passwort bestehende Lösung weiterhin verwendet werden können. Überdies ermöglicht die bevorzugte Ausführungsform der vorliegenden Erfindung einem Client, seine Identität mit Hilfe eines Zertifikats mit einem öffentlichen Schlüssel nachzuweisen, was bei LIPKEY nicht möglich ist. Darüber hinaus gestattet die bevorzugte Ausführungsform der vorliegenden Erfindung die Nutzung von vielen verschiedenen Client-Identitätsprüfungsmechanismen wie zum Beispiel ein aus Benutzername und Passwort bestehendes Paar, ein sicheres Ticket oder ein Zertifikat mit öffentlichem Schlüssel, was SPKM nicht unterstützt. Ferner setzt die bevorzugte Ausführungsform der vorliegenden Erfindung den Netzwerkverkehr und kryptographische Operationen im Vergleich zu LIPKEY auf ein Mindestmaß herab, beispielsweise werden statt der sechs Nachrichten, die bei LIPKEY ausgetauscht werden, nur vier Nachrichten zwischen einem Client und einem Server ausgetauscht.
  • Es sei unbedingt angemerkt, dass eine bevorzugte Ausführungsform der vorliegenden Erfindung zwar im Zusammenhang mit einem uneingeschränkt funktionsfähigen Datenverarbeitungssystem beschrieben wurde, der Fachmann jedoch verstehen wird, dass die Prozesse der bevorzugten Ausführungsform der vorliegenden Erfindung in Form von Befehlen in einem rechnerlesbaren Medium und einer Vielzahl anderer Formen verteilt werden können, ungeachtet der jeweiligen Art des Signal tragenden Mediums, das zur Durchführung der Verteilung tatsächlich verwendet wird. Zu Beispielen für rechnerlesbare Medien gehören Medien wie EPROMs, ROMs, Bänder, Papier, Disketten, Plattenlaufwerke, RAMs und CD-ROMs sowie Medien vom Übertragungstyp wie digitale und analoge Datenübertragungsverbindungen.
  • Unter einem Verfahren wird allgemein eine selbstkonsistente Folge von Schritten verstanden, die zu einem gewünschten Ergebnis führt. Diese Schritte setzen die physische Verarbeitung von physikalischen Größen voraus. Gewöhnlich, jedoch nicht zwingend vorgeschrieben, können diese Größen die Form von elektrischen oder magnetischen Signalen annehmen, die gespeichert, übertragen, kombiniert, verglichen und in anderer Weise verarbeitet werden können. Hauptsächlich, weil es allgemein üblich ist, werden diese Signale der Einfachheit halber zuweilen als Bits, Werte, Parameter, Gegenstände, Elemente, Objekte, Symbole, Zeichen, Begriffe, Zahlen oder dergleichen bezeichnet. Es sei jedoch angemerkt, dass all diese und ähnliche Begriffe den entsprechenden physikalischen Größen zuzuordnen sind und es sich dabei lediglich um praktische Bezeichnungen handelt, die auf diese Größen angewandt werden.
  • Die Beschreibung von bevorzugten Ausführungsformen der vorliegenden Erfindung erfolgte zum Zweck der Veranschaulichung, und sie erhebt weder Anspruch auf Vollständigkeit noch ist sie als auf die beschriebenen Ausführungsformen beschränkt zu verstehen. Der Fachmann erkennt, dass viele Ab- und Veränderungen möglich sind.

Claims (6)

  1. Verfahren zum Aufbau eines sicheren Kontexts zum Austausch von Nachrichten zwischen einem ersten System (504) und einem zweiten System (502), wobei das Verfahren Folgendes umfasst: Abrufen (510) eines ersten Zertifikats mit öffentlichem Schlüssel des ersten Systems durch das zweite System, wobei das zweite System das erste Zertifikat mit öffentlichem Schlüssel, das einen öffentlichen Schlüssel enthält, auf Gültigkeit prüft (512); dadurch gekennzeichnet, dass von dem zweiten System ein Transportschlüssel erzeugt wird, wobei der Transportschlüssel ein symmetrischer geheimer Schlüssel ist; der Transportschlüssel und ein Identitätsprüfungselement (authentication token) von dem zweiten System in eine erste Nachricht gestellt werden, die mit dem öffentlichen Schlüssel gesichert wird; die erste Nachricht von dem zweiten System an das erste System gesendet wird (516); als Reaktion auf das Senden der ersten Nachricht an das erste System an dem zweiten System eine zweite Nachricht von dem ersten System empfangen wird (522), die mit dem Transportschlüssel gesichert ist; der zweiten Nachricht von dem zweiten System ein Sitzungsschlüssel entnommen wird, wobei der Sitzungsschlüssel ein symmetrischer geheimer Schlüssel ist; der Sitzungsschlüssel zur Sicherung nachfolgender Nachrichten, die von dem zweiten System an das erste System gesendet werden, verwendet wird, wobei das Identitätsprüfungselement ein zweites Zertifikat mit öffentlichem Schlüssel des zweiten Systems umfasst und wobei das erste System das zweite Zertifikat mit öffentlichem Schlüssel auf Gültigkeit prüfen (518) kann und wobei das Verfahren des Weiteren die Entschlüsselung eines digitalen Umschlags in der zweiten Nachricht, die den Sitzungsschlüssel enthält, durch das zweite System unter Verwendung eines privaten Schlüssels, der zu dem zweiten Zertifikat mit öffentlichem Schlüssel gehört, umfasst, wobei der digitale Umschlag von dem ersten System unter Verwendung eines öffentlichen Schlüssels erzeugt wird, der in dem zweiten Zertifikat mit öffentlichem Schlüssel enthalten ist.
  2. Verfahren zum Aufbau eines sicheren Kontexts zum Austausch von Nachrichten zwischen einem ersten System (504) und einem zweiten System (502), wobei das Verfahren Folgendes umfasst: Bereitstellen (510) eines dem ersten System zugehörigen Zertifikats mit öffentlichem Schlüssel durch das erste System, wobei das zweite System das Zertifikat mit öffentlichem Schlüssel auf Gültigkeit prüfen kann; dadurch gekennzeichnet, dass an dem ersten System eine erste Nachricht von dem zweiten System empfangen wird (516), wobei die erste Nachricht mit einem öffentlichen Schlüssel von dem Zertifikat mit öffentlichem Schlüssel gesichert ist, das zu dem ersten System gehört, wobei die erste Nachricht einen Transportschlüssel und ein Identitätsprüfungselement enthält und wobei der Transportschlüssel ein symmetrischer geheimer Schlüssel ist; die Identität des zweiten Systems von dem ersten System auf der Grundlage des Identitätsprüfungselements nachgewiesen wird (518); von dem ersten System ein Sitzungsschlüssel erzeugt wird (516), wobei der Sitzungsschlüssel ein symmetrischer geheimer Schlüssel ist; der Sitzungsschlüssels von dem ersten System in eine zweite Nachricht gestellt wird, die mit dem Transportschlüssel gesichert wird; die zweite Nachricht von dem ersten System an das zweite System als Reaktion auf den Empfang der ersten Nachricht gesendet wird (522); und nachfolgende Nachrichten, die mit dem Sitzungsschlüssel gesichert werden, von dem zweiten System an dem ersten System empfangen werden, wobei das Identitätsprüfungselement ein Zertifikat mit öffentlichem Schlüssel umfasst, das zu dem zweiten System gehört, und wobei das Verfahren des Weiteren das Erzeugen eines digitalen Umschlags in der zweiten Nachricht, die den Sitzungsschlüssel enthält, durch das erste System unter Verwendung eines öffentlichen Schlüssels umfasst, der in dem Zertifikat mit öffentlichem Schlüssel enthalten ist, welches zu dem zweiten System gehört.
  3. Rechnerprogrammprodukt, das Rechnerprogrammcode umfasst, der, wenn er auf einem Datenverarbeitungssystem ausgeführt wird, das Datenverarbeitungssystem anweist, das Verfahren nach Anspruch 1 auszuführen.
  4. Rechnerprogrammprodukt, das Rechnerprogrammcode umfasst, der, wenn er auf einem Datenverarbeitungssystem ausgeführt wird, das Datenverarbeitungssystem anweist, das Verfahren nach Anspruch 2 auszuführen.
  5. Vorrichtung zum Aufbau eines sicheren Kontexts zum Austausch von Nachrichten zwischen einem ersten System und einem zweiten System, wobei die Vorrichtung folgendes umfasst: ein Mittel, um durch das zweite System ein erstes Zertifikat mit öffentlichem Schlüssel des ersten Systems abzurufen, wobei das zweite System das erste Zertifikat mit öffentlichem Schlüssel, das einen öffentlichen Schlüssel enthält, auf Gültigkeit prüfen kann; gekennzeichnet durch ein Mittel, um durch das zweite System einen Transportschlüssel zu erzeugen, wobei der Transportschlüssel ein symmetrischer geheimer Schlüssel ist; ein Mittel, um den Transportschlüssel und ein Identitätsprüfungselement durch das zweite System in eine erste Nachricht zu stellen, die mit dem öffentlichen Schlüssel gesichert wird; ein Mittel, um die erste Nachricht von dem zweiten System an das erste System zu senden; ein Mittel, um als Reaktion auf das Senden der ersten Nachricht an das erste System an dem zweiten System eine zweite Nachricht von dem ersten System zu empfangen, die mit dem Transportschlüssel gesichert ist; ein Mittel, um der zweiten Nachricht durch das zweite System einen Sitzungsschlüssel zu entnehmen, wobei der Sitzungsschlüssel ein symmetrischer geheimer Schlüssel ist; ein Mittel, um den Sitzungsschlüssel zur Sicherung von nachfolgenden Nachrichten zu verwenden, die von dem zweiten System an das erste System gesendet werden, wobei das Identitätsprüfungselement ein zweites Zertifikat mit öffentlichem Schlüssel des zweiten Systems umfasst und wobei das erste System das zweite Zertifikat mit öffentlichem Schlüssel auf Gültigkeit prüfen kann und wobei die Vorrichtung des Weiteren ein Mittel umfasst, um einen digitalen Umschlag in der zweiten Nachricht, die den Sitzungsschlüssel enthält, durch das zweite System unter Verwendung eines privaten Schlüssels zu entschlüsseln, der zu dem zweiten Zertifikat mit dem öffentlichen Schlüssel gehört, wobei der digitale Umschlag von dem ersten System unter Verwendung eines öffentlichen Schlüssels erzeugt wurde, der in dem zweiten Zertifikat mit öffentlichen Schlüssel enthalten ist.
  6. Vorrichtung zum Aufbau eines sicheren Kontexts zum Austausch von Nachrichten zwischen einem ersten System und einem zweiten System, wobei die Vorrichtung folgendes umfasst: ein Mittel, um durch das erste System ein Zertifikat mit öffentlichem Schlüssel bereitzustellen, das zu dem ersten System gehört, wobei das zweite System das Zertifikat mit öffentlichen Schlüssel auf Gültigkeit prüfen kann; gekennzeichnet durch ein Mittel, um an dem ersten System eine erste Nachricht von dem zweiten System zu empfangen, wobei die erste Nachricht mit einem öffentlichen Schlüssel von dem Zertifikat mit öffentlichen Schlüssel gesichert ist, das zu dem ersten System gehört, wobei die erste Nachricht einen Transportschlüssel und ein Identitätsprüfungselement enthält und wobei der Transportschlüssel ein symmetrischer geheimer Schlüssel ist; ein Mittel, um die Identität des zweiten Systems durch das erste System auf der Grundlage des Identitätsprüfungselements nachzuweisen; ein Mittel, um durch das erste System einen Sitzungsschlüssel zu erzeugen, wobei der Sitzungsschlüssel ein symmetrischer geheimer Schlüssel ist; ein Mittel, um den Sitzungsschlüssel durch das erste System in eine zweite Nachricht zu stellen, die mit dem Transportschlüssel gesichert wird; ein Mittel, um die zweite Nachricht als Reaktion auf den Empfang der ersten Nachricht von dem ersten System an das zweite System zu senden; und ein Mittel, um an dem ersten System von dem zweiten System nachfolgende Nachrichten zu empfangen, die mit dem Sitzungsschlüssel gesichert sind, wobei das Identitätsprüfungselement ein Zertifikat mit öffentlichem Schlüssel umfasst, das zu dem zweiten System gehört, und wobei die Vorrichtung des Weiteren ein Mittel zum Erzeugen eines digitalen Umschlags in der zweiten Nachricht, die den Sitzungsschlüssel enthält, durch das erste System unter Verwendung eines öffentlichen Schlüssels umfasst, der in dem Zertifikat mit öffentlichem Schlüssel enthalten ist, das zu dem zweiten System gehört.
DE602005001613T 2004-01-08 2005-01-05 Einrichten eines sicheren kontexts zur übermittlung von nachrichten zwischen computersystemen Active DE602005001613T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US753842 2004-01-08
US10/753,842 US20050154889A1 (en) 2004-01-08 2004-01-08 Method and system for a flexible lightweight public-key-based mechanism for the GSS protocol
PCT/EP2005/050032 WO2005069531A1 (en) 2004-01-08 2005-01-05 Establishing a secure context for communicating messages between computer systems

Publications (2)

Publication Number Publication Date
DE602005001613D1 DE602005001613D1 (de) 2007-08-23
DE602005001613T2 true DE602005001613T2 (de) 2008-04-10

Family

ID=34739273

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602005001613T Active DE602005001613T2 (de) 2004-01-08 2005-01-05 Einrichten eines sicheren kontexts zur übermittlung von nachrichten zwischen computersystemen

Country Status (8)

Country Link
US (1) US20050154889A1 (de)
EP (1) EP1714422B1 (de)
JP (1) JP4600851B2 (de)
KR (1) KR100992356B1 (de)
CN (1) CN100574184C (de)
AT (1) ATE367025T1 (de)
DE (1) DE602005001613T2 (de)
WO (1) WO2005069531A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009050936B4 (de) 2008-10-31 2018-06-28 GM Global Technology Operations LLC (n. d. Ges. d. Staates Delaware) Vorrichtung und Verfahren zum Bereitstellen einer ortsbasierten Sicherheit für eine Kommunikation mit einer entfernten Einrichtung
DE102008019627B4 (de) 2008-04-18 2022-03-17 Samedi Gmbh System und Verfahren zur sicheren Speicherung und Freigabe von Applikationsdaten

Families Citing this family (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9794237B2 (en) * 2005-01-31 2017-10-17 Unisys Corporation Secured networks and endpoints applying internet protocol security
US7743254B2 (en) * 2005-03-23 2010-06-22 Microsoft Corporation Visualization of trust in an address bar
US7725930B2 (en) * 2005-03-30 2010-05-25 Microsoft Corporation Validating the origin of web content
JP4755472B2 (ja) * 2005-09-29 2011-08-24 ヒタチグローバルストレージテクノロジーズネザーランドビーブイ データ転送方法及びシステム
US7587045B2 (en) * 2005-10-03 2009-09-08 Kabushiki Kaisha Toshiba System and method for securing document transmittal
US8108677B2 (en) * 2006-10-19 2012-01-31 Alcatel Lucent Method and apparatus for authentication of session packets for resource and admission control functions (RACF)
ATE552685T1 (de) * 2006-11-15 2012-04-15 Research In Motion Ltd Sicheres, auf kundenberechtigungsnachweis basierendes sitzungsauthentifizierungsverfahren und vorrichtung
ATE427617T1 (de) * 2006-11-22 2009-04-15 Research In Motion Ltd System und verfahren fur ein sicheres aufzeichnungsprotokoll unter verwendung von gemeinsam genutzten kenntnissen von mobilteilnehmerberechtigungsnachweisen
US8285989B2 (en) * 2006-12-18 2012-10-09 Apple Inc. Establishing a secured communication session
US8364975B2 (en) * 2006-12-29 2013-01-29 Intel Corporation Methods and apparatus for protecting data
US20080167888A1 (en) * 2007-01-09 2008-07-10 I4 Commerce Inc. Method and system for identification verification between at least a pair of entities
US7899188B2 (en) 2007-05-31 2011-03-01 Motorola Mobility, Inc. Method and system to authenticate a peer in a peer-to-peer network
US8528058B2 (en) 2007-05-31 2013-09-03 Microsoft Corporation Native use of web service protocols and claims in server authentication
CN101340281B (zh) * 2007-07-02 2010-12-22 联想(北京)有限公司 针对在网络上进行安全登录输入的方法和系统
KR101351110B1 (ko) * 2007-08-24 2014-01-16 한국과학기술원 통신 시스템에서 암호화된 데이터 송수신 장치 및 방법
KR100981419B1 (ko) * 2008-01-31 2010-09-10 주식회사 팬택 디지털 권한 관리를 위한 사용자 도메인 가입방법 및 그정보 교환 방법
CA2621147C (en) * 2008-02-15 2013-10-08 Connotech Experts-Conseils Inc. Method of bootstrapping an authenticated data session configuration
US8443431B2 (en) * 2009-10-30 2013-05-14 Alcatel Lucent Authenticator relocation method for WiMAX system
JP6014585B2 (ja) * 2010-05-19 2016-10-25 コーニンクレッカ フィリップス エヌ ヴェＫｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ． 属性ベースのデジタル署名システム
CN102348201B (zh) * 2010-08-05 2014-02-19 华为技术有限公司 获取安全上下文的方法和装置
US8769299B1 (en) 2010-10-13 2014-07-01 The Boeing Company License utilization management system license wrapper
US9563751B1 (en) 2010-10-13 2017-02-07 The Boeing Company License utilization management system service suite
US8522035B2 (en) * 2011-09-20 2013-08-27 Blackberry Limited Assisted certificate enrollment
CN103095662B (zh) * 2011-11-04 2016-08-03 阿里巴巴集团控股有限公司 一种网上交易安全认证方法及网上交易安全认证系统
US9397980B1 (en) * 2013-03-15 2016-07-19 Microstrategy Incorporated Credential management
CA2919106C (en) * 2013-07-23 2018-07-17 Ericsson Ab Media client device authentication using hardware root of trust
CA3189251A1 (en) * 2014-01-31 2015-08-06 Cryptometry Canada Inc. System and method for performing secure communications
JP2015192377A (ja) * 2014-03-28 2015-11-02 富士通株式会社 鍵送信方法、鍵送信システム、及び鍵送信プログラム
WO2016054149A1 (en) * 2014-09-30 2016-04-07 Citrix Systems, Inc. Fast smart card logon and federated full domain logon
US10129031B2 (en) * 2014-10-31 2018-11-13 Convida Wireless, Llc End-to-end service layer authentication
US9735970B1 (en) * 2014-11-24 2017-08-15 Veewear Ltd. Techniques for secure voice communication
WO2016149355A1 (en) 2015-03-16 2016-09-22 Convida Wireless, Llc End-to-end authentication at the service layer using public keying mechanisms
WO2016164496A1 (en) * 2015-04-06 2016-10-13 Bitmark, Inc. System and method for decentralized title recordation and authentication
EP3113501A1 (de) * 2015-06-29 2017-01-04 Nagravision SA Inhaltsschutz
CA2990651A1 (en) * 2015-06-30 2017-01-05 Visa International Service Association Confidential authentication and provisioning
EP4221258A1 (de) * 2015-07-02 2023-08-02 GN Hearing A/S Hörgerät und verfahren zur aktualisierung eines hörgeräts
US10104522B2 (en) 2015-07-02 2018-10-16 Gn Hearing A/S Hearing device and method of hearing device communication
DK201570433A1 (en) 2015-07-02 2017-01-30 Gn Hearing As Hearing device with model control and associated methods
US10318720B2 (en) 2015-07-02 2019-06-11 Gn Hearing A/S Hearing device with communication logging and related method
US9887848B2 (en) 2015-07-02 2018-02-06 Gn Hearing A/S Client device with certificate and related method
US10158953B2 (en) 2015-07-02 2018-12-18 Gn Hearing A/S Hearing device and method of updating a hearing device
US9877123B2 (en) 2015-07-02 2018-01-23 Gn Hearing A/S Method of manufacturing a hearing device and hearing device with certificate
US10158955B2 (en) 2015-07-02 2018-12-18 Gn Hearing A/S Rights management in a hearing device
US11070380B2 (en) 2015-10-02 2021-07-20 Samsung Electronics Co., Ltd. Authentication apparatus based on public key cryptosystem, mobile device having the same and authentication method
US10467421B2 (en) * 2015-10-23 2019-11-05 Oracle International Corporation Establishing trust between containers
US9832024B2 (en) 2015-11-13 2017-11-28 Visa International Service Association Methods and systems for PKI-based authentication
US9769142B2 (en) * 2015-11-16 2017-09-19 Mastercard International Incorporated Systems and methods for authenticating network messages
US9876783B2 (en) * 2015-12-22 2018-01-23 International Business Machines Corporation Distributed password verification
GB2547025A (en) 2016-02-05 2017-08-09 Thales Holdings Uk Plc A method of data transfer, a method of controlling use of data and a cryptographic device
CN105791301B (zh) * 2016-03-24 2019-04-30 杭州安恒信息技术股份有限公司 一种面向多用户组群信密分离的密钥分发管理方法
WO2018010957A1 (en) * 2016-07-12 2018-01-18 Deutsche Telekom Ag Method for providing an enhanced level of authentication related to a secure software client application provided by an application distribution entity in order to be transmitted to a client computing device; system, application distribution entity, software client application, and client computing device for providing an enhanced level of authentication related to a secure software client application, program and computer program product
US10348713B2 (en) 2016-09-16 2019-07-09 Oracle International Corporation Pluggable authentication for enterprise web application
CN107392591B (zh) * 2017-08-31 2020-02-07 恒宝股份有限公司 行业卡的在线充值方法、系统及蓝牙读写装置
CN109962767A (zh) * 2017-12-25 2019-07-02 航天信息股份有限公司 一种安全通信方法
EP3506560A1 (de) * 2017-12-29 2019-07-03 Nagravision S.A. Sichere bereitstellung von schlüsseln
US11546310B2 (en) 2018-01-26 2023-01-03 Sensus Spectrum, Llc Apparatus, methods and articles of manufacture for messaging using message level security
CN110166227B (zh) * 2018-02-12 2024-03-26 开利公司 与非联网控制器的无线通信
CN112019647A (zh) 2018-02-12 2020-12-01 华为技术有限公司 一种获得设备标识的方法及装置
CN108390885B (zh) * 2018-03-01 2020-08-07 北京华为数字技术有限公司 一种获得设备标识的方法、通信实体、通信系统及存储介质
US11159333B2 (en) * 2018-06-25 2021-10-26 Auth9, Inc. Method, computer program product and apparatus for creating, registering, and verifying digitally sealed assets
US11777744B2 (en) * 2018-06-25 2023-10-03 Auth9, Inc. Method, computer program product and apparatus for creating, registering, and verifying digitally sealed assets
WO2020160139A1 (en) * 2019-01-29 2020-08-06 Schneider Electric USA, Inc. Security context distribution service
US11805419B2 (en) * 2019-04-22 2023-10-31 Google Llc Automatically paired devices
US11469894B2 (en) * 2019-05-20 2022-10-11 Citrix Systems, Inc. Computing system and methods providing session access based upon authentication token with different authentication credentials
US11368444B2 (en) * 2019-09-05 2022-06-21 The Toronto-Dominion Bank Managing third-party access to confidential data using dynamically generated application-specific credentials
US11259082B2 (en) 2019-10-22 2022-02-22 Synamedia Limited Systems and methods for data processing, storage, and retrieval from a server
US11838413B2 (en) * 2019-10-22 2023-12-05 Synamedia Limited Content recognition systems and methods for encrypted data structures
CN111182004B (zh) * 2020-03-10 2022-01-04 核芯互联(北京)科技有限公司 Ssl握手方法、装置及设备
CN113299018A (zh) * 2021-06-22 2021-08-24 上海和数软件有限公司 一种atm的软件远程升级方法
CN113672898B (zh) * 2021-08-20 2023-12-22 济南浪潮数据技术有限公司 服务授权方法、授权设备、系统、电子设备及存储介质

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5265164A (en) * 1991-10-31 1993-11-23 International Business Machines Corporation Cryptographic facility environment backup/restore and replication in a public key cryptosystem
JPH1056447A (ja) * 1996-08-12 1998-02-24 Nippon Telegr & Teleph Corp <Ntt> 非対称ネットワークシステムによる情報暗号化提供方法
JP3595109B2 (ja) * 1997-05-28 2004-12-02 日本ユニシス株式会社 認証装置、端末装置、および、それら装置における認証方法、並びに、記憶媒体
US6307936B1 (en) * 1997-09-16 2001-10-23 Safenet, Inc. Cryptographic key management scheme
US6363154B1 (en) * 1998-10-28 2002-03-26 International Business Machines Corporation Decentralized systems methods and computer program products for sending secure messages among a group of nodes
US6874084B1 (en) * 2000-05-02 2005-03-29 International Business Machines Corporation Method and apparatus for establishing a secure communication connection between a java application and secure server
JP2002300150A (ja) * 2001-03-29 2002-10-11 Nippon Telegr & Teleph Corp <Ntt> Ｉｃカードの鍵生成方法及びシステム
JP2002344438A (ja) * 2001-05-14 2002-11-29 Nippon Telegr & Teleph Corp <Ntt> 鍵共有システム及び装置並びにプログラム
CN1191696C (zh) * 2002-11-06 2005-03-02 西安西电捷通无线网络通信有限公司 一种无线局域网移动设备安全接入及数据保密通信的方法
US20040250073A1 (en) * 2003-06-03 2004-12-09 Cukier Johnas I. Protocol for hybrid authenticated key establishment
US7155290B2 (en) * 2003-06-23 2006-12-26 Cardiac Pacemakers, Inc. Secure long-range telemetry for implantable medical device
US7568098B2 (en) * 2003-12-02 2009-07-28 Microsoft Corporation Systems and methods for enhancing security of communication over a public network

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008019627B4 (de) 2008-04-18 2022-03-17 Samedi Gmbh System und Verfahren zur sicheren Speicherung und Freigabe von Applikationsdaten
DE102009050936B4 (de) 2008-10-31 2018-06-28 GM Global Technology Operations LLC (n. d. Ges. d. Staates Delaware) Vorrichtung und Verfahren zum Bereitstellen einer ortsbasierten Sicherheit für eine Kommunikation mit einer entfernten Einrichtung

Also Published As

Publication number Publication date
JP4600851B2 (ja) 2010-12-22
ATE367025T1 (de) 2007-08-15
EP1714422A1 (de) 2006-10-25
EP1714422B1 (de) 2007-07-11
US20050154889A1 (en) 2005-07-14
CN1906886A (zh) 2007-01-31
CN100574184C (zh) 2009-12-23
KR20060123465A (ko) 2006-12-01
WO2005069531A1 (en) 2005-07-28
DE602005001613D1 (de) 2007-08-23
JP2007518324A (ja) 2007-07-05
KR100992356B1 (ko) 2010-11-04

Similar Documents

Publication Publication Date Title
DE602005001613T2 (de) Einrichten eines sicheren kontexts zur übermittlung von nachrichten zwischen computersystemen
DE112020004236B4 (de) Vorwärts gerichtete sicherheit in der transport layer security unter verwendung von ephemeren schlüsseln
DE60315914T2 (de) Ad hoc Sicherheitszugriff auf Dokumente und Dienste
EP1777907B1 (de) Vorrichtungen und Verfahren zum Durchführen von kryptographischen Operationen in einem Server-Client-Rechnernetzwerksystem
DE112011101729B4 (de) Verwaltung von Ressourcenzugriff
DE69835416T2 (de) Verfahren zur sicheren ausführung eines fernmeldebefehls
DE60308692T2 (de) Verfahren und system für benutzerbestimmte authentifizierung und einmalige anmeldung in einer föderalisierten umgebung
DE602004002140T2 (de) Universeller sicherer Datenaustausch für kryptographischen Modulen
DE60311036T2 (de) Verfahren zur Authentisierung potentieller Mitglieder eingeladen, eine Gruppe anzuschliessen
DE60307736T2 (de) Serverarchitektur für sichere Plug-ins in digitalen Rechteverwaltungsssystemen
DE60105326T2 (de) Infrastruktur für öffentliche Schlüssel
DE69433771T2 (de) Verfahren und Vorrichtung zur Geheimhaltung und Authentifizierung in einem mobilen drahtlosen Netz
EP2289222B1 (de) Verfahren, authentikationsserver und diensteserver zum authentifizieren eines client
DE60119857T2 (de) Verfahren und Vorrichtung zur Ausführung von gesicherten Transaktionen
WO2011131715A1 (de) Verfahren zum lesen eines attributs aus einem id-token
DE112012002741T5 (de) Identitäts- und Berechtigungsprüfungsverfahren für die Sicherheit einer Cloud-Datenverarbeitungsplattform
DE112008001436T5 (de) Sichere Kommunikation
DE102015214267A1 (de) Verfahren und System zum Erzeugen eines sicheren Kommunikationskanals für Endgeräte
DE112005001672T5 (de) Verfahren zum Liefern eines geheimen Direktnachweisschlüssels an Vorrichtungen unter Verwendung eines Onlinedienstes
DE112011102224B4 (de) Identitätsvermittlung zwischen Client- und Server-Anwendungen
DE602005003631T2 (de) Ausschluss der Passwortaufdeckung bei Attributzertifikatausgabe
DE112018001559T5 (de) Cachespeicherlose sitzungsticket-unterstützung bei tls-prüfung
WO2020143878A1 (de) Verfahren zum sicheren bereitstellen einer personalisierten elektronischen identität auf einem endgerät
DE60311328T2 (de) Verfahren und vorrichtung zur netzwerksicherheit
EP1468520B1 (de) Verfahren zur datenverkehrssicherung in einer mobilen netzumgebung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8320 Willingness to grant licences declared (paragraph 23)