06 Jun App Sicherheit in iOS

App-Sicherheit in iOS erschien als Gast-Beitrag von Andreas Schenk im Magazin iMOTION von ALSO Deutschland. ALSO ist einer der größten ITK-Distributoren in Deutschland und bietet in seiner Rolle als Großhändler Produkte, Lösungen und Dienstleistungen von mehr als 350 Herstellern aus der IT- und Telekommunikationsbranche an. Die Kunden der ALSO Deutschland sind Systemhäuser, Fachhändler und bekannte Namen aus dem eTail und Retail – diese werden von rund 1.000 Mitarbeitern aus mehreren Standorten in Deutschland betreut.

Die Business Unit Apple der ALSO hat in der dritten Ausgabe ihres hauseigenen Apple-Magazins iMOTION eine Serie zum Thema „Sicherheit in iOS“ gestartet. Der erste Beitrag beleuchtete die Gerätesicherheit von iOS, der zweite Beitrag Netzwerk-Sicherheit in iOS. Hier ist der der dritte Teil.

App Sicherheit in iOS

Der dritte und letzte Teil der Reihe „Sicherheit in iOS“ beschäftigt sich nun mit der Sicherheit der Daten in Apps, nachdem die beiden letzten iMotion Ausgaben die Gerätesicherheit und die Übertragungssicherheit im Netzwerk beleuchtet haben.

Wie sicher sind die Daten in einer App vor fremdem Zugriff?

Auf diese Frage gibt es leider keine immer gültige, einfache Antwort. Auf der einen Seite enthält iOS schon immer seitens Apple mit dem sogenannten Sandboxing eine Funktion, die die Daten der verschiedenen Apps klar voneinander trennt:

Sandboxing

In iOS bekommt jede App ihre eigene, von anderen Apps getrennte Sandbox. Das ist ein abgetrennter Bereich, auf den nur die jeweilig App Zugriff hat. Eine App kann nur innerhalb der eigenen Sandbox Dateien ablegen und auch nur auf Dateien Zugreifen, die in dieser liegen. Auf die Daten einer anderen App, die in deren Sandbox liegen, kann nicht zugegriffen werden. Dieses Prinzip ist im iOS Betriebssystemkern verankert. Damit ist es ausgeschlossen, dass eine App die Daten einer anderen App auslesen kann. Somit muss z. B. ein Unternehmen keine Angst haben, dass eine private App eines Mitarbeiters die vertraulichen Daten einer Unternehmensapp ausliest und missbräuchlich verwendet. Durch das Sandboxing ist jede App auf ihren eigenen kleinen Sandkasten beschränkt.

Das Prinzip des Sandboxing gilt auch für die mitgelieferten Apps und Systemdienste, wie Kontakte, Kalender, Notizen, Photos und mehr. Allerdings sollen diese ja meist auch von den Apps aus dem App Store mitbenutzt werden können. Das Sandboxing gilt hier insofern, dass die anderen Apps sich nicht so einfach die Daten dieser Systemdienste aus dem Dateisystem holen können. Eine App, die z. B. Zugriff auf die Kontakte möchte, muss durch eine sogenannte API – ein Application Programmers Interface – gehen. Bevor das Betriebssystem über diese Schnittstelle den Zugriff gewährt, wird der Anwender mit einer Meldung gefragt, ob der jeweiligen App Zugriff auf den angeklagten Systemdienst gegeben werden soll. Es liegt also in der Hand des Anwenders, ob er diesen Zugriff gewähren oder ablehnen will. Die Zustimmung oder Ablehnung hierbei gilt natürlich nicht fest bis in alle Zeit, sondern kann jederzeit in den Einstellungen unter dem Punkt Datenschutz geändert werden. Hat man z. B. versehentlich einer App den Zugriff auf die Photo Mediathek eingeräumt, so kann man das später jederzeit wieder abschalten. Der Grundsatz sollte hier sein, dass man nur die Zugriffe gewährt, die man wirklich benötigt und alles andere abschaltet, denn hat man einer App den Zugriff auf einen Systemdienst erlaubt, kann die App grundsätzlich die Daten frei nutzen. Man muss sich dann darauf verlassen, dass der Entwickler der App diese nicht missbräuchlich nutzt.

Neben der Überlegung, ob und wie eine App auf die Daten einer anderen App zugreifen kann, ist ja auch noch wichtig, inwiefern die Daten in einer App sicher sind gegenüber einem externen Angreifer, der physischen Zugriff auf das Telefon hat. Ob ein solcher Zugriff möglich ist oder nicht, hängt in erster Linie davon ab, wie wichtig dem Entwickler der App das Thema Datenschutz war, als er die App geschrieben hat. Apple hat schon recht früh ein sehr ausgeklügeltes Verschlüsselungssystem in iOS integriert. Dieses System baut auf Datenschutzklassen auf, über die geregelt ist, zu welchen Zeitpunkten überhaupt die Daten verfügbar sind.

