This should help clear up the common misconception that data is encrypted and secured in iOS. While it’s true that iOS does sport an encrypted file system, that file system is virtually always unlocked from the moment the operating system boots up, as the OS (and your applications) need access to it. Even when the device is locked with your PIN or passphrase, the encrypted file system is readable to the operating system – what this means is that your data is NOT encrypted using an encryption that depends on your password – at least for the most part. Apple adds a second layer of encryption on top of this file system called Data-Protection. Apple’s Data-Protection encryption has the ability to protect a file while the device is locked by encrypting it with a key that is only available when you’ve entered your PIN or passphrase. While a PIN can be brute forced, a passphrase is much stronger.
So what’s the problem? Well, as of even the latest versions of iOS, the only files protected with this secondary encryption is your mail index, the keychain itself, and third party application files specifically tagged (by the developer) as protected with Data-Protection. Virtually everything else (your contacts, SMS, spotlight cache, photos, and so on) remain unprotected. To demonstrate this, I’ve put together a small recipe you can run on your own jailbroken device to bypass the lock screen. You can then use the GUI to browse through all of the data on the device, without ever providing your PIN. The only thing you’ll not be able to access are the files I’ve just mentioned. This lock screen bypass isn’t really a vulnerability in and of itself; it’s just one of many ways I can demonstrate to you that you don’t need a passphrase to view a vast majority if the data on your phone.
To demonstrate this, jailbreak your iOS device and install ssh and cycript through Cydia.
Protect your device with a PIN or passphrase, and instruct iOS to require the passcode immediately. Hit the power button and slide to unlock your device. You’ll see that it requires a passphrase. Next, ssh into the device’s IP address. Now use cycript to issue the commands shown below (emboldened).
root# cycript -p SpringBoard
cy# SBDeviceLockController.messages['isPasswordProtected'] = function() { return NO; }
function () {return NO;}
cy# [ [ SBDeviceLockController sharedController ] attemptDeviceUnlockWithPassword: nil appRequested: YES ]
1
Once completed, hit cancel on the passcode screen, and then slide to unlock again. The device will open right up and you’ll have GUI access. The lock screen is merely a screen saver lock, which as most people know doesn’t equate to real security anyway.
Under certain conditions, this is one technique law enforcement forensic engineers are able to perform to unlock a device they’ve seized, if all other forensic techniques fail. Apple is also capable of doing this, however to my knowledge they do not. Under a subpoena, Apple will, however, copy off the same readable contents of the file system if given a warrant. The data that law enforcement gets is the same that you’re able to see when you perform this test yourself. Apple doesn’t need a jailbroken device to do this either, as they have code signing authority on any device they’ve manufactured. Who else can pull this off on a non-jailbroken device? Certain levels of federal government likely have access to iOS code execution exploits as well, especially given a private government contractor paid $250,000 recently for access to such an exploit. There are possibly exploits in the wild as well that can gain code execution on an iOS device. This kind of data exposure affects every model iOS device and operating system. The real question is, who do you want your data to be secured from? Your typical snot-nosed TSA agent certainly isn’t going to have a device capable of scraping data off of your phone, however both hackers and government might. If you jailbreak your device, it’s possible that a much larger pool of people will as well.
Of course, this is nothing new. People who work in this field have been aware of it for years, as has Apple. Apple could redesign the operating system to be more secure (and I hope they do at some point). The difference between iOS’ encryption, and File Vault is that the operating system itself cannot boot until you enter your File Vault password – it is taken whenever the device is booted. If Apple were to encrypt the file system keys stored in effaceable storage (namely, the Dkey) with a complex passphrase that only YOU know, and require it in order to boot the device, then security would be about on par with that of File Vault. In addition to this, you could manage with a much simpler password or PIN for normal use, because the device is protected with the more secure passphrase in order to boot (almost ever forensic tool ever designed for iOS requires the device to be rebooted in order to image it). These design changes aren’t an overnight easy fix that you should expect to find any time soon, however. True full disk encryption is something I’d love to see on the iPhone and iPad, but it’s not here yet.