28

Following on from this question, what resources are available relating to the technical specifics of how apple implement encryption on their iOS 4.x series devices?

The Apple marketing material here, states that "iPad offers 256-bit AES encoding hardware-based encryption to protect all data on the device. Encryption is always enabled and cannot be disabled by users."

Using a custom RAMDisk to boot up an old iOS device it was possible to see the contents of user files in the clear which means in some way if they are encrypted the process of booting the custom OS is allowing for decryption of the data to happen.

Community
  • 1
Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • 4
    A quick observation: the encryption is hardware-dependent, not iOS version. For instance the iPhone 3G, 3GS and 4 all run iOS 4 and all have different encryption capabilities. –  Dec 11 '10 at 11:58
  • I am also interested in this subject. From what I have learnt so far, setting a Pin provides an "additional / secondarely layer" of encryption to some (but not all) app data like e.g. Mail. Does someone knows which data is also "secondarely encrypted" besides the mail data? –  Nov 09 '11 at 09:03

1 Answers1

27

All shipping iOS devices (with the possible exception of the AppleTV, which doesn't have third party apps) have two filesystems, implemented as two partitions on the flash storage. The first is mounted read-only and just contains the OS. The second contains user data: the installed apps, and their supporting data including documents and caches. This second partition, on the iPhone 3GS, iPhone 4, 3rd and 4th generation iPod Touch and the iPad only is encrypted with a key that is managed by a hardware encryption chip on the device's PCB. This key cannot be leaked out of the chip directly; though I don't know if there are any side-channel attacks.

When the device is turned on, the encryption chip unlocks the second partition. That means that this encryption only protects the data at rest. In fact, it's designed to support quick remote wiping: when the device receives the remote wipe signal it just resets the key.

iOS 4 separately uses the same encryption facility to support its file protection API. Files store with the NSFileProtectionComplete option are encrypted on the filesystem, and the decryption key is only available while the device is unlocked. That means that when you lock the screen, even if an app has a background component that is still running, the protected files cannot be accessed.

In the case of protected files, if the user has a passcode configured then the passcode and the device key are combined to derive the protection key. Actually, it's a little more complex: each file is protected by a separate key. These keys are protected by a class key. The class key is protected by a key derived from the hardware key and the passcode. This gives you the following properties:

  • when the device is locked, the files are completely unavailable because the kernel doesn't have the passcode with which to generate the unlock key.
  • brute force discovery of the user's passcode must be done on the device, which slows down attempts.
  • remote wiping still involves just resetting the device key.
  • 3
    Ahh I see, thanks for that. So essentially attacks where a custom OS is loaded onto the device (like using limera1n), will bypass the first class of protection as by the time they're inserted into the boot process the partition is unlocked, but physical attacks on the flash memory would fail (unless the key could be retrieved in some way) – Rory McCune Dec 12 '10 at 15:06
  • 3
    @Rory: yes. So jail broken phones can still access the data (and a quick scp -rp root@iPhone:/* . lets you get all of it in that case). –  Dec 12 '10 at 17:58
  • @Graham, do you have a reference for your description. I am very much interested in this with more details. Particularly of what I am still not getting: -will the key for decrypting be compromised? If I use for iOS4 apps this same encryption API but do encrypt the confidential data on my own, will that be also not sufficient? Many thanks – Phoenician-Eagle Mar 13 '11 at 15:10
  • 1
    @Paul: A good reference for the iOS filesystem setup is "iPhone Forensics" from O'Reilly: http://oreilly.com/catalog/9780596153595 The encryption info can be found in Apple's technical papers and developer documentation. –  Mar 13 '11 at 15:43
  • 1
    Graham, I think it is worth mentioning that NSFileProtectionComplete & co are only really effective when data protection is enabled and the device has a PIN or passphrase set (in other words the key involved is derived from a user known secret not stored on the device - hence why the data is not available when the device is locked). – frankodwyer Apr 20 '11 at 20:06
  • @frankodwyer a valid point, but remember that this basically gives you "how much do I care about my personal data?" If you require a password in your app, then the user can still choose a poor password if they don't care much. –  Jun 09 '11 at 19:03
  • Are the files then encrypted only when the device is off or locked? – Thomas Aug 02 '13 at 06:50