Schutzklassen

Diese Schutzklassen haben verschiedene Abstufungen. So ist z. B. die niedrigste Schutzklasse „available after boot“ sofort nach dem Gerätestart ohne weitere Passworteingabe verfügbar. Dateien dieser Klasse verfügen also über fast keinen Schutz. Sie sind zwischen Start und Herunterfahren des iPhones immer frei verfügbar. Die höchste Schutzklasse „always protected“ dagegen funktioniert so, dass der kryptographische Schlüssel zum Zugriff auf diese Schutzklasse nur erstellt werden kann, wenn neben dem einzigartigen Hardwareschlüssel des jeweiligen iPhones auch die Eingabe des Gerätecodes erfolgt. Dieser Klassenschlüssel wird dann nur im Hauptspeicher gehalten und nicht auf den Flash-Speicher geschrieben und kann nur benutzt werden, solange das iPhone entsperrt ist, denn sobald das iPhone in den Sperrzustand geht, wird der Klassenschlüssel aus dem Hauptspeicher gelöscht. Und da er nirgendwo im Dateisystem existiert, kann er auch von keinem Angreifer ausgelesen oder benutzt werden. Solange das Gerät gesperrt ist, existiert dieser Schlüssel einfach nicht.

Die Entwickler von Apps können für die Daten Ihrer Apps frei wählen, in welcher Datenschutzklasse die App Ihre Daten speichert. Allerdings kann nicht jede App die höchste Schutzklasse „always protected“ verwenden, denn dann würde die App nicht im Hintergrund funktionieren können, während das iPhone gesperrt ist. Aus diesem Grund gibt es noch eine Reihe weiterer Datenschutzklassen, die eine feinere Abstufung möglich machen eine sei hier noch erwähnt, v.a. auch weil diese Datenschutzklasse seit iOS 8 für alle Apps zum Standard wird, bei denen der Entwickler nicht explizit eine andere gewählt hat: „Protected until first authentication“. Bei dieser Schutzklasse wird der kryptographische Schlüssel ähnlich wie bei der höchsten Schutzklasse „always protected“ sowohl vom eindeutigen Hardwareschlüssel, als auch vom Gerätecode abgeleitet. Und auch dieser Schlüssel wird nur im Hauptspeicher gehalten und nicht auf den Flash-Speicher geschrieben. Allerdings wird er nicht aus dem Hauptspeicher gelöscht, wenn das iPhone in den Sperrzustand geht. Damit können die Daten dieser Klasse nach einem Neustart erst genutzt werden, wenn das Gerät zum ersten Mal entsperrt wurde. Danach sind sie dann aber auch im Hintergrund verfügbar. Dies ist z. B. für die allermeisten Musik- oder Navigations-Apps wichtig. Alle seitens Apple mitgelieferten Apps benutzen auch diese Schutzklasse.

Welche Schutzklasse eine App aber verwendet, kann ein Anwender nicht direkt sehen. Wenn Sie als Unternehmen also interessiert sind, welche Schutzklassen die von Ihnen verwendeten Apps benutzen, müssen Sie beim jeweiligen Entwickler nachfragen.

Touch ID für Apps

Ein App-Entwickler kann inzwischen auch die Touch-ID Schnittstelle nutzen, um den Zugriff auf die Daten seiner App zusätzlich zu sichern. Die App fragt dann beim Start nach einer Authentifizierung durch einen in Touch ID gespeicherten Finger. Dabei gibt es keine stärkere Verschlüsselung, es ist lediglich ein weiterer Schlüssel (hier: der Finger) zum entsperren der Daten möglich. Touch ID bringt also auch in Bezug auf die Daten einer App keine zusätzliche Sicherheit, sondern nur einen höheren Komfort, wenn man eine stärkere Sicherheit verwendet. Aber auch das ist ja eine gute Sache.

Als Fazit kann man also sagen, dass die Daten in den Apps vor anderen Apps sicher sind. Bei externen Angreifern steigt die Sicherheit der App-Daten mit der verwendeten Schutzklasse. Da wohl die meisten Apps die Standardklasse „Protected until first authentication“ verwenden, bei der die kryptographischen Schlüssel nach dem ersten Entsperren existieren, sollte man sein Telefon immer Ausschalten, wenn man es aus der Hand gibt. Dadurch übergibt man ein Gerät, bei dem die meisten Daten so geschützt sind, dass ohne eine Eingabe des korrekten Gerätecodes keine Daten extrahiert werden können.