-
Diese
Erfindung bezieht sich auf Mobilpaketnetze und insbesondere aber
nicht notwendigerweise auf die Authentifizierung eins Mobilknotens,
der eine Verbindung zu einem Mobil-IP-(Internet Protokoll)-Netz
herstellt.
-
Bei
der Mobil-IP-Vernetzung stellt ein Endgerät, wie ein Laptop-Computer,
der einen damit verbundenen Wireless Local Area Network (WLAN) Adapter
aufweist, mit seinem Heimatagenten über einen fremden Agenten eine
Verbindung her. Funktionell ausgedrückt wirkt das Endgerät als ein
Mobilknoten im Netz. Die Ausdrücke
Mobilknoten, Heimatagent und fremder Agent sind in der Veröffentlichung
Request For Comments 2002 folgendermaßen erläutert:
Mobilknoten (MT):
Ein Host oder Router, der seinen Anknüpfungspunkt von einem Netz
oder einem Unternetz zu einem anderen ändert. Ein Mobilknoten kann
seinen Standort wechseln, ohne seine IP-Adresse zu ändern; er
kann weiter mit anderen Internet-Knoten an jedem Standort unter
Verwendung seiner (konstanten) IP-Adresse kommunizieren, vorausgesetzt
dass die Sicherungsschichtkonnektivität (link layer connectivity)
zu einem Anknüpfungspunkt
verfügbar
ist.
Heimatagent (HA): Ein Mobilknoten gehört zu einem Heimatnetz, zu
dem ein Heimatagent des Mobilknoten gehört. Der HA ist ein Router auf
einem Mobilknotenheimatnetz, der Datagramme für eine Lieferung an den Mobilknoten
tunnelt, wenn er sich entfernt von der Heimat befindet, und der
aktuelle Standortinformation für den
Mobilknoten bewahrt.
Fremder Agent: ein Router auf einen Netz,
das vom Mobilknoten besucht wird, der Lenkdienste für den Mobilknoten
liefert, während
er registriert wird. Der fremde Agent enttunnelt und liefert Datagramme
an den Mobilknoten, die durch den Heimatagenten des Mobilknoten
getunnelt wurden. Für
Datagramme, die durch einen Mobilknoten gesendet werden, kann der
fremde Agent als ein Standardrouter für mobile Knoten, die bei ihm registriert
sind, dienen.
Mobilitätsagent:
Entweder ein Heimatagent oder ein fremder Agent.
-
In
der Veröffentlichung
RFC2002 ist weiter erläutert,
dass einem Mobilknoten eine lange IP-Adresse oder Heimatadresse
in seinem Heimatnetz gegeben wird. Diese Heimatadresse wird in derselben
Weise wie eine "permanente" IP-Adresse, die
einem stationären
Host geliefert wird, verwaltet. Wenn er sich entfernt von seinem
Heimatnetzwerk befindet, so wird durch den Heimatagenten eine "Sorgeadresse (care-of
address)" mit dem
Mobilknoten verbunden und sie zeigt den aktuellen Anknüpfungspunkt
des Mobilknotens an. Der Mobilknoten kann seine Heimatadresse als
Quelladresse der IP-Datagramme, die er sendet, verwenden.
-
Es
ist für
einen Mobilknoten oft wünschenswert,
dass er auf der Verbindung zu einem IP-Netz authentifiziert wird.
Ein Weg für
ein IP-Netz, einen Mobilknoten zu erkennen, besteht in der Verwendung
eines gemeinsamen Geheimschlüssels,
der dem IP-Netz und dem Mobilknoten bekannt ist. Das gemeinsame
Geheimnis ist als der kryptographische Schlüssel zu verwenden. Das gemeinsame
Geheimnis kann zuerst dem IP-Netz bekannt sein und dann in einem
Mobilknoten gespeichert werden, wenn die Verwaltung des IP-Netzes einen
sicheren Zugang zum Mobilknoten erhält. Im Interesse der Sicherheit
sollte das gemeinsame Geheimnis nicht über ein Netz gesendet werden,
das abgehört
werden kann. Somit sollte der Mobilknoten an die Verwaltung des
IP-Netzes geliefert werden. In der Zukunft gibt es wahrscheinlich
viele verschiedene IP-Netze.
Gemäß der vorliegenden
Anordnung würde
ein Mobilknoten mit einer Datenbank von geheimen Schlüsseln versehen
werden müssen,
um einen für
jedes der verschiedenen IP-Netze, mit denen er verbunden werden
könnte,
zu haben.
-
Die
WO00/02406 beschreibt ein Authentifizierungsverfahren für ein Telekommunikationsnetz,
insbesondere für
ein IP-Netz. Von einem Endgerät
im Netz wird eine erste Nachricht, die eine Authentikator und eine Dateneinheit
enthält,
an das Netz übertragen,
wobei die Dateneinheit Information in Bezug auf die Art, wie die Authentifizierung
gebildet ist, enthält.
Für das
Ausführen
der Authentifizierung im Netz wird die Dateneinheit, die in der
ersten Nachricht enthalten ist, für das Bestimmen eines Prüfwerts,
der mit dem Authentikator verglichen wird, verwendet. Um es für das Endgerät unnötig zu machen,
irgend einen komplizierten und umfangreichen Austausch von Nachrichten
durchzuführen,
wenn es sich an das Netz anknüpft
und dennoch die gewünschten
Sicherheitseigenschaften für
den Gebrauch zu behalten, wird eine solche Identifizierungseinheit
im Endgerät
verwendet, die als ein Eingangssignal eine Challenge empfängt, aus
der eine Antwort und ein Schlüssel
im wesentlichen in derselben Weise wie im Teilnehmeridentitätsmodul
eines bekannten Mobilkommunikationssystems bestimmt werden kann,
wobei ein Satz von Authentifizierungsblöcken in das Netz erzeugt wird,
von denen jeder eine Challenge, eine Antwort und einen Schlüssel enthält, wodurch
die Erzeugung in derselben Weise wie in diesem Mobilkommunikationssystem
durchgeführt
wird, wobei mindestens einige der Challenges, die in den Authentifizierungsblöcken enthalten
sind, an das Endgerät übertragen
werden:
Eine der Challenges wird für eine Verwendung am Endgerät ausgewählt und
auf ihrer Basis werden eine Antwort und ein Schlüssel für die Verwendung mit der Hilfe
der Endgerätidentifizierungseinheit
bestimmt, wobei in der ersten Nachricht dem Netz mit Hilfe der Dateneinheit
mitgeteilt wird, welcher Schlüssel,
der welcher Challenge entspricht, ausgewählt wurde, und wobei die Authentifizierung
der ersten Nachricht und der Prüfwert
mit der Hilfe des gewählten
Schlüssels
bestimmt werden.
-
Die
WO00102407 betrifft eine Authentifizierung, die in einem Telekommunikationsnetz,
insbesondere einem IP-Netz durchzuführen ist. Um eine einfache
und glatte Authentifizierung der Benutzer eines IP-Netzes in einem
geographisch großen
Gebiet zu ermöglichen,
verwendet das Endgerät
(TE1) des IP-Netzes ein Teilnehmerkennungsmodul (SIM) wie es in
einem getrennten Mobilkommunikationssystem (MN) verwendet wird, wodurch
die Antwort aus der Challenge, die dem Kennungsmodul als Eingangssignal
gegeben wird, bestimmt werden kann. Das IP-Netz umfasst auch einen
Speziellen Sicherheitsserver (SS), an den eine Nachricht über einen
neuen Benutzer übertragen
wird, wenn ein Teilnehmer eine Anknüpfung an das IP-Netz vollzieht.
Die Authentifizierungsinformation des Teilnehmers, die mindestens
eine Challenge und eine Antwort enthält, wird aus dem Mobilkommunikationssystem
zum IP-Netz ergriffen, und die Authentifizierung wird auf der Basis
der Authentifizierungsinformation, die vom Mobilkommunikationssystem
erhalten wird, durch das Übertragen
der Challenge durch das IP-Netz zum Endgerät ausgeführt, durch das Erzeugen einer
Antwort von der Challenge im Endgerätkennungsmodul und durch das
Vergleichen der Antwort mit der Antwort, die vom Mobilkommunikationssystem
erhalten wird. Eine solche Datenbank (DB) kann auch in einem System
verwendet werden, wo die teilnehmerspezifische Authentifizierungsinformation
im Vorhinein gespeichert wird, wodurch die in Frage stehende Information
nicht vom Mobilkommunikationssystem ergriffen werden muss, wenn
ein Teilnehmer eine Anknüpfung
an das Netz vornimmt.
-
Dieses
Dokument beschreibt das Senden eines Satzes von Challenges, wenn
einige der Challenges mit den reservierten Sicherheitsparameterindexwerten
(SPI-Werten) in Konflikt geraten würden, was eine Datenübertragungsbandbreite
verschwendet und ein mögliches
Sicherheitsrisiko darstellt, da es mehr Daten für das Ausspähen eines Geheimnisses des
Mobilkommunikationssystems liefert, unter dessen Verwendung die teilnehmerspezifische
Authentifizierungsinformation gebildet wird.
-
Sowohl
in der WO00/02406 als auch der WO00/02407 muss das Endgerät die Antwort
senden, ohne eine Versicherung, dass die Challenges frisch sind
und von einem vertrauenswürdigen
Netz empfangen werden. Somit ist das Endgerät nicht fähig, zu bestimmen, ob die Challenges
Teil eines Replay-Angriffs (replay attack) sind.
-
Gemäß einem
ersten Aspekt der Erfindung wird ein Authentifizierungsverfahren
für das
Authentifizieren eines Mobilknotens (MT) an ein Paketdatennetz geliefert,
das folgende Schritte umfasst:
Empfangen einer Mobilknotenkennung
und eine Schutzkodes von Mobilknoten durch das Paketdatennetz, wobei
die Mobilknotenkennung einem gemeinsamen Geheimnis entspricht, das
für die
Mobilknotenkennung spezifisch ist und von einem Telekommunikationsnetz
verwendet werden kann;
wobei das Paketdatennetz Authentifizierungsinformation
erhält,
die durch das Telekommunikationsnetz verwendet werden kann, wobei
die Authentifizierungsinformation eine Challenge und ein Sitzungsgeheimnis
umfasst, die der Mobilknotenkennung entsprechen und unter Verwendung
der Challenge und des gemeinsamen Geheimnisses abgeleitet werden
können;
Ausbilden
kryptographischer Information unter Verwendung von mindestens dem
Schutzkode und dem Sitzungsgeheimnis;
Senden der Challenge
und der kryptographischen Information vom Paketdatennetz zum Mobilknoten;
Empfangen
einer ersten Antwort, die der Challenge entspricht und auf dem gemeinsamen
Geheimnis basiert, durch das Paketdatennetz; und
Verifizieren
der ersten Antwort für
das Authentifizieren des Mobilknotens.
-
Vorzugsweise
umfasst das Verfahren ferner:
Prüfen der Gültigkeit der kryptographischen
Information unter Verwendung der Challenge und des gemeinsamen Geheimnisses
am Mobilknoten; und
Erzeugen des Sitzungsgeheimnisses und der
ersten Antwort, die der Challenge entsprechen, am Mobilknoten auf
der Basis des gemeinsamen Geheimnisses.
-
Vorzugsweise
umfasst das Verfahren weiter die folgenden Schritte:
Versehen
des Mobilknotens mit einer Teilnehmerkennung für das Telekommunikatiansnetz;
und
Ausbilden einer Netzzugangskennung aus der Teilnehmerkennung
als Mobilknotenkennung durch den Mobilknoten.
-
Vorzugsweise
umfasst das Verfahren weiter den Schritt der Erkennung des Telekommunikationsnetzes
am Paketdatennetz direkt aus der Mobilknotenkennung.
-
Vorzugsweise
umfasst das Verfahren weiter den Schritt des Versehens des Paketdatennetzes
mit einem gemeinsamen Sitzungsschlüssel auf der Basis von mindestens
einem Sitzungsgeheimnis.
-
Vorzugsweise
umfasst das Verfahren weiter den Schritt des Vorsehens einer Kommunikationsverbindung
zwischen dem Paketdatennetz und dem Mobilknoten, um die Challenge
zwischen ihnen zu kommunizieren, wobei die Kommunikationsverbindung
keine Verbindung des Telekommunikationsnetzes ist.
-
Vorzugsweise
umfasst das Verfahren ferner den Schritt der Verwendung des Teilnehmerkennungsmoduls
für das
Versehen des Mobilknotens mit einer Mobilknotenkennung. Vorzugsweise
wird das Teilnehmerkennungsmodul bei Erzeugen des Sitzungsgeheimnisses
auf der Basis eines gemeinsamen Geheimnisses, das für die Mobilknotenkennung
spezifisch ist, verwendet.
-
Vorzugsweise
umfasst das Verfahren weiter folgende Schritte:
Erhalten einer
zweiten Antwort durch das Telekommunikationsnetz; und
Verwenden
der zweiten Antwort beim Prüfen
der ersten Antwort.
-
Vorzugsweise
umfasst das Verfahren ferner den Schritt des Sendens der Challenge
vom Telekommunikationsnetz zum Mobilknoten über das Paketdatennetz.
-
Vorzugsweise
basiert der Schutzkode auf der Zeit.
-
Vorzugsweise
basiert die Challenge auf RAND-Kodes von mindestens zwei Authentifizierungstripletts des
Telekommunikationsnetzes.
-
Vorzugsweise
wird die Challenge kryptographisch unter Verwendung von mindestens
der n RAND-Kodes gebildet.
-
Vorzugsweise
umfasst das Verfahren ferner den Schritt des Versehens der Paketdatennetzes
mit einem gemeinsamen Sitzungsschlüssel auf der Basis der n Sitzungsschlüssel Kc,
die den n RAND-Kodes der Challenge entsprechen.
-
Vorzugsweise
umfasst das Verfahren ferner den Schritt der Erzeugung eines Authentifizierungsschlüssel auf
der Basis des gemeinsamen Geheimnisses, des Schutzkodes und eines
Algorithmus, der dem Mobilknoten und dem Paketdatennetz bekannt
ist. Auf diese Weise ist es möglich,
Kommunikationen zwischen dem Mobilknoten und dem Paketdatennetz
zu authentifizieren. Je höher
die Anzahl der verwendeten Sitzungsschlüssel Kc ist, desto stärker wird
ein gemeinsamer Sitzungsschlüssel
K.
-
Vorzugsweise
ist das Paketdatennetz ein IP-Netz. Noch besser ist es, wenn das
Paketdatennetz ein Mobil-IP-Netz ist.
-
In
einer alternativen Ausführungsform
umfasst das Verfahren ferner den Schritt der Erzeugung eines gemeinsamen
Sitzungsschlüssels
für den
Internet-Schlüssel-Austausch,
wobei der gemeinsame Sitzungsschlüssel auf mindestens einem Sitzungsgeheimnis
und der mindestens einen Challenge basiert.
-
In
einer alternativen Ausführungsform
umfasst der Schritt des Versehens des Mobilknotens mit der Mobilknotenkennung
und dem gemeinsamen Geheimnis, das spezifisch für die Mobilknotenidentität ist, weiter folgende
Schritte:
Ausbilden einer lokalen Verbindung zwischen dem Mobilknoten
und einer Mobilstation, wobei die Mobilstation eine Mobilknotenkennung
und das gemeinsame Geheimnis, das für die Mobilknotenkennung spezifisch
ist, aufweist;
Ausbilden einer lokalen Verbindung zwischen
dem Mobilknoten und einer Mobilstation, die die Mobilknotenkennung
und das gemeinsame Geheimnis, das für die Mobilknotenkennung identisch
ist, aufweist; und
Abrufen der Mobilknotenkennung und des gemeinsamen
Geheimnisses von der Mobilstation zum Mobilknoten.
-
Vorzugsweise
umfasst der Schritt des Versehens des Mobilknotens mit der Mobilknotenkennung
und dem gemeinsamen Geheimnis, das der Mobilknotenkennung spezifisch
ist, weiter folgende Unterschritte:
Ausbilden einer lokalen
Verbindung zwischen dem Mobilknoten und einem Teilnehmerkennungsmodul,
das die Mobilknotenkennung und das gemeinsame Geheimnis, das für die Mobilknotenkennung
spezifisch ist, aufweist; und
Abrufen der Mobilknotenkennung
und eines Sitzungsgeheimnisses, das für die Mobilknotenkennung spezifisch
ist, vom Teilnehmerkennungsmodul an den Mobilknoten.
-
Gemäß einem
zweiten Aspekt der Erfindung wird ein Authentifizierungsverfahren
in einem Mobilknoten für
das Authentifizieren des Mobilknotens gegenüber einem Paketdatennetz, geliefert,
das folgende Schritte umfasst:
Erhalten einer Mobilknotenkennung
und eines gemeinsamen Geheimnisses, welches für Mobilknotenkennung spezifisch
ist und durch ein Telekommunikationsnetz verwendet werden kann;
Erhalten
eines Schutzkodes;
Senden der Mobilknotenkennung und des Schutzkodes
an das Paketdatennetz;
Empfangen einer Challenge und einer
kryptographischen Information vom Paketdatennetz;
Prüfen der
Gültigkeit
der kryptographischen Information unter Verwendung der Challenge
und des gemeinsamen Geheimnisses;
Erzeugen eines Sitzungsgeheimnisses
und einer ersten Antwort, die der Challenge entspricht, auf der
Basis des gemeinsamen Geheimnisses; und
Senden der ersten Antwort
an das Paketdatennetz.
-
Gemäß einem
dritten Aspekt der Erfindung wird ein Mobilknoten, der zu einer
Authentifizierung gegenüber
einem Paketdatennetz fähig
ist, geliefert, wobei er umfasst:
Mittel zum Erhalten einer
Mobilknotenkennung und eines gemeinsamen Geheimnisses, das für die Mobilknotenkennung
spezifisch ist und von einem Telekommunikationsnetz genutzt werden
kann;
Mittel für
das Erhalten eines Schutzkodes;
Mittel für das Senden der Mobilknotenkennung
und des Schutzkodes an das Paketdatennetz;
Mittel für das Empfangen
einer Challenge und kryptographischer Information vom Paketdatennetz;
Mittel
für das
Prüfen
der Gültigkeit
der kryptographischen Information unter Verwendung der Challenge
und des gemeinsamen Geheimnisses;
Mittel für das Erzeugen eines Sitzungsgeheimnisses
und einer ersten Antwort, die der Challenge entspricht, auf der
Basis des gemeinsamen Geheimnisses; und
Mittel für das Senden
der ersten Antwort an das Paketdatennetz.
-
Gemäß einem
vierten Aspekt der Erfindung wird ein Gateway mit der Funktion einer
Schnittstelle zwischen einem Paketdatennetz und einem Telekommunikationsnetz,
das Zugang zu einem Authentifizierungsserver hat, geliefert, wobei
das Gateway umfasst:
einen Eingang zum Empfangen einer Mobilknotenkennung
und eines Schutzkodes vom Paketdatennetz;
einen Ausgang, um
dem Authentifizierungsserver die Mobilknotenkennung bereit zu stellen;
einen
Eingang für
das Empfangen einer Challenge und eines Sitzungsgeheimnisses, das
der Mobilknotenkennung entspricht, vom Authentifizierungsserver;
einen
ersten Prozessor für
das Ausbilden kryptographischer Information unter Verwendung von
mindestens dem Schutzkode und dem Sitzungsgeheimnis;
einen
Ausgang, um dem Paketdatennetz die Challenge und die kryptographische
Information zur weiteren Übertragung
an einen Mobilknoten bereit zu stellen;
einen Eingang für das Empfangen
einer ersten Antwort, die der Challenge entspricht, auf der Basis
eines gemeinsamen Geheimnisses, das spezifisch für die Teilnehmerkennung ist
und dem Mobilknoten und dem Telekommunikationsnetz bekannt ist,
vom Mobilknoten über
das Paketdatennetz; und
einen zweiten Prozessor für das Verifizieren
der ersten Antwort für
die Authentifizierung des Mobilknotens.
-
Gemäß einem
fünften
Aspekt der Erfindung wird ein Kommunikationssystem geliefert, das
umfasst:
ein Telekommunikationsnetz;
ein Paketdatennetz;
einen
Mobilknoten, der einen ersten Prozessor zur Bildung eines Schutzkodes
umfasst;
ein Gateway, um als eine Schnittstelle zwischen dem
Paketdatennetz und dem Telekommunikationsnetz zu fungieren;
ein
Teilnehmerkennungsmodul, auf das der Mobilknoten zugreifen kann,
welches eine Teilnehmerkennung und ein gemeinsames Geheimnis umfasst;
einen
Authentifizierungsserver für
das Telekommunikationsnetz, der das gemeinsame Geheimnis, abgebildet auf
die Teilnehmerkennung, umfasst;
wobei der Authentifizierungsserver
ausgebildet ist, um die Teilnehmerkennung zu erhalten und als Antwort eine
Challenge zurück
zu senden;
das Gateway, das einen zweiten Prozessor für das Ausbilden
kryptographischer Information auf der Basis des Schutzkodes umfasst;
den
Mobilknoten, der ausgebildet ist, vom Gateway die Challenge und
die kryptographische Information zu empfangen; und der ausgebildet
ist, um dem Teilnehmerkennungsmodul die Challenge bereit zu stellen,
um in Antwort darauf eine erste Antwort zu empfangen, die auf der
Challenge und dem gemeinsamen Geheimnis basiert;
den ersten
Prozessor, der weiter ausgebildet ist, um die kryptographische Information
unter Verwendung des Schutzkodes zu verifizieren, um das Gateway
gegenüber
dem Mobilknoten zu authentifizieren; und
einen dritten Prozessor,
auf den vom Gateway zur Verifizierung der ersten Antwort zugegriffen
werden kann, um den Mobilknoten zu authentifizieren.
-
Gemäß einem
sechsten Aspekt wird ein Computerprogrammprodukt für das Steuern
eines Mobilknoten für
die Authentifizierung des Mobilknotens gegenüber einem Paketdatennetz bereitgestellt,
wobei es umfasst:
von einem Computer ausführbaren Kode, um es dem Mobilknoten
zu ermöglichen,
eine Mobilknotenkennung und ein für die Mobilknotenkennung spezifisches
und von einem Telekommunikationsnetz nutzbares gemeinsames Geheimnis
zu erhalten;
von einem Computer ausführbaren Kode, um es dem Mobilknoten
zu ermöglichen,
einen Schutzkode zu erhalten;
von einem Computer ausführbaren
Kode, um es dem Mobilknoten zu ermöglichen, die Mobilknotenkennung und
den Schutzkode an das Paketdatennetz zu senden;
von einem Computer
ausführbaren
Kode, um es dem Mobilknoten zu ermöglichen, eine Challenge und
kryptographische Information vom Paketdatennetz zu empfangen;
von
einem Computer ausführbaren
Kode, um es dem Mobilknoten zu ermöglichen, die Gültigkeit
der kryptographischen Information unter Verwendung der Challenge
und des gemeinsamen Geheimnisses zu prüfen;
von einem Computer
ausführbaren
Kode, um es dem Mobilknoten zu ermöglichen, ein Sitzungsgeheimnis
und eine erste Antwort, die der Challenge entspricht, auf der Basis
des gemeinsamen Geheimnisses zu erzeugen; und
von einem Computer
ausführbaren
Kode, um es dem Mobilknoten zu ermöglichen, die erste Antwort
an das Paketdatennetz zu senden.
-
Gemäß einem
siebten Aspekt wird ein Computerprogrammprodukt für das Steuern
eines Paketdatennetzes, um einen Mobilknoten gegenüber dem
Paketdatennetz zu authentifizieren, geliefert, wobei es umfasst:
von
einem Computer ausführbaren
Kode, um es dem Paketdatennetz zu ermöglichen, eine Mobilknotenkennung
und einen Schutzkode von einem Mobilknoten zu empfangen, wobei die
Mobilknotenkennung einem gemeinsamen Geheimnis entspricht;
von
einem Computer ausführbaren
Kode, um es dem Paketdatennetz zu ermöglichen, eine Authentifizierungsinformation
zu erhalten, die vom Telekommunikationsnetz verwendbar ist, wobei
die Authentifizierungsinformation eine Challenge und ein Sitzungsgeheimnis
umfasst, die der Mobilknotenkennung entsprechen und unter Verwendung
der Challenge und dem gemeinsamen Geheimnis ableitbar sind;
von
einem Computer ausführbaren
Kode, um es dem Paketdatennetz zu ermöglichen, kryptographische Information
unter Verwendung von mindestens dem Schutzkode und dem Sitzungsgeheimnis
zu bilden;
von einem Computer ausführbaren Kode, um es dem Paketdatennetz
zu ermöglichen,
die Challenge und die kryptographische Information an den Mobilknoten
zu senden;
von einem Computer ausführbaren Kode, um es dem Paketdatennetz
zu ermöglichen,
eine erste Antwort, die der Challenge entspricht und auf dem gemeinsamen
Geheimnis basiert, vom Mobilknoten zu empfangen; und
von einem
Computer ausführbaren
Kode, um es dem Paketdatennetz zu ermöglichen, die erste Antwort
unter Verwendung des Sitzungsgeheimnisses zu verifizieren.
-
In
einer alternativen Ausführungsform
umfasst das Verfahren den Schritt der Authentifizierung der Mobilknotens
gegenüber
dem Paketdatennetz mit einem vorläufigen Authentifizierungsverfahren
vor dem Authentifizieren des Mobilknotens gegenüber dem Paketdatennetz.
-
Vorteilhafterweise
können
durch die Verwendung des Geheimnisses, das dem Telekommunikationsnetz
und dem Mobilknoten gemeinsam ist, Teilnehmerkennungsmodule für die starke
gegenseitige Authentifizierung verwendet werden. Dies liefert ein
geradliniges, vertrauenswürdiges
Authentifizierungsverfahren, in welchem existierende Authentifizierungsdaten
des Telekommunikationsnetzes verwendet werden können.
-
Die
Ausführungsformen
eines Aspekts gelten auch für
verschiedene andere Aspekte der Erfindung. Aus Gründen der
Knappheit wurden die Ausführungsformen
nicht in Verbindung mit jedem Aspekt der Erfindung wiederholt. Ein
kundiger Leser wird die Vorteile der verschiedenen Aspekte auf der
Basis der Vorteile des ersten Aspekts der Erfindung wahrnehmen.
-
Die
Erfindung wird nun, nur beispielhaft, unter Bezug auf die begleitenden
Zeichnungen beschrieben.
-
1 zeigt
ein System, das ein IP-Netz umfasst, das eine der IP-Vernetzung
gemäße Mobilstation umfasst,
gemäß einer
bevorzugten Ausführungsform
der Erfindung;
-
2 zeigt
ein Austauschverfahren für
einen gemeinsamen Sitzungsschlüssel
des Systems der 1;
-
3 zeigt
eine Authentifizierungserweiterung gemäß dem System der 1;
-
4 zeigt
das Format einer neuen Anforderungserweiterung für einen gemeinsamen Sitzungsschlüssel des
Systems der 1;
-
5 zeigt
das Format einer neuen Antworterweiterung des gemeinsamen Sitzungsschlüssels des Systems
der 1;
-
6 zeigt
eine Signed RESponse (SRES)-Erweiterung des Systems der 1;
-
7 zeigt
eine Architektur eines Mobilkommunikationssystems gemäß einer
anderen Ausführungsform
der Erfindung;
-
8 zeigt
signifikante Funktionsblöcke
des Systems der 7;
-
9 zeigt
die Hauptsignalisierungsereignisse des Systems der 7;
-
10 zeigt
ein detailliertes Signalisierdiagramm einer Authentifizierungsoperation
des Systems der 7;
-
11a und 11b bilden
zusammen ein Flussdiagramm, das die Funktionalität einer öffentlichen Zugangssteuerung
während
der Authentifizierung des Systems der 7 zeigt;
-
12a bis 12d bilden
zusammen ein Flussdiagramm, das die Funktionalität des Global System for Mobile
Communications/General Packet Radio Service Authentication- und Abrechnungsgateways
während
der Authentifizierung des Systems der 7 zeigt;
-
13 zeigt
die Hauptsignalisierung einer gesteuerten Verbindungsunterbrechung
des Mobilknotens vom Netz des Systems der 7;
-
14 zeigt
ein Internet-Schlüssel-Austausch-Verfahren,
wenn ein Mobilknoten ein Initiator der Internet-Schlüssel-Austausch-Verhandlung
ist, gemäß einer
nochmals anderen Ausführungsform
der Erfindung;
-
15 zeigt
Modifikationen des Verfahrens der 14, wenn
die öffentliche
Zugangssteuerung (Public Access Controller) statt des Mobilknotens
ein Initiator der Internet-Schlüssel-Austausch-Verhandlung
ist; und
-
16 zeigt
das Verfahren in einem Authentifizierungssystem gemäß einer
Ausführungsform
der Erfindung.
-
Im
Folgenden wird eine bevorzugte Ausführungsform der Erfindung unter
Anwendung auf ein Telekommunikationsnetz eines globalen Systems
für Mobilkommunikation
(Global System for Mobile Communications, GSM) beschrieben. Für die Authentifizierung
eines Mobilknotens gegenüber
einem Paketdatennetz werden Teilnehmerkennungsmodulkarten (Subscriber
Identity Modul, SIM), die normalerweise für die Authentifizierung von
GSM-Teilnehmern verwendet werden, verwendet. Während des Authentifizierungsverfahrens kommuniziert
das SIM und das GSM-Telekommunikationsnetzwerk über das Paketdatennetz statt über das GSM-Telekommunikationsnetz.
-
Der
tatsächliche
Typ des Telekommunikationsnetzes ist irrelevant. GSM wird als ein
Beispiel verwendet, aber der Netztyp könnte auch ein universales Mobiltelekommunikationssystem
(Universal Mobile Telecommunications System, UMTS) oder ein GSM
mit einem allgemeinen Paketfunkdienst (General Packet Radio Service,
GPRS) sein. Tatsächlich
kann man das GPRS als eine Erweiterung des GSM statt eines unabhängigen Netzes
in dem Sinn ansehen, dass das GPRS unter Verwendung des GSM-Funkzugangsnetzes
und von GSM-Authentifizierungsverfahren arbeitet.
-
Die
Erfindung wird unter Verwendung von drei Beispielen beschrieben.
Beispiel 1 bezieht sich auf eine Mobil-IP-Implementierung, wo existierende Mobil-IP-Extensions
verwendet werden. Beispiel 2 bezieht sich auf eine drahtlose LAN-Umgebung
mit einem Roaming von einem Unternetzwerk zu einem anderen Unternetzwerk.
Beispiel 3 bezieht sich auf die Erzeugung von IKE-Schlüsseln für Internetknoten.
-
Beispiel 1: Mobil-IP
-
In
der bevorzugten Ausführungsform
der Erfindung werden Mobilknoten durch eine internationale Mobilteilnehmerkennung
(IMSI) in Form einer Folge von Ziffern identifiziert. Die IMSI ist
per Definition eine eindeutige Teilnehmerkennung, die aus einer
nationalen Mobilteilnehmerkennung und einem Mobilländerkode (mobile
country code) besteht. Beispielsweise wird im GSM die IMSI durch
eine Anzahl von Bytes, die geringer als Anzahl von Ziffern in der
IMSI sind, dargestellt.
-
Die
IMSI wird in Mobil-IP-Nachrichten als Netzzugangskennung (NAI) übertragen.
Die NAI liegt in der Form imsi@sonera.fi (beispielsweise 1234567@sonera.fi)
oder imsi@gsm.org (beispielsweise „1234567@gsm.org") vor. Somit trägt die NAI
eine Kennung (beispielsweise als Text oder als eine Kennungsnummer)
des Mobiltelekommunikationsnetzes, dessen Teilnehmer der Mobilknoten
ist, und eine Identifikation der Domain des Mobilknotens. Dies ermöglicht das
Erkennen des Telekommunikationsnetzes direkt aus der NAI.
-
Das
letztere der beiden Beispiele der NAI, die gsm.org-Domain, ist ein Beispiel
einer Domain oberer Ebene, die angepasst ist, um nach der passende
Domain in Bezug auf den relevanten GSM-Telekommunikationsnetzbetreiber
zu suchen.
-
Das
Ausbilden der NAI aus der IMSI ermöglicht später eine Bestimmung des relevanten
GSM-Telekommunikationsnetzbetreibers
durch das Paketdatennetz auf der Basis der NAI allein. Dies beseitigt
die Notwendigkeit, im Paketdatennetz irgend eine lokale Datenbank
zu führen,
die zusammen unterschiedliche Telekommunikationsnetzbetreiber und
ihre Teilnehmer abbildet.
-
Im
allgemeinen ist die Identifizierung von Mobilknoten mit NAIs einem
Fachmann im Bereich von Mobile IP bekannt. Eine NAI-Erweiterung
kann in eine Registrieranforderung oder eine Registriererwiderung,
die beide später
beschrieben werden, eingefügt
werden.
-
Es
wird nun die Funktion der SIM-Karte im GSM-Telekommunikationsnetz erläutert. Im
GSM sind Authentifizierungsalgorithmen bekannt, die als A3 und A8
bezeichnet werden. Diese Algorithmen laufen auf dem SIM und im GSM-Telekommunikationsnetz.
Diese Algorithmen und ein gemeinsames GSM-Geheimnis Ki sind dem
SIM und dem Betreiber des GSM-Telekommunikationsnetzes bekannt,
der sie typischerweise in einem Heimatregister (Home Location Register,
HLR) einer Mobilvermittlungszentrale (Mobile services Switching Centre,
MSC) speichert.
-
Bei
der Authentifizierung erzeugt der Betreiber des GSM-Telekommunikationsnetzes
eine Challenge RAND, das ist ein 128 Bit Zufallskode, der als eine
Challenge verwendet werden soll, einen entsprechenden 64 Bit GSM-Sitzungsschlüssel Kc
und eine 32 Bit unterzeichnete Antwort (signed response) SRES für das Verifizieren
der Antwort gegenüber
der Challenge. Der 64 Bit Sitzungs-GSM-Sitzungsschlüssel Kc
wird durch den A8 Algorithmus erzeugt als A8(Ki,RAND)
und die 32 Bit lange SRES wird durch A3(Ki,RAND)
erzeugt. Die Kombination RAND, SRES und Kc wird im allgemeinen als
GSM-Triplett bezeichnet. Der Betreiber des GSM-Telekommunikationsnetzes
sendet die RAND an seinen Teilnehmer (GSM-Telefon), die RAND wird durch
den Teilnehmer empfangen, und der Teilnehmer gibt sie an das SIM,
das die SRES und Kc reproduziert. Dann antwortet das SIM auf die
Challenge durch das Senden der SRES. Der Betreiber empfängt die
SRES und kann die Identität
des SIM bestätigen.
Der Betreiber des GSM-Telekommunikationsnetzes kann auch verifizieren,
dass er einen Kc mit dem SIM teilt. Dann kann der Kc verwendet werden,
um Datenverkehr über
einen GSM-Funkkanal
zu verschlüsseln.
Der Vorteil dieses Challenge-Antwort-Mechanismus
ist der, dass der Kc nie über
den GSM-Funkkanal
gesendet werden muss und somit nicht abgehört werden kann.
-
1 zeigt
ein Kommunikationssystem 10, das ein Mobil-IP-Netzwerk MIP, das
einen für
die IP-Vernetzung geeigneten Mobilknoten MT aufweist, umfasst, gemäß einer
bevorzugten Ausführungsform
der Erfindung. Der Mobilknoten MT ist typischerweise ein Laptop-Computer
mit einem drahtlosen Netzadapter und Software für die Vernetzung. Eine Vielzahl
von Mobilknoten MT können
an das MIP angefügt
werden. Der Mobilknoten MT umfasst eine Tastatur KB, ein Teilnehmerkennungsmodul
SIM_B, einen ersten Funkblock FR1 (einen PCMCIA drahtlosen LAN-Adapter)
für das
Kommunizieren mit einem Funkzugangspunkt über einen WLAN-Funkkanal, (optional)
einen zweiten Funkblock RF2 (ein PCMCIA GSM-Adapter) für das Kommunizieren mit einem
GSM-Netz GSM_B, eine Hauptverarbeitungseinheit (master processing
unit, MPU, beispielsweise ein Mikroprozessor oder ein digitaler
Signalprozessor) für
das Steuern der vorher erwähnten
Blöcke, und einen
Speicher MEM1, der eine erste Software SW1 für das Betreiben der MPU enthält.
-
Das
MIP umfasst eine Vielzahl von Zugangspunkten AP, um dem MT eine
drahtlose Verbindung zu liefern, eine öffentliche Zugangssteuerung
(Public Access Controller) PAC für
das Steuern der APs und einen fremden Authentifizierungs-, Autorisierungs-
und Abrechnungsserver FAAA (Foreign Authentication, Authorisation
and Accounting server).
-
Das
GSM-Netz GSM_B ist ein Heimat-GSM-Netz des SIM_B. Das GSM_B umfasst
einen Heimat-Authentifizierungs-, Autorisierungs- und Abrechnungsserver
HAAA (Home Authentication, Authorisation and Accounting server),
der eine Datenbank der Teilnehmerdaten besitzt, die Abrechnungs- und Autorisierungsdaten der
Teilnehmer des GSM_B umfasst. Diese Daten umfassen die IMSI und
das gemeinsame GSM-Geheimnis Ki für
jeden Teilnehmer.
-
Das
MIP ist mit dem GSM_B durch ein GSM-Authentifizierungs-Gateway GAGW verbunden.
Das GAGW ist ein Server und es besitzt einen Speicher MEM2 für das Speichern
einer zweiten Software SW2 und einen Zentralprozessor CPU für das Steuern
des Betriebs des Servers durch das Ausführen der zweiten Software SW2.
Das GAGW verbindet einen Server im GSM_B und einen Server im MIP.
Diese Server sind als ein Heimat-AAA-Server HAAA (AAA bezieht sich auf Authentifizierung,
Autorisierung und Abrechnung) und ein Fremd-AAA-Server FAAA bezeichnet.
Die PAC kann auch als ein Mobilitätsagent MA fungieren. Wenn
das MIP das Heimatnetz des MT ist, so ist auch die PAC ein Heimatagent
HA des MT. Ansonsten gehört
die PAC zu einem fremden Netz und die PAC kann als fremder Agent
(Foreign Agent) FA bezeichnet werden. Der HAAA befindet sich im
GSM_B, und der FAAA befindet sich im MIP. Die Kommunikation zwischen
den beiden AAA-Servern findet mittels eines geeigneten AAA-Protokolls
statt. Das AAA-Protokoll wird hier nicht beschrieben.
-
Es
wird nun ein Überblick
des Authentifizierungsverfahrens kurz beschrieben. Um einen Mobilknoten gegenüber einem
Paketdatennetz zu authentifizieren, wird ein gemeinsamer Sitzungsschlüssel K sowohl
im MT als auch im FAAA-Server erzeugt. Die Authentifizierung wird
unter Verwendung des GSM_B und seines SIM, SIM_B, ausgeführt. In
diesem Fall wird das Authentifizierungsverfahren ähnlich dem
sein, das oben in Bezug auf ein Basis-GSM-Netz beschrieben wurde.
Die Authentifizierung verwendet den Ki,
der auf dem SIM_B und dem GSM_B vorhanden ist. Auf das SIM_B wird
zugegriffen, indem der MT (beispielsweise ein Laptop-Computer mit
einem drahtlosen Lokalnetzadapter) mit einem SIM-Kartenleser versehen
wird. Alternativ greift das MIP nicht direkt auf den Ki des
GSM_B zu, sondern empfängt
eine RAND, die sich auf das SIM_B bezieht. Diese RAND wird an den
MT gesandt, und die RESP wird gegen die RESP, die das Telekommunikationsnetz
erzeugt hat, verifiziert. Die Authentifizierung kann weiter durch
die Verwendung mehrerer RANDs, um einen Authentifizierungsschlüssel zu
erzeugen, der sicherer als nur gerade ein Kc ist, verbessert werden.
-
2 zeigt
ein Austauschverfahren für
einen gemeinsamen Sitzungsschlüssel
des Systems der 1. Nachfolgend wird das Verfahren
kurz zusammengefasst und dann detaillierter beschrieben.
- 1. Der MT sendet an den FAAA eine Netzzugangskennung
NAI und einen Schutzkode MT_RAND (der in der Terminologie des Mobile-IP als Nonce bezeichnet
wird), der durch den MT erzeugt wird. Der MT_RAND bleibt während einer
Authentifizierungssitzung derselbe und seine Bedeutung besteht im
Verhindern von Replay-Attacken. Der MT_RAND ist typischerweise eine
Zufallszahl oder basiert auf der Zeit (ein Zeitstempel mit einer
gewissen Auflösung).
- 2. Der FAAA sendet an den HAAA eine Anfangsidentifizierungsnachricht,
die die IMSI oder NAI des MT und den MT_RAND enthält.
- 3. Der HAAA gewinnt n GSM-Tripletts wieder, wobei jedes eine
RAND, einen Kc und eine SRES umfasst. Dann berechnet der HAAA den
K = H(n*Kc, MT_RAND) für
den MT. Hier ist n eine ganze Zahl größer oder gleich 1, * stellt
die Anzahl der Parameter dar (n*Kc bezieht sich auf n verschiedene
Kcs), und H( ) stellt eine Einweg-Hash-Funktion dar. Der HAAA berechnet
auch einen Wert SIGNrand, der aus MRC(K,n*RAND,MT_RAND) berechnet
wird, wobei MAC einen Nachrichtenauthentifizierungskode bezeichnet.
SIGNrand ist eine kryptographische Prüfsumme, um zu verifizieren,
dass die n RANDs wirklich von einer Einheit stammen, die einen Zugang
zum Ki hat (da K davon abgeleitet ist).
Die Prüfsumme
zeigt auch an, ob die n RANDs wirklich während derselben Authentifizierungssitzung
erzeugt werden, da sich MT_RAND von einer Authentifizierungssitzung
zur anderen ändert.
- 4. Der HAAA sendet die n RANDs, die SIGNrand und wahlweise die
IMSI an den FAAA. Die IMSI selbst muss nicht benutzt werden, wenn
eine andere Sitzungskennung mit der IMSI im Schritt 1 dieses Verfahrens gesendet
wurde. In diesem Fall würde
diese Sitzungskennung statt der IMSI verwendet.
- 5. Der FAAA sendet mindestens eine RAND und die SIGNrand an
den MT.
- 6. Unter Verwendung von i, das auf dem
SIM_B gespeichert ist, berechnet der MT den K. Unter Verwendung des
K, der n RANDs und der MT_RAND testet der MT dann SIGNrand. Wenn
SIGNrand korrekt ist, so erzeugt der MT Kopien der n SRESs (eine
für jede
RAND). Der MT berechnet eine kryptographische Prüfsumme SIGNsres = HASH2(k,n*SRES)
für den
K und die SRESs.
- 7. Der MT sendet die SIGNsres an den FAAA. Im MT ist die Berechnung
des K dieselbe wie die Berechnung des K im HAAA.
- 8. Der FAAA sendet die SIGNsres an den HAAA.
- 9. Der HAAA verifiziert, das die SIGNres gültig ist, durch das Prüfen, dass
die Gleichung SIGNsres = HASH2(K,n*SRES) mit den Werten, die der
MT empfangen hat, gilt. Der HAAA sendet das Ergebnis (ob die SIGNsres
gültig
ist) an den FAAA. Wenn die SIGNsres gültig ist, sendet der HAAA auch
den K an den FAAA.
- 10. Die Authentifizierung ist komplett und der FAAA und der
MT verwenden den K gemeinsam.
-
Der
FAAA ist funktionell mit mehreren HAAAs verbunden, und der FAAA
wählt den
korrekten HAAA auf der Basis des Domain-Teils der Benutzer-NAI, beispielsweise „sonera.fi" aus. Der HAAA verwendet
ein HAAA-HAAA Protokoll, um die anfängliche Identifikationsnachricht
an den korrekten HAAA oder die GSM-Infrastruktur, wie eine Mobilvermittlungszentrale
(MSC), zu senden. Gemäß einer
alternativen Ausführungsform ist
der FAAA konfiguriert, um mit einem einzigen HAAA zu kommunizieren
und sendet immer die Nachricht im Schritt 1 an diesen HAAA.
-
Es
wird nun das Verfahren der 2 beschrieben.
Es beginnt mit einer Nachrichtenregistrieranforderung, die eine
Neuer-Sitzungsschlüssel-Anforderungs-Erweiterung
enthält.
Diese und die folgenden Erweiterungen werden unter Bezug auf die 3 bis 6 später erläutert. Die
IMSI kann in einer Netzzugangskennung-(NAI)-Erweiterung übertragen
werden. Die Neuer-Sitzungsschlüssel-Anforderungs-Erweiterung
enthält die
maximale Lebenszeit des Schlüssels
und eine Zufallszahl MT_RAND, die durch den MT gewählt wird. Wenn
der MA die Registrieranforderung mit der Neuer-Sitzungsschlüssel-Anforderungs-Erweiterung
empfängt,
sendet er die NAI (die die IMSI enthält) und die MT_RAND an den
HAAA. Wenn der MA ein Heimatagent ist, der durch den Betreiber eines
GSM-Telekommunikationsnetzes
betrieben wird, so hat der Heimatagent typischerweise einen direkten
Zugang zu GSM-Tripletts.
In einer Ausführungsform
der Erfindung werden eine Anzahl von Tripletts im Voraus wiedergewonnen,
um die Registrierung zu beschleunigen. Wenn der HAAA die n GSM- Tripletts für den MT
auf irgend eine Weise erhalten hat, so berechnet der den neuen K
und eine Authentikator SIGNrand, wie das oben beschrieben ist.
-
Der
MA sendet dann eine Registrierantwort mit einer Neuer-Sitzungsschlüssel-Antwort-Erweiterung an
den MT. Die Registrierantwort enthält die MT_RAND und die SIGNrand,
so dass der MT verifizieren kann, dass die RANDs aktuell sind und
dass sie durch die GSM-Infrastruktur erzeugt wurden. Die Registrierantwort enthält auch
die verbleibende Lebenszeit des Schlüssels, die gleich oder kleiner
als die Lebenszeit, die vom MT vorgeschlagen ist, sein kann.
-
Wenn
der MT und MA keinen gemeinsamen Kontext verwenden, wird die Authentifizierung
der ersten Registrieranforderung und der Registrierantwort fehlschlagen.
Der Antwortkode in der Registrierantwort ist „misslungene Authentifizierung
des Mobilknotens" oder „Identifikationsfehlanpassung". Im Mobil-IP wird eine Authentifizierungserweiterung
verwendet. Die Authentifizierungserweiterung weist einen speziellen
Wert für ein
Sicherheitsparameterindex-(SPI)-Feld auf, das bedeutet „Austausch
eines neuen Sitzungsschlüssels". Der SPI und die
IP-Adresse des MT werden als ein Index für das Verwalten von Authentifizierungsverfahren
im Hinblick auf unterschiedliche Mobilknoten verwendet. Die Authentifizierungserweiterung
weist auch ein Feld für einen
Authentikator, das ist typischerweise ein MAC-Kode, auf. Der Authentikator
kann leer sein. Wenn somit der MA die Authentifizierung gemäß der vorliegenden
Erfindung nicht unterstützt,
wird er einfach mit dem Antwortkode „misslungene Authentifizierung
des Mobilknotens" antworten.
Wenn der MA ein fremder Agent ist, sollte der MT die Authentifizierungserweiterung
insgesamt weglassen.
-
Nach
dem Empfangen der Registrierantwort mit der Neuer-Sitzungsschlüssel-Antwort-Erweiterung
ist der MT fähig,
die Gültigkeit
von SIGNrand zu verifizieren. Wenn die SIGNrand gültig ist,
so erzeugt der MT den Schlüssel
K und die SIGNsres und schafft einen neuen Sicherheitskontext für den MA
oder, wenn ein solcher schon existiert, aktualisiert er den Kontext
mit dem neuen K. Dieser Schlüssel
wird als Mobil-IP-Authentifizierungsschlüssel in
nachfolgenden Registriernachrichten verwendet.
-
Der
MT fügt
die SIGNsres in eine SRES-Erweiterung bei der nächsten Registrieranforderung
ein und sendet sie an den MA. Der MA sendet die SIGNsres an den
HAAA, der sie verifiziert und eine Anzeige an den MA sendet. Wenn
die SIGNsres gültig
ist, sendet der HAAA auch den K an den MA. Der MA kann nun den Sicherheitskontext
für den
MT erzeugen/aktualisieren.
-
Wenn
der MA der FA ist, könnte
der K nun an alle fremden Agenten in der besuchten Domain verteilt werden.
-
Da
es sein kann, dass der MA die SRES-Erweiterung schnell bekommen
muss, ist es vorteilhaft, dass der MT die Registrieranforderung
mit der SRES-Erweiterung direkt nach dem Empfang der RAND sendet.
-
Der
Sicherheitskontext, der durch den oben beschriebenen K-Austauschmechanismus
geschaffen wurde, weist einen SPI auf. Hier wird ein anderer wohl
bekannter SPI für
den SIM-erzeugten
Sicherheitskontext verwendet. Ein Wert ist für den SPI „SIM-erzeugter Sicherheitskontext" und für den SPI „Austausch
eines neuen Sitzungsschlüssels" reserviert.
-
Gemäß der bevorzugten
Ausführungsform
ist der Standardalgorithmus bei der Mobil-IP-Authentifizierung in
MD5 in einem Präfix-Suffix-Modus
verschlüsselt.
In diesem Modus wird eine Authentifizierungsfingerabdruck (authentification
digest) für
eine Nachricht durch das Laufenlassen des MD5 über den folgenden Strom von
Bytes berechnet: ein erstes Auftauchen des K und der geschützten Felder
von der Registrieranforderung und ein zweites Auftauchen des K.
-
Der
Authentifizierungsfingerabdruck wird in einer Authentifizierungserweiterung übertragen,
wie das in 3 gezeigt ist. 3 zeigt
eine beispielhafte Bitmap als Tabelle von Bits, wobei jede Zeile
vier Oktette aufweist. Es gibt drei Arten von Authentifizierungserweiterungen:
eine obligatorische Mobil-Heimat-Authentifizierungserweiterung,
die zwischen dem MT und dem Heimatagenten verwendet wird, eine optionale
Mobil-Fremd-Authentifizierungserweiterung, die zwischen dem MT und
dem fremden Agenten verwendet wird, und eine optionale Fremd-Heimat-Authentifizerungserweiterung,
die zwischen dem FA und dem HA verwendet wird. Alle diese Erweiterungen
haben dasselbe Format. Der SPI ist eine durchsichtige Kennung. Ein
Authentifikator (der den Empfänger
der Nachricht verifiziert) für
die Authentifizierungserweiterung bildet den SPI und die IP-Adresse des Teilnehmers
auf einen Sicherheitskontext in der Mobilitätssicherheitsverbanddatenbank (mobility
security association database) ab. Der Sicherheitskontext enthält einen
Schlüssel,
den Algorithmus und andere Sicherheitsparameter. Das Authentifikatorfeld
enthält
die Nachrichtenauswahl.
-
In
der Mobil-IP-Authentifizierung gemäß der bevorzugten Ausführungsform
werden die Sicherheitskontexte (die den K einschließen) unter
Verwendung des SIM_B erzeugt. Da die RANDs durch das GSM_B, beispielsweise
durch den HAAA, erzeugt werden, muss der MT zuerst seine IMSI an
den MA, mit dem er sich registriert, senden. Dann kann der MA das
FAAA-HAAA Protokoll verwenden, um die GSM-Authentifizierungsinformation
für den
MT zu erhalten (wie dies oben beschrieben wurde) und diese Information
für das
Erzeugen des K mit der MT verwenden. Nachdem der K erzeugt wurde,
kann der MT sich mit/durch den MA registrieren.
-
Der
K kann für
mehrere nachfolgende Registrierungen verwendet werden. Es gibt jedoch
eine Lebensdauer für
diesen K, und bevor die Lebensdauer abläuft, kann ein neuer K durch
ein ähnliches
Verfahren erzeugt werden.
-
Die
K-Austauschnachrichten zwischen dem MT und dem MA werden als Erweiterungen
der Registrieranforderung und der Registrierantwort übertragen.
Drei neue Erweiterungen für
die Registriernachrichten zwischen dem MT und dem MA werden benötigt, um
sich über
den K zu einigen. Diese Erweiterungen sind Neuer-Sitzungsschlüssel-Anforderungs-Erweiterung,
eine Neuer-Sitzungsschlüssel-Antwort-Erweiterung
und eine SRES-Erweiterung.
-
Typischerweise
weiß der
MT, dass sein HA die Authentifizierung gemäß der vorliegenden Erfindung unterstützt. Es
kann jedoch sein, dass der MT nicht weiß, welches Authentifizierungsverfahren
oder welche Authentifizierungsverfahren der FA unterstützt. Um
zu prüfen,
ob der FA das Authentifizierungsverfahren gemäß der Erfindung unterstützt, schließt der MT
die Neuer-Sitzungsschlüssel-Anforderungs-Erweiterung
für den
fremden Agenten in die erste Registrierantwort ein und lässt die
Mobil-Fremd-Authentifizierungs-Erweiterung
weg. Die Neuer-Sitzungsschlüssel-Anforderungs-Erweiterung
ist optional. Wenn der FA sie nicht unterstützt, sollte der FA sie ignorieren
und sie entfernen, bevor der die Anforderung an den HA weiter gibt.
Wenn die MT die Registrierantwort empfängt, implementiert sie die
folgende Logik:
-
– Wenn die
Registrierantwort eine Neuer-Sitzungsschlüssel-Antwort-Erweiterung enthält, und
der Antwortkode vom FA der Fehlerkode „misslungene Authentifizierung
des Mobilknotens" ist,
unterstützt
der FA die Authentifizierung gemäß der vorliegenden
Erfindung. Wenn die Neue-Sitzungsschlüssel-Antwort gültig ist, erzeugt der MT einen
Sicherheitskontext für
den FA und fügt
eine SRES-Erweiterung für
den FA in die nächste Registrieranforderung
ein.
- – Wenn
der FA den Antwortkode nicht auf einen Fehlerkode festsetzt, und
die Registrierantwort keine Neue-Sitzungsschlüssel-Antwort-Erweiterung
enthält,
und der Antwortkode vom FA nicht gesetzt ist, so unterstützt der
FA die Authentisierung nicht, sondern ermöglicht alternativ Registrierungen
mit der Mobil-Fremd-Authentifizierung. Der MT kann nachfolgende
Registrierungen mit dem FA ausführen,
ohne dass irgend welche Authentifizierungserweiterungen erforderlich
sind.
- – Wenn
die Registrierantwort keine Neue-Sitzungsschlüssel-Antwort-Erweiterung enthält, und
der Antwortkode vom fremden Agenten der Fehlerkode „misslungene
Authentifizierung des Mobilknotens" darstellt, so unterstützt der
FA keine Authentifizierung gemäß der vorliegenden
Erfindung und erfordert so eine andere Art der Authentifizierung.
In diesem Fall kann, wenn der MT nur die Authentifizierungsfunktion
gemäß der vorliegenden
Erfindung aufweist, er keine Registrierung mit dem FA durchführen.
-
Wenn
der FAAA eine Registrierungsanforderung von einem Mobilknoten empfängt, mit
dem der FA keinen Sicherheitskontext teilt, hat der FA die folgenden
Optionen:
- – Wenn
es eine ungültige
Mobil-Fremd-Authentifizierungs-Erweiterung
in der Registrieranforderung gibt, so antwortet der FA mit dem Fehlerkode „misslungene
Authentifizierung des Mobilknotens". Das ist das Standard-Mobil-IP-Verhalten.
- – Wenn
die Registrieranforderung keine Mobil-Fremd-Authentifizierungs-Erweiterung enthält, und
wenn die lokale Praxis keine Mobil-Fremd-Authentifizierung erfordert,
gibt der FA die Registrieranforderung an den HA. Der FA fügt keine
Neue-Sitzungsschlüssel-Antwort-Erweiterung
in die Registrierantwort ein, sogar dann, wenn es eine Neue-Sitzungsschlüssel-Anforderungs-Erweiterung
in der Registrieranforderung gegeben hat. Dies ist das Standardverhalten
vom Mobil-IP. Diese Konfiguration könnte beispielsweise in gemeinsamen
Zugangszonen nützlich
sein.
- – Wenn
die lokale Praxis im FA die Mobil-Fremd-Authentifizierung fordert, und es keine
Mobil-Fremd-Authentifizierungs-Erweiterung
noch eine Neue-Sitzungsschlüssel-Anforderungs-Erweiterung
in der Registrieranforderung gibt, so antwortet der FA mit dem Fehlerkode „misslungene
Authentifizierung des Mobilknotens". Dies ist das Standardverhalten vom
Mobil-IP.
- – Wenn
die lokale Praxis im FA die Mobil-Fremd-Authentifizierung fordert, und die Registrieranforderung eine
Neue-Sitzungsschlüssel-Anforderungs-Erweiterung
und keine Mobil-Fremd-Authentifizierungs-Erweiterung enthält, so gibt
der FA die Registrieranforderung nicht an den Heimatagenten, sondern
antwortet stattdessen mit dem Fehlerkode „misslungene Authentifizierung
des Mobilknotens" und
fügt eine
Neue-Sitzungsschlüssel-Antwort-Erweiterung
in die Registrierantwort ein. Wenn der MT dann eine andere Registrieranforderung
mit einer gültigen
SRES-Erweiterung und einer gültigen
Mobil-Fremd-Authentifizierungs-Erweiterung sendet, gibt der FA die
Anforderung an den HA.
-
Nur
gewisse GSM-Teilnehmer sind autorisiert, sich durch einen speziellen
MA zu registrieren. Die Benutzerautorisation kann in jeder der folgenden
Einheiten durchgeführt
werden:
- – der
GSM-Infrastruktur. Das GSM-Telekommunikationsnetz (MSC/HLR) kann
eine Authentifizierung gemäß der vorliegenden
Erfindung nur für
gewisse Teilnehmer unterstützen.
- – dem
HAAA. Der HAAA kann mit einer Liste autorisierter IMSIs konfiguriert
sein. Der HAAA kann eine getrennte Liste für jede Zugangssteuerung, mit
der er verbunden ist, aufweisen. Dies ermöglicht dem HAAA zu entscheiden,
welche Teilnehmer autorisierte Benutzer eines gewissen MA sind.
Wenn der HA durch den Betreiber des GSM-Telekommunikationsnetzes
betrieben wird, kann der HAAA bequemerweise diese Art von Autorisationsinformation
speichern.
- – dem
FAAA. Wenn eine Firma den FAAA betreibt, beispielsweise für ihre Angestellten,
kann es sein, dass die Firma wünscht,
zu steuern, welchen GSM-Teilnehmern es ermöglicht wird, eine Registrierung
mit dem FAAA durchzuführen.
In diesem Fall muss der MA eine Liste autorisierter GSM-Teilnehmer
führen.
Der MA muss die IMSI auch im Klartext sehen. Wenn eine Verschlüsselung
mit einem öffentlichen
Schlüssel
zwischen dem MS und dem HAAA verwendet wird, um die IMSI zu schützen, kann
es sein, dass der HAAA die Klartext-IMSI an den MA senden muss,
so dass der MA prüfen
kann, ob der MT autorisiert ist, eine Registrierung mit dem FAAA
durchzuführen.
-
Die
Neue-Sitzungsschlüssel-Austausch-Erweiterungen
sind normale (nicht kritische) Erweiterungen, die vorzugsweise in
einer MT-AAA-Authentifizierungserweiterung gespeichert werden. Alternativ
können
die lieferantenspezifische Sitzungs-Erweiterungen verwendet werden.
Wenn der Empfänger
der Registrieranforderung die Erweiterung nicht erkennt, wird die
Erweiterung verworfen.
-
Der
Sitzungsschlüsselaustausch
zwischen dem MT und dem FA ist unabhängig vom K-Austausch zwischen
dem MT und dem HA. Somit enthält
eine Registrieranforderung Folgendes:
- – eine Neue-Sitzungsschlüssel-Anforderung-Erweiterung
für den
FA,
- – eine
Neue-Sitzungsschlüssel-Anforderung-Erweiterung
für den
HA,
- – eine
Neue-Sitzungsschlüssel-Anforderung-Erweiterung
sowohl für
den FA als auch den HA,
- – eine
SRES-Erweiterung für
den FA,
- – eine
SRES-Erweiterung für
den HA,
- – eine
SRES-Erweiterung sowohl für
den FA als auch den HA,
- – eine
Neue-Sitzungsschlüssel-Anforderung-Erweiterung
für den
FA und eine SRES-Erweiterung für
den HA, und
- – eine
SRES-Erweiterung für
den FA und eine Neue-Sitzungsschlüssel-Anforderung
für den
HA.
- Typischerweise enthält
die Registrierantwort irgend eine der folgenden Dinge:
- – eine
Neue-Sitzungsschlüssel-Antwort-Erweiterung
vom FA,
- – eine
Neue-Sitzungsschlüssel-Antwort-Erweiterung
vom HA, und
- – eine
Neue-Sitzungsschlüssel-Antwort-Erweiterung
sowohl vom FA als auch dem HA.
-
Das
Format der Neue-Sitzungsschlüssel-Anforderung-Erweiterung
ist in 4 gezeigt. Der MT kann die Neue-Sitzungsschlüssel-Anforderung-Erweiterung
mit einem Untertyp 1 (MF-FA) platzieren, nach der Mobil-Heimat-Authentifizierung-Erweiterung
und vor der Mobil-Fremd-Authentifizierung-Erweiterung
(wenn vorhanden). Der FA muss diese Erweiterung von der Anforderung
entfernen, bevor er die Anforderung an den HA weiter gibt.
-
Der
MT kann die Neue-Sitzungsschlüssel-Anforderung-Erweiterung mit einem
Untertyp 2 (MT-HA) vor der Mobil-Heimat-Authentifizierung-Erweiterung
platzieren.
-
Wie
man aus
4 sieht, gestaltet sich das
Format der Neue-Sitzungsschlüssel-Anforderung-Erweiterung
folgendermaßen:
Typ | Wert
134 (kann ausgelassen werden) |
Länge | Die
Länge dieser
Erweiterung in Bytes ohne die Typen- und Längenfelder. Für die Neue-Sitzungsschlüssel-Anforderung-Erweiterung
beträgt
die Länge
26 Byte. |
Reserviert | Reserviert
für zukünftigen
Gebrauch. Muss auf 0 gesetzt werden. |
Anbieter/Org-ID | Das
hochrangige Oktett ist 0 und die niederrangigen Oktetts sind der
SMI-Netz-Verwaltungsprivatunternehmenskode
eines Anbieters eines Mobilvernetzungsdienstes in der Netzbytereihenfolge. |
Anbietertyp | NEUER_SITZUNGSSCHLÜSSEL_ANFORDERUNG_ANBIETER_
TYP. Dieser Wert zeigt, dass der spezielle Typ dieser Erweiterung
eine Neue-Sitzungsschlüssel-Anforderung-Erweiterung
ist. Die Verwaltung des Anbietertyps wird durch den Anbieter vorgenommen |
Untertyp
1: | MT-FA
Neue-Sitzungsschlüssel-Anforderung-Erweiterung
2:
MT-HA Neue-Sitzungsschlüssel-Anforderung-Erweiterung |
Schlüssellebensdauer | Maximale
Schlüssellebensdauer
in Sekunden, zwei Byte lang |
MT_RAND | eine
Zufallszahl, die durch den MT erzeugt wird (16 Byte oder 8 Byte) |
-
Dies
ist ein Beispiel der Verwendung einer anbieterspezifischen Erweiterung.
Alternativ kann ein anderer Typ einer Mobil-IP spezifizierten Erweiterung
verwendet werden.
-
Das
Format der Neuer-Sitzungsschlüssel-Antwort-Erweiterung
ist in 5 gezeigt. Der FA kann die Neuer-Sitzungsschlüssel-Antwort-Erweiterung
mit dem Untertyp 1 (MT-FA)
in eine Registrierantwort nach der Mobil-Heimat-Authentifizierung-Erweiterung (sofern
vorhanden) einschieben. Der HA kann die Neuer-Sitzungsschlüssel-Antwort
mit dem Untertyp 2 (MT-HA) in eine Registrierantwort vor der Mobil-Heimat-Authentifizierung-Erweiterung
einschieben.
-
Wie
man aus
5 sehen kann, gestaltet sich
das Format der Neuer-Sitzungsschlüssel-Antwort-Erweiterung folgendermaßen:
Typ | Wert
134 (kann ausgelassen werden) |
Länge | Die
Länge dieser
Erweiterung in Byte ohne die Typ- und Längenfelder. Für die Neuer-Sitzungsschlüssel-Antwort-Erweiterung
ist die Länge
42 plus die Länge
der n RANDs. |
Reserviert | Reserviert
für zukünftigen
Gebrauch. Ist auf 0 zu setzen. |
Anbieter/Org–ID | Wert,
beispielsweise 94 (Nokia). Das hochrangige Oktett ist 0 und die
niederrangigen 3 Oktetts sind der SMI-Netzverwaltungsprivatunternehmenskode
des Anbieters in Netzbytereihenfolge. |
Anbietertyp | Dieser
Wert zeigt, dass der spezielle Typ dieser Erweiterung eine Neuer-Sitzungsschlüssel-Antwort-Erweiterung
ist. Die Verwaltung der Anbietertypen erfolgt durch den Anbieter. |
Untertyp | 1:
FA-MT Neuer-Sitzungsschlüssel-Antwort-Erweiterung
2:
HA-MT Neuer-Sitzungsschlüssel-Antwort-Erweiterung |
Schlüssellebensdauer | Verbleibende
Schlüssellebensdauer
in Sekunden |
SIGNrand | Der
Authentikator für
die n RANDs, 16 Byte |
n*RAND | n
GSM RANDs (Länge
n•16 Byte) |
-
Das
Format der SRES-Erweiterung ist in 6 gezeigt.
Der MT kann die SRES-Erweiterung mit Untertyp 1 (MT-FA) in einer
Registrieranforderung nach der Mobil-Heimat-Authentisierung- Erweiterung und
vor der Mobil-Fremd-Authentisierung- Erweiterung (wenn vorhanden) platzieren.
Der FA muss diese Erweiterung entfernen, bevor er die Registrieranforderung
an den HA weiter gibt.
-
Der
MT kann die SRES-Erweiterung mit dem Untertyp 2 (MT-HA) in einer
Registrieranforderung vor der Mobil-Heimat-Authentisierung-Erweiterung platzieren.
-
Wie
man aus
6 sehen kann, gestaltet sich
das Format der SRES-Erweiterun folgendermaßen:
Typ | Wert
134 (kann ausgelassen werden) Die Länge dieser Erweiterung in Byte
ohne die |
Länge | Typ-
und Längenfelder.
Für die
SRES-Erweiterung
ist die Länge
32 Byte. |
Reserviert | Reserviert
für zukünftigen
Gebrauch. Ist auf 0 zu setzen. |
Anbieter/Org-ID | Das
hochrangige Oktett ist 0 und die niederrangigen 3 Oktetts sind der
SMI-Netzverwaltungsprivatunternehmenskode
des Anbieters in Netzbytereihenfolge, wie er in der Zugewiesene-Nummern-RFC
[Zugewiesene Nummern] definiert ist. |
Anbietertyp | Dieser
Wert zeigt, dass der spezielle Typ dieser Erweiterung eine SRES-Erweiterung
ist. Die Verwaltung der Anbietertypen erfolgt durch den Anbieter. |
Untertyp | 1:
MT-FA SRES-Erweiterung
2: MT-HA SRES-Erweiterung |
SIGNsres | Die
durch den MT berechnete Antwort, 16 Byte |
-
In
einer anderen Ausführungsform
der Erfindung werden die Austauschnachrichten für den gemeinsamen Sitzungsschlüssel zwischen
der MT und der FA durch das Erweitern von Agenterkennungsnachrichten, so
dass sie IMSIs und RANDs einschließen, übertragen.
-
In
einer nochmals anderen alternativen Ausführungsform wird ein durchsichtiges
Authentikatorfeld in der Authentifizierungserweiterung verwendet.
Der Beginn dieser Erweiterung wird für das Senden von RANDs, Schlüssellebensdauern
und andere Austauschparameter des gemeinsamen Sitzungsschlüssels verwendet. Die
Schlüsselaustauschparameter
sind in der Berechnung des Authentikators eingeschlossen.
-
Wenn
die Parameter in einer getrennten Erweiterung vor der Authentisierungserweiterung übertragen werden,
werden die Daten für
den Schlüsselaustausch
automatisch in die Berechnung der Authentifizierungserweiterung
eingeschlossen. Weiterhin ergibt die Verwendung getrennter Erweiterungen
eine leichtere Implementierung des Systems. Der Authentikator ist
das Ergebnis der MAC-Funktion, beispielsweise eine SIGNrand, wie
sie gemäß Schritt
2 berechnet wird.
-
In
einer weiteren Ausführungsform
werden statt der Verwendung wohl bekannter SPIs für die vom
SIM erzeugten Sicherheitskontexte SPIs in den Austauschnachrichten
für den
neuen gemeinsamen Sitzungsschlüssel
kommuniziert.
-
Beispiel 2: Drahtloses
LAN
-
7 zeigt
eine Architektur eines Mobilkommunikationssystems gemäß einer
anderen Ausführungsform
der Erfindung. Das System umfasst einen Mobilknoten MT, der ein
Datenendgerät
ist, zwei öffentliche drahtlose
IP-Zugangsnetze (WISPs) WISP1 und WISP2, das Internet INET, ein
erste GSM-Telekommunikationsnetz GSM_A und ein zweites GSM-Telekommunikationsnetz
GSM_B, das mit einem GSM-Kern GSMCORE verbunden ist.
-
Die öffentlichen
drahtlosen IP-Zugangsnetze (WISP1, WISP2) bieten drahtlose Breitband-IP-Dienste, um
es dem MT zu ermöglichen,
in öffentlichen
Hot-Spots zu roamen, wie beispielsweise Hot-Spots, die beispielsweise
in Hotels und Flughäfen
angeordnet sind. Jedes WISP kann entweder durch einen GSM-Telekommunikationsnetzbetreiber
oder durch ein privates ISP mit einer Roamingvereinbarung mit einem
GSM-Telekommunikationsnetzbetreiber
betrieben werden. Die Roamingvereinbarung ist für die SIM-Authentifizierung wesentlich.
-
Der
MT fungiert als ein Mobilknoten. Er kann eine Verbindung mit einem
WISP herstellen. Der MT kann auch von einem Netz zu einem anderen
Netz unter Verwendung bekannter Technik roamen. Im WLAN wird das
Roamen von einem WLAN Hot-Spot zu einem anderen als WLAN-Roamingdienst
bezeichnet. Die WISPs haben Zugang zum Internet INET.
-
Der
MT weist einen Ausrüstungsteil
ME und ein SIM_B auf, die für
die Verwendung mit dem zweiten GSM-Telekommunikationsnetz GSM_B
vorgesehen sind. Es kann sein, dass der MT keine GSM- fähige Mobilstation ist. In diesem
Fall kann ein Benutzer des MT auf das zweite GSM-Telekommunikationsnetz
GSM_B zugreifen, indem er eine GSM-Mobilstation mit dem SIM_B versieht.
In diesem Beispiel ist der MT tatsächlich ein Laptop-Computer,
der mit einer (nicht gezeigten) WLAN-Adapterkarte und einem (nicht
gezeigten) Smart-Karten-Leser, der das SIM_B verwenden kann, ausgerüstet ist.
Alternativ ist der MT eine Vorrichtung, die einen GSM-Mobilstationsteil
für das
Kommunizieren mit GSM-Telekommunikationsnetzen, und einen WLAN-Anschlussteil
für das
Kommunizieren mit WLANs aufweist.
-
Beide
GSM-Telekommunikationsnetze GSM_A und GSM_B umfassen jeweils Mobilvermittlungszentralen
MSC1 und MSC2. Der GSM-Kern
koppelt diese beiden MSCs. Weiterhin weist das erste GSM-Telekommunikationsnetz
ein GSM/GPRS-Authentifizierungs- und
Abrechnungsgateway (GAGW) auf, das es mit dem Internet INET verbindet.
Das GAGW ist die Betreibereinheit des GSM-Telekommunikationsnetzes, die die GSM-Authentifizierungsdienste
für die
WISPs liefert und Abrechnungsinformation sammelt.
-
Das
GSM_B ist mit dem GSMCORE verbunden, und kann weiter durch das GSMCORE
und das GAGW mit dem WISP1 (mit dem der MT verbunden ist) und mit
dem MT für
Authentifizierungs- und Abrechnungszwecke verbunden werden, wie
das später
detaillierter beschrieben wird.
-
Eine
GSM/GPRS SIM basierte Benutzermobilitätsverwaltungsfunktionalität (Benutzerauthentifizierung
und Abrechnung) kann für
Authentifizierungs- und Abrechnungsfunktionen für eine öffentliche WLAN Zugangszone
verwendet werden. Die SIM basierte Authentifizierung liefert eine
relativ vertrauenswürdige
Verifikation der Teilnehmeridentität (Authentifizierung) für eine Abrechnung
der Benutzung. Der GSM-Kern GSMCORE liefert Roamingdienste für eine GSM-Mobilstation, die
sich zwischen verschiedenen Betreibernetzen bewegt. Vorteilhafterweise
wird der Roamingdienst unter Verwendung existierender SIM-Karten
und der GSM-Infrastruktur implementiert. Somit sollte das WISP-Roaming
keine zusätzlichen
Sicherheitsschlüssel vom
MT fordern. Weiterhin benötigen
alle GSM-Benutzer, die WLAN-Roamingdienste von ihrem Heimatbetreiber
erhalten, den MT, das SIM und die notwendige Roamingsoftware, um
Zugang zum öffentlichen
Netz zu bekommen. Ein Heimatbetreiber versieht den ein Roaming durchführenden
MT mit dem SIM_B, um eine Authentifizierung damit durchzuführen. Das
GSM_B ist alternativ ein GSM-Telekommunikationsnetz,
das GPRS unterstützt.
-
Der
Betrieb des Systems der 7 wird nun beschrieben. Der
Benutzer hat eine GSM-Vereinbarung mit dem Betreiber des GSM_B,
das den Heimatnetzbetreiber des Benutzers darstellt. Der Netzbetreiber
B hat eine Roamingvereinbarung mit dem Betreiber des GSM_A unterzeichnet.
Der GSM-Telekommunikationsnetzbetreiber
A hat Partnervereinbarungen mit den Betreibern von WISP1 und WISP2,
die jeweils als Betreiber C und D bezeichnet werden. Der ein Roaming
durchführende
Benutzer mit dem SIM_B kann sich von WISP1 zum WISP2 bewegen. Beide
WISPs senden Authentifizierungsanforderungsnachrichten an den Betreiber
des GSM_A. Die GSM-Kernnetzroamingfunktionalität wird für das Weiterleiten der Authentifizierungsnachrichten an
den Teilnehmerheimatbetreiber (Betreiber des GSM_B) verwendet. Die
Architektur ermöglicht
es Benutzern beider GSM-Telekommunikationsnetze,
sich mit ihren MTs zwischen den WISPs zu bewegen, obwohl die WISPs
nur zum Betreiber A des Netzes GSM_A direkte Verbindung haben.
-
Ein
ein Roaming durchführender
Benutzer muss keine im Vorhinein errichtete Kundenbeziehung mit einem
WISP haben. Stattdessen kann sich der das Roamen durchführende Benutzer
auf seine Kundenbeziehung mit seinem Heimat-GSM-Telekommunikationsnetz verlassen, um
eine Authentifizierung und eine Abrechnung im WLAN zu liefern. Der
WISP-Zugang wird der GSM-Rechnung des das Roaming durchführenden Benutzers über ein
Authentifizierungsgateway des Betreibers des GSM-Telekommunikationsnetzes belastet.
-
Hier
werden diese Roamingdienste verwendet, um es einem MT zu ermöglichen,
unter Verwendung eines SIM sowohl für den Zugang zum GSM-Kern als
auch zu öffentlichen
IP-Zugangsnetzen authentifiziert und belastet zu werden. Der GSM-Telekommunikationsnetzbetreiber
belastet den Benutzer für
die Authentifizierungs/Roamingdienste und für die Verwendung von öffentlichen
IP-Zugangsnetzen. Dann entschädigt
der Betreiber des GSM-Telekommunikationsnetzes die Betreiber der öffentlichen
IP-Zugangsnetze für
die Verwendung der Netze.
-
In
einer alternativen Ausführungsform
der Erfindung kann der Betreiber des GSM-Telekommunikationsnetzes
den Teilnehmer mit einem WISP-Roaming-SIM versehen, das die Verwendung
von GSM-Funkdiensten
nicht erlaubt. Ein solches zugewiesenes SIM kann verwendet werden,
um Dienste, die durch ein WLAN geliefert werden, zu authentifizieren
und abzurechnen.
-
Wie
aus dem GSM bekannt ist, speichert das Heimat-GSM-Netz Kundeninformation,
wie Authentifizierungskodes und die Benutzerkennung. Typischerweise
wird diese Information in einem GSM-Heimatregister (HLR) einer MSC
gespeichert. Der Betreiber des GSM-Telekommunikationsnetzes liefert
die auf dem IP basierende Authentifizierungs- und Abrechnungsschnittstelle
für einen
oder mehrere WISP-Betreiber,
möglicherweise
auch oder nur für
Firmenzugangslösungen.
-
Das
GAGW unterstützt
ein nahtloses Roaming zwischen den Betreibern verschiedener GSM-Telekommunikationsnetze.
Die WISPs senden alle Authentifizierungs- und Abrechnungsinformation
an das GAGW. Das GAGW verwendet die GSM-Kernsignalisierung, die
vom GSM bekannt ist, um die Authentifizierungs- und Abrechnungsinformation
zum entsprechenden GSM-Telekommunikationsnetzbetreiber zu befördern. Die
Signallisierung der Abrechnungsinformation zwischen verschiedenen
GSM-Telekommunikationsnetzen kann in einer ähnlichen Weise wie bei einem
konventionellen Roaming eines Mobiltelefons in einem fremden GSM-Telekommunikationsnetz
ausgebildet werden. In diesem Fall belastet das fremde GSM-Telekommunikationsnetz
den Heimat-GSM-Telekommunikationsdienst
für seinen
Dienst beim Arrangieren des Telefongesprächs.
-
Im
System der 7 speichert der Heimatbetreiber
die Abrechnungsaufzeichnungen und sendet die Rechnung an den Benutzer.
Das WISP erzeugt eine Abrechnungsaufzeichnung, die die abgerechneten
Dienste beschreibt. Die Abrechnung kann auf irgend bekannten Prinzipien
oder Kombinationen dieser basieren, beispielsweise auf einer Flatrate,
einer Nutzungszeit, der Anzahl der Pakete oder der Zugangsbandbreite.
Das GSM-Netz (GAGW) überträgt die vom
WISP ausgehenden Aufzeichnungen an das existierende GSM-Abrechnungssystem.
-
Der
MT unterstützt
die Authentifizierung durch die Verwendung einer SIM-Karte. In einer
alternativen Ausführungsform
unterstützt
der MT einen oder mehrere Authentifizierungsmechanismen beispielsweise
eine Smartkartenauthentifizierung für ein Firmennetzzugang. Ein
solcher MT enthält
Authentifizierungssoftware und die Smartkarte, aber er braucht keine
Schlüssel
für einen öffentlichen
Zugang oder irgend einen anderen Sicherheitsverband (security association)
haben.
-
8 zeigt
signifikante Funktionsblöcke
des Systems der 7. 8 zeigt
nur ein einziges WISP, obwohl es verständlich ist, dass mehr als ein
WISP und mehr als ein GSM-Telekommunikationsnetz vorhanden sein
können. 8 zeigt
drei wichtige funktionelle Elemente des Systems: den MT, eine öffentliche
Zugangssteuerung PAC und das GPRS/GSM-Authentifizierungs- und Abrechnungsgateway
GAGW. Das GAGW ist eine zugewiesene Einheit des GSM-Telekommunikationsnetzes,
das eine Schnittstelle zwischen dem GSM/GPRS-Netz und einem IP-Netz
(beispielsweise dem Internet oder einem Weitbereichs-IP-Netz) herstellt. Das
GAGW bietet auch die notwendigen WLAN-Zell-Roamingfunktionen, insbesondere
solche die in Bezug zu Authentifizierungs- und Abrechnungsdiensten
stehen.
-
Die
PAC ist die Einheit des WISP-Netzes, die den Zugang vom Funkzugangsnetz
zu Internetdiensten steuert. In diesem Beispiel weist die PAC eine
IP-Rdresse dem MT zu und authentifiziert den MT, bevor die Verbindung
zum Internet errichtet ist. Die PAC befördert die Authentifizierungsnachrichten
zwischen dem MT und dem GAGW, sammelt die Abrechnungsaufzeichnungen
und sendet sie an das GAGW. Die PAC leitet auch den Benutzerdatenverkehr
zwischen dem MT und dem Internet.
-
Die
SIM-Authentifizierung ist ein komplementärer Dienst für die PAC
und die PAC unterstützt
zusätzlich
andere Authentifizierungsmechanismen, wie eine auf einem Passwort
basierende Authentifizierung.
-
Es
werden nun die Schnittstellen des Systems beschrieben.
-
Die
MT-PAC-Schnittstelle ist eine auf dem IP basierende Schnittstelle,
die mit der Authentifizierungsfunktionalität versehen ist. Die Authentifizierung
ist so gestaltet, dass sie in ein wohl bekanntes Standard-IP-Protokoll
eingebettet oder als eine Erweiterung zum existierenden Protokoll
implementiert werden kann. Der MT und die PAC werden unter Verwendung
ihrer IP-Adressen in dieser Schnittstelle identifiziert.
-
Die
PAC-GAGW-Schnittstelle ist eine auf dem IP basierende Schnittstelle,
die ein geeignetes Authentifizierungsprotokoll verwendet. Typischerweise
unterstützt
ein einzelnes GAGW mehrere PACs gleichzeitig. Das GAGW identifiziert
verschiedene PACs unter Verwendung ihrer IP-Adressen. In dieser
Schnittstelle basiert die MT-Kennung auf einem IMSI-Kode, der auf dem
SIM_B gespeichert ist.
-
Die
GAGW-HLR-Schnittstelle ist Implementierungs- und Anbieter-spezifisch.
Das GAGW verbirgt die zellulare Infrastruktur gegenüber den
PACs. Somit ist die PAC-GAGW-Schnittstelle
immer dieselbe, obwohl das darunter liegende zellulare Netz von
verschiedenem Typ (GSM, GPRS) sein kann oder durch einen anderen
Anbieter geliefert wird.
-
9 zeigt
die Hauptsignalisierungsschritte des Systems der 7 und 8.
Das Verfahren der Authentifizierung des MT gegenüber der PAC wird typischerweise
ausgelöst,
wenn der MT versucht eine Verbindung zu dem Netz mit öffentlichen
Zugang aufzubauen. In diesem Fall erwirbt der MT eine IP-Adresse über einen
(nicht gezeigten) Server mit dynamischem Hostkonfigurationsprotokoll
(DHCP). Das DHCP-Protokoll und passende Server sind aus dem Stand
der Technik wohl bekannt. Die Authentifizierung muss abgeschlossen
werden, bevor auf das Netz jenseits der PAC zugegriffen werden kann.
Der MT löst
die Authentifizierung durch Roaming-Software aus. In einer alternativen
Ausführungsform
wird die Authentifizierung automatisch ausgelöst, wenn der MT unter Verwendung
der SIM-Authentifizierung
versucht, Zugang zum Netz zu erlangen, und die Roaming-Anwendung
läuft.
-
Ein Überblick
der Authentifizierung wird als nächstes
unter Bezug auf die Nachrichten, die während des Authentifizierungsverfahrens
verwendet werden, erläutert:
301:
Der MT kommuniziert mit der PAC, um eine Verbindung mit dem WISP1
herzustellen und um eine IP-Adresse von einem DCHP-Server zu erhalten.
302:
Die PAC sendet Information, die die unterstützten Authentifizierungsmechanismen,
wie eine SIM-Authentifizierung,
eine Infrastruktur mit öffentlichem
Schlüssel
(PKI) oder einen im Vorhinein gemeinsam genutzten (pre-shared) Schlüssel, betrifft.
303:
Der MT erkennt, dass die SIM-Authentifizierung unterstützt wird.
Der ME fordert die IMSI vom SIM_B an.
304: Das SIM_B
antwortet auf die IMSI-Anforderung 303 durch das Senden
der IMSI an den ME.
305: Der MT bildet eine Netzzugangskennung,
das ist die IMSI, in einem Netzzugangskennungs-(NAI)-Format, wie
es am Beginn der Beschreibung des Beispiels 1 erläutert ist.
Der MT errichtet eine dynamische Sicherheitsverbindung mit der PAC,
beispielsweise unter Verwendung von Diffie-Hellman, und sendet die
NAI verschlüsselt über den
temporär
sicheren Kanal. In einer alternativen Ausführungsform wird die NAI als
Klartext ohne Verschlüsselung
gesendet.
306: Die PAC entschlüsselt die NAI und gibt sie
in einem Datenpaket, wieder verschlüsselt, über die sichere PAC-GAGW-Schnittstelle an
das GAGW. Die IP-Adresse des GAGW ist in der PAC statisch konfiguriert.
Ein sicherer Kanal wird zwischen der PAC und dem GAGW unter Verwendung
ihres vorher arrangierten gemeinsamen Geheimnisses ausgebildet.
307:
Das GAGW verifiziert, dass das Datenpaket von einer gültigen PAC
kommt, entschlüsselt
das Paket, prüft die
NAI, extrahiert die IMSI und sendet die IMSI mit einer Authentifizierungsanforderung
an die nächste
MSC. Als nächstes
analysiert die MSC die IMSI, um das Heimat-HLR des Teilnehmers,
der durch die IMSI bezeichnet wird, heraus zu finden. Dann gibt
die MSC die Authentifizierungsanforderung an das Heimat-HLR.
308:
Das Heimat-HLR bildet einen Satz eines oder mehrerer GSM-Authentifizierungstripletts
(RAND, SRES, Kc) und sendet den Satz an die Ursprungs-MSC, die den
Satz an das GAGW weiter gibt.
309: Das GAGW bildet
ein Packet, das die RANDs und eine kryptographische Prüfsumme der
RANDs, die unter Verwendung von mindestens der Kcs erzeugt wird,
enthält.
Das GAGW bewahrt die SRESs für
eine spätere Verwendung
in einem nachfolgenden Schritt 314.
310:
Die PAC entschlüsselt
das Paket und leitet die RANDs und die kryptographische Prüfsumme an
den MT.
311: Der MT gibt die RANDs an das SIM_B, das
den entsprechenden Kc und die SRES-Werte berechnet.
312:
Der MT prüft,
ob die Kcs zur kryptographischen Prüfsumme, die durch die PAC gegeben
wird, passen. Wenn sie passen, weiß der MT, dass die PAC eine
Verbindung zum HLR hat und man so der PAC trauen kann.
313:
Der MT erzeugt eine kryptographische Prüfsumme für die SRESs mit den Kcs und
sendet die Prüfsumme an
die PAC.
314: Die PAC leitet die Prüfsumme der
SRES an das GAGW. Das GAGW prüft,
ob die Prüfsumme
zu den SRESs passt, die es von der MSC im Schritt 308 erhalten
hat. Wenn sie passt, so sendet das GAGW eine Bestätigungsnachricht
Ack an die PAC. Wenn sie nicht passt, so sendet das GAGW eine negative
Bestätigung NACK
an die PAC.
315: Wenn die PAC eine positive Bestätigungsnachricht
ACK empfängt,
die eine erfolgreiche Authentifizierung versichert, so vollendet
sie die Authentifizierung durch das Öffnen des Zugangs zum Internet.
Wenn die PAC eine negative Bestätigungsnachricht
NACK empfängt,
so weigert sie sich, den Zugang zum Internet zu öffnen.
-
In
einer alternativen Ausführungsform
wird die IMSI in den vorhergehenden Schritten statt der NAI verwendet.
-
Die
folgenden Tabellen listen die Parameter auf, die zwischen den Elementen
des Systems befördert werden:
-
Tabelle
1: Hauptparameter die zwischen dem MT und dem GAGW befördert werden
-
Tabelle
2: Hauptparameter, die zwischen dem MT und der PAC befördert werden
-
Tabelle
3: Hauptparameter, die zwischen der PAC und dem GAGW befördert werden
-
Vorteilhafterweise
wird ein optionaler user_class Parameter verwendet, um die Qualität des Dienstes, beispielsweise
die maximale Bandbreite für
einen speziellen Benutzer, zu definieren.
-
10 zeigt
ein detailliertes Signalisierdiagramm einer Authentifizierung des
Systems der 7 und 8. Das Diagramm
zeigt die folgenden Schritte:
(Schritt 401) Der MT
sendet eine vom MT ausgehende Authentifizierungsstartanforderung MT_PAC_AUTHSTART_REQ,
die die NAI, die die IMSI aufweist, enthält. Die Anforderung enthält typischerweise
auch einen Schutzkode MT_RAND (der als Nonce im Kontext des Mobil-IP
bekannt ist).
(Schritt 402) Die PAC empfängt die
MT_PAC_AUTHSTART_REQ vom MT und fordert die GSM-Tripletts an, indem
sie an das GAGW eine Nachricht PAC_GAGW_AUTHSTART_REQ sendet, die
auch die NAI und die MT_RAND enthält.
(Schritt 403)
Das GAGW erhält
die GSM-Tripletts vom Heimat-GSM-Telekommunikationsnetz.
Ein Triplett genügt,
aber es kann sein, dass das GSM-Telekommunikationsnetz eine Vielzahl
von Tripletts zurück
gibt, wobei in diesem Fall entweder einige der Tripletts verworfen
oder für
eine spätere
Verwendung gespeichert werden, oder sie noch besser alle verwendet
werden, um einen stärkeren
Schlüssel
zu erzeugen. Das Heimat-GSM-Telekommunikationsnetz
wird unter Verwendung der NAI erkannt.
(Schritt 404)
Das GAGW erzeugt den K unter Verwendung eines Verschlüsselungsalgorithmus
aus mindestens dem oder den GSM-Sitzungsschlüssel(n)
Kc. Vorteilhafterweise wird auch die MT_RAND bei der Verschlüsselung
verwendet. Das GAGW verschlüsselt
die GSM RAND(s) der GSM-Tripletts, berechnet eine kryptographische
Prüfsumme
oder einen Nachrichtenauthentifizierungskode MAC auf der Basis der
RAND(s) und des K und bereitet eine Authentifizierungsstartantwortnachricht
GAGW_PAC_AUTHSTART_RESP. Die Verschlüsselung zwischen dem GAGW und
der PAC basiert auf ihrem eigenen gemeinsamen Geheimnis.
(Schritt 411)
Das GAGW sendet an die PAC eine Authentifizierungsstartantwortnachricht GAGW_PAC_AUTHSTART_RESP,
die die RANDs, den MAC, die MT_RAND, einen Rechnungsinformationskode
und einen Rechnungsinformations-MAC, der für den Rechnungsinformationskode
berechnet wurde, enthält.
Typischerweise enthält
die Authentifizierungsstartantwortnachricht zusätzlich ein Feld für einen
Sitzungszeitablaufparameter für
das Bestimmen der gültigen
Zeitdauer des neuen K, der zu erzeugen ist, und ein Feld für den Zustand
der Sitzung.
(Schritt 412) Die PAC gibt an den MT
die Authentifikationsstartantwortnachricht GAGW_PAC_AUTHSTART_RESP
als eine Nachricht PAC_MT_AUTHSTART_RESP.
(Schritt 413)
Der MT prüft
mit der SIGNrand, ob die Parameter, die von der GAGW_PAC_AUTHSTART_RESP und
der PAC_MT_AUTHSTART_RESP befördert
werden, tatsächlich
vom GSM-Telekommunikationsnetz stammen.
(Schritt 414)
Der MT handhabt die Abrechnungsinformation, die er vom GAGW erhalten
hat. Typischerweise liefert er dem Benutzer Information in Bezug
auf den Preis des Dienstes, der vom Benutzer angefordert wird. Gewöhnlicherweise
basiert dieser Preis mindestens auf Folgendem: einer Flat-Rate-Gebühr, einer
auf der Zeit basierenden Abrechnung, der Anzahl der Datenpakete,
die zum oder vom MT gesendet wurden, und der Qualität des Dienstes
QoS. Der MT fragt dann den Benutzer, ob der Dienst mit dem gegebenen
Preis erhalten werden soll. Der MT empfängt eine Antwort vom Benutzer.
(Schritt 415)
Der MT erzeugt einen MAC der SRESs, der für das Antworten an das GAGW
verwendet werden soll.
(Schritt 416) Der MT erzeugt
dann ein Zugangsgeheimnis Kpac_MT unter Verwendung von mindestens
der Kcs.
(Schritt 421) Der MT erzeugt und sendet eine
Nachricht MT_PAC_AUTHANSWER_REQ an die PAC. Die Nachricht enthält im Zustandsfeld
eine Antwort des Benutzer, die zeigt, ob der Benutzer die Bezahlung
für den Dienst
akzeptiert, den MAC der SRESs, einen MAC des Abrechnungskodes und
die MT_RAND (als alle Nachrichten, die während einer Authentifizierungssitzung
gesendet werden).
(Schritt 422) Die PAC erzeugt eine
PAC_GAGW_AUTHANSWER_REQ, die die Daten der Nachricht MT_PAC_AUTHANSWER_REQ
und zusätzlich
die NAI und die IP-Adresse der PAC enthält.
(Schritt 423)
Das GAGW testet den MAC der SRESs, um zu verifizieren, dass bei
den Daten, die vom MT gesendet werden, die von der PAC_GAGW_AUTHANSWER_REQ
befördert
werden, keine unerlaubten Eingriffe vorgenommen wurden.
(Schritt 424)
Wenn das GAGW eine positive Antwort auf den Test im vorigen Schritt
bekommt, erzeugt es den Zugangsschlüssel Kpac_MT in einer ähnlichen
Weise wie der MT im Schritt 416 und geht dann zum Schritt 431 weiter.
(Schritt 431)
Das GAGW sendet an die PAC eine Nachricht GAGW_PAC_AUTHANSWER_RESP_OK.
Die Nachricht enthält
die MT_RAND und die Kodes filter_id, Kpac_MT und SIGNresult. Der
Kode filter_id ist optional und zeigt die Benutzerklasse des Teilnehmers
an. Dies kann bei der Definition einer QoS verwendet werden, beispielsweise
eine Verbindung mit hoher Qualität
für mehr
bezahlende Geschäftskunden.
Der SIGNresult ist ein MAC der Daten in der Nachricht, um dem MT
schließlich
zu verifizieren, dass die Antwort vom GAGW auf dem Weg zum MT nicht
geändert
wurde.
(Schritt 441) Die PAC antwortet dem GAGW durch
eine Nachricht PAC_GAGW_STARTBILLING_REQ, die das GAGW auffordert,
die Abrechnung zu starten. Die Nachricht enthält die NAI und eine Sitzungs-ID
(die MT_RAND).
(Schritt 442) Das GAGW prüft die Antwort
vom MT, um zu verifizieren, dass der MT die Abrechnung gestattet hat.
(Schritt 451)
Wenn der MT die Abrechnung gestattet hat, sendet das GAGW an die
PAC eine Nachricht GAGW_PAC-STARTBILLING_RESP_OK
um den Start der Abrechnung anzuzeigen.
(Schritt 452)
Die PAC sendet an den MT die Nachricht PAC_MT_AUTHANSWER_RESP_OK,
die SIGNresult enthält.
(Schritt 453)
Die MT empfängt
die Nachricht PAC_MT_AUTHANSWER_RESP_OK und prüft das SIGNresult, das sie
enthält.
Wenn das SIGNresult korrekt ist, kann der MT den Benutzer über den
Start der Abrechnung informieren.
-
Der
MAC des Abrechnungskodes wird berechnet, wobei mindestens die Kcs
verwendet werden, so dass die PAC keinen unerlaubten Eingriff beim
Abrechnungskode vornehmen kann.
-
In
der Nachricht PAC_MT_AUTHANSWER_RESP_OK wird der MT über die
Laufzeit der Authentifizierung benachrichtigt. Der MT führt eine
erneute Authentifizierung seiner selbst durch, bevor die Laufzeit
der Authentifizierung abläuft.
Wenn er keine erneute Authentifizierung durchführt, so wird die Verbindung
des MT zur PAC aufgehoben, und der MT kann sich selbst erneut authentifizieren.
-
Vorteilhafterweise
erhält
der MT Abrechnungsinformation und entscheidet, wie er sie handhaben
will. Vorteilhafterweise kann der Benutzer des MT eine Handhabungsweise
der Abrechnungsinformation definieren. Diese Handhabungsweise kann
verwendet werden, um beispielsweise zu definieren, dass dem Benutzer keine
Abrechnungsinformation präsentiert
wird im Falle einer erneuten Authentifizierung oder einer normalen Authentifizierung.
Das Handhaben der Abrechnungsinformation beeinflusst nicht das Protokoll
der Benachrichtigung zwischen den verschiedenen Einheiten (MT, PAC,
GAGW, MSC und HLR).
-
Die 11a und 11b bilden
zusammen ein Flussdiagramm, das die Funktionalität der PAC während der Authentifizierung
zeigt. In dieser Figur gehören
alle Blöcke
zur PAC mit Ausnahme derjenigen, die als „MT" oder „GAGW" markiert sind. Die Zeichnung wird beschrieben,
indem auf jeden der Blöcke
durch sein Bezugszeichen Bezug genommen wird.
-
Die
Operation startet vom Block 501. Der MT fordert eine Authentifizierung
von der PAC durch das Senden einer Nachricht MT_PAC_AUTHSTART_REQ,
die die MT_RAND und die NAI enthält,
an die PAC, um somit dort das Authentifizierungsverfahren auszulösen (Block 511).
Die PAC bildet (Block 512) eine IP-Adresse MT_IP für den MT
ab. Die PAC prüft
zuerst, ob sie schon eine IP-Adresse empfangen hat, die für diese
NAI abgebildet wurde. Wenn sie das hat, so gewinnt sie die Abbildung
aus einer Datenbankaufzeichnung (Block 513). Ansonsten
erhält
sie eine IP-Adresse und speichert sie mit der NAI in einer Datenbank
für eine
zukünftige Verwendung.
-
Nach
dem Abbilden (Block 512) der IMSI mit einer IP-Adresse
leitet die PAC (Block 514) die NAI an das GAGW (Block 541)
in einer Nachricht PAC_GAGW_AUTHSTART_REQ. Das GAGW antwortet (Block 542)
durch eine Nachricht GAGW_PAC_AUTHSTART_RESP, die eine Zufallszahl
RAND, die als eine Challenge zu verwenden ist, enthält. Im Block 515 empfängt die
PAC die Challenge und bildet einen Sitzungs-ID-Kode auf dem MT_IP
ab. Als nächstes
aktualisiert die PAC die Datenbankaufzeichnung (Block 516) durch
das Speichern der SESSION_ID mit dem MT_IP und der IMSI. Dann sendet
die PAC (Block 517) die Challenge RAND an den MT in einer
Nachricht PAC_MT_AUTHSTART_RESP. Der MT empfängt (Block 502) die
Nachricht, erzeugt eine Nachricht und antwortet mit dieser Nachricht
MT_PAC_AUTHANSWER_REQ, die eine kryptographische Prüfsumme SIGN_RES,
die der Challenge entspricht, und die Challenge selbst enthält. Die
PAC empfängt
die SIGN_SRES und leitet sie (Block 518) an das GAGW weiter,
das prüft
(Block 543), ob sie korrekt ist. Das GAGW gibt an die PAC
(Block 544) eine Nachricht GAGW_PAC_AUTHANSWER_RESP zurück, um die
PAC zu informieren, ob die SIGN_SRES korrekt ist. Alternativ kann
das GAGW die korrekte SIGN_SRES berechnen und sie an die PAC zurück geben,
so dass die PAC selbst verifiziert, ob die vom MT erzeugte SIGN_SRES
korrekt ist. In jedem Fall verifiziert (Block 519) die
PAC die Antwort vom GAGW und entscheidet (Block 520) die
nächste
Aktionen auf der Basis der Antwort. Wenn die Antwort positiv ist,
das bedeutet eine erfolgreiche Authentifizierung, dann geht die
PAC zum Block 523 weiter, um die Abrechnung zu starten.
Ansonsten geht die Ausführung
zum Block 521 weiter. Dort wird ein NACK als eine PAC_MT_AUTH_ANSWER_RESP_ERR
an den MT gesandt, um einen Fehler in der Authentifizierung anzuzeigen,
und die SESSION_ID wird aus der Aufzeichnung, in der sie gespeichert
wurde, entfernt (Block 522).
-
Als
nächstes
werden die Schritte, die sich auf die Abrechnung beziehen, erläutert. Im
Block 523 wird eine Nachricht PAC_GAGW_STARTBILLING_REQ
an das GAGW gesandt. Die Nachricht informiert das GAGW über die
Möglichkeit,
Belastungen auf dem Konto der Benutzers des MT, die einer GSM-Rechnung
hinzugefügt
werden sollen, vorzunehmen. Das GAGW empfängt (Block 547) diese
Nachricht und antwortet mit einer Nachricht GAGW_PRAC_STARTBILLING_RESP
als Bestätigung.
Die Nachricht wird durch die PAC verifiziert (Block 524),
und im Fall einer Ablehnung statt einer Bestätigung kehrt die PAC zum Block 521 zurück. Ansonsten
(Block 526) wird eine Bestätigungsnachricht PAC_MT_AUTHSTART_RESP_OK
an den MT gesandt, um den Start der möglichen Abrechnung zu bestätigen, und
es wird ein Zeitgeber gestartet.
-
In
der nächste
Phase bleibt die PAC im Leerlauf und liefert periodische Abrechnungsaktualisierungen. Diese
Aktualisierungen werden durch belastende Ereignisse, wie ein Senden
oder Empfangen von Datenpaketen, ausgelöst. Die PAC kann diese Belastungen
kombinieren und nur nach einer gewissen Zeitdauer oder nach dem
Erreichen einer gewissen Auslösemenge
der Belastung eine Abrechnungsaktualisierung durchführen, die
der so gesammelten Pauschalsumme entspricht. Wenn ein Ereignis abgerechnet
wird, sendet die PAC eine PAC_GAGW_UPDATEBILLING_REQ, um das GAGW über die
Abrechnungsaktualisierung zu benachrichtigen. Das GAGW empfängt (Block 547)
diese Nachricht und antwortet (Block 548) durch eine Empfangsnachricht
GAGW_PAC_UPDATEBILLING_RESP. Die PAC empfängt (Block 528) die
Empfangsquittung und prüft
(Block 529), ob sie positiv ist. Wenn die Empfangsquittung
negativ ist, verhindert die PAC (Block 532), dass der MT
Datenpakete zum und vom WISP überträgt, sendet
einen Abrechnungsstop an das GAGW und sendet (Block 533)
eine Authentifizierungsanforderung an den MT für dessen erneute Authentifizierung.
Wenn andererseits die Empfangsquittung im Block 529 positiv
ist, prüft
die PAC (Block 530) den Zeitgeber, um einen Zeitablauf
der Sitzung zu erkennen. Wenn ein Zeitablauf erkannt wird, so geht
die PAC zum Block 532 weiter und macht weiter, wie das
oben beschrieben wurde. Wenn kein Zeitablauf erkannt wird, so kehrt
die PAC-Operation zum Block 527 zurück.
-
Die 12a bis 12d bilden
zusammen ein Flussdiagramm, das die Funktionalität des GSM/GPRS Authentifizierungs-
und Abrechnungsgateways (GSM/GPRS Authentication and billing Gateway, GAGW)
während
der Authentifizierung im System der 7 zeigt.
Das Flussdiagramm, das in den 11a und 11b gezeigt ist, zeigte die Funktionalität der PAC,
und hier wird dieselbe Prozedur aus der Sicht des GAGW betrachtet.
Die Prozedur startet vom Block 601. Die PAC sendet an das
GAGW die Nachricht PAC_GAGW_AUTHSTART_REQ, die die IMSI und den
Domainnamen der MT (definiert durch das SIM_B) enthält. Das
GAGW prüft
(Block 611), ob der MT schon authentifiziert ist. Wenn
ja, so wird ein Authentifizierungsgültigkeitszeitgeber (der später beschrieben
wird) gestoppt (Block 613) und es wird existierende Benutzerinformation
verwendet (Block 615). Ansonsten wird eine temporäre Benutzer-ID
dem MT, der durch die IMSI identifiziert wird, zugewiesen, und die
Teilnehmerdaten (IMSI und entsprechende Benutzer-ID) werden in einem
Datensatz der Datenbank gespeichert.
-
Dann
wird die MT-Authentifizierung gestartet (Block 621). Das
GAGW fordert (Block 623) die GSM-Tripletts vom Heimat-GSM-Telekommunikationsnetz
des Teilnehmers durch eine Nachricht GAGW_MSC_DATA_REQ, die an die
dichteste MSC gesendet wird, an (Block 681). Der MS antwortet
(Block 682) durch eine Nachricht MSC_GAGW_DATA_RESP, die
ein oder mehrere GSM-Tripletts
und zusätzliche
Information, die angibt, ob die MSC eine Abrechnung für die Benutzung
der PAC durch diesen Benutzer gestattet, enthält. Das GAGW verifiziert diese
Antwort (Block 627). Wenn der Benutzer für den Abrechnungsdienst nicht
autorisiert ist, oder wenn alternativ der Antwortzeitgeber abläuft (Block 625),
so sendet das GAGW (Block 629) eine Autorisierungsfehlernachricht
GAGW_PAC_AUTHSTART_RESP_ERROR an die PAC (Block 602). Ansonsten
ist der Zeitgeber nicht abgelaufen, und die Verifikation der Antwort
ist positiv, und das Verfahren setzt sich vom Block 633 fort.
Das GAGW erhält
aus der Datenbank (Block 635) die MT_RAND und mindestens
ein GSM-Triplett, das mit dem Teilnehmer verbunden ist, der authentifiziert
wurde. Dann berechnet das GAGW eine SIGNrand unter Verwendung einer
Hashfunktion, und der Kc und die RAND des GSM-Tripletts oder jedes
GSM-Tripletts werden verwendet. Diese gewisse Anzahl von KCs werden
durch n*Kc bezeichnet. Hier bezieht sich der Stern nicht auf eine
Multiplikation sondern auf die Anzahl der Parameter Kc unterschiedlicher
Werte. Dasselbe gilt für
alle anderen Vorkommen von Sternen. Für die Multiplikation wird ein „•" statt eines Sterns
verwendet. Da die MSC typischerweise ein bis vier unterschiedliche
GSM-Tripletts in Erwiderung auf eine Anforderung liefert, können ein
oder mehrere Tripletts für
die Authentifizierung verwendet werden. Durch das Verwenden von
zwei oder mehr Tripletts statt nur einem wird eine verbesserte Sicherheit
erhalten, da die Schlüssel
länger
sind, und da die Wiederholzeitdauer, nach der derselbe Schlüssel wieder
verwendet wird, zunimmt. Dies ermöglicht weiter eine Erhöhung der
Gültigkeitszeitdauer
der ausgebildeten Authentifizierungsschlüssel.
-
Im
Block 637 sendet das GAGW eine Challenge und seine SIGNrand
in einer Nachricht GAGW_PAC_AUTHSTART_RESP an die PAC (Block 603).
Die PAC antwortet mit einer Nachricht PAC_GAGW_AUTHANSWER_REQ, um
anzuzeigen, ob der Benutzer gewillt ist, die Abrechnung zu akzeptieren.
Das GAGW prüft
(Block 641) die Nachricht, und wenn sie zeigt, dass der
Benutzer die Abrechnung nicht akzeptiert, so speichert das GAGW
(Block 643) die Antwort für statistische Zwecke (Block 639)
und sendet eine Nachricht GAGW_PAC_AUTHANSWER_RESP an die PAC, um
der PAC zu bestätigen,
dass die Authentifizierung abgebrochen werden soll. Die statistische
Zwecke umfassen das Sammeln von Information, wie viele Benutzer
die Abrechnung akzeptiert haben und wie viele dies nicht getan haben.
Diese Information kann für die
Optimierung des Preises für
die Verbindung verwendet werden, um den Profit der Betreiber des WISP
und der Betreiber des GSM-Telekommunikationsnetzes zu maximieren.
-
Wenn
die Nachricht PAC_GAGW_AUTHANSWER_REQ anzeigt, dass der Benutzer
gewillt ist, die Abrechnung zu akzeptieren, prüft das GAGW (Block 645)
die SIGNsres. Diese Prüfung
wird ausgeführt
durch das Berechnen der SIGNres unter Verwendung der Hashfunktion,
die dem MT bekannt ist, und unter Verwendung derselben Eingabedaten
(MT_RAND, Kc und RAND jeder der verwendeten GSM-Tripletts). Für die Prüfung erhält das GAGW
(Block 647) die Eingabedaten von der Datenbank. Als nächsten Schritt
(Block 649) prüft
das GAGW, ob die SIGNsres tatsächlich
korrekt war.
-
Wenn
die SIGNsres inkorrekt war, sendet (Block 653) das GAGW
eine Zurückweisungsnachricht GAGW_PAC_AUTHANSWER_RESP_ERR
an die PAC (Block 606).
-
Wenn
die SIGNsres korrekt war, gewährt
das GAGW dem MT Zugang und erzeugt (Block 651) das Kpac_MT.
Dann sendet (Block 655) das GAGW die Zugangsbestätigung durch
eine Nachricht GAGW_PAC_AUTHANSWER_RESP_OK an die PAC (Block 607).
Weiterhin erzeugt das GAGW (Block 657) ein PAC-spezifische
Authentifizierungsticket und speichert es (Block 663).
Dann aktualisiert (Block 659) das GAGW die Benutzerinformation
in der Datenbank und speichert (Block 655) die Benutzerdaten,
die das Kpac_MT umfassen. Schließlich startet (Block 661)
das GAGW den Authentifizierungsgültigkeitszeitgeber
(der auch in Bezug auf Block 613 erwähnt wurde) und startet (Block 667)
ein Abrechnungsverfahren. Der Authentifizierungsgültigkeitszeitgeber
wird vorzugsweise durch das Speichern der Ablaufzeit der Authentifizierung
in der Datenbank implementiert. Dies ermöglicht die Verwendung der allgemeinen
Hardware (Takt) für
eine Vielzahl von verschiedenen Benutzern und ein leichtes Prüfen des
Ablaufens der Authentifizierung durch das Vergleichen der aktuellen
Zeit mit der Ablaufzeit.
-
Ein
Zugang zum WISP durch den MT wird dem GSM-Konto des Benutzers belastet.
Wenn der MT gegenüber
dem WISP authentifiziert ist, startet die PAC das Sammeln von Abrechnungsinformation.
Die PAC führt
eine Datenbank der Verbindungszeit und der Menge der gesendeten
Daten. Wenn der MT die Verbindung löst, so leitet die PAC diese
Information an das GAGW weiter. Das GAGW erzeugt dann ein GSM-Rufdetailaufzeichnungsticket
(Call Detailed Record, CDR) und leitet es an das GSM-Abrechnungssystem,
das vom GSM bekannt ist, weiter.
-
13 zeigt
die Hauptsignalisierungsschritte eines gesteuerten Lösen der
Verbindung der MT vom Netz. Das Löseverfahren startet, wenn der
MT wählt,
dass er seine Verbindung lösen
will (Block 711). Der MT sendet (Block 713) eine
Nachricht MT_PAC_DISCONNECT_REQ an die PAC. Die PAC sendet (Block 721) eine
Nachricht PAC_GAGW_STOPBILLING_REQ, die das GAGW auffordert, die
Abrechnung zu stoppen. Das GAGW antwortet durch das Senden (Block 731)
einer PAC_GAGW_STOPBILLING_RESP an die PAC. Schließlich sendet
die PAC eine Nachricht PAC_MT_DISCONNECT_RESP, um dem MT ein erfolgreiches
Lösen der
Verbindung zu bestätigen.
-
Im
Beispiel 2 ist die Funktionalität
für die
Authentifikatoreinheit, die für
die Authentifizierung eines Endgeräts verantwortlich ist, in einem
Netzschichtrouter angeordnet. Alternativ ist die Funktionalität ein Verbindungsschichtelement,
wie ein WLAN-Zugangspunkt, wobei in diesem Fall die Schnittstelle
zwischen dem MT und dem WLRN-Zugangspunkt auf einem Verbindungsschichtprotokoll
statt dem IP basiert.
-
Beispiel 3
-
Die
funktionelle Architektur der vorliegenden Erfindung kann unter Verwendung
verschiedener geeigneter Protokolle implementiert werden. In diesem
Beispiel wird jedoch eine erweiterte Version eines Internet-Schlüssel-Austausch-Protokolls (Internet
Key Exchange, IKE, RFC 2409) bei Kommunikationen zwischen dem MT
und der PAC verwendet. Ein Fern-Authentisierungs-Einwahl-Nutzer-Dienst-Protokoll
(Remote Authentication Dial In User Service, RADIUS, RFC 2138, RFC
2139) wird für
Kommunikationen zwischen der PAC und dem GAGW verwendet. Es sollte
auch bemerkt werden, dass die PAC-Funktionalität innerhalb eines Zugangspunktservers
integriert sein könnte,
wenn das notwendig sein sollte. Durch das Trennen der PAC-Funktionalität vom Zugangspunkt
sind jedoch Übergaben
leichter zu implementieren, und somit ist die Trennung für Installationen,
die eine Vielzahl von Zugangspunkten aufweisen, passend. 14 zeigt
die Hauptsignalisierung zwischen dem MT, der PAC dem GAGW, wenn
das erweiterte IKE-Protokoll, das als IKE+ bezeichnet wird, zwischen
dem MT und der PAC verwendet wird.
-
HDR
ist ein Internet-Sicherheits-Verband-und-Schlüsselverwaltungsprotokoll-Kopfabschnitt
(Internet Security Association and Key Management Protocol, ISAKMP,
RFC 2409), dessen Austauschtyp die Nutzdatenreihenfolge definiert.
Wenn es als HDR* geschrieben wird, zeigt es eine Nutzdatenverschlüsselung
an. SA sind SA-Verhandlungsnutzdaten mit einem oder mehreren Vorschlags-
und Transformationsnutzdaten (Proposal and Transform payload). KE
sind die Schlüsselaustauschnutzdaten.
IDmt sind die Kennungsnutzdaten für den MT.
-
Das
IKE+ Protokoll wird nun im Detail beschrieben.
-
Das
IKE+ Protokoll verwendet IKE-Mechanismen mit Verbesserungen. Dieser
Authentifizierungsmodus ist eine Erweiterung zu denen, die in der
RFC2409 definiert sind, und bezieht sich auf den einen, der von Litvin
M., Shamir R., Zegman T., in „A
Hybrid Authentication Mode for IKE", draft-ietf-ipsec-isakmp-hybrid-auth-03.txt,
Dezember 1999 vorgeschlagen wurde. Das Protokoll ist für eine Zweiwege-Authentifizierung zwischen
dem MT und der PAC gestaltet und verwendet die GSM-Authentifizierung
in Phase 1. Der Austausch ist nicht symmetrisch, im Gegensatz zu
denen in der RFC2409. Stattdessen müssen beide IKE-Verhandlungsteilnehmer
wissen, wo sie die Ausführung
vornehmen, da sie mit unterschiedlichen Komponenten kommunizieren:
Der MT verwendet sein angefügtes
SIM_B für
die auf die Authentifizierung bezogenen Funktionen, wohingegen sich
die PAC auf einen Authentifizierungsserver (GAGW) im GSM-Telekommunikationsnetz
stützt,
in einer Kette:
SIM_B <--> MT <-------------> PAC <---------> GAGW
-
Die
IKE-Verhandlung zwischen dem MT und der PAC verwendet die Standard-ISAKMP-Nutzdatensyntax.
Andere Nachrichten weisen nicht dieselbe Syntax auf und sind implementierungsabhängig.
-
Da
dieser Austausch ziemlich viel komplizierter ist als die, die in
der RFC2409 definiert sind, ist er nur im IKE-Hauptmodus definiert. Die folgenden
Parameter werden beim Austausch verwendet. Sie sind in Standard-ISAKMP-Nutzdaten
enthalten, wie das später
erläutert
wird.
IMSI IMSI aus der SIM-Karte abgelesen
MT_RAND eine
durch den MT erzeugte Zufallszahl
RAND eine durch das GAGW
vorgegebene Zufallszahl
SIGNrand berechnet durch das GAGW als
HMAC(Kc*n,RAND*n|MT_RANDbillinginfo),
wobei HMAC der MD5
Algorithmus der RFC1321, angewandt im HMAC-Modus,
der in der RFC2104 beschrieben ist, ist und Kc der Chiffrierschlüssel von
der SIM-Karte ist.
SIGNsres berechnet durch den MT und das
GAGW als HMAC(Kc*n,SRES*n||MS||MT_RAND), wobei SRES der Authentikator
von der SIM-Karte ist
Kpac_MT berechnet durch das GAGW und
den MT als HMACK(Kc*n,RAND*n||MS||MT_RAND)
-
Hier
bezieht sich der Strich „|" auf eine Zeichenkettenverkettung,
wobei zwei Sätze
von Ziffern miteinander verkettet werden, beispielsweise 1234|567
= 1234567.
-
Der
Austausch, wie er unten gezeigt ist, ist durch eine Man-in-the-Middle Attacke
zwischen dem MT und der PAC durch die Authentifizierungsasymmetrie
verletzbar. Wenn jedoch der Austausch über ein Medium, wie ein drahtloses
LAN, verwendet wird, ist diese Art eines aktiven Angriffs schwierig.
Die Tatsache, dass das GAGW nur zu ihm bekannten PACs über sichere
Kanäle
spricht, reduziert weiter die Wahrscheinlichkeit für den Erfolg
eines solchen Angriffs.
-
Die
Sicherheit des Austausches kann durch eine Technik mit einem öffentlichen
Schlüssel
verbessert werden, die nicht die Gefahr einer Man-in-the-Middle
Attacke beseitigt, aber die IMSI des Nutzers schützt: Der MT kann das GAGW-Zertifikat
von der PAC anfordern und den darin befindlichen öffentlichen
Schlüssel
verwenden, um den IMSI-Wert, der in den IDmt Nutzdaten herüber gesandt
wird, zu verschlüsseln.
Der IMSI-Wert ist
somit nur dem MT und dem GAGW bekannt, und er kann auch verwendet
werden, um die PAC gegenüber dem
MT zu authentifizieren, wie das später erläutert wird.
-
Wenn
die ID Nutzdaten verwendet werden, um die IMSI des MT zu befördern, wird
das ID-Typfeld im ursprünglichen
ISAKMP-Nutzlastkopfabschnitt
auf ID_USER_FQDN gesetzt.
-
Die
folgenden Werte identifizieren die Rollen, die die IKE-Teilnehmer annehmen
sollten. Die Werte werden vom Bereich der privaten Nutzung, der
in der RFC2409 definiert ist, für
das Authentifikationsverfahrensattribut genommen und sie sollten
zwischen sich gegenseitig einander zustimmenden Parteien verwendet werden.
-
-
14 zeigt,
wie der Austausch funktioniert, wenn der MT der Initiator der IKE-Verhandlung
ist.
-
Die
am meisten bemerkbare Ausnahme gegenüber IKE-Praktiken, bei denen
nur die ersten zwei Nachrichten die verhandelte IKE-SA beeinflussen,
besteht darin, dass die endgültige
SA-Lebensdauer auf
den Sitzungszeitablaufwert, der durch das GAGW ausgewählt wird,
eingestellt wird. Es wird angenommen, dass die anfängliche
Lebensdauer lang genug ist, um es zu ermöglichen, dass die Verhandlung
beendet und der endgültige
Wert eingestellt wird.
-
Der
Zugangsschlüssel
Kpac_MT zwischen der MT und der PAC wird erzeugt als SKEYID = prf(g^xy, CKY-I|CKY-R).
Die Werte für
SKEYID_{a,d,e} werden in der üblichen
Weise auf der Basis der SKEYID berechnet.
-
Wenn
das GAGW die IMSI erkennen kann, so berechnet es SIGNrand. Für das Senden
der RAND und der SIGNrand zum MT verwendet die PAC_MT_RAND beziehungsweise
Hash-Nutzdaten (HASH(1)). Wenn es notwendig ist, mehr als eine RAND
in einer einzigen Nachricht zu senden, so können diese in denselben MT_RAND
Nutzdaten verkettet werden, oder es können viele MT_RANDs gesendet
werden. Der Empfänger
kann leicht die Wahl des Senders bestimmen, da die Größe von GSM
RAND sich nicht häufig ändert. Wenn
die IMSI-Verifikation misslingt, zeigt die PAC dies der MT an durch
die Verwendung von Benachrichtigungsnutzdaten, wobei der Anzeigetyp
auf INVALID-ID-INFORMATION
gesetzt ist. Ansonsten können
implementierungsabhängig
Fehlerkodes zusätzlich
in den Benachrichtigungsnutzdaten übertragen werden.
-
Das
GAGW liefert auch Abrechnungsinformation, die die PAC an den MT
in Benachrichtigungsnutzdaten (NOTIFY) weitergibt. Der Statuskode
für die
Benachrichtigungsnutzdaten ist BILLING_INFO und verwendet den Wert
32768 aus dem privaten Bereich. Die Person, die den MT verwendet,
muss gefragt werden, ob sie den angebotenen Tarif akzeptiert. Wenn
sie dies tut oder wenn ein vordefinierter Zeitgeber abläuft, wird der
Austausch mit Nachricht sieben fortgesetzt. Ansonsten sendet der
MT eine Benachrichtigungsnachricht an die PAC mit dem Benachrichtigungstyp
ATTRIBUTES-NOT-SUPPORTED. Der MT sollte einen relativ kurz eingestellten
Zeitgeber verwenden, so dass die Protokollmaschine in der PAC nicht übermäßig verzögert wird.
-
Der
MT berechnet die SIGNsres und sendet sie hinüber an die PAC in HASH(2),
wobei diese sie an das GAGW für
eine Verifikation weiter gibt. Wenn die Verifikation gelingt, so
enthält
die Antwortnachricht des GAGW einen Zugangsschlüssel (Kpac_MT) zwischen dem
MT und der PAC für
eine spätere
Verwendung und einen Zeitablaufwert für die Sitzung des MT mit dem
GAGW. Der von GAGW gewählte
Zeitablaufwert aktualisiert denjenigen, auf dem man sich vorher
bei der IKE-Verhandlung
geeinigt hat. Die PAC muss somit eine aktualisierte IKE SA an den
MT senden. Die PAC sendet nicht den Wert Kpac_MT an den MT sondern
verwendet ihn stattdessen, um den Körper der aktualisierten SA-Nutzdaten
zu verschlüsseln.
Dies ist gezeigt als <SA_b>Kpac_MT. Der SIGNresult-Wert
vom GAGW wird in ein HASH(3) für
den IKE-Transport
verpackt. Wenn das GAGW die Identität des MT nicht verifizieren
kann, so zeigt die PAC dies dem MT an unter Verwendung von Benachrichtigungsnutzdaten,
wobei der Benachrichtigungstyp auf AUTHENTICATION-FAILED festgesetzt
ist.
-
15 zeigt
die sehr kleinen Modifikationen am Verfahren der 14,
wenn die PAC der Initiator ist. Eine zusätzliche Nachricht ist erforderlich,
um das Zertifikat zum arbeiten zu bringen. Die PAC könnte das GAGW-Zertifikat
in der ersten Nachricht einschließen, wobei auf diese Weise
der MT entscheiden kann, ob er das Zertifikat benötigt. Das
GAGW und die nicht geänderten
Teile sind in der 15 weggelassen worden.
-
16 zeigt
ein Verfahren in einem Authentifizierungssystem gemäß einer
Ausführungsform
der Erfindung. Die Authentifizierung verwendet das Erweiterbare
Authentifizierungsprotokoll (Extensible Authentication Protocol,
EAP), das aus der RFC 2284 „PPP
Extensible Authentication Protocol (EAP)", von L. Bunk und J. Vollbrecht, März 1998,
bekannt ist. Die Ausführungsform
der 16 kann auch mit irgend welchen der oben beschriebenen
Ausführungsformen
kombiniert werden.
-
Das
EAP ist ursprünglich
ein Punkt-zu-Punkt-Protokoll-(PPP)-Authentifizierungs-Rahmenwerk, das es einem
PPP-Teilnehmer ermöglicht,
eine Authentifizierung mit seinem AAA-Server durchzuführen, ohne
dass der Zugangspunkt die Details des Authentifizierungsverfahrens
kennen muss.
-
In
dieser Ausführungsform
gibt die PAC EAP-Pakete zwischen dem MT und dem GAGW weiter, bis sie
eine Erfolgs- oder Fehleranzeige vom GAGW erhält.
-
Durch
die Verwendung des EAP müssen
die Details des Authentifizierungsverfahrens dem MT und dem HAAA
aber nicht einen dazwischen liegenden Authentikator, wie der PAC,
bekannt sein. Somit ist das EAP-Protokoll in der Tat ein Client-AAA-Server-Protokoll,
wobei der Authentikator eine Weiterleitungsstelle (relay) ist, die
die EAP-Pakete weitergibt, ohne darauf zu achten, was sie enthalten.
Die PAC ist nur am Ausgang der Authentifizierung (Erfolg oder Misserfolg)
interessiert. Zusätzlich
wird ein Sitzungsschlüssel
als Teil des Authentifizierungsverfahrens erzeugt, und dieser Schlüssel kann
an die PAC verteilt werden.
-
16 zeigt
EAP-Pakete, die bei einer erfolgreichen SIM-Authentifizierung übertragen werden. Die EAP-Authentifizierung
beginnt typischerweise damit, dass die PAC an den MT eine EAP-Anforderung
mit dem Typ 1 (Kennung) ausgibt. Der MT antwortet mit der EAP-Antwort/Kennung,
die die MT-Kennung enthält.
In einer Roaming-Umgebung ist die Kennung die Netzzugangskennung
(NAI).
-
Nach
dem EAP-Antwort/Kennungs-Paket der MT empfängt das Endgerät die EAP-Anforderungen
des Typs GSMSIM vom HAAA und sendet die entsprechenden EAP-Antworten.
Die EAP-Pakete des Typs GSMSIM haben auch ein Untertyp-Feld. Die
erste EAP-Anforderung
des GSMSIM-Typs ist vom Untertyp-Start. Dieses Paket enthält die kleinste
und größte GSM-SIM-Protokollnummer,
die durch den HAAA unterstützt
wird. Die Antwort des MT (EAP-Antwort/GSMSIM/Start) enthält die MT-Versionsnummer (die
zwischen den minimalen und maximalen Versionsnummern der EAP-Anforderung
liegen muss), den Vorschlag für
die Schlüssellebensdauer
der MT, und eine Zufallszahl MT_RAND, die durch den MT geformt wird.
Alle nachfolgenden EAP-Anforderungs- und Antwortpakete enthalten
dieselbe Version wie das EAP-Antwort/GSMSIM/Start-Paket des MT.
Nach dem Empfang von EAP-Antwort/GSMSIM/Start erhält der Authentifizierungsserver
n GSM-Tripletts aus dem GSM-Netz und erzeugt den gemeinsamen Sitzungsschlüssel K.
-
Die
nächste
EAP-Anforderung, die der Authentifizierungsserver sendet, ist vom
Typ GSMSIM und vom Untertyp Challenge. Sie enthält die RAND-Challenges, die
Schlüssellebensdauer,
die vom HAAA festgelegt wurde, und einen Authentikator für die Challenge
und die Lebensdauer. Auf den Empfang dieser Nachricht hin, lässt der
MT den GSM-Authentifizierungsalgorithmus
auf der SIM-Karte ablaufen und berechnet eine Kopie des MAC_RAND-Authentikators.
Der MT verifiziert dann, dass die MAC_RAND, die er berechnet hat,
der empfangenen MAC_RAND gleicht. Wenn die MAC RANDs nicht passen,
so löscht
der MT die SIM-Authentifizierung.
-
Wenn
alle Prüfungen
gemacht sind, antwortet der MT mit der EAP-Antwort/GSMSIM/Challenge,
die die Antwort MAC_SRES des MT enthält. Der HAAA verifiziert, dass
die MAC_SRES korrekt ist und sendet das EAP-Erfolgspaket, das anzeigt,
dass die Authentifizierung erfolgreich war. Der HAAA fügt die abgeleiteten
Sitzungsschlüssel
in die Nachricht, die er an die PAC sendet, ein.
-
Die
EAP-Pakete können
zwischen dem MT und der PAC durch ein PPP-Protokoll befördert werden, wenn
die PAC ein Einwählserver
ist. Andere Protokolle können
auch verwendet werden. Wenn beispielsweise die PAC eine Authentikator-Anschlusszugangseinheit
(Port Access Entity, PAE) auf einem lokalen Netz (LAN) ist, so kann
die EAP-Kapselung über
das LAN-Protokoll (EAPOL), die durch das IEEE Draft P802.1X/D9,
vom 29. November 2000 vorgeschlagen wurde, ebenfalls verwendet werden.
-
Es
wurden spezielle Implementierungen und Ausführungsformen der Erfindung
beschrieben. Für
einen Durchschnittsfachmann ist es klar, dass die Erfindung nicht
auf die Details der oben dargestellten Ausführungsformen beschränkt ist,
sondern dass sie in anderen Ausführungsformen
unter Verwendung äquivalenter Mittel
implementiert werden kann, ohne von den Eigenschaften der Erfindung
abzuweichen. Beispielsweise ist in einer Ausführungsform der MT physikalisch
eine Einheit getrennt von einer Mobilstation, die das SIM_B aufweist.
Dann bildet der MT eine permanente Verbindung oder eine temporäre Verbindung
zur Mobilstation, beispielsweise eine Funkverbindung niedriger Leistung,
wie eine Bluetooth-Verbindung.
In diesem Fall ist es nicht einmal notwendig, dass das Telekommunikationsnetz
irgend welche getrennte SIMs für
die Authentifizierung verwendet. Die SIM-Funktionalität kann in
die Mobilstation in einer untrennbaren Weise integriert werden,
beispielsweise kann der Ki oder sein Äquivalent
in einem nicht flüchtigen
Speicher der Mobilstation gespeichert werden. Natürlich kann
der Mobilknoten mit der Mobilstation so integriert werden, dass
auf die Authentifizierungsfunktionalität der Mobilstation durch ein
Endgeräteteil
zugegriffen werden kann, unabhängig
davon, ob die Mobilstation gestaltet ist, ein SIM zu verwenden oder
dies nicht der Fall ist. In einer nochmals anderen Ausführungsform
ist das Paketdatennetz ein festes Paketdatennetz, beispielsweise
ein LAN oder ein Weitbereichsnetz. In einer weiteren Ausführungsform
wird die erfundene Authentifizierung für die Authentifizierung eines
Mobilknotens gegenüber
einem Dienst, beispielsweise einem WWW-Portal oder einem Internet-Bankdienst,
verwendet. Somit ist der Umfang der Erfindung nur durch die angefügten Patentansprüche beschränkt.
-
Abkürzungen/Bezugszeichen
-
- AAA
- Authentifizierung,
Autorisierung und Abrechnung
- FA
- fremder
Agent
- FAAA
- Fremder
Authentifizierungs-, Autorisierungs- und Abrechnungsserver
- GAGW
- GSM-Authentifizierungsgateway
- GSM
- globales
System für
Mobilkommunikationen
- GSM
triplet
- RAND,
Kc und SRES
- HA
- Heimatagent
- HAAA
- Heimat-Authentifizierungs-,
Autorisierungs- und Abrechnungsserver
- HDR
- Kopfabschnitt
der Internet Security Assocation und Schlüsselverwaltungsprotokoll (Internet Security
Association and Key Management Proctocol, ISAKMP), dessen Austauschtyp
die Nutzdatenbestellungen definiert
- HLR
- Heimatregister
(ein Element des GSM-Telekommunikationsnetzes)
- IMSI
- internationale
Mobilteilnehmerkennung, im GSM verwendet
- IPsec
- Internetprotokoll-Sicherheitsprotokoll
- ISAKMP
- Internet
Security Association und Schlüsselverwaltungsprotokoll
- Kc
- ein
64 Bit langer Schlüssel,
der durch ein SIM erzeugt wird
- Ki
- Teilnehmerauthentifizierungsschlüssel, der
im GSM verwendet wird und auf dem GSM-Telekommunikationsnetz (beispielsweise
im HLR) und auf dem SIM gespeichert wird
- MD5
- Fingerabdruck
5 (Message Digest 5)
- MT
- Mobilknoten
(Mobil-IP-Client)
- MSC
- Mobilvermittlungszentrale
(ein Element des GSM-Telekommunikationsnetzes)
- MT
- Mobilknoten
- NAI
- Netzzugangskennung,
beispielsweise user@nokia.com oder imsi@gsm.org
- RAND
- eine
128 Bit Zufallszahl, die als eine Challenge bei der GSM-Authentifizierung
verwendet wird
- MT_RAND
- Ein
Zufallsschlüssel
für den
Schutz gegen Replay-Attacken,
vom MT erzeugt
- SIM
- Teilnehmerkennungsmodul
- SPI
- Sicherheitsparameterindex
- SRES
- unterzeichnete
Antwort (signed response), eine 32 Bit Antwort bei einer GSM-Authentifizierung