\section{Grundlagen} In diesem ersten Teil wird der momentane Stand von \textit{location privacy} Software auf mobilen Geräten aufgezeigt. \textit{Location privacy} wird von Beresford und Stanjano durch ``...the ability to prevent other parties from learning one's current or past position'' \citep{privacy} definiert.\newline Des weiteren werden die Anforderungen, die an ein Programm dieser Art gestellt werden, analysiert. \subsection{Aktueller Stand} Da so gut wie alle aktuellen Smart Phones mit dem \textit{Global Positioning System (GPS)} ausgestattet sind existieren für die verschiedenen Betriebssysteme schon eine Reihe von Anwendungen die Funktionalitäten rund um die eigene Position bieten. So existieren Anwendungen um sich Routen erstellen zu lassen, die eigene Position zu bestimmen oder um \textit{Geocaching} zu betreiben.\newline Zum Beispiel bietet \textit{Google} den Dienst \textit{Google Latitude} \citep{Latitude} an. Bei diesem Programm ist es möglich die Position von Freunden, die diesen Dienst auch nutzen, auf einer Karte anzeigen zu lassen. Es besteht hierbei die Möglichkeit die eigene Position per \textit{GPS} oder mit Hilfe von Daten der \textit{GSM-Funkzelle} zu bestimmen.\newline Um auch im Rahmen solcher Anwendungen die \textit{location privacy} zu wahren, gibt es unterschiedliche Ansätze. So befasst sich eine Arbeit mit dem Titel \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS} mit dem Versenden von verschlüsselten Daten. Hierfür wurde ein Dienst für mobile Geräte implementiert welcher Daten verschlüsselt an mehrere Nutzer sendet. Es wurde ein möglichst einfaches und verlässliches Protokoll entworfen, mit dem Ziel die Berechnungszeiten niedrig zu halten. \newline Einen anderer Ansatz verfolgen Gruteser und Grundwald \citep{kprivacy}. Sie versuchen mit Hilfe von \textit{k-anonymity} \citep{kanonymity} \textit{location privacy} zu ermöglichen. Man versteht unter \textit{k-anonymity}, dass in einer Menge von $k$ Personen ein Teilnehmer nicht von den anderen $k-1$ Teilnehmern unterschieden werden kann. Gruteser und Grundwald haben hierfür einen \textit{quadtree} \citep{quadtree} genutzt um bestimmte Bereiche zu erstellen. Diese Bereiche haben nur eine Vorraussetzung, sie müssen $k$ Personen enthalten. Somit kann nicht festgestellt werden, welcher dieser $k$ Personen eines Bereiches die Daten versandt hat.\newline Zum Verschleiern der Position nutzen Kido u.a. \citep{dummy} Datensätze die falsche Positionsangaben beinhalten. Dieser wird an einen Dienst gesandt, welcher auf den gesamten Datensatz antwortet. Nur der Client weiß, welche der empfangenen Daten auf der eigentlichen Position basieren.\newline Wie an den vorangegangenen Arbeiten ersichtlich ist, existieren schon ein Reihe von unterschiedlichen Ansätzten um die Wahrung der \textit{location privacy} zu ermöglichen. %anderer titel der section \subsection{Vorraussetzungen} Um die Privatsphäre der Nutzer, von Diensten wie \textit{Google Latitude}, zu wahren kann neben den bereits existenten auch ein anderer Ansatz verfolgt werden. Da die Verbreitung von mobilen Geräten in den letzten Jahren beständig zugenommen hat und alle neueren Modelle ein \textit{GPS}-Modul besitzen, sind die Vorraussetzungen für Anwendungen, die Positionsdaten nutzen, gegeben. Auch im Rahmen der Datenübertragung sind alle modernen Geräte in der Lage, Daten sowohl über den \textit{3G}-Standart sowie per \textit{WLAN} zu übertragen. \newline Wenn nun ein sicherer Austausch von Positionsdaten erfolgen soll, so müssen, neben der Hardware, auch andere Rahmenbedingungen gegeben sein. Um die \textit{location privacy} zu wahren, dürfen die Positionsdaten also nicht für jederman zugänglich sein. Da man aus solchen Daten die aktuelle Position erfahren oder Bewegungsprofile erstellen kann, sollten der Zugang zu ihnen nur dann erlaubt sein wenn der Benutzer dies erlaubt. Die Daten müssen also soweit entfremdet oder abgeändert werden damit diese nicht mehr rekonstruierbar sind, ausser der Benutzer wünscht dies.\newline Ist dies gegeben, sollen die Daten im nächsten Schritt versendet werden. Auch hier sollte ein Weg gefunden werden mit dem der Nutzer möglichst viel Kontrolle über seine Datensätze besitzt. Um diese Kontrolle zu bewahren, müssen die Informationen mit einer möglichst transparenten und doch verlässlichen Methode verteilt werden. Auch die Möglichkeit der Speicherung der Daten über die Zeit muss hier berücksichtigt werden. Um diesen Punkt zu umgehen sollte man zum Übertragen der Informationen nicht nur auf einen zentralen Knoten angewießen sein, sondern nutzt im optimalen Fall ein ganzes Netzwerk von solchen Knotenpunkten.\newline Wenn all diese Punkte beim Versenden der Daten berücksichtigt werden, so kann man einen Dienst erstellen welcher die Funktionalität eines \textit{Goolge Latitudes} bietet aber auch die \textit{location privacy} des Benutzers wahrt. \subsection{Ziele} Zusammenfassend kann also gesagt werden, dass eine Software mit den beschriebenen Eigenschaften die Sicherheit der Daten, im Kontext von nicht für jeden zugänglich, und das Vermeiden von Vorratsdatenspeicherung zum Ziel haben sollte. Dem Anwender soll es aber trotz allem einfach gemacht werden dieses Programm zu nutzen. Die Inhalte der Anwendung sollen also soweit abstrahiert werden, als dass auch ein Benutzer ohne Fachkentniss alle Features anwenden kann, ohne dass die obigen Punkte ausser Kraft treten. \newline Damit die Positionsdaten nicht für alle zugänglich sind sollen diese verschlüsselt werden. Da Verschlüsselungen Schlüssel voraussetzt, muss ein Verfahren genutzt werden welches den Austausch von zwei Schlüsseln auf einfache Weiße ermöglicht. Allerdings muss garantiert sein dass die Schlüssel während des Austausches nicht von Personen abgefangen werden, für die sie nicht bestimmt sind. \newline Ist ein solches Verfahren gegeben, so muss nun eine Möglichkeit gefunden werden die Daten möglichst sicher und effizient zu Verschlüsseln. Es muss also ein Algorithmus genutzt werden, der sowohl sicher ist und mit möglichst geringem Aufwand die Daten ver- und entschlüsselt. \newline Da vermieden werden soll, dass es möglich ist Daten über die Zeit zu sammeln, sollte die Anwendung nicht nur auf einen zentralen Knotenpunkt, über den alle Daten fließen, angewießen sein. Es wird also ein dezentrale Struktur benötigt, innerhalb derer man einzelne Knoten, über die die Daten gesendet werden, wählen kann. Diese Struktur sollte über ein Protokoll verfügen welches die Daten versenden kann. Dieses Protokoll sollte verlässlich, stabil und auch für langsame Netzwerke optimiert sein um eine reibungslose Kommunikation zu garantieren. \newline Ein weiterer, bisher noch nicht berücksichtigter Punkt ist die Plattformunabhängigkeit. Ein solches Programm sollte unter möglichst vielen Plattformumgebungen lauffähig sein. Zum einen wird somit der Aufwand der Implementierung verringert, da die Software nicht mehrmals implementiert werden muss. Zum anderen werden somit auch möglichst viele Benutzer erreicht und es kann auch Kommunikation unter Besitzern von unterschiedlichen Typen von Mobiltelefonen stattfinden.\newline \subsection{Anforderungen an die Software} Aus den vorrangegangenen Zielen lassen sich die Anforderungen ableiten die an eine solche Software, neben der Ver- sowie Entschlüsselung der Daten und einem dezentralen System zum Versenden der Daten, gestellt werden. Da Positionsdaten versendet werden, sollte die Applikation in der Lage sein die Standorte anderer Nutzer anzuzeigen. Um die Position zu visualisieren muss ein Format genutzt werden, welches hierfür geeignet ist. Es bietet sich an hierfür das \textit{Latitude}/\textit{Longtitude} Format zu nutzen, da es hiermit möglich ist jeden Punkt auf der Erdoberfläche Geokoordinatensystem darzustellen. Des weiteren nutzt \textit{GPS} dieses Koordinatenformat. Da aus Gründen der Nutzbarkeit die Positionen der Teilnehmer auf einer Karte dargestellt werden sollten muss ein Format für die Karte genutzt werden, welches auf dem mobilen Gerät darstelbar ist und man einfach auf den neusten Stand bringen kann.\newline Benutzer die sich in größeren Entfernungen befinden sind für Programme dieser Art nur begrenzt interessant. Deshalb werden nur Teilnehmer innerhalb eines bestimmten Radiuses angezeigt.\newline Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen sollte es des weiteren möglich sein Chatnachrichten auszutauschen. Somit kann die Interaktion der Anwender und somit der Nutzen des Dienstes noch gesteigert werden.\newline Die Struktur des Programmes sollte möglichst modular gehalten werden, damit es auch in späteren Phasen den Entwicklern leicht fällt bestimmte Programmteile auszutauschen. Somit soll gewährleistet werden das bestimmte Funktionen auch zu einem späteren Zeitpunkt ausgetauscht werden können. So wäre es zum Beispiel denkbar verschiedene Algorithmen zur Verschlüsselung oder ein anderes Protokoll zum Versenden der Daten zusätzlich zu implementieren oder die bisher genutzten Algrorithmen auszutauschen. \newline \subsection{Verfahren} Anhanden der Anforderungen müssen nun geeignete Verfahren und Protokolle sowohl für Kommunikation als auch für Verschlüsselung gewählt werden. Wie schon erwähnt muss die Verschlüsselung möglichst einfach zu berechnen sein und dabei trotzdem noch bestmögliche Sicherheit der Daten bieten. Aus Gründen der Schlüsselverwaltung ist ein symmetrisches Verfahren besser geeignet als ein asymmetrisches. Es ist einfacher einen Schlüssel pro Gruppe zu verwalten als einen privaten, einen öffentlichen sowie unter Umständen noch ein Zertifikat. Des weiteren sind symmetrische Verfahren nicht so berrechnungsintensiv wie asymmetrische, was einen wichtigen Punkt auf mobilen Geräten darstellt. \newline Der Austausch der Schlüssel könnte theoretisch auf mehreren Wegen geschehen. So könnte man sie per \textit{Bluetooth} übertragen oder einen 2D-Barcode \citep{qrcode} aus der Zeichenkette erstellen, fotographieren und wieder in eine Zeichenkette umwandeln. Da \textit{Bluetooth} ein unsicheres Medium darstellt \citep{bluetooth}, der Sitzungs PIN kann per Daten-Phishing wiederhergestellt werden, werden die Schlüssel per Barcode verteilt. Es findet somit keine Datenübertragung durch Kommunikation zwischen den Geräten statt, womit der Schlüssel auf diesem Weg nicht abgefangen werden kann. \newline Für die Kommunikation zwischen den einzelnen Teilnehmern ist ein dezentrales Protokoll von Nöten, welches möglichst wenig Daten verschickt, die nichts mit der eigentlichen Kommunikation zu tun haben, das stabil läuft und welches beim Ausfallen eines Knotenpunktes diesen mit einem anderen ersetzen kann.\newline Ein Vorhandenes Protokoll, welches ein aktives Netzwerk bereitstellt das auch rege genutzt wird, ist das \textit{IRC}-Protokoll \citep{IRC}. Es stehen bereits mehrere Server zur Verfügung und jeder Nutzer kann einen eigenen Server bereitstellen. Jeder Server verwaltet mehrere \textit {Channels}. Würde nun ein Server ausfallen, so könnten die Nutzer auf einen anderen \textit{IRC}-Server ausweichen. Des weiteren sind \textit{IRC}-Netzwerke nicht mit einem zentralen Knotenpunkt organisiert, sondern bestehen aus mehreren Servern. Somit ist auch die Anforderung der Dezentralität gegeben, da Nutzer beliebig zwischen den Servern wechseln können. Das Versenden von Hintergrunddaten, wie zum Beispiel Sitzungsinformationen, ist von der Anwendung auf Clientseite frei auswählbar und skalierbar.\newline Auf dieses Verfahren soll nun das Protokoll zum Versenden von Textnachrichten sowie Positionsdaten aufsetzten. Die Daten werden in beiden Fällen verschlüsselt über einen \textit{IRC}-Channel gesendet und dort ausgegeben. Beim Versenden der Positionen muss zwischen Sender und Empfänger unterschieden werden. Dies geschieht, indem dem User ein entsprechender Suffix angehängt wird. Somit kann zwischen diesen beiden Diensten unterschieden werden. Beim Kommunizieren mit Textnachrichten muss der Benutzer im Vorfeld festlegen mit welchem anderen Teilnehmer er Nachrichten austauschen möchte. Daraufhin werden den zwei Anwendern nur die jeweiligen Textnachrichten des anderen aus dem \textit{Channel} angezeigt. \newline Durch die Wahl dieser Lösung ist sowohl die Berechnungszeiten durch ein symmetrisches Verfahren niedrig gehalten, der Verwaltungsaufwand für die Schlüssel gering und die Verteilung der Schlüssel kann durch die angesprochenen Barcodes erfolgen. Bei der Kommunikation gibt es keinen einzelnen zentralen Server der den gesamten Datenverkehr einsehen kann. Der Verkehr erfolgt über die \textit{IRC}-Server nur in verschlüsselter Form. Des weiteren kann jeder beliebige \textit{IRC}-Server gewählt werden