DE60308099T2

DE60308099T2 - Gesicherter Schlüsselaustausch mit gegenseitigen Authentifizierung

Info

Publication number: DE60308099T2
Application number: DE60308099T
Authority: DE
Inventors: Dinarte R. Redmond Morais; Ling Tony Bellevue Chen; Damon V. Clyde Hill Danieli
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2002-06-10
Filing date: 2003-04-30
Publication date: 2006-12-21
Anticipated expiration: 2023-05-01
Also published as: DE60308099D1; US7565537B2; JP2004015813A; ATE339042T1; EP1372292B1; US20030229789A1; EP1372292A1

Description

Technischer Bereich
Diese Erfindung bezieht sich auf die Sicherheit und das Aufbauen gesicherter Netzwerkverbindungen und insbesondere auf einen gesicherten Schlüsselaustausch mit gegenseitiger Authentifikation.
Hintergrund
Üblicherweise waren Spielsysteme mit einer speziell angefertigten Konsole Einzelgeräte, die eine begrenzte Anzahl von Spielern aufnahmen (z. B. 2-4 Spieler). Auf PC basierendes Spielen wuchs in der Popularität teilweise infolge der Fähigkeit Spiele mit vielen entfernten Spielern über das Internet online zu spielen. Deshalb ist es ein Trend für speziell angefertigte Spielsysteme, Fähigkeiten bereitzustellen, die das Spielen über ein Netzwerk ermöglichen, wie ein auf dem Internet basierendes Online-Spielen.
Online-Spielen kann in einem Zentralserver-Ansatz oder in einem Peer-to-Peer-Ansatz implementiert werden. In dem Zentralserver-Ansatz sind Spielsysteme mit einem oder mehreren Zentralservern verbunden und kommunizieren miteinander über diese(n) Zentralserver. In dem Peer-to-Peer-Ansatz sind Spielsysteme miteinander verbunden und kommunizieren unmittelbar miteinander. Es kann jedoch auch bei dem Peer-to-Peer-Ansatz ein Zentralserver verwendet werden, um die Kommunikation zu unterstützen, wie z. B. mit einem Anfangs-Übereinstimmungs-Herstellungs-Dienst, um dabei zu helfen, dass die Spielsysteme einander finden.
Ein Problem auf das man bei der Verwendung solcher Zentralserver stößt, ist das Schützen des Netzwerkverkehrs zwischen den Servern und den Spielsystemen vor unbefugter Einmischung oder Beobachtung durch andere Geräte im Netzwerk. Spieler sind bekannt dafür, dass sie kreative Betrugsmechanismen entwickeln, die den Netzwerkverkehr zu einem reifen Angriffsziel für solche Anwender macht. Unglücklicherweise waren bisherige auf Konso len basierende Spielsysteme üblicherweise nicht für die gesicherte Kommunikation mit Zentralservern ausgestattet. Ein zusätzliches Problem liegt darin, dass ein Mechanismus, der verwendet wird, um den Netzwerkverkehr zu schützen, keinen bedeutenden Umfang an Ressourcen für Spielsysteme benötigen sollte, da er diese Ressourcen für die Spiele verwenden sollte, die gespielt werden. Der Mechanismus sollte auch keinen bedeutenden Umfang an Zentralserver-Ressourcen benötigen, um mehr Spielsysteme mit weniger Zentralservern verarbeiten zu können.
KRAWCZYK H: "SKEME: ein anpassungsfähiger gesicherter Schlüsselaustauschmechanismus für das Internet", NETWORK AND DISTRIBUTED SYSTEM SECURITY, 1996, PROCEEDINGS OF THE SYMPOSIUM ON SAN DIEGO; CA, USA, 22.-23. Februar 1996, LOS ALAMITOS, CA, USA IEEE COMPUT. SOC, US, 22. Februar 1996 bezieht sich auf ein gesichertes Schlüsselaustauschprotokoll für die Schlüsselverwaltung über das Internet. Das Protokoll unterstützt den Schlüsselaustausch basierend auf Schlüsselverteilungszentren und bietet wahlweise perfekte Vorwärtsgeheimhaltung. Es gibt drei Grundphasen in dem Protokoll: SHARE, EXCH und AUTH. Bei SHARE tauschen die Teilnehmer halbe Schlüssel aus, die untereinander durch öffentliche Schlüssel verschlüsselt sind, und dann werden die halben Schlüssel mittels einer Hash-Funktion kombiniert, um einen gemeinsamen Schlüssel zu erzeugen. Die nächste Phase EXCH wird verwendet, um Diffie-Hellman-Exponenten g^x mod p und g^y mod p auszutauschen. Die Authentifikation dieses Diffie-Hellman-Austauschs wird in der folgenden Phase AUTH ausgeführt, die den gemeinsamen Schlüssel der SHARE-Phase verwendet, um die Diffie-Hellman Exponenten zu authentifizieren. Der Sitzungsschlüssel, der der gemeinsame Schlüssel zwischen den Teilnehmern als ein Ergebnis des Protokolls ist, wird durch die Teilnehmer als eine Hash-Funktion des Diffie-Hellman-Exponenten g^xy mod p berechnet. Aus Gründen der Kommunikationsleistungsfähigkeit können die obigen Phasen in drei Nachrichten kombiniert werden.
EP 1 134 929 A bezieht sich auf ein gegenseitiges Netzwerk-Authentifikations-Protokoll, das nur durch ein Passwort gesichert ist. Üblicherweise sind die Teilnehmer ein Client-Computer und ein Server-Computer. Der Client wählt einen Zufallswert für einen Index x. Dann berechnet der Client einen Parameter m als m = g^x(H₁(A, B, π))^r mod p, wobei A ein eindeutiger Identifikator des Clients ist, B ist ein eindeutiger Identifikator des Servers, π ist das Client-Passwort für diesen bestimmten Server, H₁ ist eine Zufalls-Hash-Funktion, H₁(A, B, π) ist um r potenziert und g^x ist ein Diffie-Hellman-Wert. Der Client überträgt den Parameter m an den Server. Nach Empfang des Parameters m durch den Server überprüft der Server den Parameter-Wert, um zu gewährleisten, dass der Wert nicht 0 mod p ist. Wenn der Wert 0 mod p ist, beendet der Server das Protokoll. Andernfalls wählt der Server einen Zufallswert für einen Index x. Dann berechnet der Server einen Parameter μ als μ = g^y(H₂(A, B, π))^r mod p. Als Nächstes extrahiert der Server den Diffie-Hellman-Wert g^x und berechnet das Diffie-Hellman-Shared-Secret g^xy. Dann berechnet der Server einen Sitzungssehlüssel K als K = H₃(A, B, m, μ, σ, π), wobei σ das Diffie-Hellman-Shared-Secret g^xy ist Der Server überträgt dann den Parameter μ an den Client. Nach Empfang des Parameters μ überprüft der Client den Parameter-Wert μ, um zu gewährleisten, dass der Wert nicht 0 mod p ist. Wenn der Wert 0 mod p ist, beendet der Client das Protokoll. Andernfalls extrahiert der Client unter Verwendung des Wertes von μ den Diffie-Hellman-Wert g^y und berechnet das Diffie-Hellman-Shared-Secret g^xy. Dann berechnet der Client den Sitzungsschlüssel K als K = H₃(A, B, m, μ, σ, π).
MOLVA R. "Internet-Sicherheitsarchitektur" COMPUTER NETWORKS, ELSEVIER SCIENCE PUBLISHERS B. V., AMSTERDAM NL, Band 31, Nr. 8, 23. April 1999, Seiten 787-804 bezieht sich auf eine Internet-Sicherheitsarchitektur, in der ein Client unter Verwendung eines TLS-Protokolls eine Verbindung mit dem Server initiiert. Der Client und der Server führen das Protokoll aus, um Sicherheitsalgorithmen auszuhandeln, sich gegenseitig zu authentifizieren und gemeinsame Verschlüsselungsgeheimnisse aufzubauen. Das Ergebnis des Protokolls umfasst ein Hauptgeheimnis, von dem verschiedene Verschlüsselungs- und MAC-Schlüssel abgeleitet werden. Das Protokoll unterstützt die Schlüsselgenerierung mit Diffie-Hellman: der Server und der Client generieren einen Shared-Secret-Schlüssel unter Verwendung des Diffie-Hellman-Algorithmus und der gegenseitigen allgemeinen Diffie-Hellman-Komponente. Zunächst senden der Client und der Server sich gegenseitig eine Nachricht, die eine Zufallszahl enthält, und handeln die Gruppe von Attributen und Algorithmen aus, die bei der aktuellen Sitzung verwendet werden. Der Server kann auch sein Zertifikat senden, das seine allgemeine Diffie-Hellman-Komponente enthält. Zum Zweck des Schlüsselaustauschs kann der Server temporäre allgemeine Werte liefern, die mit dem Geheimschlüssel signiert sind, der zu dem allgemeinen Schlüssel passt, der in seinem Zertifikat enthalten ist. Die temporären Werte können eine allgemeine Diffie-Hellman-Komponente sein. Der Server zeigt das Ende seiner Antwort an, indem er eine ServerHalloErledigt-Nachricht sendet. Das erste IoErledigt-Nachricht sendet. Das erste Antwortnachricht-Zertifikat des Clients kann das allgemeine Schlüsselzertifikat des Clients enthalten. Das Nächste ist eine Schlüsselaustauschnachricht, die die allgemeine Diffie-Hellman-Komponente des Clients enthält. Zu diesem Zeitpunkt können der Client und der Server den gemeinsamen Vor-Hauptschlüssel (PMK) durch berechnen als Diffie-Hellman-Shared-Secret abrufen. Der Client kann dann eine ZertifikatsBestätigung-Nachricht senden, die seine Signatur in dem Hash-Wert von PMK enthält, die mit allen früher ausgetauschten Nachrichten in der aktuellen Sitzung kombiniert wird. Der Handshake-Ablauf schließt mit der Beendet-Nachricht ab, die bestätigt, dass der Schlüsselaustausch und die Authentifikation erfolgreich waren.
WO 00/48358 beschreibt ein Authentifikationsverfahren zur Authentifikation der Kommunikation zwischen einem ersten Teilnehmer und einem zweiten Teilnehmer, die einen dritten Teilnehmer verwenden, dem der erste Teilnehmer und der zweite Teilnehmer vertrauen. Der dritte Teilnehmer berechnet unter Verwendung von Parametern des ersten Teilnehmers den Wert einer ersten Authentifikationsausgabe und unter Verwendung der ersten Authentifikationsausgabe einer zweiten Authentifikationsausgabe. Die zweite Authentifikationsausgabe wird zu dem zweiten Teilnehmer gesendet. Der erste Teilnehmer berechnet die erste Authentifikationsausgabe und sendet die erste Authentifikationsausgabe zu dem zweiten Teilnehmer. Der zweiten Teilnehmer berechnet die zweite Authentifikationsausgabe, die auf der ersten Authentifikationsausgabe basiert, die von dem ersten Teilnehmer empfangen wurde, und vergleicht die berechnete zweite Authentifikationsausgabe mit der empfangenen zweiten Authentifikationsausgabe, die von dem zuverlässigen dritten Teilnehmer empfangen wurde. Wenn die zweiten Authentifikationsausgaben dieselben sind, ist dadurch der ersten Teilnehmer authentifiziert.
Übersicht
Hierin wird ein gesicherter Schlüsselaustausch mit gegenseitiger Authentifikation beschrieben.
Es ist das Ziel der vorliegenden Erfindung eine Wartezeit ebenso wie einen Bandbreiten-Mehraufwand beim Aufbau eines Schlüssels zwischen einem Clientgerät und einem Servergerät zu reduzieren und die Geräte gegenseitig zu authentifizieren.
Dieses Ziel wird erreicht durch die Erfindung, wie sie in den beigefügten Hauptansprüchen umgrenzt wird. In den Unteransprüchen werden Ausführungsformen vorgegeben.
Nach bestimmten Ausführungsformen wird ein Schlüsselaustausch mit einem Gerät im Netzwerk in einem einzelnen Hin- und Rückweg über das Netzwerk durchgeführt, wodurch sowohl die gegenseitige Authentifikation mit dem Gerät als auch die perfekte Vorwärtsgeheimhaltung erreicht werden.
Nach bestimmten Ausführungsformen wird ein Schlüsselaustausch-Initiatorpaket, das nicht den Schlüssel beinhaltet, der aufgebaut werden soll, über ein Netzwerk zu einem Gerät gesendet. Ein Schlüsselaustausch-Antwortpaket, das den Schlüssel ebenfalls nicht beinhaltet, wird von dem Gerät empfangen. Das Schlüsselaustausch-Antwortpaket wird validiert, und der Schlüssel wird, zumindest teilweise auf Daten in dem Schlüsselaustausch-Antwortpaket basierend, generiert, ohne dass zusätzliche Pakete zu dem Gerät gesendet oder von dem Gerät empfangen werden müssen, um den Schlüssel zu generieren.
Nach bestimmten Ausführungsformen wird ein Schlüsselaustausch-Initiatorpaket das keinen Schlüssel beinhaltet, der aufgebaut werden soll, über ein Netzwerk von einem Gerät empfangen und validiert. Der Schlüssel wird, zumindest teilweise auf Daten in den Schlüsselaustausch-Initiatorpaket basierend, generiert, ohne dass zusätzliche Pakete von dem Gerät empfangen werden müssen, um den Schlüssel zu generieren. Zusätzlich wird ein Schlüsselaustausch-Antwortpaket über das Netzwerk zu dem Gerät gesendet, das den Schlüssel nicht beinhaltet.
Kurze Beschreibung der Zeichnungen
Dieselben Zahlen werden durchweg in dem Dokument verwendet, um auf gleiche Komponenten und/oder Eigenschaften zu hinzuweisen.
1 ist ein Blockdiagramm, das eine beispielhafte Umgebung darstellt, in der der gesicherte Schlüsselaustausch mit gegenseitiger Authentifikation verwendet werden kann.
2 ist ein Ablaufdiagramm, das einen beispielhaften Ablauf zur Durchführung des gesicherten Schlüsselaustauschs mit gegenseitiger Authentifikation zwischen einem Client- und einem Servergerät darstellt.
3 ist ein Ablaufdiagramm, das einen beispielhaften Ablauf für das Generieren und Senden eines Schlüsselaustausch-Initiatorpakets darstellt.
4 ist ein Ablaufdiagramm, das einen beispielhaften Ablauf für das Empfangen und Validieren des Schlüsselaustausch-Initiatorpakets darstellt
5 ist ein Ablaufdiagramm, das einen beispielhaften Ablauf für das Generieren von kryptografischen Schlüsseln ebenso wie das Generieren und Senden eines Schlüsselaustausch-Antwortpakets darstellt.
6 ist ein Ablaufdiagramm, das einen beispielhaften Ablauf für das Empfangen und Validieren des Schlüsselaustausch-Antwortpakets und für das Generieren kryptografischer Schlüssel darstellt.
7 ist ein Blockdiagramm, das eine beispielhafte Online-Spiel-Umgebung darstellt, in der der gesicherte Schlüsselaustausch mit gegenseitiger Authentifikation verwendet werden kann.
8 stellt eine allgemeine Computerumgebung dar, die verwendet werden kann, um die hierin beschriebenen Techniken zu implementieren.
9 zeigt ausführlicher funktionelle Komponenten einer Spielkonsole, die verwendet werden können, um die hierin beschriebenen Techniken zu implementieren.
Ausführliche Beschreibung
Die folgende Erörterung richtet sich auf einen gesicherten Schlüsselaustausch-Mechanismus mit gegenseitiger Authentifikation für Netwerkgeräte. Die Erörterung geht davon aus, dass der Leser mit Kryptografie-Grundlagen, wie Verschlüsselung, Entschlüsselung, Authentifikation, Hashing und digitalen Signaturen, vertraut ist Für eine Grundlagen einführung in die Kryptografie wird der Leser an einen Text verwiesen, der geschrieben wurde von Bruce Schneider mit dem Titel „Angewandte Kryptografie: Protokolle, Algorithmen und Quellcode in C", veröffentlicht durch John Wiley & Söhne, Urheberrecht 1994 (zweite Ausgabe 1996).
1 ist ein Blockdiagramm, das eine beispielhafte Umgebung 100 darstellt, in der der gesicherte Schlüsselaustausch mit gegenseitiger Authentifikation verwendet werden kann. Ein Clientgerät 102 ist mit einem Schlüsselverteilungszentrum 104 und mir einem Servergerät 106 gekoppelt. Die Kopplung zwischen dem Gerät 102 und dem Schlüsselverteilungszentrum 104 kann eine beliebige Kopplung auf einer Vielzahl von Kopplungen sein, die eine Datenübertragung zwischen dem Gerät 102 und dem Zentrum 104 ermöglicht. In ähnlicher Weise kann die Kopplung zwischen den Geräten 102 und 106 eine beliebige Kopplung aus einer Vielzahl von Kopplungen sein, die eine Datenübertragung zwischen dem Gerät 102 und dem Gerät 106 ermöglicht. In einer Implementierung beinhalten die Kopplungen das Internet und können auch optional ein oder mehrere andere Netzwerke (z. B. ein lokales Netzwerk (LAN) und/oder ein Breitbereichsnetzwerk (WAN)) beinhalten.
Obwohl in 1 nur ein einzelnes Clientgerät 102, ein einzelnes Schlüsselverteilungszentrum 104 und ein einzelnes Servergerät 106 gezeigt werden, können mehrere solcher Gerte und Zentren in der Umgebung 100 enthalten sein. Zum Beispiel können mehrere Clientgeräte 102 mit einem oder mehreren Schlüsselverteilungszentren 104 und einem oder mehreren Servergeräten 106 kommunizieren.
Datenübertragungen zwischen dem Clientgerät 102 und dem Servergerät 106, ebenso wie Datenübertragungen zwischen dem Clientgerät 102 und dem Schlüsselverteilungszentrum 104 können in einem beliebigen Paketformat aus einer Vielzahl von verschiedenen Paketformaten erfolgen. In einer beispielhaften Implementierung erfolgen die Datenübertragungen in dem User Datagram Protocol(UDP)-Format.
Das Schlüsselverteilungszentrum 104 verteilt Schlüssel und Sicherheitstickets an das Clientgerät 102, das dann bei dem gesicherten Schlüsselaustausch mit dem Servergerät 106 verwendet werden kann. Das Servergerät 106 stellt Dienste bereit oder arbeitet als Gateway für andere (nicht in 1 gezeigte) Gerte, die Dienste für das Clientgerät 102 bereitstellen.
Das Clientgerät 102 kann ein Beliebiges aus einer breiten Vielzahl von Geräten sein. In einigen Erläuterungen hierin wird das Clientgerät 102 als eine Spielkonsole bezeichnet. Eine solche Spielkonsole kann eine speziell angefertigte Spielkonsole sein oder kann alternativ eine zusätzliche Funktionalität beinhalten. Zum Beispiel kann die Spielkonsole eine digitale Video-Aufzeichnungs-Funktionalität beinhalten, so dass sie als ein digitaler VCR arbeiten kann, die Spielkonsole kann eine Kanaleinstell-Funktionalität beinhalten, so dass sie Fernsehsignale (gleichgültig ob es Rundfunksignale, Kabelsignale, oder Satellitensignale etc. sind) einstellen und decodieren kann und so weiter. Das Clientgerät 102 kann auch eine andere Art von Rechnergerät sein, wie z. B. Desktop-PC, ein tragbarer Computer, ein Handy, eine Internetvorrichtung, ein Servercomputer etc.
In der Umgebung 100 ist ein gesicherter Schlüsselaustausch mit gegenseitiger Authentifikation zwischen dem Clientgerät 102 und dem Servergerät 106 erwünscht. Das ermöglicht den Geräten 102 und 106 sich gegenseitig zu authentifizieren, und ferner ermöglicht es, dass einer oder mehrere kryptografische Schlüssel aufgebaut werden und als eine Grundlage für die Geräte 102 und 106 verwendet werden, um gesichert miteinander über ein unsicheres Netzwerk (z. B. das Internet) zu kommunizieren.
Um den gesicherten Schlüsselaustausch mit gegenseitiger Authentifikation durchzuführen, wird von dem Schlüsselverteilungszentrum 104 ein Sicherheitsticket bezogen. In einer beispielhaften Implementierung ist das Sicherheitsticket ein Kerberos-Ticket, das von einem Clientgerät 102 bezogen wird, das ein kerberosähnliches Authentifikationsprotokoll verwendet, welches in einem einzigen Ticket die Identität des jeweiligen Clientgeräts 102 und die Identitäten eines oder mehrerer Anwender des Clientgeräts 102 authentifiziert. Das Clientgerät 102 bezieht das Kerberos-Ticket folgendermaßen.
Zu Erläuterungszwecken wird angenommen, dass das Clientgerät 102 eine Spielkonsole ist, und ferner wird angenommen, dass es vier Anwender der Spielkonsole gibt. Jedem Anwender werden eine Identität U₁, U₂, U₃, und U₄ und ein Anwenderschlüssel K₁, K₂, K₃, und K₄ zugewiesen. Der Spielkonsole wird auch ihre eigene Identität C und ein Spielkonsolenschlüssel K_C zugewiesen. Zusätzlich wird einem Spieltitel des Spiels, das auf der Spielkonsole gespielt wird, wie z. B. einer Spieldisk, eine gesonderte Identität G zugewiesen. In einer ähnlichen Weise wird dem Servergerät 106 seine eigens Identität A und ein Schlüssel K_A zugewiesen. Es sollte beachtet werden, dass die hierin beschriebene Authentifikation teil weise von den Schlüsseln K₁, K₂, K₃, und K₄, K_C und K_A abhängig ist. Deshalb sollten die Auswahl und die Speicherung dieser Schlüssel sorgfältig erfolgen, so dass nur die Einheiten, denen sie zugewiesen sind, in der Lage sind, sie zu verwenden.
Die Spielkonsole generiert basierend auf den Anwenderidentitäten U₁, U₂, U₃, und U₄ und ein Anwenderschlüsseln K₁, K₂, K₃, und K₄ validierte Anwenderidentitäten. Insbesondere beinhalten die validierten Anwenderidentitäten die Anwenderidentitäten und Werte, die von den Anwenderschlüsseln abgeleitet werden. Die validierten Anwenderidentitäten werden mit einer Abfrage an das Schlüsselverteilungszentrum 104 übermittelt und verwendet, um dem Schlüsselverteilungszentrum anzuzeigen, dass die Spielkonsole den Anwenderschlüssel kennt und somit die Anwender implizit authentifiziert.
Um die Beschreibung des Wegs der Berechnung der verschiedenen Nachrichten und Schlüssel zu vereinfachen, möchten wir die folgende Anmerkung einbringen:
H = H_Kx(M): H ist ein verschlüsselter Einweg-Hash-Code (MAC) der Nachricht M, die den Schlüssel K_X verwendet. Es kann ein beliebiger MAC-Algorithmus verwendet werden. Ein Beispiel eines solchen MAC-Algorithmus ist der HMAC-Algorithmus nach IETF RFC 2104.
Verschlüsseltes M = E_Kx(M): Verschlüsseltes M ist eine verschlüsselte Form der Nachricht M, die den Schlüssel K_X verwendet. Es kann ein beliebiger Verschlüsselungs-Algorithmus verwendet werden. Beispiele solcher Verschlüsselungs-Algorithmen beinhalten DES, Dreifach-DES und RC4-HMAC.
Ein Weg zur Generierung des schlüsselabgeleiteten Werts ist das Berechnen eines kryptografischen Hash-Codes des Anwenderschlüssels unter Verwendung des Schlüssels der Spielkonsole. Für den Anwender U₁ mit dem Schlüssel K₁ wird eine Hash-Code H₁ folgendermaßen berechnet: H1 = HKc(K1)
Der Hash-Code H₁ bildet den schlüsselabgeleiteten Werk Ein weiterer Weg besteht darin, unter Verwendung des Anwenderschlüssels K₁ die aktuelle Zeit folgendermaßen zu verschlüsseln: H1 = EK1(T)
Der sich ergebende Wert H₁ bildet erneut den schlüsselabgeleiteten Wert. Die validierte Anwenderidentität ist die Kombination von der Anwenderidentität U₁ und dem entsprechenden schlüsselabgeleiteten Wert H₁: Validierte Anwenderidentität = (U1, H1).
Die Spielkonsole erstellt eine Abfrage, die die Spielkonsolenidentität C, die Spieltitelidentität G, die Serveridentität A des Servergeräts 106 und mehrere validierte Anwenderidentitäten (U₁, H₁), (U₂, H₂), (U₃, H₃) und (U₄, H₄) enthält. Die Abtrage weist die folgende Identitäts-Zeichenfolge auf: Abfrage = (C, G, A (U1, H1), (U2, H2), (U3, H3) und (U4, H4)]
Zusätzlich kann die Abfrage eine Version des Authentifikationsprotokolls beinhalten und eine Zufalls-Nonce, die von der Spielkonsole generiert wird, um Replay-Attacken zu widerstehen. Die Abfrage kann ferner einen Prüfsummenwert beinhalten, der verwendet wird, um den Empfang der gesamten Identitäts-Zeichenfolge zu verifizieren. Die Spielkonsole sendet die Abfrage über die Kopplung zu dem Schlüsselverteilungszentrum 104.
Das Schlüsselverteilungszentrum 104 wertet die Abfrage ebenso wie die Identitäten, die in der Abfrage enthalten sind, aus. Das Schlüsselverteilungszentrum 104 generiert einen Zufalls-Sitzungsschlüssel, der für das Servergerät 106 verwendet wird. In diesem Beispiel generiert das Schlüsselverteilungszentrum einen Zufalls-Sitzungsschlüssel K_CA, der von der Spielkonsole 102 bei der Kommunikation mit dem Servergerät 106 benutzt wird. Dieser Zufalls-Sitzungsschlüssel K_CA wird hierin auch als der Kerberos-Sitzungsschlüssel bezeichnet.
Das Schlüsselverteilungszentrum generiert ein Ticket, das anschließend durch die Spielkonsole dem Servergerät 106 vorgelegt wird. Es wird ein Ticket für das Servergerät 106 ausgestellt, aber das Ticket ist für mehrere Anwender wirksam. Das Ticket enthält die Identitäts-Zeichenfolge, die in der Abfrage zugesendet wurde. Es enthält auch eine Zeit T_G, zu der das Ticket generiert wurde, eine Zeit T_L, die die Zeitdauer vor dem Ticketverfall bezeichnet und den zufällig generierten Kerberos-Sitzungsschlüssel K_CA für das Servergerät 106. Das Ticket kann optional auch eine Dienst-Übersichtkarte S_m enthalten, die den (die) Dienst(e) und/oder Dienstgeräte bezeichnet, die über das Servergerät 106 verfügbar sind, auf die die Anwender der Spielkonsole zugreifen dürfen. Das Schlüsselverteilungszentrum 104 hält eine Aufzeichnung aufrecht oder greift auf ein anderes Gerät oder Zentrum zu, das eine Aufzeichnung aufrechterhält, auf die die Anwender der jeweiligen Dienste zugreifen dürfen (z. B. die Anwender, die einen Aufpreis bezahlt haben, um auf einen oder mehrere Premium-Dienste zuzugreifen). Die Ticketinhalte sind durch einen symmetrischen Schlüsselcode (z. B. Dreifach-DES), der den Servergeräteschlüssel K_A verwendet, folgendermaßen verschlüsselt:
Man beachte, dass das Ticket die entsprechenden schlüsselabgeleiteten Werte H_i nicht überträgt. Sobald das Schlüsselverteilungszentrum die schlüsselabgeleiteten Werte liest und glaubt, dass die Spielkonsole die Anwenderschlüssel kennt, platziert das Schlüsselverteilungszentrum die Identitäten der Anwender innerhalb der ausgefertigten Tickets. Das Servergerät 106 glaubt anschließend alles, was das Ticket berichtet und muss somit nicht die schlüsselabgeleiteten Werte H_i sehen.
Das Schlüsselverteilungszentrum gibt das generierte Ticket an die Spielkonsole zurück. Da die Spielkonsole den Servergeräteschlüssel K_A nicht kennt, kann die Spielkonsole das Ticket nicht öffnen und die Inhalte verändern. Das Schlüsselverteilungszentrum gibt auch einen Sitzungssicherheitsschlüssel in einer beigefügten verschlüsselten Nachricht zurück. Die Sitzungsschlüsselnachricht enthält die Ticket-Generierungszeit T_G, die Ticket-Verfalldauer T_L und den Sitzungssicherheitsschlüssel K_CA, und alle Inhalte werden unter Verwendung des Spielkonsoleschlüssels K_C folgendermaßen verschlüsselt:
Da die Sitzungsschlüsselnachricht mit dem Schlüssel K_C der Spielkonsole verschlüsselt ist, kann die Spielkonsole die Sitzungsschlüsselnachricht öffnen und die Sitzungszeiparameter und die Sitzungsschlüssel wiederherstellen.
Weiterhin auf 1 bezogen, kann das Clientgerät 102 das Ticket verwenden, um den gesicherten Schlüsselaustausch mit gegenseitiger Authentifikation mit dem Servergerät 106 durchzuführen, sobald das Clientgerät 102 (z. B. eine Spielkonsole) das Ticket von dem Schlüsselverteilungszentrum 104 empfängt. Der gesicherte Schlüsselaustausch mit gegenseitiger Authentifikation ermöglicht dem Clientgerät 102 und dem Servergerät 106 sich gegenseitig zu authentifizieren – das Clientgerät 102 kann verifizieren, dass das Servergerät 106 das Servergerät ist, das es behauptet zu sein, und das Servergerät 106 kann verifizieren, dass das Clientgerät 102 das Clientgerät ist, das es behauptet zu sein. Ferner kann jedes der Gerät 102 und 106 verifizieren, dass das andere Kenntnis von einem bestimmten Schlüssel hat.
Der Schlüsselaustausch erlaubt auch, dass ein neues Geheimnis von den zwei Geräten 102 und 106 abgeleitet wird, das von diesen zwei Geräten gemeinsam benutzt wird, aber es wird nicht zwischen den zwei Geräten übertragen und kann nicht, basierend auf dem Hin- und Rückweg-Verkehr zwischen den Geräten, von einem dritten Teilnehmer (z. B. einem anderen Gerät in demselben Netzwerk wie die Geräte 102 und 106) abgeleitet werden. In einer beispielhaften Implementierung verwenden die Geräte Diffie-Hellman-Potenzierungs-Operationen, um das neue Geheimnis abzuleiten. Zusätzliche Informationen bezüglich Diffie-Hellman sind zu finden in W. Diffie und M. E. Hellman „Neue Richtungen in der Kryptografie", IEEE-Transaktionen in der Informationstheorie v. IT-12, 6. November 1976, S. 644-654. Die Datenübertragungen zwischen den Geräten 102 und 106 können durch Verschlüsseln der Datenübertragungen geschützt werden, oder sie können alternativ ohne Verschlüsselung durchgeführt werden.
2 ist ein Ablaufdiagramm, das einen beispielhaften Ablauf 150 zur Durchführung des gesicherten Schlüsselaustauschs mit gegenseitiger Authentifikation zwischen einem Client- und einem Servergerät darstellt. Der Ablauf von 2 wird sowohl durch ein Clientgerät als auch durch ein Servergerät implementiert, wobei Arbeitsgänge von dem Clientgerät durchgeführt werden, das auf der linken Seite von 2 gezeigt wird und Arbeitsgänge von dem Servergerät durchgeführt werden, das auf der rechten Seite von 2 gezeigt wird. Der Ablauf von 2 kann in der Software, der Firmware, der Hardware und in Kombinationen davon durchgeführt werden. Der Ablauf von 2 wird mit Bezug auf die Komponenten von 1 behandelt. Obwohl als ein Ablauf zwischen dem Client und dem Servergerät dargestellt, kann der Ablauf zusätzlich durch zwei beliebige Geräte durchgeführt werden, bei de nen der Aufbau eines gesicherten Datenübertragungskanals untereinander gewünscht wird (z. B. kann der Ablauf von zwei Clientgeräten oder von zwei Servergeräten durchgeführt werden).
Zunächst generiert das Clientgerät 102 ein Schlüsselaustausch-Initiatorpaket und sendet das Paket an das Servergerät 106 (Vorgang 152). Das Servergerät 106 empfängt das Schlüsselaustausch-Initiatorpaket und validiert das empfangene Paket (Vorgang 154). Sobald das Paket validiert ist, generiert das Servergerät 106 die kryptografischen Schlüssel, die verwendet werden sollen, um die Datenübertragungen mit dem Clientgerät 102 zu sichern (Vorgang 156). In einer beispielhaften Implementierung sind diese kryptografischen Schlüssel Verbindungssicherheitsschlüssel, die verwendet werden, um Punkt-zu-Punkt-Datenübertragung zwischen zwei Geräten zu sichern.
Das Servergerät 106 generiert dann ein Schlüsselaustausch-Antwortpaket und sendet das generierte Paket zu dem Clientgerät 102 (Vorgang 158). Das Clientgerät 102 empfängt das Schlüsselaustausch-Antwortpaket und validiert das empfangene Paket (Vorgang 160). Sobald das Paket validiert ist, generiert das Clientgerät 102 die kryptografischen Schlüssel, die verwendet werden sollen, um die Datenübertragung mit dem Servergerät 106 zu sichern (Vorgang 162). Die kryptografischen Schlüssel sind dieselben wie die, die in Vorgang 156 durch das Servergerät 106 generiert werden. Deshalb endigen sowohl das Clientgerät 102 als auch das Servergerät 106 mit denselben Schlüsseln, aber sie tun das, ohne dass die Schlüssel tatsächlich zwischen ihnen übertragen werden.
Es sollte beachtet werden, dass der Vorgang 150 die perfekte Vorwärtsgeheimhaltung aufrechterhält. Die perfekte Vorwärtsgeheimhaltung bezieht sich auf die Unfähigkeit eines dritten Teilnehmers ein neues Geheimnis abzuleiten, selbst dann wenn der dritte Teilnehmer Kenntnis von einem früheren Geheimnis haben kann. Wenn zum Beispiel ein dritter Teilnehmer (z. B. ein anderes Gerät) den Sitzungssicherheitsschlüssel K_CA oder einen zuvor aufgebauten Schlüssel zwischen dem Clientgerät 102 und dem Servergerät 106 entdecken würde, dann wäre der dritte Teilnehmer deshalb nicht in der Lage den neuen Schlüssel abzuleiten, der durch den Sicherheitsschlüssel-Austauschvorgang 150 generiert wurde. Das ist zum Beispiel deshalb so, weil der dritte Teilnehmer keine Kenntnis von den Diffie-Hellman-Werten (nachfolgend ausführlicher behandelt) hätte, die in dem Ablauf 150 verwendet werden.
Zusätzlich ist zu sehen, dass nur zwei Pakete zwischen dem Clientgerät 102 und dem Servergerät 106 übertragen werden müssen – das Schlüsselaustausch-Initiatorpaket und das Schlüsselaustausch-Antwortpaket. Deshalb ist ein einzelner Hin- und Rückweg (ein Paket von dem Clientgerät 102 zu dem Servergerät 106 und ein Antwortpaket von dem Servergerät 106 zu dem Clientgerät 102) alles, was benötigt wird, um den gesicherten Schlüsselaustausch mit gegenseitiger Authentifikation durchzuführen. Dieser einzelne Hin- und Rückweg dient durch das Reduzieren der Anzahl der verwendeten Pakete dazu, die Wartezeit ebenso zu reduzieren wie einen Bandbreiten-Mehraufwand beim Aufbau der (des) Schlüssel(s) und der gegenseitigen Authentifikation der Geräte.
Mit Bezug auf 3-6 wird der Ablauf 150 nachfolgend ausführlicher behandelt. 3 stellt den Vorgang 152 in zusätzlicher Ausführlichkeit dar, 4 stellt den Vorgang 154 in zusätzlicher Ausführlichkeit dar, 5 stellt die Vorgänge 156 und 158 in zusätzlicher Ausführlichkeit dar, und 6 stellt die Vorgänge 160 und 162 in zusätzlicher Ausführlichkeit dar.
3 ist ein Ablaufdiagramm, das einen beispielhaften Ablauf 200 für das Generieren und Senden eines Schlüsselaustausch-Initiatorpakets darstellt. 3 stellt den Vorgang 152 von 2 in zusätzlicher Ausführlichkeit dar. Der Ablauf von 3 wird von einem Clientgerät implementiert und kann in der Software, der Firmware, der Hardware und in Kombinationen davon durchgeführt werden. Der Ablauf von 3 wird mit Bezug auf die Komponenten von 1 behandelt.
Zunächst generiert das Clientgerät 102 eine Schlüsselaustausch-Initiatornachricht (Vorgang 202). Die Schlüsselaustausch-Initiatornachricht beinhaltet einen Zufallswert (oder Pseudozufallswert), der von dem Clientgerät 102 generiert wird und als NonceInit bezeichnet wird, und sie beinhaltet auch den Diffie-Hellman-Wert (g^X mod N), wobei X ebenfalls eine Zufallszahl (oder Pseudozufallszahl) ist, die von dem Clientgerät 102 generiert wird, und einen Sicherheitsparameter-Indexwert (SPI₁), der verwendet wird, um, sobald der Schlüsselaustauschablauf abgeschlossen ist, folgendermaßen eindeutig diesen Client/Server-Kommunikationskanal zu definieren: InitMess = [NonceInit, SPI1(gX mod N)].
Das Clientgerät 102 berechnet dann einen Auszug der Schlüsselaustausch-Initiatornachricht unter Verwendung des Kerberos-Sitzungsschlüssel K_CA, der von dem Schlüsselverteilungszentrum 104 empfangen wurde (Vorgang 204). Der Auszug wird folgendermaßen generiert:
Alternativ könnte auch ein generischer Einweg-Hashwert (der nicht verschlüsselt ist) bei der Berechnung von HashInitMess verwendet werden. Die Sicherheit des Schlüsselaustauschs ist nicht darauf angewiesen, ob dieser Hashwert verschlüsselt ist oder nicht.
Das Clientgerät 102 generiert dann einen Kerberos-Authentifikator (Vorgang 206). Der Kerberos-Authentifikator beinhaltet einen Zeitstempel (z. B. die aktuelle Zeit des Clientgeräts 102) und den HashInitMess-Auszug, der in Vorgang 204 berechnet wird. Der Zeitstempel wird von dem Clientgerät 102 jedes Mal erhöht, wenn das Gerät 102 einen Kerberos-Authentifikator generiert, was dem Servergerät 106 ermöglicht, besser Replay-Attacken zu ermitteln. Das Clientgerät 102 verschlüsselt den Kerberos-Authentifikator (Vorgang 208) unter Verwendung des Kerberos-Sitzungsschlüssels K_CA folgendermaßen:
Das Clientgerät 102 generiert dann ein Schlüsselaustausch-Initiatorpaket (Vorgang 210). Das Schlüsselaustausch-Initiatorpaket beinhaltet die Schlüsselaustausch-Initiatornachricht InitMess, den verschlüsselten Kerberos-Authentifikator Auth_T und das Kerberos-Ticket für das Servergerät 106, das von dem Schlüsselverteilungszentrum 104 empfangen wurde. Wie oben besprochen, beinhaltet das Kerberos-Ticket mindestens den Kerberos-Sitzungsschlüssel (K_CA, eine Zeitspanne, in der das Ticket gültig ist, und eine einzelne Zahl, die das Clientgerät 102 identifiziert, alles unter Verwendung eines Geheimschlüssels verschlüsselt, der gemeinsam von dem Schlüsselverteilungszentrum 104 und dem Servergerät 106 benutzt wird. Der SPI-Wert identifiziert die Sicherheitsverbindung oder den Datenübertragungskanal zwischen dem Clientgerät 102 und dem Servergerät 106. Der SPI₁-Wert gehört zu den Datenübertragungen von dem Servergerät 106 zu dem Clientgerät 102, und ein SPI₂-Wert gehört zu den Datenübertragungen von dem Clientgerät 102 zu dem Servergerät 106. Das Schlüsselaustausch-Initiatorpaket stellt sich deshalb folgendermaßen dar. InitPacket = [InitMess, AuthT, Ticket].
Es sollte beachtet werden, dass die Kombination von dem Authentifikator und dem Ticket in der Kerberos-Therminologie als die AP-Abfrage bezeichnet wird. Das Clientgerät 102 sendet dann das Schlüsselaustausch-Initiatorpaket an das Servergerät 106 (Vorgang 212).
4 ist ein Ablaufdiagramm, das einen beispielhaften Ablauf 250 für das Empfangen und Validieren des Schlüsselaustausch-Initiatorpakets darstellt. 4 stellt den Vorgang 154 von 2 in zusätzlicher Ausführlichkeit dar. Der Ablauf von 4 wird von einem Servergerät implementiert und kann in der Software, der Firmware, der Hardware und in Kombinationen davon durchgeführt werden. Der Ablauf von 4 wird mit Bezug auf die Komponenten von 1 behandelt.
Zunächst empfängt das Servergerät 106 das Schlüsselaustausch-Initiatorpaket InitPacket (Vorgang 252). In einer Implementierung erwartet das Servergerät 106, dass alle Schlüsselaustausch-Initiatorpakete in einem festgelegten Format und einem festgelegten Umfang vorliegen. Jedes Schlüsselaustausch-Initiatorpaket, das nicht in dem festgelegten Format oder dem festgelegten Umfang vorliegt, wird von dem Servergerät 106 ignoriert. Alternativ kann das Servergerät 106 den Schlüsselaustausch-Initiatorpaketen gestatten, in einer Vielfalt von Formaten und/oder Umfängen vorzuliegen.
Sobald das Schlüsselaustausch-Initiatorpaket empfangen wird, entschlüsselt das Servergerät 106 das Kerberos-Ticket (Vorgang 254) unter Verwendung des Schlüssels, den das Servergerät 106 und das Schlüsselverteilungszentrum 104 gemeinsam benutzen. Das Servergerät 106 überprüft dann das entschlüsselte Ticket, um festzustellen ob das Ticket abgelaufen ist (Vorgang 256). Wenn die aktuelle Zeit in dem Zeithereich enthalten ist, während dessen das Ticket gültig ist (wie es in dem Ticket identifiziert ist), dann ist das Ticket nicht abgelaufen. Wenn die aktuelle Zeit jedoch nicht in dem Zeitbereich enthalten ist, während dessen das Ticket gültig ist, dann ist das Ticket abgelaufen. Wenn das Kerberos Ticket abgelaufen ist, dann schlägt der Schlüsselaustauschablauf fehl (Vorgang 258), was dazu führt, dass keine Sicherheitsverbindung zwischen dem Clientgerät 102 und dem Servergerät 106 auf gebaut wird. Als Teil von Vorgang 258 kann das Servergerät 106 das Clientgerät 102 benachrichtigen, dass der Schlüsselaustauschablauf fehlgeschlagen ist, oder alternativ kann das Servergerät 106 einfach das empfangene InitPacket löschen und das Clientgerät 102 nicht benachrichtigen.
Wenn das Kerberos Ticket jedoch nicht abgelaufen ist, dann entschlüsselt das Servergerät 106 den Kerberos-Authentifikator Auth_T (Vorgang 260) unter Verwendung des Kerberos-Sitzungsschlüssels K_CA, der von dem entschlüsselten Kerberos-Ticket wiederhergestellt wird. Das Servergerät 106 greift dann auf den Zeitstempel in dem Kerberos-Authentifikator zu und überprüft, ob der Zeitstempel akzeptabel ist (Vorgang 262). Der Zeitstempel ist akzeptabel, wenn er nicht zu weit außerhalb der Synchronisation mit der aktuellen Zeit in dem Servergerät 106 liegt. In einer beispielhaften Implementierung ist der Zeitstempel dann akzeptabel, wenn der Zeitstempel innerhalb eines Schwellenwertzeitumfangs (z. B. 5 Minuten, was der vorgeschlagene Kerberos-Zeitversatz ist) von der aktuellen Zeit in dem Servergerät 106 liegt. Wenn der Zeitstempel nicht akzeptabel ist, dann schlägt der Schlüsselaustauschablauf fehl (Vorgang 258).
Wenn der Zeitstempel akzeptabel ist, dann berechnet das Servergerät 106 den Auszug der Schlüsselaustauschnachricht InitMess (Vorgang 264). Das Servergerät 106 berechnet den Auszug in der gleichen Weise wie das Clientgerät 102 den Auszug in Vorgang 204 von 3 berechnet. Das Servergerät 106 überprüft dann, ob der Auszugswert, der in Vorgang 264 berechnet wird, mit dem Auszugswert übereinstimmt (gleich ist), der von dem Clientgerät 102 als Teil des verschlüsselten Kerberos-Authentifikators Auth_T empfangen wird (Vorgang 266). Wenn die zwei Auszugswerte dieselben sind, dann dient das der Bestätigung, dass die Schlüsselaustauschnachricht InitMess zwischen dem Clientgerät 102 und dem Servergerät 106 nicht geändert wurde (z. B. wurde die Schlüsselaustauschnachricht InitMess nicht verfälscht). Wenn die zwei Auszugswerte nicht übereinstimmen (mit anderen Worten, wenn die zwei Auszugswerte nicht gleich sind), dann schlägt der Schlüsselaustauschablauf fehl (Vorgang 258).
Wenn die empfangenen und berechneten Auszugswerte jedoch übereinstimmen, dann überprüft das Servergerät 106, ob der Kerberos-Authentifikator eine Replay-Attacke erlitten hat (Vorgang 268). Das Servergerät 106 bewahrt eine Aufzeichnung der Zeitstempel von jedem Kerberos-Authentifikator, den es von jedem Clientgerät C (das in dem Kerberos- Ticket aufgedeckt wird) empfangen hat, auf. Wenn das Servergerät 106 ein Kerberos-Ticket mit einem Zeitstempel Time empfängt, die nicht neuer ist als der letzte aufgezeichnete Zeitstempel, der von dem Servergerät 106 aufgezeichnet wurde, dann erkennt das Servergerät 106, dass der Kerberos-Authentifikator eine Replay-Attacke erlitten hat. Wenn der Kerberos-Authentifikator eine Replay-Attacke erlitten hat, dann ist das Schlüsselaustausch-Initiatorpaket nicht gültig, und der Schlüsselaustauschablauf schlägt fehl (Vorgang 258). Wenn der Kerberos-Authentifikator jedoch keine Replay-Attacke erlitten hat, dann wurde das Schlüsselaustausch-Initiatorpaket von dem Servergerät 106 validiert (Vorgang 270). Wenn alle diese Tests zufriedenstellend verlaufen und das Schlüsselaustausch-Initiatorpaket in Vorgang 270 validiert wird, dann hat das Servergerät 106 das Clientgerät 102 wirklich als das Gerät authentifiziert, das es behauptet zu sein, – das Servergerät 106 hat verifiziert, dass das Clientgerät 102 Kenntnis von dem Kerberos-Sitzungsschlüssel K_CA hat, und es hat auch (indirekt durch das Vertrauen des Schlüsselverteilungszentrums) verifiziert, dass der Client Kenntnis von K_C hat.
5 ist ein Ablaufdiagramm, das einen beispielhaften Ablauf 300 für das Generieren von kryptografischen Schlüsseln ebenso wie das Generieren und Senden eines Schlüsselaustausch-Antwortpakets darstellt. 5 stellt die Vorgänge 156 und 158 von 2 in zusätzlicher Ausführlichkeit dar. Der Ablauf von 5 wird von einem Servergerät implementiert und kann in der Software, der Firmware, der Hardware und in Kombinationen davon durchgeführt werden. Der Ablauf von 5 wird mit Bezug auf die Komponenten von 1 behandelt.
Zunächst generiert das Servergerät 106, basierend auf der Schlüsselaustausch-Initiatornachricht InitMess, dem Kerberos-Sitzungsschlüssel K_CA, der Nonce von dem Clientgerät 102 (NonceInit) und einer Nonce, die von dem Servergerät 106 generiert wird (NonceResp) kryptografische Schlüssel (Vorgang 302). Das Servergerät 106 generiert eine Zufallszahl (oder eine Pseudozufallszahl) Y ebenso wie einen Zufallswert, der als NonceResp bezeichnet wird. Das Servergerät 106 berechnet ferner den Diffie-Hellman-Wert (g^XY mod N) ebenso wie den Diffie-Hellman-Wert (g^Y mod N). Zu diesem Zeitpunkt weist das Servergerät 106 genug Daten auf, um die Sicherheitsverbindungsschlüssel zu berechnen. Die Sicherheitsverbindungsschlüssel werden verwendet, um die Punkt-zu-Punkt-Datenübertragungen zwischen zwei Konsolen zu sichern. In einer beispielhaften Implementierung verwendet das Servergerät 106 die zwei Diffie-Hellman-Werte ((g^X mod N) und (Y), um die Funtion (g^XY mod N) zu berechnen. Das Servergerät 106 kann dann unter Verwendung verschiedener Algorithmen, die auf den Werten NonceInit, NonceResp, (g^XY mod N) und dem Kerberos-Sitzungsschlüssel K_CA basieren, verschiedene Auszüge berechnen. Diese Auszüge werden verwendet, um die Sicherheitsverbindungsschlüssel zu bilden. In einer beispielhaften Implementierung berechnet das Servergerät 106 unter Verwendung von NonceInit, NonceResp, (g^XY mod N) als Eingabe vier verschiedene Auszüge, ebenso wie dem Kerberos-Sitzungsschlüssel K_CA die als die Sicherheitsschlüssel für das Authentifizieren und das Verschlüssel/Entschlüsseln aller gesscherten Pakete in beide Richtungen verwendet werden sollen (ein Schlüssel für die Authentifikation, ein Schlüssel für die Verschlüsselung mal zwei für jede Richtung ergibt vier).
Das Servergerät 106 generiert dann eine Schlüsselaustausch-Antwortnachricht (Vorgang 304). Die Schlüsselaustausch-Antwortnachricht enthält NonceInit, der Zeitstempel Time, die von dem Clientgerät 102 empfangen wird, NonceResp, den Diffie-Hellman-Wert, (g^Y mod N) und einen SPI₂-Wert, wie folgt: RespMess = [NonceInit, SPI2, NonceResp, (gY mod N)].
Der SPI₂-Wert wird von dem Servergerät 106 generiert und gehört zu allen Datenübertragungen von dem Clientgerät 102 zu dem Servergerät 106. Das Servergerät 106 berechnet dann unter Verwendung des Kerberos-Sitzungsschlüssels (Vorgang 306) und einer Hash-Funktion H einen Auszug der Antwortnachricht wie folgt:
Die Hash-Funktion M in Vorgang 306 kann dieselbe sein wie die Hash-Funktion H in Vorgang 204 oder alternativ eine andere Hash-Funktion.
Das Servergerät 106 generiert dann eine Kerberos-Antwortnachricht, die sowohl den berechneten Hash-Auszug als auch der Zeitstempel Time von dem Kerberos-Authentifikator (Vorgang 308) beinhaltet, wie folgt: ReplyMess = [HashRespMess, Time]
Das Servergerät 106 entschlüsselt dann unter Verwendung eines Verschlüsselungsalgorithmus E (z. B. Dreifach-DES) und des Kerberos-Sitzungssicherheitsschlüssels K_CA (Vorgang 310) die Kerberos-Antwortnachricht ReplyMess wie folgt:
Der Verschlüsselungsalgorithmus E in Vorgang 308 kann derselbe Verschlüsselungsalgorithmus sein, der in Vorgang 206 von 3 verwendet wird, oder er kann alternativ ein anderer Verschlüsselungsalgorithmus sein.
Das Servergerät 106 generiert dann ein Schlüsselaustausch-Antwortpaket, das die Schlüsselaustausch-Antwortnachricht RespMess und die verschlüsselte Kerberos-Antwortnachricht EncryptedReplyMess beinhaltet, wie folgt: RespPacket = [RespMess, EncryptedReplyMess].
Das Servergerät 106 sendet dann das Schlüsselaustausch-Antwortpaket RespPacket an das Clientgerät 102 (Vorgang 314).
6 ist ein Ablaufdiagramm, das einen beispielhaften Ablauf 350 für das Empfangen und Validieren des Schlüsselaustausch-Antwortpakets und für das Generieren kryptografischer Schlüssel darstellt. 6 stellt die Vorgänge 160 und 162 von 2 in zusätzlicher Ausführlichkeit dar. Der Ablauf von 6 wird von einem Clientgerät implementiert und kann in der Software, der Firmware, der Hardware und in Kombinationen davon durchgeführt werden. Der Ablauf von 6 wird mit Bezug auf die Komponenten von 1 behandelt.
Zunächst empfängt das Clientgerät 102 das Schlüsselaustausch-Antwortpaket RespPacket von dem Servergerät 106 (Vorgang 352). Das Clientgerät 102 entschlüsselt die Kerberos-Antwortnachricht EncryptedReplyMess unter Verwendung des Kerberos-Sitzungsschlüssels K_CA (Vorgang 354). Das Clientgerät 102 überprüft dann, ob der Zeitstempel Time in der entschlüsselten Antwortnachricht zu dem Zeitstempel Time passt, die das Clientgerät 102 zu dem Servergerät 106 gesendet hat (Vorgang 356). Wenn die Zeitstempel übereinstimmen (mit anderen Worten, wenn die Zeitstempel gleich sind), dann bestätigt das Übereinstimmen, dass das Servergerät 106 das Kerberos-Ticket (somit Kenntnis von K_A prüfend) und den Kerberos-Authentifikator (und somit Kenntnis des Kerberos-Sitzungsschlüssels K_CA hat) entschlüsseln konnte und deswegen wirklich das Servergerät 106 ist, das es behauptet zu sein. Das Servergerät 106 ist somit gegenüber dem Clientgerät 102 authentifiziert, wenn diese Zeitstempelwerte übereinstimmen, und zu diesem Zeitpunkt ist die vollständige Authentifikation erreicht (der Server hat die Client-Kenntnis von K_A geprüft, und der Client hat die Server-Kenntnis von K_C geprüft).
Wenn die Zeitstempelwerte nicht übereinstimmen, dann schlägt, analog zu Vorgang 258 von 4, der Schlüsselaustauschablauf fehl (Vorgang 358). Wenn die Zeitstempelwerte jedoch übereinstimmen, dann ist das Servergerät 106 gegenüber dem Clientgerät 102 authentifiziert, und das Clientgerät 102 fährt damit fort, unter Verwendung des Kerberos-Sitzungsschlüssels K_CA den Auszug der Schlüsselaustausch-Antwortnachricht RespMess zu berechnen (Vorgang 360). Das Clientgerät 102 berechnet den Auszug in der gleichen Weise wie das Servergerät 106 den Auszug in Vorgang 306 von 5 berechnet. Das Clientgerät 102 überprüft dann, ob der Auszugswert, der in Vorgang 360 berechnet wird mit dem Auszugswert übereinstimmt (gleich ist), der von dem Servergerät 106 als Teil der verschlüsselten Kerberos-Antwortnachricht EncryptedReplyMess empfangen wird (Vorgang 362). Wenn die zwei Auszugswerte dieselben sind, dann dient das der Bestätigung, dass die Schlüsselaustausch-Antwortnachricht RespMess zwischen dem Servergerät 106 und dem Clientgerät 102 nicht geändert wurde (z. B. wurde die Schlüsselaustausch-Antwortnachricht RespMess nicht verfälscht). Wenn die zwei Auszugswerte nicht übereinstimmen (mit anderen Worten, wenn die zwei Auszugswerte nicht gleich sind), dann schlägt der Schlüsselaustauschablauf fehl (Vorgang 358).
Wenn die zwei Auszugswerte jedoch übereinstimmen, dann generiert das Clientgerät 102, basierend auf dem Kerberos-Sitzungsschlüssel K_CA, der NonceInit, der NonceResp und g^XY mod N die kryptografischen Schlüssel (Vorgang 364). Analog zu der obigen Erörterung hat das Clientgerät 102 bezüglich des Vorgangs 302 von 5 nun genügend Daten, um den Diffie-Hellman-Wert (g^XY mod N) und die Sicherheitsverbindungsschlüssel zu berechnen. Die in Vorgang 364 von dem Clientgerät 102 berechneten Sicherheitsverbindungsschlüssel sind dieselben und werden in derselben Weise berechnet, wie diejenigen, die von dem Servergerät 106 in Vorgang 302 von 5 berechnet werden. Man beachte, dass g^XY mod N von dem Clientgerät aus g^Y mod N und X berechnet wird.
Sobald das Clientgerät 102 die Sicherheitsverbindungsschlüssel berechnet hat, ist das Gerät 102 frei, beliebige Pakete zu übertragen, die darauf gewartet haben, dass der Schlüsselaustausch fertig ist. Das Servergerät 106 ist jedoch nicht frei, dieses zu tun, obwohl es die gleiche Schlüsselgruppe aufweist, weil es nicht sicher sein kann, dass seine Antwortnachricht RespMess nicht verloren ging. Das Servergerät 106 wartet bis es ein Paket empfängt, das mit dem berechneten Sicherheitsverbindungsschlüssel von dem Clientgerät 102 authentifiziert wurde, oder bis es alternativ ein Bestätigungspaket (AckPack) von dem Clientgerät 102 empfängt.
Üblicherweise sendet das Clientgerät 102 ein Paket zu dem Servergerät 106, und deshalb besteht der Schlüsselaustauschablauf aus genau zwei Paketen – InitPacket und RespPacket. Sollte das Clientgerät 102 kein Paket zum Senden aufweisen, wird das Clientgerät 102 alternativ ein künstliches Bestätigungspaket (als "AckPack" bezeichnet) senden. Dieses Paket unterscheidet sich von den zwei anderen Schlüsselaustauschpaketen dadurch, dass das AckPack unter Verwendung des berechneten Sicherheitsverbindungsschlüssels anstelle des Kerberos-Sitzungsschlüssels K_CA einer Hash-Funktion unterzogen wird.
Van diesem Zeitpunkt an benutzen die zwei Geräte 102 und 106 die Sicherheitsverbindungsschlüssel für gesicherte Datenübertragungen. Alle Netzwerkpakete, die zu dem anderen Gerät übertragen werden müssen, sind authentifiziert nachdem sie optional verschlüsselt wurden, wobei das empfangende Gerät die Authentifikationsdaten verifiziert bevor die Paketinhalte entschlüsselt werden. Jedes der Geräte 102 und 106 kann die Schlüsselaustauschpakete von der anderen Seite ausklammern, die dieselben Noncen enthalten.
7 ist ein Blockdiagramm einer beispielhaften Online-Spiel-Umgebung 400. Mehrere Spielkonsolen 402(1), 402(2), ..., 402(n) sind mit einem Sicherheits-Gateway 404 über ein Netzwerk 406 gekoppelt. Das Netzwerk 406 stellt ein beliebiges Netzwerk aus einer Vielfalt von herkömmlichen Datenkommunikations-Netzwerken dar. Das Netzwerk 406 wird üblicherweise Paketvermittlungsnetze beinhalten, aber es kann auch leitungsvermittelte Netze beinhalten. Das Netzwerk 406 kann drahtgebundene und/oder drahtlose Abschnitte beinhalten. in einer beispielhaften Implementierung beinhaltet das Netzwerk 406 das Internet und kann optional ein oder mehrere lokale Netzwerke (LANs) und/oder Weitbereichsnetze (WANs) beinhalten. Mindestens ein Teil des Netzwerks 406 ist ein öffentliches Netz, was sich auf ein Netzwerk bezieht, dass öffentlich zugänglich ist. Praktisch jeder kann auf das öffentliche Netz zugreifen.
In einigen Situationen beinhaltet das Netzwerk 406 ein LAN (z. B. ein Heimnetz) mit einem Leitweggerät, das sich zwischen der Spielkonsole 402 und dem Sicherheits-Gateway 404 befindet. Dieses Leitweggerät kann eine Netzwerkadressumwandlung (NAT) durchführen, was mehreren Geräten in dem LAN gestattet, dieselbe IP-Adresse im Internet gemeinsam zu benutzen und so als eine Firewall zu fungieren, um das (die) Gerät(e) in dem LAN vor dem Zugriff bösartiger oder schädlicher Anwender über das Internet zu schützen.
Das Sicherheits-Gateway 404 arbeitet als ein Gateway zwischen einem öffentlichen Netz 406 und einem privaten Netz 408. Das private Netz 408 kann ein beliebiges Netzwerk aus einer breiten Vielfalt von Netzwerken, wie z. B. ein lokales Netzwerk sein. Das private Netz 408, ebenso wie andere Geräte, die in größerer Ausführlichkeit nachfolgend behandelt werden, befinden sich innerhalb eines Datenzentrums 410, das als ein Sicherheitsbereich fungiert. Das Datenzentrum 410 ist aus zuverlässigen Geräten aufgebaut, die mittels zuverlässiger Datenübertragungen miteinander kommunizieren. Deshalb sind Verschlüsselung und Authentifikation innerhalb des Sicherheitsbereichs 410 nicht notwendig. Die private Art des Netzwerks 408 bezieht sich auf die eingeschränkte Zugänglichkeit zu dem Netzwerk 408 – der Zugang zu dem Netzwerk 408 ist auf bestimmte Personen beschränkt (z. B. auf den Besitzer oder Betreiber des Datenzentrums 410 beschränkt).
Das Sicherheits-Gateway 404 ist eine Ansammlung von einem oder mehreren Sicherheits-Gateway-Rechengeräten. Diese Sicherheits-Gateway-Rechengeräte implementieren gemeinsam das Sicherheits-Gateway 404. Das Sicherheits-Gateway 404 kann optional ein oder mehrere herkömmliche Lastausgleichsgeräte beinhalten, die arbeiten, um Abfragen, die von den Sicherheits-Gateway-Rechengeräten verarbeitet werden sollen, zu den geeigneten Rechengeräten zu leiten. Dieses Leiten oder Last Ausgleichen wird in einer Weise durchgeführt, die versucht die Last ungefähr gleichmäßig (oder alternativ gemäß andere Kriterien) auf die verschiedenen Sicherheits-Gateway-Rechengeräte zu verteilen.
Außerdem befinden sich innerhalb des Datenzentrums 410: ein oder mehrere Überwachungsserver 412; eine oder mehrere Anwesenheits- und Meldungs-FrontDoors 414, ein oder mehrere Anwesenheitsserver 416 und ein oder mehrere Meldungsserver 418 (die ge meinsam einen Anwesenheits- und Meldungsdienst implementieren); eine oder mehrere Anpassungs-FrontDoors 420 und ein oder mehrere Anpassungsserver 422 (die gemeinsam einen Anpassungsdienst implementieren); und eine oder mehrere Statistik-FrontDoors 424 und ein oder mehrere Statistikserver 426 (die gemeinsam einen Statistikdienst implementieren). Die Server 416, 418, 422 und 426 stellen für die Spielkonsole 402 Dienste bereit, und sie können deshalb als Dienstgeräte bezeichnet werden. Weitere Dienstgeräte können ebenfalls zusätzlich zu und/oder anstelle von einem oder mehreren Servern 416, 418, 422 und 426 enthalten sein. Obwohl nur ein Datenzentrum in 7 gezeigt wird, können alternativ zusätzlich mehrere Datenzentren bestehen, mit denen die Spielkonsolen 402 kommunizieren können. Diese Datenzentren können unabhängig arbeiten, oder sie können alternativ gemeinsam arbeiten (z. B. um ein großes Datenzentrum für die Spielkonsolen 402 verfügbar zu machen).
Die Spielkonsolen 402 befinden sich entfernt von dem Datenzentrum 410 und greifen über das Netzwerk 406 auf das Datenzentrum 410 zu. Eine Spielkonsole, die mit einem oder mehreren Geräten in dem Datenzentrum kommunizieren möchte, baut einen gesicherten Datenübertragungskanal zwischen der Konsole 402 und dem Sicherheits-Gateway 404 auf. Die Spielkonsole 402 und das Sicherheits-Gateway 404 verschlüsseln und authentifizieren Datenpakete, die vor und zurück vorbei geleitet werden, wobei sie ermöglichen, dass die Datenpakete gesichert zwischen ihnen übertragen werden, ohne dass sie von irgend einem anderen Gerät verstanden werden, das die Datenpakete abfangen oder kopieren könnte ohne die Verschlüsselung zu knacken. Jedes Datenpaket, das von der Spielkonsole 402 zu dem Sicherheits-Gateway 404 oder von dem Sicherheits-Gateway 404 zu der Spielkonsole 402 übertragen wird, kann dann eingebettete Daten aufweisen. Diese eingebetteten Daten werden als der Inhalt oder der Dateninhalt des Pakets bezeichnet. Zusätzliche Informationen können, basierend auf dem dazugehörigen Pakettyp, ebenso in dem Paket enthalten sein.
Der gesicherte Datenübertragungskanal zwischen einer Konsole 402 und dem Sicherheits-Gateway 404 wird unter Verwendung des gesicherten Schlüsselaustauschs mit gegenseitiger Authentifikation, der hierin beschrieben ist, aufgebaut Die Konsole 402 authentifiziert sich selbst, und den (die) aktuellen Anwender der Konsole 402 gegenüber einem Schlüsselverteilungszentrum 428 und erhält von dem Schlüsselverteilungszentrum 428 ein Sicherheitsticket. Die Konsole 402 verwendet dann dieses Sicherheitsticket, um den gesicherten Datenübertragungskanal mit dem Sicherheits-Gateway 404 aufzubauen. Beim Aufbauen des gesicherten Datenübertragungskanals mit dem Sicherheits-Gateway 404 authentifizieren die Spielkonsole 402 und das Sicherheits-Gateway 404 sich selbst gegenseitig und bauen einen oder mehrere Sitzungssicherheitsschlüssel auf, die nur dieser bestimmten Spielkonsole 402 und dem Sicherheits-Gateway 404 bekannt sind. Diese(r) Sitzungssicherheitsschlüssel wird (werden) verwendet, um Daten zu verschlüsseln, die zwischen der Spielkonsole 402 und der Sicherheits-Gateway-Ansammlung 404 übertragen werden, so können keine anderen Geräte (einschließlich andere Spielkonsolen 402) die Daten lesen. Der (die) Sitzungssicherheitsschlüssel wird (werden) außerdem verwendet, um ein Datenpaket als das von dem Sicherheits-Gateway 404 oder der Spielkonsole 402 stammende Datenpaket zu authentifizieren, das es behauptet zu sein. Unter Verwendung solcher Sitzungssicherheitsschlüssel können deshalb gesicherte Datenübertragungskanäle zwischen dem Sicherheits-Gateway 404 und den verschiedenen Spielkonsolen 402 aufgebaut werden.
Sobald ein gesicherter Datenübertragungskanal zwischen einer Spielkonsole 402 und dem Sicherheits-Gateway 404 aufgebaut ist, können die verschlüsselten Datenpakete sicher zwischen den beiden übertragen werden. Wenn die Spielkonsole 402 Daten zu einem bestimmten Dienstgerät in dem Datenzentrum 410 übertragen möchte, verschlüsselt die die Spielkonsole 402 die Daten und sendet sie zu dem Sicherheits-Gateway 404 und fordert, dass sie zu dem (den) bestimmten Datendienst(en) weiterbefördert werden, auf den (die) das Datenpaket abzielt. Nach der Authentifikation und der Entschlüsselung des Datenpakets empfängt das Sicherheits-Gateway 404 das Datenpaket und verkapselt den Dateninhalt des Pakets in eine andere Nachricht, die über das private Netzwerk 408 zu dem geeigneten Dienst gesendet werden soll. Das Sicherheits-Gateway 404 ermittelt, basierend auf dem (den) angeforderten Dienst(en), auf den (die) das Datenpaket abzielt, den geeigneten Dienst.
Obwohl hierin in erster Linie die Datenübertragung verschlüsselter Datenpakete zwischen dem Sicherheits-Gateway 404 und einer Spielkonsole 402 behandelt wird, können alternativ einige Datenpakete teilweise verschlüsselt werden (einige Teilbereiche des Datenpakets werden verschlüsselt, während andere Teilbereiche nicht verschlüsselt werden). Welche Teilbereiche der Datenpakete verschlüsselt werden und welche nicht kann, basierend auf den Wünschen der Designer des Datenzentrums 410 und/oder der Spielkonsolen 402 vari ieren. Zum Beispiel können die Designer auswählen, dass es Sprachdaten gestattet wird, zwischen den Konsolen 402 so übertragen zu werden, dass die Anwender der Konsolen 402 miteinander sprechen können – die Designer können ferner auswählen, dass es Sprachdaten gestattet wird, unverschlüsselt zu sein, während alle anderen Daten in den Paketen verschlüsselt sind. Zusätzlich können in einer weiteren Alternative einige Datenpakete keine Teilbereiche aufweisen, die verschlüsselt sind (das heißt, das gesamte Datenpaket ist unverschlüsselt). Es sollte beachtet werden, dass das gesamte Datenpaket immer noch authentifiziert ist, selbst wenn ein Datenpaket unverschlüsselt oder nur teilweise verschlüsselt ist.
Wenn ein Dienstgerät in dem Datenzentrum 410 Daten an eine Spielkonsole 402 übertragen möchte, sendet das Datenzentrum im in ähnlicher Weise eine Nachricht über das private Netzwerk 408 zu dem Sicherheits-Gateway 404, die den Dateninhalt, der zu der Spielkonsole 402 gesendet werden soll ebenso beinhaltet wie eine Bezeichnung der bestimmten Spielkonsole 402, an die der Dateninhalt gesendet werden soll. Das Sicherheits-Gateway 404 bettet den Dateninhalt in ein Datenpaket ein und verschlüsselt dann das Datenpaket, so dass es nur durch die bestimmte Spielkonsole 402 entschlüsselt werden kann, und sie authentifiziert außerdem das Datenpaket als eines, das von dem Sicherheits-Gateway 404 kommt.
Jedes Sicherheits-Gateway-Gerät in dem Sicherheits-Gateway 404 ist verantwortlich für den gesicherten Datenübertragungskanal mit üblicherweise einer oder mehreren Spielkonsolen 402, und deshalb kann jedes Sicherheits-Gateway-Gerät als verantwortlich für das Verwalten oder Verarbeiten einer oder mehrerer Spielkonsolen betrachtet werden. Die verschiedenen Sicherheits-Gateway-Geräte können untereinander kommunizieren und Nachrichten zueinander übertragen. Zum Beispiel kann ein Sicherheits-Gateway-Gerät, das ein Datenpaket zu einer Spielkonsole senden muss, das nicht für das Verwalten verantwortlich ist, eine Nachricht mit den Daten, die zu dieser Spielkonsole gesendet werden sollen, zu allen anderen Sicherheits-Gateway-Geräten senden. Diese Nachricht wird von dem Sicherheits-Gateway-Gerät empfangen, das für das Verwalten dieser Spielkonsole verantwortlich ist, und sie sendet die geeigneten Daten zu dieser Spielkonsole. Alternativ können die Sicherheits-Gateway-Geräte unterrichtet werden welche Spielkonsolen von welchen Sicherheits-Gateway-Geräte bearbeitet werden – das kann explizit geschehen, wie z. B. indem jedes Sicherheits-Gateway-Gerät eine Tabelle von Spielkonsolen aufrechterhält, die durch die anderen Sicherheits-Gateway-Geräte bearbeitet werden, oder alternativ implizit, wie z. B. indem entschieden wird, welches Sicherheits-Gateway-Gerät, basierend auf einem Identifikator der Spielkonsole, für eine bestimmte Spielkonsole verantwortlich ist.
Überwachungsserver 412 arbeiten, um die Geräte in dem Datenzentrum 410 über eine nicht verfügbare Spielkonsole 402 oder ein nicht verfügbares Sicherheits-Gateway-Gerät des Sicherheits-Gateways 404 zu informieren. Die Spielkonsolen 402 können aus einer Vielfalt von verschiedenen Gründen nicht verfügbar werden, wie z. B. einem Hardware- oder einem Softwareausfall, die Konsole kann abgeschaltet werden ohne sich bei dem Datenzentrum 410 abzumelden, das Netzwerkverbindungskabel kann von der Spielkonsole 402 getrennt sein, andere Netzwerkprobleme können auftreten (z. B. das LAN für die Spielkonsole 402 ist defekt) etc. In ähnlicher Weise kann ein Sicherheits-Gateway-Gerät des Sicherheits-Gateways 404 aus einer Vielfalt von verschiedenen Gründen nicht verfügbar werden, wie z. B. einem Hardware- oder einem Softwareausfall, das Gerät kann abgeschaltet sein, das Netzwerkverbindungskabel kann von dem Gerät getrennt sein, andere Netzwerkprobleme können auftreten etc.
Jedes Sicherheits-Gateway-Gerät in dem Sicherheits-Gateway 404 wird von einem oder mehreren Überwachungsservern 412 überwacht, die ermitteln, wann eines der Sicherheits-Gateway-Geräte nicht verfügbar wird. In dem Fall, in dem ein Sicherheits-Gateway-Gerät nicht verfügbar wird, sendet ein Überwachungsserver 412 eine Nachricht an alle anderen Geräte in dem Datenzentrum 410 (Server, FrontDoors, etc.), dass das Sicherheits-Gateway-Gerät nicht länger verfügbar ist Jedes der anderen Geräte kann basierend auf diesen Informationen nach Belieben arbeiten (z. B. kann es annehmen, dass bestimmte Spielkonsolen, die durch das Sicherheits-Gateway-Gerät verwaltet werden, nicht länger in Verbindung mit dem Datenzentrum 410 stehen, und dementsprechend verschiedene Aufräumarbeiten durchführen). Alternativ können nur bestimmte Geräte eine solche Nachricht von dem Überwachungsserver 412 erhalten (z. B. nur die Geräte, die damit befasst sind, ob die Sicherheits-Gateway-Geräte verfügbar sind).
Das Sicherheits-Gateway 404 überwacht die einzelnen Spielkonsolen 402 und ermittelt, wann eine der Spielkonsolen 402 nicht verfügbar wird. Wenn das Sicherheits-Gateway 404 ermittelt, dass eine Spielkonsole nicht länger verfügbar ist, sendet das Sicherheits-Gateway 404 eine Nachricht an den Überwachungsserver 412, der die nicht verfügbare Spielkonsole identifiziert. Als Antwort sendet der Überwachungsserver 412 eine Nachricht an alle anderen Geräte in dem Datenzentrum 410 (oder alternativ nur an ausgewählte Geräte), dass die Spielkonsole nicht länger verfügbar ist. Jedes der anderen Geräte kann dann basierend auf diesen Informationen nach Belieben arbeiten.
Die Anwesenheitsserver 416 beinhalten und verarbeiten die Daten, die den Zustand oder die Anwesenheit eines bestimmten Anwenders betreffen, der in dem Datenzentrum 410 für das Online-Spielen angemeldet ist. Meldungsserver 418 halten mehrere Reihen von ausgehenden Nachrichten aufrecht, die für einen Spieler bestimmt sind, der in dem Datenzentrum 410 angemeldet ist. Die Anwesenheits- und Anmeldungs-FrontDoor 414 besteht aus einem oder mehreren Servergeräten, die als ein Vermittler zwischen dem Sicherheits-Gateway 404 und den Servern 416 und 418 arbeiten. Ein oder mehrere (nicht gezeigte) Lastausgleichsgeräte können in der Anwesenheits- und Anmeldungs-FrontDoor 414 enthalten sein, um die Last unter mehreren Servergeräten zu verteilen, die als FrontDoor 414 arbeiten. Das Sicherheits-Gateway 404 überträgt Nachrichten für die Server 416 und 418 an die FrontDoor 414, und die FrontDoor 414 stellt fest, an welchen bestimmten Server 416 oder weichen bestimmten Server 418 die Nachricht übertragen werden soll. Unter Verwendung der FrontDoor 414 wird die tatsächliche Implementierung der Server 416 und 418, wie z. B. der Server, die für das Verwalten der Daten der betreffenden Anwender verantwortlich sind, von dem Sicherheits-Gateway 404 abgezogen. Das Sicherheits-Gateway 404 kann einfach Nachrichten weiterbefördern, die auf den Anwesenheits- und Anmeldungs-Dienst für die Anwesenheits- und Anmeldungs-FrontDoor 494 abzielen und sich auf die FrontDoor 414 verlassen, um die Nachrichten zu dem (den) geeigneten Server(n) 416 und 418 zu leiten.
Anpassungsserver 422 beinhalten und verarbeiten Daten, die das Anpassen der Online-Spieler zueinander betreffen. Ein Online-Anwender kann ein Spiel ankündigen, das gemeinsam mit verschiedenen Eigenschaften des Spiels (z. B. der Ort, wo ein Fußballspiel gespielt wird, ob ein Spiel tagsüber oder nachts gespielt werden soll, das Geschicklichkeitsniveau des Anwenders etc.) zum Spielen verfügbar ist. Diese verschiedenen Eigenschaften können dann als eine Basis dafür verwendet werden, um verschiedene Online-Anwender aneinander anzupassen, um Spiele zusammen zu spielen. Die Anpassungs-FrontDoor 420 beinhaltet ein oder mehrere Servergeräte (und optional (ein) Lastausgleichsgerät(e)) und arbeitet, um den (die) Anpassungsserver 422 von dem Sicherheits-Gateway 404 in einer Weise ab zuziehen, die analog ist zu dem Abziehen der FrontDoor 414 durch den (die) Server 416 und den (die) Server 418.
Statistikserver 426 beinhalten und verarbeiten Daten, die verschiedene Statistiken für Online-Spiele betreffen. Die speziellen Statistiken, die verwendet werden, können, basierend auf den Wünschen der Spieldesigner variieren (z. B. die besten zehn Punktzahlen oder Zeiten, eine Weltrangliste für alle Online-Spieler des Spiels, eine Liste der Anwender, die die meisten Objekte gefunden haben, oder die die meiste Zeit mit spielen verbracht haben etc.). Die Statistik-FrontDoor 426 beinhaltet ein oder mehrere Servergeräte (und optional (ein) Lastausgleichsgerät(e)) und arbeitet, um den (die) Statistikserver 426 von dem Sicherheits-Gateway 404 in einer Weise abzuziehen, die analog ist zu dem Abziehen der FrontDoor 414 durch den (die) Server 416 und den (die) Server 418.
Deshalb ist zu sehen, dass das Sicherheits-Gateway 404 arbeitet, um die Geräte in dem Sicherheitsbereich des Datenzentrums 410 vor dem nicht gesicherten öffentlichen Netz 406 zu schützen. Datenübertragungen innerhalb des Sicherheitsbereichs des Datenzentrums 410 müssen nicht verschlüsselt werden, da alle Geräte innerhalb des Datenzentrums 410 zuverlässig sind. Es laufen jedoch etliche Informationen, die von einem Gerät innerhalb des Datenzentrums 410 an eine Spielkonsole 402 übertragen werden sollen, durch das Sicherheits-Gateway 404, wo sie in einer solchen Weise verschlüsselt, dass sie nur von der Spielkonsole 402 entschlüsselt werden können, auf die die Informationen abzielen.
8 stellt eine allgemeine Computerumgebung 500 dar, die verwendet werden kann, um die hierin beschriebenen Techniken zu implementieren. Die Computerumgebung 500 ist nur ein Beispiel einer Computerumgebung, und es ist nicht beabsichtigt irgendeine Einschränkung bezüglich des Rahmens der Anwendung und Funktionsweise des Computers und der Netzwerkarchitektur anzudeuten. Die Computerumgebung 500 sollte auch nicht so gedeutet werden, als bestände eine Abhängigkeit von den Anforderungen, die sich auf eine Komponente oder eine Kombination von Komponenten bezieht, die in der beispielhaften Computerumgebung 500 dargestellt sind.
Die Computerumgebung 500 beinhaltet ein Universalrechengerät in der Farm eines Computers 502. Der Computer 502 kann zum Beispiel sein: ein Clientgerät 102, ein Servergerät 106 und/oder ein Gerät, das Teil des Schlüsselverteilungszentrums 104 von 1 ist; ein Sicherheits-Gateway 404, ein Server 412, 416, 418, 422 und/oder 426 von 1 und/oder eine FrontDoor 414, 420 oder 424 von 7. Die Komponenten des Computers 502 können beinhalten sind aber nicht beschränkt auf: einen oder mehrere Prozessoren oder Verarbeitungseinheiten 504, einen Systemspeicher 506 und einen Systembus 508, der verschiedene Systemkomponenten, einschließlich des Prozessors 504 mit dem Systemspeicher 506 koppelt. Der Computer 502 kann auch (einen) kryptografische(n) Prozessor(en) oder Coprozessor(en) beinhalten (nicht in 8 gezeigt). Solche kryptografische Prozessoren oder Coprozessoren sind so konzipiert, das sie kryptografische Operationen durchführen (wie eine Verschlüsselung, eine Entschlüsselung und ein Hashing) und andere Prozessoren (z. B. Verarbeitungseinheit(en) 504) bei den rechenintensiven kryptografischen Operationen entlasten.
Der Systembus 508 verkörpert eine oder mehrere von beliebigen verschieden Arten von Busstrukturen, einschließlich einem Speicherbus oder einem Speichercontroller, einem Peripheriebus, einem beschleunigten Grafikport und einem Prozessor oder einem lokalen Bus, der eine beliebige Busarchitektur aus einer Vielfalt von Busarchitekturen verwendet. Beispielsweise können solche Architekturen einen Industry Standard Architecture(ISA)-Bus, einen Micro Channel Architecture(MCA)-Bus, einen Enhanced ISA(EISA)-Bus, einen lokalen Video Electronics Standards Association(VESA)-Bus und einen Peripheral Component Interconnects(PCI)-Bus, auch als Mezzanine-Bus bekannt, beinhalten.
Der Computer 502 beinhaltet üblicherweise eine Vielfalt von computerlesbaren Medien. Solche Medien können beliebige Medien sein, auf die der Computer 502 zugreifen kann und beinhalten sowohl flüchtige als auch nicht flüchtige Medien, austauschbare und nicht austauschbare Medien.
Der Systemspeicher 506 beinhaltet computerlesbare Medien in der Form eines flüchtigen Speichers, wie eines Arbeitsspeichers (RAM) 510 und/oder eines nicht flüchtigen Speichers, wie eines Festspeichers (ROM) 512. Ein Basisdatenaustauschsystem (BIOS) 514, das die Basisroutinen enthält, die dabei helfen, Informationen zwischen den Elementen innerhalb des Computers zu übertragen, wie während des Hochfahrens, ist in ROM 512 gespeichert. RAM 510 enthält üblicherweise Daten- und/oder Programmmodule auf die durch die Verarbeitungseinheit 504 unmittelbar zugegriffen werden kann und/oder von ihr sogleich verarbeitet werden.
Der Computer 502 kann außerdem andere austauschbare/nicht austauschbare, flüchtige/nicht flüchtige Computer-Speichermedien beinhalten. 8 stellt zum Beispiel folgendes dar: ein Festplattenlaufwerk 516 für das Lesen von und das Schreiben auf ein nicht austauschbares, nicht flüchtiges (nicht gezeigtes) magnetisches Medium, ein Magnetplattenlaufwerk 518 für das Lesen von und das Schreiben auf eine austauschbare, nicht flüchtige Magnetplatte 520 (z. B. eine „Diskette") und ein optisches Plattenlaufwerk 522 für Lesen von und/oder Schreiben auf eine austauschbare, nicht flüchtige optische Platte 524, wie eine CD-ROM, DVD-ROM oder andere optische Medien. Das Festplattenlaufwerk 516, das Magnetplattenlaufwerk 518 und das optisches Plattenlaufwerk 522 sind jeweils durch eine oder mehrere Datenmedien-Schnittstellen 526 mit einem Systembus 508 verbunden. Alternativ können das Festplattenlaufwerk 516, das Magnetplattenlaufwerk 518 und das optisches Plattenlaufwerk 522 über eine oder mehrere (nicht gezeigte) Schnittstellen mit einem Systembus 508 verbunden sein.
Die Plattenlaufwerke und die ihre dazugehörigen computerlesbaren Medien stellen einen nicht flüchtigen Speicher für computerlesbare Befehle, Datenstrukturen, Programmmodule und andere Daten für den Computer 502 bereit. Obwohl das Beispiel ein Festplattenlaufwerk 516, eine austauschbare Magnetplatte 520 und eine austauschbare optische Platte 524 darstellt, wird begrüßt, dass andere Arten von computerlesbaren Medien, die Daten speichern können, auf die ein Computer zugreifen kann, wie Magnetkassetten oder andere magnetische Speichergeräte, Flash-Speicherkarten, CD-ROM, DVD oder andere optische Speicher, Arbeitsspeicher (RAM), Festspeicher (ROM), elektrisch löschbare programmierbare Festspeicher (EEPROM) und Ähnliches verwendet werden können, um das beispielhafte Computersystem und die Umgebung zu implementieren.
Eine Anzahl von Programmmodulen kann auf der Festplatten 516, der Magnetplatte 520, der optischen Platte 524, der ROM 512 und/oder der RAM 510 gespeichert werden, was beispielsweise ein Betriebssystem 526 oder ein oder mehrere Anwendungsprogramme 528, weitere Programmmodule 530 und Programmdaten 532 einschließt. Das Betriebssystem 526, das eine oder die mehreren Anwendungsprogramme 528, die weiteren Programmmodule 530 und die Programmdaten 532 (oder einige Kambinationen davon) können jeweils die gesamten oder einen Teil der residenten Komponenten implementieren, die das verteilte Dateiverwaltungssystem unterstützen.
Ein Anwender kann über Eingabegeräte, wie eine Tastatur 534, und ein Zeigegerät 536 (z. B. eine „Maus") Befehle und Informationen in den Computer 502 eingeben. Andere (nicht speziell gezeigte) Eingabegeräte 538 können ein Mikrofon, einen Joystick, ein Gamepad, eine Satellitenschüssel, einen seriellen Port, einen Scanner und/oder Ähnliches beinhalten. Diese und weitere Eingabegeräte sind mit der Verarbeitungseinheit 504 über Eingabe/Ausgabe-Schnittstellen 540 verbunden, die mit dem Systembus 508 gekoppelt sind, aber sie können auch über andere Schnittstellen- und Busstrukturen verbunden sein, wie einen parallelen Port, einen Gameport, oder einen universellen seriellen Bus (USB).
Ein Monitor 542 oder eine Andere Art von Anzeigegerät kann ebenfalls über eine Schnittstelle, wie einen Videoadapter 544, mit dem Systembus 508 verbunden sein. Zusätzlich zu dem Monitor 542 können weitere Ausgabe-Peripheriegeräte Komponenten wie (nicht gezeigte) Lautsprecher und einen Drucker 546 beinhalten, die über die Eingabe/Ausgabe-Schnittstellen 540 mit dem Computer 502 verbunden sind.
Der Computer 502 kann in einer Netzwerkumgebung arbeiten unter Verwendung von booleschen Verbindungen zu einem oder mehreren entfernten Computern, wie einem entfernten Rechengerät 548. Das entfernte Rechengerät 548 kann beispielsweise ein PC, ein tragbarer Computer, ein Server, ein Router, ein Netzwerkcomputer, ein Peergerät oder ein anderer gemeinsamer Netzwerkknoten, eine Spielkonsole und Ähnliches sein. Das entfernte Rechengerät 548 wird als ein tragbarer Computer dargestellt, der viele oder alle hierin beschriebenen Elemente und Eigenschaften beinhalten kann, die sich auf den Computer 502 beziehen.
Boolesche Verbindungen zwischen dem Computer 502 und dem entfernten Rechengerät 548 werden als ein lokales Netzwerk (LAN) 550 und ein allgemeines Breitbereichsnetz (WAN) 552 dargestellt. Solche Netzwerkumgebungen sind in Büros, unternehmensweiten Computernetzwerken, Intranets und dem Internet alltäglich.
Wenn er in einer LAN-Netzwerkumgebung implementiert wird, ist der Computer 502 über eine Netzwerkschnittstelle oder einen Netzwerkadapter 554 mit einem lokalen Netzwerk 550 verbunden. Wenn er in einer WAN-Netzwerkumgebung implementiert wird, beinhaltet der Computer 502 üblicherweise ein Modem 556 oder eine andere Einrichtung für den Aufbau von Datenübertragungen über das Breitbereichsnetz 552. Das Modem 556, das sich inner halb oder außerhalb des Computers 502 befinden kann, kann über eine Eingabe/Ausgabe-Schnittstelle 540 oder andere geeignete Mechanismen mit dem Systembus 508 verbunden sein. Es sollte begrüßt werden, dass die dargestellten Netzwerkverbindungen beispielhaft sind, und dass andere Einrichtungen für den Aufbau einer (von) Kommunikationsverbindung(en) zwischen den Computern 502 und 548 verwendet werden können.
In einer Netzwerkumgebung, wie sie mit der Rechnerumgebung 500 dargestellt wird, können Programmmodule, die bezüglich des Computers 502 beschrieben werden, oder Teile davon in einem entfernten Speichergerät gespeichert werden. Beispielsweise können sich entfernte Anwendungsprogramme 558 in einem Speichergerät des entfernten Computers 548 befinden. Zu Zwecken der Veranschaulichung werden Anwendungsprogramme und andere ausführbare Programmkomponenten, wie das Betriebssystem, hierin als diskrete Blöcke dargestellt, obwohl anerkannt wird, dass solche Programme und Komponenten sich zu verschiedenen Zeiten in verschiedenen Speicherkomponenten des Rechengeräts 502 befinden und durch den (die) Datenprozessor(en) des Computers ausgeführt werden.
9 zeigt ausführlicher funktionelle Komponenten einer Spielkonsole 601. Die Spielkonsole 601 kann zum Beispiel ein Clientgerät 102 von 1 sein. Die Spielkonsole 601 weist eine zentrale Verarbeitungseinheit (CPU) 600 auf und einen Speichercontroller 602, der dem Prozessor Zugriff auf verschiedene Speicherarten ermöglicht, einschließlich einem Flash-ROM (Festspeicher) 604, einer RAM (Arbeitsspeicher) 606, einem Festplattenlaufwerk 608 und einem tragbaren Medienlaufwerk 609. Die CPU 600 ist mit einem Level 1-Cache 610 und einem Level 2-Cache 612 ausgerüstet, um zeitweise Daten zu speichern und somit die Anzahl der Speicherzugriffszyklen zu reduzieren, wodurch die Verarbeitungsgeschwindigkeit und der Durchsatz verbessert werden.
Die CPU 600, der Speichercontroller 602 und verschiedene Speichergeräte sind über einen oder mehrere Busse, einschließlich serielle und parallele Busse, einem Speicherbus, einem Peripheriebus und einem Prozessorbus oder einem lokalen Bus, die eine beliebige Busarchitektur aus einer Vielfalt von Busarchitekturen verwenden, untereinander verbunden. Solche Architekturen können beispielsweise einen Industry Standard Architecture(ISA)-Bus, einen Micro Channel Architecture(MCA)-Bus, einen Enhanced ISA(EISA)-Bus, einen lokalen Video Electronics Standards Association(VESA)-Bus und einen Peripheral Component Interconnects(PCI)-Bus, auch als ein Mezzanine-Bus bekannt, beinhalten.
Als eine geeignete Implementierung sind die CPU 600, der Speichercontroller 602, der ROM 604 und der RAM 606 in einem gemeinsamen Modul 614 integriert. In dieser Implementierung ist der ROM 604 als ein Flash-ROM konfiguriert, der mit dem Speichercontroller 602 über einen Peripheral Component Interconnects(PCI)-Bus und einen ROM-Bus (keiner von beiden gezeigt) verbunden ist. Der RAM 606 ist als ein Mehrfach-DDR SDRAM (Double Data Rate Synchronous Dynamic RAM) konfiguriert, der über gesonderte (nicht gezeigte) Busse durch den Speichercontroller 602 unabhängig gesteuert wird. Das Festplattenlaufwerk 608 und das tragbare Medienlaufwerk 609 sind über den PCI-Bus und einen ATA(Advanced Technology Attachment)-Bus 616 mit dem Speichercontroller verbunden.
Eine 3D-Grafikverarbeitungseinheit 620 und ein Videocodierer 622 bilden eine Videoverarbeitungsleitung für eine Hochgeschwindigkeits- und Hochauflösungs-Grafikverarbeitung. Die Daten werden über einen (nicht gezeigten) digitalen Videobus von der 3D-Grafikverarbeitungseinheit 620 zu einem Videocodierer 622 übertragen. Eine Audioverarbeitungseinheit 624 und ein Audio-Codec (Coder/Decoder) 626 bilden eine entsprechende Audioverarbeitungsleitung mit einer HiFi-Stereo-Verarbeitung. Audiodaten werden zwischen der Audioverarbeitungseinheit 624 und dem Audio-Codec 626 über eine (nicht gezeigte) Kommunikationsverbindung übertragen. Die Video- und Audioverarbeitungsleitungen geben für die Übertragung an ein Fernsehgerät oder ein anderes Display Daten an einen A/V(Audio/Video)-Port 628 aus. In der dargestellten Implementierung sind die Video- und Audioverarbeitungskomponenten 620-628 in dem Modul 614 befestigt.
Ebenso in dem Modul 614 implementiert sind ein USB-Host-Controller 630 und eine Netzwerkschnittstelle 632. Der USB-Host-Controller 630 ist über einen Bus (z. B. einen PCI-Bus) mit der CPU 600 und dem Speichercontroller 602 gekoppelt und dient als Host für die Peripheriecontroller 636(1)-636(4). Die Netzwerkschnittstelle 632 stellt einen Zugang für ein Netzwerk (z. B. für Internet, Heimnetz etc.) bereit und kann eine beliebige Komponente aus einer breiten Vielfalt von verschiedenen drahtgebundenen oder drahtlosen Schnittstellenkomponenten sein, einschließlich einer Ethernetkarte, eines Modems, eines Bluetoothmoduls, eines Kabelmodems und Ähnliches.
Die Spielkonsole 601 weist zwei Doppelcontroller-Unterstützungsuntergruppen 640(1)-640(2) auf, wobei jede Untergruppe zwei Spielcontroller 636(1)-636(4) unterstützt. Eine Frontplatten-I/O-Untergruppe 642 unterstützt die Funktionsweise eines An-/Aus-Schalters 631 und einer Medienauswurftaste 633 ebenso wie einiger LEDs (Leuchtdioden) oder anderer Indikatoren, die an der Außenfläche der Spielkonsole angeordnet sind. Die Untergruppen 640(1), 640(2) und 642 sind über eine oder mehrere Kabelbaugruppen 644 mit dem Modul 614 gekoppelt.
Acht Speichereinheiten 634(1)-634(8) sind als mit den vier Controllern 636(1)-636(4) verbindbar dargestellt, d. h. zwei Speichereinheiten für jeden Controller. Jede Speichereinheit 634 bietet einen zusätzlichen Speicher, wo Spiele, Spielparameter und andere Daten gespeichert werden können. Sobald sie in einen Controller eingesetzt wird, kann durch den Speichercontroller 602 auf die Speichereinheit 634 zugegriffen werden.
Ein System-Stromversorgungsmodul 650 stellt Strom für die Komponenten der Spielkonsole 601 bereit. Ein Lüfter 652 kühlt die Schaltung innerhalb der Spielkonsole 601.
Eine Konsolen-Anwenderschnittstellen(UI)-Anwendung 660 wird in dem Festplattenlaufwerk 608 gespeichert. Sobald die Spielkonsole angeschaltet wird, werden verschiedene Teile der Konsolenanwendung 660 in den RAM 606 und/oder die Caches 610 und 612 geladen und in der CPU 600 ausgeführt. Die Konsolenanwendung 660 stellt eine grafische Anwenderschnittstelle dar, die eine beständige Anwenderpraxis während des Navigierens zu verschiedenen Medientypen, die in der Spielkonsole verfügbar sind, bereitstellt.
Die Spielkonsole 601 implementiert ein Kryptografiegerät, um gemeinsame Kryptografiefunktionen, wie Verschlüsselung, Entschlüsselung, Authentifikation, digitales Signieren, Hashing und Ähnliches durchzuführen. Das Kryptagrafiegerät kann als ein Teil der CPU 600 implementiert sein, oder in der Software, die in dem Festplattenlaufwerk 608 gespeichert ist, die in der CPU ausgeführt wird, so dass die CPU so konfiguriert ist, dass sie die kryptografischen Funktionen durchführt. Alternativ kann ein kryptografischer Prozessor oder Coprozessor, der so aufgebaut ist, dass er die kryptografischen Funktionen durchführt, in der Spielkonsole 601 enthalten sein.
Die Spielkonsole kann als ein Einzelgerätsystem betrieben werden, indem das System einfach an ein Fernsehgerät oder ein anderes Display angeschlassen wird. In diesem Einzelgerätmodus erlaubt die Spielkonsole 601 einem oder mehreren Spielern, Spiele zu spielen, Filme anzuschauen oder Musik zu hören. Mit der Integration einer Breitbandnetzwerkfähig keit, die durch die Netzwerkschnittstelle 632 verfügbar gemacht wird, kann die Spielkonsole 601 jedoch, wie oben besprochen, ferner als ein Teilnehmer beim Online-Spielen betrieben werden.
Verschiedene Module und Techniken können hierin im allgemeinen Zusammenhang mit computerausführbaren Befehlen, wie Programmmodulen, die von einem oder mehreren Computern oder anderen Geräten ausgeführt werden, beschrieben werden. Im Allgemeinen beinhalten Programmmodule Routinen, Programme, Objekte, Komponenten, Datenstrukturen etc., die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen implementieren. Üblicherweise kann die Funktionsweise der Programmmodule kombiniert oder verteilt werden, wie es in verschiedenen Ausführungsformen gewünscht wird.
Eine Implementierung dieser Module und Techniken kann in Einigen der computerlesbaren Medien gespeichert werden oder von ihnen übertragen werden. Computerlesbare Medien können beliebige verfügbare Medien sein, auf die ein Computer zugreifen kann. Zum Beispiel, aber nicht darauf begrenzt, können computerlesbare Medien "Computerspeichermedien" und "Kommunikationsmedien" umfassen.
"Computerspeichermedien" beinhalten flüchtige und nicht flüchtige, austauschbare und nicht austauschbare Medien, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen, wie computerlesbaren Befehlen, Datenstrukturen, Programmmodulen oder anderen Daten, implementiert werden. Computerspeichermedien beinhalten, sind aber nicht beschränkt auf: RAM, ROM, EEPROM, Flash-Speicher oder eine andere Speichertechnologie, CD-ROM, DVD oder andere optische Speicher, Magnetkassetten, ein Magnetband, einen magnetischen Plattenspeischer oder andere magnetische Speichergeräte, oder ein beliebiges anderes Medium, das verwendet werden kann, um die gewünschten Informationen zu speichern und auf das ein Computer zugreifen kann.
"Kommunikationsmedien" verkörpern üblicherweise computerlesbare Befehle, Datenstrukturen, Programmmodule oder andere Daten in einem modulierten Datensignal, wie einer Trägerwelle oder einem anderen Transportmechanismus. Kommunikationsmedien beinhalten ebenfalls beliebige Informationszufuhrmedien. Der Begriff „moduliertes Datensignal" meint ein Signal, bei dem eine oder mehrere seiner Eigenschaften in einer solchen Weise festgelegt oder verändert sind, dass Informationen in dem Signal codiert sind. Kammunikations median beinhalten zum Beispiel und nicht darauf beschränkt: drahtgebundene Medien, wie ein drahtgebundenes Netzwerk oder eine direktverdrahtete Verbindung, und drahtlose Medien, wie akustische, HF-, Infrarot- und andere drahtlose Medien. Kombinationen von beliebigen oben erwähnten Medien fallen ebenfalls in den Rahmen computerlesbarer Medien.
Der gesicherte Schlüsselaustausch mit gegenseitiger Authentifikation wird hierin unter Bezug auf die Diffie-Hellman-Exponentialoperationen behandelt, um ein Geheimnis abzuleiten. Alternativ können andere Kryptografieoperationen oder -verfahren anstelle von Diffie-Hellman verwendet werden.
Obwohl die obige Beschreibung eine Sprache verwendet, die für die strukturellen Eigenschaften und/oder methodologischen Vorgänge spezifisch ist, sollte verstanden werden, dass die Erfindung, die in den beigefügten Ansprüchen umgrenzt wird, nicht auf die beschriebenen spezifischen Eigenschaften oder Vorgänge begrenzt ist. Vielmehr werden die spezifischen Eigenschaften und Vorgänge als beispielhafte Formen der Implementierung der Erfindung offengelegt.

Claims

Verfahren, das in einem Clientgerät (102, 402(1)-402(n), 502, 601) implementiert ist, welches einen in nachfolgenden sicheren Kommunikationen zwischen dem Clientgerät und einem Servergerät (106, 404, 502) zu benutzenden Schlüssel etabliert, wobei das Verfahren folgende Schritte umfasst: Generieren (202) einer Schlüsselaustauschinitiatornachricht; Berechnen (204) eines Auszugs (digest) der Schlüsselaustauschinitiatornachricht; Generieren (206) eines Authentifikators zumindest teilweise auf Basis des Auszugs; Verschlüsseln (208) des Authentifikators; Generieren (210) eines Schlüsselaustauschinitiatorpakets, das die Schlüsselaustauschinitiatornachricht, den verschlüsselten Authentifikator und ein Sicherheitsticket enthält; Senden (212) des Schlüsselaustauschinitiatorpakets an das Servergerät; Empfangen (352) eines Schlüsselaustauschantwortpakets von dem Servergerät; Entschlüsseln (354) einer in dem Schlüsselaustauschantwortpaket enthaltenen Antwortnachricht; Überprüfen (356), ob eine Zeitmarke in der Antwortnachricht die gleiche wie eine zuvor durch das Clientgerät an das Servergerät gesandte Zeitmarke ist; Berechnen (360) eines Auszugwertes (digest value) einer in dem Schlüsselaustauschantwortpaket enthaltenen Schlüsselaustauschantwortnachricht; und Feststellen (356, 362), dass das Schlüsselaustauschantwortpaket gültig ist, nur dann, wenn die Zeitmarke in der Antwortnachricht die gleiche wie die zuvor durch das Clientgerät an das Servergerät gesandte Zeitmarke ist und wenn der berechnete Auszugswert des Schlüsselaustauschantwortpakets der gleiche wie ein in dem Schlüsselaustauschantwortpaket enthaltener Auszugswert ist.
Verfahren nach Anspruch 1, wob die Generierung der Schlüsselaustauschinitiatornachricht umfasst: Generieren eines ersten Wertes NonceInit; Generieren eines zweiten Wertes X; Verwenden des zweiten Wertes X, um einen Diffie-Hellman-Wert g^X mod N zu generieren; und Einfügen des ersten Wertes NonceInit und des Diffie-Hellman-Wertes g^X mod N in die Schlüsselaustauschinitiatornachricht.
Verfahren nach Anspruch 1 oder 2, wobei die Berechnung des Auszugs der Schlüsselaustauschinitiatornachrichtumfasst: Verwenden eines Kerberos-Sitzungsschlüssels K_CA, welcher zuvor von einem Schlüsselverteilungscenter (104, 502) empfangen wurde, und einer Hash-Funktion, um den Auszug zu berechnen.
Verfahren nach einem der Ansprüche 1 bis 3, wobei die Generierung des Authentifikators umfasst: Generieren einer aktuellen Zeitmarke; und Einfügen der aktuellen Zeitmarke und des Auszugs der Schlüsselaustauschinitiatornachricht in den Authentifikator.
Verfahren nach einem der Ansprüche 1 bis 4, wobei die Verschlüsselung des Authentifikators ein Verschlüsseln des Authentifikators zumindest teilweise auf Basis eines zuvor von einem Schlüsselverteilungscenter (104, 502) empfangenen Kerberos-Sitzungsschlüssels K_CA umfasst.
Verfahren nach einem der Ansprüche 1 bis 5, wobei die Generierung des Schlüsselaustauschinitiatorpakets ein Einfügen folgender Elemente in das Schlüsselaustauschinitiatorpaketumfasst: der Schlüsselaustauschinitiatornachricht; eines vorbestimmten Sicherheitsparameter-Index-Wertes, um anzugeben, dass eine Etablierung einer neuen Sicherheitsassoziation initiiert wird; des verschlüsselten Authentifikators; und des Sicherheitstickets.
Verfahren nach einem der Ansprüche 1 bis 6, wobei das Sicherheitsticket ein Kerberos-Ticket umfasst.
Verfahren nach einem der Ansprüche 1 bis 7, das ferner der Etablierung eines wechselseitigen Schlüssels zur Benutzung in den Kommunikationen mit dem Servergerät dient, wobei das Senden des Schlüsselaustauschinitiatorpakets an das Servergerät ein Senden des Schlüsselaustauschinitiatorpakets an das Servergerät über ein Netzwerk (406, 550, 552) umfasst, wobei das Schlüsselaustauschinitiatorpaket den wechselseitigen Schlüssel nicht enthält; wobei das Empfangen des Schlüsselaustauantwortpakets von dem Servergerät ein Empfangen (352) eines Schlüsselaustauschantwortpakets, das den wechselseitigen Schlüssel nicht enthält, von dem Servergerät über das Netzwerk umfasst; und wobei das Verfahren ferner umfasst: Validieren (354-362) des Schlüsselaustauschantwortpakets; und Generieren (162, 364) des wechselseitigen Schlüssels zumindest teilweise auf Basis von Daten in dem Schlüsselaustauschantwortpaket, ohne das Erfordernis, dass zusätzliche Pakete an das Servergerät gesandt werden oder von dem Servergerät empfangen werden, um den wechselseitigen Schlüssel zu generieren.
Verfahren nach Anspruch 8, wobei das Schlüsselaustauschinitiatorpaket dem Servergerät, das das Schlüsselaustauschantwortpaket sendet, erlaubt, den gleichen wechselseitigen Schlüssel zu generieren (158, 302), ohne dass es erforderlich ist, zusätzliche Pakete an das Servergerät zu senden, um den Schlüssel zu generieren.
Verfahren nach Anspruch 8 oder 9, wobei die Generierung des Schlüsselaustauschinitiatorpakets umfasst: Generieren der Schlüsselaustauschinitiatornachricht; Berechnen des Auszugs der Schlüsselaustauschinitiatornachricht; Generieren des Authentifikators zumindest teilweise auf Basis des Auszugs; und Verschlüsseln des Authentifikators.
Verfahren nach einem der Ansprüche 8 bis 10, wobei die Validierung des Schlüsselaustauschantwortpakets folgende Schritte umfasst: Empfangen des Schlüsselaustauschantwortpakets von dem Servergerät; Entschlüsseln der in dem Schlüsselaustauschantwortpaket enthaltenen Antwortnachricht; Überprüfen, ob die Zeitmarke in der Antwortnachricht die gleiche wie die zuvor an das Servergerät gesandte Zeitmarke ist; Berechnen des Auszugswertes der in dem Schlüsselaustauschantwortpaket enthaltenen Schlüsselaustauschantwortnachricht; und Feststellen, dass das Schlüsselaustauschantwortpaket gültig ist, nur dann, wenn die Zeitmarke in der Antwortnachricht die gleiche wie die zuvor an das Gerät gesandte Zeitmarke ist und wenn der berechnete Auszugswert des Schlüsselaustauschantwortpakets der gleiche wie der in dem Schlüsselaustauschantwortpaket enthaltene Auszugswert ist.
Verfahren nach einem der Ansprüche 8 bis 11, wobei die Generierung des Schlüssels umfasst: Wiedergewinnen (retrieving) eines Diffie-Hellman-Wertes g^Y mod N aus dem Schlüsselaustauschantwortpaket; Erhalten eines Wertes X, welcher früher zufällig generiert wurde; Berechnen eines Diffie-Hellman-Wertes g^XY mod N; und Generieren des Schlüssels zumindest teilweise auf Basis des Diffie-Hellman-Wertes g^XY mod N.
Verfahren nach einem der Ansprüche 1 bis 12, wobei das Entschlüsseln der Antwortnachricht ein Entschlüsseln der Antwortnachricht unter Benutzung eines zuvor durch das Clientgerät von einem Schlüsselverteilungscenter (104, 502) erhaltenen Kerberos-Sitzungsschlüssels umfasst.
Verfahren nach einem der Ansprüche 1 bis 13, ferner umfassend: Wiedergewinnen (retrieving) eines Diffie-Hellman-Wertes g^Y mod N aus dem Schlüsselaustauschantwortpaket; Berechnen eines Diffie-Hellman Wertes g^XY mod N unter Benutzung eines zuvor generierten Wertes X; und Generieren des Schlüssels zumindest teilweise auf Basis des Diffie-Hellman-Wertes g^XY mod N.
Verfahren, das in einem Servergerät (106, 404, 502) implementiert ist, welches einen in nachfolgenden sicheren Kommunikationen zwischen dem Servergerät und einem Clientgerät (102, 402(1)-402(n), 502, 601) zu benutzenden Schlüssel etabliert, wobei das Verfahren folgende Schritte umfasst: Empfangen (252) eines Schlüsselaustauschinitiatorpakets von dem Clientgerät; Entschlüsseln (254) eines Sicherheitstickets in dem Schlüsselaustauschinitiatorpaket; Entschlüsseln (260) eines Authentifikators in dem Schlüsselaustauschinitiatorpaket; Berechnen (264) eines Auszugs (digest) einer Schlüsselaustauschnachricht in dem Schlüsselaustauschinitiatorpaket; Feststellen (256, 262, 266, 268), dass das Schlüsselaustauschinitiatorpaket gültig ist, nur dann, wenn alle der folgenden Bedingungen erfüllt sind: das Sicherheitsticket ist nicht abgelaufen (stale), eine Zeitmarke in dem Authentifikator ist akzeptabel, der berechnete Auszug der Schlüsselaustauschnachricht gleicht einem als Teil des Authentifikators enthaltenen Auszugswert (digest value), und der Authentifikator wurde nicht wiederverwendet (replayed); Generieren (304) einer Schlüsselaustauchantwortnachricht; Berechnen (306) eines Auszugs der Schlüsselaustauschantwortnachricht; Generieren (308) einer Antwortnachricht; Verschlüsseln (310) der Antwortnachricht; Generieren (312) eines Schlüsselaustauschantwortpakets, welches sowohl die Schlüsselaustauschantwortnachricht als auch die verschlüsselte Antwortnachricht enthält; und Senden (314) des Schlüsselaustauschantwortpakets an das Clientgerät.
Verfahren nach Anspruch 15, wobei die Entschlüsselung des Sicherheitstickets umfasst: Entschlüsseln des Sicherheitstickets unter Benutzung eines gemeinsamen (shared) Schlüssels des Servergeräts und eines Schlüsselverteilungscenters, welches dem Clientgerät das Sicherheitsticket gegeben hat.
Verfahren nach Anspruch 15 oder 16, ferner umfassend die Feststellung (256), dass das Sicherheitsticket abgelaufen ist, wenn eine aktuelle Zeit nicht in einer in dem Sicherheitsticket identifizierten Zeitspanne enthalten ist.
Verfahren nach einem der Ansprüche 15 bis 17, ferner umfassend die Feststellung (262), dass die Zeitmarke in dem Authentifikator akzeptable ist, wenn die Zeitmarke innerhalb einer Zeitschwelle einer aktuellen Zeit liegt.
Verfahren nach einem der Ansprüche 15 bis 18, ferner umfassend die Feststellung (268), dass der Authentifikator wiederverwendet wurde, wenn die Zeitmarke nicht neuer als eine letzte durch das Servergerät von dem Clientgerät empfangene Zeitmarke ist.
Verfahren nach einem der Ansprüche 15 bis 19, ferner umfassend: Wiedergewinnen (retrieving) eines Diffie-Hellman-Wertes g^X mod N aus dem Schlüsselaustauschinitiatorpaket; Generieren eines Zufallswertes Y; Senden eines Diffie-Hellman-Wertes g^Y mod N in einer Antwort auf das Schlüsselaustauschinitiatorpaket; Berechnen eines Diffie-Hellman-Wertes g^XY mod N; und Generieren des Schlüssels zumindest teilweise auf Basis des Diffie-Hellman-Wertes g^XY mod N.
Verfahren nach einem der Ansprüche 15 bis 20, wobei das Empfangen des Schlüsselaustauschinitiatorpakets ein Empfangen des Schlüsselaustauschinitiatorpakets von dem Clientgerät über ein Netzwerk (406, 550, 552) umfasst, wobei das Schlüsselaustauschinitiatorpaket den Schlüssel nicht enthält; wobei das Verfahren ferner umfasst: Validieren (254-270) des Schlüsselaustauschinitiatorpakets; und Generieren (156, 302) des Schlüssels zumindest teilweise auf Basis von Daten in dem Schlüsselaustauschinitiatorpaket ohne das Erfordernis, dass zusätzliche Pakete von dem Clientgerät empfangen werden, um den Schlüssel zu generieren; und wobei das Senden des Schlüsselaustauschantwortpakets an das Clientgerät ein Senden (314) eines Schlüsselaustauschantwortpakets, das den Schlüssel nicht enthält, an das Clientgerät über das Netzwerk umfasst.
Verfahren nach Anspruch 21, wobei das Schlüsselaustauschantwortpaket Informationen enthält, die es dem Clientgerät erlauben, den Schlüssel zu generieren, ohne dass es erforderlich ist, zusätzliche Pakete an das Clientgerät zu senden, um den Schlüssel zu generieren.
Verfahren nach Anspruch 21 oder 22, wobei die Validierung des Schlüsselaustauschinitiatorpakets umfasst: Entschlüsseln des Sicherheitstickets in dem Schlüsselaustauschinitiatorpaket; Entschlüsseln des Authentifikators in dem Schlüsselaustauschinitiatorpaket; Berechnen des Auszugs der Schlüsselaustauschnachricht in dem Schlüsselaustauschinitiatorpaket; und Feststellen, dass das Schlüsselaustauschinitiatorpaket gültig ist, nur dann, wenn alle der folgenden Bedingungen erfüllt sind: das Sicherheitsticket ist nicht abgelaufen, die Zeitmarke in dem Authentifikator ist akzeptabel, der berechnete Auszug der Schlüsselaustauschnachricht gleicht dem als Teil des Authentifikators enthaltenen Auszugswert, und der Authentifikator wurde nicht wiederverwendet.
Verfahren nach einem der Ansprüche 21 bis 23, wobei die Generierung des Schlüssels umfasst: Wiedergewinnen (retrieving) eines Diffie-Hellman-Wertes g^X mod N aus dem Schlüsselaustauschinitiatorpaket; Generieren eines zufälligen Diffie-Hellman-Wertes Y; Einfügen von g^Y mod N als Teil der Schlüsselaustauschantwort; Berechnen eines Diffie-Hellman-Wertes g^XY mod N; und Generieren des Schlüssels zumindest teilweise auf Basis des Diffie-Hellman-Wertes g^XY mod N.
Verfahren nach einem der Ansprüche 15 bis 24, wobei die Generierung der Schlüsselaustauschantwortnachricht umfasst: Generieren eines ersten Wertes NonceResp; Generieren eines zweiten Wertes Y; Verwenden des zweiten Wertes Y, um einen Diffie-Hellman-Wert g^Y mod N zu generieren; und Einfügen folgender Elemente in die Schlüsselaustauschantwortnachricht: eines zuvor von dem Clientgerät empfangenen NonceInit-Wertes, des ersten Wertes NonceResp, des Diffie-Hellman-Wertes g^Y mod N, und eines zuvor von dem Clientgerät empfangenen Zeitmarkenwertes.
Verfahren nach einem der Ansprüche 15 bis 25, wobei die Berechnung des Auszugs der Schlüsselaustauschantwortnachricht umfasst: Verwenden eines Kerberos-Sitzungsschlüssels K_CA, der zuvor von dem Clientgerät als Teil eines Kerberos-Tickets empfangen wurde, und einer Hash-Funktion, um den Auszug zu berechnen.
Verfahren nach einem der Ansprüche 15 bis 26, wobei die Generierung der Antwortnachricht ein Einfügen sowohl einer zuvor von dem Clientgerät empfangenen Zeitmarke als auch des Auszugs der Schlüsselaustauschantwortnachricht in die Antwortnachricht umfasst.
Verfahren nach einem der Ansprüche 15 bis 27, wobei die Verschlüsselung der Antwortnachricht ein Verschlüsseln der Antwortnachricht zumindest teilweise auf Basis eines Kerberos-Sitzungsschlüssels K_CA der zuvor als Teil eines Kerberos-Tickets von dem Clientgerät empfangen wurde, umfasst.
Verfahren nach einem der Ansprüche 15 bis 28, wobei die Generierung des Schlüsselaustauschantwortpakets ein Einfügen folgender Elemente in das Schlüsselaustauschantwortpaket umfasst: der Schlüsselaustauschantwortnachricht; der verschlüsselten Antwortnachricht; und eines Sicherheitsparameter-Index-Wertes, der verwendet wird, um die nachfolgenden sicheren Kommunikationen von dem Servergerät an das Clientgerät zu identifizieren.
Verfahren nach einem der Ansprüche 1 bis 29, wobei das Schlüsselaustauschinitiatorpaket und/oder das Schlüsselaustauschantwortpaket das Erreichen perfekter Vorwärtsgeheimhaltung (perfect forward secrecy) erlaubt.
Verfahren nach einem der Ansprüche 1 bis 30, ferner umfassend: Kommunizieren des Clientgeräts und des Servergeräts miteinander über einen einzigen Rundlauf (roundtrip) über ein Netzwerk (406, 550, 552), um einen Sicherheitsschlüssel sicher auszutauschen und die Geräte wechselseitig zu authentifizieren sowie perfekte Vorwärtsgeheimhaltung (pertect forward secrecy) zu erreichen.
Verfahren nach Anspruch 31, wobei ein anderes Gerät in dem Netzwerk nicht in der Lage ist, den Schlüssel aus dem einzigen Rundlauf über das Netzwerk abzuleiten.
Verfahren nach einem der Ansprüche 1 bis 32, wobei das Clientgerät eine Spielekonsole (402(1)-402(n), 601) umfasst.
Verfahren nach einem der Ansprüche 1 bis 33, wobei das Servergerät ein Datencenter-Sicherheitsgateway (404) umfasst.
Ein oder mehrere computerlesbare Medien (506, 510, 512, 516, 520, 524, 548), die eine Vielzahl von Befehlen gespeichert haben, welche, wenn sie durch einen oder mehrere Prozessoren (504) eines Servergeräts (106, 404, 502) beim Etablieren eines in nachfolgenden sicheren Kommunikationen zwischen dem Servergerät und einem Clientgerät (102, 402(1)-402(n), 502, 601) zu verwendenden Schlüssels ausgeführt werden, die einen oder mehrere Prozessoren zu folgenden Schritten veranlassen: Empfangen (252) eines Schlüsselaustauschinitiatorpakets; Entschlüsseln (254) eines Sicherheitstickets in dem Schlüsselaustauschinitiatorpaket; Überprüfen (256), ob eine aktuelle Zeit innerhalb einer in dem Sicherheitsticket identifizierten Zeitspanne liegt, und Angeben (258), dass der Schlüssel nicht etabliert werden kann, wenn die aktuelle Zeit nicht innerhalb der in dem Sicherheitsticket identifizierten Zeitspanne liegt; Entschlüsseln (260) eines Authentifikators in dem Schlüsselaustauschinitiatorpaket; Überprüfen (262), ob eine Zeitmarke in dem Authentifikator innerhalb einer Zeitschwelle der aktuellen Zeit liegt, und Angeben (258), dass der Schlüssel nicht etabliert werden kann, wenn die Zeitmarke nicht innerhalb der Zeitschwelle der aktuellen Zeit liegt; Berechnen (264) eines Auszugswertes (digest value) einer Schlüsselaustauschnachricht in dem Schlüsselaustauschinitiatorpaket; Überprüfen (266), ob der berechnete Auszugswert einem als Teil des Authentifikators enthaltenen Auszugswert gleicht, und Angeben (258), dass der Schlüssel nicht etabliert werden kann, wenn der berechnete Auszugswert dem als Teil des Authentifikators enthaltenen Auszugswert nicht gleicht; Generieren (304) einer Schlüsselaustauschantwortnachricht; Berechnen (306) eines Auszugs (digest) der Schlüsselaustauschantwortnachricht; Generieren (308) einer Antwortnachricht, die den Auszug und eine zuvor von dem Clientgerät empfangene Zeitmarke enthält; Verschlüsseln (310) der Antwortnachricht; Generieren (312) eines Schlüsselaustauschantwortpakets, das sowohl die Schlüsselaustauschantwortnachricht als auch die verschlüsselte Antwortnachricht enthält; und Senden (314) des Schlüsselaustauschantwortpakets an das Clientgerät.
Ein oder mehrere computerlesbare Medien nach Anspruch 35, wobei die Befehle ferner die ein oder mehreren Prozessoren zu folgenden Schritten veranlassen: Überprüfen (268), ob die Zeitmarke neuer als eine letzte durch das Servergerät von dem Clientgerät empfangene Zeitmarke ist, und Angeben (258), dass der Schlüssel nicht etabliert werden kann, wenn die Zeitmarke nicht neuer als die letzte Zeitmarke ist.
Ein oder mehrere computerlesbare Medien nach Anspruch 35 oder 36, wobei die Befehle ferner die ein oder mehreren Prozessoren zu folgenden Schritten veranlassen: Wiedergewinnen (retrieve) eines Diffie-Hellman-Wertes g^X mod N aus dem Schlüsselaustauschinitiatorpaket; Generieren eines Zufallswertes Y; Senden eines Diffie-Hellman-Wertes g^Y mod N als Teil einer Antwort auf das Schlüsselaustauschinitiatorpaket; Berechnen eines Diffie-Hellman-Wertes g^XY mod N; und Generieren des Schlüssels zumindest teilweise auf Basis des Diffie-Hellman-Wertes g^XY mod N.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 35 bis 37, wobei das Schlüsselaustauschinitiatorpaket das Erreichen perfekter Vorwärtsgeheimhaltung (perfect forward secrecy) erlaubt.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 35 bis 38, wobei die Befehle, die die ein oder mehreren Prozessoren zum Berechnen des Auszugs der Schlüsselaustauschantwortnachricht veranlassen, Befehle umfassen, die die ein oder mehreren Prozessen dazu veranlassen, den Auszug der Schlüsselaustauschantwortnachricht zumindest teilweise auf Basis eines Kerberos-Sitzungsschlüssels zu berechnen.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 35 bis 39, wobei die Befehle, die die ein oder mehreren Prozessoren zum Generieren der Schlüsselaustauschantwortnachricht veranlassen, Befehle umfassen, die die ein oder mehreren Prozessoren zu folgenden Schritten veranlassen: Generieren eines ersten Wertes NonceResp; Generieren eines zweiten Wertes Y; Verwenden des zweiten Wertes Y, um einen Diffie-Hellman-Wert g^Y mod N zu erzeugen; und Einfügen der folgenden Elemente in die Schlüsselaustauschantwortnachricht: eines zuvor von dem Clientgerät empfangenen NonceInit-Wertes, des ersten Wertes NonceResp, des Diffie-Hellman-Wertes g^Y mod N, und des Zeitmarkenwertes.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 35 bis 40, wobei die Befehle, die die ein oder mehreren Prozessoren zum Verschlüsseln der Antwortnachricht veranlassen, Befehle umfassen, die die ein oder mehreren Prozessoren zum Verschlüsseln der Antwortnachricht zumindest teilweise auf Basis des Kerberos-Sitzungsschlüssels veranlassen.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 35 bis 41, wobei die Befehle, die die ein oder mehreren Prozessoren zur Generierung des Schlüsselaustauschantwortpakets veranlassen, Befehle umfassen, die die ein oder mehreren Prozessoren zum Einfügen folgender Elemente in das Schlüsselaustauschantwortpaket veranlassen: der Schlüsselaustauschantwortnachricht; der verschlüsselten Antwortnachricht; und eines Sicherheitsparameter-Index-Wertes, der verwendet wird, um die nachfolgenden sicheren Kommunikationen von dem Servergerät an das Clientgerät zu identifizieren.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 35 bis 42, wobei das Schlüsselaustauschantwortpaket das Erreichen perfekter Vorwärtsgeheimhaltung (perfect forward secrecy) erlaubt.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 35 bis 43, wobei die Befehle die ein oder mehreren Prozessoren ferner zu folgendem Schritt veranlassen: Durchführen eines Schlüsselaustauschs mit dem Clientgerät in einem einzigen Rundlauf (roundtrip) über ein Netzwerk (406, 550, 552), wobei sowohl wechselseitige Authentifikation mit dem Clientgerät als auch perfekte Vorwärtsgeheimhaltung (perfect forward secrecy) erreicht wird.
Ein oder mehrere computerlesbare Medien nach Anspruch 44, wobei die wechselseitige Authentifikation auf Basis eines Kerberos-Authentifikationsprotokolls erreicht wird.
Ein oder mehrere computerlesbare Medien nach Anspruch 44 oder 45, wobei die perfekte Vorwärtsgeheimhaltung auf Basis von in dem einzigen Rundlauf über das Netzwerk enthaltenen Diffie-Hellman-Werten erreicht wird.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 44 bis 46, wobei der einzige Rundlauf über das Netzwerk eine Schlüsselaustauschinitiatornachricht enthält und wobei die Befehle, wenn sie durch die ein oder mehreren Prozessoren ausgeführt werden, die ein oder mehreren Prozessoren zum Verifizieren (266) eines Auszugs der Schlüsselaustauschinitiatornachricht veranlassen, um zu verifizieren, dass die Schlüsselaustauschinitiatornachricht nicht verfälscht (tampered with) wurde.
Ein oder mehrere computerlesbare Medien nach Anspruch 47, wobei die Befehle, wenn sie durch die ein oder mehreren Prozessoren ausgeführt werden, ferner die ein oder mehreren Prozessoren zum Generieren (264) des Auszugs der Schlüsselaustauschinitiatornachricht unter Benutzung einer schlüsselbasierten (keyed) Hash-Funktion veranlassen.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 44 bis 48, wobei der einzige Rundlauf über das Netzwerk eine Schlüsselaustauschinitiatornachricht enthält und wobei die Befehle, wenn sie durch die ein oder mehreren Prozessoren ausgeführt werden, die ein oder mehreren Prozessoren zum Überprüfen (262), ob eine in der Schlüsselaustauschinitiatornachricht enthaltene Zeitmarke innerhalb einer Zeitschwelle der aktuellen Zeit liegt, und zum Beantworten der Schlüsselaustauschinitiatornachricht nur dann, wenn die Zeitmarke innerhalb der Zeitschwelle der aktuellen Zeit liegt, veranlassen.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 44 bis 49, wobei der einzige Rundlauf über das Netzwerk eine Schlüsselaustauschinitiatornachricht umfasst und wobei die Befehle, wenn sie durch die ein oder mehreren Prozessoren ausgeführt werden, die ein oder mehreren Prozessoren zum Überprüfen (268), ob eine in der Schlüsselaustauschinitiatornachricht enthaltene Zeitmarke neuer ist als eine letzte von dem Clientgerät empfangene Zeitmarke ist, und zum Beantworten der Schlüsselaustauschinitiatornachricht nur dann, wenn die Zeitmarke neuer als die letzte von dem Clientgerät empfangene Zeitmarke ist, veranlassen.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 44 bis 50, wobei das Netzwerk das Internet (552) umfasst.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 44 bis 51, wobei die Vielzahl von Befehlen die ein oder mehreren Prozessoren ferner zu folgenden Schritten veranlassen: Empfangen (252) eines Schlüsselaustauschinitiatorpakets, das den Schlüssel nicht enthält, von dem Clientgerät; Validieren (254-270) des Schlüsselaustauschinitiatorpakets; Generieren (302) des Schlüssels zumindest teilweise auf Basis von Daten in dem Schlüsselaustauschinitiatorpaket, ohne das Erfordernis, dass zusätzliche Pakete von dem Clientgerät empfangen werden, um den Schlüssel zu generieren; und Senden (314) eines Schlüsselaustauschantwortpakets, das den Schlüssel nicht enthält, an das Clientgerät.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 44 bis 52, wobei der einzige Rundlauf über das Netzwerk eine Schlüsselaustauschantwortnachricht enthält und wobei die ein oder mehreren computerlesbaren Medien ferner Befehle haben, die, wenn sie durch einen oder mehrere Prozessoren (504, 600) des Clientgeräts ausgeführt werden, die ein oder mehreren Prozessoren des Clientgeräts zum Verifizieren (362) eines Auszugs der Schlüsselaustauschantwortnachricht und zum Verifizieren, dass die Schlüsselaustauschantwortnachricht nicht verfälscht (tampered with) wurde, veranlassen.
Ein oder mehrere computerlesbare Medien nach Anspruch 53, wobei die Befehle, wenn sie durch die ein oder mehreren Prozessoren des Clientgeräts ausgeführt werden, ferner die ein oder mehreren Prozessoren des Clientgeräts zum Generieren (360) des Auszugs der Schlüsselaustauschantwortnachricht unter Benutzung einer schlüsselbasierten (keyed) Hash-Funktion veranlassen.
Ein oder mehrere computerlesbare Medien nach einem der Ansprüche 44 bis 54, wobei die ein oder mehreren computerlesbaren Medien ferner Befehle haben, die, wenn sie durch einen oder mehrere Prozessoren (504, 600) des Clientgeräts ausgeführt werden, die ein oder mehreren Prozessoren des Clientgeräts zu folgenden Schritten veranlassen: Senden (212) eines Schlüsselaustauschinitiatorpakets, das den Schlüssel nicht enthält, an das Servergerät; Empfangen (352) eines Schlüsselaustauschantwortpakets, das den Schlüssel nicht enthält, von dem Servergerät; Validieren (354-362) des Schlüsselaustauschantwortpakets; und Generieren (364) des Schlüssels zumindest teilweise auf Basis von Daten in dem Schlüsselaustauschantwortpaket, ohne das Erfordernis, dass zusätzliche Pakete an das Servergerät gesandt oder von dem Servergerät empfangen werden, um den Schlüssel zu generieren.
Ein oder mehrere computerlesbare Medien (506, 510, 512, 516, 520, 524, 548), die eine Vielzahl von Befehlen gespeichert haben, welche, wenn sie durch ein oder mehrere Prozessoren (504, 600) eines Clientgeräts (102, 402(1)-402(n), 502, 601) beim Etablieren eines in nachfolgenden sicheren Kommunikationen zwischen dem Clientgerät und einem Servergerät (106, 404, 502) zu benutzenden Schlüssels ausgeführt werden, die ein oder mehrere Prozessoren zum Durchführen des Verfahrens nach einem der Ansprüche 1 bis 14 veranlassen.
System (100, 500) umfassend: ein Clientgerät (102, 402(1)-402(n), 502, 601), das dazu konfiguriert ist, einen Sitzungsschlüssel von einem Schlüsselverteilungscenter (104, 428) zu erhalten; und ein Servergerät (106, 404, 502), das über ein Netzwerk (406, 550, 552) an das Clientgerät gekoppelt ist und dazu konfiguriert ist, mit dem Clientgerät zu kommunizieren und in einem einzigen Rundlauf (roundtrip) über das Netzwerk sicher einen Schlüssel auszutauschen und sich wechselseitig zu authentifizieren sowie perfekte Vorwärtsgeheimhaltung (perfect forward secrecy) zu erreichen; und wobei das Clientgerät und das Servergerät dazu konfiguriert sind, das Verfahren nach einem der Ansprüche 1 bis 14 bzw. nach einem der Ansprüche 15 bis 34 durchzuführen.
System nach Anspruch 57, wobei das Clientgerät ferner zu folgenden Schritten konfiguriert ist: Senden (212) eines Schlüsselaustauschinitiatorpakets, das den Schlüssel nicht enthält, an das Servergerät; Empfangen (352) eines Schlüsselaustauschantwortpakets, das den Schlüssel nicht enthält, von dem Servergerät; Validieren (354-362) des Schlüsselaustauschantwortpakets; und Generieren (364) des Schlüssels zumindest teilweise auf Basis von Daten in dem Schlüsselaustauschantwortpaket ohne das Erfordernis, dass zusätzliche Pakete an das Servergerät gesandt oder von dem Servergerät empfangen werden, um den Schlüssel zu generieren.
System nach Anspruch 57 oder 58, wobei das Servergerät ferner zu folgenden Schritten konfiguriert ist: Empfangen (252) eines Schlüsselaustauschinitiatorpakets, das den Schlüssel nicht enthält, von dem Clientgerät; Validieren (254-270) des Schlüsselaustauschinitiatorpakets; Generieren (302) des Schlüssels zumindest teilweise auf Basis von Daten in dem Schlüsselaustauschinitiatorpaket, ohne das Erfordernis, dass zusätzliche Pakete von dem Clientgerät empfangen werden, um den Schlüssel zu generieren; und Senden (314) eines Schlüsselaustauschantwortpakets, das den Schlüssel nicht enthält, an das Clientgerät.