DE102006054091A1

DE102006054091A1 - Bootstrapping-Verfahren

Info

Publication number: DE102006054091A1
Application number: DE102006054091A
Authority: DE
Inventors: Matthias Dr. Franz; Günther Dr. Horn; Wolf-Dietrich Moeller
Original assignee: Siemens Corp
Current assignee: Nokia Solutions and Networks GmbH and Co KG
Priority date: 2006-11-16
Filing date: 2006-11-16
Publication date: 2008-05-21
Anticipated expiration: 2026-11-17
Also published as: DE102006054091B4; WO2008058841A3; WO2008058841A2

Abstract

Bootstrapping-Verfahren zum Bereitstellen eines gemeinsamen temporär gültigen anwendungsspezifischen Schlüssels (Ks_NAF) für ein Endgerät (UE) und einen Applikationsserver (NAF) mit den folgenden Schritten: Auswählen eines Bootstrapping-Servers (BSF) aus mehreren vorhandenen Bootstrapping-Servern anhand einer von dem Endgerät (UE) empfangenen ersten Nutzerkennung, wobei nach erfolgreicher Authentisierung des Endgerätes (UE) durch den ausgewählten Bootstrapping-Server (BSF) eine temporär gültige zweite Nutzerkennung (B-TID) diesem Endgerät (UE) zugewiesen wird und ein temporär gültiger Basisschlüssel (Ks) durch den ausgewählten Bootstrapping-Server (BSF) gebildet wird und wobei nach Empfang einer von dem Applikationsserver (NAF) stammenden Anforderungsnachricht, welche die gleiche temporär gültige zweite Nutzerkennung (B-TID) aufweist, durch den ausgewählten Bootstrapping-Server (BSF) dieser den temporär gültigen anwendungsspezifischen Schlüssel (Ks_NAF) aus dem temporär gültigen Basisschlüssel (Ks) ableitet und an den Applikationsserver (NAF) überträgt.

Description

