Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
2 passcode locks
source | link

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.

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.

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.
1
source | link

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.