October 06, 2015

Decrypting iOS Firmware and AES Derived Keys (iOS 8.3 on iPhone6)

1. Introduction
We study both the underlying cryptographic algorithms and firmware related vulnerabilities for iOS in protecting against attackers exploiting the mobile device.
  • Review of iOS cryptography and existing attacks against code signing
  • Extracting AES keys for iOS firmware
  • Compromising code sign with either downgraded or patched firmware
2. Summary of Findings
We have analyzed iOS system where cryptography architecture and algorithms are applied, and suggested where and how possibly certain attacks can be exploited against device protection.
We have parsed new iOS firmware format and extracted latest SHSH blobs for firmware code sign. Firmware of new version is not allowed to downgrade to old version beyond Apple's time window. We study the possibility to break that limitation, where device can be boot with either "patched" firmware or downgraded version, both of which thus may contain exploitable vulnerabilities.
We have partially extracted some low-level derived AES keys from iOS firmware. These encryption keys are derived from hardware keys, and can be intercepted if we break the kernel.

3 R&D Findings
3.1 Review of iOS Cryptography Key Hierarchy
We have analyzed iOS system where cryptography architecture and algorithms are applied, and suggested where and how possibly certain attacks can be exploited against device protection. Review on latest iOS security research papers show that AES and Hash/MAC cryptographic algorithms are subtly applied in the code sign design.

Apple has built encryption into the hardware and firmware of its iPads and iPhones. Every iOS device has a dedicated AES 256-bit crypto processor that sits between the flash storage and main system memory. The engine works in conjunction with the SHA-1 cryptographic hash function – which is implemented in the hardware as well -- to reduce overhead for cryptographic operations.

There are two "master keys" for iOS devices.
  • One is called the unique identifier (UID), which is an AES 256-bit key fused into the AES processor. The UID is also called hardware key since it is specific to the device and is not recorded anywhere else. No software or firmware can read it directly. They can see only the results of the encryption and decryption operations. Plus, because the key is burnt into the silicon, it cannot be tampered with or bypassed. Only the crypto engine can access it. As a result, data is cryptographically tied to a specific device and cannot be related to any other identifier or device.
  • Another master key is derived from user's passcode.
The UID key as 256-bit AES key is used to create a key called “key0x89b.” Key0x89b is used in encrypting the device’s flash disk. Because this key is unique to the device, and cannot be extracted from the device, it is impossible to remove the flash memory from one iPhone and transfer it to another, or to read it offline.

Fig.1 iOS cryptography key hierarchy.
The exact mechanisms used to encrypt the storage are complicated as shown in Figure above. General speaking,
  • A random key is generated and used as basis for encrypting the entire disk
  • This key is itself encrypted using key0x89b, and stored in a special form of memory called “effaceable storage”
  • Because key0x89b is tied to the device (being derived from UID), this disk key can’t be decrypted on any other device. The memory chips must stay in the device they were formatted on — unless you extract key0x89b
3.2 Extracting Firmware AES keys
The iPhone device comes with built-in encryption keys, UID and GID. These two hard-coded keys are used only for boot-loader in kernel mode. Although unable to read these hard-coded keys, the iOS running on the device can generate other encryption keys which are used for data protection, keychain encryption, and code sign. We discuss the techniques about extracting those derived AES keys.