Die Erfindung betrifft ein Bootstrapping-Verfahren zum Bereitstellen eines gemeinsamen temporär gültigen anwendungsspezifischen Schlüssels für ein Endgerät und einen Applikationsserver.
1 zeigt ein Beispiel für eine Netzwerkarchitektur nach dem Stand der Technik. Ein mobiles Endgerät bzw. ein Benutzerendgerät UE (User Equipment) kann über unterschiedliche Zugangsnetze, die im Mobilfunkbereich jeweils mehrere Basisstationen BS und ein Gateway GW aufweisen, und beispielsweise über besuchte Netze mit einem Heimatnetz des Teilnehmers eine Datenverbindung aufbauen. Die Zugangsnetze können dabei unterschiedliche standardisierte Zugangstechnologien aufweisen. Bei einem Zugangsnetz kann es sich beispielsweise um ein 3GPP-Zugangsnetz handeln. In einer GBA (Generic Bootstrapping Architecture) weist das Heimatnetz des Teilnehmers einen Bootstrapping-Server BSF (Bootstrapping Server Function) und einen Home-Subscriber-System-Server HSS auf.
2 zeigt den Aufbau eines GBA-Netzwerkes nach dem Stand der Technik. Der Bootstrapping-Server BSF ist über eine U_b-Schnittstelle mit einem Benutzerendgerät UE verbunden. Das Benutzerendgerät ist beispielsweise ein mobiles Endgerät wie ein Handy. Der Bootstrapping-Server BSF ist über eine Z_n-Schnittstelle mit einem Applikationsserver NAF (Network Application Function) verbunden, auf dem ein Anwendungsprogramm läuft. Darüber hinaus ist der Bootstrapping-Server BSF über eine Z_h-Schnittstelle mit dem Home-Subscriber-System-Server HSS verbunden, in dem ein Langzeitschlüssel bzw. ein langfristig gültiger Schlüssel abgelegt ist. Ferner kann der Bootstrapping-Server BSF über eine D_Z-Schnittstelle mit einem Server zur Lokalisierung des zugehörigen Home-Subscriber-System-Servers HSS verbunden sein. Dieser Server zur Lokalisierung eines Home-Subscriber-System-Servers HSS für einen Teilnehmer wird auch als SLF-Server (Subscriber Locator Function) bezeichnet. Bei der GBA-Netzwerkarchitektur wird eine langfristig gültige Sicherheitsbeziehung bzw. ein langfristig gültiger Schlüssel, der dem Benutzerendgerät UE und dem Home-Subscriber-System-Server HSS gemeinsam bekannt ist, dazu benutzt, eine kurzfristig gültigen Sicherheitsbeziehung zwischen dem Benutzerendgerät UE und dem Applikationsserver NAF aufzubauen. Zur Absicherung der Datenverbindung zwischen dem Benutzerendgerät UE und dem Applikationsserver NAF wird dabei ein temporär gültiger Schlüssel aus dem langfristig gültigen Schlüssel abgeleitet. Der Applikationsserver NAF kann sich in dem Heimatnetz des Teilnehmers, in einem besuchten Netzwerk oder an einem sonstigen Ort (3^rd party server) befinden.
Der Bootstrapping-Server BSF befindet sich stets im Heimatnetz des Teilnehmers und stellt die einzige Komponente innerhalb der GBA-Netzwerkarchitektur dar, die den Home-Subscriber-System-Server HSS kontaktiert.
Sobald der Bootstrapping-Server BSF eine Anforderung des Be-Benutzerendgeräts UE über die U_b-Schnittstelle erhält, lädt er aus dem HSS-Server kryptographische Zwischenschlüssel bzw. abgeleitete Schlüssel über die Z_h-Schnittstelle. Diese kryptographischen Zwischenschlüssel werden von dem langzeitig gültigen gemeinsamen Schlüssel bzw. dem Langzeitschlüssel, der in dem HSS-Server abgelegt ist und der auch dem Benutzerendgerät UE bekannt ist, abgeleitet. Anschließend leitet der Bootstrapping-Server BSF auf eine Anfrage des Applikationsserver NAF hin, die er über die Zn-Schnittstelle erhält, einen anwendungsspezifischen kryptographischen Schlüssel von dem kryptographischen Zwischenschlüssel bzw. Basisschlüssel ab und überträgt diese abgeleiteten anwendungsspezifischen Schlüssel an den Applikationsserver NAF. Das Benutzerendgerät UE leitet ebenfalls den gleichen Zwischenschlüssel bzw. Basisschlüssel und die gleichen anwendungsspezifischen kurzzeitig gültigen Schlüssel ab wie der Bootstrapping-Server BSF. Dies ist möglich, da dem Benutzerendgerät UE der langfristig gültige Schlüssel ebenfalls bekannt ist. Nach der Übertragung der anwendungsspezifischen und temporär gültigen Schlüssel an den Applikationsserver NAF verfügen sowohl der Applikationsserver als das Benutzerendgerät UE über die gleichen temporär gültigen anwendungsspezifischen Schlüssel (Ks_NAF) und können diese zur Absicherung einer Datenverbindung über die U_a-Schnittstelle zwischen dem Benutzerendgerät UE und dem Applikationsserver NAF verwenden. In einer GBA-Netzwerkarchitektur können mehrere Home-Subscriber-System-Server HSS vorgesehen werden. Allerdings weist jeder Teilnehmer einen zugehörigen Home-Subscriber-System-Server HSS auf. Dabei ist es möglich, einem Teilnehmer durch Transfer seiner Subskriptionsdaten einen anderen HSS-Server zuzuweisen, ohne das Benutzerendgerät UE neu konfigurieren zu müssen. Damit ein Teilnehmer bzw. ein Benutzerendgerät UE den richtigen Home-Subscriber-System-Server HSS auffinden kann, kontaktiert der Bootstrapping-Server BSF über die D_Z-Schnittstelle den SLF(Subscriber Locator Function)-Server unter Verwendung einer langfristig gültigen Teilnehmeridentität. Für den Fall, dass das GBA-Netzwerk nur über einen einzigen Home-Subscriber-System-Server HSS verfügt, kann auf die Anfrage beim SLF-Server verzichtet werden.
Bei einem herkömmlichen GBA-Netzwerk kontaktiert das Benutzerendgerät UE und der Applikationsserver NAF den Bootstrapping-Server BSF, indem sie einen DNS-Namen des Bootstrapping-Servers BSF auf der Grundlage einer Teilnehmeridentität oder einer temporär gültigen Nutzerkennung B-TID ableiten, die auf den Netzwerkbetreiber hinweisen.
Herkömmliche GBA-Netzwerke verfügen über nur einen Bootstrapping-Server BSF, wobei dieser Bootstrapping-Server BSF bzw. die Bootstrapping-Server-Funktion Teil des Heimatnetzes ist. Nimmt die Anzahl von Teilnehmern für einen Netzwerkprovider bzw. Netzwerkanbieter zu, kann es vorkommen, dass die Verarbeitungskapazität des Bootstrapping-Servers BSF nicht mehr ausreicht. Nun ist es aber wünschenswert für den Netzbetreiber, den bisherigen Bootstrapping-Server BSF weiter betreiben und ihn nur durch einen zusätzlichen Bootstrapping-Server BSF, möglicher Weise von einem Hersteller, ergänzen zu können. Dies ist bei einem herkömmlichen GBA-Netzwerk nicht möglich. Eine ähnliche Situation ergibt sich, wenn, wie in einem herkömmlichen GBA-Netzwerk möglich, der Bootstrapping-Server BSF mit dem HSS-Server integriert ist und der Speicherplatz in dem HSS-Server nicht mehr ausreichend ist. Auch in diesem Fall ist es nicht möglich, das in 2 dargestellte herkömmliche GBA-Netz nach dem Stand der Technik durch Vorsehen weiterer mit einem Bootstrapping-Server integrierter HSS- bzw. Home-Subscriber-System-Server zu erweitern. Eine Erweiterung des herkömmlichen GBA-Netzwerks ist somit nur mit einem sehr großen technischen Aufwand möglich.
Es ist daher die Aufgabe der vorliegenden Erfindung, ein Bootstrapping-Verfahren und einen Bootstrapping-Proxy-Server zu schaffen, die es erlauben, ein GBA-Netzwerk flexibel durch Vorsehen zusätzlicher Bootstrapping-Server BSF zu erweitern.
Diese Aufgabe wird erfindungsgemäß durch ein Bootstrapping-Verfahren mit den im Patentanspruch 1 angegebenen Merkmalen gelöst.
Die Erfindung schafft ein Bootstrapping-Verfahren zum Bereitstellen eines gemeinsamen temporär gültigen anwendungsspezifischen Schlüssels (Ks_NAF) für ein Endgerät (UE) und einen Applikationsserver (NAF) mit den folgenden Schritten:

