Über unsMediaKontaktImpressum
Raphael Arias & Alexander Mack 03. Dezember 2014

MobileEdge - Ein Framework für sichere und anonyme mobile Kommunikation

Im Projekt MobileEdge geht es um die Entwicklung einer Plattform, die Anwendern von mobilen Geräten Sicherheit und Anonymität gewährleisten soll. Zu diesem Zweck wird ein client- und serverseitiges Framework implementiert, das von Anwendungsentwicklern einfach eingebunden werden kann. Es abstrahiert dabei transparent die Ende-zu-Ende-Verschlüsselung der Kommunikation zwischen Client und Server inklusive Perfect Forward Secrecy. Verwendung findet hierfür das von Trevor Perrin und Moxie Marlinspike entwickelte Axolotl-Ratchet, das bisher hauptsächlich in der App TextSecure angewandt wird. Optional - aber per Voreinstellung aktiviert - soll dabei der Datenverkehr über das Tor-Netzwerk geleitet werden, um für die nötige Netzwerk-Anonymisierung zu sorgen.

Die Endprodukte, also Backend-Proxy, derzeit ein Prototyp in Node.js, sowie jeweils ein Framework für iOS und Android, sollen als Open-Source (unter einer geeigneten Open-Source-Lizenz, voraussichtlich LGPL/AGPL) der Öffentlichkeit zur Verfügung gestellt werden.

Ziel ist es, App- und Service-Entwicklern ein Werkzeug an die Hand zu geben, das den Aufwand, ein sicheres System zu produzieren, maßgeblich reduziert. Der geringe Aufwand zur Einbindung sowie der Open-Source-Charakter sollen Entwickler dazu animieren, MobileEdge in ihr Produkt zu integrieren.

Was bedeutet Anonymität?

Anonymität ist die Abwesenheit eines Namens. Nach einer Definition von Christian Grothoff [1] ist die Aktion eines Nutzers genau dann anonym, wenn die Aktion nicht mit der Identität des Nutzers verknüpft werden kann. Anonymität ist also erreicht, wenn eine Aktion auch von beliebigen anderen Identitäten ausgeführt worden sein könnte. Wichtig ist dabei das Konzept von "anderen". Anonym ist man immer im Bezug auf eine Anonymitätsmenge, also eine Menge von Personen, die es auch gewesen sein könnten.

Bespielsweise ist es der Polizei möglich, auf einer Demonstration – mittels einer Funkzellenabfrage – sämtliche anwesenden Mobiltelefone zu ermitteln. Ein einzelner Demonstrant ist dann innerhalb der Menge derer anonym, die ebenfalls mit Mobiltelefon an der Demonstration teilnehmen. Logischerweise ist ein Individuum stärker anonym, je größer die Anonymitätsmenge ist. Je größer die Menge, desto mehr Bits an zusätzlicher Information werden benötigt, um den einzelnen zu identifizieren.

Pseudonymität?

Pseudonymität ist in gewisser Weise das, was viele im Internet als Anonymität wahrnehmen. Wenn man bspw. in einem Forum, auf einem Blog oder über Twitter etwas veröffentlicht, geschieht dies häufig unter einem Pseudonym (“süßerhase56“). Dadurch, dass oft mehrere Veröffentlichungen unter demselben Pseudonym erfolgen, entsteht eine Art parallele Identität. Tatsächliche Pseudonymität ist die Unverknüpfbarkeit dieser Parallelidentität mit der realen.

Interessanterweise ist Pseudonymität, die zunächst einfacher und so vertraut scheint (durch die Foren, Blogs und Twitter), das härtere Problem. Zwar ist es einfach, ein Pseudonym zu verwenden, doch die Unverknüpfbarkeit einer so entstehenden Parallelidentität mit der echten zu garantieren ist schier unmöglich. Wäre das Problem von Pseudonymität gelöst, ließe sich das Problem der Anonymität trivial lösen (neues Pseudonym für jede Interaktion).

Warum will man anonym sein?

Der Wunsch nach Anonymität kann aus verschiedenen Gründen entstehen. In manchen Gesellschaften ist es die einzige Art, auf die Menschen kommunizieren können, ohne negative Konsequenzen für sich und andere in Kauf zu nehmen. Es muss aber nicht gar so ernst aussehen, damit Anonymität Sinn macht.

