DE69935510T2

DE69935510T2 - Vermeidung der unberechtigten nutzung eines dienstes

Info

Publication number: DE69935510T2
Application number: DE69935510T
Authority: DE
Inventors: Sami Uskela
Original assignee: Nokia Inc
Current assignee: Nokia Inc
Priority date: 1998-05-20
Filing date: 1999-05-18
Publication date: 2007-11-29
Anticipated expiration: 2019-05-19
Also published as: WO1999060750A3; EP1078492A2; US6721886B1; WO1999060750A2; FI107984B; DE69935510D1; EP1078492B1; FI981132A0; FI981132L; ATE357099T1; AU4267999A

Description

Hintergrund der Erfindung
Die Erfindung betrifft Verhindern eines nicht autorisierten Gebrauchs von den Diensten und insbesondere Verhindern eines unautorisierten Gebrauchs von den Diensten in einem mobilen Kommunikationssystem.
Mobile Kommunikationssysteme wurden entwickelt, da es einen Bedarf gab, Personen zu ermöglichen, sich von festen Telefonendgeräten wegzubewegen, ohne ihre Erreichbarkeit zu beeinträchtigen. Die durch Mobilstationen angebotenen Dienste wurden zusammen mit den mobilen Kommunikationssystemen entwickelt. Im Moment werden verschiedene neue Formen von Diensten für die aktuellen und insbesondere für die zukünftigen mobilen Kommunikationssysteme der dritten Generation geplant, wie zum Beispiel dem universellen mobilen Telekommunikationssystem (Universal Mobile Telecommunication System, UMTS) und der internationalen mobilen Telekommunikation 2000 (International Mobile Telecommunication 2000, IMT-2000). UMTS wird durch das ETSI (European Telecommunications Standards Institute) standardisiert, wohingegen das ITU (International Telecommunications Union) das IMT-200-System standardisiert. Diese zukünftigen Systeme sind sich in grundlegenden Merkmalen sehr ähnlich. Im Folgenden wird in größeren Einzelheiten das IMT-2000-System beschrieben, dessen Architektur in 1 veranschaulicht ist.
Ähnlich allen mobilen Kommunikationssystemen erzeugt IMT-2000 drahtlose Datenübertragungsdienste an mobile Anwender. Dieses System unterstützt Roaming (Herumwandern), mit anderen Worten Anwender des IMT-2000 sind erreichbar und können Anrufe überall innerhalb des Abdeckungsbereichs des IMT-2000-Systems durchführen. Es wird erwartet, dass das IMT-2000 den Bedarf für einen breiten Bereich zukünftiger Dienste erfüllt, wie zum Beispiel eine virtuelle Heimatumgebung (Virtual Home Environment, VHE). Mit der virtuellen Heimatumgebung hat ein Anwender des IMT-2000 überall innerhalb des Abdeckungsbereichs des Systems Zugriff auf dieselben Dienste. Gemäß dem aktuellen Verständnis erfordert eine flexible Implementierung verschiedener Dienste und ins besondere der Unterstützung von Roaming das Laden bestimmter Dienstlogiken in das Endgerät des Anwenders und/oder des bedienenden Netzwerks. Ein bedienendes Netzwerk ist das Netzwerk, durch das der Dienstanbieter dem Anwender seinen Dienst anbietet. Eine Dienstlogik ist ein Programm, Teilprogramm, Skript oder Applet, das mit dem Dienst in Zusammenhang steht. Der Dienst wird mittels der Dienstlogik durch Ausführen wenigstens der Dienstlogik und der darin definierten Funktionen erzeugt. Ein Dienst kann außerdem verschiedene Dienstlogiken umfassen.
Problem mit der oben beschriebenen Anordnung besteht darin, dass sie überhaupt nicht verifiziert, ob der Anwender tatsächlich das Recht hat, den Dienst zu verwenden. Es ist besonders leicht, Dienste, bei denen die Dienstlogik in das Endgerät und/oder bedienende Netzwerk geladen wird, zu kopieren und unautorisierten Gebrauch davon zu machen.
Die internationale Patentanmeldung WO 95/21509 offenbart eine Lösung für dieses Problem, wobei die Authentifizierungsdaten und die Dienstlogik in zwei verschiedenen Einheiten (Verifizierungseinheit und Abwicklungseinheit) des Heimatortsregisters geladen werden.
Kurze Beschreibung der Erfindung
Daher ist es eine Aufgabe der Erfindung, ein Verfahren und eine Vorrichtung, die das Verfahren umsetzt, zur Lösung des oben erwähnte Problems zur Verfügung zu stellen. Die Aufgabe der Erfindung wird gelöst durch ein Verfahren, ein System, ein Netzwerkelement und eine Vorrichtung, die durch das gekennzeichnet sind, was in den unabhängigen Ansprüchen angegeben ist. Der Begriff Vorrichtung bezieht sich hier auf ein Netzwerkelement des bedienenden Netzwerks, ein Endgerät oder irgendeine andere entsprechende Dienstplattform, in bzw. auf die die Dienstlogik geladen werden kann. Die bevorzugten Ausführungsbeispiele der Erfindung sind in den abhängigen Ansprüchen angelegt.
Die Erfindung basiert auf der Idee, eine Dienstlogik aus zwei Teilen zu bilden: Authentisierung bzw. Authentifizierung des Anwenders und der tatsächlichen Dienstlogik. Die für die Anwenderauthentifizierung benötigten Daten werden an die Dienstlogik angefügt, und der Anwender wird immer authentisiert bzw. authentifiziert, bevor die tatsächliche Dienstlogik ausgeführt wird. Dies hat den Vorteil, dass ein nicht autorisierter Gebrauch und ein Kopieren der Dienstlogik verhindert werden kann. Nur der Anwender, für den der Dienst subskribiert (abonniert) ist und der so das Recht hat, den Dienst zu verwenden, kann davon Gebrauch machen.
In einem bevorzugten Ausführungsbeispiel der Erfindung wird immer der Dienstanbieter verifiziert bzw. überprüft, bevor der Dienst ausgeführt wird. Dies verbessert deutlich die Sicherheit des Anwenders und einer möglichen Dienstplattform, in bzw. auf die die Dienstlogik geladen wird. Dies stellt sicher, dass die Dienstlogik wirklich vom Dienstanbieter stammt.
In einem bevorzugten Ausführungsbeispiel der Erfindung wird bei der Anwendeauthentifizierung bzw. Anwenderauthentisierung eine Teilnehmerkennung, die zur Individualisierung verwendet wird, verwendet. Dies hat den Vorteil, dass Teilnehmerauthentifizierung bzw. Teilnehmerüberprüfung einfach, aber zuverlässig ist.
In einem bevorzugten Ausführungsbeispiel der Erfindung wird die Dienstlogik mit ihren Anwender- und Authentifizierungsdaten im Speicher der Dienstplattform, in bzw. auf die sie geladen wird, gespeichert und für einen neuen Anwender werden nur die Authentifizierungsdaten des neuen Anwenders geladen. Dies hat den Vorteil, dass die Dienstlogik nicht mehrere Male nacheinander geladen werden muss, wodurch die Netzwerkauslastung reduziert wird.
Kurze Beschreibung der Zeichnungen
Im Folgenden wird die Erfindung in größerem Detail in Verbindung mit bevorzugten Ausführungsbeispielen und unter Bezugnahme auf die begleitenden Zeichnungen beschrieben, in denen
1 die IMT-2000-Architektur veranschaulicht,
2 ein Flussdiagramm der Dienstplattformfunktionen in einem ersten bevorzugten Ausführungsbeispiel der Erfindung zeigt,
3 ein Signalisierungsdiagramm eines zweiten bevorzugten Ausführungsbeispiels der Erfindung ist, und
4 den Betrieb eines Netzwerkelements, das einen Dienst eines Dienstanbieters steuert, in einem dritten bevorzugten Ausführungsbeispiel der Erfindung zeigt.
Detaillierte Beschreibung der Erfindung
Die vorliegende Erfindung kann in allen Datenübertragungssystemen angewendet werden, in denen der Anwender die abonnierten Dienste in irgendeinem Endgerät, das die Dienstbereitstellung unterstützt, empfangen kann. Im Folgenden wird die Erfindung unter Verwendung des IMT-2000-Systems als ein Beispiel beschrieben, ohne jedoch die Erfindung auf dieses besondere System zu beschränken. Spezifikationen der mobilen Kommunikationssysteme entwickeln sich im Allgemeinen und die des IMT-2000- und UMTS-Systems besonders rasant. Diese Entwicklung kann zusätzliche Änderungen an der Erfindung erforderlich machen. Daher sollten alle Begriffe und Ausdrücke so breit wie möglich interpretiert werden und mit diesen ist beabsichtigt, die Erfindung zu beschreiben und nicht zu beschränken. Es ist die Funktion, die für die Erfindung wesentlich ist, und nicht, in welchem Netzwerkelement oder Vorrichtung sie ausgeführt wird.
1 zeigt die Netzwerkarchitektur des IMT-2000-Systems auf einem allgemeinen Niveau, da die Systemspezifikationen im Moment festgelegt werden. Eine detailliertere Netzwerkstruktur würde im Hinblick auf die Erfindung keine wesentliche Bedeutung hervorbringen. Mobile Kommunikationssysteme der dritten Generation trennen einen Dienstanbieter SP und einen Netzwerkbetreiber voneinander. Ein Dienstanbieter bietet einem Endanwender durch ein Netzwerk SN eines oder mehrerer Netzwerkbetreiber Dienste an. Diese Art eines Netzwerks SN wird ein bedienendes Netzwerk genannt. Ein Dienstanbieter kann Dienste durch ein bedienendes Netzwerk SN eines oder mehrerer Netzwerkbetreiber anbieten. Zusätzlich kann ein Dienstanbieter auf ein anderes bedienendes Netzwerk während des Dienstes umschalten, ohne dass der Anwender dies bemerkt. Ein Dienstanbieter kann außerdem ein Netzwerkbetreiber sein. Ein bedienendes Netzwerk SN umfasst ein tatsächliches Zugriffsnetzwerk AN, ein oder mehrere Kernnetzwerke CN und eine Zusammenarbeitseinheit, die Schnittstellen IWU für jede andere Kernnetzwerkart anpasst. Nach aktuellem Verständnis umfasst ein Zugriffsnetzwerk Basisstationen BS und Funknetzwerksteuerungen RNC, die sie steuern (nicht in der Figur gezeigt). Ein Kernnetzwerk kann ein Netzwerk gemäß dem pan-europäischen mobilen Kommunikationssystem GSM (Globales System für mobile Kommunikation bzw. Global System for Mobile Communication) sein. Verbindungen zu anderen Netzwerken ON werden durch ein Kernnetzwerk CN aufgebaut.
Im Beispiel in 1 wurden ein Heimatortsregister mit IMT-2000-Verbesserung HLRi und der Dienststeuerknoten SCN im bedienenden Netzwerk SN angeordnet. Das verbesserte Heimatortsregister HLRi enthält nicht nur die Heimatregistrierungsdaten des Kernnetzwerks, sondern außerdem die Teilnehmer- und Dienstdaten, die seitens des IMT-2000-Systems benötigt werden. Der Dienstanbieter SP verwaltet diese IMT-2000-Daten für den Dienste-Teil. Der Teilnehmer schließt einen Bestellvertrag mit dem Dienstanbieter, der dann dem Teilnehmer die Verwendung bzw. den Gebrauch der Dienste in Rechnung stellt. Der Dienststeuerknoten SCN ist eine Dienstplattform, in bzw. auf die die Dienstlogik, die mit dem Dienst in Zusammenhang steht, geladen werden kann und auf der dieser ausgeführt werden kann. Der Dienststeuerknoten SCN kann außerdem für Laden des Dienstes irgendwo in das Netzwerk und Weiterleiten von Dienstanforderungen vom Anwender an den Dienstanbieter sorgen. Zusätzlich hierzu stellt der Dienststeuerknoten SCN sicher, dass die Dienste des Heimatnetzwerks außerdem in den besuchten Netzwerken verfügbar sind.
In mobilen Kommunikationsnetzwerken der dritten Generation sind auch Teilnehmer und Anwender getrennt. Der Teilnehmer gestattet dem Anwender Zugriff auf die subskribierten (abonnierten) Dienste durch Aushändigen einer Kennungskarte (bzw. Identification Card, IC Card) an den Anwender, zum Beispiel einer USIM-Karte (User and Services and Identity Module bzw. Anwender- und Dienste- und Identitätsmodul). Der Anwender greift auf die Dienste mit einem mobilen Endgerät MT zu, welches über Basisstationen BS mit einem bedienenden Netzwerk SN über einen Funkweg verbunden ist. Ein mobiles Endgerät MT umfasst tatsächliche mobile Ausstattung ME und eine lösbar verbundene Identifikationskarte USIM, die auch Teilnehmeridentitätsmodul genannt wird. Es ist eine Smart-Card, die vom mobilen Endgerät entfernt werden kann und mit der der Teilnehmer ein kartengesteuertes mobiles Endgerät benutzten kann. Der An wender wird mittels der Karte im mobilen Endgerät identifiziert bzw. erkannt und nicht durch das Endgerät selbst. Gemäß dem aktuellen Verständnis ist die USIM-Karte eine multifunktionale Karte und unterstützt mobile Anwendungen des Kommunikationssystems und andere Anwendungen, wie zum Beispiel Java-Anwendungen, Gesundheitsvorsorgeanwendungen etc. Der Teilnehmer kann die Dienste mehrerer unterschiedlicher Dienstanbieter mit demselben Teilnehmeridentitätsmodul USIM subskribieren (abonnieren). Der Teilnehmer und der Anwender kann ein und dieselbe Person sein. Das Teilnehmeridentitätsmodul USIM enthält außerdem eine internationale mobile Teilnehmeridentität IMSI, mit der der Teilnehmer explizit identifiziert bzw. erkannt werden kann und die außerdem verwendet werden kann, um den Anwender zu identifizieren. Die Kennung eines mobilen Teilnehmers wird Teilnehmeridentität genannt.
Die Endgeräteauswahl der Systeme der dritten Generation wird wahrscheinlich extrem vielfältig sein. Das Endgerät kann ein vereinfachtes Endgerät nur für Sprache sein oder es kann ein Endgerät sein, das verschiedene Dienste zur Verfügung stellt, welches als eine Dienstplattform fungiert und das Laden und Ausführen verschiedener Dienstlogiken unterstützt.
Ein mobiles Kommunikationssystem, das die Funktionalität der vorliegenden Erfindung umsetzt, umfasst nicht nur Einrichtungen bzw. Mittel, die zum Erzeugen und Laden von Diensten gemäß dem Stand der Technik erforderlich sind, sondern auch Einrichtungen bzw. Mittel zum Anhängen bzw. Anfügen von Authentifizierungsdaten an eine Dienstlogik und Einrichtungen bzw. Mittel zum Authentifizieren des Anwenders vor dem Ausführen der Dienstlogik. Hier bedeutet Anhängen bzw. Anfügen außerdem Einbetten von Daten in die Dienstlogik. Zusätzlich kann das System Einrichtungen bzw. Mittel zum Verifizieren bzw. Überprüfen des Dienstanbieters und Einrichtungen bzw. Mittel zum Speichern der Dienstlogik mit ihren ergänzenden Daten in dem Speicher und Einrichtungen bzw. Mittel zum Empfangen von unverschlüsselten Authentifizierungsdaten umfassen. Die Einrichtungen bzw. Mittel zum Anhängen von Authentifizierungsdaten und die möglichen Einrichtungen bzw. Mittel zum Anhängen von Verifizierungsdaten sind bevorzugt zusammen mit den Einrichtungen bzw. Mitteln, die zum Laden der Dienstlogik des Dienstanbieters erforderlich sind, angeordnet. Die anderen Einrichtungen bzw. Mittel sind bevorzugt auf der Dienstplattform angeordnet, zum Beispiel in dem Endgerät oder dem Dienststeuerpunkt des Netzwerkbetreibers. Die Einrichtungen bzw. Mittel oder ein Teil davon kann außerdem irgendwo angeordnet sein, zum Beispiel in dem Netzwerkknoten des Teilnehmernetzwerks oder in dem bedienenden Unterstützungsknoten des Kernnetzwerks.
2 zeigt ein Flussdiagramm des Ablaufs gemäß dem ersten bevorzugten Ausführungsbeispiel der Erfindung auf einer Dienstplattform, die eine tatsächliche mobile Ausstattung ME oder ein Dienststeuerknoten SCN zum Beispiel sein kann. In dem ersten bevorzugten Ausführungsbeispiel der Erfindung wird eine Verschlüsselungstechnik, die per se bekannt ist, basierend auf öffentlichen Schlüsseln in einer neuen und erfinderischen Weise verwendet. Eine derartige Verschlüsselungstechnik ist RSA (Rivest Shamir Adleman Public-Key Cryptographic Algorithm), der sowohl zum Verschlüsseln als auch zur digitalen Signatur verwendet werden kann. In dem ersten bevorzugten Ausführungsbeispiel der Erfindung werden wenigstens der geheime Schlüssel des Teilnehmers und der öffentliche Schlüssel des Dienstanbieters in dem Teilnehmeridentitätsmodul U-SIM gespeichert. Wenn der Teilnehmer mehrere Schlüsselpaare besitzt, wird der geheime Schlüssel des Paars, dessen öffentlicher Schlüssel in die Teilnehmerdaten des Anwenders eingegeben worden sind, gespeichert. Entsprechend kann ein Dienstanbieter mehrere Schlüsselpaare besitzen, von denen eines zum Beispiel in dem Teilnehmeridentitätsmodul gespeichert wird und Informationen über das Paar, dessen Schlüssel in dem Identitätsmodul gespeichert wird, wird in die Teilnehmerdaten eingegeben. Dies stellt sicher, dass der geheime und öffentliche Schlüssel desselben Paars verwendet wird. In dem ersten bevorzugten Ausführungsbeispiel der Erfindung wird der Dienstanbieter durch eine digitale Signatur verifiziert. Diese wird in dem ersten Ausführungsbeispiel der Erfindung durch Berechnung eines Einwege-Hash (Einwege-Hash-Funktion) von der Dienstlogik erzeugt, der dann verschlüsselt wird. Dieses Ausführungsbeispiel hat den unerwarteten Vorteil, dass in Verbindung mit der Verifizierung bzw. Überprüfung des Dienstanbieters die Tatsache, ob die Dienstlogik sich geändert hat, außerdem verifiziert bzw. überprüft wird. Wenn sich die Dienstlogik geändert hat, dann ändert sich auch der aus ihr berechnete Hash und die Dienstanbieterverifizierung wird nicht mehr erfolgreich sein.
Mit Bezug auf 2 wird eine Dienstanforderung betreffend einen Dienst S1 von einem Anwender U1 in Schritt 200 empfangen. In Schritt 201 wird eine Verifizierung durchgeführt, um zu sehen, ob die Dienstlogik SL1, die sich auf den Dienst S1 bezieht, im Speicher ist. Wenn sie es nicht ist, wird die Dienstanforderung an den Dienstanbieter in Schritt 202 weitergeleitet. Der Dienstanbieter findet die aktuelle Dienstlogik SL1, die sich auf den Dienst S1 bezieht, und fügt an die Dienstlogik Authentifizierungsdaten A1 an, die für die Anwenderauthentifizierung benötigt werden, welche in dem ersten bevorzugten Ausführungsbeispiel der öffentliche Schlüssel des Teilnehmers sind. Danach berechnet der Dienstanbieter den Hash aus der aktuellen Dienstlogik und den Authentifizierungsdaten, fügt dies als Verifizierungsdaten V1 an die Dienstlogik an und verschlüsselt die so erzeugte Datei mit seinem eigenen geheimen Schlüssel. Die Datei enthält die Verifizierungsdaten V1, die Authentifizierungsdatei A1 und die tatsächliche Dienstlogik SL1. Alternativ könnte der Dienstanbieter den Hash mit seinem geheimen Schlüssel verschlüsseln, den verschlüsselten Hash als die Verifizierungsdaten V1 an die Datei anfügen und dann die Datei mit dem öffentlichen Schlüssel des Anwenders verschlüsseln. Danach werden in Schritt 203 die Datei, das heißt die tatsächliche Dienstlogik SL1, die mit dem Dienst S1 in Zusammenhang steht, die Authentifizierungsdaten A1, die an sie für den Anwender U1 angefügt worden sind, und die Verifizierungsdaten V1, die für diese berechnet wurden, in bzw. auf die Dienstplattform geladen. In Schritt 204 werden gespeichert die Dienstlogik SL1 und in ihr, die Authentifizierungsdaten A1 und die Verifizierungsdaten V1, die sich auf den Anwender U1 beziehen, und natürlich Informationen über den Anwender, auf den sich die Authentifizierungsdaten A1 und die Verifizierungsdaten V1 beziehen. Die Daten werden in einem verschlüsselten Format im Speicher gespeichert. Danach wird im ersten bevorzugten Ausführungsbeispiel der öffentliche Schlüssel des Dienstanbieters vom Teilnehmeridentitätsmodul USIM im Endgerät des Anwenders in Schritt 205 angefordert und in Schritt 206 empfangen, wonach die Verschlüsselung der Dienstlogik SL1, der Authentifizierungsdaten A1 und der Verifizierungsdaten V1 in Schritt 207 unter Verwendung des empfangenen Schlüssels entschlüsselt werden. In Ausführungsbeispielen, in denen der Dienstanbieter nur ein Schlüsselpaar besitzt, kann sich die Information über den öffentlichen Schlüssel des Anbieters bereits auf der Dienstplattform befinden und braucht nicht getrennt angefordert zu werden. Sobald die Verschlüsselungen entschlüsselt worden sind, wird der Dienstanbieter verifiziert durch Berechnen eines Hashs aus der Dienstlogik und den Authentifizierungsdaten in Schritt 208 und durch Vergleichen des so berechneten Hashs mit den Verifizierungsdaten V1 in Schritt 209. Wenn sie dieselben sind, ist die Verifizierung des Dienstanbieters erfolgreich und danach wird eine Anfrage, das heißt eine Zeichenkette, in Schritt 210 ausgewählt. Wie die Anfrage ausgewählt wird, hat keine Bedeutung im Hinblick auf die Erfindung. Eine einfache und sichere Lösung ist es, einen Zufallszahlengenerator zu verwenden, wodurch die Anfrage eine Zufallszahl ist. Die ausgewählte Anfrage wird in Schritt 211 mit dem öffentlichen Schlüssel des Teilnehmers, das heißt die Authentifizierungsdaten A1, verschlüsselt. Danach wird in Schritt 212 die verschlüsselte Anfrage an das Teilnehmeridentitätsmodul USIM im Endgerät des Anwenders U1 gesendet, welches die verschlüsselte Anfrage in Klartext mit dem geheimen Schlüssel des Teilnehmers entschlüsselt und den Klartext zurück zur Dienstplattform sendet. In Schritt 213 empfängt die Dienstplattform den Klartext und in Schritt 214 vergleicht sie die ursprüngliche Anfrage mit dem Klartext. Wenn die Zeichenketten dieselben sind, ist die Anwenderauthentifizierung erfolgreich und die tatsächliche Dienstlogik-SL1 kann in Schritt 215 ausgeführt werden.
Wenn in Schritt 209 festgestellt wird, dass der berechnete Hash nicht derselbe ist wie die Verifizierungsdaten, schlägt die Dienstanbieterverifizierung fehl oder die Dienstlogik hat sich verändert. In beiden Fällen würde das Ausführen der Dienstlogik ein Sicherheitsrisiko sein und daher wird sie nicht ausgeführt und in Schritt 217 werden alle Daten, die für den Dienst S1 gespeichert sind, das heißt die Dienstlogik SL1 und alle angefügten Authentifizierungs- und Verifizierungsdaten mit Anwenderdaten aus dem Speicher gelöscht.
Wenn in Schritt 214 festgestellt wird, dass die Anfrage nicht dieselbe ist wie der Klartext, ist die Authentifizierung nicht erfolgreich und die Dienstlogik wird nicht ausgeführt und in Schritt 216 werden die Authentifizierungsdaten A1, die Verifizierungsdaten V1 und Informationen über den Anwender U1, die an die Dienstlogik SL1 des Dienstes S1 angefügt wurden, aus dem Speicher gelöscht. Auf diese Weise muss die tatsächliche Dienstlogik 311 das nächste Mal nicht mehr geladen werden, sondern nur die Authentifizierungsdaten und Verifizierungsdaten.
Falls in Schritt 201 festgestellt wird, dass die Dienstlogik SL1, die sich auf den Dienst S1 bezieht, sich im Speicher befindet, wird eine Prüfung in Schritt 218 durchgeführt, um zu sehen, ob die Authentifizierungs- und Verifizierungsdaten für den Anwender U1 an sie angefügt sind. Wenn diese Daten sich auch im Speicher befinden, geht der Ablauf von Schritt 204, in dem der öffentliche Schlüssel des Dienstanbieters vom Teilnehmeridentitätsmodul USIM abgefragt wird, weiter. Von Schritt 205 an geht der Ablauf wie oben beschrieben weiter. Auf diese Weise werden Netzwerkressourcen gespart, da die einmal geladenen Daten nicht noch einmal geladen werden müssen.
Wenn in Schritt 218 festgestellt wird, dass keine Authentifizierungs- und Verifizierungsdaten für den Anwender U1 an die Dienstlogik SL1 im Speicher angefügt sind, werden in Schritt 219 die Authentifizierungs- und Verifizierungsdaten für den Dienst S1 vom Dienstanbieter für den Anwender U1 angefordert. Die Authentifizierungsdaten A1 und die Verifizierungsdaten V1 werden in Schritt 220 empfangen, nach dem sie und Informationen über den Anwender U1 an die Dienstlogik SL1 in Schritt 221 angefügt werden. Danach geht der Ablauf von Schritt 205, in dem der öffentliche Schlüssel des Dienstanbieters im Teilnehmeridentitätsmodul USIM angefordert wurde, weiter. Von Schritt 205 an geht der Ablauf weiter wie oben beschrieben.
Die Dienstplattform kann eine tatsächliche mobile Ausstattung ME oder ein Netzwerkelement des bedienenden Netzwerks, wie zum Beispiel der Dienststeuerknoten SCN, sein. Der Speicher, in dem die Daten und Dienstlogiken gespeichert werden, kann außerdem ein Cache-Speicher sein. In Ausführungsbeispielen, in denen die Dienstlogik im Speicher gespeichert wird, kann die Dienstplattform Einrichtungen bzw. Mittel zum Löschen der Dienstlogik aus dem Speicher für vorbestimmte Gründe, zum Beispiel nach einer bestimmten Zeitdauer, umfassen.
In dem Ausführungsbeispiel, in dem die Dienstlogik nicht in dem Speicher gespeichert wird, werden die Schritte 200, 202, 203 und 205 bis 215 ausgeführt. Das Datenlöschen, das in den Schritten 216 und 217 beschrieben wurde, findet nicht statt, aber die tatsächliche Dienstlogik bleibt unausgeführt.
Die oben in 2 beschriebenen Schritte befinden sich nicht in absolut chronologischer Reihenfolge und einige der Schritte können gleichzeitig oder von der gegebenen Reiehenfolge abweichend ausgeführt werden. Andere Funktionen können außerdem zwischen den Schritten ausgeführt werden. Einige der Schritte, wie zum Beispiel die Dienstanbieterverifizierung, kann außerdem weggelassen werden. Der wesentliche Punkt besteht in der Authentifizierung des Anwenders, bevor die tatsächliche geladene Dienstlogik ausgeführt wird.
3 zeigt eine Signalisierung gemäß einem zweiten bevorzugten Ausführungsbeispiel der Erfindung. In dem zweiten Ausführungsbeispiel wird die Teilnehmerkennung IMSI als die Authentifizierungsdaten verwendet. Es wird außerdem angenommen, dass die Dienstlogik in die tatsächliche mobile Ausstattung ME geladen wird und nicht in ihrem Speicher gespeichert wird.
In 3 sendet ein Anwender U Informationen in einer Nachricht 3-1 an eine mobile Ausstattung ME über die Anwenderschnittstelle, wobei ein Dienst S angefordert wird. Die mobile Ausstattung ME sendet die Dienstanforderung über das bedienende Netzwerk an einen Dienstanbieter SP in Nachricht 3-2. Die Dienstanforderung enthält Informationen über den benötigten Dienst S und den Anwender U, der den Dienst anfordert. In Schritt 3-3 prüft der Dienstanbieter, ob der Dienst S von dem Anwender U subskribiert (abonniert) ist. Wenn der Dienst S nicht von dem Anwender subskribiert ist, sendet der Dienstanbieter über das bedienende Netzwerk eine negative Bestätigung auf die Dienstanforderung in Nachricht 3-4 an die mobile Ausstattung ME, die die Informationen in Nachricht 3-5 über die Anwenderschnittstelle an den Anwender U weiterleitet.
Wenn der Dienst S von dem Anwender subskribiert (abonniert) ist, ruft der Dienstanbieter die Teilnehmerkennung IMSI-A des Anwenders U und die Dienstlogik SL, die mit dem Dienst S in Zusammenhang steht, ab und berechnet daraus einen Hash. Danach verschlüsselt der Dienstanbieter die Dienstlogik und die damit in Zusammenhang stehenden Daten (IMSI-A, Hash) mit dem geheimen Schlüssel des Dienstanbieters. In Nachricht 3-6 sendet der Dienstanbieter die Dienstlogik SL, die Kennung IMSI-A und den Hash an die mobile Ausstattung ME. In dem zweiten bevorzugten Ausführungsbeispiel fordert nach Empfangen der Nachricht 3-6 die mobile Ausstattung ME den öffentlichen Schlüssel des Dienstanbieters aus dem Teilnehmeridentitätsmodul USIM in Nachricht 3-7 an. Das Teilnehmeridentitätsmodul USIM sendet sie an die mobile Ausstattung in Nachricht 3-8, nach der die mobile Ausstattung ME den Dienstanbieter in Schritt 3-9 verifiziert. Die mobile Ausstattung entschlüsselt die Verschlüsselung der Dienstlogik SL, die Teilnehmerkennung A1 und den Hash mit dem empfangenen öffentlichen Schlüssel und berechnet einen Hash aus der Kombination der Dienstlogik und der Teilnehmerkennung IMSI-A. Wenn der berechnete Hash nicht derselbe ist wie der in Nachricht 3-6 empfangene, schlägt die Verifizierung bzw. Überprüfung fehl. In einem derartigen Fall wird die Dienstlogik nicht ausgeführt und die mobile Ausstattung ME sendet Informationen über den Verifizierungsfehler durch die Anwenderschnittstelle an den Anwender U in Nachricht 3-10, indem sie zum Beispiel mitteilt, dass der Dienst nicht verfügbar ist.
Wenn der in Schritt 3-9 berechnete Hash und der empfangene Hash derselbe sind, ist die Verifizierung erfolgreich und die mobile Ausstattung ME fordert die Teilnehmerkennung IMSI des Anwenders U von dem Teilnehmeridentitätsmodul USIM in Nachricht 3-11 an. Das Teilnehmeridentitätsmodul USIM ruft die Teilnehmerkennung IMSI-B aus ihrem Speicher ab und sendet sie an die mobile Ausstattung ME in Nachricht 3-12. In Schritt 3-13 authentifiziert die mobile Ausstattung den Anwender durch Prüfen, ob die IMSI-A, die von dem Dienstanbieter empfangen wurde, dieselbe ist wie die IMSI-B, die von dem Identitätsmodul empfangen wurde. Wenn der Anwender die Authentifizierung in Schritt 3-9 passiert (das heißt IMSI-A ist dieselbe wie IMSI-B), führt die mobile Ausstattung ME die tatsächliche Dienstlogik SL aus und stellt den Dienst durch die Anwenderschnittstelle dem Anwender U in Nachricht 3-14 zur Verfügung. Wenn die Werte der Teilnehmerkennungen IMSI sich voneinander unterscheiden, schlägt die Authentifizierung fehl. In einem derartigen Fall führt die mobile Ausstattung die tatsächliche Dienstlogik nicht aus, sondern informiert den Anwender U über die Anwenderschnittstelle in Nachricht 3-10, dass die Authentifizierung fehlgeschlagen ist, indem sie zum Beispiel mitteilt, dass der Dienst nicht verfügbar ist.
Die beschriebenen Signalisierungsnachrichten in Verbindung mit 3 sind lediglich eine Referenz und können mehrere getrennte Nachrichten enthalten, um dieselben Informationen weiterzuleiten. Zusätzlich können die Nachrichten außerdem andere Informationen enthalten. Die Nachrichten können außerdem frei kombiniert werden. In dem Ausführungsbeispiel, in dem die Dienstlogik nicht verifiziert wird, werden die Nachrichten 3-7, 3-8 und 3-10, die sich auf die Verifizierung beziehen, und Schritt 3-9 ausgelassen. Abhängig von den Dienstanbietern, vom Kernnetzwerk und der mobilen Ausstattung, können andere Netzwerkelemente auf die verschiedenste Funktionalitäten verteilt sind, an der Datenübertragung und Signalisierung teilnehmen.
4 zeigt in einem dritten bevorzugten Ausführungsbeispiel der Erfindung ein Flussdiagramm eines Netzwerkelements, das einen Dienst eines Dienstanbieters steuert. Im dritten bevorzugten Ausführungsbeispiel wird die Authentifizierung und die Verifizierung nur durchgeführt, wenn eine Dienstlogik in ein besuchtes (Besuchs-)Netzwerk oder mobile Ausstattung geladen wird. Das besuchte Netzwerk ist ein Netzwerk, dessen Netzwerkelement, in das der Dienst geladen wird, ein Netzwerkelement ist, das einem Anbieter gehört, der ein anderer als der Dienstanbieter ist. Das dritte bevorzugte Ausführungsbeispiel verwendet sowohl Verschlüsselung mit öffentlichem Schlüssel als auch symmetrische Verschlüsselung, wie zum Beispiel DES (Data Encryption Standard). Die letztere Verschlüsselungstechnik wird verwendet, wenn die Dienstlogik in die mobile Ausstattung geladen wird. Ein gemeinsamer Schlüssel wird dafür sowohl im Teilnehmeridentitätsmodul als auch in den Teilnehmerdaten des Anwenders gespeichert. Zusätzlich wird der öffentliche Schlüssel des Dienstanbieters im Teilnehmeridentitätsmodul für die in den besuchten Netzwerken zu ladenden Dienstlogiken gespeichert. Alleinige Verschlüsselung der Dienstlogik mit dem geheimen Schlüssel des Dienstanbieters, vor Senden der Dienstlogik an das bedienende Netzwerk, oder Verschlüsselung mit dem gemeinsamen Schlüssel, vor dem Laden in die mobile Ausstattung, wird als Signatur verwendet.
Jetzt wird Bezug auf 4 genommen, in der in Schritt 400 eine Dienstanforderung betreffend einen Dienst S2 von einem Anwender U2 empfangen wird. In Schritt 401 wird eine Prüfung durchgeführt, um zu sehen, ob der Anwender U2 den Dienst S2 subskribiert (abonniert). Wenn der Anwender den Dienst S2 subskribiert, wird eine Prüfung in Schritt 402 durchgeführt, um zu sehen, ob die Dienstlogik SL2, die sich auf den Dienst U2 bezieht, ein Laden in die mobile Ausstattung ME des Anwenders erfordert. Wenn die Dienstlogik SL2 in die mobile Ausstattung des Anwenders geladen wird, wird in Schritt 403 ein gemeinsamer Schlüssel aus den Teilnehmerdaten des Anwenders U2 zur Verschlüsselung der Dienstlogik SL2 in Schritt 404 abgerufen. Dieser gemeinsame Schlüssel wird verwendet sowohl als die Authentifizierungsdaten des Anwenders als auch die Verifizierungsdaten des Dienstanbieters. Niemand anders sollte in diesem Fall irgendeine Information über den gemeinsamen Schlüssel besitzen. Die Authentifizierung und Verifizierung wird im Zusammenhang mit der Entschlüsselung der Dienstlogik durchgeführt. Die verschlüsselte Dienstlogik SL2 wird in die mobile Ausstattung ME in Schritt 405 geladen. Der Anwender wird authentifiziert und der Dienstanbieter wird in der mobilen Ausstattung verifiziert, zum Beispiel durch Senden der verschlüsselten Dienstlogik an das Teilnehmeridentitätsmodul USIM in der mobilen Ausstattung, die die Dienstlogik unter Verwendung des gemeinsamen Schlüssels in ihrem Speicher entschlüsselt und die Klartext-Dienstlogik an die mobile Ausstattung sendet. Wenn die Dienstlogik ausgeführt worden ist, werden Informationen bezüglich in Schritt 406 empfangen und dem Teilnehmer wird der Gebrauch bzw. die Verwendung des Dienstes in Schritt 407 in Rechnung gestellt.
Wenn in Schritt 402 festgestellt wird, dass die Dienstlogik SL2 nicht in die mobile Ausstattung geladen wird, wird in Schritt 408 eine Prüfung durchgeführt, um zu sehen, ob der Anwender U2 sich im Bereich des Heimatnetzwerks befindet. Wenn ja, wird die Dienstlogik SL2 in Schritt 409 ausgeführt, nach dem der Ablauf von Schritt 407, in dem dem Anwender der Gebrauch bzw. die Verwendung des Dienstes in Rechnung gestellt wird.
Wenn in Schritt 408 festgestellt wird, dass der Anwender sich nicht im Bereich des Heimatnetzwerks befindet, muss im dritten bevorzugten Ausführungsbeispiel der Erfindung die Dienstlogik SL2 in das besuchte Netzwerk geladen werden. Dafür wird in Schritt 410 der öffentliche Schlüssel des Anwenders U2 aus den Teilnehmerdaten abgerufen, um diese als Authentifizierungsdaten an die Dienstlogik anzufügen. In Schritt 411 wird der öffentliche Schlüssel des Anwenders an die Dienstlogik SL2 angefügt und sie werden unter Verwendung des geheimen Schlüssels des Dienstanbieters in Schritt 412 verschlüsselt. Die Verschlüsselung fungiert außerdem als Verifizierungsdaten. Wenn der Dienstanbieter mehrere Schlüsselpaare öffentlicher und geheimer Schlüssel besitzt, wird der geheime Schlüssel des Schlüsselpaars, dessen öffentlicher Schlüssel in dem Identitäts modul des Anwenders gespeichert wurde, verwendet. Die verschlüsselte Dienstlogik, an die die Authentifizierungsdaten angefügt wurden, wird in das besuchte Netzwerk in Schritt 413 geladen. Das Netzwerkelement des besuchten Netzwerks prüft den Dienstanbieter durch Entschlüsseln der Dienstlogik unter Verwendung des öffentlichen Schlüssels des Dienstanbieters und authentifiziert den Anwender zum Beispiel in der Art und Weise wie im Zusammenhang mit 2 beschrieben, wonach die Dienstlogik ausgeführt wird. Wenn die Dienstlogik ausgeführt wurde, wird diesbezügliche Information in Schritt 406 empfangen und dem Teilnehmer wird die Verwendung bzw. der Gebrauch des Dienstes in Schritt 407 in Rechnung gestellt.
Wenn in Schritt 411 festgestellt wird, dass der angeforderte Dienst von dem Anwender nicht subskribiert (abonniert) ist, werden in Schritt 414 Informationen übertragen, dass der Dienst für den Anwender nicht verfügbar ist.
Oben in Verbindung mit 4 wurde angenommen, dass die Authentifizierung und Verifizierung erfolgreich ist. Wenn dies nicht der Fall ist, wird die Dienstlogik nicht ausgeführt und der Teilnehmer nicht belastet bzw. dies dem Teilnehmer nicht in Rechnung gestellt. Die in Verbindung mit 4 oben beschriebenen Schritte sind nicht in absolut chronologischer Reihenfolge und einige der Schritte können gleichzeitig oder abweichend von der gegebenen Reihenfolge ausgeführt werden. Andere Funktionen können außerdem zwischen den Schritten ausgeführt werden. Einige der Schritte können außerdem weggelassen werden. Der wesentliche Punkt besteht darin, dass die Authentifizierungsdaten auf irgendeine Weise an die Dienstlogik, die geladen wird, angefügt werden.
In den obigen Ausführungsbeispielen wurde die tatsächliche Dienstlogik verändert, um sicherzustellen, dass die Authentifizierung und Verifizierung durchgeführt wird. Dies wurde durchgeführt durch Zufügen bzw. Anfügen der Dienstlogik eines Teils, die Authentifizierung und Verifizierung sicherstellt, der immer vor der Dienstlogik ausgeführt wird. In einigen Ausführungsbeispielen kann die Dienstlogik nur verändert werden, um die Authentifizierung sicherzustellen. In einigen Ausführungsbeispielen braucht die Dienstlogik nicht geändert zu werden und die Authentifizierungsdaten und die möglichen Verifizierungsdaten werden an die Dienstlogik als getrennte Daten angefügt und die Dienstplattform stellt sicher, dass die Authentifizierung und die mögliche Verifizierung durchgeführt wird. In diesen Ausführungsbeispielen können vorverschlüsselte Dienstlogiken verwendet werden, was die Auslastung des Netzwerkelements reduziert, da eine Verschlüsselung nur einmal durchgeführt wird.
Es wurde im Zusammenhang mit 2, 3 und 4 angenommen, dass der Dienstanbieter die Authentifizierungsdaten an die Dienstlogik vor der Verschlüsselung anfügt. Die Authentifizierungsdaten können außerdem an eine vorverschlüsselte Dienstlogik angefügt werden. In einem solchen Fall können das bedienende Netzwerk oder die mobile Ausstattung außerdem angepasst werden, die Authentifizierungsdaten an die Dienstlogik anzufügen, zum Beispiel mittels der Anwenderdaten, die in der Dienstanforderung zur Verfügung gestellt wurden. Es wurde oben dargestellt, dass der Anwender nur nach der Verifizierung authentifiziert wird. Jedoch hat die Reihenfolge keine Bedeutung im Hinblick auf die Erfindung. Der Anwender kann in einem Ausführungsbeispiel, in dem auch der Dienstanbieter verifiziert wird, authentifiziert werden, bevor der Dienstanbieter verifiziert wird. Die Daten und/oder Dienstlogik muss außerdem nicht verschlüsselt werden, ohne dass Verschlüsselung für Authentifizierung und/oder Verifizierung verwendet wird. Andere Alternativen zur Authentifizierung, Verifizierung und möglichen Verschlüsselung als diejenigen oben im Zusammenhang mit den bevorzugten Ausführungsbeispielen beschriebenen, können außerdem verwendet werden. Die bevorzugten Ausführungsbeispiele können auch kombiniert werden. Der wesentliche Punkt besteht darin, dass der Anwender vor dem Ausführen der Dienstlogik authentifiziert wird, wenigstens sobald die Dienstlogik in die mobile Ausstattung oder das besuchte Netzwerk geladen wird. In einem Ausführungsbeispiel, in dem die Dienstlogik in die mobile Ausstattung geladen wird, kann die Verschlüsselung der Dienstlogik mit dem öffentlichen Schlüssel des Teilnehmers auch als die Authentifizierungsdaten verwendet werden. Der Teilnehmer wird authentifiziert, wenn das Identitätsmodul USIM die Verschlüsselung mit dem geheimen Schlüssel des Teilnehmers entschlüsselt. Aus Sicherheitsgründen ist es von Vorteil, dass das USIM niemals an die mobile Ausstattung den in ihr gespeicherten geheimen Schlüssel sendet und die Verschlüsselung mit dem geheimen Schlüssel immer im USIM durchgeführt wird. Andere Daten zur Authentifizierung und möglichen Verifizierung, als die in den obigen Beispielen verwendeten, können auch verwendet werden. Die Anforderungen für die Authentifizierungsdaten und möglichen Verifizierungsdaten sind eine passende Individualisierung, Verlässlichkeit und Nicht-Ablehnung. Geeignete Individualisierung bedeutet, dass die Daten den Anwender wenigstens pro Teilnehmer spezifiziert.
Im Aufbau des bedienenden Netzwerks sind keine Änderungen an der Hardware erforderlich. Es umfasst Prozessoren und Speicher, die in Funktionen der Erfindung verwendet werden können. Alle Änderungen, die zur Implementierung der Erfindung benötigt werden, können stattdessen als zusätzliche aktualisierte Software-Routinen in den Netzwerkelementen, in die die Dienstlogik geladen wird, durchgeführt werden. Ein Beispiel für ein derartiges Netzwerkelement ist der Dienststeuerknoten. Zusätzlicher Speicher wird außerdem benötigt in dem Netzwerkelement, das die geladene Dienstlogik mit ihren zusätzlichen Daten speichert.
Der Aufbau des Dienstanbieters erfordert auch keine Änderungen an der Hardware. Der Dienstanbieter umfasst Prozessoren und Speicher, die in Funktionen der Erfindung verwendet werden können. Alle Änderungen, die zur Implementierung der Erfindung erforderlich sind, können als zusätzliche oder aktualisierte Software-Routinen durchgeführt werden, um die Funktionalität der Erfindung zu erreichen. Zusätzlicher Speicher kann benötigt werden, abhängig vom Ausführungsbeispiel der Erfindung. Es ist jedoch auf eine geringe Menge begrenzt, die zum Speichern der zusätzlichen Authentifizierungsdaten und der möglichen Verifizierungsdaten ausreicht.
Der Aufbau der mobilen Ausstattung erfordert keine Änderungen an der Hardware. Sie umfasst Prozessoren und Speicher, die in der Erfindung Funktionen verwendet werden können. Alle Änderungen, die zur Implementierung der Erfindung benötigt werden, können stattdessen als zusätzliche oder aktualisierte Software-Routinen in der mobilen Ausstattung durchgeführt werden, die angepasst ist, um als Dienstplattform zu fungieren. Wenn die Dienstlogik in der mobilen Ausstattung gespeichert wird, wird zusätzlicher Speicher benötigt.
Im Teilnehmeridentitätsmodul USIM ist der zusätzliche Speicher, der möglicherweise zur Implementierung der Erfindung benötigt wird, auf eine kleine Menge begrenzt, die zum Speichern der zusätzlichen Authentifizierungsdaten, der mög lichen Verifizierungsdaten und der möglicherweise benötigten Entschlüsselungsalgorithmen ausreicht.
Es ist einleuchtend, dass die obige Beschreibung und die Figuren, die sich auf sie beziehen, lediglich für den Zweck der Veranschaulichung der vorliegenden Erfindung dargestellt wurden. Die unterschiedlichsten Modifikationen und Variationen der Erfindungen sind für Fachleute offensichtlich, ohne von dem Bereich der Erfindung, wie er in den angefügten Ansprüchen offenbart ist, abzuweichen.