– Auswählen eines Bootstrapping-Servers (BSF) aus mehreren vorhandenen Bootstrapping-Servern anhand einer von dem Endgerät (UE) empfangenen ersten Nutzerkennung;
– wobei nach erfolgreicher Authentisierung des Endgerätes (UE) durch den ausgewählten Bootstrapping-Server (BSF) eine temporär gültige zweite Nutzerkennung (B-TID) diesem Endgerät (UE) zugewiesen wird und ein temporär gültiger Basisschlüssel (Ks) durch den ausgewählten Bootstrapping-Server (BSF) gebildet wird;

Bei einer bevorzugten Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens wird die erste Nutzerkennung durch eine permanent gültige Nutzerkennung gebildet, wenn diese vorteilhaft ist.
Bei dieser ersten Nutzerkennung handelt es sich vorzugsweise um eine IMPI (IP-Multimedia-Private-Identity).
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens erfolgt die Auswahl des Bootstrapping-Servers BSF durch einen B-SLF(Subscriber Locator Function)-Server.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens werden die Nachrichten zwischen dem Endgerät und dem ausgewählten Bootstrapping-Server über einen BSF-Proxy-Server übertragen.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens werden auch die Nachrichten zwischen dem Applikationsserver NAF und dem ausgewählten Bootstrapping-Server BSF über einen BSF-Proxy-Server übertragen.
Bei einer bevorzugten Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens überträgt der B-SLF-Server an den BSF-Proxy-Server eine Adresse des ausgewählten Bootstrapping-Servers.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens speichert der BSF-Proxy-Server die Adresse des ausgewählten Bootstrapping-Servers zwischen.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens authentisiert der ausgewählte Bootstrapping-Server BSF das Endgerät UE mit Hilfe eines Home-Subscriber-System-Server HSS.
Dabei überträgt der Home-Subscriber-System-Server HSS an den ausgewählten Bootstrapping-Server BSF einen Authentisierungsvektor AV.
Dieser übertragene Authentisierungsvektor AV weist vorzugsweise eine Authentisierungschallenge, einen Authentisierungsantwort, einen Chiffrierschlüssel (Cipher Key) und einen Integritätsschlüssel (Integrity Key) auf.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens bildet der ausgewählte Bootstrapping-Server BSF den temporär gültigen Basisschlüssel aus dem Chiffrierschlüssel CK und dem Integritätsschlüssel IK.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens generiert der ausgewählte Bootstrapping-Server die temporär gültige zweite Nutzerkennung B-TID.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens wird die temporär gültige zweite Nutzerkennung B-TID zusammen mit einer Gültigkeitsdauer des gebildeten Basisschlüssels Ks von dem ausgewählten Bootstrapping-Server BSF an den Bootstrapping-Proxy-Server in einer Nachricht übertragen, welcher die temporär gültige zweite Nutzerkennung B-TID und die Gültigkeitsdauer des gebildeten Basisschlüssels Ks zwischenspeichert und anschließend die Nachricht an das Endgerät UE weiterleitet.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens überträgt das Endgerät UE bei Anforderung eines Dienstes von dem Applikationsserver NAF die von dem Bootstrapping-Proxy-Server an das Endgerät UE weitergeleitete temporär gültige zweite Nutzerkennung B-TID an den Applikationsserver NAF in einer Dienstanforderungsnachricht.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens sendet der Applikationsserver NAF eine Dienstanforderungsnachricht mit der temporär gültigen zweiten Nutzerkennung B-TID an den Bootstrapping-Proxy-Server, welcher die Dienstanforderungsnachricht an den ausgewählten Bootstrapping-Server BSF weiterleitet.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens bildet das Endgerät UE den temporär gültigen Basisschlüssel.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens leitet das Endgerät UE aus dem temporär gültigen Basisschlüssel Ks den temporär gültigen anwendungsspezifischen Schlüssel Ks_NAF ab.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens generiert der ausgewählte Bootstrapping-Server BSF die temporär gültige zweite Nutzerkennung B-TID und codiert darin ein, von welchem Bootstrapping-Server BSF die generierte zweite Nutzerkennung B-TID stammt.
Die Erfindung schafft ferner einen Bootstrapping-Proxy-Server für ein GBA(Generic Bootstrapping Architecture)-Netzwerk, welcher Nachrichten zwischen einem Endgerät UE und einem anhand einer permanenten Nutzerkennung ausgewählten Bootstrapping-Server BSF weiterleitet.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Proxy-Servers speichert der Bootstrapping-Proxy-Server eine von einem Bootstrapping-Server BSF erhaltene temporär gültige Nutzerkennung B-TID zugeordnet zu dem jeweiligen Bootstrapping-Server BSF ab.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Proxy-Servers leitet der Bootstrapping-Proxy-Server Nachrichten zwischen einem Applikationsserver NAF und dem ausgewählten Bootstrapping-Server BSF weiter.
Im Weiteren werden bevorzugte Ausführungsformen des erfindungsgemäßen Bootstrapping-Verfahrens und des dabei eingesetzten Bootstrapping-Proxy-Servers unter Bezugnahme auf die beigefügten Figuren zur Erläuterung erfindungswesentlicher Merkmale beschrieben.
Es zeigen:
1: ein Netzwerk nach dem Stand der Technik;
2: die Netzwerkarchitektur eines GBA-Netzwerks nach dem Stand der Technik;
3: ein Signaldiagramm zur Erläuterung einer möglichen Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens;
4: eine erste Ausführungsform eines erfindungsgemäß erweiterten GBA-Netzwerks mit einem BSF-Proxy-Server gemäß der Erfindung;
5: eine GBA-Netzwerkarchitektur für die in 4 dargestellte Ausführungsform;
6: eine weitere Ausführungsform eines erfindungsgemäß erweiterten Netzwerks mit einem BSF-Proxy-Server;
7: eine GBA-Netzwerkarchitektur für die in 6 dargestellte Ausführungsform;
8: eine weitere Ausführungsform eines erfindungsgemäß erweiterten Netzwerks mit einem BSF-Proxy-Server.
Das erfindungsgemäße Bootstrapping-Verfahren dient zum Bereitstellen eines gemeinsamen temporär gültigen anwendungsspezifischen Schlüssels Ks_NAF für ein Endgerät UE und einen Applikationsserver NAF. Bei dem in 3 dargestellten Signaldiagramm sind beispielhaft zwei unterschiedliche Bootstrapping-Server BSF-A und BSF-B vorgesehen. Ein BSF-Proxy-Server ist bei dem erfindungsgemäßen Bootstrapping-Verfahren zur Übertragung von Nachrichten zwischen dem Endgerät UE und einem ausgewählten Bootstrapping-Server BSF vorgesehen. Nachrichten zwischen dem Applikationsserver NAF und dem ausgewählten Bootstrapping-Server werden dabei ebenfalls über den BSF-Proxy-Server übertragen. Die Auswahl des Bootstrapping-Servers BSF erfolgt durch einen Subscriber-Locator-Function-Server B-SLF. Bei dem in 3 dargestellten Beispiel meldet der B-SLF-Server zur Lokalisierung des Bootstrapping-Servers BSF den ersten Bootstrapping-Server BSF-A.
Darüber hinaus weist das Netzwerk bei dem in 3 dargestellten Beispiel zwei Home-Subscriber-System-Server HSS-X und HSS-Y auf, die mittels eines weiteren Subscriber-Location-Function-Server H-SLF lokalisiert werden. Die H-SLF-Funktion übt die Funktion eines herkömmlichen SLF-Server aus.
Bei dem erfindungsgemäßen Verfahren wird zunächst ein Bootstrapping-Server, beispielsweise der Bootstrapping-Server BSF-A, aus einer Gruppe von vorhandenen Bootstrapping-Server, beispielsweise eine aus den Bootstrapping-Servern BSF-A, BSF-B bestehende Gruppe ausgewählt, wobei die Auswahl des Bootstrapping-Server BSF vorzugsweise durch einen entsprechenden SLF-Server B-SLF erfolgt. Die Auswahl des Bootstrapping-Servers BSF erfolgt anhand einer von dem Endgerät UE empfangenen ersten Nutzerkennung. Diese erste Nutzerkennung ist eine permanent gültige bzw. eine langfristige Nutzerkennung. Bei dieser ersten langfristigen Nutzerkennung kann es sich beispielsweise um eine IMPI handeln.
Nach erfolgreicher Authentisierung des Endgeräts UE wird durch den ausgewählten Bootstrapping-Server BSF eine temporär gültige zweite Nutzerkennung B-TID diesem Endgerät UE zugewiesen und ein temporär gültiger Basisschlüssel durch den ausgewählten Bootstrapping-Server BSF gebildet.
Nach Empfang einer von dem Applikationsserver NAF erhaltenen Anforderungsnachricht, welche die gleiche temporär gültige zweite Nutzerkennung B-TID aufweist, durch den ausgewählten Bootstrapping-Server BSF leitet dieser Bootstrapping-Server BSF den temporär gültigen anwendungsspezifischen Schlüssel Ks_NAF aus dem temporär gültigen Basisschlüssel Ks ab und überträgt diesen temporär gültigen anwendungsspezifischen Schlüssel Ks_NAF an den Applikationsserver NAF.
Im Folgenden wird der genaue Ablauf einer möglichen Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens unter Bezugnahme auf die 3 beschrieben.
In einem ersten Schritt S1 überträgt das Benutzerendgerät UE in einer Nachricht eine langfristig gültige Nutzerkennung. Diese erste Nutzerkennung ist eine permanent bzw. langfristig gültige Nutzerkennung, beispielsweise eine IMPI. Das Benutzerendgerät UE initiiert somit den Bootstrapping-Vorgang, wobei es beispielsweise einen DNS-Namen des BSF-Servers bestimmt. Ein DNS-Server liefert die IP-Adresse des BSF-Proxy-Servers, und das Benutzerendgeräts UE sendet daraufhin beispielsweise eine http-Anforderung über die U_b-Schnittstelle an den BSF-Proxy-Server. Für ein 2G-GBA-Netzwerk baut das Benutzerendgerät UE zunächst einen TLS-Tunnel zu dem BSF-Proxy-Server auf.
Sobald der BSF-Proxy-Server die Langzeit-Nutzerkennung bzw. die permanent gültige erste Nutzerkennung von dem Benutzerendgerät im Schritt S1 erhalten hat, überträgt der BSF-Proxy-Server im Schritt S2 eine Nachricht, welche diese permanent gültige erste Nutzerkennung enthält, an den Subscriber-Location-Function-Server B-SLF über das D_Z*-Interface. Bei einer Ausführungsform leitet der BSF-Proxy-Server lediglich die empfangene http-Anforderungsnachricht an den B-SLF-Server weiter. Das D_Z-Interface, wie es im 3GPP-Standard spezifiziert ist, wird diesbezüglich erweitert.
Der Subscriber-Location-Function-Server B-SLF sendet im Schritt S3 eine Nachricht zurück an den BSF-Proxy-Server, welche den Namen des ausgewählten Bootstrapping-Servers BSF bzw. eine Adresse des ausgewählten Bootstrapping-Servers BSF enthält. Bei dem in 3 dargestellten Beispiel wird die Adresse des Bootstrapping-Servers BSF-A an den BSF-Proxy-Server übertragen. Um den korrekten Namen des BSF-Servers bzw. die korrekte Adresse des BSF-Servers zu bestimmen, geht der Subscriber-Location-Function-Server B-SLF wie folgt vor. Der B-SLF-Server bestimmt zunächst die zu dem Teilnehmer gehörigen Subscriber-Server HSS. Anschließend bestimmt der B-SLF-Server anhand einer abgelegten Tabelle den zu dem ermittelten HSS-Server zugehörigen eingetragenen BSF-Server und sendet eine entsprechende Nachricht an den BSF-Proxy-Server, etwa unter Verwendung einer http-Redirect-Funktion.
Bei einer möglichen Ausführungsform speichert der BSF-Proxy-Server den erhaltenen BSF-Namen bzw. die Adresse des ausgewählten BSF-Servers ab, wobei der BSF-Name bzw. die BSF-Adresse zugeordnet zu der empfangenen langfristig gültigen ersten Nutzerkennung des Teilnehmers abgespeichert wird. Das Abspeichern des BSF-Namens ist nicht zwingend notwendig, vermeidet jedoch eine wiederholte Übertragung von Anforderungen seitens des BSF-Proxy-Servers über die D_Z*-Schnittstelle. Der BSF-Proxy-Server leitet die von dem Endgerät UE erhaltene Anforderung für den gewünschten Dienst an den ausgewählten BSF-Server im Schritt S4 weiter. Bei dem in 3 dargestellten Beispiel wird die Anforderung im Schritt S4 von dem BSF-Proxy-Server an den BSF-Server BSF-A weitergeleitet.
Der ausgewählte BSF-Server BSF-A verarbeitet die empfangene Nachricht entsprechend dem 3GPP-Standard, wobei der BSF- Server seinen eigenen DNS-Namen durch den DNS-Namen des BSF-Proxy-Servers ersetzt.
In einem weiteren Schritt S5 überträgt der ausgewählte BSF-Server eine HSS-Anforderungsnachricht an einen Subscriber-Location-Function-Server H-SLF. Der H-SLF-Server liefert dem anfragenden BSF-Server BSF-A im Schritt S6 die Adresse des Home-Subscriber-System-Servers HSS. In dem dargestellten Beispiel ist dies die Adresse des Home-Subscriber-Servers HSS-Y. Auf eine im Schritt S7 übertragene Anforderung hin sendet der HSS-Y einen Authentisierungsvektor AV an den anfragenden Bootstrapping-Server BSF-A im Schritt S8. Der an den ausgewählten Bootstrapping-Server BSF-A übertragene Authentisierungsvektor AV weist bei einer Ausführungsform eine Authentisierungschallenge, eine Authentisierungsantwort bzw. -Response, einen Chiffrierschlüssel CK (Cipher Key) und einen Integritätsschlüssel IK (Integrity Key) auf.
Die in dem Authentisierungsvektor AV empfangene Authentisierungschallenge wird im Schritt S9 von dem Bootstrapping-Server BSF-A an den BSF-Proxy-Server übertragen und von dort im Schritt S10 an das Benutzerendgerät UE. Das Benutzerendgerät UE berechnet eine Response bzw. eine Authentisierungsantwort und überträgt diese im Schritt S11 an den BSF-Proxy-Server, der diese Nachricht im Schritt S12 an den BSF-Server BSF-A weiterleitet. Der BSF- bzw. Bootstrapping-Server BSF-A überprüft, ob die von dem Benutzerendgerät UE empfangene Authentisierungsantwort korrekt ist. Anschließend generiert der ausgewählte Bootstrapping-Server eine temporär gültige zweite Nutzerkennung B-TID und überträgt diese im Schritt S13 an den BSF-Proxy-Server. Darüber hinaus bildet der ausgewählte Bootstrapping-Server BSF-A einen temporär gültigen Basisschlüssel BSF aus dem Chiffrierschlüssel CK und aus dem Integritätsschlüssel IK des Authentisierungsvektors AV, den er im Schritt S8 von dem Home-Subscriber-System-Server HSS-Y erhalten hat.
Der Bootstrapping-Proxy-Server BSF-Proxy erhält im Schritt S13 die temporär gültige zweite Nutzerkennung B-TID und die Gültigkeitsdauer (Key Lifetime) des gebildeten Basisschlüssels Ks von dem ausgewählten Bootstrapping-Server BSF-A und leitet die temporär gültige zweite Nutzerkennung B-TID zusammen mit der Gültigkeitsdauer an das Benutzerendgerät UE im Schritt S14 weiter. Bei einer möglichen Ausführungsform speichert der Bootstrapping-Proxy-Server die temporär gültige zweite Nutzerkennung B-TID und die Gültigkeitsdauer des gebildeten Basisschlüssels Ks zwischen, bevor er diese im Schritt S14 weiterleitet. Dabei speichert der Bootstrapping-Proxy-Server vorzugsweise auch die BSF-Namen für die Gültigkeitsdauer der Nutzerkennung B-TID und des Basisschlüssels K zwischen.
Möchte das Benutzerendgerät UE eine Anwendung bzw. einen Dienst nutzen, sendet es eine Dienstanforderungsnachricht im Schritt S15 an den Applikationsserver NAF. Der Applikationsserver überträgt eine Anforderung für einen temporär gültigen anwendungsspezifischen Schlüssel Ks_NAF anschließend im Schritt S16 an den BSF-Proxy-Server, der diese Anforderung im Schritt Si7 an den ausgewählten Bootstrapping-Server BSF-A weiterleitet. Der Bootstrapping-Server BSF-A leitet den temporär gültigen anwendungsspezifischen Schlüssel Ks_NAF aus dem temporär gültigen Basisschlüssel Ks ab und überträgt diesen temporär gültigen anwendungsspezifischen Schlüssel Ks_NAF im Schritt S18 an den BSF-Proxy-Server, der diesen zur Verfügung gestellten temporär gültigen anwendungsspezifischen Schlüssel Ks_NAF im Schritt S19 an den Applikationsserver NAF weiterleitet. Nach der gegenseitigen Authentisierung im Schritt S20 erfolgt im Schritt S21 ein kryptographisch gesicherter Datenaustausch zwischen dem Benutzerendgerät UE und dem Applikationsserver NAF über die Schnittstelle U_a unter Verwendung des temporär gültigen anwendungsspezifischen Schlüssels Ks_NAF, der sowohl dem Benutzerendgerät UE als auch dem Applikationsserver NAF bekannt ist. Der Applikationsserver NAF erhält den temporär gültigen anwendungsspezifischen Schlüssel Ks_NAF von dem ausgewählten Bootstrapping- Server BSF-A. Das Benutzerendgerät UE leitet den temporär gültigen anwendungsspezifischen Schlüssel Ks_NAF aus dem temporär gültigen Basisschlüssel Ks selbst ab.
4 zeigt eine mögliche Ausführungsform eines erfindungsgemäß erweiterten GBA-Netzwerks, das einen BSF-Proxy-Server enthält. Bei der in 4 dargestellten Ausführungsform sind mehrere Bootstrapping-Server BSF vorgesehen, die jeweils einen zugehörigen Home-Subscriber-System-Server HSS aufweisen. Beispielsweise ist die Bootstrapping-Server-Function BSF in dem HSS-Server integriert.
5 zeigt eine GBA-Netzwerkarchitektur für die in 4 dargestellte Ausführungsform.
6 zeigt eine weitere Ausführungsform eines erfindungsgemäß erweiterten GBA-Netzwerks, wobei in dieser Ausführungsform ebenfalls mehrere BSF-Server vorgesehen sind, die mit einem gemeinsamen BSF-Proxy-Server kommunizieren. Bei der in 6 dargestellten Ausführungsform kann jeder BSF- bzw. Bootstrapping-Server mit unterschiedlichen Home-Subscriber-Servern HSS Daten austauschen. Jeder BSF-Server kann mit mehreren HSS-Servern verbunden sein und jeder HSS-Server kann mit verschiedenen BSF-Servern verbunden sein. Da jeder BSF-Server bei der in 6 dargestellten Ausführungsform mit unterschiedlichen HSS-Servern Daten austauschen kann, benötigt er eine Subscriber-Location-Function H-SLF zum Auffinden des zugehörigen HSS-Servers.
7 zeigt eine GBA-Netzwerkarchitektur für die in 6 dargestellte Ausführungsform. Wie man aus 7 erkennen kann, ist der BSF- bzw. Bootstrapping-Server über eine eigene Schnittstelle D_Z mit einem Subscriber-Location-Function-Server H-SLF verbunden zum Auffinden des Home-Subscriber-Servers HSS. Der BSF-Proxy-Server ist seinerseits mit einem B-SLF-Server über eine D_Z*-Schnittstelle verbunden zum Auffinden des korrekten BSF-Servers.
Bei einer Ausführungsform des erfindungsgemäßen Bootstrapping-Verfahrens generiert der ausgewählte Bootstrapping-Server BSF die temporär gültige zweite Nutzerkennung B-TID und codiert darin ein, von welchem Bootstrapping-Server BSF die generierte zweite Nutzerkennung B-TID stammt. Dies ermöglicht, dass der Applikationsserver NAF direkt auf den BSF-Server zugreifen kann und dass der BSF-Proxy-Server nicht die temporär gültige zweite Nutzerkennung B-TID sowie die zugehörigen Gültigkeitsdauern abspeichern muss.
8 zeigt eine weitere Ausführungsform des erfindungsgemäß erweiterten GBA-Netzwerks, wobei jeder BSF- bzw. Bootstrapping-Server mit mehr als einem Home-Subscriber-Server verbunden sein kann. Alle BSF-Server sowie der BSF-Proxy-Server sind lokal konfiguriert mit einem BSF-Namen, wobei der Name des BSF-Proxy-Servers gemäß den heutigen GBA-Spezifikationen standardisiert ist. Alle DNS-Server liefern auf Anfrage die IP-Adresse des Proxy-Servers. Auf Anfrage liefert der B-SLF-Server den DNS-Namen oder die IP-Adresse des ausgewählten BSF-Servers für einen vorgegebenen Teilnehmer, beispielsweise aufgrund der gegebenen IMPI. Der gelieferte DNS-Name ist unterschiedlich von dem in heutigen GBA-Spezifikationen standardisierten BSF-Namen. Bei der in 8 dargestellten Ausführungsform initiiert das Benutzerendgerät UE den Bootstrapping-Vorgang und bestimmt den DNS-Namen des Bootstrapping-Servers BSF, der in dieser Ausführungsform auf den BSF-proxy verweist, was dem Benutzerendgerät jedoch nicht bekannt sein muss. Anschließend sendet das Benutzerendgerät UE einen ersten http-Request über die U_b-Schnittstelle. Für den Fall einer 2G-GBA-Netzwerkarchitektur baut das Benutzerendgerät UE einen TLS-Tunnel zu dem BSF-Proxy-Server auf. Die http-Anforderung erreicht den BSF-Proxy-Server, da der DNS-Name des Bootstrapping-Servers BSF in die IP-Adresse des BSF-Proxy-Servers übersetzt wird. Der BSF-Proxy-Server überträgt eine Nachricht mit der langfristig gültigen ersten Nutzerkennung IMPI über ein D_Z*-Interface an den B-SLF-Server. Der B-SLF-Server sendet eine Nachricht zurück an den BSF-Proxy-Server, welche den DNS-Namen oder die IP-Adresse des für den Teilnehmer gültigen BSF-Servers enthält. Diese DNS-Nachricht bzw. die IP-Adresse, die zu der Teilnehmeridentität gehört, kann durch den BSF-Proxy-Server gespeichert werden.
Der BSF-Proxy-Server leitet die ursprüngliche von dem Benutzerendgerät empfangene http-Anforderung an den BSF- bzw. Bootstrapping-Server weiter, der durch den B-SLF-Server angegeben ist. Falls die Anforderung für ein 2G-GBA-Netzwerk besteht und der BSF-Server einen TLS-Tunnel fordert, wird dieser aufgebaut. Die übertragene Nachricht wird durch den BSF- bzw. Bootstrapping-Server verarbeitet und es wird eine Antwort an den BSF-Proxy-Server übertragen, welcher diese Nachricht ohne Veränderungen an das Benutzerendgerät UE weiterleitet. Das Benutzerendgerät UE verarbeitet die empfangene Nachricht und sendet eine weitere http-Anforderung an den BSF-Proxy-Server, welcher diese an den korrekten Bootstrapping-Server BSF weiterleitet. Der BSF-Server verarbeitet die empfangene Nachricht und sendet eine Antwort an den BSF-Proxy-Server zurück, der die temporär gültigen zweiten Nutzerkennung B-TID und die zugehörige Gültigkeitsdauer zusammen mit der IP-Adresse des BSF-Servers speichert. Der BSF-Proxy-Server leitet dann die Nachricht unverändert an das Benutzerendgerät UE weiter, wobei nach Ablauf der Gültigkeitsdauer alle zu der temporär gültigen zweiten Nutzerkennung B-TID gehörigen Einträge durch den BSF-Proxy-Server gelöscht werden.
Bei einer weiteren Ausführungsform ist der DNS-Server, der auf die DNS-Anfragen antwortet, derart konfiguriert, dass die DNS-Anforderung für den standardisierten BSF-Namen in die IP-Adresse des jeweiligen BSF-Servers übersetzt werden, anstatt in die IP-Adresse des BSF-Proxy-Servers.
Bei dem erfindungsgemäßen Netzwerk ist es möglich, mehrere BSF-Server bzw. Bootstrapping-Server vorzusehen, ohne dass dies für das Benutzerendgerät UE und den Applikationsserver NAF bemerkbar ist. Das erfindungsgemäße Netzwerk ist abwärts kompatibel, da die Benutzerendgeräte UE und die Applikations server NAF die Schnittstellen U_a, U_b, Z_n in gewohnter Weise nutzen können.