Spätestens seit im Juni 2013 die Massenüberwachung durch Geheimdienste als Realität an die Öffentlichkeit gelangte, ist bekannt, dass sämtliche Kommunikation im Internet mitgeschnitten wird. Die Unmengen an Daten, die dabei erfasst werden, enthalten unter anderem sogenannte Metadaten. Bei den Metadaten handelt es sich um die Eckdaten der Kommunikation: Wer schreibt wem? Wo ist er zu dem Zeitpunkt? Häufig wurde und wird auch behauptet, nur diese Daten würden (dauerhaft) gespeichert. Hinterfragt man nun den Wahrheitsgehalt dieser Aussage nicht, so bleibt dennoch ein bitterer Beigeschmack. Hier wird signalisiert, das Mitschneiden von Metadaten sei ja nicht so schlimm. Dabei haben einige Studien und Selbstversuche [2] bereits belegt, dass die Metadaten oft mindestens so aussagekräftig sind, wie Kommunikationsinhalte selbst. Anschaulich wird einem das vor Augen geführt, wenn man folgende Beispiele liest, und sich fragt, welche Mutmaßungen man nach ihrem Lesen anstellen könnte:

  • Die junge Frau Alice ruft bei der Schwangerschaftsberatung an.
  • Bob tweetet aus dem öffentlichen WLAN einer onkologischen Praxis.
  • Der Mitarbeiter der Firma X surft auf der Jobseite der Konkurrenzfirma Y.
  • Der Mitarbeiter der Firma Z ruft Informationen zu einem bestimmten Forschungsgebiet ab.

Die Informationen lassen auf den ersten Blick eine relativ eindeutige Schlussfolgerung zu und häufig mag diese Vermutung auch zutreffen. Wenn die Anzahl der Fälle, in denen die Schlussfolgerung nicht stimmt, klein genug ist, wird der ein oder andere sicher die Auffassung vertreten, es sei in Ordnung, zunächst einmal davon auszugehen, die Schlussfolgerung treffe zu. Und damit begibt man sich auf dünnes Eis.

Mit gegebener Anonymität kann niemand die Beobachtungen, wie sie oben formuliert sind, machen. Da hieße es dann möglicherweise: Irgendjemand ruft bei irgendjemandem an. Oder zumindest: Irgendjemand ruft bei der Schwangerschaftsberatung an. Die Aktion ist mit der Identität nicht verknüpfbar. Dadurch lässt sich kein Profil über eine Person anlegen, aus dem sich weitere Rückschlüsse ziehen lassen ("Bob ist drei Mal wöchentlich in einem McDonald's-WLAN.").

Wie wird man im Internet anonym?

Der Goldstandard zur Anonymisierung im Internet nennt sich onion routing. Nach ihm ist auch das bekannte Tor-Netzwerk ursprünglich benannt (The Onion Router). Beim onion routing werden Pakete erst über mehrere Knoten, sogenannte hops, durch ein Netzwerk geleitet, bevor sie an den eigentlichen Empfänger gesendet werden. Der erhält so als “Absenderadresse“ nur die Adresse des letzten hops. Der eigentliche Sender bleibt vor ihm anonym. Tor ist eine Implementierung dieses Prinzips. Auch hier gilt selbstverständlich: je mehr Leute das Tor-Netzwerk verwenden, desto besser wird der einzelne anonymisiert.

Es gibt unterschiedliche Projekte mit ähnlichen Zielen und Ansätzen wie Tor. Momentan scheint allerdings Tor am weitesten verbreitet und dadurch, wie oben bemerkt wurde, am stärksten anonymisierend. Obwohl einige Angriffe auf Tor in den letzten Jahren bekannt wurden (übrigens auch auf Konkurrenznetzwerke), ist die grundlegende Sicherheit des Netzwerks bisher nicht gebrochen worden. Dies beklagt auch die NSA in ihrem "Tor stinks"-Dokument vom Juni 2012, das aus dem Snowden-Fundus veröffentlicht wurde.

Dennoch ist denkbar, dass in Zukunft weitere Angriffe publik werden oder ein anderes System sich als sicherer hervortut. Aus diesem Grund sollte sich eine Lösung nicht zu stark an Tor klammern und auch mit alternativen Netzwerken kompatibel sein.

