summaryrefslogtreecommitdiffstats
path: root/ausarbeitung/Grundlagen.tex
diff options
context:
space:
mode:
authorPatrick Hornecker2010-02-18 19:11:15 +0100
committerPatrick Hornecker2010-02-18 19:11:15 +0100
commit88bb54e30a038269e33fd3b14f3bf321f0cb96c8 (patch)
tree7bf54973611ac14d974f9a07a6cff87093dae706 /ausarbeitung/Grundlagen.tex
parenttex source (diff)
downloadfriendfinder-88bb54e30a038269e33fd3b14f3bf321f0cb96c8.tar.gz
friendfinder-88bb54e30a038269e33fd3b14f3bf321f0cb96c8.tar.xz
friendfinder-88bb54e30a038269e33fd3b14f3bf321f0cb96c8.zip
tex source
Diffstat (limited to 'ausarbeitung/Grundlagen.tex')
-rw-r--r--ausarbeitung/Grundlagen.tex246
1 files changed, 135 insertions, 111 deletions
diff --git a/ausarbeitung/Grundlagen.tex b/ausarbeitung/Grundlagen.tex
index f66bf6b..f9634e2 100644
--- a/ausarbeitung/Grundlagen.tex
+++ b/ausarbeitung/Grundlagen.tex
@@ -1,54 +1,99 @@
\section{Grundlagen}
-In diesem ersten Teil dieser Bachelor-Arbeit wird der momentane Stand von \textit{location awareness} Software auf mobilen
-Geräten aufgezeigt. Es wird auch analysiert, was für Anforderungen an ein Programm dieser Art gestellt werden um einen sicheren
-Datenverkehr zu garantieren.
+In diesem ersten Teil dieser Bachelor-Arbeit 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 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
+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. 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 Programm 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. Für diesen Dienst wurde auch mit ein möglichst einfaches und verlässliches
-Protokoll entworfen, mit dem Ziel 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 mit Hilfe von \textit{Bluetooth} zu bestimmen. Hierbei registrierte eine Software wie oft welcher Nutzer mit
-einem anderen in Kontakt stand und wie oft sie in \textit{Bluetooth} Reichweite 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, meistens 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 stellt dies ein großes Manko dar. So könnten 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 erst einmal 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
+existieren auch eine Menge von Anwendungen, die die eigene Position für Freunde sichtbar macht.\newline
+So bietet \textit{Google} beispielsweise 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
+Es wurde in einer Befragung von Versuchspersonen herausgefunden, dass diese keine Bedenken im Bezug auf Positionsdaten und
+Privatsphäre haben \citep{location}. Da es aber immer mehr solcher Dienste gibt, sollte man gerade zum Schutz dieser Benutzer,
+Anwendungen entwickeln welche Wert auf die Wahrung \textit{location privacy } legen.\newline
+Um die Positionsdaten auf optimale Art und Weiße zu schützen, sollten diese nur in einem verschlüsselten Format
+versendet werden. Positionsdaten stellen für den Nutzer sensible Daten dar, da sie viel über seine Gewohnheiten und täglichen
+Ablauf verraten können. Wenn man diese Daten unverschlüsselt versendet so begibt man sich in die Gefahr das regelmäßige
+Aufenthaltsorte erkannt werden oder man sogar ständig aufspürbar ist, was eine erhebliche Verletzung der \textit{location
+privacy} darstellen würde.\newline
+Mit der Thematik von verschlüsselter Datenübertragung auf mobilen Geräten befasst sich eine Arbeit 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. Es wurde ein möglichst einfaches und verlässliches Protokoll entworfen, mit
+dem Ziel die Berechnungszeiten niedrig zu halten. \newline
+
+Ein anderes Problem stellt die Nutzung von zentral organisierten Netzen dar. Hier ist es möglich, ohne das der Benutzer davon
+Kentniss hat, auf alle über diesen Knoten versandten Daten zuzugreifen. Dies könnte durch die Nutzung eines dezentralen,
+verteilten Systems eingeschränkt werden. Somit würde nicht nur keine Kontrollinstanz existieren, welche Einsicht in die Daten der
+Nutzer hat während die Nutzer selbst immer nur Zugang zu den für sie bestimmten Daten besitzen, sondern man könnte die Daten auf
+mehrere Knoten verteilen. Diese Tatsache würde das gezielte Sammeln von Daten erschweren und somit der oben genannten Defintion
+von \textit{location privacy} entgegenkommen.\newline
+
+\subsection{Anwendungsmöglichkeiten}
+
+Die Verbreitung von solchen mobilen Geräten hat in den letzten Jahren beständig zugenommen und alle neueren Modelle besitzen ein
+\textit{GPS}-Modul. Des weiteren sind alle modernen Geräte in der Lage, Daten sowohl über den \textit{3G}-Standart
+sowie per \textit{WLAN} zu übertragen. Wenn nun eine Gruppe, welche mit entsprechenden mobilen Geräten ausgestattet ist,
+die Positionen austauschen möchte, so wird zuallerst ein Protokoll benötigt welches die Daten versenden kann. Dieses Protokoll
+sollte sowohl verlässlich als auch für langsame Netze konzipiert sein. Im nächsten Schritt soll diese Verbindung nun nur
+verschlüsselte Daten übertragen. Hierzu wird also ein geeigneter Algorithmus benötigt, welcher die Daten verschlüsselt. Dieser
+sollte dabei bei möglichst wenig Berechnungsaufwand eine möglichst gute Verschlüsselung bieten.\newline
+Will man nun Daten verschlüsseln so benötigen sowohl Sender als auch Empfänger die gleichen Schlüssel. Es wird also auch eine
+Möglichkeit gesucht, mit deren Hilfe man Schlüssel auf eine sichere Art und Weiße übertragen kann. Sind diese Anforderungen
+erfüllt, so können die Mitglieder dieser Gruppe nun ihre Positionsdaten austauschen, ohne diese Möglichweiße Personen mitzuteilen
+für die diese nicht bestimmt sind.\newline
+Mit diesem gegebenen Protokoll und den Verschlüsselungsverfahren ist es nun ohne weiteres möglich auch Textnachrichten zwischen
+zwei Mitgliedern einer Gruppe auszutauschen. \newline
+%Wenn nun eine Benutzergruppe dieses Programm nutzen möchte, so sollte dies für sie mit einfachen Mitteln möglich sein. Hierzu
+%betrachten wir den Fall, dass eine Gruppe von Touristen in einer ihnen fremden Stadt
+%unterwegs ist. Die Reiseteilnehmer möchten nun auf eigene Faust die Stadt erkunden. Da die Gruppeteilnehmer ihre Daten nicht
+%öffentlich preisgeben wollen, möchten sie ein verschlüsselte Verbindung untereinander aufbauen. Dazu wird im ersten Schritt ein
+%oder mehrere Schlüssel benötigt. Beim Verteilen der Schlüssel 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 an die
+%jeweiligen Teilnehmer senden. Nach dem Austausch der Schlüssel kann nun über eine beliebige Infrastruktur eine Verbindung mit den
+%anderen Teilnehmern der Gruppe aufgebaut werden. \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 es 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 zugehörigen ö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. 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.
+%Zusätzlich würde auch noch für ein symmetrisches Verfahren sprechen,dass diese einen wesentlich geringeren Berechnungsaufwand
+%haben und somit der Akku länger halten würde.\newline
+%Wenn diese Gruppe sich nun aufteilt, um getrennt die Stadt zu erkunden, so kann nun über die bestehnde Verbindung kommuniziert
+%werden. Die Gruppenteilnehmer möchten hierbei sehen wo die anderen Mitreisenden sich gerade befinden. Allerdings ist es für die
+%Teilnehmer hier nicht von Interesse, die Position weit entfernter Teilnehmer 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 Abstand 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 wäre hier noch eine Zusatzfunktion möglich, die einen Chat mit der gesamten Gruppe
+%%verfügbar macht. Wenn dieser Tourist nun seinen Freund per Chat kontaktiert hat, können sich diese nun einen Treffpunkt
+%verabreden
+%und diesen auf der Karte dem anderen Teilnehmer senden und im Anschluss sich den Weg dorthin errechnen lassen. \newline
\subsection{Ziele}
-Die obigen zwei Punkte wurden bisher in den meisten noch nicht berücksichtigt. 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 sein, dass es den Nutzern 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 sollte also gewährleistet werden dass die genutzten Algorithmen nicht zu berechnungsintensiv sind, die
-Datensicherheit aber trotz allem gegeben ist. \newline
+Die Anwendung eines solchen Programmes soll dem Nutzer möglichst einfach gemacht werden und trotzdem die gesetzten Ziele, wie die
+Verschlüsselung der Daten und Nutzung einer dezentralen Infrastruktur, erfüllen. \newline
+
+Es soll also sicher gestellt sein, dass es auch Benutzern ohne Fachkentniss möglich ist, die benötigten Schlüssel untereinander
+auszutauschen und somit festzulegen wer alles diese Positionsdaten einsehen 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 mitlesen können.
+Hierbei muss allerdings beachtet werden, dass diese Software auf mobilen Geräten lauffähig sein soll. Es sollte also gewährleistet
+werden dass die genutzten Algorithmen nicht zu berechnungsintensiv sind, die Datensicherheit aber trotz allem gegeben 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 ein dezentrales Prinzip verfolgt. Auch hier muss, wie bei der
+Kommunikationsdienst genutzt werden, welcher ein dezentrales Prinzip verfolgt. Auch hier muss, wie bei der
Datenverschlüsselung, gewährleistet sein dass die Bedienung für den Anwender möglichst einfach gehalten wird und er somit ohne
Aufwand und Fachwissen die Kommunikationsparameter einstellen und abändern kann. \newline
@@ -56,96 +101,75 @@ Da mittlerweile eine große Anzahl an unterschiedlichen Plattformen für mobile
die Software auf möglichst vielen dieser Betriebssystemen lauffähig ist. So ist sichergestellt, dass möglichst viele Benutzer
erreicht werden. \newline
-\subsection{Anwendungsmöglichkeiten}
-
-Wenn nun eine Benutzergruppe dieses 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 werden das diese möglichst immer auf einem aktuellen Stand sind. Wenn so eine Karte vorhanden ist, so kann im
-nächstenwird Schritt ein Schlüssel erstellt und an alle Teilnehmer dieser Gruppe verteilt werden. 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 es 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 zugehörigen ö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. 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.
-Zusätzlich würde auch noch für ein symmetrisches Verfahren sprechen,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 Abstand 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 wäre hier noch eine Zusatzfunktion möglich, die einen Chat mit der gesamten Gruppe
-verfügbar macht. Wenn dieser Tourist nun seinen Freund per Chat kontaktiert hat, können sich diese nun einen
-Treffpunkt verabreden und diesen 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 und kein öffentliches WLAN in Reichweite ist. Es sollte also auch sichergestellt sein dass die Datenpakete, welche
-versandt werden, nicht allzu groß sind. Auch die Anzahl der Hintergrunddaten, die vom verwendeten Protokoll versandt werden,
-sollten 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
+Anhanden der Anwendungsmöglichkeiten lassen sich die Anforderungen, die an die Software gestellt werden, ableiten. So sollte
+es möglich sein die Standorte anderer Nutzer anzuzeigen. Damit für andere Anwender 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, da es sich um das am meisten verbreitetste Format handelt und es möglich ist jeden Punkt auf der Erdeerfläche ob in
+diesem Geokoordinatensystem darzustellen. Um zu verhindern dass die Daten von jedem gelesen werden können 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
+Um die Position anderer Teilnehmer zu visualisieren sollte 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
+Benutzer innerhalb einer bestimmten Entfernung anzuzeigen, da eine Person die sich in sechs 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
+hier muss gewährleistet sein, dass der Datenverkehr verschlüsselt abläuft und somit das mitlesen der Konversation nicht möglich
+ist. \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
+Möglichkeit geben diesen Schlüssel auf einfach Weise weiterzugeben. Es ist allerdings darauf zu achten, dass dieser
+Schlüssel nicht während der übertragung abgefangen werden kann, da die Kommunikation ansonsten nichtmehr sicher wäre.\newline
+
+Auf dem Markt sind aktuell viele unterschiedliche Betriebsysteme für Smartphones vertreten. Um möglichst viele Benutzer zu
+erreichen sollte das Programm der Lage sein auf möglichst vielen dieser Plattformen zu arbeiten. Im Zuge dieser
+Plattformunabhängigkeit sollte die Software in einer Sprache implementiert werden, die von möglichst vielen
+Betriebssystemen der mobilen Geräte unterstützt wird. \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 Verschlüsselung bieten. Aus Gründen von Berechnungsaufwand als auch von Schlüsselverwaltung ist ein symmetrisches
+bestmögliche Verschlüsselung bieten. Aus Gründen des Berechnungsaufwand als auch von 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. 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
-zwischen den Anwendern Ausgetauscht werden.
+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
+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
-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. Jeder Server verwaltet mehrere \textit {Channels}. Würde nun ein Server ausfallen, so könnten die Nutzer auf einen anderen
+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
-
-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 gering ist 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, im Unterschied zu den meisten anderen Anwendungen dieser Art, gesichert. \ No newline at end of file
+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. Somit
+sind die Eingangs erwähnten Punkte, Verschlüsselung und dezentralles Protokoll, hiermit abgedeckt und die Privatsphäre ist für den
+Anwender, im Unterschied zu den meisten anderen Anwendungen dieser Art, gesichert. \ No newline at end of file