Beitragsbild Ziegler AriasZusammenfassung

Viele der heute auf dem Markt verfügbaren Apps wurden ohne ernsthafte Berücksichtigung von Sicherheitsaspekten entwickelt und viele Entwickler und Unternehmen legen leider auch weiterhin keinen großen Wert darauf. Die Gründe dafür sind meist finanzieller Natur, häufig aber auch auf mangelnde Kenntnisse der Entwickler und Projektmanager zurückzuführen.

Absolute Sicherheit kann es für mobile Apps ebenso wenig geben wie für sonstige Software. Trotzdem, ja gerade deswegen, ist es erforderlich, Sicherheitsaspekte bereits in der Designphase einer App zu berücksichtigen und diese während des gesamten Entwicklungszyklus im Auge zu behalten und zu verifizieren, denn Sicherheit ist kein hinterher eingebautes Zusatzfeature, sondern das Ergebnis sorgfältiger Entwicklung und umfassender Tests.

Für Sie als iOS-Entwickler bedeutet das, dass Sie sich nicht nur bezüglich neuer Bibliotheken, Tools und Technologien, sondern auch hinsichtlich aktueller Erkenntnisse auf dem Gebiet der IT-Sicherheit auf dem aktuellen Stand halten müssen. Ebenso wichtig ist natürlich, dass Sie stets im Auge behalten, welche Sicherheitslücken die von Ihnen verwendeten Bibliotheken, Plattformen, Protokolle und Services beinhalten.

In diesem Kapitel geben wir Ihnen einen grundlegenden Überblick über das iOS-Sicherheitsmodell, wesentliche Sicherheitskonzepte für mobile Anwendungen sowie Privatsphäreanforderungen und -Schutzmaßnahmen für mobile Apps.

Beim Lesen dieses Kapitels wird sich Ihnen vielleicht häufig das Gefühl aufdrängen, jemand stünde mit erhobenem Zeigefinger vor Ihnen. Es ist leider schwierig, die Notwendigkeit der Beachtung elementarer Sicherheitsregeln anders zu vermitteln[1]. Es ist und bleibt unverzichtbar, diese Ratschläge zu beherzigen und sich mit der Sicherheit von Anwendungen auseinanderzusetzen. Wir hoffen, Sie sind trotzdem gespannt darauf, mehr über Sicherheit im Bezug auf iOS zu erfahren.

 

Das Sicherheitsmodell von iOS

Apple veröffentlicht mehr oder weniger regelmäßig einen iOS Security Guide, in dem das Sicherheitsmodell der jeweils aktuellen iOS-Version beschrieben wird. Die aktuelle Version (iOS Security Guide, 2015) dieses Dokuments stammt vom April 2015. Prinzipiell hat Apple bei der Konzeption des iOS-Systems, was Sicherheit angeht, viele Dinge richtig gemacht. So ist beispielsweise der Boot-Prozess von iOS mithilfe der sogenannten secure boot chain gegen Angriffe auf dieser Ebene weitestgehend abgesichert. Durch diesen Schutzmechanismus kann nur von Apple signierter Code während des Startprozesses geladen werden. Auch die Geräteverschlüsselung, bei der jede Datei mit einem eigenen Schlüssel verschlüsselt wird, beinhaltet sehr viele, theoretisch sichere Mechanismen zum Schutz von Daten. Durch sogenanntes sandboxing soll sichergestellt werden, dass Apps nur ihre eigenen Daten sehen und verändern können. Insbesondere soll das System nicht durch Apps verändert werden können. In diesem Abschnitt lernen Sie, welche Techniken eingesetzt werden, um diese Schutzmechanismen zu ermöglichen.

 

Codesignierung und -verifikation

Apple hat sein Betriebssystem so konzeptioniert, dass nur von Apple signierter Code auf dem System ausgeführt werden können soll. In diesem Zusammenhang sollte vielleicht kurz erläutert werden, was man unter einer kryptographischen Signatur versteht.

Die Idee hinter einer digitalen Signatur entspricht im Grunde der Idee einer Unterschrift. Es soll also sichergestellt werden, dass eine bestimmte Information tatsächlich von einem bestimmten Autor stammt. Umgesetzt wird dies mithilfe von asymmetrischer Kryptographie. Bei asymmetrischer Kryptographie, häufig auch public key cryptography genannt, ist jeder Identität, also zum Beispiel einer Person, ein Schlüsselpaar zugeordnet. Ein solches Schlüsselpaar besteht dabei aus einem öffentlichen Schlüssel (public key) und einem geheimen, persönlichen Schlüssel (private oder secret key). Dabei muss, wie der Name schon sagt, letzterer unter allen Umständen geheim bleiben. Der öffentliche Schlüssel allerdings, muss Kommunikationspartnern bekannt sein.

Nehmen wir an, Alice[2] möchte eine Nachricht an Bob senden. Wenn zur Signierung das klassische RSA-Verfahren, ein sehr populäres asymmetrisches Kryptosystem, das von Ronald Rivest, Adi Shamir und Leonard M. Adleman 1978 vorgestellt wurde (Rivest, et al., 1978), eingesetzt wird, wie es beispielsweise im OpenPGP-Standard (Callas, et al., 2007) vorgesehen ist, würde Alice dabei zunächst eine Prüfsumme der Nachricht berechnen und diese anschließend mithilfe ihres private keys verschlüsseln. Bob würde, um zu überprüfen, ob die entsprechende Nachricht tatsächlich von Alice verfasst wurde, zunächst die von Alice erhaltene Signatur mit ihrem public key entschlüsseln[3] und die dabei erhaltene, von Alice erzeugte Prüfsumme der Nachricht, mit einer selbst erzeugten Prüfsumme der Nachricht vergleichen. Sind diese Prüfsummen identisch, kann Alice als Autorin der Nachricht angesehen werden (siehe Bild 1).