Was ist die Schwierigkeit bei mobilen Geräten?

Mobilgeräte sind häufig stärker personengebunden als normale Computer – Familien- oder Arbeitsrechner werden manchmal von mehreren Personen verwendet – und können oft sensible Positionsdaten preisgeben. So kann bspw. ein Onlinedienst verfolgen, wo sich ein Nutzer bewegt, je nachdem von welcher Host- bzw. IP-Adresse er sich verbindet. Diese Adressen lassen sich häufig physischen Orten zuordnen. Nutzern ist dies oftmals vermutlich nicht bewusst, und wenn doch, wissen viele nicht, wie sie damit umgehen sollen. Einigen ist es möglicherweise auch egal, das Potenzial für Missbrauch solcher Metadaten wird oft unterschätzt.

Das Leiten von Datenverkehr durch das Tor-Netzwerk ist ein Schritt zur Anonymisierung der Nutzer. Um aber wirklich wirksamen Schutz zu gewährleisten, müssen auch die kommunizierten Daten selbst anonymisiert werden. Dies bedeutet, dass in Anwendungsdaten keinerlei identifizierende Informationen enthalten sein dürfen. Häufig benötigen Anwendungen aber eine gewisse Identität, sei es für Chats, das Bezahlen oder andere kostenpflichtige Dienste, zu deren Nutzung nur ein bestimmter Kunde berechtigt ist. Diese Notwendigkeit irgendeiner Identität scheint sich mit Anonymität tatsächlich schwieriger vereinbaren zu lassen als mit Pseudonymität. In diesem Fall muss versucht werden, sinnvolle Pseudonymität mithilfe von kurzlebigen kryptographischen Identitäten zu schaffen.

Was kann getan werden?

Mit MobileEdge ist beabsichtigt, eine Plattform zu entwickeln, die Netzwerkanonymität (via Tor), Datenanonymität, bzw. -pseudonymität (via kurzlebiger Identitäten) und Sicherheit (via Axolotl-Ratchet-Protokoll) bietet und sich zudem möglichst transparent in mobilen Apps sowie zugehörigen Backends integrieren lässt.

Als Open-Source-Software soll es einer großen Zielgruppe zugute kommen und Entwickler und Nutzer dazu anstoßen, häufiger auf sichere Lösungen zu setzen.

Denkbar ist die Integration in eine Vielzahl von Apps und Services, beispielsweise in Bereichen des mobilen Bezahlens, der Kommunikation, des Online-Einkaufs, bei datenschutzfreundlichen Bonussystemen oder Whistleblowing-Plattformen.

Designprinzipien

Die Lösung, die entwickelt wird, soll für Entwickler möglichst einfach zu verwenden sein. Ein spürbarer Mehraufwand würde nämlich einfach dazu führen, dass Entwickler das Framework nicht einbinden. Um diese Einfachheit zu erreichen, wird versucht, sich an gängigen und verbreiteten Frameworks (bspw. AFNetworking auf iOS) zu orientieren. Ein Anwendungsentwickler erstellt also einen MOBHTTPRequestOperationManager. An diesem kann er einige Einstellungen vornehmen und ihn ansonsten verwenden wie einen herkömmlichen AFHTTPRequestOperationManager. Wenn allerdings ein Request an eine URL gestellt werden soll, die MobileEdge unterstützt, kümmert sich der Manager – transparent für den Entwickler – um Verschlüsselung der Nachricht und Entschlüsselung der Antwort.

Serverseitig muss ebenfalls die Verschlüsselung und Entschlüsselung von Daten erfolgen können. Um zu vermeiden, dass jedes mögliche Backend (in jeder möglichen Sprache) eigene Bindings für das Framework benötigt, kann MobileEdge als Proxy-Server einfach verschlüsselte Anfragen empfangen und an das eigentliche Backend entschlüsselt weiterreichen. So bewahrt man eine Interoperabilität mit einer großen Anzahl von möglichen Backend-Diensten.
Zwischen den Geräten soll der Datenverkehr durch ein anonymisierendes Netzwerk geleitet werden. Dies geschieht ebenfalls transparent für den Entwickler. Unter gewissen Umständen kann es nötig sein, die Anonymisierung zu deaktivieren. Entwickler können dies durch das Setzen einer entsprechenden Option erreichen.

