Beitragsbild Ziegler AriasIm dritten Teil dieses Beitrages erfahren Sie mehr über die speziellen Privatsphäreanforderungen, die Sie berücksichtigen müssen, wenn Sie sichere iOS-Apps entwickeln möchten. Dazu gehört nicht nur Ende-zu-Ende-Verschlüsselung, sondern auch die Anonymisierung des Datenverkehrs. Nur so schützen Sie Ihre Nutzer effektiv vor Angreifern und Datenspionen.

Wenn Sie eine App schreiben, werden Sie in den meisten Fällen persönliche Daten des Nutzers erheben und zur Verarbeitung an Ihre Server übertragen. Dabei sollten Sie zumindest einfache Schutzmaßnahmen ergreifen, um zu verhindern, dass auf dem Übertragungsweg, oder auf Ihrem Server Dritte an diese Daten gelangen. Um das zu verhindern, sollten Sie Daten mindestens auf dem Transportweg wirksam verschlüsseln. Auf dem Server sollten Sie Daten nur dann permanent ablegen, wenn diese für die Funktion Ihrer Anwendung unverzichtbar sind. Sollte dies der Fall sein, ist auch hier eine geeignete Verschlüsselung zu wählen.

Um Ihren Nutzern zu ermöglichen, Ihren Dienst anonym zu nutzen, sollte es möglich sein, diesen über netzwerkanonymisierende Dienste, wie beispielsweise Tor[1] oder das Invisible Internet Project (I2P)[2] zu erreichen. Dadurch wird sowohl einem lokalen, als auch einem globalen Beobachter erschwert, festzustellen, welche Nutzer Ihren Dienst wann und wie häufig verwenden.

 

Kryptosysteme

Man kann unterschiedliche Kryptosysteme nach verschiedenen Kriterien unterteilen. Typischerweise unterscheidet man zwischen symmetrischen und asymmetrischen Verfahren. Symmetrische Verfahren wiederum unterteilt man in Blockchiffren (Block Cipher) und Stromchiffren (Stream Cipher).

Besonders wichtig für jegliche Art von Kryptosystem ist heute der von Auguste Kerckhoffs zu Beginn des Jahres 1883 postulierte Grundsatz, dass das System selbst keine Geheimhaltung erfordern darf, dass also die Vertraulichkeit eines bestimmten Chiffrentextes nur die Geheimhaltung des Schlüssels, nicht aber die Geheimhaltung des verwendeten Verfahrens erfordern darf (Kerckhoffs, 1883)[3]. Kann man das Kerckhoffs’sche Prinzip auf ein bestimmtes Kryptosystem nicht anwenden, spricht man von Security through obscurity.

 

Transportverschlüsselung

Unter dem Terminus Transportverschlüsselung versteht man die Verschlüsselung von Daten auf dem Transportweg. Das bedeutet, dass Daten zwar vor einem außenstehenden Beobachter nicht mitgelesen werden können, jedoch von jeder, direkt an der Kommunikation beteiligten Instanz. Betrachten wir das am Beispiel der E-Mail-Kommunikation, wie sie heute leider im Gros der Fälle stattfindet: Angenommen Alice <alice@gmy.de> möchte Bob <bob@0und0.de> eine E-Mail senden. Dazu überträgt sie diese E-Mail unter Einsatz von Transportverschlüsselung an den Mailserver ihres Anbieters, in diesem Fall gmy.de. Dort wird die eingehende Nachricht entschlüsselt und anschließend unter Einsatz von Transportverschlüsselung an Bobs Mailserver, in diesem Fall 0und0.de, übertragen. Die eingehende Nachricht wird hier ebenfalls entschlüsselt und, sobald Bob seine Mails abruft, ein letztes Mal mithilfe von Transportverschlüsselung verschlüsselt an Bob übertragen. Neben Bob und Alice kann die E-Mail also von deren Anbietern GMY und 0&0 gelesen werden (siehe Bild 1)[4].

Abb3

Bild 1: Ende zu Ende vs. Transportverschlüsselung am Beispiel einer E-Mail

TLS

