By jean » Friday 14 October 2011, 14:36 - Reverse engineering
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
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
Two new protection classes for files were added in iOS 5:
NSFileProtectionCompleteUntilFirstUserAuthentication(class C, CLAS=3)
NSFileProtectionCompleteUnlessOpen(class B, CLAS=2)
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.
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.
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.
Keybags generated on iOS 5 now have the version attribute set to version 3. The only notable changes are the addition of the
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
private key. Only class key number 2 (
The passcode derivation algorithm was not modified since iOS 4.3.
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.