\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