Das heute am Weitesten verbreitete Protokoll zur Transportverschlüsselung ist das Transport Layer Security Protokoll[5](TLS) (Dierks, et al., 2008). Auch wenn dieses Protokoll eine wesentlich größere Sicherheit als unverschlüsselte Kommunikation bietet, ist es kein Allheilmittel. Gerade die vielen Ausnahmeregelungen des Protokolls haben dazu geführt, dass selbst bei Verwendung sicherer Kryptosysteme Sicherheitslücken existieren, die Angreifern sogenannte Man-in-the-Middle-Attacken ermöglichen.

Dazu kommt, dass TLS, um überhaupt theoretische Sicherheit bieten zu können, zusammen mit sicheren Kryptosystemen genutzt werden muss. Andernfalls ist es einem Angreifer möglich, den ursprünglich verschlüsselten Netzwerkverkehr mithilfe von Kryptoanalyseverfahren zu entschlüsseln. Dazu kommen zuweilen auch Fehler in den einzelnen Implementierungen, wie der im Jahr 2014 entdeckte Heartbleed-Bug (The Heartbleed Story, 2014) in der OpenSSL-Implementierung.

Neben diesen kryptographischen Schwächen, kann man dem TLS-Protokoll noch eine weitere Schwachstelle attestieren, die in der zugrundeliegenden, zentralisierten Public Key Infrastruktur begründet liegt. Die Zertifikate, die einen Server gegenüber dem Client beim TLS-Protokoll authentifizieren, werden von sogenannten Certificate Authorities ausgestellt. Dabei handelt es sich meist um Unternehmen mit vorrangig ökonomischen Interessen. Diese rund 300 Certificate Authorities legen im Grunde fest, wem Nutzer vertrauen können und wem nicht. Ist das ein sinnvolles Konzept? Wohl kaum, zumindest dann nicht, wenn man davon ausgeht, dass Vertrauensentscheidungen subjektiv sind. Woher soll eine Certificate Authority, die nicht einmal weiß, dass Sie existieren, besser wissen, wem Sie vertrauen können, als Sie selbst?

 

Ende-zu-Ende-Verschlüsselung

Im Gegensatz zu Transportverschlüsselung hat der Betreiber eines Dienstes beim Einsatz von Ende-zu-Ende-Verschlüsselung keinerlei Zugriff auf die übermittelten Benutzerdaten. Stattdessen werden diese, im Falle einer interpersonellen Kommunikation zwischen den Endgeräten zweier Nutzer, bzw. im Falle einer Nutzung der Daten ausschließlich durch den Nutzer selbst, nur für dessen Endgerät(e), verschlüsselt.

Auf diese Art und Weise wird nicht nur gewährleistet, dass Angreifer, die keinen Zugriff auf einen der Endpunkte der Kommunikation haben, auch keinen Zugriff auf die übermittelten Daten erlangen können, sondern auch, dass Sie als Betreiber eines Dienstes keine Benutzerdaten einsehen können. Damit schützen Sie Ihre Nutzer nicht nur vor Missbrauch ihrer Daten durch Mitarbeiter Ihrer Firma, sondern Sie stellen unter anderem auch sicher, dass Sie von keinem Geheimdienst zur Herausgabe von Nutzerdaten gezwungen werden können (Dingledine, 2013).

Einsatzszenarien von Ende-zu-Ende- und Transportverschlüsselung

Sie sollten grundsätzlich sowohl eine Ende-zu-Ende- als auch eine Transportverschlüsselung in Ihren Anwendungen einsetzen und nur dann auf reine Transportverschlüsselung zurückfallen, wenn dies unbedingt erforderlich ist.

Außerdem sollten Sie stets darauf achten, sogenannte Perfect Forward Secrecy zu erreichen. Andernfalls fällt einem Angreifer die gesamte Kommunikation eines Nutzers in die Hände, wenn es ihm gelingt, den Schlüssel einer Nachricht zu rekonstruieren. Dies gilt insbesondere, da einige Geheimdienste Kommunikation dauerhaft oder über einen langen Zeitraum hinweg speichern.

Verarbeitung persönlicher Daten in zentralisierten Infrastrukturen

