summaryrefslogtreecommitdiffstats
path: root/ausarbeitung/Friend_Finder.tex
diff options
context:
space:
mode:
Diffstat (limited to 'ausarbeitung/Friend_Finder.tex')
-rw-r--r--ausarbeitung/Friend_Finder.tex169
1 files changed, 61 insertions, 108 deletions
diff --git a/ausarbeitung/Friend_Finder.tex b/ausarbeitung/Friend_Finder.tex
index e823035..4c59b03 100644
--- a/ausarbeitung/Friend_Finder.tex
+++ b/ausarbeitung/Friend_Finder.tex
@@ -1,80 +1,13 @@
\section{Friend Finder}
-So gut wie alle Geräte der heutigen Generation von Smart Phones besitzen einen GPS Empfänger. Dieser kann auf unterschiedliche
-Art und Weiße genutzt werden. Von einfachem bestimmen der aktuellen Position, über Routing bis hin zu Freizeitaktivitäten wie
-\textit{Geocaching}. Eine weitere, interessante Möglichkeit wäre es, sich Freunde anzeigen zu lassen, die sich in
-einem bestimmten Radius um die eigene Position befinden. Mit diesen könnte man dann, ähnlich wie mit einem Chat Programm,
-Nachrichten austauschen.\newline
-Da es unter Datenschutzaspekten aber nicht wünschenswert ist das jeder Dritte die Position anderer ermitteln kann, sollten die
-Daten verschlüsselt versendet werden. Ansonsten könnte es zu Szenarien, wie das erstellen eines Bewegungsprofiles der Benutzer,
-kommen. Es muss somit gewährleistet sein, dass die gesendeten Daten nur dann lesbar sind, wenn der Nutzer dem einwilligt. \newline
-
-Mit einer solchem Programm wäre es zum Beispiel möglich, sich mit Freunden zum Essen zu verabreden, wenn diese sich in der Nähe
-der eigenen Position befinden. Der Nutzer sollte einfach nur den Radius wählen, innerhald dessen Personen sichtbar sind, und
-könnte diese dann per verschlüsselter Textnachricht anschreiben. \newline
-Eine andere Möglichkeit bestünde darin, dass man auf bestimmten Veranstaltungen wissen möchte wer teilnimmt. Dabei stellt
-der Nutzer allerdings fest das eine ihm bekannte Person die gleiche Software nutzt, aber für ihn nicht sichtbar ist. Der
-Benutzer muss nun die Möglichkeit haben dieser Person ohne aufwand den für die Verschlüsselung genutzen Schlüssel zu
-übergeben.\newline
-
-Eine ähnliche Software wurde schon im Paper \textit{Spontaneous Privacy-Aware Location Sharing} \citep{SPALS} beschrieben und
-implementiert. Allerdings lag bei dieser Arbeit der Focus auf einem effizienten Protokoll zur verschlüsselten
-Positionsübertragung. Der Aspekt, dass Nutzer nur innerhalb eines begrenzten Radius angezeigt werden, wurde hier nicht
-berücksichtigt. Auch die Software \textit{SmokeScreen} \citep{SmokeScreen} beschäftigt sich mit versenden privater Informationen
-innerhalb von Gruppen die der Nutzer festlegt. Allerdings bewegt sich \textit{SmokeScreen} nich im Rahmen von \textit{location
-awareness}. Somit sollte die Software ein effizientes Protokoll, eine sichere Verschlüsselung sowie die Möglichkeit der
-Einstellung durch den Anwender verbinden.
+Die eingangs beschriebene Software hat den Namen \textit{Friend Finder} und wurde im Rahmen dieser Arbeit mit fast allen
+aufgezählten Funktionen realisiert. Das fotographieren des Barcodes sowie der Gruppenchat sind in der Implementation nicht
+enthalten. Im folgenden wird auf die Verwendeten Verfahren sowie Bibliotheken, die zur Realisierung notwendig waren, eingegangen.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\subsection{Anforderungsanalyse}
-
-Anhand der oben erstellten Szenarien sollte diese Software also folgende Funktionen besitzen:
-
-\begin{itemize}
- \item Versenden von Nachrichten
- \item Versenden der eigenen Position
- \item Anzeigen der Position von anderen Teilnehmern
- \item Erstellen eines 2D-Barcodes
- \end{itemize}
-
-\subsubsection{Eigene Position senden}
-
-Um den Standort anderer Nutzer zu sehen, muss das Programm in der Lage sein, auf einer Karte deren Position anzuzeigen. Damit
-für andere Nutzer die eigene Position sichtbar ist, muss diese in einem gängigen Format versendet werden. Hierfür fiel die Wahl
-auf das Standart Positions Format \textit{Latitude}/\textit{Longtitude}. Um Datensicherheit zu garantieren müssen diese
-Positionsdaten in verschlüsselter Form versendet werden.
-
-\subsubsection{Position anderer Teilnehmer anzeigen}
-
-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.
-
-\subsubsection{Nachrichten versenden und empfangen}
-
-Damit man mit anderen Nutzern, welche sich in der Nähe der eigenen Position befinden, auch Kommunizieren kann, muss die Software
-in der Lage sein Textnachrichten zu versenden und zu empfangen. Auch soll die Datensicherheit garantiert sein. Der Datenverkehr
-muss also auch bei dieser Funktion in verschlüsselter Form stattfinden.
-
-\subsubsection{2D-Barcode}
-
-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 oder per MMS versenden und auf dem anderen Gerät wiederherstellen.
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
\subsection{Verwendete Verfahren und Bibliotheken}
-Die oben beschriebene Software wurde mit fast all diesen Funktionen, ausser das abfotographiern und umwandeln der 2D-Barcodes in
-einen Schlüssel, im Rahmen dieser Arbeit implementiert und hört auf den Namen \textit{Friend Finder}. Im folgenden Abschnitt wird
-die Implementierung und Funktionsweise der einzelnen Funktionen erläutert, sowie die zugrundeliegenden Bibliotheken vorgestellt.
-\newline
-
\textit{Friend Finder} wurde so konzipiert, dass die Graphische Darstellung ohne großen Aufwand vom den restlichen
Teilen der Software abgekoppelt und durch eine andere, darstellende Bibliothek ersetzt werden kann. Somit
könnte man \textit{Enlightenment} durch eine andere Art der Darstellung austauschen, ohne dabei die Funktionalität der
@@ -92,17 +25,6 @@ empfangenen Daten an die \textit{GUI} weiter, welche sie mit Hilfe von \textit{E
\caption{\textit{Friend Finder} Nachrichtenaustausch}
\end{figure}
-
-\textit{Friend Finder} ist an sich in fünf Submodule aufgeteilt:
-
-\begin{enumerate}
- \item Graphische Benutzeroberfläche
- \item Versenden von Textnachrichten
- \item Versenden der eigenen Position
- \item Empfangen der eigenen Position
- \item Erstellen eines Barcodes
-\end{enumerate}
-
\subsubsection{Grafisches Benutzeroberfläche}
Zum erstellen der Oberfläche wurde \textit{Enlightenment} verwendet. Diese Bibliothek stellt alle benötigten Funktionen bereit und
@@ -135,7 +57,13 @@ Empfänger wieder zusammengesetzt. \newline
Ein weiterer wichtiger Unterschied zu den Modulen Senden und Empfangen von \textit{GPS}-Positionen ist die Tatsache, dass bei
diesem Programmteil Sender und Empfänger in der gleichen Datei implementiert wurden. Der Grund hierfür ist, dass man hier nicht
zwischen mehreren Sendern oder Empfängern unterscheiden muss, und diese zwei Teile hier somit nicht komplett getrennt voneinander
-arbeiten müssen.\newline
+arbeiten müssen. In der folgenden Abbildung ist eine Konversation über \textit{Friend Finder} zu sehen.\newline
+
+\begin{figure}[h]
+\centering
+ \includegraphics[width=5cm]{Bilder/chat}
+ \caption{Versenden von Chatnachrichten}
+\end{figure}
Um Nachrichten zu versenden wurde für dieses Projekt die \textit{IRC-Client Bibliothek}\citep{libircclient} verwendet. Diese
\textit{library} bietet verschiedene Funktionen um eine Verbindung mit einem \textit{IRC-Server} zu erstellen und Nachrichten an
@@ -156,6 +84,7 @@ Bestätigung ist unverschlüssel. Kommt dieses \textit{Acknowledgement} beim Sen
Auch hier wird, wie beim Versenden der Nachrichten zum verschlüsseln der \textit{Blowfish-Algorithmus} aus \textit{libcrypto},
sowie \textit{libircclient} zum versenden der Daten genutzt.
+
\subsubsection{Empfangen der eigenen Position}
noch nicht final....empfänger empfängt nachricht, ordnet sie, leitet sie zum zeichnen weiter....grob gesehen
@@ -165,6 +94,16 @@ noch nicht final....empfänger empfängt nachricht, ordnet sie, leitet sie zum z
Die Datei \textit{barcode.c} beinhaltet die Funktionen zum erstellen eines 2D-Barcodes. Hierzu wird die Funktion
"\textit{generate\_barcode(char* key)}", mit einer Zeichenkette als Übergabeparameter, aufgerufen. Aus dieser Zeichenkette wird
dann ein Barcode erstellt, welcher im darauf folgenden Schritt als \textit{.png} Datei auf das Speichermedium geschrieben wird.
+Zum erstellen des Barcodes wurde die offene Bibliothek \textit{qrencode} \citep{qrencode} genutzt. Diese erstellt aus einer
+Zeichenkette einen 2D-Barcode. Aus den Bilddaten dieses Barcodes wurde mit \textit{libpng} \citep{PNG} eine \textit{.png} Datei
+erstellt. Die untere Abbildung zeigt einen solchen erstellten Barcode, wie er von \textit{Friend Finder} ausgegeben wird.
+
+\begin{figure}[h]
+\centering
+ \includegraphics[width=5cm]{Bilder/barcode}
+ \caption{2D-Barcode mit \textit{Friend Finder}}
+\end{figure}
+
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -172,40 +111,55 @@ dann ein Barcode erstellt, welcher im darauf folgenden Schritt als \textit{.png}
Das Ziel war es mit \textit{Friend Finder} Daten verschlüsselt zu übertragen. Es soll dabei ein möglichst geringer
Berechnungsaufwand entstehen um die Daten zu verschlüsseln, sowie möglichst wenig Datenoverhead produziert und versendet werden.
-Dies ist notwendig, damit das Programm möglichst lange auf dem mobilen Gerät ausgeführt werden kann und nicht schon nach
-kurzer Zeit der Akku versagt. \newline
+Unter Datenoverhead werden die Hintergrunddaten gesehen, welche versendet werden um zum Beispiel die Verbindung
+zwischen Client und Server aufrecht zu erhalten oder um zu kontrollieren ob Server oder Client noch verfügbar sind. Diese Daten
+ sind von Interesse da mit vielen versendeten Daten ein höherer Anspruch des Rechenkerns einhergeht, was wiederrum in einem
+höheren Stromverbrauch resultiert.\newline
Im folgenden Teil wird der erzeugte Datenverkehr von \textit{Friend Finder} analysiert. Ein Hauptaugenmerkt wird hierbei vor allem
auf die Packetgröße, sowie die Menge der versendeten Datenpakete geworfen. Der \textit{Traffic} wurde mit Hilfe des Programmes
-\textit{Wireshark} \citep{Wireshark} untersucht.\newline
+\textit{Wireshark} \citep{Wireshark} untersucht.Wie bereits erwähnt wird zum Versenden der Nachrichten das \textit{IRC-Protokoll}
+verwendet. In dieser Testumgebung wurde die Software \textit{IRCD-Hybrid} \citep{IRCD} genutzt. Der Server lief auf dem gleichen
+Computer wie der Client und der Client hat sich über das \textit{localhost} Interface mit dem Server verbunden. \newline
-Die Analyse selbst ist in drei Teile aufgeteilt. Als erstes wird auf den allgemein entstehenden Datenverkehr eingegangen, welcher
+Die Analyse ist in drei Teile aufgeteilt. Als erstes wird auf den allgemein entstehenden Datenverkehr eingegangen, welcher
bei Verbindungsaufbau, sowie bei Beenden der Verbindung entsteht. Der zweite Teil beschäftigt sich mit dem Versenden sowie
Empfangen von Nachrichten. Im letzten Teil dieser Analyse wird auch das dritte Feature, dass Versenden und Empfangen von
Positionen, unter die Lupe genommen.
\subsubsection{Allgemeiner Datenverkehr}
-Wie bereits erwähnt wird zum Versenden der Nachrichten das \textit{IRC-Protokoll} \citep{IRC} verwendet. Dieses Protokoll basiert
-\textit{TCP/IP} und führt somit bei Verbindungsaufbau einen \textit{TCP-Handshake} durch. Des weiteren werden
-während der gesamten Verbindungsdauer \textit{ACK-} oder \textit{NACK-Pakete} für jede Nachrichten versendet. \newline
-
-Während einer bestehenden Verbindung zu einem \textit{IRC-Server} schicken sich Server und Client fortlaufend Nachrichten. So
-sendet der Client zum Beispiel immer eine "Who" Anfrage an den Server, welcher dann mit allen im Channel eingelogten Nutzern
-antwortet.\newline
-
-Wird eine bestehnde Verbindung beendet, so entsteht auch hier wieder Datenverkehr, da \textit{TCP} auch beim Beenden einer
-Verbindung ein eigenes Verfahren nutz. Bei diesem wird ein Paket versendet welches angibt dass die Verbindung nun beendet wird.
-Dieses Paket wird auch wieder bestätigt. Diese beiden Pakete werden von beiden Seiten der Kommunikation versandt.\newline
+Bei Messung des allgemeinen Datenaufkommens mit eine normalen \textit{IRC-Clients}, hier \textit{X-Chat} \citep{xchat}, ergeben
+sich folgender Datenverkehr. \newline
+Beim Verbindungsaufbau sendet der \textit{IRC}-Server zuerst ein Paket mit Informationen wie Limit der \textit{Channels}
+oder Anzahl der aktiven Benutzer. Dieses Paket hatte in der Versuchsumgebung eine Größe von 1090 Bytes. Hiervon müssen noch 20
+Bytes \textit{IP-} und 32 Byte \textit{TCP-Header} abgezogen werden. Somit sind die hat das Datenfeld eine Größe von 1038 Bytes.
+Bei im folgenden genannten Paketgrößen sind diese 52 Byte schon abgezogen. \newline
+Wenn im nächsten Schritt der Benutzer nun eine \textit{Channel} beitritt so sendet dieser drei Pakete an den Server. Diese
+beinhalten den Namen des \textit{Channels} dem beigetreten werden soll, eine Anfrage der aktiven Nutzer in diesem \textit{Channel}
+sowie welche Rechter der beitretende Nutzer in diesem \textit{Channel} inne hat. Diese drei Pakete haben alle die Größe von 26
+Byte. Ist die Verbindung zwischen Client und Server aufgebaut so sendet der Client alle 30 Sekunden ein \textit{Ping} Paket an den
+Server, welches dieser mit einem \textit{Pong} beantwortet. Diese Pakete haben eine Größe von 40 Byte für die \textit{Ping}
+Nachricht und 58 Byte für die beantwortende \textit{Pong} Nachricht. Alle 60 Sekunden versendet der Client eine Anfrage, welche
+Teilnehmer sich im \textit{Channel} befinden. Diese Nachricht von Client zu Server ist 25 Byte groß. Die Antwort hierzu ist
+abhängig von der Anzahl der Benutzer. Ist nur ein Benutzer im \textit{Channel} so ist sie 151 Bytes groß, bei zwei ist sie schon
+233 Byte groß. Wird eine Verbindung beendet, so schickt der Client noch eine \textit{Quit} Nachricht an den Server. \newline
+
+Im Gegensatz zu diesem hohen Hintergrundverkehr benötigt \textit{Friend Finder} nur einen \textit{TCP-Handshake} um die
+Verbindung aufzubauen. Ist die Verbindung etabliert fallen keine weiteren Hintergrunddaten an. Der Nachteil hiervon ist, dass der
+Client nur bei einem auftretenden Fehler beim versenden der Daten bemerkt das er nicht mehr verbunden ist. Allerdings wird
+hiermit auch Berechnungszeit und somit Akku gespart, da diese \textit{Keep-Alive} Nachrichten, sowie die zusätzliche
+Informationen über den Server im Rahmen von \textit{Friend Finder} nicht benötigt werden.
\subsubsection{Versenden und Empfangen von Nachrichten}
Um das Versenden von Nachrichten zu evaluieren wurde "Hello World" als Testnachricht benutzt. Der \textit{Blockcipher} von
\textit{Friend Finder} teilt den Satz "Hello World" in zwei Teile auf: "Hello " und "World". Diese werden dann von \textit{TCP}
-aufgrund der Fenstergröße in ein Paket gepackt. Das gesamte Paket hat die größe von 81 Bytes, wobei der \textit{TCP-Header} 32
-Bytes und der \textit{IP-Header} 20 Bytes groß ist. Somit haben die Daten eine Größe von insgesamt 29 Bytes.\newline
+aufgrund der Fenstergröße in ein Paket gepackt. Das gesamte Paket hat die größe von 147 Bytes, wobei \textit{TCP-}
+und \textit{IP-Header} in der Summe auch wieder mit 52 Byte abzuziehen sind. Somit haben die Daten eine Größe von insgesamt 95
+Bytes.\newline
Beachtet man dass ein \textit{char} in \textit{C} die Größe von einem Byte hat und der Beispielsatz aus elf Zeichen besteht, so
-ist dieser unverschlüsselt 11 Byte groß. Somit vergrößern sich die Daten nach der Verschlüsselung um circa den Faktor 2,6.\newline
+ist dieser unverschlüsselt 11 Byte groß. Somit vergrößern sich die Daten nach der Verschlüsselung um circa den Faktor 8,6.\newline
Wenn $h$ die Größe des \textit{TCP-Headers} und $t$ die Anzahl der Zeichen der unverschlüsselten Nachricht ist, so ergibt sie die
Länge der zu versendenden Nachricht aus: $h + (t * 2,6)$.
@@ -213,12 +167,11 @@ Länge der zu versendenden Nachricht aus: $h + (t * 2,6)$.
\subsubsection{Fazit der Auswertung}
-Zur Analyse des Allgemeinen Datenverkehrs ist zu sagen dass Aufgrund der Tatsache dass das \textit{IRC-Protokoll}
-auf \textit{TCP/IP} bassiert, eine großer Overhead an Paketen versandt wird. Somit werde wesentlich mehr Pakete als
-nur die benötigten Daten verschickt. Hinzu kommen noch Pakete welche zur ständigen Kommunikation zwischen Server und
-Client ausgetauscht werden.
+Im Bereich des Allgemeinen Datenverkehrs fällt kein Overhead durch \textit{Friend Finder} an. Hier werden nur dann Daten
+versandt, wenn dies auch vom Nutzer so gewollt ist. Dies hat den Vorteil, dass der Anwender die totale Kontrolle über die Daten,
+die er sendet, hat. Allerdings kann so auch erst beim versenden von Daten festgestellt werden, ob die Verbindung unterbrochen
+wurde.\newline
+Ein weiterer Vorteil von \textit{Friend Finder} ist das versenden von Daten an mehrere Benutzer. Hier muss der
+Client sein Paket nur einmal versenden und alle Teilnehmenden Nutzer in einem Channel können diese Nachricht einsehen, sofern dies
+gewollt ist.
-Um den den von \textit{TCP} generierten Datenoverhead zu minimieren, wäre auch das versenden von Daten über \textit{UDP}
-interessant. Dies gilt weniger für das versenden der Textnachrichten sondern eher für das versenden der Positionen. Hier werden,
-wenn mehrere User aktiv sind, ständig Positionsdaten und Acknowledgements zwischen Server und Clients ausgetauscht. Somit könnte
-durch die Nutzung von \textit{UDP} hier einiges an versendeten Packeten gespart werden.\newline