Bild 1: Funktionsweise einer kryptografischen Signatur

Bild 1: Funktionsweise einer kryptografischen Signatur

Während Bob mithilfe Alices Signatur sicherstellen kann, dass eine Nachricht auch tatsächlich von Alice stammt, sind iOS-Geräte eher daran interessiert, dass der Programmcode, den sie ausführen, wirklich von Apple stammt. Unter Umständen sind sie auch mit Apples Versprechen, den Code geprüft zu haben, zufrieden; nämlich dann, wenn der Programmcode von Drittanbietern stammt.

 

Der Boot-Prozess unter iOS

Damit Sicherheit auf Anwendungsebene überhaupt gewährleistet werden kann, muss die darunter liegende Betriebssystemebene hinreichend gegen Angriffe abgesichert werden. Apple versucht dies mithilfe der sogenannten secure boot chain zu erreichen. Dabei wird jede Softwarekomponente einzeln mithilfe einer kryptographischen Signatur verifiziert und nur dann gestartet, wenn ihre Integrität bestätigt wurde.

Dazu ist im sogenannten Boot ROM der Apple Root CA public key abgelegt, der erforderlich ist, um die kryptographischen Signaturen der im Laufe des Bootprozesses zu ladenden Komponenten (Bootloader, Kernel, Kernelmodule und Baseband Firmware) zu überprüfen (iOS Security Guide, 2015).

Der Boot ROM wird bei der Herstellung im Apple-Werk beschrieben und sollte anschließend nie wieder beschrieben werden können (Read Only Memory). Wie bei den meisten Systemen handelt es sich beim Boot ROM von iOS-Geräten jedoch nicht um einen echten ROM-Speicher. Durch das Ausnutzen von Exploits kann dieser Speicherbereich im sogenannten DFU-Modus (Device Failsafe Utility bzw. Device Firmware Upgrade) überschrieben werden. Dieser Ansatz wird zum Beispiel genutzt, um Jailbreaks zu ermöglichen (Zdziarski, 2012).

Sobald es einem Angreifer gelungen ist, den Boot ROM zu überschreiben und dort insbesondere Apples Root-Zertifikat mit einem eigenen Zertifikat zu ersetzen, kann er beliebigen Code während dem Boot-Prozess ausführen und auf diese Art und Weise die Integrität der geladenen Komponenten zerstören.

 

App code signing

Um eine App unter iOS auszuführen ist es ebenfalls erforderlich, dass diese von Apple signiert wurde. Apple testet dabei alle Apps mithilfe spezieller Blackbox-Tests, die Schadsoftware erkennen sollen.

Dass dieses Verfahren selbstverständlich nicht wirklich vor bösartiger Software schützt, sollte jedem klar sein. Vielmehr handelt es sich bei diesem Prozess, wenngleich man ihm natürlich zumindest eine ganz kleine Verbesserung der Sicherheitssituation zugestehen muss, vorrangig um ein Politikum. Mithilfe dieses Prozesses hat Apple die Kontrolle darüber, welche Software für iOS-Geräte verfügbar ist.

 

Geräteverschlüsselung

Apple hat in iOS standardmäßig Geräteverschlüsselung integriert. Das ist auf jeden Fall ein Fortschritt gegenüber klassischen Betriebssystemen. Alle unter iOS abgelegten Dateien werden mit einem individuellen File Key verschlüsselt, der wiederum vom File System Key und dem entsprechenden Class Key verschlüsselt wird (siehe Bild 2) (iOS Security Guide, 2015).

Bild 2: Funktionsweise der Hardwareverschluesselung unter iOS und die hierarchische Schluesselabhaengigkeit

Bild 2: Funktionsweise der Hardwareverschlüsselung unter iOS und die hierarchische Schlüsselabhängigkeit.

Auf diese Art und Weise ist gewährleistet, dass eine Datei nur dann entschlüsselt werden kann, wenn der entsprechende Class Key und der File System Key zur Verfügung stehen. Indem man den File System Key überschreibt, kann man in kürzester Zeit alle Daten vom Mobiltelefon löschen, schließlich kann ohne diesen Schlüssel auf keine Datei zugegriffen werden.

 

Sandboxing

Ebenfalls ein wichtiges Sicherheitskonzept von iOS ist das sogenannte Sandboxing, bei dem jede Anwendung in ihrer eigenen sicheren Umgebung ausgeführt wird. Auf diese Art und Weise wird gewährleistet, dass eine App andere Apps weder bewusst noch versehentlich manipulieren kann und auch, dass eine App nur auf ihre eigenen Dateien zuzugreifen vermag. Die Kommunikation zwischen zwei Apps ist dabei nur über iOS-Services möglich (iOS Security Guide, 2015).

 

Nachdem Sie in diesem Teil einen grundlegenden Überblick über die in iOS integrierten Sicherheitsmechanismen erhalten haben, erfahren Sie in den folgenden beiden Teilen, wie Sie diese Konzepte in Ihren Anwendungen nutzen und geeignet erweitern können. Sie erfahren zusätzlich, wo besondere Gefahren für Sicherheitslücken liegen, und wie Sie Anonymität für Ihre Nutzer gewährleisten können.

 

[1] Zugegeben: Es ist nicht so, als hätten die Autoren keinen Spaß daran, andere mit erhobenem Zeigefinger zu belehren.

[2] Alice und Bob sind in diesem Kontext übliche Repräsentanten. Erstmals angeführt wurden diese von Rivest, et al. in A method for obtaining digital signatures and public-key-cryptosystems (Rivest et al., 1978).

[3] Die Verwendung von private und public key bei der Verschlüsselung einer Nachricht ist genau umgekehrt.

 

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.)