Architektur

Finale MobileEdge-Systeme bestehen im Grunde genommen aus vier Komponenten. Zwei davon sind direkt Teil von MobileEdge selbst und jeweils verteilt auf den Client (Client-Framework) sowie den Server (Server-Framework). Sie abstrahieren dabei das Ver- und Entschlüsseln der Antworten bzw. Anfragen in beiden Richtungen und dienen somit als eine Art Façade.
Eine weitere Komponente ist der Client selbst, der verschlüsselt mit dem eigentlichen Backend-Service – der vierten Komponente – kommunizieren möchte. Abb. 1 bietet einen Überblick über die Architektur des Systems.

Neben der eigentlichen Verschlüsselung von Daten, die zwischen Client und Backend-Service ausgetauscht werden, bietet das Server-Framework zusätzlich die Fähigkeit, für verschiedene Identitäten sogenannte Prekeys zu verwalten, auf die weiter unten noch genauer eingegangen wird.

Das clientseitige iOS-Framework von MobileEdge befindet sich derzeit noch in der Entwicklung. Ein weiteres Framework für Android (Java) ist geplant. Von außen betrachtet stellt das Framework eine Schnittstelle bereit, über die HTTP(s)-Anfragen verschickt werden können. Um Anonymität zu gewährleisten, können dabei optional alle Anfragen automatisch über das Tor-Netzwerk geroutet werden. Die eigentliche Verschlüsselung, das Routen über Tor sowie die Identitätsverwaltung werden intern innerhalb des Frameworks abgehandelt.

Serverseitig steht momentan eine prototypische Komponente basierend auf Node.js [3] zur Verfügung, die auf Seiten des Backend-Services alle vom Client ankommenden Anfragen entschlüsselt und an den eigentlichen Service übergibt.

Technologien

Um die Mechanismen umzusetzen, die in MobileEdge Sicherheit gewährleisten sollen, kommen einige separate Konzepte zum Einsatz. Unter anderem benötigt es ein Protokoll zum (asynchronen) Schlüsselaustausch und Wechsel (sogenanntes ratcheting – von ratchet (Ratsche)) des Schlüsselmaterials. Dies dient der Gewährleistung einer starken Ende-zu-Ende-Verschlüsselung, um die Vertraulichkeit der Anfragen zu garantieren.

Außerdem steht man vor der Herausforderung, Tor auf iOS zum Laufen zu bekommen. Kein Ding der Unmöglichkeit, wie sich herausstellt. Tor wird benötigt, um das Endgerät und dessen Adresse im Netzwerk vor dem Server sowie eventuellen Lauschern zu verschleiern und so (Netzwerk-)Anonymität zu gewährleisten.

Schlüssel-Ratcheting mit Axolotl

Axolotl ist der Name, den Trevor Perrin und Moxie Marlinspike einem Protokoll [4] zum Schlüsselaustausch und -Ratcheting gaben, das hauptsächlich in Programmen zu asynchroner Kommunikation, z.B. TextSecure [5] und Pond [6] und neuerdings (sehr überraschend) in Whatsapp [7], Anwendung findet.

Axolotl (sprich „Aschólotl“), stammt ursprünglich aus dem Nahuatl und bezeichnet einen mexikanischen Schwanzlurch. Die "Selbstheilung" des Protokolls bei Kompromittierung einzelner Nachrichtenschlüssel erinnert an die Fähigkeit des Schwanzlurchs, Gliedmaßen zu regenerieren.

Es handelt sich um eine Weiterentwicklung von Off-the-Record (OTR) mit einigen Elementen des SCIMP-Ratchets von Silent Circle. Der Schlüsselaustausch basiert auf dem bekannten Diffie-Hellman-(DH-)Verfahren, das in Abb. 2 dargestellt wird.

