<Desc/Clms Page number 1>
Die vorliegende Erfindung betrifft ein Verfahren zum Umwandeln der Ortsinformation von Tar- gets in einem Telekommunikationsnetz in eine ortsbezogene Mehrwertinformation für einen diese anfragenden Requestor mit Hilfe eines Servers zum Bereitstellen der Ortsinformation und einer daran über eine Schnittstelle angeschlossenen Fremdapplikation zum Umwandeln der Ortsinformation in die ortsbezogene Mehrwertinformation, mit den Schritten: wenn der Requestor noch nicht am Server registriert ist, Registrieren eines Requestors am Server, wobei zwischen Requestor und Server ein Passwort übermittelt wird, und wenn der Requestor noch nicht am Target angemeldet ist, Anmelden des Requestors über Vermittlung des Servers an einem Target als Ortsinformationsberechtigter, wobei der Server dieser Beziehung eine neue Beziehungskennung zuteilt und die Beziehungskennung an den Requestor sendet.
Auf Ortsinformationen basierende Dienste in Telekommunikationsnetzen, sogenannte "location based Services", sind ein Wachstumsgebiet der m-commerce-Industrie. Beispielsweise wurden für Mobiltelephonnetze nach dem GSM-Standard bereits einheitliche Standards für Location Based Services vorgeschlagen, siehe die 3GPP-Spezifikationen TS 22. 071 V6. 6.0 und TS 23. 271 V6.6.0.
Dem Schutz der Privatsphäre des Teilnehmers ("target" bzw. "presentity"), dessen Ortsinforma- tion überwacht bzw. von einem anderen Teilnehmer ("requestor" bzw. "watcher") angefragt werden soll, kommt dabei vordringliche Bedeutung zu. Vorschläge zur Lösung dieser Daten- schutzproblematik sind z. B. für GSM-Netze in den 3GPP-Dokumenten Tdoc SP-020379 und Tdoc S2-021104 enthalten und umfassen Berechtigungsmechanismen in der Disposition des Targets, um Überblick und Kontrolle über die daran angemeldeten ("abonnierten") Requestoren zu erlangen ; Verwendung von Passwörtern in der Anmeldebeziehung zwischen Requestor und Target ; die Ersetzung der Teilnehmerkennung des Targets (z. B. seiner MSISDN) durch eine anonymisierte Kennung, um die Anonymität des Targets gegenüber dem Requestor zu gewährleisten.
Verfahren der letzteren Art sind beispielsweise in den Schriften WO 2003/065753 A1, WO 2002/047349 A2, EP 1 126 732 A2 und WO 2002/067089 A2 beschrieben. Die WO 2003/065753 A1 schlägt vor, die anonymisierte Kennung aus einer Hashfunktion der Teil- nehmerkennung des Targets (z. B. seiner MSISDN) oder einem Vorrat von Einmal-Kennungen zu generieren. Entsprechend der WO 2002/047349 A2 wird eine bevorzugt einmalgültige Teil- nehmerkennung mittels symmetrischer oder asymmetrischer Verschlüsselungsverfahren ano- nymisiert. Gemäss der EP 1 126 732 A2 wird durch Anwendung eines Zufallsprozesses eine temporäre anonymisierte Kennung erzeugt und in einer Konkordanztabelle der Teilnehmerken- nung zugeordnet.
Die Schrift WO 2002/067089 A2 beschreibt schliesslich die einer Bildung anonymisierten Kennung, welche für die Dauer einer aufrechten Verbindung zwischen Re- questor und Server gültig ist.
Die bekannten Datenschutzmechanismen funktionieren jedoch nur in geschlossenen Telekom- munikationsnetzen, in welchen der zwischen Requestor und Target vermittelnde Server des Telekommunikationsnetzes ("location Server") autark nach diesen Regeln arbeiten kann.
Neuere gesetzliche Anforderungen verpflichten Netzbetreiber in zunehmendem Masse, die Schnittstellen ihrer Netzknoten aus Wettbewerbsgründen für Dritte zugänglich zu machen, darunter auch die ihrer Location Server. Dafür wurden verschiedene offene Schnittstellen ge- schaffen, wie OSA- oder PARLAY-Schnittstellen.
Mit der Schaffung offener Schnittstellen für Dritte wurden in letzter Zeit auch Dienste angedacht, bei welchen Dritte ihre Rechner bzw. Applikationen ("Fremdapplikationen") über eine offene Schnittstelle an den Location Server anschalten, um Ortsinformationen von Targets abzurufen und daraus Mehrwertinformationen zu erzeugen. Beispiele solcher ortsbezogener Mehrwertin- formationen sind die Darstellung von Landkarten, auf denen die Targets eingezeichnet sind
<Desc/Clms Page number 2>
(Flottenmanagement, Flottenverfolgung), das Suchen und Anzeigen von ortsabhängigen "points of special interest" (Tankstellen, Bankomaten) usw.
Ein derartiges Szenario ist in Fig. 1 gezeigt. Ein Target B ist in einem Telekommunikationsnetz T an einem Location Server LS angemeldet. Der Location Server LS verfügt über die Ortsinformation locB des Targets B, wie es dem Vertrauensverhältnis zwischen dem Benutzer des Targets B und dem Betreiber des Telekommunikationsnetzes T entspricht.
Über einen Berechtigungsvorgang "subscribe" kann das Target B einem weiteren Teilnehmer, dem Requestor A, die Berechtigung zum Empfang seiner Ortsinformation locB erteilen. Die Berechtigung kann eine Einmalberechtigung oder eine Berechtigung für einen längeren Zeitraum sein ("tracking and tracing").
Der Requestor A kann sich in einem beliebigen anderen Telekommunikationsnetz befinden, es ist aber auch möglich, dass die Rollen von Requestor A und Target B von ein und demselben Endgerät im Telekommunikationsnetz T eingenommen werden, z. B. dem Mobiltelephon eines Benutzers.
Das Vertrauen, welches das Target B dem Requestor A (z.B. "sich selbst", wenn in ein und demselben Endgerät beheimatet) entgegenbringt, wird einer beliebigen anderen Fremdapplikation AS, die über eine offene Schnittstelle OI an den Location Server LS angeschlossen ist, in der Regel nicht entgegengebracht. In dem gezeigten Szenario möchte der Requestor A dennoch ortsbezogene Mehrwertinformation dataB bezüglich des Targets B von der Fremdapplikation AS berechnen lassen, ohne dieser die Ortsinformation locB des Targets B mitteilen oder eine eigene Berechtigung erteilen zu müssen.
Die Erfindung setzt sich zum Ziel, in einem solchen Szenario ein Verfahren zum Umwandeln der Ortsinformation des Target in eine ortsbezogene Mehrwertinformation mit Hilfe einer Fremdapplikation zu schaffen, welches Anonymität und Nicht-Verfolgbarkeit der Ortsbewegungen der Targets B gegenüber der Fremdapplikation AS gewährleistet. Das Verfahren soll hohe kryptographische Sicherheit bieten, aber gleichzeitig nur geringe Rechenleistung erfordern, um auch mit kleinen Benutzerendgeräten, wie Mobiltelephone begrenzter Rechenleistung, praktisch durchführbar zu sein.
Diese Ziele werden mit einem Verfahren der einleitend genannten Art erreicht, welche sich gemäss der Erfindung auszeichnet durch die Schritte: Generieren einer neuen Abfragekennung als Funktion aus - beim ersten Mal - der Beziehungskennung oder - bei einem weiteren Mal - der letzten Abfragekennung und aus dem Passwort, und zwar sowohl im Requestor als auch im Server, wobei der Server die Abfragekennung über die Beziehungskennung dem Target zuordnet und speichert, Senden einer Mehrwertinformationsabfrage bezüglich des Targets vom Requestor an die Fremdapplikation, wobei das Target durch die Abfragekennung referenziert wird, Senden einer Ortsinformationsabfrage bezüglich des Targets von der Fremdapplikation an den Server, wobei das Target durch die empfangene Abfragekennung referenziert wird,
Ermitteln des Targets und seiner Ortsinformation aus der empfangenen Abfragekennung und den gespeicherten Zuordnungen im Server und Zurücksenden der Ortsinformation unter der Abfragekennung an die Fremdapplikation, Umwandeln der empfangenen Ortsinformation in die ortsbezogene Mehrwertinformation durch die Fremdapplikation und Zurücksenden der Mehrwertinformation an den Requestor, und Empfangen der Mehrwertinformation im Requestor als angefragte Mehrwertinformation des Targets.
Die Erfindung beruht auf der überraschenden Erkenntnis, dass aus dem bei der Anmeldung des Requestors am Server verfügbaren Passwort und der für eine Berechtigungsbeziehung zwischen Requestor A und Target B zugeteilten Sitzungs- bzw. Beziehungskennung eine kryp-
<Desc/Clms Page number 3>
tographisch ausreichend sichere Kette von variierenden Abfragekennungen ("EinmalPasswörtern") erzeugt werden kann. Die Fremdapplikation erfährt in jeder Mehrwertinformationsabfrage - selbst wenn diese sich auf ein und dasselbe Target B bezieht - eine jeweils andere Abfragekennung, sodass sie daraus weder auf die Identität des Targets B schliessen noch nicht einmal ein Bewegungsprofil eines bestimmten, wenn auch unbekannten Targets B erstellen kann. Anonymität und Nicht-Verfolgbarkeit des Targets B gegenüber der Fremdapplikation AS sind dadurch vollständig gewährleistet.
Darüber hinaus erfordert das Verfahren der Erfindung keine komplizierten Verschlüsselungsmechanismen wie private-public-key-Verschlüsselungen, da die zu berechnende Funktion bloss jeweils eine neue Verknüpfung zwischen der letzten Abfragekennung und dem Passwort durchführen muss. Das Verfahren der Erfindung ist daher für Benutzerendgeräte mit geringer Rechenleistung besonders geeignet, wie Mobiltelephone, PDAs ("personal digital assistants"), Smartphones usw.
Eine besonders bevorzugte Ausführungsform der Erfindung zeichnet sich dadurch aus, dass als genannte Funktion eine Hashfunktion, bevorzugt vom Typ SHA-1 oder MD5, verwendet wird.
Eine Hashfunktion y = H (x) definiert als jene Funktion, für welche der Aufwand zur Berech- nung von x, bei einem Ergebnis y mit n Bits, im Durchschnitt 2n-1 Versuche erfordern würde.
Hashfunktionen sind damit zwar einfach zu berechnen, jedoch bei entsprechender Wahl von n praktisch nicht umkehrbar. Hashfunktionen sind ferner kollisionsresistent, d. h. der Aufwand,
EMI3.1
erfordern.
Bevorzugte Hashfunktionen sind die Hashfunktion MD5 von Ronald L. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992, sowie die Hashfunktion SHA-1 des National Institute of Standards and Technology, "Secure Hash Standard", Mai 1993, Federal Information Processing Standards (FIPS) Publikation 180-1. Diese Funktionen bieten hohe kryptographische Sicherheit bei geringem Rechenleistungsbedarf.
Die Datenschutzsicherheit des Verfahrens kann noch weiter erhöht werden, wenn bevorzugt die Beziehungskennung idAB auf einer Zufallszahl basiert.
Gemäss einer weiteren vorteilhaften Ausführungsform des Verfahrens der Erfindung kann vorgesehen werden, dass der Server, wenn er eine Veränderung der Ortsinformation des Targets feststellt, die neue Ortsinformation unter der Abfragekennung an die Fremdapplikation sendet, welche die empfangene neue Ortsinformation in die ortsbezogene Mehrwertinformation umwandelt und an den Requestor sendet. Auf diese Weise können z. B. die Fremdapplikation und/oder der Requestor auf Ortsveränderungen des Targets reagieren, ein Bewegungsprofil des Targets erstellen, usw.
Die Erfindung wird nachstehend anhand eines in den beigeschlossenen Zeichnungen dargestellten Ausführungsbeispieles näher erläutert. In den Zeichnungen zeigt Fig. 1 das bereits erörterte Szenario des Standes der Technik in Blockschaltbildform, und Fig. 2 das Verfahren der Erfindung im Rahmen dieses blockschaltbildlich dargestellten Szenarios, wobei die Schritte des Verfahrens numeriert eingetragen sind.
In Fig. 2 entsprechen die Komponenten Telekommunikationsnetz T, Target B, Server LS, Schnittstelle OI, Requestor A und Fremdapplikation AS den gleichnamigen Komponenten in Fig. 1 und es wird auch die obige Erörterung von Fig. 1 verwiesen.
Der Ablauf des Verfahrens wird nun anhand von Fig. 2 näher erläutert.
<Desc/Clms Page number 4>
In einem ersten Schritt 1a registriert sich der Requestor A beim Server LS, wobei er im Zuge der Registrierung ein Passwort pwA an den Server LS sendet.
Bei der Registrierung im Schritt 1a kann das Passwort pwA auf beliebige Art und Weise in das System gelangen, beispielsweise vom Benutzer am Benutzerendgerät, das die Rolle des Requestors A einnimmt, frei eingegeben werden, oder vom Betreiber des Servers LS zugeteilt werden ; wesentlich ist lediglich, dass das Passwort pwA ein nur von Requestor A und Server LS geteiltes Geheimnis ("shared secret") ist.
Nach erfolgreicher Registrierung kann sich der Requestor A im Schritt 1 b jederzeit für eine Sitzung am Server LS authentifizieren, beispielsweise durch verschlüsselte Übermittlung des Passwortes pwA im Zuge einer Sitzungsanmeldung ("logon") des Requestors A am Server LS.
Im einfachsten Fall könnte der Schritt 1 b jedoch auch entfallen.
Sowohl der Requestor A als auch der Server LS haben somit für den gesamten weiteren Ablauf des Verfahrens, gegebenenfalls auch darüber hinaus, Kenntnis über das Passwort pwA.
Das Target B meldet sich seinerseits - vor, zwischen oder nach den Schritten 1 a oder 1 b - in einem Schritt 1c am Server LS an. Ab diesem Zeitpunkt hat der Server LS Kenntnis über den
EMI4.1
ermitteln. Wenn das Telekommunikationsnetz T beispielsweise ein Mobiltelephonnetz ("public land mobile network", PLMN) nach dem GSM-Standard ist, kann die Ortsinformation locB z. B. aus der Zelleninformation der Funkzelle ermittelt werden, in, welcher sich das Target B befindet.
Das Target B könnte sich jedoch auch an einem festen Ort in einem FestnetzTelekommunikationssystem befinden, z. B. dem Telephonfestnetz ("public switched telephone network", PSTN), in welchem Fall die Ortsinformation locB auch durch blosse Identifikation der Anschlussleitung des Targets B ermittelt werden könnte. Weitere Beispiele von Telekommunikationsnetzen T, in denen sich das Target B und/oder der Requestor A befinden können, sind UMTS-Telekommunikationsnetze, Datennetze, das Internet usw.
In einem zweiten Schritt 2a meldet sich der Requestor A über Vermittlung des Servers LS am Target B als Berechtigter zum Empfang von Ortsinformationen an und das Target B akzeptiert bzw. bestätigt dies im Schritt 2b. Ab diesem Zeitpunkt besteht eine Berechtigungsbeziehung zwischen Requestor A und Target B, welcher der vermittelnde Server LS eine Beziehungskennung idAB zuteilt. Der genaue Ablauf der Errichtung dieser Beziehung ist beispielsweise für GSM-Netze in den einleitend genannten Spezifikationen beschrieben.
Die der Berechtigungsbeziehung A-B zugeteilte Beziehungskennung idAB teilt der Server LS im Schritt 2b auch dem Requestor A mit, sodass ab diesem Zeitpunkt sowohl der Requestor A als auch der Server LS über die Beziehungskennung idAB verfügen.
Die Beziehungskennung idAB kann einfach der im Server LS zugeteilten Sitzungskennung ("ses- sion id") für diesen Prozess entsprechen ; wird sie aber mit Hilfe einer Zufallszahl verschlüsselt, beispielsweise in der Form idAB = SitzungskennungAB + Zufallszahl Zwischen Schritt 1 a/1 b/1 c und Schritt 2a/2b tritt in der Praxis ein beliebiger Zeitabstand auf.
Ferner kann ein Requestor A auch mehrere Berechtigungsbeziehungen zu verschiedenen Targets B unterhalten.
Aus dem Passwort pwA und der Beziehungskennung idAB generieren nun im Schritt 3 sowohl der Requestor A als auch der Server LS jeweils unabhängig voneinander eine Abfragekennung hn zur Kommunikation mit der Fremdapplikation AS, und zwar in der folgenden Art und Weise:
<Desc/Clms Page number 5>
Beim ersten Mal, wenn noch keine Beziehungskennung hn erzeugt worden ist, wird die erste Beziehungskennung h1 mit Hilfe einer Hashfunktion H aus einer Kombination von Beziehungskennung idAB und Passwort pwA erstellt als h1 = H (idAB + PWA) Als Hashfunktionen H eignen sich insbesondere die genannten Hashfunktionen vom Typ MD5 oder SHA-1.
Sobald die erste Abfragekennung h1 berechnet worden ist, werden alle weiteren Abfragekennungen hn - sei es vorab auf "Vorrat" oder jeweils nach Bedarf, d. h. wenn eine Kommunikation mit der Fremdapplikation AS gewünscht ist (siehe unten) - aus einer Kombination von letzter Abfragekennung hn-1 und Passwort pwA generiert zu
EMI5.1
Die einzelnen Abfragekennungen hi, h2 .. hn stellen eine Kette von aufeinanderfolgenden variierenden "Einmal-Passwörtern" dar, wie in der Technik bekannt, siehe beispielsweise N. Haller, C.
Metz, P. Nesser, M. Straw, IETF RFC 2289, "A One-Time Password System".
Anschliessend speichert der Server LS im Schritt 3 eine Zuordnung zwischen der Abfragekennung hn und dem Target B (bevorzugt auch dem Requestor A, wenn der Server LS Anfragen verschiedener Requestoren A erhält) in einer entsprechenden Tabelle. Die Tabelle kann jeweils nur die neueste Abfragekennung hn enthalten, oder z. B. eine ganze Kette von im Voraus berechneten Abfragekennungen h1 .. hn.
Auch im Requestor A kann die Zuordnung zwischen Abfragekennung hn und Target B gespeichert werden, wenn der Requestor A Beziehungen zu verschiedenen Targets B unterhält.
Im Schritt 4 sendet der Requestor A eine Abfrage reqdata (hn) an die Fremdapplikation AS, um von dieser eine ortsbezogene Mehrwertinformation dataB bezüglich des Targets B zu erhalten, ohne der Fremdapplikation AS eine verfolgbare Identität des Targets B mitzuteilen.
Zu diesem Zweck sendet der Requestor A die für das Target B zuletzt erzeugte Abfragekennung hn an die Fremdapplikation AS. Die Fremdapplikation AS sendet im Schritt 5 eine Anfrage reqloc (hn) an den Server LS, um die der Abfragekennung hn zugeordnete Ortsinformation des Targets B zu erhalten. Im Schritt 6 ordnet der Server LS anhand der gespeicherten Zuordnungen die empfangene Abfragekennung hn dem Target B zu und ermittelt mit Hilfe in der Technik bekannter Verfahren die Ortsinformation locB (soferne nicht bereits verfügbar) des Targets B. Im Schritt 7 sendet der Server LS die Ortsinformation locB unter der Abfragekennung hn an die Fremdapplikation AS zurück.
Die Fremdapplikation AS ermittelt aufgrund der Ortsinformation loc(hn) eine zugehörige ortsbe-
EMI5.2
unter der Abfragekennung hn zurück.
Der Requestor A ordnet im Schritt 9 die empfangene Abfragekennung hn, wenn erforderlich, anhand gespeicherter Zuordnungen, dem Target B zu, sodass im Schritt 10 die ortsbezogene Mehrwertinformation dataB des Targets B zur Verfügung steht.
Die Erfindung ist nicht auf die dargestellten Ausführungsbeispiele beschränkt, sondern umfasst alle Varianten und Modifikationen, die in den Rahmen der angeschlossenen Ansprüche fallen.
So könnte beispielsweise eine im Voraus berechnete Hash-Kette von Abfragekennungen h, .. hn auch in umgekehrter Abfragefolge hn ..h1 verwendet werden. Anstelle von mehrdeutigen Funktionen bzw. Hashfunktionen könnte im einfachsten Fall auch eine blosse Verknüpfungsfunk-
<Desc/Clms Page number 6>
tion zur Verknüpfung von Beziehungskennung bzw. Abfragekennung und Passwort eingesetzt werden. Das Verfahren kann auch von der gezeigten "pull"-Variante zu einer #push"-Variante modifiziert werden, in welcher der Server LS aktiv die Ortsinformation des Targets B unter der Abfragekennung hn an die Fremdapplikation AS sendet, sobald das Targets B seinen Ort ver- ändert, so dass die Fremdapplikation AS z.
B. ein Bewegungsprofil generieren oder ihrerseits aktiv die zugeordnete Mehrwertinformation an den Requestor A senden kann.
Patentansprüche: 1. Verfahren zum Umwandeln der Ortsinformation (locB) von Targets (B) in einem Telekom- munikationsnetz (T) in eine ortsbezogene Mehrwertinformation (dataB) für einen diese an- fragenden Requestor (A) mit Hilfe eines Servers (LS) zum Bereitstellen der Ortsinformation und einer daran über eine Schnittstelle (OI) angeschlossenen Fremdapplikation (AS) zum
Umwandeln der Ortsinformation in die ortsbezogene Mehrwertinformation, mit den Schrit- ten :
wenn der Requestor noch nicht am Server registriert ist, Registrieren eines Requestors (A) am Server (LS), wobei zwischen Requestor und Server ein Passwort (pwA) übermittelt wird, und wenn der Requestor noch nicht am Target angemeldet ist, Anmelden des Requestors (A) über Vermittlung des Servers (LS) an einem Target (B) als Ortsinformationsberechtigter, wobei der Server (LS) dieser Beziehung eine neue Beziehungskennung (idAB) zuteilt und die Beziehungskennung an den Requestor (A) sendet, gekennzeichnet durch die Schritte:
Generieren einer neuen Abfragekennung (hn) als Funktion (H) aus - beim ersten Mal - der
Beziehungskennung (idAB) oder - bei einem weiteren Mal - der letzten Abfragekennung (hn-i) und aus dem Passwort (pwA), und zwar sowohl im Requestor (A) als auch im Server (LS), wobei der Server (LS) die Abfragekennung (hn) über die Beziehungskennung (idAB) dem Target (B) zuordnet und speichert,
Senden einer Mehrwertinformationsabfrage (reqdata(hn)) bezüglich des Targets (B) vom
Requestor (A) an die Fremdapplikation (AS), wobei das Target (B) durch die Abfrageken- nung (hn) referenziert wird,
Senden einer Ortsinformationsabfrage (reqloc(hn)) bezüglich des Targets (B) von der
Fremdapplikation (AS) an den Server (LS), wobei das Target (B) durch die empfangene
Abfragekennung (hn) referenziert wird,
Ermitteln des Targets (B)
und seiner Ortsinformation (locB) aus der empfangenen Abfrage- kennung (hn) und den gespeicherten Zuordnungen im Server (LS) und Zurücksenden der
Ortsinformation unter der Abfragekennung (hn) an die Fremdapplikation (AS),
Umwandeln der empfangenen Ortsinformation (loc(hn)) in die ortsbezogene Mehrwertin- formation (data(hn)) durch die Fremdapplikation (AS) und Zurücksenden der Mehrwertin- formation an den Requestor (A), und
Empfangen der Mehrwertinformation im Requestor (A) als angefragte Mehrwertinformation (dataB) des Targets (B).