summaryrefslogtreecommitdiffstats
path: root/ausarbeitung/Grundlagen.tex~
diff options
context:
space:
mode:
Diffstat (limited to 'ausarbeitung/Grundlagen.tex~')
-rw-r--r--ausarbeitung/Grundlagen.tex~150
1 files changed, 150 insertions, 0 deletions
diff --git a/ausarbeitung/Grundlagen.tex~ b/ausarbeitung/Grundlagen.tex~
new file mode 100644
index 0000000..9bd815d
--- /dev/null
+++ b/ausarbeitung/Grundlagen.tex~
@@ -0,0 +1,150 @@
+\section{Grundlagen}
+
+In diesem ersten Teil dieser Bachelor-Arbeit wird der momentane Softwarestand von \textit{location awareness} auf mobilen Geräten
+aufgezeigt. Es wird auch analysiert werden, was für Anforderungen an ein Programm dieser Art gibt um einen sicheren Datenverkehr
+zu garantieren.
+
+\subsection{Aktueller Stand}
+Da so gut wie alle aktuellen Smart Phones mit einem \textit{GPS} ausgestattet sind existieren für die verschiedenen
+Betriebssysteme schon eine Reihe von Anwendungen die Funktionalitäten für \textit{location awareness} bieten. So existieren
+Anwendungen um sich Routen erstellen zu lassen, die eigene Position zu bestimmen oder um \textit{Geocaching} zu betreiben. Es
+existieren auch eine Menge an Anwendungen die die eigene Position für Freunde sichtbar macht.\newline
+So bietet \textit{Google} den Dienst \textit{Google Latitude} \citep{Latitude} an. Bei diesem Dienst ist es möglich die Position
+von Freunden, die diesen auch Dienst 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. Es existiert auch eine Paper mit dem
+Titel \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS}. Hierfür wurde ein Dienst für mobile Geräte implementiert,
+welcher Daten verschlüsselt an mehrere Nutzer sendet. Dieser Dienst wurde auch mit einem möglichst einfachen und verlässlichen
+Protokoll entworfen um die Berechnungszeiten niedrig zu halten. Des weiteren hat man in dem Paper \textit{FriendSensing:
+Recommending Friends Using Mobile Phones} \citep{FriendSensing} Möglichkeiten erörtert um die Position anderer Benutzer mithilfe
+von \textit{Bluetooth} zu bestimmen. Hierbei registrierte eine Software wie oft welcher Nutzer mit einem anderen in Kontakt stand
+und wie oft sie in Reichweite von \textit{Bluetooth} waren. Diese Aufzählung, über Software die sich mit der Thematik von
+\textit{location awareness} auseinandersetzt könnte an dieser Stelle noch weiter fortgeführt werden da es hierfür Unmengen an
+Programmen gibt. \newline
+
+Allerdings nutzen diese Programme, die oft auf \textit{Google Maps} basieren, immer das Prinzip eines zentralen Knotenpunktes, an
+welchen die Positionsdaten gesendet werden und dieser diese dann weiterleitet. Somit existiert immer eine zentrale
+Kontrollinstanz, welche Einsicht in die Daten der Nutzer hat, während die Nutzer selbst immer nur Zugang zu den für sie bestimmten
+ Daten besitzen. Somit können die Nutzer auch nicht die Nutzung ihrer Daten durch den Anbieter einsehen. Die folgen hiervon
+könnten sein, dass zum Beispiel der Anbieter gezielt Werbung für die Position der Nutzer einspielt, da er ihren Aufenthaltsort
+immer kennt. \newline
+
+Bestehende Software dieser Art verschlüsselt auch in den seltensten Fällen die versendeten Daten. Da es sich bei Positionsdaten
+um sehr sensible Daten handelt ist dies ein großes Manko. So können Dritte den Datenverkehr abhören und auch Positionsdaten von
+Nutzern erhalten die diese nur einer bestimmten Gruppe zur Verfügung stellen wollten. Sind diese Positionsdaten ersteinmal
+gesammelt können ohne weiteres Bewegungsprofile erstellt und missbraucht werden. Der Benutzer begibt sich also mit der Nutzung von
+solchen Programmen in die Gefahr das regelmäßige Aufenthaltsorte erkannt werden und der ständig aufspürbar ist. Somit stellen
+solche Dienste, die sensible Daten dieser Art ohne Verschlüsselung versenden, eine starke Einschränkung für die Privatsphäre dar.
+\newline
+
+\subsection{Ziele}
+
+Die obigen zwei Punkte wurden bisher in den meisten Fällen noch nicht als Software realisiert. Somit besteht seitens der Nutzer
+mit Sicherheit eine Nachfrage nach einer Software welche ihre Persönlichen Daten auf sicherem Wege schützt und trotzdem noch die
+gewohnte Funktionalität bietet. Hierfür muss sichergestellt werden, dass es dem Nutzer ohne Fachkentniss möglich ist, Schlüssel
+zur Verschlüsselung untereinander auszutauschen und somit festzulegen wer alles diese Positionsdaten erhalten darf. Des
+weiteren muss beim Schlüsselaustausch gewährleistet sein, dass der Schlüssel auf eine Sichere Art und weiße übertragen
+wird, ohne das andere diesen abfangen können. Hierbei muss allerdings beachtet werden, dass diese Software auf mobilen Geräten
+lauffähig sein soll. Es muss also gewährleistet werden dass die genutzten Algorithmen nicht zu berechnungsintensiv sind, die
+Sicherheit der Daten aber trotz allem gewährleistet ist. \newline
+
+Da auch ein zentraler Knoten, über den der gesamte Datenverkehr aller Benutzer läuft, unerwünscht ist, muss hier ein
+Kommunikationsdienst genutzt werden, welcher nach einem dezentralen Prinzip funktioniert. Auch hier muss, wie bei der
+Datenverschlüsselung, gewährleistet sein dass die Bedinung für den Anwender möglichst einfach gehalten wird und er somit ohne
+Aufwand und Fachwissen die Kommunikationsparameter einrichten und ändern kann. \newline
+
+Da mittlerweile eine große Anzahl an unterschiedlichen Plattformen für mobile Geräte existieren, sollte gewährleistet sein dass
+die Software auf möglichst vielen dieser Betriebssystemen lauffähig ist. So ist gewährleistet, dass möglichst viele Benutzer
+erreicht werden. \newline
+
+\subsection{Anwendungsmöglichkeiten}
+
+Wenn nun eine Benutzergruppe diese Programm nutzen möchte, so sollte sie in der Lage sein mit einfachen mitteln die nötigen
+Parameter zu verteilen. Hierzu betrachten wir den möglichen Fall, dass eine Gruppe von Touristen in einer ihnen fremden Stadt
+unterwegs sind. Diese möchten nun auf eigene Faust diese Stadt erkunden. Hierzu müssen zuerst geignete Kartendaten vorhanden
+sein. Hier sollten, wenn möglich, freie Kartendaten verwendet werden um Nebenkosten zu verringern. Es muss allerdings darauf
+geachtet Ist dies der Fall, so wird ein Schlüssel erstellt und an alle Teilnehmer dieser Gruppe verteilt. Beim verteilen stellt
+sich nun die Frage wie dies ohne großen Aufwand aber mit maximaler Sicherheit möglich ist. Hier könnte nun ein Gruppenmitglied
+einen oder mehrere Schlüssel erstellen und diese sich in Form eines \textit{2D-Barcodes} ausgeben lasen. Dieser Barcode kann nun
+von den anderen Nutzern, mit deren Smart Phones, gescannt und wieder in einen Schlüssel, bestehend aus Zeichenketten, umgewandelt
+werden. Da dies keine Kommunikation zwischen den Geräten erfordert kann kein dritter diese Schlüssel während der Datenübertragung
+abfangen.\newline
+Nun stellt sich allerdings auch die Frage nach der Anzahl der zu verteilenden Schlüssel. Je nach Art der Verschlüsselung reicht
+ein Schlüssel aus, oder sind mehrere nötig. Würde die Software eine asymmetrische Verschlüsselung benutzen, so müsste jeder
+Nutzer einen privaten Schlüssel erstellen und sich, mittels scannen eines Barcodes, den öffentlichen Schlüssel besorgen. Dies
+hätte zur folge das man, je nach Gruppe mit der kommuniziert werden soll, immer mehrere Schlüssel besitzen und verwalten müsste.
+Je nach gewähltem Verfahren kann auch zusätzlich noch ein Zertifikat für diese Schlüssel hinzukommen. Der normale Benutzer müsste
+hier also schon seine Schlüssel richtig verwalten. Ein symmetrischen Kryptographieverfahren hätte hier den Vorteil, dass man nur
+einen Schlüssel an alle Benutzer der Gruppe verteilen müsste. Des weitern fällt der Verwaltungsaufwand hier wesentlich geringer
+aus, da nur ein Schlüssel pro Gruppe von nöten ist. Was des weiteren auch noch für ein symmetrisches Verfahren sprechen würde,
+ist die Tatsache dass diese einen wesentlich geringeren Berechnungsaufwand haben und somit der Akku länger halten würde.\newline
+Nachdem diese Gruppe von Touristen nun ihre Schlüssel ausgetauscht haben erkunden sie unabhängig voneinander die Stadt. Dabei
+möchten sie sehen wo die anderen Mitreisenden sich gerade befinden. Allerdings ist es für die Teilnehmer hier nicht von
+Interesse, die anderen Teilnehmer auserhalb eines bestimmten Radiuses zu sehen, da der Fussweg zu deren Standort zu weit wäre. Es
+wäre also nützlich für den Benutzer wenn er ab einem bestimmten Radius die anderen Teilnehmer ausblenden könnte. Endeckt nun ein
+Mitglied dieser Reisegruppe eine besondere Sehenswürdigkeit, möchte er dies vielleicht einem Freund aus der Reisegruppe
+mitteilen. Zu diesem Zweck bräuchte er eine Chatfunktion, mit welcher er andere Gruppenmitglieder kontaktieren und mit ihnen
+Nachrichten austauschen kann. Allerdings sollte auch diese Funktion aus Gründen der Privatsphäre Daten nur in einem
+verschlüsselten Format übertragen. Des weiteren sollte es möglich sein nur mit dieser einen Person gezielt zu chatten, ohne das
+die gesamte Gruppe mithören kann. Natürlich könnte man sich auch hier noch eine Zusatzfunktion überlegen, die einen Chat mit
+der gesamten Gruppe ermöglicht. Wenn dieser Tourist nun seinen Freund per Chat kontaktiert hat, können sich diese nun einen
+Treffpunkt verabreden und diesen entweder auf der Karte dem anderen Teilnehmer senden und im Anschluss den Weg dorthin sich
+errechnen lassen. \newline
+
+Ein weiterer möglicher Fall wäre dass man mit Freunden kommunzieren möchte, aber keine \textit{UMTS} Datenflatrate
+besitzt. Es sollte also auch sichergestellt sein dass die Datenpakete, welche versandt werden, nicht allzu groß sind und auch die
+Anzahl der Hintergrunddaten, die vom verwendeten Protokoll versandt werden, nicht zu groß ist. So ist zum einen gesichert das
+nicht zu hohe Verbindungskosten entsehen und zum anderen auch der Berechnungsaufwand für das erstellen und versenden dieser
+Pakete nicht zu groß ist. \newline
+
+\subsection{Anforderungen}
+
+Anhand der zwei vorrangegangenen Beispielen ist gut erkennbar was an Funktionalität benötigt wird. So sollte es möglich sein die
+Standorte anderer Nutzer zu auf einer Karte zu anzuzeigen. Damit für andere Nutzer die eigene Position sichtbar ist, muss diese in
+einem gängigen Format versendet werden. Hierfür ist das Format \textit{Latitude}/\textit{Longtitude} bestens geignet. Um
+die Datensicherheit zu garantieren müssen diese Positionsdaten in verschlüsselter Form versendet werden. \newline
+
+Um die Position anderer Teilnehmer zu visualisieren muss das Programm in der Lage sein, die eigehenden Positionsdaten sowohl zu
+entschlüsseln, als auch diese auf einer Karte darzustellen. Des weiteren 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. Es sollte auch möglich sein, nur
+Benutzer innerhalb einer bestimmten Entfernung anzuzeigen, da eine Person die sich in 6 Kilometer Entfernung aufhält für Dienste
+dieser Art nur begrenzt sinnvoll sind. \newline
+
+Um die Kommunikation zwischen verschiedenen Teilnehmern zu ermöglichen sollte es möglich sein Chatnachrichten auszutauschen. Auch
+hier muss gewährleistet sein das der Datenverkehr verschlüsselt ablaufen muss und somit dritte nicht die Konversation mitlesen
+können. \newline
+
+Um einen Schlüssel an eine Person weiterzugeben, deren Positon man sehen oder mit ihr kommunizieren möchte, muss es eine
+Möglichkeit geben diesen Schlüssel auf einfach Weise weiterzugeben. Hierzu kann aus einer vorher festgelegten Zeichenkette einen
+2D-Barcode erstellt und angezeigt werden. Zur Weitergabe des Schlüssels muss nun der andere Anwender diesen vom Display
+fotographieren. \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 Verschlüsselung bieten. Wie schon erwähnt ist aufgrund von sowohl Berechnungsaufwand als auch von
+Schlüsselverwaltung 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. Die Daten werden also
+durch Client A ver- und von Client B entschlüssel. \newline
+Die Schlüssel können, wie schon beschrieben, durch das Erstellen eines \textit{2D-Barcodes} und das fotographieren von diesem
+ausgetauscht werden.
+
+Für die Kommunikation zwischen den einzelnen Teilnehmern ist ein dezentrales Protokoll von nöten, welches möglichst wenig
+Daten verschickt welche 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
+Eine Möglichkeit wäre hier eine \textit{Peer-to-Peer} Lösung. Allerdings verbietet ein Großteil der \textit{GSM}-Provider
+\textit{Peer-to-Peer} Datenverkehr innerhalb ihrer Netze, womit diese Lösung praktisch nicht anwendbar wäre. Ein Vorhandenes
+Protokoll, welches ein aktives Netzwerk bereitstellt und dieses und auch rege genutzt wird, ist das \textit{IRC}-Protokoll
+\citep{IRC}. Dieses stellt mehrere Server zur Verfügung, wobei jeder Nutzer auch einen eigenen Server bereitstellen kann, die
+mehrere \textit{Channels} haben können. \textit{IRC} ist ein Chatprotokoll welches auch Dateien versenden kann. Würde nun ein
+Server ausfallen, so könnten die Nutzer auf einen anderen \textit{IRC}-Server wechseln. 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.\newline
+
+Durch die Wahl dieser Lösung ist also garantiert, dass sowohl die Berechnungszeiten durch ein symmetrisches Verfahren niedrig
+gehalten werden, der Verwaltungsaufwand für die Schlüssel ist gering da nur ein Schlüssel pro Gruppe gespeichert werden muss 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 diesen nur in verschlüsselter Form. Des
+weiteren kann jeder beliebige \textit{IRC}-Server gewählt werden. Somit sind die Eingangs erwähnten Punkte, Verschlüsselung und
+dezentralles Protokoll, hiermit abgedeckt und die Privatsphäre ist für den Anwender, anderst als bei anderen Anwendungen
+dieser Art, gesichert. \ No newline at end of file