Jeder Kommunikationspartner hat ein Langzeit- oder Identitätsschlüsselpaar. Zusätzlich erstellen beide ein kurzlebiges (ephemeral) Schlüsselpaar und lassen einander die öffentlichen Schlüssel zukommen. Durch geschickte Kombination der öffentlichen und privaten Schlüssel erhalten sowohl Alice also auch Bob das gleiche Geheimnis, von dem sie im Verlauf der Kommunikation einzelne Nachrichtenschlüssel ableiten können. Der modifizierte DH-Austausch wird in Abb. 3 dargestellt.

Im weiteren Verlauf der Kommunikation werden zusätzliche DH-Parameter an die Nachrichten angehängt und verwendet, um neues Schlüsselmaterial zu generieren – ähnlich wie dies auch bei OTR passiert. Zusätzlich wird aber auch für jede Nachricht ohne erneuten DH-Austausch (bspw. wenn ein Kommunikationspartner für lange Zeit nicht antwortet oder seine Antworten verloren gehen) das Schlüsselmaterial durchgewechselt, indem der sogenannte Chain Key gehasht wird. Abb. 4 visualisiert diesen Vorgang.

Ursprünglich wurde das Protokoll für asynchrone Kommunikation zwischen mehreren Nutzern entwickelt und nicht speziell für eine Client-Server-Kommunikation, wie sie in den meisten Architekturen von mobilen Apps wiederzufinden ist. Dennoch bietet es durch das Ratcheting exzellente Perfect Forward Secrecy und hält die Möglichkeit offen, Kommunikations-, wie Chat- oder Social-Media-Anwendungen, mit MobileEdge zu implementieren.
Ein wichtiges Merkmal des Protokolls ist die Möglichkeit, sogenannte Prekeys zur Verfügung zu stellen. Dabei handelt es sich, vereinfacht gesagt, um eine Vorab-Schlüsselaustauschnachricht. Dies ermöglicht es, bereits den Schlüsselaustausch asynchron durchzuführen – ein unglaublich nützliches Feature, gerade im mobilen Bereich.

Es mag unnötig erscheinen, die ohnehin HTTPS-verschlüsselte Verbindung zum Server noch zusätzlich Ende-zu-Ende zu verschlüsseln. Dies macht aber in Zeiten, in denen Geheimdienste Firmen (auch Certificate Authorities) zur Herausgabe von privaten Schlüsseln zwingen können, durchaus Sinn. Eine Kompromittierung der TLS-Verbindung durch derartige Machenschaften kompromittiert dann nämlich nicht direkt die Integrität und Vertraulichkeit der Kommunikation zwischen Clients und Server.

Ein Tor-Proxy auf iOS

Normalerweise läuft ein Tor-Client auf einem System als eigenständiger Prozess, über den verschiedene Applikationen ihren Datenverkehr leiten können. Auf iOS ist das nicht ohne Weiteres möglich. Deswegen diente für das MobileEdge-Framework Mike Tigas' OnionBrowser für iOS [8] als Vorbild. Tigas verwendet die Tor-Bibliothek, um eine Tor-Main-Funktion als Thread der eigenen App auszuführen. Das Projekt CPAProxy [9] verallgemeinert diesen Ansatz und wird in MobileEdge-iOS verwendet, um Tor-Unterstützung bereitzustellen.

URL-Anfragen der eigenen Anwendung werden dann mittels einer Subklasse von NSURLProtocol abgefangen und über das Tor-Netzwerk geleitet.

Ausblick

Das grob fertiggestellte serverseitige Framework steht bereits auf Github zur Verfügung [10]. Die iOS- sowie Android-Pendants sollen bald folgen. Demo-Apps, die die Funktionalität des Frameworks verwenden, sind ebenfalls in Planung. eMundo freut sich über Kommentare und Vorschläge. Jegliches Feedback und Interesse an Partnerschaften ist willkommen.

Autoren

Alexander Mack

Alexander Mack ist Projektleiter für Mobile Anwendungen bei der Firma eMundo GmbH, hält Vorträge & Schulungen zum Thema App-Entwicklung und ist Lehrbeauftragter an der Technischen Hochschule Ingolstadt für das Fach Entwicklung...
>> Weiterlesen

Raphael Arias

Raphael Arias studiert Informatik an der Technischen Universität München und ist Werkstudent bei der Firma eMundo GmbH. IT-Sicherheit ist sein Schwerpunkt.
>> Weiterlesen
botMessage_toctoc_comments_9210