Mobile · 11. Mai 2015 0

iOS Sicherheit

Apple nutzte bei der Entwicklung von iOS das bereits vorhandene Wissen aus dem Desktop Bereich und etablierte einen neuen Ansatz für die Sicherheit unter einer neuen Architektur. iOS unterscheidet sich von Android schon dahingehend, dass die Hardware und Software aus einer Hand kommt und auch nicht dafür vorgesehen ist, auf anderen Geräten installiert zu werden. Dabei schützt es nicht nur das Gerät und seine Daten, sondern das gesamte Ökosystem, also das was Benutzer lokal, im Netzwerk und mit Internet-Diensten macht. Viele dieser Funktionen sind standardmäßig aktiviert, so dass IT-Abteilungen nicht umfangreiche Konfigurationen vornehmen müssen. iOS ist eines der komplexesten Betriebssysteme für mobile Geräte und bietet weitaus mehr als die hier beschriebenen Funktionen. Abbildung 1 zeigt die Sicherheitsarchitektur unter iOS:


Abbildung 1: Die iOS Sicherheitsarchitektur. (Quelle: Eigene Abbildung nach: https://www.apple.com/business/docs/iOS_Security_Guide.pdf, Stand 11.05.2015.)

Sichere Boot-Kette
Jeder Schritt des Startvorgangs enthält von Apple kryptographisch signierte Komponenten, um die Integrität dieser zu gewährleisten. Wird ein iOS Gerät eingeschalten, lädt es zunächst den Inhalt (Code) des Boot-ROM. Dieser unveränderliche Code wird während der Herstellung hinterlegt und enthält u.a. den öffentlichen Schlüssel des Apple Root Zertifikats der Zertifizierungsstelle von Apple, um sicherzustellen, das der Low-Level-Bootloader (LLB) auch von Apple signiert wurde bevor er geladen wird. Dies ist der erste Schritt innerhalb der Vertrauenskette, wo in jedem weiteren Schritt wieder überprüft wird, ob die Signatur gültig ist. Nachdem der LLB seine Aufgaben erledigt hat, überprüft und lädt er den nächsten Bootloader iBoot, welcher wiederum nach erfolgreicher Überprüfung den iOS Kernel lädt. Die sichere Boot-Kette stellt sicher, dass Low-Level-Software nicht manipuliert wurde und auch nur auf Apple Geräten läuft. Sollte ein Prozess des Bootvorgangs den nächsten nicht laden oder überprüfen können, muss das Gerät mit iTunes über einen USB-Kabel verbunden werden, um es so auf die Werkseinstellungen zurückzusetzen. Ein ähnlicher Boot-Prozess durchläuft auch das Baseband-Subsystem bei Geräten mit Mobilfunkzugang.

Signatur der Apps
Sobald der iOS-Kernel geladen ist, steuert er welche Benutzerprozesse und Apps ausgeführt werden können. Um sicherzustellen, dass alle Apps von einer bekannten und anerkannten Quelle stammen und nicht manipuliert wurden, muss der ausführbare Code unter iOS mit einem gültigen Zertifikat von Apple signiert sein. Damit erweitert die Pflichtsignierung die Vertrauenskette und verhindert die Ausführung von unsignierten Apps oder das Nachladen von Schadcodes. Apple eigene Apps unterliegen denselben Restriktionen, werden aber von Apple selbst signiert. Um ein solches Zertifikat zu bekommen, muss man sich zunächst bei Apple als Entwickler registrieren und bekommt nach erfolgreicher Identitätsüberprüfung ein gültiges Zertifikat zum Signieren der eigenen App, um diese bei Apple einzureichen. Apple wiederum signiert diese App zusätzlich nach erfolgreicher Überprüfung, damit diese unter iOS starten kann.

Sandbox
Ist eine App erfolgreich überprüft worden, greifen weitere Sicherheitsmaßnahmen, die verhindern, das andere Apps oder das System beeinträchtigt werden. Hierzu erfolgt die Installierung aller Drittanbieter Apps in einer Sandbox. Unter Sandbox ist ein explizit zugewiesener Bereich im Dateisystem, in dem eine App schreibend Zugriff bekommt, zu verstehen. Außerhalb dieses Bereiches darf eine App nicht auf die Sandbox einer anderen App oder auf Systemdateien lesend oder schreibend zugreifen. Die Systempartition ist bspw. als nur lesend eingebunden. Somit ist auch sichergestellt, dass eine App keine Daten einer anderen auslesen oder manipulieren darf. Das macht das Löschen einer App ebenso einfach, da ihre Dateien etc. nicht im System verstreut liegen. Um auf fremde Daten oder lokale Ressourcen, wie das Adressbuch oder auf Fotos zuzugreifen, werden Dienste und API-Aufrufe bereitgestellt. Remote-Login-Dienste wurden hingegen nicht in das System integriert. Address Space Layout Randomization (ASLR) schützt das System u.a. gegen die Ausnutzung von Speicherfehlern, da beim Start einer App der benötigte Speicherbereich nach dem Zufallsprinzip zugewiesen wird. Dies erschwert Angreifer den Programmcode einer App in Speicher zu finden. Diese Technik findet auch bei den Systemeigenen Apps Verwendung, zudem werden Drittanbieter Apps unter Xcode automatisch mit ASLR kompiliert. Weiteren Schutz bietet ARMs Execute Never (NX) Funktion, welche Speicherseiten als nicht ausführbar markiert. Ein Angreifer könnte Codes in einen Speicherbereich einschleusen und hoffen, dass diese von der App gelesen werden. Der iOS-Kernel überprüft hierbei, ob die Apple eigene Berechtigung zur dynamischen Codesignierung vorhanden ist. Sollte dies der Fall sein, ist auch nur ein einziger Aufruf einer beschreibbaren und ausführbaren Speicherseite möglich. Safari (Apple Browser) nutzt dies z.B. für JavaScript. ASLR und NX verhindern so das aktive Ausnutzen eines Speicherüberlaufs durch einen Angreifer.

Verschlüsselung
Da auf mobilen Geräten Geschwindigkeit und Energieeffizienz eine große Rolle spielen, kommt für kryptografische Operationen eine hardwareseitige AES 256 Krypto Engine (Beschleuniger) zum Einsatz, die im DMA-Pfad zwischen Flashspeicher und Hauptspeicher liegt. Während der Herstellung bekommt jedes iOS Gerät einen eindeutigen Geräteschlüssel (Unique ID, UID) und einen Gruppenschlüssel (Group-ID, GID) als 256-bit Schlüssel eingebrannt, die durch keine Software oder Firmware ausgelesen werden kann, sondern lediglich auf das Ergebnis durch Ver- oder Entschlüsselungen Zugriff erhalten. Auf diese Werte wiederum kann lediglich die AES KryptonEngine (siehe Abbildung 1) zugreifen. Apple und auch der Zulieferer führen keine Listen etc. über die UID, so dass diese gänzlich unbekannt sind. Lediglich die GID ist für alle Geräte einer Prozessoren-Familie, bspw. dem Apple A8 Prozessor, gleich und auch bekannt. Durch die UID können verschlüsselte Daten an ein Gerät gebunden werden, so ist z.B. das Dateisystem mit der UID verschlüsselt. Zusätzlich zur Verschlüsselung des Dateisystems bietet das System die Verschlüsselung von Dateien über die Data Protection-Klasse an, welche von System Apps, aber auch von Drittanbieter Apps verwendet werden kann. Wird eine neue Datei erstellt, erzeugt die Data Protection einen neuen 256-bit Dateischlüssel und übergibt diesen an die Hardware-AES Krypto Engine, welche die Datei verschlüsselt. Der Initialisierungsvektor (IV) errechnet sich aus dem Block-Offset der Datei, welcher mit dem SHA1 Hashwert des 256-bit Schlüssel der Datei erstellt wird. Beim Öffnen der Datei erfolgt die Entschlüsselung durch die Metadaten in Kombination mit dem zugehörigen Dateischlüssel. Als Letztes ist die Verwendung eines Passwortschutzes für ein Gerät unabdingbar, erst mit Hilfe dessen wird die Data Protection aktiviert. Besteht das Passwort aus einem sechsstelligen alphanumerischen Code, dauert die Entschlüsselung ca. fünfeinhalb Jahre, wenn ein Versuch ca. achtzig Millisekunden dauert. Ist die Passwortsperre aktiviert, kann ein Angreifer bestimmte Daten nur mit Hilfe des Passwortes einsehen, andernfalls bleiben sie verschlüsselt.