From 1428440cfffe73e75320dde46d8afb3afe9fced5 Mon Sep 17 00:00:00 2001 From: Patrick Hornecker Date: Thu, 11 Feb 2010 18:06:06 +0100 Subject: tex source --- ausarbeitung/Ausblick.tex~ | 146 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 ausarbeitung/Ausblick.tex~ (limited to 'ausarbeitung/Ausblick.tex~') 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 -- cgit v1.2.3-55-g7522