Nicht nur bei der Übermittlung von Nutzerdaten in öffentlichen Netzwerken ist es wichtig, diese vor unberechtigtem Zugriff zu schützen. Auch wenn diese Daten bei Ihnen auf einem Server gespeichert sind, ist es erforderlich, sicherzustellen, dass unberechtigte Dritte nicht darauf zugreifen können. Dazu gehören Angreifer, denen es gelingt Zugriff auf Ihren Server zu erlangen, Dienstleister Ihres Unternehmens, die beispielsweise die Server-Infrastruktur in Stand halten und die Mitarbeiter Ihres Unternehmens.

Um Daten dabei auch vor technisch versiertem Personal zu schützen, das dazu in der Lage ist, zugriffsgeschützte Benutzeroberflächen zu umgehen, ist auch hier der Einsatz kryptographischer Verfahren erforderlich. Im besten Fall verarbeiten Sie in Ihren Systemen ohnehin nur Ende-zu-Ende-verschlüsselte Daten, sodass Sie sich hier keine weiteren Gedanken zu machen brauchen. Sollten Sie jedoch auch im Klartext vorliegende Daten in Ihren Systemen speichern müssen, auf die womöglich sogar Ihre Mitarbeiter zugreifen müssen, so ist es erforderlich, geeignete Verfahren zu finden, die eine differenzierte Zugriffskontrolle ermöglichen. Eine sehr interessante Möglichkeit für dieses Szenario bietet die sogenannte Attributbasierte Verschlüsselung (Sahai, et al., 2004; Goyal, et al. 2006).

Onion Routing

Auch wenn Kommunikation dank Verschlüsselung vertraulich zwischen zwei Instanzen stattfindet, so geben doch die Metadaten reichlich Aufschluss über soziale Netzwerke, Standort, ja unter Umständen sogar Inhalte der Kommunikation. Das bislang erfolgreichste Konzept zur Verschleierung von Metadaten ist das sogenannte Onion Routing. Der Name Onion Routing rührt daher, dass Datenpakete, wie beim Aufbau einer Zwiebel aus den unterschiedlichen Schalen, ineinander geschachtelt und dabei jeweils mit unterschiedlichen Schlüsseln verschlüsselt werden. Anschließend wird die so erzeugte Onion-Struktur über mehrere Knotenpunkte geleitet, wobei an jedem der Knoten eine Schicht entfernt wird. Der letzte Knoten leitet dann das eigentliche Datenpaket an den Empfänger weiter. Wurde das Paket vorher durch mindestens drei Knotenpunkte geleitet, sind Absender und Empfänger ohne sogenannte Korrelationsattacken[6] nicht mehr gleichzeitig bestimmbar.

Das Prinzip des Onion Routings wurde 1998 von Michael G. Reed, Paul F. Syverson und David M. Goldschlag (Reed, et al., 1998) im Naval Research Laboratory, einem Forschungslabor der US Navy, entwickelt. Heute wird Onion Routing vor allem im Rahmen des Tor-Projekts (Dingledine, et al., 2004) verwendet, das unter anderen von Roger Dingledine und Nick Mathewson geleitet wird[7]. Tor hat sich über die Jahre zu einem so mächtigen Werkzeug für den Schutz der Privatsphäre entwickelt, dass sich selbst die NSA die Zähne daran ausbeißt, Tor-Nutzer zu enttarnen: „Tor stinks“ (NSA: Tor Stinks, 2013) oder „Still the King of high secure, low latency Internet Anonymity“ (NSA: The king of high-secure, low-latency anonymity, 2013) kann man auf den von Edward Snowden geleakten Folien der NSA lesen.

Android-Nutzer können mittels der App Orbot[8] vergleichsweise einfach eine Verbindung mit dem Tor-Netzwerk herstellen; iOS-Nutzern fehlt so eine einfache Möglichkeit bisher. Allerdings können Sie als Entwickler mittels der Komponente CPAProxy[9] relativ einfach einen Tor-Client in Ihre App integrieren. Es ist außerdem möglich, dass die iOS-Version 9 ein integrieren von Tor mit anderen Apps erleichtert[10], hier handelt es sich aber um reine Spekulation.

Lesen Sie auch die beiden ersten Teile des Beitrages Das Sicherheitsmodell von iOS und Sicherheitskonzepte für mobile Entwicklung.

 