Claims

Bootstrapping-Verfahren zum Bereitstellen eines gemeinsamen temporär gültigen anwendungsspezifischen Schlüssels (Ks_NAF) für ein Endgerät (UE) und einen Applikationsserver (NAF) mit den folgenden Schritten: (a) Auswählen eines Bootstrapping-Servers (BSF) aus mehreren vorhandenen Bootstrapping-Servern anhand eines von dem Endgerät (UE) empfangenen ersten Nutzerkennung; (b) wobei nach erfolgreicher Authentisierung des Endgerätes (UE) durch den ausgewählten Bootstrapping-Server (BSF) eine temporär gültige zweite Nutzerkennung (B-TID) diesem Endgerät (UE) zugewiesen wird und ein temporär gültiger Basisschlüssel (Ks) durch den ausgewählten Bootstrapping-Server (BSF) und das Endgerät (UE) gebildet wird; (c) und wobei nach Empfang einer von dem Applikationsserver (NAF) stammenden Anforderungsnachricht, welche die gleiche temporär gültige zweite Nutzerkennung (B-TID) aufweist, durch den ausgewählten Bootstrapping-Server (BSF) dieser den temporär gültigen anwendungsspezifischen Schlüssel (Ks_NAF) aus dem temporär gültigen Basisschlüssel (Ks) ableitet und an den Applikationsserver (NAF) überträgt.
Bootstrapping-Verfahren nach Anspruch 1, wobei die erste Nutzerkennung durch eine permanent gültige Nutzerkennung gebildet wird.
Bootstrapping-Verfahren nach Anspruch 2, wobei die erste Nutzerkennung durch eine IMPI (IP-Multimedia-Private-Identity) gebildet wird.
Bootstrapping-Verfahren nach Anspruch 1, wobei die Auswahl des Bootstrapping-Servers (BSF) durch einen B-SLF(Subscriber Location Function)-Server erfolgt.
Bootstrapping-Verfahren nach Anspruch 1, wobei Nachrichten zwischen dem Endgerät (UE) und dem ausgewählten Bootstrapping-Server (BSF) über einen BSF-Proxy-Server übertragen werden.
Bootstrapping-Verfahren nach Anspruch 1, wobei Nachrichten zwischen dem Applikationsserver (NAF) und dem ausgewählten Bootstrapping-Server (BSF) über einen BSF-Proxy-Server übertragen werden.
Bootstrapping-Verfahren nach Anspruch 4 bis 6, wobei der B-SLF-Server an den BSF-Proxy-Server eine Adresse des ausgewählten Bootstrapping-Servers (BSF) überträgt.
Bootstrapping-Verfahren nach Anspruch 7, wobei der BSF-Proxy-Server die Adresse des ausgewählten Bootstrapping-Servers (BSF) zwischenspeichert.
Bootstrapping-Verfahren nach Anspruch 1, wobei der ausgewählte Bootstrapping-Server (BSF) das Endgerät (UE) mit Hilfe eines Home-Subscriber-System-Server (HSS) authentisiert.
Bootstrapping-Verfahren nach Anspruch 9, wobei der Home-Subscriber-System-Server (HSS) an den ausgewählten Bootstrapping-Server (BSF) einen Authentisierungsvektor (AV) überträgt.
Bootstrapping-Verfahren nach Anspruch 10, wobei der an den ausgewählten Bootstrapping-Server (BSF) übertragene Authentisierungsvektor (AV) eine Authentisierungs-Challenge, eine Authentisierungsantwort, einen Chiffrierschlüssel (Cipher Key CK) und einen Integritätsschlüssel (integrity key IK) aufweist.
Bootstrapping-Verfahren nach Anspruch 11, wobei der ausgewählte Bootstrapping-Server (BSF) den temporär gültigen Basisschlüssel (Ks) aus dem Chiffrierschlüssel (CK) und aus dem Integritätsschlüssel (IK) bildet.
Bootstrapping-Verfahren nach Anspruch 1, wobei der ausgewählte Bootstrapping-Server (BSF) die temporär gültige zweite Nutzerkennung (B-TID) generiert.
Bootstrapping-Verfahren nach Anspruch 13, wobei die temporär gültige zweite Nutzerkennung (B-TID) zusammen mit einer Gültigkeitsdauer des gebildeten Basisschlüssels (Ks) von dem ausgewählten Bootstrapping-Server (BSF) an den Bootstrapping-Proxy-Server in einer Nachricht übertragen wird, welcher die temporär gültige zweite Nutzerkennung (B-TID) und die Gültigkeitsdauer des gebildeten Basisschlüssels (Ks) zwischenspeichert und anschließend die Nachricht an das Endgerät (UE) weiterleitet.
Bootstrapping-Verfahren nach Anspruch 14, wobei das Endgerät (UE) bei Anforderung eines Dienstes von dem Applikationsserver (NAF) die von dem Bootstrapping-Proxy-Server an das Endgerät (UE) weitergeleitete temporär gültige zweite Nutzerkennung (B-TID) an den Applikationsserver (NAF) in einer Dienstanforderungsnachricht überträgt.
Bootstrapping-Verfahren nach Anspruch 15, wobei der Applikationsserver (NAF) die Dienstanforderungsnachricht mit der temporär gültigen zweiten Nutzerkennung (B-TID) an den Bootstrapping-Proxy-Server sendet, welcher die Dienstanforderungsnachricht an den ausgewählten Bootstrapping-Server (BSF) weiterleitet.
Bootstrapping-Verfahren nach Anspruch 1, wobei das Endgerät (UE) den temporär gültigen Basisschlüssel (Ks) bildet.
Bootstrapping-Verfahren nach Anspruch 17, wobei das Endgerät (UE) aus dem temporär gültigen Basisschlüssel (Ks) den temporär gültigen anwendungsspezifischen Schlüssel (Ks_NAF) ableitet.
Bootstrapping-Verfahren nach Anspruch 1, wobei der ausgewählte Bootstrapping-Server (BSF) die temporär gültige zweite Nutzerkennung (B-TID) generiert und darin eincodiert, von welchem Bootstrapping-Server (BSF) die generierte zweite Nutzerkennung (B-TID) stammt.
Bootstrapping-Proxy-Server für ein GBA(Generic Bootstrapping Architecture)-Netzwerk, welcher Nachrichten zwischen einem Endgerät (UE) und einem anhand einer permanenten Nutzerkennung ausgewählten Bootstrapping-Server (BSF) weiterleitet.
Bootstrapping-Proxy-Server nach Anspruch 20, wobei der Bootstrapping-Proxy-Server eine von einem Bootstrapping-Server (BSF) erhaltene temporär gültige Nutzerkennung (B-TID) zugeordnet zu dem jeweiligen Bootstrapping-Server (BSF) zwischenspeichert.
Bootstrapping-Proxy-Server nach Anspruch 20, wobei der Bootstrapping-Proxy-Server Nachrichten zwischen einem Applikationsserver (NAF) und dem ausgewählten Bootstrapping-Server (BSF) weiterleitet.