summaryrefslogtreecommitdiffstats
path: root/ausarbeitung/Ausblick.tex~
diff options
context:
space:
mode:
Diffstat (limited to 'ausarbeitung/Ausblick.tex~')
-rw-r--r--ausarbeitung/Ausblick.tex~146
1 files changed, 146 insertions, 0 deletions
diff --git a/ausarbeitung/Ausblick.tex~ b/ausarbeitung/Ausblick.tex~
new file mode 100644
index 0000000..17a61eb
--- /dev/null
+++ b/ausarbeitung/Ausblick.tex~
@@ -0,0 +1,146 @@
+\section{Ausblick}
+
+Die Software \textit{Friend Finder} zeigt nur einen recht einfachen Ansatz auf, um Daten sicher zu versenden und die Position von
+anderen Benutzern aufzuzeigen. Im nun folgenden Teil dieser Arbeit werden Ausblicke auf weitere Möglichkeiten und Ansätze, für
+Nachrichtenverschlüsselung und \textit{location awareness}, aufgezeigt.
+
+\subsection{Plattformunabhängigkeit}
+
+Für mobile Systeme existieren zum momentanen Zeitpunkt mehrere verschiedene Betriebssysteme, welche zum Teil andere Ansätze
+verfolgen. Es werden nun die drei bekanntesten Vertreter der Betriebssyteme, für Smart Phones, vorgestellt und es wird erläutert
+werden, inwiefern sie sich zur portierung von Software eignen.
+
+\subsubsection{Windows Mobile}
+
+Der wohl bekannteste Vertreter ist \textit{Windows Mobile}. Die aktuelle Version 6.5 wurde von Microsoft
+auch \textit{Windows Phone} betitelt.Das gesamte Betriebssystem basiert auf der \textit{Windows Win32 API} und lässt
+ähnlichkeiten zu den Desktop-Varianten der \textit{Windows}-Familie erkennen. \newline
+
+Will man für dieses Betriebssystem Anwendungen entwickeln so bietet Microsoft eine eigenes \textit{Software Development Kit (SDK)}
+an, welches auch jeder frei nutzen kann. Bei der Programmierung kann hierbei sowohl auf \textit{C}/\textit{C++},
+sowie auch auf Java zurückgegriffen werden. Allerdings ist die \textit{Win32 API} nich kompatibel mit der Desktopversion, weshalb
+Anwendungen getrennt entwickelt oder portiert werden müssen.\newline
+
+Wie Im Kapitel Tutorial schon erwähnt, lässt sich mit Hilfe eines \textit{Cross-Compilers} das \textit{Enlightenment}-Paket für
+dieses System, mit etwas Aufwand, portieren. Durch diese Tatsache und der Unterstützung von \textit{C}/\textit{C++}
+eignet sich Windows Mobile sehr gut als Plattform für Anwendungen, welche nich unbedingt von vorne herein für diese entwickelt
+wurden.
+
+\subsubsection{Android}
+
+Bei \textit{Android} \citep{Android} handelt es sich um ein neueres Betriebssystem für Smart Phones. Das von Google entwickelte
+System setzt auf einen Linux-Kernel der Version 2.6 auf. Dieser Kernel kümmert sich um die Prozess- und Speicherverwaltung,
+Kommunikation sowie um die Hardwareabstraktion. \newline
+
+Zum implementieren von Anwendungen stellt Google eigens ein eigenes \textit{SDK} bereit. Dieses greift allerdings nur auf
+\textit{Java}-Bibliotheken zurück, womit sich die nutzbaren Sprachen im moment eben auf diese beschränken. Somit können Programme
+die in \textit{C} oder \textit{C++} geschrieben wurden nicht portiert werden. Auch wenn man einen passenden
+\textit{Cross-Compiler} nutzt funktionieren ist die Portierung nicht immer möglich, da Google die \textit{libc}-Bibliothek (unter
+\textit{Android} nun \textit{Bionic} genannt) an mobile Geräte angepasst und verändert hat.\newline
+
+Durch diese starken Einschränkungen ist es somit auch nicht wirklich möglich das \textit{Elementary}-Paket für \textit{Android}
+zu compilieren, da dieses komplett in \textit{C} geschrieben wurde. Somit muss Software, um auf einem \textit{Android}-Handy ohne
+Probleme lauffähig zu sein, in \textit{Java} geschrieben sein. Als graphische Darstellung kann der Entwickler die von Google
+bereitgestellten \textit.{GUI}-Elemente nutzen.
+
+\subsubsection{WebOS}
+
+\textit{WebOS} \citep{WebOS} gehört nicht zu den weit verbeiteten Betriebsystemen, allerdings wird es hier aufgeführt, da
+\textit{Enlightenment} portiert werden kann. Das System wurde von \textit{Palm} als Nachfolger von \textit{PalmOS} entwickelt.
+Momentan ist das System nur auf zwei Geräten zu finden: Auf dem \textit{Palm Pre} und dem \textit{Palm Pixi}.\newline
+
+Für dieses Betriebssystem existiert sowohl ein \textit{SDK} für \textit{HTML5}, \textit{CSS} und \textit{Java} sowie ein
+weiteres, welches im März 2010 veröffentlicht wird, für \textit{C} und \textit{C++}. Hiermit werden mehrere Programmiersprachen
+unterstütz und die Portierungsmöglichkeiten dieser Plattform gewinnen erheblich an Attraktivität.\newline
+
+Wie bereits erwähnt, wurde \textit{Enlightenment}, genauer gesagt \textit{Evas}, bereits erfolgreich für WebOS compiliert und
+ausgeführt. Mit dem \textit{C SDK} und dieser Portierung wäre es so ohne weitere Probleme möglich den \textit{Friend Finder} auf
+einem \textit{WebOS}-Gerät auszuführen.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\subsection{Kryptographische Verfahren auf Mobilen Plattformen}
+
+In diesem Absatz werden mögliche kryptographische Verfahren für Smart Phones behandelt. So wird prinzipiell zwischen zwei
+verschiedenen Arten der Verschlüsselung unterschieden. Zum einen existieren die sogenanten symmetrischen und zum anderen die
+asymmetrischen Verfahren. Bei ersterem existiert nur ein \textit{private-key} welcher von allen Teilnehmern zum ver- sowie
+entschlüsseln genutzt wird. Bei den asymmetrischen Verfahren sind mehrere Schlüssel nötig. Hierbei werden Daten mit einem
+öffentlichen Schlüsel verschlüsselt und können nur mit dem dazu passenden privaten Schlüssel wieder entschlüsselt werden. \newline
+
+Im folgenden werden verschiedene Algorithmen und deren Tauglichkeit vorgestellt. Des weiteren wird auch auf Möglichkeiten
+eingegangen, um Schlüssel zu verteilen.
+
+\subsubsection{Symmetrische Verschlüsselungsverfahren}
+
+Bei der Klasse der symmetrischen Verschlüsselungsverfahren können theoretisch alle bekannten Verfahren genutzt werden. Natürlich
+stellt sich hier die Frage der Güte der Verschlüsselung, die die einzelnen Algorithmen bieten. Das eigentliche Problem bei der
+Nutzung dieser Verfahren ist, wie man den privaten Schlüssel an die anderen Nutzer weitergeben kann, ohne ihn dabei für dritte
+zugänglich zu machen.\newline
+
+Als naiven Ansatz könnte man hierzu den Austausch per \textit{Bluetooth} erwägen. Allerdings gilt \textit{Bluetooth} nicht als
+sicheres Verfahren um Daten zu übertragen. Somit eignet sich dieses Art des Austauschens nicht, da nicht garantiert ist das
+Dritte mithören und den \textit{private key} erhalten. \newline
+
+Eine weitere Möglichkeit wäre einen 2D-Barcode aus einer Zeichenkette zu erstellen. Diesen könnte man dann auf dem Display
+eines mobilen Gerätes ausgeben. Andere Nutzer könnten dann den Barcode fotographieren und wiederrum in eine Zeichenkette
+umwandeln. Diese Zeichenkette könnte dann für beide Kommunikationspartner als privater Schlüssel genutzt werden.\newline
+Was allerdings gegen diese Methode spricht ist die Tatsache, dass sich zwei oder mehrere Nutzer treffen müssen um diese Daten
+auszutauschen. Somit verliert dieser Ansatz den großen Nachteil, dass die Mobilität ein Stück weit verloren geht, da man sich vor
+beginn der sicheren Kommunikation erst treffen muss. \newline
+Man könnte auch einfach die SD-Karten der mobilen Geräte mit einem oder mehreren gespeicherten, privaten Schlüsseln mit anderen
+Nutzern austauschen. Aber auch hier verliert man stark an Mobilität.\newline
+
+Man könnte auch eine Implementierung von \textit{Kerberos} \citep{Kerberos} für mobile Geräte erwägen. Bei diesem Verfahren
+übernimmt eine vertrauenswürdige dritte Partei die Authentifizierung. Diese wird von einem geschützten \textit{Kerberos}
+durchgeführt. Wenn ein Client sich gegenüber einem Server authentifizieren möchte, muss er sich beim \textit{Kerberos} Server
+anmelden. Dieser verifiziert dann seine eigene Identität, sowie Client gegenüber Server und Server gegenüber Client. \newline
+Möchte man nun diesen Dienst auf Smart Phones erweitern, so muss man einen \textit{Kerberos} Client für die jeweilige Plattform
+entwickeln.
+
+\subsubsection{Asymmetrische Verschlüsselungsverfahren}
+
+Der Vorteil von asymmetrischen Kryptographiesystemen gegenüber den symmetrischen ist, dass man nur den eigenen privaten Schlüssel
+geheim halten muss während der öffentliche Schlüssel frei zugänglich ist. Bei symmetrischen Verfahren muss man alle privaten
+Schlüssel speichern und geheim halten. Durch diesen Vorteil der \textit{Public-Key} Verfahren ist das Verteilen der einzelenen
+Schlüssel wesentlich einfacher. Das Problem von vorgetäuschten öffentlichen Schlüssen durch dritte kann mit einer
+vertrauenswürdigen Zertifizierungsstelle oder einem \textit{Web of Trust} stark eingegrenzt werden.\newline
+
+Das Prinzip des \textit{Web of Trust} macht sich das \textit{Pretty Good Privacy (PGP)} Verfahren zu nutze. Dieses Verfahren wurde
+von der Firma \textit{PGP} in Form von \textit{PGP Mobile} \citep{PGPmobile} für Smart Phones realisiert. Das
+\textit{PGP}-Verfahren ermöglicht es Daten zu verschlüsseln, signieren oder sowohl zu verschlüsseln als auch zu signieren. Bei
+einem signierten und Verschlüsselten Datenpaket wendet der Sender zuerst ein Hash-Verfahren auf die zu verschlüsselnden Daten an.
+Im nächsten Schritt wird der private Schlüssels des Senders auf eben diesen Hash angewendet um eine Signatur zu erstellen. Soll
+die Nachricht nun verschlüsselt werden, so wird das unverschlüsselte Datenpaket und die Signatur komprimiert und mit einem
+zufällig generierten Schlüssel verschlüsselt. Da dieser zufällige Schlüssel nur einmal gültig ist, wird er asymmetrisch mit
+dem öffentlichen Schlüssel des Empfängers verschlüsselt und an die Nachricht angehängt. Nun kann die gesamte Nachricht an den
+Empfänger gesendet werden. \newline
+Der Empfänger kann nun mit Hilfe seines private Schlüssels den angehängten Schlüssel dieser Sitzung entschlüsseln und mit desen
+Hilfe die komprimierte Nachricht wiederherstellen.\newline
+Für dieses Verfahren existiert auch eine \textit{Open Source} Variante namens \textit{OpenPGP} \citep{openPGP}. Mit dieser
+offenen Implementierung wäre es möglich ein solches Verfahren auch als freie Variante zu implementieren.\newline
+Der Nachteil des genannten Verfahrens ist mit Sicherheit der große Overhead an Daten versendet werden muss, sowie die Maße an
+benötigten Operationen um einen Klartext zu verschlüsseln. Dies tritt vor allem dann in Vordergrund wenn man, wie in
+\textit{Friend Finder}, im Sekundentakt verschlüsselte Positionsdaten versenden möchte.\newline
+
+%noch ein verfahren ipsec??
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\subsection{Alternative \textit{location awareness} Verfahren}
+
+Neben dem in \textit{Friend Finder} implementierten, recht einfachen Verfahren, um andere Nutzer zu lokalisieren wurden schon
+andere Verfahren vorgestellt. Im folgenden Abschnitt werden alternative Vorgehensweisen vorgestellt und erklärt.
+
+\subsubsection*{FriendSensing: Recommending Friends Using Mobile Phones}
+
+Im Paper \textit{FriendSensing: Recommending Friends Using Mobile Phones} \citep{FriendSensing} aus dem Jahr 2009 erläutern die
+Autoren ihren Ansatz um Freunde für mobile, soziale Netze zu finden. Hierfür benutzen sie zum einen \textit{Bluetooth} und
+zeichnen andere Telefone in Reichweite auf. Somit kann aufgezeichnet werden, wie oft Nutzer A und Nutzer B aufeinandergetroffen
+sind. Des weiteren haben sie eine Software auf den mobilen Geräten installiert, welche aufzeichnet wie oft Nutzer A mit Nutzer B
+kommunziert. Aus diesen zwei gewonnenen Datensätzen waren die Autoren nun mit Hilfe von verschiedenen Algorithmen, wie zum
+Beispiel den \textit{Shortest Path} Algorithmus oder \textit{Markov Ketten}, in der Lage zu ermitteln, wie gut Nutzer A einen
+Nutzer B kennt.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\subsection{Zusammenfassung} \ No newline at end of file