[1] https://torproject.org

[2] https://geti2p.net

[3] Man nennt das auch Kerckhoffssches Prinzip.

[4] Man nennt dieses Prinzip in den Marketing-Abteilungen deutscher E-Mail Provider auch E-Mail made in Germany.

[5] Frühere Versionen des TLS-Protokolls wurden unter der Bezeichnung Secure Socket Layer (SSL) veröffentlicht. Daher ist SSL auch heute noch die vermutlich häufiger verwendete, eigentlich jedoch falsche, Bezeichnung für das TLS-Protokoll.

[6] Unter einer Korrelationsattacke versteht man einen Angriff, bei dem zwei getrennt beobachtete Ereignisse miteinander in Verbindung gebracht werden und auf diese Art und Weise weitere Informationen abgeleitet werden können.

[7] Weitere bekannte Personen aus dem Umfeld des Tor-Projekts sind Jacob Appelbaum, Ian Goldberg, Mike Perry und viele weitere prominente Persönlichkeiten aus dem IT-Sicherheitssektor, nicht zu vergessen, eine große Gemeinschaft von freiwilligen Entwicklern.

[8] https://guardianproject.info/apps/orbot/

[9] https://github.com/ursachec/CPAProxy

[10] iOS 9 beinhaltet eine neue VPN-Schnittstelle.

 

Literatur

(NSA: Tor Stinks, 2013) ’tor stinks’ presentation – read the full document, 2013. http://www.theguardian.com/world/interactive/2013/oct/04/tor-stinks-nsa-presentation-document.

(NSA: The king of high-secure, low-latency anonymity, 2013) Tor: ’the king of high-secure, low-latency anonymity, 2013. http://www.theguardian.com/world/interactive/2013/oct/04/tor-high-secure-internet-anonymity.

(The Heartbleed Story, 2014) The heartbleed story, 2014. http://www.codenomicon.com/resources/brochure/pdf/Heartbleed-Story.pdf.

(iOS Security Guide, 2015) ios security. https://www.apple.com/business/docs/iOS_Security_Guide.pdf, 2015. letzter Zugriff: 09.05. 2015.

(Callas, et al., 2007) J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayer. RFC 4880: OpenPGP Message Format. 2007. http://tools.ietf.org/html/rfc4880.

(Dierks, et al., 2008) T. Dierks and E. Rescorla. Rfc 5246: The transport layer security (tls) protocol version 1.2, 2008. http://tools.ietf.org/html/rfc5246.

(Dingledine, et al., 2004) R. Dingledine, N. Mathewson, and P. Syverson. Tor: The second-generation onion router, 2004. https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf.

(Goyal, et al., 2006) V. Goyal, O. Pandey, A. Sahai, and B. Waters. Attribute-based encryption for fine-grained access control of encrypted data, 2006.

(Kerckhoffs, 1883) A. Kerckhoffs. La cryptographie militaire. Journal des sciences militaires, IX, 1883.

(Lattner, 2014) C. Lattner, 2014. http://chrislattner.com/.

(Paget, 2010) C. Paget. Practical cellphone spying, 2010.

(Reed, et al., 1998) M. G. Reed, P. F. Syverson, and D. M. Goldschlag. Anonymous connections and onion routing. IEEE Journal on Selected Areas in Communications, 16, 1998.

(Rivest, et al., 1978) R. L. Rivest, A. Shamir, and L. M. Adleman. A method for obtaining digital signatures and public-key cryptosystems. CACM, 21(2):120–126. (This is the RSA paper.).

(Dingledine, 2013) R. Dingledine, J. Appelbaum. Q&a marathon, 2013. https://gnunet.org/tor2013tum-video.

(Sahai, et al., 2004) A. Sahai and B. Waters. Fuzzy identity based encryption. Cryptology ePrint Archive, Report 2004/086, 2004. http://eprint.iacr.org/.

(Zdziarski, 2012) J. Zdziarski. Hacking and Securing iOS Applications. O’REILLY, 2012.

(Dieses Literaturverzeichnis bezieht sich auf alle drei Teile des Beitrages Sicherheit in der iOS-Entwicklung, der im kostenlosen E-Book als gesamtes Kapitel veröffentlicht wird.)