Datenschutz in lokationsbasierten Diensten Jürgen Czerny Universität Karlsruhe (TH) Zusammenfassung. Fortschritte in der mobilen Positionsbestimmung bieten die Möglichkeit auf mobilen Geräten eine neue Art von Dienst anzubieten: sogenannte lokationsbasierte Dienste. Diese verwenden ortsund personenspezifische Daten um dem Endbenutzer ein auf ihn und seine Position zugeschnittenes Informationsangebot oder einen anderen Dienst zu präsentieren. Allerdings führt das Mitteilen von orts- und personenspezifischen Daten dazu, dass ein Nutzer eines solchen Dienstes sehr leicht nachverfolgbar wird. Dieses Seminarthema beschäftigt sich mit Datenschutz in diesem Anwendungsgebiet. Zunächst wird die Besonderheit der lokationsbasierten Dienste im Bezug auf Datenschutz behandelt und die Methode der Anonymisierung des Endbenutzers betrachtet. Ein kurzer Anriss ist der Problematik bei kontinuierlichen Abfragen, welche nicht in dieser Seminararbeit ausführlich behandelt werden kann, gewidmet. Es folgen verschieden Verfahren, die von drei unterschiedlichen Standpunkten aus zentralisiert, peer-to-peer und eigenständig diese Anonymisierung realisieren. Die Zusammenfassung geht kurz auf die Bedeutung des Behandelten ein und verweist auf verwandte Themen. 1 Einführung Die zunehmende Verwendung von GPS und anderen Methoden zur Positionsbestimmung gerade im Bereich von mobilen Kommunikationsgeräten (Mobiltelefone, PDAs, etc.) ermöglicht eine neue Art von Dienst: den Lokationsbasierten Dienst (LBS). Bei diesem ermittelt der Endbenutzer, meist vollautomatisiert, seine aktuelle Position und sendet diese mit seiner, vom Dienst festgelegten, Anfrage mit. Der Dienst verwendet dann die Positions- wie auch die Zeitangaben, um dem Endbenutzer eine bereits selektierte Auswahl von Informationen zur Verfügung zu stellen. Dies kann eine Suche nach dem nächsten Restaurant oder der nächsten Tankstelle sein, aber auch eine Vielzahl von anderen Diensten umfassen. Lokationsbasierte Dienste können ihre Anwendung in der Verkehrsplanung und -auskunft finden, wobei hier nur die für den Benutzer gerade relevanten Daten berücksichtig werden. Aber gerade im Zusammenspiel mit ubiquitären Systemen 1 zeigen lokationsbasierte Dienste eine wahre Fülle von Möglichkeiten. Denkbar wäre z.b. eine von einer Kreuzung automatisiert erhobenen Unfallstatistik oder auch eine pay-as-you-drive Versicherung, welche ihren Beitrag 1 Systeme, die mit Alltagsgegenständen verschmelzen, um den Gegenstand und nicht das informationsverarbeitende System in den Vordergrund zu stellen.
2 abhängig von Fahrstil und Regelmäßigkeit der Benutzung errechnet. Einen bereits bestehenden lokationsbasierten Dienst möchte ich zur weiteren Veranschaulichung kurz detaillierter darstellen. NavXS steht für Navigation Exchange Service [5] und stellt in etwa einen Instant Messaging Dienst dar, den man von seinem Mobiltelefon aus verwenden kann. Was diesen Dienst nun als lokationsbasierten Dienst qualifiziert, ist, dass ein Anwender mit NavXS nicht nur sehen kann, wann bestimmte andere Personen online sind, sondern auch wo sie sich gerade befinden. Dadurch können z.b. spontane Treffen in einem Café in der Innenstadt oder ähnliche Zusammentreffen entstehen. Was jedoch an diesem Beispiel auch zu erkennbar wird ist, dass es dadurch sehr leicht wird eine Person zu verfolgen, oder Auskunft über deren Position zu erlangen. Dies ist eine Problematik, die allen lokationsbasierten Diensten innewohnt. Durch die Orts- und Zeitdaten, die bei jeder Anfrage an den Dienstgeber übermittelt werden, können Dritte leicht Angriffe auf die Privatsphäre der Dienstnutzer starten. Ist einmal die Verbindung von einem Gerät zu dessen Besitzer hergestellt, wird es einfach diese Person zu stalken oder aufgrund ihrer Aufenthaltsorte Rückschlüsse über Zugehörigkeit zu Gruppierungen oder andere private Informationen zu erlangen. Erkundigt sich beispielsweise ein Nutzer einer lokationsbasierten Busauskunft öfters von einem Krankenhaus aus über Verbindungen, so kann jemand, der diese Daten sammelt, darauf schließen, dass diese Person vielleicht an einer Krankheit leidet, die ihn zwingt regelmäßig ins Krankenhaus zu gehen. Stimmen die Orts- und Zeitangaben mit den Treffen einer politischen oder religiösen Vereinigung überein, so ist anzunehmen, dass die Person dieser Vereinigung angehört. 2 Datenschutz in lokationsbasierten Diensten Die einleitenden Beispiele machen deutlich, dass es im Interesse des Datenschutzes ist, keine orts- bzw. zeitspezifischen Informationen weiterzuleiten. Je weniger über die aktuelle Position bekannt ist, desto weniger Rückschlüsse können über eine Person angestellt werden. Dies wiederum hat zur Folge, dass es schlechter möglich wird den lokationsbasierten Dienst zu nutzen, denn je weniger der Dienst über die Position des Nutzers weiß, desto weniger genaue Informationen kann er dem Nutzer zur Verfügung stellen. Ein hoher Grad an Privatsphäre verringert also die Dienstqualität, während eine hohe Dienstqualität die Privatsphäre verringert. Dieses Dilemma ist inhärent für lokationsbasierte Dienste. Um nun doch lokationsbasierte Dienste nutzen zu können, ohne zuviel über seine Person preiszugeben ist ein Kompromiss notwendig. Der Anwender opfert sozusagen einen Teil der Dienstqualität der Privatsphäre, indem er dem Dienstgeber nicht mehr genau mitteilt, wo er sich befindet sondern nur eine Näherung angibt. Der Dienstgeber im Gegenzug teilt dem Anfragesteller nicht mehr das eine nächste Restaurant mit, sondern gibt diesem eine Liste von Restaurants, welche sich in der Umgebung der Näherung befinden.
3 Anonymität In einem Vorschlag über Terminologie zu diesem Gebiet formulieren Pfitzmann und Köhntopp: Anonymity is the state of being not identifiable within a set of subjects, the anonymity set. [1] Ein Nutzer gilt demnach als anonym, wenn er nicht mehr unterscheidbar von einer Menge anderer Nutzern ist. Anonymität ist also ein sehr geeigneter Mechanismus um Datenschutz im Umfeld von LBSen zu gewährleisten. Dadurch, dass der Anwender seine orts- und zeitspezifischen Daten derart verändert, dass sie nicht mehr nur auf ihn alleine, sondern auf eine hinreichend große Menge an Personen zutrifft, erreicht er, dass ein Angreifer sich nicht sicher sein kann zu welcher Person die Daten gehören. Somit werden unlautere Rückschlüsse auf die Person verhindert. Die Größe der Anonymisierungsmenge spielt dabei jedoch eine entscheidende Rolle. Wählt der Benutzer sie zu klein, und verändert seine Daten nur geringfügig, so kann ein Angreifer mit wenigen Zusatzinformationen den Anfragesteller dennoch eindeutig identifizieren. Wählt der Anwender die Anonymisierungsmenge hingegen zu groß so tendiert er zum anderen bereits erwähnten Extrem, bei welchem die Qualität des Dienstes erheblich leidet. Aus diesem Grund empfiehlt sich die Verwendung des Qualitätsmaßes der k- Anonymität, welches von Samarati und Sweeney [12] eingeführt wurde. Etwas gilt als k-anonym, wenn es nicht mehr von k 1 anderen Dingen unterschieden werden kann. Anonymität wird erreicht, indem man die Ortsdaten der Anfrage verändert, in den meisten Fällen bedeutet das eine Verallgemeinerung. Der Nutzer gibt nicht mehr die genaue Hausnummer in der Straße an, an der er sich gerade befindet sondern nur noch die Straße. Die Möglichkeit die Daten zu verallgemeinern um Anonymität zu erlangen, ist allerdings nicht nur auf die Ortsdaten beschränkt sondern auch bei Zeitdaten gegeben. Hierbei lassen sich die Daten jedoch nicht so einfach, wie bei dem vorangegangen Beispiel, verallgemeinern, da der Dienst ja problemlos feststellen kann, wann ihn die Anfrage erreicht hat. Es ist also notwendig dass das Verfahren die Anfrage ein wenig zu verzögert bevor es sie an den Dienst leitet und zwar solange bis eine bestimmte Anzahl an Personen dieselbe Stelle betreten haben. Die zeitliche Verallgemeinerung wird also durch den Zeitpunkt der Anfrageerstellung und den Zeitpunkt der Zustellung bestimmt. Es leuchtet ein, dass eine Kombination aus Verallgemeinerung von Orts- und Zeitdaten die gleiche k-anonymität bei geringerem Verlust von Dienstqualität erzeugen kann und im Allgmeinen auch tut. Angreifermodell Genau wie bei anderen Diensten gibt es unterschiedliche Zielsetzungen mit denen man LBSe angreifen kann. Ein Angreifer kann einerseits versuchen den Dienst zu stören, so dass er dem Anwender nicht mehr zur Verfügung steht. Er kann jedoch auch versuchen den Dienst zu infiltrieren so dass er im laufenden Betrieb des Dienstes die positionsbezogenen Daten des Anwenders erlangt. Da ein vom Anwender unbemerktes Mithören der Positionsdaten eine größere Gefahr für die
4 Privatsphäre eines jeden Anwenders darstellt wird die letztere Zielsetzung, im Gegensatz zur ersten, in dieser Seminararbeit genauer betrachtet. Im Hinblick auf die im Folgenden vorgestellten Verfahren stehen Angreifern ein paar unterschiedliche Strategien zur Verfügung um an positionsbezogene Daten zu gelangen: 1. Es ist es möglich die Kommunikation des Anwenders abzuhören, bevor diese z.b. von einem Anonymisierungsdienst verändert wurde. Diese Herangehensweise scheint im Besonderen bei zentralen Verfahren vielversprechend. 2. Der Angreifer kann sich als Anonymisierungsdienst ausgeben und so den Anwender täuschen. Offensichtlich hat diese Strategie auch nur bei einem zentralen Verfahren Sinn, da es bei dezentralen Verfahren keinen Anonymisierungsdienst gibt. 3. Indem sich ein Angreifer als Peer ausgibt, kann er bei dezentralen Verfahren seine Zielsetzung erreichen. 4. Ein Angreifer kann sich als Anbieter eines LBSs ausgeben, um an die Positionsdaten des Anwenders zu gelangen. Dies ist durch Auswerten bestimmter Daten der Anfrage möglich. Mittels Verfahren, die die genaue Ankunftszeit des Signals (TOA 2 und TDOA 3 ) und dessen ungefähre Richtung (DOA 4 ) feststellen können, kann der Anwender unter Umständen trianguliert werden. Herausforderungen Soll ein Verfahren wirkungsvoll und effizient Datenschutz im Kontext von LBSen ermöglichen, so muss es eine Reihe von Herausforderungen meistern. Diese ergeben sich aus der besonderen Situation, welche durch LBSe gegeben ist. Diese Herausforderungen sind: Angriffsfläche Die Angriffsfläche, die ein Verfahren aufweist, ist wesentlich im Bezug auf die Anfälligkeit des Verfahrens gegenüber den schon beschriebenen Angriffsmodellen. Für ein Verfahren ist es wichtig die verschiedenen Angriffsmöglichkeiten, die bestehen, zu minimieren. Kommunikationsaufwand Diese Herausforderung ist äußerst wichtig im Sinne der Performanz des Verfahrens. Ein deutlicher Mehraufwand an Kommunikation verlangsamt den kompletten Dienst und wirkt sich in Gegenden mit hoher Nutzerdichte noch einmal zusätzlich bremsend aus, da ein Mehr an Kommunikation die Kapazitäten des Kommunikationsmediums für Nutzdaten verringert. Von Relevanz ist hierbei die Kommunikation, welche zwischen den Nutzern untereinander und dem Dienstgeber bzw. gegenüber einer Drittpartei auftritt. 2 Time-of-Arrival 3 Time Difference of Arrival 4 Direction of Arrival
5 Nutzerdichte Anonymisierung lässt sich leichter in Gebieten mit hoher Nutzerdichte erreichen. Es muss weniger Dienstqualität geopfert werden, da kleinere Zeit- und Ortsintervalle ausreichen um k-anonym zu werden. Funktionsfähigkeit in Gebieten mit geringer Nutzerdichte ist hingegen schwieriger und muss daher als Herausforderung gezählt werden. Rechenaufwand Ein weiterer Faktor, der sich direkt auf die Performanz des Verfahrens auswirkt ist der Rechenaufwand dessen. Gerade auf den mobilen Endgeräten, welche nur beschränkte Ressourcen zur Verfügung haben, ist ein geringer Rechenaufwand daher wichtig. Bei zentralen Strukturen ist ein hoher Rechenaufwand eher zu vertreten, da diese im Prinzip uneningeschränkte Ressourcen nutzen können. Sequenzverhalten Abfragesequenzen bzw. kontinuierliche Abfragen können dazu führen, dass eine Person, obwohl sie bei jeder einzelnen Abfrage k- anonym ist, identifiziert werden kann. Vor allem wenn sich die Person auf eine für die Menge untypische Weise verhält. Skalierbarkeit Skalierbarkeit ist ein äußerst wesentlicher Punkt zur Bewertung, ob das Verfahren praxistauglich ist. Verfahren, die den Datenschutz in LBSen verwirklichen müssen in der Lage sein mit einer Vielzahl von Nutzern und Anfragen umzugehen und daher in diesem Bereich gut skalierbar sein. Diese Herausforderungen sind für die Bewertung einzelner Verfahren sehr gut geeignet. Beim Sequenzverhalten handelt es sich allerdings um eine sehr umfangreiche Herausforderung und wird daher nicht zur Bewertung der folgenden Verfahren herangezogen. Stattdessen wird hier kurz auf die Problematik eingegangen und auf weiterführende Arbeiten verwiesen. Abfragesequenzen Kontinuierliche Abfragen sind rasch und regelmäßig aufeinanderfolgende Abfragen, die in etwa den selben Inhalt haben. Ein lokationsbasierter Fahrtenplaner zum Beispiel muss regelmäßig Anfragen wegen der Verkehrslage starten, um den Fahrer um Staus herum lotsen zu können. Für den Datenschutz bergen diese Sequenzen eine nicht zu vernachlässigende Problematik, denn die Abfragen kann ein Angreifer aufgrund des Inhalts als zusammengehörig identifizieren. Man kann dies mit einer Spur aus Brotkrumen vergleichen. Bei kontinuierlichen Abfragen erhält ein Angreifer erhebliche Zusatzinformationen, nämlich die Bewegungsrichtung des Anfragestellers. Mittels dieser kann der Angreifer vor allem wenn sich das Umfeld anders als das Ziel bewegt den Kandidatenkreis, welcher für den Anfragesteller in Frage kommt, stark einschränken. So weit sogar, dass er die Person wieder eindeutig identifizieren kann. Die hier vorgestellten Verfahren sind nicht in der Lage eine Nachverfolgbarkeit anhand der Abfragespur vollständig zu verhindern. Einzig die Anonymisierung durch Dummies (siehe Abschnitt 3.3) bietet Schutz bei Sequenzverhalten, da sich die Dummies gezwungenermaßen mit dem Anfragesteller bewegen. Es ist also notwendig weitere Konzepte in die Verfahren, die eine genaue Lokalisierung trotz kontinuierlicher Abfragen verhindern, zu integrieren. Da dies aber den Rahmen dieser Arbeit sprengen würde, wird an dieser Stelle auf die Seminararbeit
6 von Hichem Hemriti [7] verwiesen, welche einen detaillierteren Überblick über diese Problematik verschafft. 3 Verfahren 3.1 Zentrale Anonymisierungsschicht Verfahren die eine zentrale Anonymisierungsschicht haben, kommunizieren nicht direkt mit dem Dienstgeber des LBSs sondern mittelbar über die Schicht. Der Nutzer schickt eine Anfrage mit exakten Positionsdaten, welche in der Schicht verarbeitet und anonymisiert werden. Personalisiertes Anonymisierungsmodell: Beim personalisierten Anonymisierungsmodell hat jeder Nutzer die Möglichkeit eine persönlich bestimmte Untergrenze sowohl für Privatsphäre (k min ), als auch für Dienstqualität (constraint box) festzulegen. Diese Vorgaben müssen von der Anonymisierungsschicht eingehalten werden, wenn die Nachricht anonymisiert werden soll. Gedik und Liu bauen mit diesem Verfahren [3] auf der Arbeit von Gruteser und Grunwald [10], welche ebenfalls ein zentrales Anonymisierungsmodell vorstellt, auf. Grutesers und Grunwalds Verfahren sammelt die verschlüsselten Nachrichten in einer Anonymisierungsschicht und stellt sie ortsgetreu dar. Danach ermittelt es mittels eines Quadtree-Verfahrens die kleinste Anonymisierungsmenge, welche einem globalen k entspricht. Das personalisierte Anonymisierungsmodell unterscheidet sich jedoch nicht nur durch die bereits genannte Möglichkeit persönliche Grenzen anzugeben, sondern verwendet zusätzlich noch einen gänzlich anderen Algorithmus um die orts- und zeitspezifischen Daten der Anfrage zu verschleiern. Funktionsweise: Jede Nachricht m s, welche von der Anonymisierungsschicht empfangen wird, wird als Tupel (u id, r no, (t, x, y), k, (d t, d x, d y ), C) (1) dargestellt, wobei u id die Identifikationsnummer für den Nutzer ist und r no die Sequenznummer darstellt. Gemeinsam identifizieren beide Werte eine Nachricht eindeutig. Das Tripel (t, x, y) stellt die genaue örtliche und zeitliche Position des Nutzers dar. k entspricht dem bereits genannten k min und das Tripel (d t, d x, d y ) bildet die ebenfalls bereits erwähnte constraint box. Anschaulich gesprochen ist die constraint box die Region, welche dadurch begrenzt ist, dass sie maximal um d t auf der Zeitachse in einer Richtung bzw. analog um dx 2 auf der x- und um dy 2 y-achse in beide Richtungen abweicht. C letztlich stellt die durch Anonymisierungsschicht abgedeckte Region dar. Nach dem Empfang von m s fügt die Anonymisierungsschicht die Nachricht anhand ihrer tatsächlichen Position und ihrer constraint box als Knoten in einen sogenannten constraint graph(g) ein. Abbildungen 1 (a)-(d) veranschaulichen
7 dies indem sie die realen Positionen ((a) und (b)) den Positionen in G ((c) und (d)) gegenüberstellen. 5. Im constraint graph besitzt der Knoten m s dann eine Verbindung zum Knoten m r, wenn die Punkte jeweils innerhalb der constraint box des anderen Knotens liegen. Danach sucht die Anonymisierungsschicht eine Clique mit Kardinalität k, welche m s enthält. Gibt es so eine Clique und werden alle k-bedingungen der Knoten erfüllt, so entfernt die Schicht die komplette Clique aus dem Graph. Die darin enthaltenen Nachrichten werden mit dem minimum bounding rectangle(mbr) - erkennbar in Abb.1 (b) als durchgezongene schwarze Linie - von der zentralen Schicht anonymisiert, indem sie das MBR als Positionsdaten für alle Nachrichten angegibt. Kann die Clique nicht aus dem Graphen entfernt werden, so verbleiben die Knoten in G. Sollte die zeitliche Beschränkung d t einer Nachricht verletzt werden, so wird der zugehörige Knoten aus G entfernt, ohne dass die Nachricht weitergesandt wird. Der Nutzer wird davon in Kenntnis gesetzt und hat dann die Möglichkeit seine Beschränkungen neu zu definieren. Abb. 1. Veranschaulichung des constraint graph[3] Optimierung: Da es sich beim Finden der passenden Clique um ein sehr aufwändiges Verfahren handelt, leuchtet es ein, dass das bisher vorgestellte Verfahren noch an ein paar Stellen optimiert werden kann. So führt zum Beispiel das ständige Suchen nach einer Clique, sobald eine neuer Knoten im Graphen angelegt wird, zu einer hohen Latenz in Bezug auf die Verarbeitung der Nachrichten. Weiter stellt sich heraus, dass sich die Wahrscheinlichkeit eine Clique zu finden, beim Hinzufügen des Knotens im Vergleich zum Rechenaufwand marginal erhöht. Es ist daher sinnvoll die Cliquen-Suche nicht bei jeder Nachricht, 5 Zur besseren Anschaulichkeit wurde die zeitliche Dimension vernachlässigt.
8 sondern seltener durchzuführen. Weiterhin ist es effizienter nach möglichst großen Cliquen zu suchen, da die Anonymisierungsschicht mit großen Cliquen sehr viel mehr Nachrichten abarbeiten kann als mit der jeweiligen Clique der Kardinalität k. Dies hat zusätzlich den Effekt, dass die Privatsphäre für diese Übertragung erhöht wird. Letztlich zeigt die Erfahrung, dass sich Cliquen in großen Graphen nicht quer über den Graphen verteilt bilden. Es können also, um die Effizienz zu erhöhen, Teilgraphen des großen Graphen parallel auf Cliquen untersucht werden, ohne dabei die Wahrscheinlichkeit Cliquen nicht zu erkennen wesentlich zu erhöhen. Abbildung 1 (e) veranschaulicht dieses Suchen in Teilbäumen. Die jeweiligen Teilbäume, welche auf Cliquen durchsucht werden sind grau hinterlegt. Bewertung: Betrachten wir das Verfahren anhand der zu Beginn aufgestellten Metrik, so stellen sich folgende Punkte heraus: Angriffsfläche Die zentrale Anonymisierungsschicht bildet einen SPoF und eignet sich daher für Angriffe welche darauf zielen den Anonymisierungsdienst zu übernehmen. Auch ist die Kommunikation zwischen Anwender und Anonymisierungsschicht problematisch, da sie abgehört werden kann. Von den zu Beginn genannten Angriffsstrategien sind daher die Strategien 1 und 2 anwendbar. Da der Anwender bei der Kommunikation mit der Anonymisierungsschicht unverschleierte Daten versendet kann durch ein Abhören also die genaue Position in Erfahrung gebracht werden. Eine verschlüsselte Kommunikation mit der Anonymisierungsschicht ist, wenn auch nicht für das Verfahren notwendig, also sehr empfehlenswert. Weil bei diesem Verfahren ein zentraler Dienst die Anonymisierung übernimmt ist also auch die Strategie 2 verwendbar. Ein Dienst der entweder von einem Angreifer kompromittiert wurde oder von vorneherein nicht vertauenswürdig war bekommt alle Positionsdaten unverschleiert geliefert. Die Strategien 3 und 4 hingegen sind nicht anwendbar weil im Verfahren keine Peers vorgesehen sind und weil der Dienstgeber bei einer vertrauenswürdigen Anonymisierungsschicht nur verschleierte Positionsdaten bekommt. Kommunikationsaufwand Es tritt kein Mehraufwand an Kommunikation auf, da die Nutzer einfache Anfragen mit den unveränderten Orts- und Zeitdaten schicken. Nutzerdichte Das Verfahren ist prinzipiell auch bei geringer Nutzerdichte funktionsfähig, allerdings ist der Nutzer evtl. genötigt Kompromisse in Bezug auf k min oder die constraint box einzugehen. Rechenaufwand Der Rechenaufwand wird nicht erhöht. Skalierbarkeit Aufgrund der Komplexität des Algorithmus steigt der Rechenaufwand auf Seiten der Anonymisierungsschicht schnell an, was es schwieriger macht in Bezug auf Anfragen zu skalieren, da jede Anfrage einen Knoten im Graphen darstellt. Mittelbar wirkt sich das auch auf die Skalierbarkeit in Bezug auf Anwender aus.
9 Durch den Nebel Routen: Beim durch den Nebel routen (engl: Routing Through the Mist) von Al-Muhtadi et al. [8] wird die Anonymisierung durch eine Hierarchie von Routern übernommen. Diese Hierarchie ist virtuell über die bereits vorhandenen und verbunden Router gelegt. Der Nutzer kommuniziert mit Portalen, welche jedoch nicht dessen Identität kennen und bestimmt einen in der Hierarchie höher liegenden Leuchtturm, welcher dessen Identität aber nicht dessen Position kennt. Damit dieses Verfahren funktioniert, ist eine Public- Key-Kryptographie Voraussetzung. Funktionsweise: Die überlagernde Hierarchie bildet einen Baum, wobei die Blätter (Portale) Zugangspunkten in den jeweiligen Räumen entsprechen. In der Hierarchie höher stehende Router fassen dann gewisse Bereiche zusammen, z.b. einen Flur, ein Stockwerk, ein Gebäude oder einen Stadtteil. Eine beispielhafte Hierarchie ist in Abb. 2 zu erkennen. Leuchttürme sind daher Vorfahren des jeweiligen Portals, mit dem der Nutzer kommuniziert. Um sicherzustellen, dass Leuchttürme nicht direkt das Portal kennen, routet das Verfahren sprungweise und mit einer Handle ID. Der Nutzer kann den Grad seiner Anonymität dadurch steuern, dass er einen in der Hierarchie höher oder niedriger stehenden Leuchtturm auswählt. Um eine Verbindung zu initialisieren, muss sich der Nutzer zunächst mit dem Portal verbinden. Das Portal weist dem Nutzer daraufhin eine Handle ID zu und liefert ihm eine Liste mit den möglichen Leuchttürmen und deren Zertifikaten und Public-Keys. Daraufhin wählt der Nutzer einen Leuchtturm aus der Liste aus und verschlüsselt seine Anfrage mit dem Schlüssel des Leuchtturms. Die Anfrage wird vom Anwender an das Portal gesendet, welches diese an seinen Vorfahren weitergibt. Der Vorfahre versucht zunächst die Anfrage zu entschlüsseln und passt danach seine Routing Tabelle entsprechend an (er merkt sich die Handle ID und den Kanal, über den er das Packet bekommen hat). Gelingt es dem Vorfahr die Nachricht zu entschlüsseln, so ist er der Leuchtturm für den Anfragesteller und vermerkt dessen Identität in seiner Nutzertabelle. Gelingt es dem Vorfahr nicht die Nachricht zu entschlüsseln, so vergibt er dem Packet eine neue Handle ID und sendet es seinem Vorfahr. Wurde der Leuchtturm schließlich gemäß dieses Verfahrens gefunden, dann schickt er eine Bestätigungsnachricht an den Nutzer und der Nutzer kann fortan über die aufgebaute Verbindung kommunizieren. Abbildung 3 erläutert dies mittels einer Momentaufnahme nachdem der Leuchtturm gefunden wurde. Jeder Knoten hat eine Routingtabelle in der die Handle IDs sowie die Empfangskanäle aufgeführt sind. Optimierung: Ein Verlassen des Sendebereichs des aktuellen Portals (Verlassen des Raumes) hat zur Folge, dass erneut eine Verbindung aufgebaut werden muss. Der Nutzer wäre also gezwungen erneut einen Leuchtturm auszuwählen, da dies aber gerade für mobile Nutzer sehr schnell lästig wird, lässt sich der Leuchtturm einmal manuell und fortan automatisch auswählen, soweit dieser noch erreichbar ist. Verlässt der Anwender hingegen den Einflussbereich des Leuchtturms, sprich den
10 Abb. 2. Mist Routing Hierarchie[8] Abb. 3. Mist Routing Verbindung[8]
11 Teilbaum dessen Wurzel der Leuchtturm ist, so ist eine manuelle Auswahl eines neuen Leuchtturms unumgänglich. Bewertung: Betrachten wir das Verfahren anhand der zu Beginn aufgestellten Metrik, so stellen sich folgende Punkte heraus: Angriffsfläche Durch das Trennen von Position und Identität bietet dieses Verfahren nur geringe Angriffsfläche. Die Anwendung von Strategie 1 ist natürlich möglich, allerdings schon sehr eingeschränkt, da ein Angreifer sich im selben Einflussgebiet des Portals befinden muss, um die Kommunikation mit diesem abzuhören. Ein Abfangen der Kommunikation in einer höheren Ebene der Hierarchie ist bei einer vertrauenswürdigen Anonymisierungsschicht nicht möglich. Strategie 2 scheint hier jedoch vielversprechender. Im Gegensatz zum Personalisierten Anonymisierungsmodell ist es beim Durch den Nebel Routen nicht notwendig die komplette Schicht zu übernehmen oder zu kompromittieren. Es reicht bereits wenn ein Teilbaum der Hierarchie nicht vertrauenswürdig ist. Allerdings muss auch hier dann der Leuchtturm im nicht vertrauenswürdigen Teil liegen. Strategie 3 und 4 sind hier wiederum nicht anwendbar, da keine Peers für das Verfahren von Bedeutung sind bzw. der Anbieter eines LBSs nur verschleierte Daten bekommt. Kommunikationsaufwand Die Verwaltung der Verbindung ist sehr aufwändig und führt dadurch zu einem enormen Kommunikationsoverhead. Nutzerdichte Aufgrund der Architektur des Verfahrens spielt die Nutzerdichte hier keine Rolle. Rechenaufwand Es entsteht kein zusätzlicher Rechenaufwand. Skalierbarkeit Das Verfahren lässt sich leicht durch erweitern der Hierarchie um Teilbäume skalieren. 3.2 Peer-to-Peer Anonymisierung Bei Peer-to-Peer Anonymisierungsverfahren gibt es keine vertrauenswürdige dritte Partei. Der Nutzer anonymisiert sich mit anderen Nutzern nach dem Peer-to- Peer Prinzip und leitet die bereits anonymisierten Orts- und Zeitdaten an den Dienstgeber weiter. Peer-to-Peer Verschleierung: Die Anonymisierung mittels Peer-to-Peer Verschleierung nach Chow, Mokbel und Liu [4] bildet direkt eine Anonymisierungsmenge mit anderen Nutzern, die im Moment in Reichweite sind. Um dies zu bewerkstelligen muss jeder Nutzer nicht nur über seine Position, sondern auch über seine Geschwindigkeit informiert sein, da gerade hohe Geschwindigkeiten zur Folge haben, dass der Sendebereich des anderen Peers verlassen wird. Ähnlich wie beim personalisierten Anonymisierungsmodell gibt jeder Nutzer wieder ein k als persönlichen Anonymisierungsgrad an. Bei diesem Verfahren wird jedoch darüber hinaus auch noch ein A min angegeben, welches die kleinste Anonymisierungsregion beschreibt.
12 Abb. 4. Beispiel einer Anonymisierungsmenge[4] Funktionsweise: Bevor der Nutzer eine Anfrage an den Dienst formuliert lädt er zunächst seine Peers, welche er erreichen kann ein, mit ihm eine Anonymisierungsregion zu bilden. Findet er genügend, d.h. k 1, Nachbarn in seinem direkten Senderadius, kann er die Anonymisierungsregion berechnen. In Abb. 5 (a) ist dieser Fall dargestellt. Der gestrichelte Kreis stellt den Senderadius des zentralen Punktes, welcher die Gruppe bildet, dar. Findet er nicht genügend, so muss er erneut eine Anfrage stellen, diesmal jedoch mit dem Hinweis an seine direkten Nachbarn die Einladung an deren Nachbarn weiterzuleiten. Dieser Fall ist in Abb. 5 (b) zu erkennen. Der Senderadius des Anfragestellers ist verringert und erreicht nicht genügend Punkte, deshalb werden alle die sich im Senderadius der Nachbarn (dargestellt durch weitere gestrichelte Kreise) befinden von den Nachbarn in die Gruppe eingeladen. Die Menge an befragten Nachbarn wird so iterativ immer weiter erhöht, bis eine Anonymisierungsmenge mit k 1 Nachbarn gebildet werden kann oder die Menge der antwortenden Nachbarn sich bei zwei aufeinanderfolgenden Einladungen nicht ändert. Im zweiten Fall befinden sich zu wenige Peers in der Umgebung um den Anspruch an Privatsphäre des Nutzers zu erfüllen. Befinden sich genügend Nachbarn in der Nähe, so kann der Anfragesteller m i 6 mit der Berechnung der Anonymisierungsregion beginnen. Dazu benötigt er die Position und Geschwindigkeit der an der Region beteiligten Peers, um die Punkte der maximalen Entfernung errechnen zu können. Die Kreise in Abb. 5 (c) stellen den Bewegungsradius eines jeden Nachbarn dar, welcher anhand der Geschwindigkeit des jeweiligen Punktes errechnet wurde. Die Linien stellen den angenommenen worst case dar, nämlich dass sich der Peer direkt vom Anwender entfernt. Der Schnittpunkt schließlich zwischen den Kreisen und den Linien sind die Punkte der maximalen Entfernung. Anhand dieser Punkte wird dann eine Anonymisierungsregion gewählt. Sollte die Anonymisierungsregion kleiner 6 In Abb. 5: i = 8
13 als A min sein, so wird einfach auf A min hochskaliert. Das dick umrandete Rechteck in Abb. 5 (d) stellt solch eine Anonymisierungsregion dar. Sie umfasst alle Punkte maximaler Entfernung der Peers. Im Anschluss an diese Berechnung wählt das Verfrahen einen der Peers zufällig aus, welcher als Agent fungiert und die Anfrage an den Dienstgeber weiterleitet. Abb. 5. Bilden einer Anonymisierungsregion[4] Optimierung: Wie bereits erwähnt spielt bei der Peer-to-Peer Verschleierung die Geschwindigkeit der Peers eine Rolle. Es kann beispielsweise dazu kommen, dass ein Peer aufgrund der zeitlichen Verzögerung, die durch die sog. mulit-hop Kommunikation entsteht und seiner Geschwindigkeit die Senderegion des Anfragestellers verlässt. Den bislang vorgestellten Kommunikationsmodus nennt man den on demand Modus. Sollte eine Verbindung notwendig sein, wird die Anonymisierungsregion nach Bedarf gebildet. Dieser hilft uns allerdings beim oben geschildertem Problem nicht weiter, weshalb das Verfahren von seinen Entwicklern um den sog. proactive Modus erweitert wurde. Dabei bildet ein jeder Nutzer ständig eine Anonymisierungsregion mit seinen Nachbarn, um bei Bedarf die Anfrage schneller zum Dienstgeber losschicken zu können. Bewertung: Betrachten wir das Verfahren anhand der zu Beginn aufgestellten Metrik, so stellen sich folgende Punkte heraus: Angriffsfläche Die verteilte Peer-to-Peer Architektur bietet eine ziemlich kleine Angriffsfläche. Da dieses Verfahren keine Anonymisierungsschicht besitzt kann weder die Kommunikation zu dieser abgehört werden noch kann diese kompromittiert werden. Die Angriffsstrategien 1 und 2 sind also nicht erfolgversprechend. Strategie 4 ist zwar prinzipiell denkbar, da hier die Anwender nicht über eine zentrale Schicht mit dem Dienstanbieter kommunizieren, jedoch führt das zufällige auswählen eines Agenten dazu, dass der Dienstanbieter sich kein verlässliches Bild über den Anfragesteller machen kann. Einzig Strategie 3 scheint Erfolg zu versprechen. Aber da nur die direkten Nachbarn und der Agent über die Position des Anfragestellers Bescheid wissen können erschwert dies ein Mithören der Daten ungemein. Ein Angreifer muss sich also immer in der näheren Umgebung des Opfers befinden um als direkter Nachbar die Positionsdaten zu bekommen. Agent hingegen zu
14 werden ist zu stark vom Zufall abhängig um eine geeignete Methode darzustellen. Kommunikationsaufwand Vor allem die mulit-hop Kommunikation besitzt hohen Aufwand. Nutzerdichte Die Nutzerdichte ist hier äußerst relevant, da in spärlich besetzten Gebieten keine Anonymisierungsmenge, die die Anforderungen erfüllt, gefunden werden kann. Auch kommt bei geringer Nutzerdichte die Limitierung durch Sendereichweite stärker zum Tragen. Rechenaufwand Das Berechnen der Anonymisierungsregion bietet einen nicht zu vernachlässigenden Rechenaufwand, der gerade von den Endgeräten bewältigt werden muss. Skalierbarkeit Aufgrund des Peer-to-Peer Prinzips sehr leicht und flexibel zu skalieren. 3.3 Selbstanonymisierung Selbstanonymisierungsverfahren, berechnen die Anonymisierungsmenge, welche sie dem Dienstgeber mitteilen, komplett selbst und benötigen daher keine anderen Teilnehmer. Anonymisierung durch Dummies: Die Anonymisierung durch Dummies, von Kido, Yanagisawa und Satoh [6],verwendet falsche Datensätze, sog. Dummies, um die wahre Position zu verschleiern. Hier wird keine Anonymisierungsregion gebildet, sondern es werden einfach k mögliche Aufenthaltsorte übermittelt. Funktionsweise: Bevor der Nutzer eine Dienstanfrage stellt, generiert er zufällig in einem Gebiet um sich selbst herum Dummies. Dann sendet er eine Liste von Anfragen, eine Anfrage pro Dummy, an den Server, welche alle denselben Inhalt haben. Der Server behandelt nun alle Anfragen und sendet jeweils die Antworten. Der Nutzer muss nun nur noch die ihm bekannten false positives aussortieren. Optimierung: Das Verfahren klingt simpel, dennoch gibt es ein paar Forderungen, welche die Funktionsweise etwas komplizierter gestalten. Der wesentliche Punkt ist es, realistische Dummies zu generieren, da sonst bei aufeinanderfolgenden Anfragen sehr leicht das Original ausgemacht werden kann. Denn im Gegensatz zu rein zufälligen Dummies weist das Original ein realistisches Bewegungsmuster auf. Es ist daher als Anwender notwendig einmal zufällig Dummies zu kreieren und dann nur noch zufällig in der Umgebung bereits kreierter Dummies wieder Dummies zu generieren (Moving in a Neighborhood) (MN). Auch können Dummies entlarvt werden, wenn sich die Nutzerdichte in gewissen Gebieten stark ändert, weshalb eine weitere Erweiterung bei einer hohen Nutzerdichte vom Verfahren genutzt wird: Moving in a Limited Neighborhood (MLN). Hierbei werden Dummies, die in zu dicht besetzten Gebieten kreiert werden gleich wieder verworfen und ein neuer Dummy nahe dessen voriger Position zufällig erzeugt.
15 Weiterhin ist die Generierung von Dummies mit hohem Rechenaufwand auf dem mobilen Endgerät verbunden, was sich besonders stark bei großem k bemerkbar macht. Eine Lösungsmöglichkeit hierfür ist nicht etwa k 1 Dummies zu kreieren, sondern nur log(k 1). Dann kann das Verfahren die Potenzmenge der x- und y-komponenten verwendet um die benötigten Dummies zu erstellen. Diese Methode wird durch Abb. 6veranschaulicht. Abschnitt (a) enthält die gewöhnlich zufällig generierten Dummies, während in Abschnitt (b) die Vielzahl von Dummies, welche mittels der Potenzmenge gebildet werden können, darstellt. Abb. 6. Dummyenerierung zufällig (a) und mittels Potenzmenge (b)[6] Bewertung: Betrachten wir das Verfahren anhand der zu Beginn aufgestellten Metrik, so stellen sich folgende Punkte heraus: Angriffsfläche Das Verfahren bietet kaum Angriffsfläche, da alle notwendigen Schritte auf dem Gerät des Nutzers durchgeführt werden und eine direkte Kommunikation mit dem Dienstanbieter stattfindet. Es ist also weder möglich sich gemäß Strategie 3 als Peer anzubieten noch ist es möglich Strategie 2 anzuwenden und sich als Anonymisierungsdienst auszugeben. Auch Strategie 1 ist unwirksam, da die Kommunikation bereits die Positionsdaten verschleiert, indem es eine Liste von Positionsdaten schickt. Aufgrund der direkten Kommunikation mit dem Dienstanbieter ist allerdings einem Angreifer mit Strategie 4 möglich seine Zielsetzung zu erfüllen. Die Liste der Positionsdaten wird immer vom Gerät des Anwenders aus geschickt und deswegen kann mittels der genannten Verfahren der Nutzer trianguliert werden. Kommunikationsaufwand Es entsteht ein hohes Kommunikationsaufkommen durch die vielen Dummy-Anfragen. Nutzerdichte Das Verfahren ist unabhängig von der Nutzerdichte. Rechenaufwand Der Rechenaufwand ist hoch. Skalierbarkeit Der Skalierbarkeit sind prinzipiell keine Grenzen gesetzt.
16 4 Zusammenfassung Bei der genauen Analyse muss man nun feststellen, dass die Verfahren viele interessante Herangehensweisen abdecken, jedoch lässt sich kein Verfahren ausmachen, welches alle Herausforderungen, die zur Bewertung herangezogen wurden, meistert. Zentrale Verfahren glänzen meist in puncto Rechen- und Kommunikationsaufwand, haben jedoch Probleme was die Angriffsfläche betrifft. Dezentrale Verfahren haben hingegen das Problem, dass der Rechen- und Kommunikationsaufwand hoch ist, was sich gerade bei den mobilen Endgeräten schlecht auswirkt. Auch ist die Komplementärbeziehung zwischen Datenschutz und Dienstqualität im Umfeld lokationsbasierter Dienste ein Problem. Anonymisierung bietet allerdings einen sehr interessanten Lösungsansatz für die Datenschutzproblematik in LBSen. Durch die technische Anonymisierung können Daten automatisiert für z.b. Statistiken verwendet werden, ohne Zustimmung zu einer Datenschutzrichtlinie zu bedürfen. So kann das volle Potential von lokationsbasierten Diensten ausgenutzt werden. Aufgrund der Tatsache, dass Anonymisierungsverfahren lediglich die orts- und zeitspezifischen Daten, nicht jedoch den Inhalt der Nachricht verschleiern, ist es nur ratsam zusätzlich eine Verschlüsselung bei der Kommunikation einzusetzen. Nachrichten, die in ihrem Inhalt den Aufenthaltsort der Person beschreiben, können ohne Verschlüsselung leicht dazu verwendet werden die Person eben doch zu lokalisieren. Die hier genannten Verfahren sind natürlich nicht der Weisheit letzter Schluss und es gibt eine Vielzahl weiterer Ansätze, die sich mit dieser Problematik beschäftigen. Mix Zones [2], das Cricket System [11] und Verschleierung durch Gebiete [9] sind ein paar von diesen.
17 Literatur 1. M. Köhntopp A. Pfitzmann. Anonymity, Unobservability, Pseudonymity, and Identity Management - A Proposal for Terminology. Workshop on Design Issues in Anonymity and Unobservability, 2000. 2. F. Stajano A. R. Beresford. Location Privacy in Pervasive Computing. IEEE Pervasive Computing, 2003. 3. L. Liu B. Gedik. Location Privacy in Mobile Systems: A Personalized Anonymization Model. Proceedings of the 25th IEEE International Conference on Distributed Computing Systems, 2005. 4. X. Liu C. Chow, M. F. Mokbel. A Peer-to-Peer Spatial Cloaking Algorithm for Anonymous Location-based Services. ACM-GIS 06, 2006. 5. H. Timenes C. Langewiesch. NavXS. http://www.navxs.com/about/index.aspx. 6. T. Satoh H. Kido, Y. Yanagisawa. An Anonymous Communication Technique using Dummies for Location-based Services. Proceedings of IEEE International Conference on Pervasive Services, 2005. 7. H. Hemriti. Erhalt der Privatsphäre bei kontinuierlichen Abfragen und Datenströmen. Seminar Aktuelle Herausforderungen an Datenschutz und Datensicherheit in modernen Informationssystemen Universität Karlsruhe (TH) IPD Böhm, 2007. 8. A. Kapadia M. D. Mickunas S. Yi J. Al-Muhtadi, R. Campbell. Routing Through the Mist: Privacy Preserving Communication in Ubiquitous Computing Environments. Proceedings of the 22nd International Conference on Distributed Computing Systems, 2002. 9. L. Kulik M. Duckham. Simulation of Obfuscation and Negotiation for Location Privacy. Pervasive, 2005. 10. D. Grunwald M. Gruteser. Anonymous Usage of Location-Based Services Through Spatial and Temporal Cloaking. Proceedings of MobiSys 2003: The First International Conference on Mobile Systems, Applicatons, and Services, 2003. 11. H. Balakrishnan N. B. Priyantha, A. Chakraborty. The Cricket Location-Support System. Proceedings of the Sixth Annual International Conference on Mobile Computing and Networking, 2000. 12. L. Sweeney P. Samarati. Protecting privacy when disclosing information: k- anonymity and its enforcement through generalization and suppression. International Journal on Uncertainty, Fuzziness and Knowledge-based Systems, 1998.