Perfect Acquisition Part 2: iOS Background

 

Welcome to part 2 of the Perfect Acquisition series! In case you missed part 1, make sure to check it out before continuing with this article. In this section, we will dive deeper into iOS data protection and understand the obstacles we need to overcome in order to access the data, which in turn will help us accomplish a Perfect Acquisition when certain conditions are met.

Let’s start by taking a look at how iOS data protection works. More specifically, we will limit ourselves to iOS devices that do not have a security co-processor, i.e., only devices without SEP. Therefore, for now, we will consider the following devices:

By doing so, we are working with the following properties:

All of these devices have a hardware crypto co-processor with fused encryption keys. The key that we’re interested in is called UID key. The important thing to know is that the key cannot be read from software, but it is possible to ask the crypto engine to encrypt or decrypt something with those keys.

The data protection mechanisms used in various Apple devices evolved a lot over time.

There is no disk encryption. If you remove the flash, you should be able to read it directly.

Disk encryption of the data partition was introduced. Note: other partitions are not encrypted, but also don’t contain user data.

The UID key is used to derive the so called 0x89B key, which is used to protect the EMF key. The EMF key is used to encrypt the whole data partition. It is generated freshly each time you erase-restore your device and it is stored in a special area in the flash, called the effaceable storage, which is designed for fast and secure wipe. If you wipe the effaceable storage and delete the EMF key, data can no longer be decrypted.

This provides two security mechanisms:

This means that you now need to execute code on the device to get the data, because you also need to access the 0x89B key (or access the EMF key directly).

iOS 4 came with a major security upgrade incorporating the user passcode tightly in the security model (previously it was not used for encryption). The so called SystemKeybag was introduced which stores 11 different class keys. Each file on the data partition is encrypted with its own key, which in turn is encrypted with one of the class keys. The class determines when the file can be accessed. For example class A (key 1) is only accessible when the device is unlocked (with the passcode), while class C (key 3) is always available after the user unlocked the device at least once after boot (we call this AFU After First Unlock).

The difference between the classes isn’t too relevant for us here, the important part is that when the keys are not accessible they are locked. To unlock the class keys you need the passcode key, which is derived from the user passcode (entered at the lock screen), as well a the UID key.

This means in order to access the user data you first need to know the user passcode and then with the help of the UID key derive the passcode key, which you can use to unlock the class keys stored in the System Keybag, which you can then use to unlock individual file keys which finally let you access individual files.

In addition, the System Keybag itself is also encrypted with a file key, which in turn is protected by the class D (key 4) key. The class D key is special, as it is not stored in the System Keybag, but is first encrypted with the so called 0x835 key and then stored in the effaceable storage next to the EMF key. The EMF key is still used, but now only protects the filesystems metadata and not file contents anymore.

There are a few more keys and steps involved, but the gist is that you now need the passcode key to access user data, which you have to generate on device due to the requirement of the UID key.

The main new security mechanism is that you need to know the user passcode in order to access the data. While it is possible to crack the passcode, this needs to be done on device and thus the speed it limited. It is not easily possible to do offline cracking on a GPU cluster.

The following iOS versions shipped small improvements to the model and spread the use of stronger protection classes to more files, but without the introduction of the SEP co-processor and the APFS filesystem (which are both out of scope here), no major changes occurred to the scheme.

The scheme above might sound confusing and complicated, but essentially it boils down to needing three things.

We will consider the acquisition to be a Perfect Acquisition if we manage to acquire all of those three things while meeting the following conditions:

Admittedly, this already looks like a fairytale, since clearly nobody is doing that in practise. But let’s take a look at what would be needed for a truly perfect acquisition.

Let’s tackle the first and most important point: Can we get a dump of the data without violating any of the constraints above? Yes, and surprisingly, the solution is much simpler than you might think. We can desolder the flash and read its contents. This will give us two things: first, the actual storage dump, and second (if done correctly), the effaceable storage containing the (encrypted) keys we need. At this point, we don’t care about what happens to the device anymore because we can be sure that nothing tampered with the data, and we can easily perform repeatable reads of the flash. Technically, we don’t even need to put the flash back. Thus, if we never actively modify the flash ourselves, we can be sure that nothing else ever modifies it.

At the root of the security of an iOS device is the UID key, which is the only thing left in the device if we desolder the flash. Accessing the UID key allows us to perform all other operations offline. While it has been shown that retrieving the UID key is possible in some cases using techniques such as side-channel attacks or decapping the SoC and reading the bits with a microscope, such approaches are too expensive and outside the scope of most use cases.

Instead, a simpler approach is to execute code on the SoC and ask the crypto processor to use the UID key and derive all necessary keys. In this blog post, we have covered deriving the 0x835, 0x89b, and EMF keys, all of which depend on the UID key as the only unknown variable. It is technically possible to do this without putting back the flash, and since the flash is the only place the device can store relevant data persistently, there is no need to worry about accidentally modifying the data even if unknown software is run. Furthermore, there is no risk of software providing false keys, as they either work or do not work. In the case of AES, which is what we are dealing with here, there is no such thing as a “man in the middle” possibly giving out a malicious key providing incorrect data.

The strategy here is the same as with the other keys described previously. If we have the UID key, we can derive the passcode key offline. If we don’t have the UID key, we can ask the device to derive it for us. If we already know the passcode, we can derive the key directly. If we don’t know the passcode, we can brute-force it by repeatedly generating passcode keys and trying to decrypt the System Keybag with them. Only the correct passcode key will successfully decrypt the keybag, wrong keys are recognised easily.

Finally, having acquired the dump and all needed keys without modifying the data during the process or having to trust unknown variables, we can truly call this a Perfect Acquisition. While it is not very likely anyone would go through these lengthy efforts just to fulfill all points on the list above (given that it’s not even needed in most cases), our software can support decryption of dumps acquired through reading the flash externally, provided you also manage to extract the effaceable storage and provide all needed keys.

To state the obvious, we do not offer data extraction exactly like this (but our software can help you if you do it yourself!). Instead, we have a simple and convenient to use software-only approach, which comes extremely close to the truly Perfect Acquisition described here. Stay tuned for part 3 to find out how it works and why we can still reasonably and confidently call it Perfect Acquisition.

 By Elcomsoft R&D at 2023-03-29 12:48:05 Source ElcomSoft blog: