Neben der Hardware-Verschlüsselung bietet iOS noch eine optionale Datei-Verschlüsselung. Bei iOS 7 hat Apple deren Einsatz für Apps automatisiert. Allerdings genehmigt sich Apple selbst großzügige Ausnahmen für eigene Anwendungen.
Das iPhone bietet eine Hardware-Verschlüsselung, die komplett transparent als Black-Box arbeitet. Konkret ver- und entschlüsselt diese Crypto-Box alle Daten während des Transports zwischen Speicher und CPU. Wer also den Flash-Speicher auslötet und untersucht, wird nur unlesbare, AES-verschlüsselte Daten sehen.
Wer hingegen die iPhone-CPU benutzt, um auf die Daten zuzugreifen, sieht immer den ungeschützten Klartext. Das gilt auch, wenn es einem Angreifer gelingt, seine Spionage-Tools da irgendwie einzuschleusen und auszuführen. Dazu später mehr.
Der benutzte Schlüssel ist individuell für jedes Gerät und lässt sich nicht auslesen. Primäre Aufgabe dieser Verschlüsselung ist es, ein schnelles und zuverlässiges Löschen des Flash-Speichers zu ermöglichen. Statt mühsam viele GByte Flash zu überschreiben, wirft die Crypto-Box ihren Schlüssel weg. Die im Flash verbleibenden, verschlüsselten Daten sind damit wertlos; die Original-Daten gelten als gelöscht.
Data Protection
Mit iOS 4 hat Apple eine zweite Verschlüsselung namens Data Protection eingeführt, die sich auf einzelne Dateien oder Keychain-Einträge bezieht. Dabei werden die Objekte mit einem Schlüssel verschlüsselt, in die der Passcode des Geräts mit eingeht – so einer gesetzt ist natürlich. Selbst, wenn ein Angreifer das Gerät unter seiner Kontrolle hat und darauf beliebigen Code ausführen kann, kann er die damit gesicherten Daten nicht lesen, wenn er den Passcode nicht hat.
Darüber hinaus verwendet Data Protection auch einen in der Crypto-Box abgelegten Schlüssel, den man nicht aus dem iPhone heraus bekommt. So ist sichergestellt, dass ein Angreifer nicht einfach die verschlüsselten Daten kopiert und dann auf seinem High-Performance-Cracking-Cluster alle möglichen Passcodes durchprobiert, bis er den Klartext hat. Einen solchen Brute-Force-Angriff kann er zwar immer noch probieren, aber der in der iPhone-Hardware versiegelte Schlüssel besteht aus 256 zufälligen Bits. Und bis er alle möglichen 256-Bit-AES-Schlüssel durchgetestet hat, gehen einige Jahrtausende ins Land.
Data Protection bietet verschiedene Schutzklassen, die etwa entscheiden, ob die Daten nach einem Neustart und der ersten Eingabe des Passcodes dauerhaft verfügbar sind, oder ob sie im gesperrten Zustand auch wieder gesichert werden. Dann stehen die Klartextdaten erst nach einer erneuten Eingabe des Passcodes -- beziehungsweise dem Entsperren mit dem Fingerabdruck – wieder zur Verfügung. Das sind dann die Klassen NSFileProtectionComplete für Dateien und kSecAttrAccessibleWhenUnlocked für Keychain-Einträge.
Das Problem dieser Datei- und Keychain-Verschlüsselung: Sie ist optional; der Entwickler einer App muss sie für seine Daten explizit anfordern, indem er etwa eine Datei mit der Klasse NSFileProtectionComplete anlegt. Manche Entwickler stellten tatsächlich bereits auf diesem Weg sicher, dass etwa die zentrale Datenbank ihrer App nur dann lesbar ist, wenn das Gerät nicht gesperrt ist; doch die Mehrzahl ignorierte diese Sicherheitsfunktion. Auch viele Apple-Anwendungen verzichteten auf den zusätzlichen Schutz.
iOS7
Mit iOS 7 aktiviert Apple diese Verschlüsselung jetzt zwangsweise. Konkret werden alle Dateien, die eine App in den Unterordnern Documents/ und Library/ mit der Schutzklasse NSFileProtectionCompleteUntilFirstUserAuthentication versehen. Diese sorgt dafür, dass die Daten erst verfügbar sind, wenn sich der Anwender nach dem Start des Geräts das erste Mal mit seinem Passcode angemeldet hat. Der Fingerabdruck genügt dabei übrigens nicht – bei einem Neustart ist tatsächlich immer der komplette Code einzugeben.
Diese Verschlüsselung soll vor einem Angreifer schützen, der ein ausgeschaltetes iPhone in die Finger bekommt. In allen Modellen bis zum iPhone 4 enthält der fest im System verankerte Boot-Code eine Sicherheitslücke, die es erlaubt, auf diesen Geräten eine eigene, passend manipulierte Firmware zu starten. Dieses Problem lässt sich auch nicht durch ein Firmware-Update beheben. In den Nachfolge-Modellen ist zwar bislang keine solche Lücke bekannt – aber niemand traut sich, darauf zu wetten, dass es keine mehr gibt.
Doch selbst mit einer solchen Boot-ROM-Lücke, die den Zugang zum iPhone trotz Passcode ermöglicht, sind via Data Protection gesicherte Daten nicht lesbar. Sie liegen immer noch in verschlüsselten Dateien und sind somit ohne den Passcode wertlos. Es lohnt sich also, einen möglichst langen Passcode zu verwenden, der dem oben gezeigten Angriff stand hält.