Claims

Verfahren zum Verhindern eines nicht autorisierten Gebrauchs eines Dienstes in einem mobilen Kommunikationssystem, wobei in dem Verfahren eine Dienstanforderung von einem Anwender des Dienstes empfangen wird, der Dienst mittels einer Dienstlogik erzeugt wird, der Anwender, der den Dienst anfordert, mittels Authentifizierungsdaten (3-9) authentifiziert wird, und die Dienstlogik nur ausgeführt wird, wenn die Authentifizierung erfolgreich ist (3-14), dadurch gekennzeichnet, dass in dem Verfahren die Authentifizierungsdaten an die Dienstlogik (3-6) angefügt werden.
Verfahren gemäß Anspruch 1, dadurch gekennzeichnet, dass auch Verifizierungsdaten des Dienstanbieters an die Dienstlogik angefügt werden, dass der Dienstanbieter in Verbindung mit Anwenderauthentifizierung (3-13) verifiziert wird, und dass die Dienstlogik nur ausgeführt wird, wenn auch die Verifizierung erfolgreich ist.
Verfahren gemäß Anspruch 2, dadurch gekennzeichnet, ein erster von der Dienstlogik berechneter Hash-Wert als Verifizierungsdaten der Dienstlogik verwendet werden, dass die Dienstlogik in eine Dienstplattform geladen wird, auf der sie ausgeführt wird, um den Dienst zu erzeugen, dass der Dienstanbieter auf der Dienstplattform durch Berechnen eines zweiten Hash-Werts aus der Dienstlogik verifiziert wird, und wenn der erste und der zweite Hash-Wert gleich sind, die Verifizierung erfolgreich ist, wenn der erste und der zweite Hash-Wert unterschiedlich sind, die Verifizierung fehlschlägt.
Verfahren gemäß Anspruch 2, dadurch gekennzeichnet, dass die Signatur des Dienstanbieters als die Verifizierungsdaten verwendet werden, dass die Dienstlogik durch Verschlüsseln mit dem geheimen Schlüssel des Dienstanbieters signiert wird, und dass der Dienstanbieter durch Entschlüsseln der Verschlüsselung der Dienstlogik mit dem öffentlichen Schlüssel des Dienstanbieters verifiziert wird.
Verfahren gemäß einem der hervorgehenden Ansprüche, dadurch gekennzeichnet, dass der geheime Schlüssel des Teilnehmers in dem Teilnehmerkennungsmodul (Subscriber Identity Modul, USIM) des Anwenders des Dienstes gespeichert wird, dass der öffentliche Schlüssel des Teilnehmers als die Authentifizierungsdaten verwendet wird, eine Anfrage, die mit dem öffentlichen Schlüsseln des Teilnehmers verschlüsselt ist, an das Teilnehmerkennungsmodul, das in der Mobilausstattung des Anwenders, der den Dienst anfordert (207), enthalten ist, gesendet wird, dass die Anfrage mit dem geheimen Schlüssel des Teilnehmers in dem Kennungsmodul in Klartext entschlüsselt wird, dass der Klartext von dem Kennungsmodul empfangen wird (208), dass eine Verifizierung durchgeführt wird, um zu erkennen, ob die unverschlüsselte Sicherheitsanfrage und der Klartext einander entsprechen (209), und wenn sie sich entsprechen, die Authentifizierung erfolgreich ist, wenn sie sich nicht entsprechen, die Authentifizierung fehlschlägt.
Verfahren gemäß Anspruch 1, 2, 3 oder 4, dadurch gekennzeichnet, dass die individuelle Kennung des Teilnehmers als die Authentifizierungsdaten verwendet werden, dass eine Dienstanforderung von dem Anwender empfangen wird (3-1), dass die individuelle auf den Anwender bezogen Teilnehmeridentität angefordert wird (3-7), dass die angeforderte Kennung empfangen wird (3-8), dass eine Verifizierung durchgeführt wird, um zu erkennen, ob die Authentifizierungsdaten und die angeforderte Kennung einander entsprechen (3-9), und dass, wenn sie sich entsprechen, die Authentifizierung erfolgreich ist, und dass, wenn sie sich nicht entsprechen, die Authentifizierung fehlschlägt.
Verfahren gemäß einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Dienstlogik auf die Dienstplattform geladen wird, wo sie ausgeführt wird, um den Dienst zu erzeugen, und dass die Authentifizierungsdaten an die Dienstlogik in Verbindung mit dem Laden angefügt werden.
Verfahren gemäß Anspruch 7, dadurch gekennzeichnet, dass die Dienstlogik, die an sie angefügten Authentifizierungsdaten, und die den Anwender anzeigenden Daten auf der Dienstplattform im Verbindung mit dem Laden gespeichert werden (204), dass eine Dienstanforderung von dem Anwender empfangen wird, dass eine Verifizierung durchgeführt wird, um zu erkennen, ob die in Beziehung mit dem angeforderten Dienst stehende Dienstlogik auf der Dienstplattform gespeichert ist (201), und wenn nicht, die Dienstlogik geladen wird (203), wenn ja, – eine Verifizierung durchgeführt wird, um zu erkennen, ob Authentifizierungsdaten für den den Dienst anfordernden Anwender gespeichert worden sind (217), und – wenn ja, der Anwende authentifiziert wird, – wenn nicht, – Authentifizierungsdaten von dem Anwender angefordert werden (218), – Authentifizierungsdaten und die den Anwender anzeigenden Daten in der Dienstlogik (220) gespeichert werden, und – der Anwender authentifiziert wird.
Ein Telekommunikationssystem mit einem ersten Teil (SP) zum Erzeugen des Dienstes für den Anwender mittels einer Dienstlogik, und einem zweiten Teil zum Zurverfügungstellen des Dienst (SN, MT) dem Anwender des Dienstes, wobei in dem System der erste Teil (SP) angepasst ist, den den Dienst anfordernden Anwender zu identifizieren und zu verifizieren, ob der Anwender an dem Dienst teilnimmt, und, wenn der Anwender an dem Dienst teilnimmt, den Dienst durch Laden der Dienstlogik in den zweiten Teil (SN, MT) zu erzeugen, der angepasst ist, den Dienst durch Ausführen der geladenen Dienstlogik zur Verfügung zu stellen, und der angepasst ist, den Anwender zu authentifizieren und die Dienstlogik als Antwort auf eine erfolgreiche Authentifizierung auszuführen, dadurch gekennzeichnet, dass der erste Teil (SP) angepasst ist, Authentifizierungsdaten an die Dienstlogik, die geladen wird, zur Anwenderauthentifizierung anzufügen.
System gemäß Anspruch 9, dadurch gekennzeichnet, dass der erste Teil (SP) angepasst ist, die Dienstlogik durch deren Verschlüsselung mit einem mit dem zweiten Teil vereinbarten Verschlüsselungsschlüssel zu signieren, und dass der zweite Teil (SN, MT) angepasst ist, den ersten Teil durch Entschlüsseln der Verschlüsselung der Dienstlogik mit einem dem vereinbarten Schlüssel entsprechenden Schlüssel zu verifizieren und die Dienstlogik nur auszuführen, wenn die Verifizierung auch erfolgreich ist.
Ein System gemäß Anspruch 9 oder 10, dadurch gekennzeichnet, dass das Telekommunikationssystem ein mobiles Telekommunikationssystem (IMT-2000) mit wenigstens einem Dienstanbieter und einem bedienenden Netzwerk ist, dass der erste Teil der Dienstanbieter (SP) ist, und dass der zweite Teil das bedienende Netzwerk (SN) mit wenigstens einem Netzwerkelement (SCN) ist.
System gemäß Anspruch 9 oder 10, dadurch gekennzeichnet, dass das Telekommunikationssystem ein mobiles Kommunikationssystem (IMT-2000) mit wenigsten einem Dienstanbieter (SP) und einem mobilen Endgerät (MT), das mit dem Dienstanbieter durch ein bedienendes Netzwerk (SN) verbunden ist, ist und wobei das mobile Endgerät (MT) zusätzlich zur tatsächlichen mobilen Ausstattung (ME) ein Teilnehmerkennungsmodul (USIM) umfasst, das lösbar mit der mobilen Ausstattung verbunden ist, dass der erste Teil der Dienstanbieter (SP) ist, und dass der zweite Teil die tatsächliche mobile Ausstattung (ME) ist.
Netzwerkelement (SP), dass einen Telekommunikationssystemdienst für einen Anwender erzeugt, das den Dienst mittels einer Dienstlogik erzeugt und Mittel zur Identifizierung des den Dienst anfordernden Anwenders und zum Verifizieren, ob der Anwender an dem Dienst teilnimmt, und zum Laden der Dienstlogik in das Telekommunikationssystem, wenn der Anwender an dem Dienst teilnimmt, umfasst, dadurch gekennzeichnet, dass das Netzwerkelement (SP) Mittel zum Anfügen der Authentifizierungsdaten an die Dienstlogik, die geladen werden, umfasst, sodass der Anwender der Dienstlogik, bevor die Dienstlogik ausgeführt wird, authentifiziert wird.
Netzwerkelement (SP) gemäß Anspruch 13, dadurch gekennzeichnet, dass es Mittel zum Signieren der Dienstlogik, bevor sie in das Netzwerk geladen wird, umfasst.
Netzwerkelement (SP) gemäß Anspruch 13 oder 14, dadurch gekennzeichnet, dass es einen Prozessor umfasst, der eingerichtet ist, Softwareroutinen auszuführen, und dass die Mittel als Softwareroutinen umgesetzt sind.
Vorrichtung eines Telekommunikationssystems, wobei die Vorrichtung Dienstlogik, die Mittel zum Bereitstellen eines Dienstes von einem Dienstanbieter eines Telekommunikationssystems an einen Anwender des Diens tes und Authentifizierungsmittel umfasst, wobei die Dienstlogik, die die Mittel ausführt, angepasst ist, auf die Authentifizierungsmittel zu antworten, dadurch gekennzeichnet, dass die Vorrichtung (SCN, ME) Trennungsmittel zum Trennen angefügter Authentifizierungsdaten eines Anwenders von einer geladenen Dienstlogik umfasst, und dass die Authentifizierungsmittel auf die Trennungsmittel zur Anwenderauthentifizierung antworten.
Vorrichtung (SCN, ME) gemäß Anspruch 16, dadurch gekennzeichnet, dass es Verifizierungsmittel für eine Dienstanbieterverifizierung mittels Verifikationsdaten in der geladenen Dienstlogik umfasst, und dass die Dienstlogikverifikationsmittel angepasst sind, auf die Authentifizierungsmittel zu antworten.
Vorrichtung (SCN, ME) gemäß Anspruch 16 oder 17, dadurch gekennzeichnet, dass sie einen Prozessor umfasst, der eingerichtet ist, Softwareroutinen auszuführen, und dass die Mittel als Softwareroutinen umgesetzt sind.
Vorrichtung gemäß Anspruch 16, 17 oder 18, dadurch gekennzeichnet, dass sie ein Netzwerkelement (SCN) eines mobilen Kommunikationssystem ist, das angepasst ist, als eine Dienstplattform zu funktionieren.
Vorrichtung gemäß Anspruch 16, 17 oder 18, dadurch gekennzeichnet, dass sie die Mobilausstattung (ME) in einem mobilen Kommunikationssystem ist.