Table 1. Derived Keys
Derived KeysFormuaUsage
Key 0x835Key0x835=AES(UID,
Used for data protection.
Key 0x836Key0x836=AES(UID, 0x00E5A0E6526FAE66C5C1C6D4F16D6180)This is computed by the kernel during a restore, but is zeroed out during a normal boot. It is also computed by the Secure Bootloader, and its only known use is to decrypt LLB in NOR. Like 0x835, it is different for each device.
Key 0x837Key0x837=AES(GID,
It is used as the encryption key for IMG2 files.
Key 0x838Key0x838=AES(UID,
Another UID-AES-key-based key, it is used to encrypt everything but LLB in the NOR (iBoot, DeviceTree, pictures).
Key 0x899Key0x899=AES(UID, 0xD1E8FCB53937BF8DEFC74CD1D0F1D4B0)Usage unknown.
Key 0x89AKey0x89A=AES(UID,
It is used as device-specific key to encrypt the SHSH blobs on the device. Used on A4 devices.
Key 0x89BKey0x89B=AES(UID, 0x"183e99676bb03c546fa468f51c0cbd49")It is used to encrypt the data partition key.

Computing Keys on iPhone
Key 0x835 is computed by the IOAESAccelerator kernel service at iOS boot by encrypting a static value 01010101010101010101010101010101 with UID.
UID is a hardware encryption key embedded in the iPhone application processor AES engine and it is unique for each device. iOS running on the iPhone cannot read the hardware key (UID) but it uses the key to compute Key 0x835 in kernel mode. UID is not accessible to user land process.
This restriction can be bypassed by patching the IOAESAccelerator kernel service. We developed some tools based on ios-dataprotection project.
  • kernel_patch.c: Patch kernel so we can use IOAESAccelerator in userland
  • device_infos.c: extract encryption keys (partial)
  • bruteforce.c: extract data protection class keys stored in the system keybag. Class keys are protected with passcode key and key 0x835. The script bruteforces the passcode and grabs the passcode key. Later it extracts the keys from keybag and stores the result in a plist file.
Here is the keys we partially extracted:
Dkey: <string>d379daef24f392fc5bfe94698e758bf114ae296cbdc3eedded33392bae5b3ba8</string>
ECID: <integer>5116457374519334</integer>
EMF: <string>f67b3fd593717ba3baa74b2fd6718903da2676fcf470a9f8f20eeffafa28ea54</string>
Salt: <string>90deb1a5f99c727345992e57e667edf51999d3c6</string>
dataVolumeUUID: <string>eea7c772f92b4020</string>
Udid: <string>af8e103659fedf12c63d3861c61c1870faafb06a</string>
Uuid: <string>9c572cf33a8c490da02d4523ce42893f</string>

3.3 Interception of Firmware Code Sign
iOS firmware of new version could be downgraded to old version with Apple's time window. Beyond that given time window, iOS firmware is unable to recover to old version. We take a deep look into the technique to break that limitation. If it comes possible, one can boot the iOS device with either "patched" firmware or downgraded version, both of which thus may contain exploitable vulnerabilities.
In order to extract firmware decryption key, we firstly look into IPSW firmware structure:
Fig.2 IPSW firmware package structure.

New IM4P Format
IMG4 firmware format is not widely studied although SL8900/IMG3 format is well-known. No existing decryption key is available for iPhone6 with iOS 8.3 yet. The file is an DER encoded ASN.1 object and structured as follows:
Fig.3 IMG4 data encoding structure.
The IMG4 header can be parsed according to following definition:
typedef struct {
uint8_t* magic;
uint8_t* type;
uint8_t* contents;
uint8_t* data;
int dataSize;
uint8_t* kbag;
int kbagSize;
AppleImg4_t *asn1;
} img4_file_t;

Here is an example IMG4 header bytes:
30, Type , 0x0011 0000:   P/C constructed, sequence
83 , Length = 125
8E, Type, 0x1000 1110: context,
16, Type tag indicating IAString
04, Length
49, 4D 34 50
: “IM4P”

Fig.4 A snapshot of IMG4 header.

Firmware keybag structure
Apple's IMG4 security scheme uses a data format called a KBAG, which is stored at the bottom of a firmware file. Specifically, the kernel uses the GID Key to decrypt encIV and encKey, then uses that key and IV to decrypt the DATA section of the file (the code itself). Here is the definition of Kbag structure (AES-128):

typedef struct Unparsed_KBAG_256 {
uint32_t magic;       // string with bytes flipped ("KBAG" in little endian)
uint32_t fullSize;   // size of KBAG from beyond that point to the end of it
uint32_t tagDataSize; // size of KBAG without this 0xC header
uint32_t cryptState; // 1 if the key and IV in the KBAG are encrypted with the GID Key
// 2 is used with a second KBAG for the S5L8920, use is unknown.
uint32_t aesType;     // 0x80 = aes128 / 0xc0 = aes192 / 0x100 = aes256
uint8_t encIV[16];   // IV for the firmware file, encrypted with the GID Key
uint8_t encKey[32];   // Key for the firmware file, encrypted with the GID Key
} UparsedKbagAes256_t;

Fig.5 A sample by extracting kbags by Parsing IM4 File
The firmware decryption key may be further extracted from kbags.

Extracting SHSH blobs
Users are not allowed to downgrade (or upgrade) to iOS 8.3 after Apple closes the firmware signing window for iOS 8.3. Instead, they have to settle for whatever firmware Apple is signing, which is usually the latest. We firstly extract SHSH blobs to be prepared for possible downgrade ability.

–Step 1: Download latest TinyUmbrella and run.
–Step 2: Connect iOS device (it doesn’t have to be jailbroken)
–Step 3: Wait as TinyUmbrella fetches and saves blobs to file under “~/.tu/.shsh/” directory in Mac.
Fig.6 Extracting iOS8.3 or 9.1 SHSH blobs.

3.4 Other Attacks

Defeating Fairplay Encryption for iOS App binaries
The decryption of iOS binaries can be achieved by launching the application in a GDB and extracting the unencrypted executable code. Although encryption and code signing were used, there is no much difficulty to recover the real executable code. There are already some tools like "Dumpdecrypte" which can automatically do all the above steps.

Cryptographic Function Hooking
One example is for networking, attacker can pay more attention to the Object-C crypto library, CCCrypt. Attacker can hook crypto functions on application layer without knowing much about the implementation of iOS cryptography.

4 Proposed Follow-Ups
We will further work on extracting firmware AES keys that are basis for sequential code signings.
We will further work on intercepting code sign procedure with either downgraded or patched firmware.

[1] iOS security report, 2015
[2] iPhone data protection in depth, 2014
[3] Reflections on trusting trustzone, 2014
[4] Apple iOS 4 Security Evaluatio, 2011
[5] Evolution of iOS data protection and iPhone forensics, Blackhat 2011
[6] iPhone data protection open project, http://code.google.com/p/iphone-dataprotection/
Attached Slides: Cracking iOS firmware keys -nlog2n