Entwurf und Implementierung einer Client-Software für den Anonymisierungsdienst AN.ON zur Benutzung auf mobilen Geräten

Transkript

1 Technische Universität Dresden Fakultät Informatik Institut für Systemarchitektur Lehrstuhl Datenschutz und Datensicherheit DIPLOMARBEIT Entwurf und Implementierung einer Client-Software für den Anonymisierungsdienst AN.ON zur Benutzung auf mobilen Geräten Lukas Braune Matrikel-Nr.: Studiengang: Informatik 16. Februar 2012 Betreuer/Hochschullehrer: Dr.-Ing. Stefan Köpsell

2

3 Technische Universität Dresden / Fakultät Informatik Aufgabenstellung für die Diplomarbeit Name, Vorname, Matr. Nr.: Braune, Lukas, Studiengang: Thema: Zielstellung: Informatik Entwurf und Implementierung einer Client-Software für den Anonymisierungsdienst AN.ON zur Benutzung auf mobilen Geräten Der am Lehrstuhl entwickelte Anonymisierungsdienst AN.ON befindet sich seit 2000 im öffentlichen Testbetrieb. AN.ON ( basiert auf den Chaumschen Mixen, die in Form von Kaskaden betrieben werden. Zur Benutzung des Anonymisierungsdienstes ist clientseitig die Installation eines Java-Programms namens JAP notwendig. Softwaretechnisch läßt sich JAP in eine Kernbibliothek zum Zugriff auf den Anonymisierungsdienst ( AnonLib ) und Komponenten für die Benutzungsschnittstellen unterteilen. Das Clientprogramm JAP des Anonymisierungsdienstes AN.ON wurde vordergründig für den Einsatz auf Desktop-Systemen konzipiert. Mittlerweile existiert eine Reihe von Plattformen für mobile Geräte (Maemo, Google Android, Java ME, etc.) die eine Portierung des JAP für mobile Geräte ermöglichen. Ziel ist die Umsetzung von JAP für mobile Geräte. Dabei ist zu überlegen, wie eine geeignete Softwarearchitektur aussieht, um die Portierung auf die verschiedenen möglichen Plattformen für mobile Geräte möglichst einfach zu gestalten und insbesondere den Wartungsaufwand für die unterschiedlichen JAP-Versionen zu minimieren. Als Zielplattform ist für die Implementierung zumindest Google Android zu unterstützen, wobei die Umsetzung so erfolgen soll, daß mit minimalen Anpassungen auch eine Lauffähigkeit auf anderen Plattformen gegeben ist. Zur Umsetzung ist nach Möglichkeit auf existierende OpenSource Komponenten zurückzugreifen. Ferner sind die Programmierrichtlinien des AN.ON-Projektes zu berücksichtigen ( Für eine erfolgreiche Bearbeitung des Themas sind folgende Schwerpunkte zu berücksichtigen: Konzeption einer geeigneten Modularisierung und deren Implementierung, um die AnonLib auf den verschiedenen Plattformen ausführen zu können, Konzeption und Implementierung einer Benutzungsschnittstelle für mobile Geräte, um die AnonLib auf diesen Geräten nutzbar zu machen. Evaluierung der Implementierung unter Benutzbarkeits- und Leistungsgesichtspunkten Betreuer: Dr. Stefan Köpsell Hochschullehrer: Dr. Stefan Köpsell Institut: Systemarchitektur Beginn am: 16. Mai 2011 Einzureichen am: 16. November Verantwortlicher Hochschullehrer Verteiler: 1x Prüfungsamt, 1x HSL, 1x Betreuer, 1x Student

4

5 Inhaltsverzeichnis 1 Einleitung Einführung AN.ON-Projekt Android Anforderungen Anforderungen aus der Aufgabenstellung Weitere Anforderungen Zusammenfassung der Anforderungen Entwurf Vorbetrachtungen Überblick über Mobilplattformen Artverwandte Projekte Architektur Art der Anwendung Benutzungsoberfläche Bereitstellung der Anonymisierungs-Funktionalität Zusammenfassung der Softwarearchitektur Funktionalität der Benutzungsoberfläche Sicherheitsbetrachtung Implementierung Entwicklungs- und Testumgebung Systemaufbau Systemkomponenten und Implementierungsaspekte Service

6 Inhaltsverzeichnis Logging Webservice Webserver Activity Weboberfläche Internationalisierung Datenbankanbindung Persistenz Verbindungswiederaufnahme Installation und Nutzung Evaluierung Funktionalität Zuverlässigkeit Effizienz Verbrauchsverhalten Zeitverhalten Vergleich zum JAP Benutzbarkeit Wartbarkeit/Änderbarkeit Übertragbarkeit Zusammenfassung und Ausblick 89 A API-Referenz des Webservice 93 B Aufgabenstellung und Fragebogen zur Nutzerstudie 97 Literaturverzeichnis 100 Abkürzungsverzeichnis 101 Abbildungsverzeichnis 104 Tabellenverzeichnis 105 2

7 Inhaltsverzeichnis Verzeichnis der Listings 107 3

8

9 Kapitel 1 Einleitung 1.1 Einführung Der Anonymisierungsdienst JAP bzw. dessen kommerzielle Variante JonDo ermöglicht unbeobachtbare Kommunikation im Internet. Der Dienst ging aus dem im Jahr 2000 gestarteten AN.ON-Projekt hervor, an welchem die Technische Universität Dresden, die Universität Regensburg und das Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein geforscht haben [Bra10]. AN.ON basiert grundlegend auf den von David Chaum erfundenen Mixen, welche die Kommunikation unter Zuhilfenahme verschiedener (kryptografischer) Maßnahmen verschleiern. Für die Nutzung des AN.ON-Dienstes muss clientseitig eine Java-Anwendung installiert werden. Diese als JAP bzw. JonDo bezeichnete Software ist zwar plattformunabhängig, jedoch in erster Linie für den Einsatz auf Desktop-Rechnern konzipiert. Nutzer von internetfähigen mobilen Geräten wie beispielsweise Handys, Smartphones oder Tablets haben hingegen keine Möglichkeit, den Anonymisierungsdienst zu nutzen, da die Client-Software nicht ohne weiteres auf deren mobilen Betriebssystemen ausgeführt werden kann. Nach Aussagen des Branchenverbandes der deutschen Informations- und Telekommunikationsbranche (BITKOM) vom Februar 2011 hat sich das mobile Internet bereits in weiten Teilen der deutschen Bevölkerung durchgesetzt [BIT11] und unterliegt auch im Jahr 2011 einem starken Wachstum. Genauer gesagt steigt in diesem Jahr entsprechend der BITKOM-Prognose der Absatz von Smartphones in Deutschland um 36 Prozent auf 10,1 Millionen Geräte. Darüber hinaus hat sich die in den deutschen Mobilfunknetzen übertragene Datenmenge im vergangenen Jahr auf 70 Millionen Gigabyte mehr als verdoppelt. Durch die fortschreitende Etablierung des neuen Mobilfunkstan- 5

10 Kapitel 1 Einleitung dards Long Term Evolution (LTE) sowie den immer leistungsfähigeren Mobilgeräten ist davon auszugehen, dass das mobile Internet zukünftig einen bedeutenden Anteil an der Gesamtnutzung des Internets einnehmen wird. Damit einhergehend steigt auch der Bedarf an angepassten datenschutzfördernden Technologien sowohl für Privatpersonen als auch für Unternehmen. Das Ziel der vorliegenden Arbeit sind der Entwurf und die Implementierung einer Client-Software, welche die Nutzung des Anonymisierungsdienstes AN.ON auf mobilen Geräten ermöglicht. Schwerpunkte stellen dabei die Konzeption einer geeigneten Modularisierung der Softwarekomponenten sowie der Entwurf einer Benutzungsschnittstelle dar. Die zu entwickelnde Client-Software soll als Zielplattform Google Android unterstützen. 1.2 AN.ON-Projekt In diesem Abschnitt sollen die für diese Arbeit wichtigen Softwarekomponenten des AN.ON-Projektes kurz vorgestellt werden. Abbildung 1.1 veranschaulicht die grundlegende Funktionsweise des Anonymisierungsdienstes [Bra10]. Dabei wird eine Anfrage eines Clients an einen Ziel-Server nicht wie gewöhnlich auf direktem Wege zugestellt, sondern im ersten Schritt von einem lokalen Proxy entgegengenommen. Dieser Proxy wird durch die als JAP bzw. JonDo bezeichnete Java-Anwendung bereitgestellt. Der JAP verschlüsselt die entgegengenommenen Daten und reicht sie an den ersten Mix weiter. Sukzessive werden nun die Daten von einem zum nächsten Mix gereicht, sodass sie letztlich alle Mixe der sogenannten Mix-Kaskade (Hintereinanderschaltung von Mixen) passiert haben. Der letzte Mix übernimmt schließlich die Zustellung an den Ziel-Server. Der Datenaustausch von einem Internet-Server zu einem Client erfolgt auf analoge Weise. Die Mix-Software stellt im AN.ON-Projekt eine eigenständige Softwarekomponente dar und soll im Rahmen dieser Arbeit nicht verändert werden. Da sich die Entwicklung ausschließlich mit der Client-Seite beschäftigt, werden die Mixe als solche an dieser Stelle nicht weiter betrachtet. Abbildung 1.2 zeigt die Hauptansicht des JAP mit Statusinformationen und einigen Konfigurationsmöglichkeiten. Der Anwender hat hier beispielsweise die Möglichkeit, den bevorzugten Anonymisierungsdienst (Mix-Kaskade) zu wählen oder Informatio- 6

11 1.3 Android nen über den aktuell verwendeten Dienst abzurufen. Nutzer Ziel-Server... Mix 1 Mix 2 Mix 3... Mix-Kaskade Abbildung 1.1: Architektur des Anonymisierungsdienstes AN.ON Eine wichtige Softwarekomponente stellt die Java-Bibliothek AnonLib dar. Diese implementiert die Kernfunktionalität zur Nutzung des Anonymisierungsdienstes. Der JAP, dessen Kommandozeilen-Variante JonDoConsole sowie die AN.ON-Firefox-Erweiterung basieren auf der AnonLib. Mit Hilfe des Java-Controllers JonDoController lassen sich die Client-Funktionen des JAP steuern. Genauer gesagt werden die Funktionen der AnonLib abstrahiert und auf für Entwickler einfachere Weise nutzbar gemacht. 1.3 Android Android ist ein auf Linux basierendes, freies und quelloffenes Betriebssystem für mobile Geräte. Es wird von der Open Handset Alliance (OHA), einem von Google geleiteten Konsortium, entwickelt. Die OHA wurde im Jahr 2007 von Google gegründet und besteht derzeit aus über 80 Unternehmen. Insbesondere bei Smartphones und Tablets besitzt Android bereits eine sehr hohe Popularität und ist laut einer Studie 7

12 Kapitel 1 Einleitung Abbildung 1.2: Hauptansicht des JAP des Marktforschungsunternehmens Gartner vom November 2011 mit einem Marktanteil von 52,5 Prozent an den Smartphone-Verkäufen Marktführer in diesem Segment [Gar11]. Android wird über einen Touchscreen bedient und lässt sich in seiner Funktionalität über sogenannte Apps (engl.: applications) erweitern. Apps sind an die Android- Plattform angepasste Anwendungen, die vom Benutzer über ein integriertes Online- Portal, den sogenannten Android Market, bezogen werden können. Die Anwendungen werden in der Regel in Java entwickelt. Android beinhaltet dafür eine auf der Java- Technik basierende virtuelle Maschine namens Dalvik 1 sowie Java-Klassenbibliotheken. Darunter befinden sich beispielsweise Java-Standardklassen, JUnit als Test-Framework, Klassen zur Bluetooth-Kommunikation und Android-spezifische Klassen. Zur Entwicklung von eigenen Apps benötigt man ein gewöhnliches Java-SDK und 1 Sowohl eine Java-VM als auch die Dalvik-VM führen Bytecode aus, jedoch basiert eine Java-VM auf einem Kellerautomaten und die Dalvik-VM hingegen auf einer Registermaschine. Da auch moderne Prozessorarchitekturen wie z. B. die bei fast allen aktuell erhältlichen Smartphones verwendete ARM- Architektur nativ Registermaschinencode ausführen, ist die Dalvik-VM unter Umständen schneller und ressourcenschonender als eine Java-VM. 8

13 1.3 Android darüber hinaus noch ein Android-SDK. Der in Java geschriebene Quelltext wird durch den Java-Compiler in Bytecode übersetzt und muss anschließend noch von einem Cross- Assembler in ein für die Dalvik-VM ausführbares Format konvertiert werden. 9

14

15 Kapitel 2 Anforderungen In diesem Kapitel werden die ersten Anforderungen an eine mobile Client-Software für den Anonymisierungsdienst AN.ON anhand der Aufgabenstellung ermittelt und verfeinert. Dabei werden die einzelnen Anforderungen in Anlehnung an die von Balzert in [Bal09] vorgeschlagene Notation gekennzeichnet. Jede Anforderung beginnt mit dem Buchstaben F, gefolgt von einer Zahl, eingeschlossen in Schrägstriche. Anfangs werden die Zahlen in Zehnerschritten hochgezählt, damit die im weiteren Verlauf der Arbeit eventuell zusätzlich auftretenden Anforderungen eingeordnet werden können. Des Weiteren sollen die zwei nachfolgenden Abschnitte die Anforderungen aus der Aufgabenstellung von den daraus abgeleiteten sowie eigenständig ergänzten Anforderungen abgrenzen. 2.1 Anforderungen aus der Aufgabenstellung Die erste Anforderung legt die Zielplattform fest: /F10/ Die zu entwickelnde Client-Software soll auf der Mobilplattform Android lauffähig sein. Dabei ist im Zuge des Entwurfs zu untersuchen, welche weiteren Mobilplattformen für einen mobilen AN.ON-Client grundsätzlich geeignet wären. Daraus ergibt sich eine Anforderung an die Softwarearchitektur: /F20/ Die Softwarearchitektur ist derart zu gestalten, dass eine Portierung der zu entwickelnden Android-Anwendung auf die verschiedenen geeigneten Mobilplattformen 11

16 Kapitel 2 Anforderungen mit nur minimalen Anpassungen möglich ist. Grundlage dafür ist die Konzeption einer geeigneten Modularisierung. Da gemäß Aufgabenstellung schon bestehende Softwarekomponenten des AN.ON- Projektes für die Entwicklung der Client-Software genutzt werden sollen, lautet eine weitere Anforderung: /F30/ Mit der neuen Client-Software entsteht zusätzlicher Wartungsaufwand. Dieser soll möglichst minimal gehalten werden. Insbesondere sollen neue Versionen der Kernbibliotheken des AN.ON-Projektes (siehe Abschnitt 1.2) ohne nennenswerte Anpassungen am zu entwickelnden Client nutzbar sein. Bestimmte Funktionsmerkmale lassen sich in aller Regel durch die Nutzung von bereits bestehenden Softwarekomponenten wie beispielsweise Frameworks schneller und wartungsfreundlicher realisieren, als wenn man für den jeweiligen Zweck von Grund auf neue Lösungen entwickeln würde. Eine weitere Anforderung lautet daher: /F40/ Die Implementierung der Client-Software soll nach Möglichkeit auf existierende Open-Source-Komponenten zurückgreifen. Außerdem müssen bei der Implementierung bestehende Richtlinien hinsichtlich Namenskonventionen, Quelltextformatierung, Dokumentation usw. berücksichtigt werden: /F50/ Es sind die Programmierrichtlinien des AN.ON-Projektes 1 (aktuell in Version 3.04 vom 11. Oktober 2006) zu berücksichtigen. 2.2 Weitere Anforderungen Mobile Geräte erfordern im Gegensatz zu Desktop-Systemen einen deutlich sparsameren Umgang mit Systemressourcen, da diese nur vergleichsweise eingeschränkt zur Verfügung stehen. Aus dieser Tatsache heraus ergibt sich eine weitere Anforderung: 1 (abgerufen am 14. Januar 2012) 12

17 2.3 Zusammenfassung der Anforderungen /F60/ Systemressourcen wie Netzanbindung, Rechenleistung, Hauptspeicher, interner Speicher und Energiebedarf sind auf mobilen Geräten als teure Ressourcen anzusehen. Bei der Realisierung der Client-Software soll darauf geachtet werden, dass diese Ressourcen nicht unnötig verschwendet werden. Die zu entwickelnde Client-Software soll von möglichst vielen Anwendern mobiler Geräte genutzt werden können. Eine wichtige Anforderung lautet daher: /F70/ Die Implementierung soll ähnlich wie beim JAP für Desktop-Systeme eine Internationalisierung vorsehen. 2.3 Zusammenfassung der Anforderungen Die in diesem Kapitel beschriebenen Anforderungen an das zu entwickelnde System sind in Tabelle 2.1 zusammengefasst. Bezeichnung F10 F20 F30 F40 F50 F60 F70 Zusammenfassung Android als Zielplattform Portierung auf andere Mobilplattformen ermöglichen Wartungsaufwand gering halten Verwendung von Open-Source-Komponenten Berücksichtigung der AN.ON-Programmierrichtlinien Sparsamer Umgang mit Systemressourcen Internationalisierung Tabelle 2.1: Zusammenfassung der Anforderungen 13

18

19 Kapitel 3 Entwurf In diesem Kapitel werden die Anforderungen an die zu entwickelnde Client-Software konkretisiert. Davon ausgehend wird eine geeignete Softwarearchitektur vorgeschlagen. Die getroffenen Entwurfsentscheidungen werden diskutiert und alternative Lösungsansätze werden aufgezeigt. 3.1 Vorbetrachtungen Überblick über Mobilplattformen Neben Android gibt es noch weitere Mobilplattformen, die teilweise eine hohe Verbreitung besitzen. Die Tabelle 3.1 veranschaulicht die Marktanteile der größten Mobilplattformen in den dritten Quartalen der Jahre 2011 und Es ist deutlich zu erkennen, dass Android die Symbian-Plattform innerhalb des Vergleichszeitraumes von ihrer ehemaligen Marktführerposition verdrängt hat. Mobilplattform Marktanteil an Neuverkäufen [%] 3. Quartal Quartal 2010 Android 52,5 25,3 Symbian-Plattform 16,9 36,3 Apple ios 15,0 16,6 BlackBerry OS 11,0 15,4 bada 2,2 1,1 Microsoft 1,5 2,7 andere 0,9 2,5 Tabelle 3.1: Marktanteile von Mobilplattformen an den weltweiten Smartphone-Verkäufen in den dritten Quartalen der Jahre 2011 und 2010 [Gar11] 15

20 Kapitel 3 Entwurf Nachfolgend werden die oben genannten Mobilplattformen kurz vorgestellt. Darüber hinaus gibt es noch einige weniger weit verbreitete Plattformen, die ebenfalls erwähnt werden sollen. Dabei liegt das Hauptaugenmerk auf den Möglichkeiten zur Entwicklung von Software für diese Plattformen. Symbian-Plattform Die Symbian-Plattform (im Folgenden als Symbian bezeichnet) ist ein Mobil-Betriebssytem für Smartphones und Personal Digital Assistants (PDAs), welches von Nokia entwickelt und mittlerweile ausschließlich auf deren Mobilgeräten eingesetzt wird. Die aktuelle Version von Symbian heißt Symbianˆ3 bzw. Symbian Belle (erschienen im August 2011). Das System steht unter einer proprietären Lizenz, wobei der Quelltext nach einer Registrierung auf der Website 1 von Nokia für Entwickler zugänglich ist. Das offizielle SDK bietet zahlreiche Möglichkeiten zur Entwicklung von Anwendungen für Symbian. Diese werden hauptsächlich in C++ und unter Zuhilfenahme des Qt- Frameworks entwickelt. Ebenfalls unterstützt werden die Programmiersprachen und Technologien Java Platform, Micro Edition (Java ME), Python, Adobe Flash Lite sowie die Web Runtime Widgets (WRT). Das Symbian-Pendant zum Android Market heißt Nokia Store. Maemo, Moblin, MeeGo, LiMo und Tizen Maemo ist ein auf der Linux-Distribution Debian basierendes Mobil-Betriebssystem, welches insbesondere für internetfähige Tablets, jedoch auch für Smartphones geeignet ist. Das Projekt wurde von Nokia initiiert und wird Community-basiert entwickelt. Maemo ist aktuell in Version 5 mit dem Namen Fremantle verfügbar (erschienen im Oktober 2010). Es besteht zu einem großen Teil aus freier Software wie z. B. der Desktop- Umgebung GNOME, beinhaltet allerdings auch proprietäre Software von Nokia. Mit Hilfe des Maemo SDK können Anwendungen in C, Java, Python, Ruby und Mono entwickelt werden. Die Java-Unterstützung wird dabei durch das Jalimo-Projekt ermöglicht, dessen Ziel es ist, eine freie Java-Laufzeitumgebung für mobile und eingebettete Linux-Systeme zur Verfügung zu stellen. Als Anwendungsframeworks sind Hildon und Qt vorgesehen. Bei Hildon handelt es sich unter anderem um Erweiterungen 1 (abgerufen am 21. Dezember 2011) 16

21 3.1 Vorbetrachtungen für das GIMP Toolkit (GTK+). Genau wie bei Symbian können Maemo-Apps über den Nokia Store bezogen werden. Außerdem kann das in Maemo integrierte Paketverwaltungssystem dpkg genutzt werden. Moblin war ein auf der Linux-Distribution Fedora basierendes Open-Source-Mobil- Betriebssystem. Das Projekt wurde von Intel initiiert und war insbesondere für Netbooks mit den energiesparenden Intel Atom-Prozessoren konzipiert. Im Februar 2010 wurde bekanntgegeben, dass infolge einer Kooperation zwischen Nokia und Intel die beiden Mobil-Plattformen Maemo und Moblin zu einer neuen Plattform namens MeeGo verschmolzen werden sollen. Die Verschmelzung hat stattgefunden und MeeGo ist aktuell in Version 1.2 verfügbar (erschienen im Mai 2011). 2 Maemo wird Community-basiert weiterentwickelt, wohingegen die Weiterentwicklung von Moblin zugunsten von MeeGo aufgegeben wurde. MeeGo-Anwendungen werden über das Paketverwaltungssystem RPM Package Manager (RPM) verwaltet. Die Entwicklung von Anwendungen geschieht ähnlich wie bei Maemo mit Hilfe des Qt-Frameworks. Um auch Moblin-Anwendungen ausführen zu können, werden darüber hinaus die Bibliotheken GTK+ und Clutter mitgeliefert. Um jedoch eine Kompatibilität für Hildon-basierte Maemo-Anwendungen zu gewährleisten, muss das Hildon-Framework vom Nutzer nachinstalliert werden. Im September 2011 kündigte Intel an, dass MeeGo im Laufe des Jahres 2012 durch das neue Mobil-Betriebssystem Tizen ersetzt werden soll. 3 Tizen soll ebenso Teile der LiMo-Plattform beinhalten und den Schwerpunkt für die Anwendungsentwicklung auf HTML5 sowie weitere Webtechnologien legen. Apple ios Apple ios ist das Betriebssystem für die Apple-Produkte iphone, ipod touch, ipad und Apple TV. Es handelt sich dabei um ein Derivat von dem auf Unix basierenden Apple- Betriebssystem Mac OS X. Apple ios ist aktuell in Version 5 verfügbar (erschienen im Oktober 2011). 4 Der Quelltext des Systems ist nicht öffentlich verfügbar, es handelt sich demnach um Closed-Source-Software. Apps können über den sogenannten App Store 2 (abgerufen am 27. Dezember 2011) 3 (abgerufen am 27. Dezember 2011) 4 icloud.html (abgerufen am 28. Dezember 2011) 17

22 Kapitel 3 Entwurf bezogen werden. Das für die Entwicklung von Apps verfügbare SDK ist nur unter Mac OS X lauffähig. Apps werden überwiegend in der Programmiersprache Objective-C geschrieben, können jedoch auch in C oder C++ geschriebene Elemente beinhalten. BlackBerry OS und BlackBerry 10 Das BlackBerry OS der Firma Research In Motion (RIM) ist ein für dessen Smartphones der Marke BlackBerry entwickeltes Mobil-Betriebssystem, welches aktuell in Version 7 verfügbar ist (erschienen im August 2011). 5 Der Quelltext des Systems ist nicht öffentlich verfügbar. Apps können über die sogenannte BlackBerry App World bezogen werden. Apps werden in Java auf Basis von Java ME und dem dazugehörigen Profil Mobile Information Device Profile (MIDP) entwickelt. Zusätzlich stehen Entwicklern BlackBerryspezifische Java-Schnittstellen zur Verfügung. RIM hat am 18. Oktober 2011 angekündigt, BlackBerry OS 7 durch das neue Betriebssystem BlackBerry 10 (vormals bekannt unter dem Namen BBX) ersetzen zu wollen. 6 Es soll ab dem Jahr 2012 nicht nur auf den BlackBerry-Smartphones, sondern auch auf deren Tablets zum Einsatz kommen. BlackBerry 10 wurde von Grund auf neu konzipiert und basiert anders als BlackBerry OS auf dem unixoiden Echtzeitbetriebssystem QNX. Die Java-Technologie wird nicht mehr Bestandteil des neuen Systems sein. Stattdessen werden Apps entweder nativ in C oder C++, oder unter Nutzung von HTML5 und dem BlackBerry WebWorks SDK entwickelt. Letzteres umfasst Tools und Bibliotheken, welche die Entwicklung vollwertiger BlackBerry-Apps auf Basis von Webtechnologien unterstützen. Außerdem sollen mit dem Android App Player auch Android-Apps ausgeführt werden können. bada Bada ist ein von Samsung entwickeltes Mobil-Betriebssystem für Smartphones und Tablets. Der Kernel des Systems ist je nach zugrundeliegender Hardware austauschbar. So kann sowohl ein Linux-Kernel als auch ein Echtzeitkernel verwendet werden. Bada ist aktuell in Version 2.0 verfügbar (erschienen im August 2011). 7 Derzeit ist der 5 (abgerufen am 28. Dezember 2011) 6 (abgerufen am 28. Dezember 2011) 7 (abgerufen am 28. Dezember 2011) 18

23 3.1 Vorbetrachtungen Quelltext des Systems im Wesentlichen nicht öffentlich verfügbar. Außerdem kommt bada ausschließlich auf Geräten von Samsung zum Einsatz. Samsung plant allerdings, bada in Form einer Open-Source-Plattform auch anderen Geräteherstellern zur Verfügung zu stellen. 8 Apps können über das Online-Portal Samsung Apps bezogen werden. Mit Hilfe des bada-sdks können Apps in C++, Adobe Flash oder unter Nutzung von Webtechnologien entwickelt werden. Windows Phone 7 Windows Phone 7 ist ein von Microsoft entwickeltes Mobil-Betriebssystem für Smartphones, welches aktuell in Version 7.5 verfügbar ist (erschienen im September 2011). 9 Der Quelltext des Systems ist nicht öffentlich verfügbar. Apps können über den Windows Phone Marketplace bezogen werden. Mit dem SDK namens Windows Phone Developer Tools können Apps in den Programmiersprachen C# und Visual Basic.NET entwickelt werden. Als Frameworks werden Microsoft Silverlight und Microsoft XNA verwendet. Silverlight ermöglicht im Allgemeinen die Entwicklung und Ausführung von Rich Internet Applications (RIA) und eignet sich daher auch für die App-Entwicklung. XNA ist eine Technologie zur Spieleentwicklung für die Microsoft-Plattformen Windows, Windows Phone 7, Xbox 360 und Zune. webos WebOS ist ein auf Linux basierendes Mobil-Betriebssystem für Smartphones, welches ursprünglich von der Firma Palm entwickelt wurde. Nach der Übernahme von Palm durch die Firma Hewlett-Packard (HP) wurde die Plattform von dem neu firmierten Unternehmen HP Palm weiterentwickelt. Im Dezember 2011 kündigte HP an, das bis zu diesem Zeitpunkt teilweise proprietäre webos unter einer Open-Source-Lizenz zu veröffentlichen und einer Community zur Weiterentwicklung zu übergeben. 10 Jedoch will sich HP weiterhin aktiv an der Entwicklung von webos beteiligen und diese sogar koordinieren. Schon einige Monate zuvor hatte HP bekanntgegeben, keine webos-geräte 8 html (abgerufen am 28. Dezember 2011) 9 mspx (abgerufen am 28. Dezember 2011) 10 (abgerufen am 29. Dezember 2011) 19

24 Kapitel 3 Entwurf mehr herstellen zu wollen. 11 WebOS ist aktuell in Version 3.0 verfügbar (erschienen im Juli 2011). 12 Apps können über den HP App Catalog bezogen werden. Das webos-sdk ermöglicht es Entwicklern in erster Linie, Apps auf Basis der Webtechnologien HTML5, Cascading Style Sheets (CSS) und JavaScript zu entwickeln. Mit der Web-basierten Entwicklungsumgebung Ares 13 können Apps auch direkt im Web-Browser entwickelt werden, ohne dass ein SDK installiert werden muss. Des Weiteren können Apps mit Hilfe des Plug-in Development Kits (PDK) auch in C und C++ entwickelt werden Artverwandte Projekte Neben AN.ON gibt es noch weitere Anonymisierungsdienste für das WWW. Für einige von ihnen existieren bereits Portierungen auf diverse Mobilplattformen, welche im Folgenden vorgestellt werden sollen. Orbot Tor unter Android Im Rahmen des Projektes The Guardian Project 14, welches datenschutzfördernde Anwendungen für mobile Geräte entwickelt, wird mit Orbot 15 eine Android-App für den Anonymisierungsdienst Tor 16 zur Verfügung gestellt. Orbot fungiert dabei als lokaler Proxy und ermöglicht es anderen Anwendungen, das Tor-Netzwerk zu nutzen. Dabei stellt Orbot die folgenden Schnittstellen zur Verfügung: HTTP-Proxy unter localhost:8118 SOCKS-Proxy (Versionen 4A und 5) unter localhost:9050 Transparenter Proxy (erfordert unter anderem Root-Rechte auf dem Gerät) 11 (abgerufen am 29. Dezember 2011) 12 (abgerufen am 29. Dezember 2011) 13 (abgerufen am 29. Dezember 2011) 14 (abgerufen am 29. Dezember 2011) 15 (abgerufen am 29. Dezember 2011) 16 Tor (Abkürzung für The onion router ) basiert ähnlich wie AN.ON auf den Chaumschen Mixen, jedoch unterscheiden sich beide Dienste hauptsächlich in der Art der Hintereinanderschaltung der Mixe. AN.ON nutzt Mix-Kaskaden, bei denen alle zu übertragenden Nachrichten die gleichen Mixe in der gleichen Reihenfolge durchlaufen. Hingegen nutzt Tor sogenannte freie Mix-Netze, bei denen die Nachrichten unterschiedliche Mixe in unterschiedlicher Reihenfolge durchlaufen können. Die Routenwahl geschieht bei Tor also dynamisch. 20

25 3.1 Vorbetrachtungen Soll die Netzwerkkommunikation einer Android-App durch Orbot und das Tor-Netzwerk anonymisiert werden, so muss deren Proxy-Konfiguration entsprechend angepasst werden. Web-Browser und alle anderen Anwendungen, die das HTTP-Protokoll verwenden, nutzen Orbot als HTTP-Proxy. Das SOCKS-Protokoll ermöglicht es, die Transportschicht-Protokolle Transmission Control Protocol (TCP) und User Datagram Protocol (UDP) über einen Proxy umzuleiten. Damit können zusätzlich zu HTTP-basierten Anwendungen auch andere Anwendungen wie z. B. Instant Messaging (IM), Internet Relay Chat (IRC), Secure Shell (SSH) oder mit Orbot als SOCKS-Proxy genutzt werden, sofern die jeweiligen Apps eine Proxy-Konfiguration vorgesehen haben. Darüber hinaus kann Orbot auf Geräten mit Root-Rechten 17 und einer iptables-fähigen 18 Firmware als transparenter Proxy agieren und somit den gesamten TCP-Datenverkehr des Gerätes entgegennehmen, ohne dass dafür eine Proxy-Konfiguration der Anwendungen vorgenommen werden muss. Die Abbildung 3.1 zeigt die Benutzungsoberfläche von Orbot. Die linke Hälfte der Abbildung stellt die Hauptansicht der App dar. Diese enthält eine große Schaltfläche zum Herstellen und Trennen der Verbindung zum Tor-Netzwerk. Die rechte Hälfte zeigt einen Teil des Konfigurationsmenüs der App. Tor für weitere Mobil-Plattformen Offiziell gibt es weitere Portierungen von Tor auf die Mobil-Plattformen Apple ios 19 und Maemo 20. Die ios-portierung setzt ein entsperrtes Gerät voraus (auch als Jailbreak bezeichnet), damit Apps auch von anderen Quellen als dem Apple App Store installiert werden können. Die Installation besteht aus vielen Einzelschritten und ist nur für versierte Anwender mit Hintergrundwissen zu ios zu bewerkstelligen. Die Installation der Maemo-Portierung gestaltet sich ähnlich aufwendig. Beide Portierungen können 17 Üblicherweise haben Android-Apps nur sehr eingeschränkte Rechte und können vereinfacht ausgedrückt weder auf Systemdateien noch auf Dateien anderer Apps zugreifen. Grundlegende Veränderungen am Betriebssystem sind allerdings nur mit administrativen Rechten, sogenannten Root- Rechten, möglich. Den Vorgang des Einräumens von Root-Rechten unter Android bezeichnet man umgangssprachlich als Rooten. 18 Mit dem Linux-Programm iptables kann die im Linux-Kernel integrierte Firewall regelbasiert konfiguriert werden. Auf diese Weise kann auch ein transparenter Proxy eingetragen werden (abgerufen am 30. Dezember 2011) 20 (abgerufen am 30. Dezember 2011) 21

26 Kapitel 3 Entwurf Abbildung 3.1: Benutzungsoberfläche von Orbot (Version alpha-orbot-1.0.6) als experimentell eingestuft werden und sollen aus diesem Grund im Rahmen dieser Arbeit nicht näher betrachtet werden. I2P unter Android Bei I2P 21 handelt es sich um einen Peer-to-Peer-basierten Anonymisierungsdienst, der dem Ansatz eines reinen Peer-to-Peer-basierten Systems folgt und auf den Ideen der Chaumschen Mixe aufbaut [Kö10]. Die Teilnehmer an einem I2P-Netz installieren lokal eine Software, die als I2P-Router bezeichnet wird. Eine offizielle Portierung 22 dieser Software auf die Android-Plattform existiert bereits, jedoch befindet sich diese noch in einem frühen Entwicklungsstadium, was insbesondere an der unübersichtlichen Be- 21 Abkürzung für Invisible Internet Project 22 (abgerufen am 31. Dezember 2011) 22

27 3.2 Architektur nutzungsoberfläche der App erkennbar ist (siehe Abbildung 3.2). Die App kann im Wesentlichen nur den integrierten I2P-Router starten bzw. beenden sowie Status- und Debug-Informationen anzeigen. Konfigurationsmöglichkeiten gibt es bislang keine. Abbildung 3.2: Benutzungsoberfläche der I2P-Android-App (Version android _b1-api8) 3.2 Architektur Art der Anwendung Zunächst muss festgelegt werden, in welcher Form die mobile Client-Software den Anonymisierungsdienst für den Anwender nutzbar machen soll. Im Rahmen des AN.ON- Projektes wurden für Desktop-Systeme bisher zwei unterschiedliche Ansätze realisiert. Einerseits kann ein lokaler Proxy ausgeführt werden, welcher wiederum universell 23

28 Kapitel 3 Entwurf durch andere Anwendungen wie z. B. Web-Browser oder -Clients zur Anonymisierung von deren Netzwerkkommunikation genutzt werden kann. Dieser Ansatz wird vom JAP und auch von dessen Kommandozeilen-Variante JonDoConsole umgesetzt. Andererseits besteht aber auch die Möglichkeit, die Anonymisierungs-Funktionalität z. B. in Form eines Plug-ins direkt in eine Anwendung zu integrieren. Diesem Ansatz folgt die in [Uhl06] entwickelte Erweiterung für den Web-Browser Firefox (siehe Abbildung 3.3). Der Hauptvorteil besteht darin, dass Anwender auf schnelle und einfache Weise den AN.ON-Dienst nutzen können, ohne erst komplizierte Einstellungen vornehmen zu müssen. Ebenso kann die Integration der AN.ON-Client-Komponente auf den jeweiligen Anwendungsfall individuell angepasst werden. So werden beispielsweise bei der Firefox-Erweiterung auch automatisch Browser-Einstellungen vorgenommen, die für die sichere Nutzung des Anonymisierungsdienstes unerlässlich sind. Im Falle einer Proxy-Lösung müssten diese Einstellungen entweder manuell oder mit Hilfe einer zusätzlichen Software wie dem Firefox-Profil JonDoFox vorgenommen werden. Abbildung 3.3: Erweiterung für den Web-Browser Firefox zur Integration einer AN.ON-Client-Komponente [Kö10] Ein entscheidender Nachteil der direkten Integration der Anonymisierungs-Funktionalität ist, dass sich deren Nutzbarkeit nur auf die jeweilige Anwendung beschränkt. Dieser Ansatz würde die Flexibilität der zu entwickelnden Client-Software stark einschränken, da für jede Anwendung eine eigenständige Software-Komponente entwi- 24

29 3.2 Architektur ckelt werden müsste, die den AN.ON-Dienst mit dieser Anwendung nutzbar macht. Aufgrund dessen soll der zu entwickelnde AN.ON-Client analog zum JAP einen lokalen Proxy zur Verfügung stellen Benutzungsoberfläche Gemäß der Anforderung F20 ist die Softwarearchitektur derart zu gestalten, dass eine Portierung der zu entwickelnden Android-Anwendung auf die verschiedenen geeigneten Mobilplattformen mit nur minimalen Anpassungen möglich ist. Um dies zu erreichen, sollen möglichst wenig plattformabhängige, d. h. im vorliegenden Fall Androidspezifische, Software-Komponenten wie beispielsweise Bibliotheken und Frameworks genutzt werden. Android beinhaltet jedoch ein plattformabhängiges Framework zur Entwicklung von grafischen Benutzungsoberflächen, den sogenannten GUIs 23. Mit Necessitas 24 existiert zwar eine Portierung des weit verbreiteten und plattformunabhängigen Qt-Frameworks auf die Android-Plattform, jedoch befindet sich diese noch im Alpha-Stadium und ist nach Aussagen der Entwickler noch nicht für den Produktiveinsatz geeignet, da u. a. die API 25 noch nicht vollständig ist. Die einzige plattformunabhängige und zugleich praktikable Alternative zu einer Android-spezifischen GUI stellt derzeit eine Web-basierte Benutzungsschnittstelle dar (im Folgenden als Weboberfläche bezeichnet), da alle gängigen Mobil-Betriebssysteme für Smartphones und Tablets einen Web-Browser beinhalten, mit dem auf eine Weboberfläche zugegriffen werden kann. Außerdem wurde bereits in [Kö10] erwähnt, dass eine durch einen integrierten Webserver bereitgestellte Weboberfläche die Benutzbarkeit des JAP vereinfachen würde, da somit kein separates Programm zur Bedienung der Client-Software aufgerufen werden müsste. Der zu entwickelnde AN.ON-Client soll aus diesen Gründen über eine Weboberfläche bedient werden können. Die Weboberfläche soll dabei durch einen in den Client integrierten Webserver bereitgestellt werden Bereitstellung der Anonymisierungs-Funktionalität Um die eigentliche Anonymisierungs-Funktionalität bereitzustellen und dabei den Wartungsaufwand für die verschiedenen JAP-Versionen möglichst minimal zu halten, soll 23 Abkürzung für Graphical User Interface 24 (abgerufen am 1. Januar 2012) 25 Abkürzung für Application Programming Interface 25

30 Kapitel 3 Entwurf gemäß der Anforderung F30 auf bereits bestehende Softwarekomponenten des AN.ON- Projektes zurückgegriffen werden. Wie bereits in Abschnitt 1.2 beschrieben, lassen sich mit Hilfe des Java-Controllers JonDoController die Client-Funktionen des JAP steuern. Der JonDoController bietet die höchstmögliche Abstraktion von den Funktionen der ebenfalls in Abschnitt 1.2 erwähnten Java-Bibliothek AnonLib, welche die Kernfunktionalität zur Nutzung des AN.ON-Dienstes implementiert. Deshalb soll der JonDoController auch im zu entwickelnden AN.ON-Client verwendet werden. Genauer gesagt soll dieser über eine Weboberfläche gesteuert werden. Der JonDoController stellt allerdings nur reine Java-Methoden zur Verfügung, die nicht ohne eine weitere Zwischenschicht von der zu entwickelnden Weboberfläche durch übliche Webtechnologien wie beispielsweise HTML oder JavaScript genutzt werden können. Diese Zwischenschicht soll als Webservice realisiert werden. Dadurch kann über die Weboberfläche mit üblichen Webtechnologien, die Bestandteil aller gängigen Web-Browser sind, auf die Funktionen des JonDoControllers zugegriffen werden. Paradigmen von Webservices Es gibt prinzipiell zwei verbreitete Paradigmen zur Gestaltung von Webservices. Das ist zum einen SOAP 26 und zum anderen REST 27. Im Allgemeinen gilt REST verglichen mit SOAP als leichtgewichtiger, verständlicher, ressourcenschonender und einfacher implementierbar. Dennoch bietet SOAP gerade für komplexe Webservices mehr Gestaltungsmöglichkeiten. Die beiden Architekturstile können auch miteinander kombiniert eingesetzt werden. In [RL09] wurde der REST-Architekturstil im Hinblick auf mobile Webservices untersucht. Dabei kommen die Autoren zu dem Ergebnis, dass sich mit REST Webservices realisieren lassen, die an eine clientseitige Hard- und Software vergleichsweise geringe Anforderungen stellen und deshalb auch für mobile Geräte geeignet sind. Von besonderer Bedeutung ist der Umstand, dass bei dem zu entwickelnden AN.ON-Client sowohl der Webservice als auch der dazugehörige Client, der auf den Webservice zugreift, auf demselben Gerät ausgeführt werden sollen. Dadurch ist die auf mobilen Geräten üblicherweise eingeschränkte Netzanbidung für den Webservice nahezu irrelevant, da dessen Übertragungen alle lokal erfolgen. Dennoch kann sich auch in diesem Fall ein schlankes Protokoll positiv auf die Systemressourcen auswir- 26 ursprüngliche Abkürzung für Simple Object Access Protocol 27 Abkürzung für Representational State Transfer 26

31 3.2 Architektur ken (siehe Anforderung F60). Da der zu entwickelnde Webservice grundsätzlich nur dem Zweck der Interaktion zwischen Weboberfläche und JonDoController dienen soll, stellt REST dafür aufgrund seiner Schlichtheit ein geeignetes Paradigma dar. Im folgenden Abschnitt sollen die Grundlagen von REST kurz erläutert werden. Grundlagen von REST REST ist kein definierter Standard, sondern ein von Roy Thomas Fielding, einem der Hauptautoren der HTTP-Spezifikation, in seiner Dissertation [Fie00] beschriebener Architekturstil für verteilte Anwendungen. REST basiert dabei auf den Prinzipien des WWW. Anwendungen, die das REST-Paradigma umsetzen, bestehen aus Clients und Servern. Clients senden Anfragen an Server, welche diese verarbeiten und wiederum Antworten zurückliefern. Dabei sind Anfragen und Antworten Repräsentationen (engl.: representations) von Ressourcen. Letztere stellen adressierbare Entitäten innerhalb einer Anwendung dar. Fielding beschreibt sechs Eigenschaften, die eine verteilte Anwendung aufweisen muss, um REST-konform zu sein: 1. Client-Server Client und Server sind funktional voneinander getrennt. Das bedeutet beispielsweise, dass die Datenhaltung einer verteilten Anwendung ausschließlich serverseitig und die Darstellung einer Benutzungsoberfläche ausschließlich clientseitig erfolgt. 2. Stateless Die Client-Server-Kommunikation ist zustandslos, d. h. jede Anfrage eines Clients enthält aus Sicht des jeweiligen Servers alle benötigten Informationen, um von diesem ohne Kenntnis anderer Anfragen verarbeitet zu werden. Dabei werden Sitzungen ausschließlich clientseitig verwaltet. 3. Cache Ein Client kann Server-Antworten cachen. Dazu muss ein Server für jede Antwort implizit oder explizit festlegen, ob diese clientseitig gecached werden darf oder nicht. 27

32 Kapitel 3 Entwurf 4. Uniform Interface Es existiert systemweit eine einheitliche Schnittstelle zur Client-Server-Kommunikation. 5. Layered System Ein Client kann aufgrund einer möglichen Schichtenorientierung des Systems nicht feststellen, ob er direkt mit dem jeweiligen Ziel-Server oder aber mit einem dazwischenliegenden Server kommuniziert. Letztere realisieren z. B. Lastverteilung oder Caching. 6. Code-on-Demand Ein Server kann die Funktionalität eines Clients anpassen oder erweitern, indem er ausführbare Inhalte wie z. B. Java-Applets oder JavaScript-Code liefert. Diese Bedingung ist optional. Die vierte Eigenschaft unterscheidet REST von anderen netzwerkbasierten Architekturstilen. An die einheitliche Schnittstelle eines REST-Dienstes stellt Fielding wiederum vier Anforderungen: 1. Identification of Resources Jede Ressource eines Servers ist über eine Adresse wie z. B. einen URI 28 eindeutig identifizierbar. 2. Manipulation of Resources through Representations Mit einer Repräsentation einer Ressource kann ein Client diese auf dem jeweiligen Server verändern oder auch entfernen, wenn er die dafür nötigen Rechte besitzt. 3. Self-descriptive Messages Jede Nachricht (Anfrage oder Antwort) beinhaltet ausreichend Informationen über deren weitere Verarbeitung. 4. Hypermedia as the Engine of Application State Ein Client führt Zustandsübergänge dynamisch auf Basis des vom Server gelieferten hypermedialen Inhalts durch. 28 Abkürzung für Uniform Resource Identifier 28

33 3.2 Architektur Ein REST-konformer Webservice wird auch als RESTful Webservice oder RESTful Web API bezeichnet. Dabei wird für die Client-Server-Kommunikation das HTTP-Protokoll verwendet. Ressourcen werden über URIs identifiziert und als Internet Media Type repräsentiert. In der Regel werden für diesen Zweck JSON 29 oder XML 30 verwendet. Der Zugriff auf die Ressourcen erfolgt über die HTTP-Operationen, darunter GET, POST, PUT und DELETE. An dieser Stelle sei noch darauf hingewiesen, dass im praktischen Einsatz viele der als RESTful gekennzeichneten Webservices gar nicht alle der aufgeführten Eigenschaften besitzen, sondern lediglich einige der Konzepte von REST übernehmen. Diese Webservices werden umgangssprachlich auch als REST-like oder REST-ähnlich bezeichnet. Auch der zu entwickelnde Webservice muss nicht zwingend alle Eigenschaften von REST besitzen, da bestimmte Kriterien wie z. B. Skalierbarkeit bei einem lokalen Webservice irrelevant sind. Es genügt daher, den Webservice REST-like zu gestalten Zusammenfassung der Softwarearchitektur In Tabelle 3.2 werden die in diesem Kapitel getroffenen Architekturentscheidungen zusammengefasst. Fragestellung Art der Anwendung Art der Benutzungsoberfläche Bereitstellung der Anonymisierungs- Funktionalität Bereitstellung der Weboberfläche Steuerung des JonDoControllers Umsetzung lokaler Proxy (analog zum JAP) Weboberfläche (HTML, CSS, JavaScript,...) Nutzung des JonDoControllers im Client integrierter Webserver Weboberfläche nutzt einen REST-like Webservice als Zwischenschicht Tabelle 3.2: Zusammenfassung der Architekturentscheidungen Des Weiteren veranschaulicht die Abbildung 3.4 die Softwarearchitektur der zu entwickelnden Client-Software. 29 Abkürzung für JavaScript Object Notation 30 Abkürzung für Extensible Markup Language 29

34 Kapitel 3 Entwurf Mobiler AN.ON-Client Web-Browser des mobilen Gerätes JonDoController Java-Methodenaufrufe REST-like Webservice HTTP Weboberfläche (HTML, CSS, JavaScript, ) Webserver HTTP Abbildung 3.4: Softwarearchitektur der Client-Software 3.3 Funktionalität der Benutzungsoberfläche In diesem Abschnitt wird in Anlehnung an den JAP beschrieben, welche konkreten Nutzfälle und Funktionen der mobile AN.ON-Client unterstützen soll. In diesem Zusammenhang sollen auch Funktionen untersucht werden, die sich für den Einsatz auf mobilen Geräten aus bestimmten Gründen nicht eignen. Nachfolgend werden Basisnutzfälle aufgeführt, ohne welche die Client-Software für ihren eigentlichen Zweck nicht sinnvoll nutzbar wäre: verfügbare Anonymisierungsdienste vom InfoService laden Auswählen eines Anonymisierungsdienstes Verbindung mit einem ausgewählten Anonymisierungsdienst herstellen Verbindung zu einem Anonymisierungsdienst trennen Unter der Voraussetzung, dass auf dem mobilen Gerät durch den JonDoController 30

35 3.3 Funktionalität der Benutzungsoberfläche ein lokaler Proxy zur Anonymisierung bereitgestellt wird, reichen die Basisnutzfälle für eine einfache Nutzung des AN.ON-Dienstes bereits aus. Ein Anwender könnte sich als Ersatz für die fehlenden Statusinformationen im Client beispielsweise auf der Website des AN.ON-Projektes 31 über die Details der verfügbaren Anonymisierungsdienste informieren. Das im Rahmen des AN.ON-Projektes entwickelte Java-Programm SimpleJonDo demonstriert prinzipiell eine noch einfachere Alternative, die bis auf das Starten und Beenden der Anwendung keine Benutzerinteraktion vorsieht. Jedoch ist diese Art der Nutzung nicht im Sinne des AN.ON-Dienstes, da die bewusste Auswahl eines Anonymisierungsdienstes für dessen sichere Benutzung notwendig ist. Da das manuelle Abrufen von Statusinformationen für den Anwender unkomfortabel wäre, stellt das Anzeigen von Statusinformationen zu den verfügbaren Anonymisierungsdiensten einen weiteren wichtigen Nutzfall dar. Zu diesen Statusinformationen gehören analog zum JAP die Anzahl der Nutzer, Informationen über die Mixe und deren Betreiber sowie Angaben zur Dienstgüte. Ein weiterer Nutzfall ist das Filtern der verfügbaren Anonymisierungsdienste nach bestimmten Kriterien, damit der Anwender seinen gewünschten Dienst unter einer überschaubaren Anzahl an Diensten auswählen oder ähnliche Dienste miteinander vergleichen kann. Dabei sollen die konkreten Filterkriterien im Zuge der Implementierung anhand von Usability-Gesichtspunkten festgelegt werden. Die Nutzfälle Sperren und Freigeben von Diensten sollen ebenfalls berücksichtigt werden (sogenanntes Blacklisting). Ebenso wie der JAP soll der mobile AN.ON-Client Bezahlkonten (im Folgenden nur als Konten bzw. Konto bezeichnet) unterstützen und sich mit den sogenannten Premiumdiensten verbinden können. Aus dieser Anforderung heraus ergeben sich die folgenden Nutzfälle: Konto durch Eingabe eines Gutscheincodes anlegen Konten aus einer Datei importieren (ggf. mit Kennwortschutz) Konten in eine Datei exportieren (ggf. mit Kennwortschutz) aktives Konto auswählen Kontoinformationen anzeigen 31 (abgerufen am 11. Januar 2012) 31

36 Kapitel 3 Entwurf Kontoinformationen von einer Bezahlinstanz aktualisieren Konto löschen Der JAP bietet zusätzlich noch die Möglichkeit, Guthaben über diverse Bezahloptionen wie z. B. PayPal oder paysafecard auf neu erstellte Konten aufzuladen. An dieser Stelle muss zwangsläufig auf die Implementierung vorgegriffen werden, da jede zu implementierende Funktionalität auch von der Schnittstelle 32 des JonDoControllers unterstützt werden muss. Allerdings unterstützt der JonDoController bis dato nicht alle Funktionen des JAP. So steht u. a. das soeben geschilderte Aufladen des Guthabens eines Kontos über Bezahloptionen nicht zur Verfügung. Die dafür benötigten Funktionen sind Bestandteil der AnonLib. Im Zuge der Implementierung soll deshalb überprüft werden, ob es zweckmäßig ist, die vom JonDoController nicht unterstützten Funktionen stattdessen durch direkte Nutzung der AnonLib zu realisieren. Nutzer sollen an der Anwendung auch Einstellungen vornehmen können. Dazu gehören beispielsweise das Ändern der Sprache der Benutzungsoberfläche sowie Einstellungen, die auch am JonDoController vorgenommen werden können. Zudem gibt es noch eine Reihe obligatorischer Nutzfälle, welche die Benutzungsfreundlichkeit erhöhen: Hilfe zur Anwendung anzeigen allgemeine Informationen zur Anwendung anzeigen (z. B. Versionsnummer, Name des Herstellers und Link zur Website) Anwendung beenden In der Benutzungsoberfläche des mobilen AN.ON-Clients sollen weitestgehend die gleichen Begrifflichkeiten wie im JAP verwendet werden. Diese Vereinheitlichung sorgt insbesondere dafür, dass Anwender, die bereits mit dem JAP vertraut sind, besser mit dem mobilen Client umgehen können. Im JAP können Anwender den sogenannten Anti-Zensur-Dienst aktivieren, um somit anderen AN.ON-Nutzern, die aufgrund von Zensur oder anderen restriktiven Maßnahmen keine direkte Verbindung zu den Diensten von AN.ON herstellen können, die 32 (abgerufen am 12. Januar 2012) 32

37 3.4 Sicherheitsbetrachtung Nutzung dieser Dienste über die eigene Client-Software zu ermöglichen. Der Anti- Zensur-Dienst belastet die Systemressourcen zusätzlich zum eigenen Gebrauch. Für Desktop-Systeme, die in der Regel breitbandig ans Internet angebunden sind und über ausreichend Systemressourcen verfügen, stellt diese Funktion aus technischer Sicht kein Problem dar. Für mobile Geräte hingegen ist sie eher ungeeignet, da diese zumeist über eingeschränkte Systemressourcen verfügen und häufig schmalbandig sowie mit Unterbrechungen der Verbindung ans Internet angebunden sind. Außerdem erfordert der Anti-Zensur-Dienst einen TCP-Port, der für eingehende Verbindungen aus dem Internet freigeschaltet sein muss. Genau das ist aber bei mobilen Geräten problematisch, da diese sich in unterschiedlichen Netzen aufhalten. Diese Netze schützen ihre Teilnehmer vor Zugriffen aus dem Internet im Allgemeinen durch Firewalls, welche für den Anti-Zensur-Dienst erst konfiguriert werden müssten. Viele Netze wie z. B. Mobilfunknetze oder öffentliche WLANs 33 lassen jedoch eine derartige Konfiguration gar nicht erst zu. Vor diesem Hintergrund soll der Anti-Zensur-Dienst in dem mobilen AN.ON- Client nicht zur Verfügung stehen. Der JAP ermöglicht es auch, die Anti-Zensur-Dienste anderer AN.ON-Nutzer zu verwenden. Im Gegensatz zum eigentlichen Anti-Zensur-Dienst eignet sich diese Funktion uneingeschränkt für mobile Geräte, allerdings wird sie vom JonDoController nicht unterstützt. Analog zur Bezahlfunktion soll im Zuge der Implementierung überprüft werden, inwiefern sich diese Funktion durch direkte Nutzung der AnonLib realisieren lässt. 3.4 Sicherheitsbetrachtung Da die Anonymisierungs-Funktionalität analog zu bereits bestehenden AN.ON-Anwendungen durch den JonDoController bereitgestellt wird, müssen an dieser Stelle nur die neu hinzugekommenen Softwarekomponenten Webservice, Webserver und Weboberfläche betrachtet werden. Webservice und Webserver werden lokal ausgeführt und dürfen nur Verbindungen vom eigenen Host entgegennehmen. Der Webservice stellt eine Schnittstelle zum Jon- DoController dar. Grundsätzlich können alle Anwendungen, die auf dem Mobilgerät ausgeführt werden, diese Schnittstelle verwenden, um beispielsweise Statusinforma- 33 Abkürzung für Wireless Local Area Network 33

38 Kapitel 3 Entwurf tionen zu beziehen oder sogar Steuerbefehle abzugeben. Wie beim JAP zählt die Ausführungsumgebung der mobilen Client-Software zum sogenannten vertrauenswürdigen Bereich. Auf einem Desktop-Rechner könnte eine böswillige Anwendung, die parallel zum JAP ausgeführt wird, ebenfalls Steuerbefehle an die GUI des JAP abgeben und somit den Dienst beeinträchtigen. Durch den Webservice besteht nunmehr die Möglichkeit, dass selbst Webseiten im Internet, die nicht mehr zum vertrauenswürdigen Bereich zählen, über einen auf dem Mobilgerät installierten Web-Browser mit dem lokalen Webservice und demzufolge auch mit dem JonDoController interagieren. Derartige Sicherheitslücken sind schon bei anderen Anwendungen mit Netz- bzw. Webbasierter Schnittstelle aufgetreten [Kap07, Bac08]. Abhängig von der konkreten Implementierung sollen daher geeignete Abwehrmaßnahmen getroffen werden. Der Webserver liefert lediglich Inhalte zur Darstellung der Weboberfläche. Über diese Schnittstelle darf sich der Zustand des JonDoControllers weder auslesen noch verändern lassen. Dadurch bleiben oben geschilderte Angriffe auf den Webserver ohne Wirkung. Die Kommunikation zwischen der Weboberfläche und den lokalen Komponenten Webservice bzw. Webserver erfolgt unverschlüsselt, da auch das zugrundeliegende lokale Netzwerk des Mobilgerätes als vertrauenswürdig eingestuft wird. 34

39 Kapitel 4 Implementierung In diesem Kapitel wird gemäß der Anforderung F10 eine konkrete Umsetzung der mobilen Client-Software für die Android-Plattform vorgestellt. Diese App trägt den Namen ANONdroid 1. Android ist aktuell in Version mit dem Namen Ice Cream Sandwich verfügbar (erschienen am 16. Dezember 2011). Jedoch besitzen ältere Versionen teilweise eine hohe Verbreitung. Das Diagramm in Abbildung 4.1 veranschaulicht die Verbreitung der verschiedenen Android-Versionen. Den Werten liegen die Zugriffszahlen auf den Android Market innerhalb von 14 Tagen zugrunde, wobei dieser Zeitraum am 3. Januar 2012 endete. Damit ANONdroid möglichst von vielen Anwendern genutzt werden kann, sollte die minimal unterstützte Android-Version so klein wie möglich gewählt werden. Bei älteren Versionen können jedoch API-Funktionen fehlen, die für die Ausführung der App notwendig sind. In solchen Fällen muss man einen Kompromiss zwischen Funktionalität und Kompatibilität eingehen. Die für das Parsen von XML-Dokumenten verwendeten Klassen im Paket javax.xml.xpath sind erst ab Android 2.2 Bestandteil der Android-API. Da jedoch die AN.ON-Kernbibliotheken dieses Paket benötigen, ist Android 2.2 im Hinblick auf die API-Kompatibilität die minimal unterstützte Android- Version. Hinzu kommt allerdings, dass die Klasse java.math.biginteger unter Android 2.2 fehlerhaft implementiert ist und in bestimmten Konstellationen zum Absturz der Dalvik-VM führen kann. Dieser Fehler tritt im Zusammenhang mit den kryptografischen Operationen der AnonLib auf. Deshalb setzt die vorliegende Implementierung mindestens das fehlerbereinigte Android 2.3 voraus. Gemessen an der Verbreitung der Android-Versionen im Januar 2012 kann ANONdroid durch diese Anforderung nur 1 ANONdroid ist ein Kofferwort, das sich aus den Namen des Anonymisierungsdienstes AN.ON und der Mobil-Plattform Android zusammensetzt. 35

40 Kapitel 4 Implementierung von knapp 60 Prozent aller Android-Anwender genutzt werden (siehe Abbildung 4.1). Android 4.x 0,6% Android 3.x 3,3% Android 1.5 0,6% Android 1.6 1,1% Android 2.1 8,5% Android ,5% Android ,4% Abbildung 4.1: Verbreitung der Android-Versionen gemessen an den Zugriffszahlen auf den Android Market innerhalb von 14 Tagen bis zum 3. Januar 2012, Quelle: Google, Inc Entwicklungs- und Testumgebung Für die Entwicklung wurde die weit verbreitete Open-Source-Entwicklungsumgebung Eclipse verwendet. Für diese IDE 3 gibt es offiziell das ADT 4 -Plug-in, welches zahlreiche Android-spezifische Funktionen bereitstellt und wichtige Tools des Android-SDKs in Eclipse integriert. Da die Softwarekomponenten des AN.ON-Projektes das Build- Management-Tool Apache Maven verwenden, kommt es auch bei ANONdroid zum 2 (abgerufen am 16. Januar 2012) 3 Abkürzung für Integrated Development Environment 4 Abkürzung für Android Developer Tools 36

41 4.2 Systemaufbau Einsatz. Das dazugehörige Maven-Plug-in 5 für Android stellt diverse Maven-Goals zur Verfügung, die für den Build- und Deployment-Prozess hilfreich sind. So veranlasst beispielsweise das Goal android:deploy die Übertragung der App, welche nach dem Build-Prozess als APK-Datei vorliegt, auf ein angeschlossenes Mobilgerät oder einen Android-Emulator. Letzterer ermöglicht das Testen der App ohne physisches Mobilgerät. Das Android-SDK beinhaltet Emulatoren für alle Android-Versionen ab 1.5. Diese sind besonders hilfreich, wenn man testen möchte, ob die App mit den verschiedenen API-Levels von Android kompatibel ist. Für komplexe Anwendungsszenarien sind die Emulatoren jedoch eher ungeeignet, da sie auf handelsüblichen Rechnern sehr langsam ausgeführt werden. Aufgrund dessen wurde ANONdroid überwiegend mit Hilfe der Smartphones HTC Desire 6 und Samsung Galaxy S II GT-I entwickelt. Die Geräte werden dabei über die USB-Schnittstelle mit dem Rechner verbunden. 4.2 Systemaufbau Android-Apps bestehen aus Komponenten. Es gibt vier unterschiedliche Komponententypen, wobei eine App mehrere Komponenten des gleichen Typs beinhalten kann. Die Komponententypen werden im Folgenden kurz vorgestellt: Activities Eine Activity ist eine den ganzen Bildschirm füllende grafische Komponente, die in der Regel zur Darstellung einer Benutzungsoberfläche verwendet wird. Services Ein Service läuft autonom im Hintergrund des Systems und hat keine eigene Benutzungsoberfläche. Er besitzt eine höhere Priorität als eine Activity und wird beispielsweise zur Ausführung von Aufgaben mit langer Laufzeit genutzt. Andere Komponenten können mit einem Service interagieren. Content Providers Ein Content Provider stellt anderen Anwendungen über eine einheitliche Schnittstelle Daten zur Verfügung und abstrahiert dabei deren Speicherort (Datei, Datenbank, Web-Ressource etc.). 5 (abgerufen am 16. Januar 2012) 6 Android 2.2, 1 GHz Single-Core-Prozessor, 512 MB RAM, Pixel Auflösung 7 Android 2.3.5, 1,2 GHz Dual-Core-Prozessor, 1 GB RAM, Pixel Auflösung 37

42 Kapitel 4 Implementierung Broadcast Receivers Ein Broadcast Receiver reagiert auf systemweite Broadcast-Ereignisse. JonDoController, Webservice und Webserver sollen innerhalb eines Service ausgeführt werden, da diese über einen langen Zeitraum ohne Unterbrechung nutzbar gemacht werden müssen. Die Weboberfläche könnte zwar grundsätzlich über einen beliebigen Web-Browser aufgerufen werden, jedoch müsste sich der Nutzer an der Weboberfläche aus Sicherheitsgründen beispielsweise mit einem Kennwort authentifizieren, damit böswillige Webseiten keine Steuerbefehle an den Webservice abgeben können. Mit einem sogenannten WebView ist es möglich, den bei Android mitgelieferten Browser in eine eigene Activity zu integrieren und mit den jeweiligen Authentifizierungsinformationen zu versehen, ohne dass der Nutzer etwas davon mitbekommt. Da der WebView lediglich die Weboberfläche darstellt und deren Sitzung ausschließlich innerhalb der Activity gültig ist, wird böswilligen Webseiten keine Möglichkeit geboten, diese Sitzung für Angriffe auszunutzen. Zudem wird dem Anwender die Weboberfläche wie eine konventionelle Benutzungsoberfläche zugänglich gemacht. Neben dem Service soll es daher eine Activity geben, welche die Weboberfläche darstellt. Unter Android ist der dynamische Speicher, der sogenannte Heap, im ungünstigsten Fall für jeden Prozess nur 16 MB groß. Aktuelle Geräte haben zwar immerhin ein unteres Limit von 24 MB, jedoch ist auch dieser Wert verglichen mit dem auf Desktop- Rechnern zur Verfügung stehendem Speicher sehr gering. Service und Activity sollen deswegen in getrennten Prozessen ausgeführt werden. Dadurch steht den Komponenten der App insgesamt mehr Speicher zur Verfügung und die Wahrscheinlichkeit von sogenannten Out-of-Memory-Exceptions, die bei zu wenig vorhandenem Speicher auftreten, wird reduziert. Außerdem wirken sich getrennte Prozesse positiv auf die Stabilität der App aus. Stürzt beispielsweise der Activity-Prozess aufgrund eines Laufzeitfehlers ab, kann der Hintergrunddienst dennoch weiter ausgeführt werden, da dieser nicht von der Benutzungsoberfläche abhängig ist. Im umgekehrten Fall eines Absturzes des Service-Prozesses kann die Activity jedoch nicht weiter ausgeführt werden, da diese vom Service abhängig ist. Für jede Android-App existiert genau eine XML-Datei mit dem Namen AndroidManifest.xml. Diese Datei enthält Metadaten über die App. Neben essenziellen Angaben wie beispielsweise dem Paketnamen, der Versionsnummer, dem geforderten API-Level und den benötigten Zugriffsrechten werden in dieser Datei auch die Komponenten 38

43 4.3 Systemkomponenten und Implementierungsaspekte der App beschrieben. Das Listing 4.1 zeigt einen Auszug aus dieser Datei, in welchem die beiden Komponenten Service und Activity aufgeführt werden. Das Attribut android:exported (Zeile 16) legt fest, ob der Service auch von anderen Komponenten außerhalb der App gestartet werden kann. Im vorliegenden Fall soll das jedoch nicht erlaubt sein. Über das Attribut android:process (Zeile 17) wird der Name des Prozesses angegeben, in welchem der Service ausgeführt wird. Der Doppelpunkt am Anfang des Prozessnamens besagt, dass andere Apps auf dem Mobilgerät nicht auf diesen Prozess zugreifen können. AndroidManifest.xml 1 [...] 2 <application android:icon="@drawable/icon" 3 android:label="@string/app_name" 4 android:debuggable="true"> 5 <activity android:name=".anondroid" 6 android:configchanges="orientation keyboardhidden" 7 android:label="@string/app_name" 8 android:launchmode="singletop" 9 android:statenotneeded="true"> 10 <intent-filter> 11 <action android:name="android.intent.action.main" /> 12 <category android:name="android.intent.category.launcher" /> 13 </intent-filter> 14 </activity> 15 <service android:name=".anondroidservice" 16 android:exported="false" 17 android:process=":service" /> 18 </application> 19 [...] Listing 4.1: Auszug aus der Datei AndroidManifest.xml 4.3 Systemkomponenten und Implementierungsaspekte Service Der Hintergrunddienst von ANONdroid wird in der Klasse AnondroidService implementiert. Unter Android kann ein Service started, bound oder beides sein. Ein sogenannter Started Service wird von einer anderen Komponente wie z. B. einer Activity gestartet 39

44 Kapitel 4 Implementierung und dann unabhängig von dieser ausgeführt, auch wenn die Komponente selbst nicht mehr ausgeführt wird. Ein Bound Service hingegen wird aufgerufen, wenn sich eine Komponente an diesen bindet. Es können sich auch mehrere Komponenten an einen Bound Service binden. Komponenten interagieren mit einem Bound Service über eine Client-Server-Schnittstelle. Ein Bound Service wird beendet, wenn es keine Komponenten mehr gibt, die an diesen Service gebunden sind. Bei ANONdroid wird ein Started Service verwendet, weil der Hintergrunddienst, welcher die eigentliche Funktionalität der App bereitstellt, unabhängig von der Lebensdauer der Activity ausgeführt werden soll. Die Abbildung 4.2 veranschaulicht den Lebenszyklus eines Started Service. Durch den Aufruf der Methode startservice() wird der Service gestartet. Wenn der Service noch nicht läuft, wird zunächst die im Service implementierte Methode oncreate() aufgerufen, um vorbereitende Aufgaben auszuführen. Im nächsten Schritt wird die Methode onstartcommand() aufgerufen, welche die Startanfrage anhand übergebener Parameter auswerten und abhängig davon weitere Aufgaben ausführen kann. Der Service ist so lange aktiv, bis er sich selbst durch einen Aufruf der Methode stopself() beendet oder aber durch einen Aufruf der Methode stopservice() innerhalb einer anderen Komponente beendet wird. Allerdings kann das Betriebssystem einen Service bei zu geringem Speicher beenden. Inwiefern der Service danach wieder neu gestartet wird, hängt vom Rückgabewert der Methode onstartcommand() ab. Bei ANONdroid soll der Hintergrunddienst nach einem unerwünschten Beenden vorerst nicht automatisch neu gestartet werden. Dieses Verhalten wird durch die Konstante START_NOT_STICKY erwirkt. Um dem Betriebssystem zu signalisieren, dass der Service eine hohe Priorität besitzt und ein Beenden dessen die Aktivität des Anwenders unterbrechen würde, wird der Service durch einen Aufruf der Methode startforeground() als sogenannter Foreground Service ausgeführt. Dadurch wird die Wahrscheinlichkeit, dass der Hintergrunddienst von ANONdroid aufgrund von Speichermangel beendet wird, auf ein Minimum reduziert. Der Startvorgang des Service besteht aus den folgenden Schritten: 1. Laden der Benutzereinstellungen 2. Initialisieren des JonDoControllers 3. Starten des Webservice und des Webservers 40

45 aktive Lebenszeit 4.3 Systemkomponenten und Implementierungsaspekte startservice() oncreate() onstartcommand() Service wird ausgeführt Service beendet ondestroy() Abbildung 4.2: Lebenszyklus eines Started Service unter Android, Quelle: Google, Inc. 8 Um den Nutzer jederzeit über den Verbindungsstatus des JonDoControllers zu informieren, wird eine sogenannte Status Bar Notification verwendet. Damit wird in der Statusleiste am oberen Bildschirmrand des Mobilgerätes ein aussagekräftiges Icon angezeigt (siehe Abbildung 4.3). Ein ausgegrautes Icon mit einem roten Rechteck in der unteren rechten Ecke bedeutet, dass keine Verbindung zu einem Anonymisierungsdienst besteht. Ein farbiges Icon hingegen signalisiert eine hergestellte Verbindung. Leuchten die Augen des stilisierten AN.ON-Nutzers zudem rot, dann werden in dem Moment Nutzdaten über den Anonymisierungsdienst übertragen. Zusätzlich erscheint im Benachrichtigungsfenster ein bis zu zwei Zeilen umfassender Hinweistext in der eingestellten Sprache (siehe Abbildung 4.4). Wählt der Nutzer diesen Eintrag aus, dann wird die Activity mit der Weboberfläche gestartet bzw. in den Vordergrund gebracht. Somit kann sich der Nutzer beispielsweise detaillierte Statusinformationen anzeigen lassen. 8 (abgerufen am 22. Januar 2012) 41

46 Kapitel 4 Implementierung Abbildung 4.3: Statusleistensymbol in drei verschiedenen Zuständen Logging Für das Loggen von Anwendungsmeldungen bietet die Android-API eine eigene Schnittstelle an. Die Klasse android.util.log enthält mehrere statische Methoden, mit denen Meldungen unterschiedlicher Protokollebenen, auch Logging-Level genannt, protokolliert werden können. Die folgende Anweisung erzeugt beispielsweise eine Log-Meldung mit Debug-Informationen: Log.d("ANONdroid", "connection state has changed"); Der erste Parameter, das sogenannte Tag, kennzeichnet die Herkunft der Log-Meldung (Klasse, Activity, Anwendung etc.). Der zweite Parameter ist der Text der Log-Meldung. Neben der Methode d() für das Logging-Level Debug gibt es noch die Methoden e() für Error, i() für Info, v() für Verbose und w() für Warn. Die Log-Meldungen lassen sich mit installiertem ADT-Plug-in über den Eclipse-View LogCat anzeigen. Weiterhin können sie auch über das Kommandozeilenprogramm adb, welches Bestandteil des Android-SDKs ist, mit dem Aufruf adb logcat angezeigt werden. Die genannten Varianten benötigen eine USB-Verbindung zwischen Rechner und Mobilgerät. Um die Log-Meldungen direkt auf dem Mobilgerät anzeigen zu lassen, muss auf Apps wie z. B. alogcat 9 zurückgegriffen werden. Der JonDoController erzeugt ebenfalls Log-Meldungen. Dafür verwendet er allerdings nicht die Android-API, sondern eine bei dessen Initialisierung übergebene Instanz einer Logging-Schnittstelle. Dies kann entweder ein Logger der Apache-Bibliothek Commons Logging, ein Logger des verbreiteten Logging-Frameworks log4j oder aber ein Objekt sein, dessen Klasse das Interface ILog der Logging-Bibliothek logging- 9 (abgerufen am 24. Januar 2012) 42

47 4.3 Systemkomponenten und Implementierungsaspekte Abbildung 4.4: Hinweistexte im Benachrichtigungsfenster lib des AN.ON-Projektes implementiert. Da die Android-API hierfür keine unmittelbar kompatible Logging-Schnittstelle zur Verfügung stellt, werden deren Logging-Methoden von der neuen Klasse AndroidLog abstrahiert. Diese Klasse erbt von der abstrakten Klasse AbstractLog, welche wiederum das ILog-Interface implementiert und ebenfalls Bestandteil der logginglib-bibliothek ist. Das Klassendiagramm in Abbildung 4.5 veranschaulicht das Logging in ANONdroid. Die Methode log() der Klasse AndroidLog bildet schließlich die Log-Meldungen im Format der logginglib-bibliothek auf die Logging-Methoden der Android-API ab. Die Logging-Level der logginglib-bibliothek sind jedoch feingranularer als diejenigen der Android-API. Aus diesem Grund werden die in der Android-API nicht vorhandenen Logging-Level in eckigen Klammern vor die ursprüngliche Log-Meldung geschrieben. Diese Zuordnung wird in Tabelle 4.1 dargestellt. 43

48 Kapitel 4 Implementierung Visual Paradigm for UML Community Edition [not for commercial use] <<Interface>> ILog +log(level : int, type : int, message : String) +setloglevel(level : int) +getloglevel() : int +setlogtype(type : int) +getlogtype() : int -m_level : int -m_type : int AbstractLog +AbstractLog() +AbstractLog(level : int, type : int) +islogged(level : int, type : int) : boolean +islogged(logger : ILog, level : int, type : int) : boolean +setloglevel(level : int) +getloglevel() : int +setlogtype(type : int) +getlogtype() : int AndroidLog +log(level : int, type : int, message : String) <<use>> android.util.log +d(tag : String, message : String) : int +e(tag : String, message : String) : int +i(tag : String, message : String) : int +v(tag : String, message : String) : int +w(tag : String, message : String) : int Abbildung 4.5: Klassendiagramm des Loggings Logging-Level der android.util.log logginglib-bibliothek Logging-Level Präfix vor Log-Meldung Emergency Error [EMERG] Alert Error [ALERT] Exception Error [EXCEPTION] Error Error [ERROR] Warning Warn - Notice Verbose - Info Info - Debug Debug - Tabelle 4.1: Zuordnung der Logging-Level zwischen logginglib-bibliothek und der Klasse android.util.log der Android-API 44

49 4.3 Systemkomponenten und Implementierungsaspekte Alle Log-Meldungen werden mit dem Tag ANONdroid gekennzeichnet. Anhand dessen kann die Log-Ausgabe zur Laufzeit gefiltert werden, sodass beispielsweise nur Log-Meldungen von ANONdroid angezeigt werden. Jede Log-Meldung der logginglib- Bibliothek kann neben dem Logging-Level auch einen oder mehrere Typen besitzen. Ein Typ kennzeichnet dabei den Bereich, auf den sich eine Log-Meldung bezieht. Die Angabe des Typs ist nicht Bestandteil der Log-Ausgabe von ANONdroid. Dafür kann allerdings im Zuge der Initialisierung des JonDoControllers festgelegt werden, dass nur Log-Meldungen bestimmter Typen ausgegeben werden. Log-Meldungen werden in ANONdroid genau wie auch in anderen Softwarekomponenten des AN.ON-Projektes, welche die logginglib-bibliothek verwenden, durch einen Aufruf der Methode log() der Klasse LogHolder erzeugt, wie das folgende Beispiel demonstriert: LogHolder.log(LogLevel.INFO, LogType.NET, "Web service started"); Webservice Die Java API for RESTful Web Services (JAX-RS) ist eine API-Spezifikation für die Programmiersprache Java, welche sowohl das Erstellen als auch das Nutzen REST-konformer Webservices ermöglicht und vereinheitlicht. Die Referenzimplementierung von JAX-RS stellt das Open-Source-Framework Jersey dar. Weitere bekannte Implementierungen sind Restlet, RESTEasy, Apache Wink und die JAX-RS-Erweiterung von Apache CXF. Die bis dato einzige offiziell mit Android kompatible Implementierung ist Restlet. Zwar können faktisch auch andere Implementierungen wie z. B. Jersey unter Android verwendet werden, jedoch ist es gerade im Hinblick auf die verschiedenen Android-Versionen und die spezifischen Eigenschaften mobiler Geräte vorteilhaft, wenn Android explizit unterstützt wird. Da Restlet gemäß der Anforderung F40 Open- Source-Software ist, einen schlanken Kern besitzt und darüber hinaus je nach Anforderung über Plug-ins erweitert werden kann, wird es zur Realisierung des Webservice in ANONdroid verwendet. Restlet wird in sechs verschiedenen Ausgaben angeboten. Neben einer Ausgabe für Android gibt es Restlet-Ausgaben für Java SE 10, Java EE 11, 10 Abkürzung für Java Platform, Standard Edition 11 Abkürzung für Java Platform, Enterprise Edition 45

50 Kapitel 4 Implementierung OSGi 12 -Umgebungen, Google App Engine und Google Web Toolkit. In ANONdroid wird Restlet in Version 2.1 Snapshot (unstable) eingesetzt. Webservice und Webserver sind grundlegend in der Klasse WebServerApplication implementiert. Diese Klasse erweitert die Klasse org.restlet.application des Restlet-Frameworks. Dabei wird die Methode createinboundroot() überschrieben. In ihr wird die Web- API in Form von Pfaden zu Ressourcen festgelegt. Die Funktionen des Webservice sind in drei unterschiedliche Kategorien eingeteilt: 1. Funktionen, die Status- und Anwendungsinformationen liefern und den Zustand der Anwendung nicht verändern 2. Funktionen, die die Anwendung steuern und somit deren Zustand verändern können 3. Funktionen, die den Zustand der Weboberfläche speichern oder zurückgeben und von der Anonymisierungs-Funktionalität abzugrenzen sind Mit dieser Einteilung ergeben sich drei unterschiedliche URL-Pfade: Der Platzhalter {name} steht für den Namen der Information, die abgerufen werden soll. So liefert der Webservice bei dem Informationsnamen services alle verfügbaren Anonymisierungsdienste vom JonDoController. Der Platzhalter {command} steht für einen Steuerbefehl. Beispielsweise veranlasst der Befehlsname disconnect bei der zweiten URL das Trennen der Verbindung zu einem Anonymisierungsdienst. Eine vollständige API- Referenz befindet sich im Anhang A. Der Webservice wird aus Sicherheitsgründen nur an den lokalen Host (localhost bzw ) gebunden und muss unabhängig davon nicht von außerhalb zugänglich sein. Der TCP-Port darf noch nicht belegt sein. Zudem sollte sich der Port leicht merken lassen, falls etwa zu Debugging-Zwecken manuell auf den Webservice zugegriffen werden muss. Ports bis einschließlich 1023 können nur mit administrativen Rechten reserviert werden und kommen daher nicht in Frage. Als Alternative zum üblicherweise für 12 Abkürzung für Open Services Gateway initiative 46

51 4.3 Systemkomponenten und Implementierungsaspekte das HTTP-Protokoll genutzten Port 80 wird häufig der Port 8080 verwendet. Da dieser aufgrund seiner weiten Verbreitung schon von einer anderen Anwendung auf dem Mobilgerät reserviert sein könnte, empfiehlt sich z. B. der Port Dieser ist einprägsam und wird laut der Internet Assigned Numbers Authority 13 (IANA) von der Anwendung Xprint Server genutzt. Das ist nicht weiter problematisch, da die Ports 8102 bis 8114 laut IANA offiziell keiner Anwendung zugeordnet sind und daher als Ausweichlösung genutzt werden können, wenn die Ports 8100 und 8101 schon belegt sein sollten. ANONdroid versucht bei der Initialisierung, den Port 8100 für den Webservice zu reservieren. Wenn dieser schon belegt ist, wird der Port solange bis 8109 inkrementiert, bis ein freier Port gefunden wurde. Somit gibt es neben dem Port 8100 noch neun Ausweichmöglichkeiten. In dem sehr unwahrscheinlichen Fall, dass schon alle Ports belegt sind, wird eine Fehlermeldung ausgegeben. Die Funktionen des Webservice sind entsprechend der drei URL-Pfade in den Klassen InformationResource, ControlResource und WebUIResource implementiert. Diese drei Klassen erweitern die Klasse org.restlet.resource.serverresource und dienen als Schnittstelle zwischen HTTP-Anfragen und den dazugehörigen Antworten. Als Anfragemethode wird für alle Funktionen GET verwendet. Die Antwort wird im JSON-Format geliefert, da es wegen seiner einfachen Syntax im Vergleich zu XML insbesondere von Web-Browsern performanter verarbeitet werden kann [NPRI09]. Dadurch kann sogar der Energieverbrauch auf Smartphones signifikant reduziert werden [GT11]. Die Implementierung wäre ohne eine Sicherheitsmaßnahme anfällig für sogenannte Cross-Site-Request-Forgery-Angriffe. Dabei versucht ein Angreifer über eine präparierte Webseite oder , eine HTTP-Anfrage an den lokalen Webservice abzusetzen. Beispielsweise könnte ein Angreifer den folgenden HTML-Link in eine Webseite integrieren: <a href=" Ein unbedachter Anwender könnte sich von dem Linktext Wichtig täuschen lassen und ohne Überprüfung der Zieladresse auf den Link klicken. Unter den Annahmen, dass ANONdroid auf dem Mobilgerät des Anwenders ausgeführt wird, eine Verbindung zu einem Anonymisierungsdienst besteht und der Port des Webservice tatsäch (abgerufen am 29. Januar 2012) 47

52 Kapitel 4 Implementierung lich 8100 ist, würde die Verbindung zu dem Dienst getrennt werden. Auf diese Weise könnte ein Angreifer die Nutzung von ANONdroid beeinträchtigen und mit Hilfe der dadurch gewonnenen Informationen sogar die Anonymität des Anwenders aufheben. Um dies zu verhindern, werden vom Webservice nur authentifizierte Anfragen verarbeitet. Genauer gesagt wird bei der Initialisierung von ANONdroid eine 128 Bit lange Zufallszahl (im Folgenden als Authentication Token bezeichnet) generiert, welche den HTTP-Anfragen an den Webservice in Form eines Session-Cookies beigefügt werden muss. Das Cookie mit dem Authentication Token wird weder vom Webservice noch vom Webserver herausgegeben. Einzig und allein die Activity platziert das Cookie im WebView. Angriffe wie oben geschildert sind damit nicht mehr wirksam, weil die Wahrscheinlichkeit, dass ein Angreifer das Authentication Token errät, so gering ist, dass dieser Fall praktisch vernachlässigt werden kann. Der offizielle Tor-Client kann über eine lokale TCP-Verbindung gesteuert werden. Dabei kommt ein ähnliches Authentifikationsverfahren 14 zum Einsatz. Eine steuernde Client-Software wie z. B. die grafische Benutzungsoberfläche Vidalia 15 übermittelt zur Authentifizierung je nach Konfiguration entweder ein sogenanntes Magic Cookie, welches sich im Datenverzeichnis der Tor-Installation befindet, oder aber den Hash- Wert eines zuvor festgelegten Kennwortes an den Tor-Client. Im Folgenden werden die Implementierung und der Aufruf einer konkreten Funktion des Webservice dargestellt. Das Listing 4.2 zeigt einen Auszug aus der Klasse InformationResource. InformationResource.java 1 package anondroid.anondroid.resources; 2 [...] 3 public class InformationResource extends ServerResource { 4 [...] 5 private static final String CMD_ACCOUNT_INFORMATION = "account_information"; 6 private static final String PARAM_ACCOUNT_NUMBER = "accountnumber"; 7 [...] 9 public void doinit() { 10 m_strrequestedresource = (String) getrequestattributes().get("name"); 11 } 14 (abgerufen am 15. Februar 2012) 15 (abgerufen am 15. Februar 2012) 48

53 4.3 Systemkomponenten und Implementierungsaspekte public String represent() { 15 Form queryparams = getquery(); 16 String requestparam; // authenticate request 19 String receivedauthtoken = getrequest().getcookies().getfirstvalue( 20 Constants.AUTH_TOKEN_PARAM, ""); 21 if (!receivedauthtoken.equals(anondroidservice.getauthtoken())) { 22 setstatus(status.client_error_unauthorized); 23 LogHolder.log(LogLevel.EMERG, LogType.NET, 24 Constants.LOG_MSG_UNAUTHORIZED); 25 return ResponseMessages.MSG_UNAUTHORIZED; 26 } // handle command and deliver requested information if available 29 if (m_strrequestedresource.equals(cmd_services)) { 30 requestparam = queryparams.getfirstvalue(param_service_filter); 31 if (requestparam!= null) { 32 return generateservices(requestparam); 33 } else { 34 setstatus(status.client_error_bad_request); 35 return ResponseMessages.MSG_BAD_REQUEST; 36 } 37 [...] 38 } else if (m_strrequestedresource.equals(cmd_account_information)) { 39 requestparam = queryparams.getfirstvalue(param_account_number); 40 if (requestparam!= null) { 41 return generateaccountinformation(requestparam); 42 } else { 43 setstatus(status.client_error_bad_request); 44 return ResponseMessages.MSG_BAD_REQUEST; 45 } 46 } else { 47 setstatus(status.client_error_not_found); 48 return ResponseMessages.MSG_NOT_FOUND; 49 } 50 } private String generateaccountinformation(string accountnumber) { 49

54 Kapitel 4 Implementierung 53 JSONObject result = new JSONObject(); try { 56 JonDonymAccount account = ResourceHelper. 57 getjondonymaccountfromaccountnumber(accountnumber); 58 if (account!= null) { 59 result.put("expireson", Util.formatTimestamp(account.expiresOn(), 60 false)); 61 result.put("hasexpired", account.hasexpired()); 62 result.put("currentvolume", Util.formatBytesValueWithUnit( 63 account.getcurrentvolume())); 64 result.put("monthlyvolume", Util.formatBytesValueWithUnit( 65 account.getmonthlyvolume())); 66 result.put("isactive", account.isactive()); 67 result.put("isblocked", account.isblocked()); 68 } 69 } catch (JSONException a_e) { 70 ResourceExceptionHandler.handleJSONException(getRequest().toString(), 71 a_e); 72 } return result.tostring(); 75 } 76 [...] 77 } Listing 4.2: Auszug aus der Klasse InformationResource Die Befehls- und Parameternamen der für den betrachteten URL-Pfad gültigen HTTP- Anfragen werden als String-Konstanten definiert. Die Funktion hinter der Konstante CMD_ACCOUNT_INFORMATION liefert Informationen über ein Konto. Als Parameter wird einer GET-Anfrage eine Kontonummer übergeben, deren Parametername durch PARAM_ACCOUNT_NUMBER festgelegt ist. Die Methode represent() verarbeitet GET-Anfragen. Zur Veranschaulichung des Funktionsprinzips soll die folgende GET- Anfrage Informationen zu einem fiktiven Konto mit der Nummer vom Webservice abrufen: GET /information/account_information?accountnumber= HTTP/1.1 Host: localhost 50

55 4.3 Systemkomponenten und Implementierungsaspekte Cookie: authtoken=519e63d2e2d58ea0fa646c4ba33757ef Zunächst wird das übermittelte Authentication Token mit dem intern gespeicherten Token verglichen. Nur wenn beide Werte übereinstimmen, wird die Verarbeitung der Anfrage fortgesetzt. Andernfalls werden eine Fehlermeldung und der HTTP-Statuscode 401 (Unauthorized) zurückgegeben. Im nächsten Schritt wird der Funktionsaufruf an den Webservice einer internen Java-Methode zugeordnet. Wird die aufgerufene Funktion nicht unterstützt, so werden eine Fehlermeldung und der HTTP-Statuscode 404 (Not Found) zurückgegeben. Andernfalls werden die für die jeweilige Funktion notwendigen Parameter aus der Anfrage extrahiert. Fehlen obligatorische Parameter, so wird die Anfrage mit einer Fehlermeldung und dem HTTP-Statuscode 400 (Bad Request) beantwortet. Die Antwort zu der oben genannten Anfrage wird von der Methode generateaccountinformation() erzeugt. Diese bezieht über die Hilfsmethode ResourceHelper.getJonDonymAccountFromAccountNumber() das jeweilige Konto-Objekt direkt vom JonDoController. Die Informationen des Kontos werden einem JSON-Objekt hinzugefügt, welches anschließend in Form einer String-Repräsentation als Antwort an den anfragenden Client zurückgeliefert wird. Diese Antwort im JSON-Format könnte beispielhaft wie folgt aussehen, wobei die tatsächliche Ausgabe des Webservice auf Zeilenumbrüche und Leerzeichen zu Formatierungszwecken verzichtet: { } "expireson" : " ", "hasexpired" : false, "currentvolume": "146,1 MByte", "monthlyvolume": "0 Byte", "isactive" : true, "isblocked" : false Webserver Der Webserver dient grundsätzlich zur Auslieferung von statischen Dateien, welche die Grundlage für die Weboberfläche darstellen. Diese Dateien sind Bestandteil der App. Android bietet für diesen Zweck ein Konzept namens Assets an. Dabei können beliebi- 51

56 Kapitel 4 Implementierung ge Binärdateien, die sich in dem Verzeichnis /assets/ des ANONdroid-Projektes befinden, über eine Dateisystemstruktur aus der Anwendung heraus gelesen werden. Der Webserver wird ähnlich wie der Webservice mit dem Restlet-Framework realisiert. Dazu wird in der Klasse WebServerApplication ein Objekt der Klasse org.restlet.restlet an das Wurzelverzeichnis des HTTP-Servers gebunden. Dieses verarbeitet HTTP-Anfragen, die sonst keinem der in Abschnitt genannten URL-Pfade des Webservice zugeordnet werden können. Die Anfragen müssen im Gegensatz zum Webservice nicht authentifiziert sein, d. h., dass das Authentication Token nicht übermittelt werden muss. Alle HTTP-Anfragen werden auf die Verzeichnisstruktur innerhalb des Verzeichnisses /assets/webui/ des ANONdroid-Projektes abgebildet. Bei Anfragen an die Basis-URL wird die Datei /assets/webui/index.htm zurückgegeben. Anfrageparameter werden ignoriert. Existiert eine angeforderte Ressource nicht, so wird die Anfrage inhaltslos und mit dem HTTP-Statuscode 404 (Not Found) beantwortet. Die Tabelle 4.2 veranschaulicht die Funktionsweise des Webservers. URL der Anfrage zurückgelieferte Datei /assets/webui/index.htm /assets/webui/index.htm /assets/webui/dir/img.gif keine, Fehler 404 (Not Found) Tabelle 4.2: Beispiele zur Abbildung von Anfrage-URLs auf statische Dateien durch den Webserver Die Internationalisierung, welche in Abschnitt betrachtet wird, muss auch vom Webserver berücksichtigt werden. Alle Dateien, die von der Internationalisierung betroffen sind, werden vor ihrer Auslieferung inhaltlich angepasst. Danach werden alle Vorkommen der Zeichenkette %%http_port=%% durch den aktuellen HTTP-Port ersetzt. Dies ist notwendig, damit die Weboberfläche in bestimmten Konstellationen überhaupt mit dem Webserver und dem Webservice kommunizieren kann. Außerdem werden den Antworten Cache-Direktiven hinzugefügt, die das clientseitige Caching unterbinden sollen. Dies ist notwendig, weil sich die Inhalte von internationalisierten Dateien aus der Sicht des Clients je nach eingestellter Sprache unterscheiden können. 52

57 4.3 Systemkomponenten und Implementierungsaspekte Activity Die in der Klasse ANONdroid implementierte Activity stellt den Eintrittspunkt der App dar. Wenn die Activity aufgerufen wird, sendet diese mit der Methode startservice() einen sogenannten Intent an den in der Klasse AnondroidService implementierten Service, um diesen zu starten. Der Intent enthält ein Objekt der Klasse android.os.resultreceiver, welches als eine Art Callback-Funktion betrachtet werden kann. Der Service informiert die Activity mit Hilfe des ResultReceivers über das Ergebnis der Startanfrage. Solange dieser Rückruf noch nicht stattgefunden hat, wird ein Ladebildschirm angezeigt, um dem Nutzer zu signalisieren, dass die App noch nicht einsatzbereit ist (siehe Abbildung 4.6). Der darin enthaltene Hinweistext wird in der eingestellten Sprache angezeigt. Der Ladebildschirm besteht je Sprache aus einer HTML-Datei und zwei Grafikdateien, welche sich im Verzeichnis /assets/loadingpage/ des ANONdroid-Projektes befinden. Der WebView lädt die Webseite direkt aus diesem Ordner, ohne dabei auf den lokalen Webserver angewiesen zu sein. Die animierte Aktivitätsanzeige stammt von (abgerufen am 9. Februar 2012) und ist frei verfügbar. Wenn der JonDoController und der Webservice bzw. Webserver einsatzbereit sind, sendet der Service einen Rückruf an die Activity mit dem gewählten HTTP-Port und dem Authentication Token. Dies geschieht unabhängig davon, ob der Service zum Zeitpunkt der Startanfrage bereits ausgeführt wurde oder erst gestartet werden musste. Daraufhin platziert die Activity das Authentication Token in Form eines Session-Cookies im WebView und lädt in diesem die Basis-URL um die Weboberfläche darzustellen. Konnten die Komponenten des Service hingegen nicht erfolgreich gestartet werden, so wird im WebView eine aussagekräftige Fehlermeldung in der eingestellten Sprache angezeigt. Weiterhin stellt die Activity ein Optionsmenü bereit (siehe Abbildung 4.7). Der Nutzer kann darüber einen Info-Dialog öffnen, eine Webseite mit Hilfe-Informationen aufrufen oder ANONdroid beenden. Zwar sind diese Funktionen prinzipiell auch über die Weboberfläche verfügbar, jedoch wird diese beispielsweise nicht dargestellt, solange der Service seinen Startvorgang noch nicht abgeschlossen hat. Außerdem ist anzunehmen, dass Android-Anwender ein Optionsmenü erwarten. Wenn ein Nutzer die Zurück-Taste des Mobilgerätes drückt, wird die Activity beendet und der Hintergrunddienst weiter ausgeführt. Drückt der Nutzer jedoch die Menü-Taste oder tritt eine Activity einer anderen App in den Vordergrund, so wird 53

58 Kapitel 4 Implementierung Abbildung 4.6: Ladebildschirm in Deutsch und Englisch die Activity von ANONdroid in der Regel lediglich pausiert. Um dabei Rechenleistung und somit auch Energie zu sparen, werden in ANONdroid bestimmte Aktivitäten des WebViews wie z. B. JavaScript-Timer angehalten, solange die Activity ohnehin nicht sichtbar ist. Dazu werden die WebView-Methoden pausetimers() und resumetimers() innerhalb der Activity-Methoden onpause() bzw. onresume() aufgerufen. Falls der Hintergrunddienst nicht mehr ausgeführt wird, weil er beispielsweise abgestürzt ist oder aufgrund von Speichermangel beendet wurde, erscheint eine Fehlermeldung, die den Nutzer darüber in Kenntnis setzt (siehe Abbildung 4.8). Nach Bestätigung der Fehlermeldung wird die Activity beendet Weboberfläche Die Weboberfläche basiert auf den Webtechnologien HTML, CSS und JavaScript. Da eine vollständige Eigenentwicklung der Weboberfläche sehr aufwendig gewesen wäre, 54

59 4.3 Systemkomponenten und Implementierungsaspekte Abbildung 4.7: Optionsmenü und Info-Dialog wird das freie Web-Framework jquery Mobile eingesetzt. Damit lässt sich auf einfache Weise eine für die Touch-Bedienung mobiler Geräte optimierte Weboberfläche gestalten. Neben jquery Mobile existieren noch weitere Web-Frameworks wie z. B. jqtouch und Sencha Touch, jedoch unterstützt jquery Mobile vergleichsweise besonders viele Mobilplattformen und -browser 16, was eine Portierung gemäß der Anforderung F20 begünstigt. Außerdem wurde während der Entwicklung von ANONdroid auch die erste stabile Version des Frameworks veröffentlicht. Es basiert auf dem ebenfalls freien JavaScript-Framework jquery, welches komfortable Funktionen zur DOM 17 -Navigation und -Manipulation sowie Ajax 18 -Funktionalitäten zur Verfügung stellt. In ANONdroid werden jquery Mobile in Version und jquery in Version eingesetzt (abgerufen am 8. Februar 2012) 17 Abkürzung für Document Object Model 18 Abkürzung für Asynchronous JavaScript and XML 55

60 Kapitel 4 Implementierung Abbildung 4.8: Fehlermeldung bei Nichtverfügbarkeit des Hintergrunddienstes Die HTML-Datei index.htm im Verzeichnis /assets/webui/ enthält das Grundgerüst der Weboberfläche. Im Verzeichnis /assets/webui/jquery/ befindet sich die JavaScript-Datei von jquery. Im Verzeichnis /assets/webui/jquerymobile/ befinden sich die Dateien von jquery Mobile. Abgesehen davon befindet sich der komplette JavaScript-Code der Weboberfläche in der Datei script.js. Die Datei style.css enthält CSS-Formatierungsregeln. Auf diese Weise wird eine strikte Trennung zwischen Inhalt (HTML), Formatierung (CSS) und Verhalten (JavaScript) der Weboberfläche erwirkt. Grafikdateien befinden sich in den Verzeichnissen /assets/webui/ und /assets/webui/flags/. Die Abbildungen 4.9 bis 4.16 zeigen die gesamte Weboberfläche. Diese ist in die vier untereinander angeordneten Bereiche Dienste, Aktueller Dienst, Bezahlung und Einstellungen eingeteilt. Ein Bereich wird mit Hilfe von jquery Mobile durch einen sogenannten Collapsible Content Block realisiert. Dabei handelt es sich um ein Container-Element, welches durch einen Klick auf dessen Kopfbereich auf- bzw. zugeklappt werden kann. 56

61 4.3 Systemkomponenten und Implementierungsaspekte Dadurch kann der Nutzer vorerst nicht benötigte Bereiche ausblenden und somit die Übersichtlichkeit erhöhen. Jedes Steuerelement der Weboberfläche ist durch vertikales Scrollen erreichbar. Der Bereich Dienste ermöglicht vordergründig das Auswählen eines Anonymisierungsdienstes sowie das Herstellen und Trennen einer anonymen Verbindung (siehe Abbildung 4.9). Außerdem können die verfügbaren Anonymisierungsdienste über eine Auswahlliste gefiltert werden. Es können somit entweder alle Dienste, nur kostenfreie Dienste oder nur Premiumdienste zur Auswahl angezeigt werden. Da die Anzahl der verfügbaren Anonymisierungsdienste im Zeitraum der Entwicklung von ANONdroid stets überschaubar war, wurde auf eine detailliertere Filtermöglichkeit verzichtet. Rechts neben der Auswahlliste für den Anonymisierungsdienst befindet sich eine Schaltfläche zur Aktualisierung der Informationen über alle Anonymisierungsdienste vom InfoService. Während diese Aktualisierung ausgeführt wird, erscheint anstelle der Schaltfläche eine animierte Grafik als Aktivitätsanzeige. Das Herstellen und Trennen einer Verbindung wird mit dem jquery-mobile-steuerelement Flip Toggle Switch realisiert. Der Verbindungszustand wird dabei entweder durch einen Klick oder durch Ziehen des Balkens in die gewünschte Position verändert. Während des Verbindungsaufbaus wird rechts neben dem Verbindungsschalter eine Aktivitätsanzeige dargestellt (siehe Abbildung 4.10). Die beiden Auswahllisten für Filter und Anonymisierungsdienst sind nur bedienbar, wenn keine anonyme Verbindung besteht. Weiterhin wird das noch verfügbare Restvolumen der Bezahlkonten angezeigt. Die Abbildung 4.11 zeigt den Bereich Aktueller Dienst, in welchem Informationen zum ausgewählten Anonymisierungsdienst dargestellt werden. Der Nutzer erfährt im ersten Schritt den Diensttyp, die Nutzerzahl, die Landesflaggen der Mix-Betreiber, Angaben zur Dienstgüte, die End-IP-Adresse, das Land, in welchem sich der letzte Mix befindet, sowie die Anzahl der übertragenen Daten seit dem letzten Verbindungsaufbau. Darüber hinaus werden innerhalb eines weiteren Collapsible Content Blocks detaillierte Informationen zu den einzelnen Mixen und deren Betreibern angezeigt. Die Links für , Website und Kartenansicht sind prinzipiell plattformunabhängig. Android erkennt jedoch assoziierte Anwendungen und bietet dem Nutzer beispielsweise an, die Kartenansicht mit der App Google Maps zu öffnen, sofern diese auf dem Mobilgerät installiert ist. Um Website-Links außerhalb des WebViews zu laden, müssen sie auf das Suffix /?operator_site enden. Die Zeichenkette wird später beim Öffnen eines Links 57

62 Kapitel 4 Implementierung Abbildung 4.9: Bereich Dienste der Weboberfläche von der Activity entfernt. Über das Kontrollkästchen Dienst sperren lässt sich ein zuvor ausgewählter Anonymisierungsdienst von einer Nutzung ausschließen (siehe Abbildung 4.12). Dem Nutzer ist es daraufhin nicht mehr möglich, über den Verbindungsschalter eine Verbindung mit dem gesperrten Dienst herzustellen. Eine bereits bestehende Verbindung wird im Zuge des Sperrens getrennt. Im Bereich Dienste wird ein gesperrter Dienst gekennzeichnet und am Ende der Auswahlliste der Anonymisierungsdienste gesondert aufgeführt. Die Abbildung 4.13 zeigt den Bereich Bezahlung. In der oberen Auswahlliste werden die Kontonummern aller verfügbaren Konten aufgelistet. Das ausgewählte Konto ist auch gleichzeitig das aktive Konto, welches für Premiumdienste genutzt wird. Unterhalb der Auswahlliste werden das Ablaufdatum sowie das aktuelle und das monatliche Volumen des Kontos angezeigt. Bei einem abgelaufenen Konto wird das Ablauf- 58

63 4.3 Systemkomponenten und Implementierungsaspekte Abbildung 4.10: Herstellen einer Verbindung mit einem Dienst datum in roter Schriftfarbe und mit einem Hinweistext gekennzeichnet. Die Schaltfläche Update aktualisiert die Kontoinformationen des ausgewählten Kontos von einer Bezahlinstanz. Die Schaltfläche Löschen entfernt das ausgewählte Konto unwiderruflich aus ANONdroid. Um einem versehentlichen Löschen vorzubeugen, muss die Schaltfläche zweimal hintereinander gedrückt werden. Nach dem ersten Drücken wird die Beschriftung der Schaltfläche in Rot und mit einem abschließenden Fragezeichen dargestellt. Wird nun die Schaltfläche innerhalb von drei Sekunden erneut gedrückt, so wird das Konto gelöscht. Andernfalls wird die Beschriftung der Schaltfläche wieder in den Ausgangszustand versetzt und das Konto ist nach wie vor in ANONdroid verfügbar. In ANONdroid verfügbare Konten können auch exportiert werden. Dazu wird eine Datei mit einem vom Nutzer festgelegten Namen im Download-Ordner des externen Speichers des Mobilgerätes erstellt (siehe Abbildung 4.14). Der Nutzer kann optional 59

64 Kapitel 4 Implementierung Abbildung 4.11: Bereich Aktueller Dienst der Weboberfläche ein Kennwort angeben, mit welchem die Datei verschlüsselt wird. Für den Export der Konten wird die jeweilige Methode des JonDoControllers verwendet, sodass die erstellte Datei auch vom JAP bzw. von dessen Kommandozeilen-Variante JonDoConsole importiert werden kann. Konten können sowohl über Gutscheincodes als auch über Kontodateien hinzugefügt werden. Die Abbildung 4.15 zeigt die Eingabemaske für den Konto-Import. Der Nutzer drückt auf die Durchsuchen... -Schaltfläche und wählt danach mit Hilfe des Dateiauswahl-Dialogs die zu importierende Kontodatei aus. Alternativ kann der absolute Pfad der Kontodatei auch manuell in das Eingabefeld eingetragen werden. Ein Kennwort kann ebenfalls angegeben werden. Die Abbildung 4.16 zeigt den Bereich Einstellungen in deutscher und englischer Sprache. Über eine Auswahlliste kann die Sprache der gesamten Benutzungsoberfläche von ANONdroid eingestellt werden. Über die beiden Kontrollkästchen können netzwerkspezifische Einstellungen vorgenommen werden. Unterhalb der Collapsible Con- 60

65 4.3 Systemkomponenten und Implementierungsaspekte Abbildung 4.12: Dienst sperren tent Blocks werden dieselben Funktionen des Optionsmenüs der Activity durch Schaltflächen zur Verfügung gestellt. Die in der Weboberfläche verwendeten Icons stammen von der Icon-Suchmaschine IconFinder 19,20,21,22 und stehen unter Open-Source- Lizenzen. Die Aktivitätsanzeige stammt von (abgerufen am 9. Februar 2012). Die Weboberfläche passt sich durch die Verwendung von jquery Mobile an unterschiedliche Bildschirmauflösungen und an die zurzeit eingestellte Bildschirmorientie (abgerufen am 9. Februar 2012) 20 (abgerufen am 9. Februar 2012) 21 (abgerufen am 9. Februar 2012) 22 (abgerufen am 9. Februar 2012) 61

66 Kapitel 4 Implementierung Abbildung 4.13: Bereich Bezahlung der Weboberfläche rung des Mobilgerätes an. Die Abbildung 4.17 zeigt die Weboberfläche im Querformat. Die Abbildung 4.18 zeigt die Weboberfläche im Hochformat auf dem Samsung Galaxy Tab Das Tablet besitzt eine Auflösung von Pixel. Die Weboberfläche ist weitestgehend zustandslos. Das bedeutet, dass die Eigenschaften der Steuerelemente im Service-Prozess gespeichert werden und zu jedem Zeitpunkt von diesem über den Webservice abrufbar sind. Jede Veränderung einer Eigenschaft eines Steuerelementes wird unmittelbar an den Webservice gesendet. Die Weboberfläche nutzt die Ajax-Technologie zur Kommunikation mit dem Webservice, d. h. es werden via JavaScript HTTP-Anfragen an den Webservice abgesetzt, ohne dass im Web- View andere HTML-Seiten aufgerufen werden. Um Zustandsänderungen des Service- Prozesses verarbeiten zu können, ruft die Weboberfläche in einem festgelegten Intervall von fünf Sekunden bestimmte Zustandsinformationen vom Webservice ab (sogenanntes Polling). Zwar gibt es mittlerweile einige Webtechnologien, die bidirektionale 62

67 4.3 Systemkomponenten und Implementierungsaspekte Abbildung 4.14: Konten exportieren, Gutschein aktivieren Kommunikationskanäle zwischen Client und Server innerhalb einer Webanwendung ermöglichen, jedoch erfordern diese zusätzliche Softwarekomponenten. Um eine Portierung von ANONdroid auf andere Plattformen zu erleichtern, wurde auf den Einsatz einer derartigen Technologie verzichtet. Außerdem findet das Polling nur lokal statt, sodass der dadurch entstehende Overhead vernachlässigt werden kann. Im Folgenden soll die Client-Server-Kommunikation der Weboberfläche mit dem Webservice anhand eines Beispiels demonstriert werden. Möchte ein Nutzer einen Gutschein aktivieren, so trägt er den Gutscheincode in das entsprechende Eingabefeld ein und drückt die Schaltfläche Gutschein aktivieren. Letzteres ruft die JavaScript- Funktion activatecoupon() auf. Diese setzt eine Ajax-Anfrage mit dem Gutscheincode als Parameter an die Ressource /control/activate_coupon des lokalen Webservice ab. Der Service-Prozess überprüft den erhaltenen Gutscheincode und erstellt zunächst ein neues Konto. Das Ergebnis dieser Operationen wird der Weboberfläche als Antwort 63

68 Kapitel 4 Implementierung Abbildung 4.15: Konten importieren mit Dateiauswahl-Dialog der Ajax-Anfrage übermittelt. Außerdem enthält die Antwort noch eine Ticket-ID, welche dem im Hintergrund begonnenen Aufladevorgang zugeordnet ist. Der Aufladevorgang kann einige Sekunden dauern und wird deshalb nicht innerhalb der synchronen Ajax-Anfrage ausgeführt, da ansonsten die Weboberfläche in diesem Zeitraum blockiert wäre. Stattdessen ruft die JavaScript-Funktion pollchargestatus(ticketid) aller vier Sekunden den Status der Aufladung über die Ressource /control/charge_status vom Webservice ab, bis ein Ergebnis vorliegt. Abschließend wird der Nutzer über das Resultat der Aufladung informiert. Die Funktionalität der Weboberfläche hängt von den unterstützten Funktionen des JonDoControllers ab. Um gemäß der Anforderung F30 den Wartungsaufwand der mobilen Client-Software gering zu halten, wurde darauf verzichtet, weitere Funktionen wie beispielsweise Bezahlfunktionen oder die Nutzung von Anti-Zensur-Diensten anderer AN.ON-Anwender durch direkte Nutzung der AnonLib zu realisieren. 64

69 4.3 Systemkomponenten und Implementierungsaspekte Abbildung 4.16: Bereich Einstellungen der Weboberfläche in Deutsch und Englisch Internationalisierung Die Internationalisierung umfasst die Sprachanpassung der gesamten Benutzungsoberfläche von ANONdroid. Ähnlich wie beim JAP kann der Nutzer eine Sprache auswählen. Momentan werden die Sprachen Deutsch und Englisch vollständig unterstützt. Beim ersten Start von ANONdroid wird die Systemsprache ermittelt und für die Benutzungsoberfläche eingestellt, sofern sie zu den von ANONdroid unterstützten Sprachen gehört. Andernfalls wird Englisch verwendet. Die AnonLib beinhaltet mit der Klasse anon.util.japmessages bereits einen Mechanismus zur Sprachanpassung, der auch im JAP verwendet wird. Dabei werden Platzhalter auf übersetzte Zeichenketten abgebildet. Die Übersetzungen werden in Java-Properties-Dateien, sogenannten Resource Bundles, im Verzeichnis /resources/ gespeichert. Die Dateien heißen zurzeit messages_de.properties und messages_en.properties. Die letzten bei- 65

70 Kapitel 4 Implementierung Abbildung 4.17: Weboberfläche im Querformat den Buchstaben vor der Dateiendung entsprechen dem Sprachcode nach ISO der darin enthaltenen Sprache. Die folgende Zeile in der deutschen Sprachdatei bildet den Platzhalter dialog.error auf den Text Fehler ab: dialog.error=fehler Innerhalb der Anwendung kann über die Methode JAPMessages.getString() auf die Übersetzung zugegriffen werden: String translation = JAPMessages.getString("dialog.error"); Auf diese Weise wird die Sprachanpassung der nativen GUI-Elemente Optionsmenü und Status Bar Notification realisiert. Für die Sprachanpassung der Weboberfläche gestaltet sich die Umsetzung komplexer. Die Platzhalter werden an den entsprechenden Stellen in den HTML- und JavaScript-Dateien hinterlegt und müssen vom internen Webserver vor ihrer Auslieferung durch ihre jeweiligen Übersetzungen ausgetauscht 23 Abkürzung für International Organization for Standardization 66

71 4.3 Systemkomponenten und Implementierungsaspekte Abbildung 4.18: Weboberfläche auf dem Samsung Galaxy Tab

72 Kapitel 4 Implementierung werden. Für diesen Zweck eignen sich grundsätzlich sogenannte Template Engines wie z. B. Apache Velocity oder FreeMarker. Da es sich bei der Aufgabe jedoch lediglich um eine Textersetzung handelt, blieben die meisten der mitgelieferten Funktionen ungenutzt. Aus diesem Grund kommt eine schlanke Eigenentwicklung zum Einsatz. Der Beginn und das Ende eines Platzhalters müssen gekennzeichnet werden, da ansonsten unter Umständen unerwünschte Textersetzungen durchgeführt würden. Ein Platzhalter wird mit doppelten Prozentzeichen gefolgt von einem Gleichheitszeichen eingeleitet und mit doppelten Prozentzeichen ausgeleitet. Das folgende Beispiel demonstriert die Verwendung eines Platzhalters innerhalb eines HTML-Markups: <a href="javascript:showaboutmessage()">%%=webui.about%%</a> Doppelte Prozentzeichen haben weder in HTML noch in JavaScript eine besondere Bedeutung, sodass es zu keinerlei Wechselwirkungen kommen kann. Angesichts der Tatsache, dass sich Präfix und Suffix unterscheiden, kann es nicht vorkommen, dass der Suffix eines Platzhalters gleichzeitig auch als der Präfix eines anderen Platzhalters interpretiert wird. Die Textersetzung ist in der Klasse Localization implementiert. Das konstante String-Array SUPPORTED_LANGUAGES enthält die Sprachcodes der von ANONdroid unterstützten Sprachen gemäß ISO Sollen weitere Übersetzungen angelegt werden, müssen auch deren Sprachcodes darin aufgenommen werden. Die Textersetzung erfolgt mit Hilfe der Klassen Pattern und Matcher des Paketes java.util.regex. Dabei wird der folgende reguläre Ausdruck als Suchmuster für die Platzhalter verwendet: %%=((?!(%% \s)).)+%% Dieser stimmt mit Zeichenketten überein, die mit %%= beginnen, auf %% enden und dazwischen eine nicht leere Zeichenkette haben, die weder Leerzeichen noch doppelte Prozentzeichen enthält. Der Webserver entscheidet anhand der Dateiendung einer angeforderten Datei, ob deren Inhalt vor Auslieferung an den Client der Textersetzung unterzogen wird. Das konstante String-Array LOCALIZABLE_FILE_EXTS in der Klasse WebServerApplicati- 68

73 4.3 Systemkomponenten und Implementierungsaspekte on enthält die Dateiendungen, bei denen der Webserver die Textersetzung vornimmt 24. Außerdem enthält das konstante String-Array NO_LOCALIZATION_FOLDERS Namen von Verzeichnissen, die von der Textersetzung ausgeschlossen werden 25. Mit diesen Maßnahmen werden Dateien, die ohnehin nicht für eine Sprachanpassung vorgesehen sind, schneller vom Webserver verarbeitet. Soll eine weitere Sprache von ANONdroid unterstützt werden, so muss eine entsprechende Properties-Datei erstellt werden. Die Vorlage dafür bildet die Properties- Datei für Englisch, da diese für alle innerhalb der Weboberfläche vorkommenden Platzhalter Übersetzungen bereithalten muss und somit als vollständig betrachtet werden kann. In den anderen Properties-Dateien dürfen hingegen Übersetzungen fehlen. In einem solchen Fall würde ANONdroid auf die englische Übersetzung zurückgreifen. Die Einhaltung dieser Bedingungen kann mit dem Java-Programm LanguageValidator überprüft werden. Dem Programm werden beim Aufruf zwei Parameter übergeben. Zum einen das Verzeichnis mit den Properties-Dateien und zum anderen das Verzeichnis mit den Dateien der Weboberfläche. Der LanguageValidator ermittelt alle Platzhalter in den jeweiligen Dateien der Weboberfläche und überprüft zunächst, ob hierfür englische Übersetzungen vorliegen. Gibt es mindestens einen Platzhalter ohne englische Übersetzung, so wird eine Fehlermeldung mit dem Platzhalter ausgegeben (Rückgabewert: -1). Existieren hingegen für alle Platzhalter englische Übersetzungen, jedoch nicht alle Übersetzungen für die anderen vorhandenen Sprachen, so werden für die fehlenden Übersetzungen Warnungen ausgegeben (Rückgabewert: 1). Fehlen indes überhaupt keine Übersetzungen, so wird eine Erfolgsmeldung ausgegeben (Rückgabewert: 0). Das Programm wurde in den Maven-Build-Prozess von ANONdroid integriert und informiert den Entwickler über die Konsolenausgabe der jeweiligen IDE über fehlende Übersetzungen (siehe Abbildung 4.19). Fehlt eine englische Übersetzung, so wird der Build-Prozess abgebrochen. Damit wird sichergestellt, dass für jeden Platzhalter innerhalb der Weboberfläche zumindest eine Übersetzung in englischer Sprache angezeigt werden kann. Ein weiteres Merkmal der Internationalisierung von ANONdroid ist die Möglichkeit, den Platzhalter %%lang_code=%% an beliebiger Stelle in die Weboberfläche zu integrieren. Der Webserver ersetzt diese Zeichenkette durch den Sprachcode der eingestellten Sprache gemäß ISO Somit lassen sich beispielsweise externe Webseiten 24 zurzeit html, htm und js 25 zurzeit flags, jquery und jquerymobile 69

74 Kapitel 4 Implementierung Abbildung 4.19: Konsolenausgabe des Maven-Build-Prozesses in Eclipse in der Benutzungssprache aufrufen, wenn der Platzhalter der URL als Parameter übergeben wird und die Webseite diese Funktion unterstützt. Zurzeit wird der Sprachcode an die Hilfe-URL angehängt: <a href=" Der Webserver würde dieses HTML-Markup bei deutscher Benutzungssprache wie folgt ausliefern: <a href=" Des Weiteren unterliegen sowohl die Ländernamen als auch die Darstellung von Zahlen der Internationalisierung. Für diesen Zweck werden Klassen der AnonLib verwendet. 70

75 4.3 Systemkomponenten und Implementierungsaspekte Datenbankanbindung Informationen vom InfoService werden in einer Datenbank abgelegt. Die Android-API stellt eine Schnittstelle zum Zugriff auf SQLite-Datenbanken, bei denen sich die Datenbank in einer einzigen Datei befindet, bereit. Leider ist diese Schnittstelle nicht kompatibel mit der Datenbankschnittstelle des JonDoControllers. Das liegt vor allem daran, dass Android keinen JDBC 26 -Treiber für SQLite mitliefert. Mit dem Open-Source- Projekt SQLDroid 27 existiert zwar ein solcher JDBC-Treiber, jedoch war dieser aus technischen Gründen nicht mit dem JonDoController nutzbar. Deshalb wurden vom Lehrstuhl die beiden Klassen EDBConfigurationAndroid und EDBDatabaseAndroid entwickelt. EDBConfigurationAndroid implementiert das Interface IEDBConfiguration und wird dem JonDoController innerhalb der Klasse ControllerConfiguration zur Verfügung gestellt. EDBDatabaseAndroid implementiert das Interface IEDBDatabase und beinhaltet somit auch die Abbildung der Datenbankmethoden des InfoService auf die SQLite-API von Android Persistenz Die InfoService-Daten werden in einer SQLite-Datenbank unter dem folgenden Pfad auf dem Mobilgerät gespeichert: /data/data/anondroid.anondroid/files/caching.db Benutzereinstellungen sowie Konten werden mit Hilfe des Konzeptes der Shared Preferences der Android-API in Form von Schlüssel-Wert-Paaren in XML-Dateien unter den folgenden Pfaden auf dem Mobilgerät gespeichert: /data/data/anondroid.anondroid/shared_prefs/settings.xml /data/data/anondroid.anondroid/shared_prefs/accounts.xml Dabei ist /data/data/anondroid.anondroid/ das Datenverzeichnis von ANONdroid, auf welches alle anderen auf dem Mobilgerät installierten Apps keinen Zugriff haben. Die Konten werden momentan noch unverschlüsselt gespeichert. Wird das Mobilgerät ent- 26 Abkürzung für Java Database Connectivity 27 (abgerufen am 12. Februar 2012) 71

76 Kapitel 4 Implementierung wendet bzw. verschaffen sich Unbefugte Zugriff darauf, so können auch die gespeicherten Konten gestohlen werden. Hingegen haben böswillige Apps bedingt durch das Sicherheitskonzept von Android keine Möglichkeit, an die Konten zu gelangen. Dennoch sollte im Zuge der Weiterentwicklung von ANONdroid die Möglichkeit geschaffen werden, den Zugriff auf die gespeicherten Konten mit einem Kennwort zu schützen. Die Benutzereinstellungen werden beim Beenden von ANONdroid in die Datei settings.xml geschrieben. Stürzt ANONdroid unerwartet ab, so kann dieser Vorgang nicht mehr ausgeführt werden und die seit dem letzten Beenden der App vorgenommenen Einstellungen gehen verloren. Da dieser Umstand jedoch bei den Konten inakzeptabel wäre, werden neue Konten unmittelbar nach deren Hinzufügen in die Datei accounts.xml geschrieben, sodass sie durch Abstürze nicht verloren gehen können Verbindungswiederaufnahme Mobile Geräte unterliegen im Gegensatz zu Desktop-Rechnern häufigen Wechseln des Datennetzwerks. Angenommen, das Mobilgerät eines Nutzers ist an dessen Arbeitsstätte mit dem WLAN der Firma verbunden. Verlässt der Nutzer die Firma und ist außerhalb der Reichweite des WLANs, so könnte das Mobilgerät beispielsweise auf den Mobilfunkstandard UMTS 28 ausweichen. Kommt der Nutzer anschließend nach Hause, so verbindet sich das Mobilgerät z. B. mit dem privaten WLAN. Nach jedem Verbindungswechsel muss eine vorher bestehende Verbindung zu einem Anonymisierungsdienst wieder neu aufgebaut werden. ANONdroid bietet daher die Einstellung Automatisches Wiederverbinden nach Netzwerkwechsel an, welche standardmäßig aktiviert ist. Sie kann vom Nutzer deaktiviert werden, wenn damit Probleme wie z. B. unerwünschte Verbindungsabbrüche auftreten sollten. Der Service-Prozess registriert einen BroadcastReceiver, welcher Broadcasts vom Typ ConnectivityManager.CONNECTIVITY_ACTION empfängt. Damit kann der Service-Prozess in der Klasse AnondroidService auf Änderungen der Netzwerkkonnektivität des Mobilgerätes reagieren. Wird die Verbindung zu einem Datennetzwerk getrennt, so wird auch eine bestehende anonyme Verbindung am JonDoController beendet. Außerdem wird der Zeitpunkt dieses Ereignisses festgehalten. Wird innerhalb einer festgelegten Zeitspanne eine neue Netzwerkverbindung registriert, so wird versucht, eine Ver- 28 Abkürzung für Universal Mobile Telecommunications System 72

77 4.4 Installation und Nutzung bindung mit dem zuletzt gewählten Anonymisierungsdienst herzustellen. Andernfalls wird kein Verbindungsversuch unternommen. Die Zeitspanne wird durch die Konstante RECONNECT_WINDOW in Millisekunden festgelegt und liegt bei 60 Sekunden. Diese Vorgehensweise beruht auf der Annahme, dass eine Verbindungswiederaufnahme nur bei kurzen Unterbrechungen der Konnektivität sinnvoll ist. Der Verbindungsversuch des JonDoControllers wird verzögert ausgeführt. Die Verzögerung wird durch die Konstante RECONNECT_DELAY in Millisekunden festgelegt und liegt bei zwei Sekunden. Darüber hinaus werden mehrere Verbindungsversuche unternommen. Die maximale Anzahl der Versuche wird durch die Konstante MAX_RECONNECT_ATTEMPTS festgelegt und liegt bei drei. Der zeitliche Abstand zwischen den Versuchen wird durch die Konstante RECONNECT_INTERVAL in Millisekunden festgelegt und liegt bei zehn Sekunden. Die Werte wurden durch Versuche mit dem Smartphone Samsung Galaxy S II GT-I9100 ermittelt. 4.4 Installation und Nutzung ANONdroid kann über den Android Market 29 auf Android-Geräten installiert werden. Der Download der App ist lediglich 1,7 MB groß und deswegen auch für gängige Mobilfunkverbindungen geeignet. ANONdroid benötigt auf dem Mobilgerät die folgenden Zugriffsrechte: 1. Netzkommunikation uneingeschränkter Internetzugriff 2. Speicher Inhalt des USB-Speichers und der SD-Karte ändern/löschen 3. Netzkommunikation Netzwerkstatus anzeigen Das erste Zugriffsrecht wird vor allem dafür benötigt, dass ANONdroid als lokaler Proxy fungieren kann. Das zweite Zugriffsrecht ist Voraussetzung für die Persistenz sowie den Im- und Export von Konten. Das dritte Zugriffsrecht ermöglicht es der App, 29 (abgerufen am 13. Februar 2012) 73

78 Kapitel 4 Implementierung im Rahmen der Verbindungswiederaufnahme auf Änderungen der Netzwerkkonnektivität zu reagieren. Der lokale Proxy von ANONdroid lauscht auf dem Port Dieser muss in Verbindung mit dem Host localhost bzw. der Loopback-Adresse in die Proxy- Konfiguration der Apps eingetragen werden, deren Netzwerkkommunikation anonymisiert werden soll. Der bei Android mitgelieferte Web-Browser beinhaltet keine Möglichkeit zur Proxy-Konfiguration. Stattdessen müssen alternative Web-Browser wie z. B. Opera Mobile 30, Firefox Mobile 31 oder Orweb 32 genutzt werden. In Opera Mobile gelangt man über die Adresse opera:config auf die Konfigurationsseite des Browsers. Innerhalb der Kategorie Proxy müssen die Eigenschaften FTP server, HTTP server und HTTPS server zu :4001 bzw. localhost:4001 geändert werden. Außerdem müssen die Kontrollkästchen bei Use FTP, Use HTTP und Use HTTPS aktiviert werden. Die Sicherheit der Konfiguration kann mit Hilfe des Anonymitätstests 33 der JonDos GmbH überprüft werden. Die Proxy-Konfiguration allein reicht für eine sichere Nutzung des AN.ON-Dienstes nicht aus. Zusätzlich sollten noch Cookies, JavaScript und Plug-ins wie beispielsweise Adobe Flash deaktiviert werden (siehe Abbildung 4.20). Für Firefox Mobile existiert das Add-on Proxy Mobile 34 zur Proxy-Konfiguration. Analog zum Opera Mobile werden hier der Host und der Port von ANONdroid eingetragen. Da es noch kein mobiles Äquivalent zum Firefox-Profil JonDoFox gibt, müssen auch beim Firefox Mobile zusätzliche Browser-Einstellungen vorgenommen werden, um den AN.ON-Dienst sicher nutzen zu können. Orweb ist ein datenschutzfördernder Web-Browser, der im Rahmen des Projektes The Guardian Project entwickelt wird und vordergründig als Browser für den mobilen Tor-Client Orbot empfohlen wird. Orweb verfügt standardmäßig über sicherheitsrelevante Einstellungen, die bei den oben genannten Web-Browsern erst manuell vorgenommen werden müssen. Da ANONdroid genau wie auch Orbot einen HTTP- und 30 (abgerufen am 13. Februar 2012) 31 (abgerufen am 13. Februar 2012) 32 (abgerufen am 13. Februar 2012) 33 (abgerufen am 13. Februar 2012) 34 (abgerufen am 13. Februar 2012) 74

79 4.4 Installation und Nutzung Abbildung 4.20: Anonymitätstest ohne und mit sicherheitsrelevanten Einstellungen in Opera Mobile 75

80 Kapitel 4 Implementierung einen SOCKS-Proxy bereitstellt, kann die App auch mit Orweb genutzt werden (siehe Abbildung 4.21). Im Moment stellt diese Kombination die sicherste und komfortabelste Nutzung von ANONdroid dar, da in Orweb außer dem Host und dem Port keine zusätzlichen Einstellungen mehr vorgenommen werden müssen. Abbildung 4.21: Orweb mit ANONdroid 76

81 Kapitel 5 Evaluierung In diesem Kapitel wird ANONdroid qualitativ und quantitativ bewertet. Insbesondere wird eruiert, inwiefern ANONdroid den in Kapitel 2 ermittelten Anforderungen genügt. Grundlage für die Bewertung ist dabei die Norm ISO/IEC , die Qualitätsmerkmale für die Produktqualität von Software beschreibt. In diesem Zusammenhang werden auch Anwenderberichte ausgewertet. 5.1 Funktionalität (Functionality) Die Funktionen von ANONdroid wurden im Abschnitt 3.3 anhand konkreter Nutzfälle festgelegt. Es wurden auch Funktionen betrachtet, die sich für den Einsatz auf mobilen Geräten nicht eignen. Die Funktionalität von ANONdroid hängt von den unterstützten Funktionen des JonDoControllers ab. Wünschenswerte Funktionen wie beispielsweise Bezahlfunktionen oder die Nutzung von Anti-Zensur-Diensten wurden nicht implementiert, weil aus Gründen der Wartbarkeit darauf verzichtet wurde, die vom Jon- DoController nicht unterstützten Funktionen unter direkter Nutzung der AnonLib zu realisieren. Aus Sicht der Softwarearchitektur sollten diese noch fehlenden Funktionen im JonDoController ergänzt werden. Die Anonymisierungs-Funktionalität wird in ANONdroid durch den JonDoController bereitgestellt. Dies wirkt sich positiv auf die Sicherheit der Anwendung aus, da eine eigene Implementierung der Anonymisierungs-Funktionalität die Wahrscheinlichkeit von Fehlern und Sicherheitslücken erhöht hätte. Android basiert auf Linux und stellt damit eine offene und grundsätzlich sichere Ausführungsumgebung dar. Ein Sandbox-Mechanismus sorgt dafür, dass auf dem Mo- 1 Abkürzung für International Electrotechnical Commission 77

82 Kapitel 5 Evaluierung bilgerät installierte Apps voneinander isoliert gespeichert und ausgeführt werden. Dadurch können böswillige Apps weder ANONdroid selbst noch dessen Einstellungen manipulieren. Allerdings wird Android ähnlich wie die Desktop-Betriebssysteme zum vertrauenswürdigen Bereich gezählt. Eine böswillige App kann demzufolge an der Aufdeckung der Anonymität eines Nutzers mitwirken, ohne dabei ANONdroid manipulieren zu müssen. Eine Besonderheit von Android und mobilen Betriebssystemen im Allgemeinen stellen die weitreichenden Zugriffsmöglichkeiten vom Betriebssystemhersteller auf die Mobilgeräte dar. Google kann mit einer umgangssprachlich als Kill Switch bezeichneten Funktionalität Apps auf Android-Geräten entfernen und hat davon auch schon mehrfach im Zusammenhang mit Schadsoftware Gebrauch gemacht. Angreifer könnten diese Funktion missbräuchlich dafür nutzen, um Apps auf Geräten zu manipulieren. Jeder Nutzer muss sich darüber bewusst sein, dass zumindest technisch die Möglichkeit besteht, ANONdroid von außerhalb und ohne Zutun des Nutzers uneingeschränkt zu kompromittieren. 5.2 Zuverlässigkeit (Reliability) Um die Zuverlässigkeit der Anonymisierungs-Funktionalität von ANONdroid sicherzustellen, wurde ein Web-basierter Belastungstest entwickelt. Dieser besteht aus einer HTML- und einer JavaScript-Datei und wird über einen Web-Browser aufgerufen, der für die Verwendung mit ANONdroid konfiguriert wurde. Mit Hilfe von JavaScript werden nacheinander die vom Internetdienst Alexa 2 ermittelten 500 meistbesuchten Websites im WWW in einem separaten Browserfenster geöffnet. Hierfür muss der Pop-up- Blocker des jeweiligen Web-Browsers deaktiviert werden. Das Intervall zwischen den Website-Aufrufen ist konfigurierbar und beträgt standardmäßig 30 Sekunden. Damit sind nach ca. vier Stunden alle der 500 Websites aufgerufen worden. Wenn ANONdroid innerhalb dieses Zeitraums nicht abstürzt und man sich regelmäßig von dem korrekten Aufruf der Websites überzeugt, gilt ANONdroid hinsichtlich seiner Kernfunktionalität als zuverlässig. Die aktuelle Version von ANONdroid besteht den Belastungstest auf einem Samsung Galaxy S II GT-I (abgerufen am 14. Februar 2012) 78

83 5.3 Effizienz 5.3 Effizienz (Efficiency) Für die folgenden Untersuchungen wurde ANONdroid auf dem Smartphone Samsung Galaxy S II GT-I9100 (im Folgenden als Testgerät bezeichnet) unter Android ausgeführt. Das Gerät verfügt über einen Dual-Core-Prozessor mit 1,2 GHz Taktfrequenz, 1 GB Hauptspeicher und 16 GB internen Speicher. Die Bildschirmauflösung beträgt Pixel. Mit diesen Merkmalen gehört das Samsung Galaxy S II derzeit zu den leistungsfähigsten Smartphones auf dem Markt Verbrauchsverhalten ANONdroid besteht aus einer 1,7 MB großen APK-Datei, welche über den Android Market auf die Mobilgeräte der Nutzer geladen wird. Nach der Installation belegt die App 4,7 MB Gerätespeicher. ANONdroid unterstützt auch die mit Android 2.2 eingeführte Möglichkeit, in den externen Speicher (üblicherweise die SD-Karte des Mobilgerätes) installiert werden zu können. Die persistent gehaltenen Anwendungsdaten belegten auf dem Testgerät ca. 600 KB Gerätespeicher. Ohne die temporären Cache- Daten, welche bei jedem Start von ANONdroid gelöscht werden und während dessen Ausführung auf etwa 1,5 MB anwuchsen, belegte die App demnach ca. 5,3 MB Gerätespeicher. Dies ist verglichen mit anderen populären Apps zwar nicht wenig, aber auch nicht überdurchschnittlich viel 3. Um den Hauptspeicherbedarf von ANONdroid mit anderen Apps vergleichen zu können, wird die Größe Proportional Set Size (PSS) der beiden ANONdroid-Prozesse betrachtet. Bei der PSS wird die durch Bibliotheken genutzte Speichermenge gleichmäßig auf die nutzenden Prozesse aufgeteilt. Mit den folgenden beiden Befehlen lassen sich Informationen zur Speichernutzung des Activity- bzw. Service-Prozesses beziehen: $ adb shell dumpsys meminfo anondroid.anondroid $ adb shell dumpsys meminfo anondroid.anondroid:service Abhängig von der Aktivität der Benutzungsoberfläche beanspruchte der Activity- Prozess zwischen 35 und 85 MB PSS-Speicher und hatte somit im Vergleich zu den 3 Zum Vergleich: Die App Google Earth belegte auf dem Testgerät knapp 25 MB Gerätespeicher. Die App FOCUS hingegen belegte nur 1,6 MB. 79

84 Kapitel 5 Evaluierung anderen Prozessen auf dem Testgerät den höchsten Hauptspeicherbedarf. Der Service- Prozess hingegen beanspruchte lediglich knapp 20 MB PSS-Speicher, sofern keine Daten über eine anonyme Verbindung übertragen wurden. Bei hoher Aktivität stieg dessen Speicherbedarf auf bis zu ca. 30 MB an. ANONdroid hat folglich einen vergleichsweise sehr hohen Speicherbedarf. Die CPU 4 -Auslastung der beiden Prozesse wurde mit dem Unix-Programm top durch den folgenden Befehl ermittelt: $ adb shell top Während die CPU-Auslastung des Activity-Prozesses selbst bei hoher Aktivität der Benutzungsoberfläche nie Werte über 20 % erreichte, wurden beim rechenintensiven Service-Prozess langanhaltende CPU-Auslastungen von bis zu 70 % festgestellt. Verglichen mit anderen Apps fordert ANONdroid dem Prozessor des Mobilgerätes eine sehr hohe Rechenleistung ab. Das Testgerät verfügt über eine Akkukapazität von mah. Um den Energiebedarf des Mobilgerätes bei der Nutzung von ANONdroid einordnen zu können, wurde die Akkulaufzeit in verschiedenen Konstellationen gemessen. Vor jeder Messung wurde der Akku vollständig aufgeladen und das Gerät neu gestartet, um damit die Messungen durch möglichst identische Ausgangszustände vergleichbar zu machen. Danach wurde das Testgerät in den jeweils zu testenden Zustand überführt und die Zeit gemessen, bis der Akku 50 % seines anfänglichen Ladezustandes erreicht hatte. Die Tabelle 5.1 zeigt die unterschiedlichen Konstellationen und die dazugehörigen Messwerte. Nr. ANONdroid ausgeführt ANONdroid verbunden Belastungstest ausgeführt Dauer bis 50 % Ladezustand 1 nein nein nein 39,07 Std. 2 nein nein ja 2,31 Std. 3 ja nein nein 39,84 Std. 4 ja ja nein 37,23 Std. 5 ja ja ja 1,74 Std. Tabelle 5.1: Akkulaufzeiten des Testgerätes in verschiedenen Konstellationen 4 Abkürzung für Central Processing Unit 80

85 5.3 Effizienz Die erste Konstellation repräsentiert den Bereitschaftsmodus des Testgerätes, da hierbei weder ANONdroid noch der Belastungstest aus Abschnitt 5.2 ausgeführt werden. In der dritten Konstellation wird ANONdroid ausgeführt, ohne dass eine anonyme Verbindung besteht. Der Energiebedarf ist in dieser Konstellation nur unwesentlich geringer, sodass davon auszugehen ist, dass ANONdroid keinen signifikanten Einfluss auf den Energiebedarf eines Mobilgerätes hat, solange keine anonyme Verbindung besteht. Die Messung der vierten Konstellation deutet darauf hin, dass ANONdroid mit einer anonymen Verbindung, über die keine Daten ausgetauscht werden, den Energiebedarf leicht erhöht. Noch eindeutiger ist das Ergebnis beim Belastungstest. Die Energiebedarfe fallen dabei deutlich höher aus. Wird der Belastungstest noch dazu unter Nutzung des lokalen Proxys von ANONdroid ausgeführt, steigt der Energiebedarf sichtlich. Die gemessene Akkulaufzeit verringerte sich um ca. 25 % Zeitverhalten Der Start von ANONdroid dauerte auf dem Testgerät bei zehn Versuchen im Durchschnitt 15,2 Sekunden. Lediglich der erste Start nach der Installation der App ging mit ca. 4 Sekunden deutlich schneller. Die lange Wartezeit rührt daher, weil der JonDoController im Zuge der Initialisierung die Signaturen der in der Datenbank gespeicherten Dienste überprüft. Die dafür notwendigen kryptografischen Operationen werden unter Einsatz der Java-Bibliothek BouncyCastleLightForAN.ON innerhalb der Dalvik-VM ausgeführt. Da diese Operationen allerdings sehr rechenintensiv sind, bietet es sich an, sie unter Zuhilfenahme des sogenannten Android NDKs 5 und der kryptografischen Bibliothek OpenSSL zu implementieren. Damit würden die Operationen statt in einer virtuellen Maschine direkt auf der Hardware des Mobilgerätes ausgeführt werden, wodurch sich die anfängliche Wartezeit deutlich reduzieren ließe. War die Benutzungsoberfläche erst einmal geladen, traten in der Bedienung von ANONdroid keine auffälligen Wartezeiten mehr auf. Ein Beenden und erneutes Laden der Activity dauerte bei zehn Versuchen im Durchschnitt 2,4 Sekunden. 5 Abkürzung für Native Development Kit 81

86 Kapitel 5 Evaluierung Vergleich zum JAP Um sicherzustellen, dass der von ANONdroid bereitgestellte lokale Proxy durch die eingeschränkt zur Verfügung stehenden Systemressourcen mobiler Geräte nicht den Flaschenhals bei der Nutzung des Anonymisierungsdienstes darstellt, wird dessen Leistungsfähigkeit vor allem mit der des JAP verglichen. Zu diesem Zweck wurde über verschiedene Konfigurationen eine 10 MB große Datei von einer speziellen Testseite 6 des Netzbetreibers QSC AG 7 heruntergeladen und die dafür benötigte Zeit gemessen. Die Testseite verfügt über eine performante Internetanbindung und stellte angesichts dessen innerhalb der getesteten Konfigurationen keinen Flaschenhals dar. Des Weiteren wurde ein aus zwei Mixen bestehender AN.ON-Dienst (im Folgenden als Testkaskade bezeichnet) auf einem Standard-PC virtualisiert. Der PC war ausgestattet mit dem Quad-Core-Prozessor Intel Core i5-750 und 4 GB DDR3-SDRAM. Als Host- Betriebssystem kam Microsoft Windows 7 Professional x64 zum Einsatz. Die zwei Mix- Server mit jeweils 512 MB RAM liefen unter Ubuntu LTS (32-Bit) virtualisiert durch VMware Workstation Die Testkaskade war über einen VDSL 8 -Internetzugang mit 25 MBit/s Downstream-Bandbreite und 5 MBit/s Upstream-Bandbreite ans Internet angebunden. Die Geschwindigkeitsmessungen wurden zum einen auf dem Testgerät (Smartphone) und zum anderen auf dem Standard-Notebook Lenovo Think- Pad T61 durchgeführt, welche beide via WLAN gemäß IEEE n an das Netzwerk der Testkaskade angebunden waren. Auf dem Smartphone wurden als AN.ON-Client ANONdroid und als Web-Browser Opera Mobile verwendet. Analog dazu wurden auf dem Notebook der JAP und Mozilla Firefox verwendet. Die Tabelle 5.2 zeigt die gemessenen Download-Geschwindigkeiten für die verschiedenen getesteten Konfigurationen. Die Ergebnisse der ersten beiden Konfigurationen zeigen, dass sowohl Notebook als auch Smartphone gleich hohe Datenraten beim direkten Download der Datei erzielt haben. Das Ergebnis der dritten Konfiguration stellt die maximale Datenrate dar, welche die Testkaskade an einen AN.ON-Client liefern kann. Letztendlich zeigt das Ergebnis der vierten Messung, dass auch auf einem Smartphone mit ANONdroid als AN.ON-Client ähnlich hohe Datenraten erzielt werden können. Für die Nutzer von 6 (abgerufen am 15. Februar 2012) 7 (abgerufen am 15. Februar 2012) 8 Abkürzung für Very High Speed Digital Subscriber Line 9 Abkürzung für Institute of Electrical and Electronics Engineers 82

87 5.4 Benutzbarkeit Nr. Beschreibung der Konfiguration Dauer Datenrate 1 Notebook lädt Datei direkt (ohne Testkaskade) 7 s 1.429,57 KB/s 2 Smartphone lädt Datei direkt (ohne Testkaskade) 7 s 1.429,57 KB/s 3 Notebook lädt Datei über Testkaskade 107 s 93,46 KB/s 4 Smartphone lädt Datei über Testkaskade 119 s 84,03 KB/s Tabelle 5.2: Vergleich von Download-Geschwindigkeiten in verschiedenen Konfigurationen ANONdroid bedeutet das, dass sie die Geschwindigkeitsvorteile der Premiumdienste vollumfänglich ausschöpfen können, sofern die Netzanbindung ausreichend schnell ist und das Mobilgerät über eine vergleichbar leistungsfähige Hardware verfügt wie das Testgerät. Es ist allerdings anzunehmen, dass leistungsschwächere Mobilgeräte die von den Premiumdiensten unterstützten Datenraten nicht erzielen können. 5.4 Benutzbarkeit (Usability) Die Benutzbarkeit wurde in einer Nutzerstudie untersucht. Die Testgruppe bestand aus fünf Personen. Drei davon waren Smartphone-Nutzer, von denen wiederum eine Person ein Android-Gerät und zwei Personen ein Apple iphone besaßen. Die verbleibenden zwei Personen hatten zwar nur konventionelle Mobiltelefone, verfügten jedoch über grundlegende Kenntnisse im Umgang mit Smartphones. Nach einer kurzen Erläuterung des grundlegenden Funktionsprinzips von AN.ON im Allgemeinen und ANONdroid im Speziellen, wurde jedem Probanden das Smartphone Samsung Galaxy S II GT-I9100, eine Aufgabenstellung sowie ein Fragebogen ausgehändigt (siehe Anhang B). Die Probanden sollten ANONdroid und Orweb aus dem Android Market installieren, eine anonyme Verbindung herstellen, Host und Port in Orweb konfigurieren und eine bestimmte Webseite aufrufen. Dabei mussten sie gemäß der Aufgabenstellung für einen Dienst sowohl die End-IP-Adresse als auch das Land des letzten Mixes über die Benutzungsoberfläche von ANONdroid ermitteln. Anschließend sollten die Probanden einen Fragebogen mit acht Fragen und einem Freifeld für Hinweise und Verbesserungsvorschläge ausfüllen. Die Fragen konnten mit ja, eher ja, eher nein oder nein beantwortet werden. Beim Entwurf des Fragebogens wurde angenommen, dass diejenigen Probanden, die sich bereits vor der Nutzerstudie mit dem JAP auseinan- 83

88 Kapitel 5 Evaluierung dergesetzt haben, die Aufgaben besser bewältigen würden. Aus diesem Grund wurde im Fragebogen gleich zu Beginn nach Vorkenntnissen in der Funktionsweise und der Bedienung des JAP gefragt. Die Tabelle 5.3 zeigt die quantitative Auswertung des Fragebogens. Ein gefüllter Kreis stellt die Antwort eines Probanden dar, der die erste Frage mit ja oder eher ja beantwortet hat und demzufolge schon über Vorkenntnisse verfügte. Analog dazu stellt ein leerer Kreis die Antwort eines Probanden dar, der keine nennenswerten Vorkenntnisse mitbrachte. Nr. Frage ja eher ja eher nein nein 1 Vorkenntnisse durch JAP 2 Erinnerung an Zugriffsrechte 3 Benutzungsoberfläche verständlich 4 Benutzungsoberfläche intuitiv 5 Schwierigkeiten bei Dienstauswahl 6 Schwierigkeiten beim Verb./Trennen 7 Schwierigkeiten mit Orweb-Konf. 8 ANONdroid selbst nutzen Tabelle 5.3: Quantitative Auswertung des Fragebogens zur Nutzerstudie Erwähnenswert ist die Tatsache, dass sich vier der fünf Probanden nicht mehr an die Zugriffsrechte erinnern konnten, denen sie bei der Installation von ANONdroid zugestimmt haben (siehe Frage 2). Das ist möglicherweise ein Hinweis dafür, dass Anwender unachtsam Apps installieren und somit die Sicherheit ihrer Mobilgeräte gefährden. Die Benutzungsoberfläche wurde von den Probanden größtenteils als verständlich und intuitiv wahrgenommen. Lediglich ein Proband empfand sie als geringfügig überfrachtet. Probanden mit Vorkenntnissen zum JAP beurteilten die Benutzungsoberfläche besser als diejenigen ohne Vorkenntnisse und hatten mit der Bedienung keine Schwierigkeiten. Mit der Auswahl eines Anonymisierungsdienstes sowie mit dem Verbinden und Trennen hatte kein Proband Schwierigkeiten. Bei der Konfiguration von Orweb war sich ein Proband nicht sicher, ob Proxy-Host und Host im gegebenen Kontext dieselbe Eigenschaft bezeichnen. Nur zwei Probanden würden ANONdroid für eigene Zwecke nutzen. Ein Proband, der ANONdroid eher nicht selbst nutzen würde, kommentierte, dass die Internetaktivitäten auf seinem Smartphone den Aufwand nicht rechtfertigen würden. 84

89 5.5 Wartbarkeit/Änderbarkeit Des Weiteren wurden von den Probanden noch die folgenden Hinweise und Verbesserungsvorschläge angebracht: Der Ladevorgang dauert sehr lange. Das Statusleistensymbol sollte noch den Zustand des Verbindungsaufbaus darstellen können. Die Hilfe-Webseite enthält keine Informationen zu ANONdroid. ANONdroid wurde im November 2011 im Android Market veröffentlicht. Die App befand sich zu diesem Zeitpunkt noch in einem sehr frühen Entwicklungsstadium und hatte dementsprechend einige wenige negative Bewertungen erhalten. Kritisiert wurden vor allem lange Ladezeiten und häufige Abstürze. Ende Dezember 2011 wurde die erste effizient benutzbare Version von ANONdroid im Android Market veröffentlicht und hat seitdem einige sehr positive Bewertungen erhalten. 5.5 Wartbarkeit/Änderbarkeit (Maintainability) Die Softwarekomponenten des AN.ON-Projektes werden stetig weiterentwickelt. Neue Versionen der AN.ON-Kernbibliotheken müssen daher gemäß der Anforderung F30 so einfach wie möglich in ANONdroid eingepflegt werden können. Dies wird durch die Verwendung des abstrakten JonDoControllers sichergestellt. Zudem werden durch Apache Maven Abhängigkeiten zu anderen Softwarekomponenten automatisch aufgelöst, sodass sich die Integration neuer Versionen der verwendeten Bibliotheken komfortabel gestaltet. Des Weiteren wurde ANONdroid gemäß der Anforderung F50 unter Einhaltung der Programmierrichtlinien des AN.ON-Projektes entwickelt. Diese bilden eine solide Grundlage für die Weiterentwicklung der Software. Der Quelltext wurde umfangreich in englischer Sprache kommentiert. Mit dem Web-basierten Belastungstest wurde ein wichtiges Werkzeug entwickelt, um auch in künftigen ANONdroid-Versionen semi-automatisch die Zuverlässigkeit der Anonymisierungs-Funktionalität sicherzustellen. Die Internationalisierung basiert auf Java-Properties-Dateien. Dadurch können beispielsweise auch Übersetzer, die über keine Kenntnisse in der Softwareentwicklung 85

90 Kapitel 5 Evaluierung verfügen, Änderungen an bestehenden Übersetzungen vornehmen bzw. weitere Übersetzungen anlegen. Das in den Build-Prozess von ANONdroid integrierte Java-Programm LanguageValidator überprüft die Weboberfläche auf fehlende Übersetzungen. 5.6 Übertragbarkeit (Portability) Um ANONdroid auf eine andere Mobilplattform zu portieren, muss diese bestimmte Voraussetzungen erfüllen. Zum einen muss für die Plattform eine Java-Laufzeitumgebung existieren und zum anderen muss sie Hintergrunddienste unterstützen. Allein schon diese beiden Anforderungen können die meisten der in Abschnitt betrachteten Mobilplattformen nicht erfüllen. Lediglich Symbian und die BlackBerry-Plattformen kommen grundsätzlich für eine Portierung in Frage. Symbian und BlackBerry OS unterstützen die Plattform Java ME, für welche bereits eine prototypische Portierung des JAP begonnen wurde [Kö10]. Da ANONdroid zwangsläufig viele Android-spezifische Klassen verwendet, wäre eine Portierung auf Java ME sehr aufwendig und würde eher einer Neuentwicklung unter Nutzung der Softwarekomponenten des AN.ON-Projektes gleichkommen. BlackBerry 10 hingegen soll mit dem Android App Player auch Android- Apps ausführen können. Das ist vielversprechend, da ANONdroid schon jetzt auf dem BlackBerry Tablet OS, dem Betriebssystem für das Tablet BlackBerry PlayBook, ausgeführt werden kann (siehe Abbildung 5.1). Das Produkt Alien Dalvik 10 von der Firma Myriad Group AG ermöglicht die Ausführung von Android-Apps auf anderen Plattformen. Allerdings gibt es die Software bislang nur für Gerätehersteller, Netzbetreiber und App-Marktplätze, sodass ein Kompatibilitätstest mit ANONdroid im Rahmen dieser Arbeit nicht möglich war (abgerufen am 15. Februar 2012) 86

91 5.6 Übertragbarkeit Abbildung 5.1: ANONdroid auf dem BlackBerry PlayBook Simulator 87