Apples Security-Konzept in der Kritik
Wie sicher ist die IOS-Verschlüsselung?
Auf mobilen Endgeräten haben unlängst Geräteverschlüsselungen zum Zugriffsschutz ähnlich der klassischen Festplattenverschlüsselungen mit Pre-Boot Authentication (PBA) Einzug erhalten. Apples IOS hat hier die Vorreiterrolle eingenommen und integriert eine umfassende Geräte- und Dateiverschlüsselung inklusive Secureboot-Schutz für die Bootkette (aber ohne Passworteingabe). Zuletzt war Apples Verschlüsselung jedoch nach einer Untersuchung von Cirosec in die Diskussion geraten.
Apple hat seit der Einführung des Iphone 3GS (und Ipad) eine hardwarebasierte Verschlüsselung in seine IOS-Endgeräte (Idevices) eingebaut. Zwischen dem Arbeitsspeicher und der Flash-Festplatte sitzt eine Hardware-Verschlüsselungseinheit, die sicherstellt, dass der Flash-Speicher vollständig mit einem 256-Bit-AES verschlüsselt ist (Bild 1). Der File-Systemschlüssel ist nicht auslesbar in Hardware gespeichert und steht automatisch zur Entschlüsselung zur Verfügung, sobald das Gerät startet.
Sinn und Zweck dieser Dateisystem-Verschlüsselung ist nicht (!) der Zugriffsschutz, sie dient vielmehr dem schnellen Löschen der Geräte. Um den Flash-Speicher zu löschen, wird einfach der Schlüssel für die Verschlüsselung des Flash-Speichers durch einen neu generierten Schlüssel überschrieben. Um dennoch auf "alte" Daten zugreifen zu können, müsste ein Angreifer daher entweder den Schlüssel erraten oder AES gebrochen werden.
Verschlüsselung von Dateien
Zusätzlich zur Verschlüsselung des Flash-Speichers hat Apple mit IOS 4 eine Dateiverschlüsselung (File Data Protection) eingeführt. Dabei werden einzelne Dateien mit individuellen Schlüsseln (File Keys, ähnlich einem Session Key) verschlüsselt und der Schlüssel mit einer Art Gruppenschlüssel (Class Key) für das Dateisystem verschlüsselt. Das grundlegende Konzept ähnelt dem von Microsofts Encrypted Filesystem (EFS) oder Utimacos Lancrypt (heute Sophos). Bild 2 zeigt den organisatorischen Aufbau der Flash- und Dateiverschlüsselung in IOS. Der Vorteil einer derartigen mehrstufigen Verschlüsselung ist die Vereinfachung einiger Prozesse: Ändert der Benutzer seinen Passcode, ist nur der Class Key neu zu verschlüsseln. Wird eine Datei mit einem anderen Class Key verschlüsselt, muss anstelle der kompletten Datei nur der File Key umgeschlüsselt werden. Bei der Herstellung eines Idevices werden zwei Schlüssel fest "in Silizium gebrannt": der UID- und der GID-Schlüssel (Unique-ID, Group-ID). Der UID-Schlüssel ist für jedes Gerät unterschiedlich und lediglich auf diesem Gerät verwendbar. Laut Apple-Dokumentation wird er weder von Apple gespeichert, noch lässt er sich auslesen. Er spielt eine zentrale Rolle beim Schutz des File-System-Schlüssels sowie der Class Keys und erlaubt es, Daten gezielt an ein Gerät zu binden. Dies kommt zum Beispiel beim Backup für Teile des IOS-Schlüsselbundes (Keychain) zum Einsatz, damit sich Daten nur auf dem Quellgerät wiederherstellen lassen. Der UID-Schlüssel könnte aber auch beim Kopierschutz von Nutzen sein, um Inhalte an ein bestimmtes Gerät zu binden. Würde Apple den UID-Schlüssel darüber hinaus mit einem Password versehen, hätte IOS eine starke PBA.
Der GID-Schlüssel wiederum ist allen CPUs einer Klasse (zum Beispiel allen A7-CPUs) gemein und Apple bekannt, um zum Beispiel zusätzlichen Schutz bei Updates zu bieten. Auch der GID-Schlüssel lässt sich auf dem Gerät selbst nicht auslesen.
Alle weiteren Schlüssel, die auf IOS-Geräten Anwendung finden, werden mit einem Zufallszahlengenerator basierend auf Yarrow erzeugt. Als Entropie dienen dabei das Interrupt Timing während des Bootprozesses sowie Werte diverser Sensoren, sobald das System gestartet wurde. Da Apple keine weiteren Details offengelegt hat, lässt sich die Qualität der Zufallszahlen nicht beurteilen. Allerdings wirkt sich gerade die "Qualität" von Zufallszahlen massiv auf die Sicherheit von kryptografischen Schlüsseln aus.
Bis IOS 6 konnte eine Anwendung selbst entscheiden, mit welchem Schlüssel eine von der Anwendung erzeugte Datei verschlüsselt wird. Dabei geht es um Dateien, die in den Verzeichnissen "documents/" und "library/" angelegt werden. Jede Datei wird dort mit einem individuellen Schlüssel (File Key) verschlüsselt. Dieser File Key wird mit einem Class Key verschlüsselt und anschließend in den Metadaten der jeweiligen Datei gespeichert. IOS unterscheidet dabei die folgenden vier Class Keys:
NSFileProtectionComplete: Der Schlüssel ist nur verfügbar, wenn der Benutzer am Sperrbildschirm seinen Passcode eingegeben hat.
NSFileProtectionCompleteUnlessOpen: Der Schlüssel ist nur verfügbar, wenn das Gerät gesperrt ist.
NSFileProtectionCompleteUntilFirstUserAuthentication: Dieser Schlüssel ist verfügbar, sobald der Benutzer nach einem Neustart des Geräts erstmalig seinen Passcode eingegeben hat.
NSFileProtectionNone: Dies war bis IOS 6 der Default-Schlüssel. Er ist immer verfügbar, sobald das Gerät eingeschaltet ist.
Neuerungen mit der Einführung von IOS 7
Mit der Einführung von IOS 7 wurde das Verfahren für die Dateiverschlüsselung umgestellt. Seit IOS 7 werden alle Dateien per Default mit dem NSFileProtectionCompleteUntilFirstUserAuthentication-Key verschlüsselt. Es scheint aber möglich zu sein, dass eine Anwendung nach wie vor einen der anderen Schlüssel auswählt. Apple verwendet laut Cirosecs Untersuchung für das eigene Adressbuch, den Kalender, Lesezeichen, Notizen und SMS/Imessage keine Verschlüsselung, also vermutlich den Schüssel NSfileProtectionNone. Nach den Beschreibungen zur IOS-Verschlüsselung von Apple werden die Daten zwar verschlüsselt, sie sind jedoch nach dem Starten des Geräts direkt zugänglich.
Führt man eine Dateiverschlüsselung neu ein oder überarbeitet deren Konzept und aktualisiert damit existierende Systeme, auf denen bereits unverschlüsselte Daten vorhanden sind, stellt sich die Frage, wie mit diesen zu verfahren ist. Es gibt mehrere Möglichkeiten:
Alle existierenden Daten werden automatisch ver- oder umgeschlüsselt (Initialverschlüsselung).
Alle Daten bleiben unverschlüsselt/mit dem "alten" Verfahren verschlüsselt, werden aber bei der ersten Bearbeitung, wenn sie neu geschrieben werden, automatisch ver- oder umgeschlüsselt.
Alte Daten bleiben dauerhaft unverschlüsselt/mit dem "alten" Verfahren verschlüsselt, nur neue Daten folgen dem neuen Standard. Apple hat sich bei der Umstellung des Verschlüsselungskonzepts wohl vorerst für diesen Weg entscheiden. Es bleibt abzuwarten, ob der Hersteller diese Entscheidung noch revidiert.
Bei einem Update auf IOS 7.0.4 bleiben nun alle Anwendungsdaten, die zuvor mit dem NSfileProtectionNone-Schlüssel geschützt wurden, weiterhin direkt nach dem Gerätestart zugreifbar. Eine Umschlüsselung entsprechend der neuen IOS 7-Policy auf den NSFileProtectionCompleteUntilFirstUserAuthentication-Schlüssel findet nicht automatisch statt. Eine App, die bisher den NSfileProtectionNone-Schlüssel verwendet hat, muss man daher deinstallieren und anschließend neu installieren, damit ihre Daten verschlüsselt werden.
Die Deinstallation impliziert allerdings den Verlust aller App-Daten, sodass alle Daten im Anschluss neu einzuspielen sind. Aus Unternehmenssicht ist daher ein gewisser Aufwand erforderlich, um den aktuellen Schutzstandard von IOS 7 effizient nutzen zu können. Je nachdem, wie IOS-Geräte im Unternehmen eingebunden sind, ist eine Neuinstallation mit IOS 7 vermutlich nicht nur die sauberste, sondern auch die schnellste Lösung.
Auswirkungen
Die Auswirkungen der fehlenden automatischen Umschlüsselung hängen von den Zugangsmöglichkeiten eines Angreifers auf das Gerät ab. Sobald ein Angriff bekannt wird, der den prinzipiellen Zugriff auf Dateien erlaubt, die mit dem NSfileProtectionNone-Schlüssel geschützt wurden, lassen sich diese Daten nach dem Systemstart auslesen. Cirosec zum Beispiel hat für seine Untersuchung den "limera1n"-Exploit auf einem Iphone 4 mit IOS 7.0.4 verwendet, der das Laden einer belieben RAM-Disk erlaubt.
Lesen Sie mehr zum Thema
