iOS 5 data protection updates

iOS 5 was released this week, and introduced some changes to the data
protection features we described at HITB Amsterdam. This post
highlights the updates made since iOS 4.

LwVM partition scheme

The GPT partition table used on iOS 4 was replaced by Apple's
proprietary Lightweight Volume Manager (LwVM), previously only used on
Apple TVs. This scheme was reversed earlier this year by Bluerise of
the openiBoot project. This new partition table needs to be taken
into account when computing the data partition logical block address
(LBA), required to correctly decrypt raw disk images.

File encryption changes

With the release of Mac OS X Lion, the HFS content protection code (used
in iOS) is now part of the open-source XNU kernel tree (code and
headers).However in iOS 5, the CP_CURRENT_MAJOR_VERS version
number is now 4, and the cp_xattr structure has additional padding
between the key_size and persistent_key fields. More
importantly, a change was introduced in the Initialization Vectors
computation for data forks encryption. To compute the IV for a block in
a file data fork, the input to the IV generator is now the block offset
in the file fork (instead of the block LBA on iOS 4), and the resulting
IV is then encrypted (AES128) with the "IV-key" to give the actual
IV. The "IV-key" is unique per-file and computed using the following
formula:

IV-key=SHA1(filekey)[:16]

Also, directories can now have their protection class set (through the
F_SETPROTECTIONCLASS fcntl), and by default new files will inherit
their parent folder protection class.

New protection classes

The first class has the same semantics as the AfterFirstUnlock
keychain accessibility setting that was available on iOS 4. Files that
use it can only be accessed after the device has been unlocked at least
once.The NSFileProtectionCompleteUnlessOpen class is more complex
and allows the following:

keep protected files open even if the device becomes locked: simply
keeps the file key in memory and does not block operations on the
file descriptors

create protected files even if the device is locked (and some class
keys are not accessible)

For this class, the persistent file key is secured using Elliptic curve
Diffie Hellman over D. J. Bernstein's Curve25519. The following
steps describe the creation of a file using this protection class:

file key randomly generated (used to encrypted file contents)

file public/private keypair (Curve25519) generated

shared secret computed using file private key and system keybag
public key (PBKY)

shared secret is hashed (SHA1) to get wrapping key

file key is stored wrapped in the cprotect extended attribute, along
with file public key

file private key is dismissed (erased from RAM), shared secret (and
thus file key) can only be recomputed using the file public key and
the system keybag private key (class key protected by passcode). The
file key stays in memory as long as the file is open to allow access
even if the device is currently locked.

It looks like this new class would be useful for securing pictures,
which can now be taken at the lockscreen, but apparently only the Mail
application uses this class to secure e-mails downloaded in the
background.

Keychain

The keychain database has been modified significantly in iOS 5. Now, all
item attributes are encrypted (account, service, etc.) instead of just
the data field (kSecValueData). All the attributes are regrouped in
a dictionary, serialized as a binary plist and stored encrypted in the
data column. The operating mode of the AES cipher was also changed from
CBC to GCM (Galois counter mode) with integrity protection. The
database columns for attributes that were previously in clear-text are
still there, but now only hold SHA1 hashes of the attributes values (to
allow queries without having to decrypt the whole table).We updated the
Keychain Viewer tool, which now supports iOS 3, 4 and 5.

Keybag

Keybags generated on iOS 5 now have the version attribute set to version
3. The only notable changes are the addition of the PBKY tag
[STRIKEOUT:in the header] for asymmetric keys (holds the Curve25519
public key for the NSFileProtectionCompleteUnlessOpen class), and
the KTYP tag for each class key: KTYP=0 means regular AES wrap
key, KTYP=1 means Curve25519 [STRIKEOUT:private] key. Only class key
number 2 (NSFileProtectionCompleteUnlessOpen) has KTYP=1.The
passcode derivation algorithm was not modified since iOS 4.3.

Escrow records

Escrow records are property-list files that contains passcodes for
escrow keybags (stored off-device, for instance in iTunes or on an MDM
server). Those files are now protected with the new
UntilFirstUserAuthentication protection class (the
/var/root/Library/Lockdown/escrow_records/ folder has its protection
class set to 3). This effectively blocks the "escrow keybag attack"
that was possible on iOS 4, as an attacker cannot read those files
without knowing the device's passcode, and thus cannot bypass the
passcode using an escrow keybag.

Forensics tools update

We just updated our open-source forensics tools to support iOS 5.
A few months ago we also added an adaptation for iOS of the HFS journal
carving recovery technique presented by Aaron Burghardt and Adam J.
Feldman in 2008. This technique can only recover a limited set of files
(or even nothing at all), but the simple Python implementation of HFS+
provided (read-only) can be useful for experimenting with the
file-system internals.