iPhone User Data: What’s Inside
Let’s make it very clear: no privacy purist should ever use an iPhone (or any other smartphone, probably). iPhone devices store or cache humungous amounts of information about how, when, and where the device has been used. The amount of sensitive information collected and stored in Apple smartphones is beyond what had previously been imaginable. Pictures, emails and text messages included deleted ones, calls placed and received are just a few things to mention. A comprehensive history of user’s locations complete with geographic coordinates and timestamps. Google maps and routes ever accessed. Web browsing history and browser cache, screen shots of applications being used, usernames, Web site passwords and the password to iPhone backups made with iTunes software, and just about everything typed on the iPhone is being cached by the device.It’s Not About iPhone Backups Any More
Some, but not all, of that information makes its way into iPhone backups produced with Apple iTunes. Protected iPhone backups can be broken into with Elcomsoft Phone Password Breaker; once decrypted, information stored in these backups can be viewed by many commercial products. However, the amount of information that these backups contain is reasonably limited. Analyzing actual iPhone device could provide forensic access to much more data.Adequate Protection
The amount and nature of information accumulated by iPhone devices called for adequate protection. Starting with iPhone 3GS, Apple was including a hardware encryption chip in all subsequent devices. With iOS 4, the company introduced a feature called Data Protection that enabled hardware-based encryption of all user data stored in iPhone 3GS and subsequent models (iPhone 4, all models of iPad, and latest generations of iPod Touch). Using industry-standard AES-256 encryption, the protection was considered to be adequate against even the best equipped adversaries, including forensic analysts and law enforcement agencies.Implementation of iPhone File System Encryption
If you’re not interested in technical detail on how Apple iOS 4 protects user data in iPhone devices, you can skip this chapter. Reading it will, however, help you understand and appreciate what was done by ElcomSoft researchers. iPhone, iPod Touch and iPad (referred hereafter as iOS devices) are quite popular with all types of users. Due to their popularity and considering the amount of information about the history of user’s behavior, iOS devices are common subjects to forensic analysis. The most comprehensive technique for iOS forensics is physical acquisition that allows to obtain a bit-to-bit snapshot of iOS devices’ file system. In a way, this is similar to making an image of a disk or dumping a CD or DVD into an ISO file.The technique worked great until the release of iOS 4. Before that, file system images obtained from iPhone and other iOS devices were perfectly readable with all user data being readily accessible. On iOS 4.x, however, those file system images obtained from the devices were pretty much useless for forensic analysis because the contents of each file were securely encrypted. File system seemed to be intact, though, and it was still possible to get list of files and some of their attributes.
To make things even more complicated for a security researcher, every file is encrypted with its own unique encryption key tied to particular iOS device. Furthermore, certain files are protected with encryption keys tied to both the device and the user’s passcode, meaning that those files can be only decrypted when the device is unlocked by the user. Most notable examples are e-mail files maintained by built-in Mail app.
Breaking the Encryption
Explaining what we did to break this encryption is not exactly easy. In a word, we found a way to decrypt bit-to-bit images of iOS 4 devices. Decrypted images are perfectly usable, and can be analyzed with forensic tools such as Guidance EnCase or AccessData FTK (or any other tool which supports raw drive images and HFS+ file system). Decryption is not possible without having access to the actual device because we need to obtain the encryption keys that are stored in (or computed by) the device and are not dumped or stored during typical physical acquisition. In particular, those keys include:- Keys computed from the unique device key (UID), which is believed to be embedded in the hardware and is not extractable (so-called keys 0×835 and 0x89B);
- User passcode key which is derived from users’ passcode using the unique device key (UID);
- Escrow key(s) which are derived from escrow pairing records using the unique device key (UID);
- Effaceable storage area which stores number of encryption keys.
By default (with “Simple passcode” option enabled), passcodes consists of only four digits, meaning that only 10,000 possibilities exist. Having to enter their passcode pretty often most users keep their passcodes to the default length of only four digits for the sake of usability.
Ten thousand combinations do not sound like much. On a PC, breaking a passcode of this length would only take a few moments. Unfortunately, passcodes can only be bruteforced on the device itself. With iPhone 4, the maximum time of breaking a 4-digit passcode is therefore about 40 minutes, while taking about 20 minutes on average. iPhone 3GS is slower, and it takes a bit longer to break a passcode there. In fact, phones running iPhoneOS 3.x can be broken without knowing the passcode by simply removing it; with iOS 4.x, a valid passcode is required to gain full access.
It is possible to overcome the requirement of having the correct passcode by using escrow keys. Escrow keys are created and stored by the iTunes when you first plug an iOS device to the computer. Having a set of escrow keys collected from a computer to which an iOS device was once connected gives the same powers as knowing the passcode (except that you can’t deduce the passcode itself).
The last thing standing is the keychain. The keychain is a system-wide storage area for application secrets such as user account details, usernames and passwords. While Elcomsoft Phone Password Breaker already has the ability to display the contents of the keychain area, it could only read the keychain from iOS backups. As it turns out, not all data from the system keychain is exported into the backup. For example, the backup password itself is present in the system keychain but is never exported to the backup. Application developers utilizing Keychain can choose whether records stored by their application should go to the backup or not. That said, the complete Keychain including items not included wit the backup can be read and decrypted using the same set of keys obtained from the device.
Another World’s First
So far, ElcomSoft is the first company to offer a complete, all-in-one commercial solution for performing physical acquisition analysis of iOS 4.x devices. ElcomSoft did another “World’s first” here.What This Means for You
By breaking the protection system of Apple iPhone 3GS and later devices running iOS 4, ElcomSoft opens the possibility of an extremely comprehensive forensic analysis of affected iOS devices. While this is a big achievement in cryptographic terms, iPhone backups produced with Apple iTunes software already contained a lot of sensitive information, including keychains. ElcomSoft makes forensic analysis easier, faster (the extraction of file system encryption keys is nearly instant as opposed to lengthy dictionary or brute force attacks which are required to obtain a password to an iPhone backup) and more comprehensive.The toolkit were offering includes updated Elcomsoft Phone Password Breaker which was fitted with new function to decrypt iOS 4.x file system images, as well as an optional tools to obtain filesystem images of the iOS 4.x devices, extract keys required for image decryption, and brute-force passcode.
To make sure those tools do not fall into the wrong hands, we decided to offer them only to established law enforcement, forensic and intelligence agencies as well as select government organizations.
Affected Apple Devices
All Apple devices starting with iPhone 3GS and running iOS 4 are affected, including iPhone, iPod and iPad devices.Next part: Extracting the File System from iPhone/iPad/iPod Touch Devices
 | Extracting the File System from iPhone/iPad/iPod Touch Devices |
| May 23rd, 2011 by Andrey Belenko |
In our previous blog post we have described how we broke the encryption in iOS devices. One important thing was left out of that article for the sake of readability, and that is how we actually acquire the image of the file system of the device. Indeed, in order to decrypt the file system, we need to extract it from the device first.
When it comes to obtaining the contents of iPhone’s file system, mobile forensic specialists usually mention the following three opportunities:
1. One can mount the device, mapping it as a drive letter and copy data file after file. In this mode, I/O requests are served by the file system driver on the device that’s supposed to ‘know’ the encryption keys for all files. Essentially, this means that analyst receives file data that is already decrypted during the transfer. The ‘mounting’ in this case is achieved by using undocumented interfaces provided by Apple iTunes, which makes the researcher rely on something that’s a) undocumented, and b) involuntarily provided by the manufacturer. The amount of data available depends on whether the device is booted into a so-called "jailbroken" state or not. Devices that are not booted into a "jailbroken" state allow access to significantly less information. In "jailbroken" state, all information stored on the device may be available.
2. The second option would be to decrypt file system as a part of acquisition process so that its result is a decrypted file system.
3. Finally, one can do a physical acquisition of the encrypted file system and decrypt the data off-line. This would require an additional step of extracting required keys off the device.
The last two options are indeed very similar. In both cases, I/O requests are served by storage driver (as opposed to file system driver in the first case), effectively bypassing proprietary file system drivers and avoiding all types of file locks and access permission problems. Both methods require the device to be in "jailbroken" state.
Although those last two acquisition approaches are similar and first one might seem more attractive on the first sight, we decided to go with the last one. In our eyes, there are numerous important benefits to doing the physical acquisition in a ‘raw’ way.
1. We believe that physical acquisition should be as close to the original device data as possible. The first method (mounting the device) relies on the file system driver to deliver decrypted file data. If we wanted to implement similar on-the-fly decryption during the physical acquisition process, the resulting image won’t be a bit-to-bit physical copy at all. Instead, we can do those actions off-line, and produce a decrypted image out of a precise bit copy.
2. Some device secrets such as the passcode or escrow keys might not be known at acquisition time. Without knowing those secrets, some files can not be decrypted. Off-line processing allows capturing and storing the original encrypted image while postponing the decryption to a later moment. An analyst can return to the original image if more secrets become available (e.g. escrow keys are discovered on suspects’ desktop computer) without having to re-acquire data from the physical device.
3. Analysts may have a backlog of cases. Re-doing the acquisition with a new tool might not be what they’re looking for. With off-line approach, one can obtain the keys from the device, which takes much less time than re-imaging it.
4. Forensics often already have a favorite (or the only approved) tool to do device imaging. For those who don’t, ElcomSoft can provide a basic one that just works. As long as the tool is capable of producing raw (dd-style) images, the analysts can continue using it.
5. Finally, the tools are not bug-free. The acquisition must be as simple and as straightforward as possible. Having to re-acquire the contents of a 64 Gb iPad because of a glitch in the imaging tool could be extremely frustrating and time-consuming. By performing the decryption as a separate process, one can reduce the risk of this happening.
When it comes to obtaining the contents of iPhone’s file system, mobile forensic specialists usually mention the following three opportunities:1. One can mount the device, mapping it as a drive letter and copy data file after file. In this mode, I/O requests are served by the file system driver on the device that’s supposed to ‘know’ the encryption keys for all files. Essentially, this means that analyst receives file data that is already decrypted during the transfer. The ‘mounting’ in this case is achieved by using undocumented interfaces provided by Apple iTunes, which makes the researcher rely on something that’s a) undocumented, and b) involuntarily provided by the manufacturer. The amount of data available depends on whether the device is booted into a so-called "jailbroken" state or not. Devices that are not booted into a "jailbroken" state allow access to significantly less information. In "jailbroken" state, all information stored on the device may be available.
It is worth mentioning that booting a device into a "jailbroken" state does not necessarily require a permanent "jailbreak" modification of the device, and can be performed without modifying data stored on the device, i.e. without violating read-only principle so important in computer forensics.While relatively simple, the file-based approach has numerous limitations that make it less than ideal for forensic purposes. Since the transfer is done file-by file, the case quickly becomes difficult to manage. Typical file system contains tens of thousands of files so it might be quite a challenge to even store them in forensically sound way (i.e. making sure that no files are added, deleted, or modified after acquisition is complete). Another problem is that some files may be locked by running processes, may require additional privileges, symbolic links may interfere with the host system, etc.
2. The second option would be to decrypt file system as a part of acquisition process so that its result is a decrypted file system.
3. Finally, one can do a physical acquisition of the encrypted file system and decrypt the data off-line. This would require an additional step of extracting required keys off the device.
The last two options are indeed very similar. In both cases, I/O requests are served by storage driver (as opposed to file system driver in the first case), effectively bypassing proprietary file system drivers and avoiding all types of file locks and access permission problems. Both methods require the device to be in "jailbroken" state.
Although those last two acquisition approaches are similar and first one might seem more attractive on the first sight, we decided to go with the last one. In our eyes, there are numerous important benefits to doing the physical acquisition in a ‘raw’ way.
1. We believe that physical acquisition should be as close to the original device data as possible. The first method (mounting the device) relies on the file system driver to deliver decrypted file data. If we wanted to implement similar on-the-fly decryption during the physical acquisition process, the resulting image won’t be a bit-to-bit physical copy at all. Instead, we can do those actions off-line, and produce a decrypted image out of a precise bit copy.
2. Some device secrets such as the passcode or escrow keys might not be known at acquisition time. Without knowing those secrets, some files can not be decrypted. Off-line processing allows capturing and storing the original encrypted image while postponing the decryption to a later moment. An analyst can return to the original image if more secrets become available (e.g. escrow keys are discovered on suspects’ desktop computer) without having to re-acquire data from the physical device.
3. Analysts may have a backlog of cases. Re-doing the acquisition with a new tool might not be what they’re looking for. With off-line approach, one can obtain the keys from the device, which takes much less time than re-imaging it.
4. Forensics often already have a favorite (or the only approved) tool to do device imaging. For those who don’t, ElcomSoft can provide a basic one that just works. As long as the tool is capable of producing raw (dd-style) images, the analysts can continue using it.
5. Finally, the tools are not bug-free. The acquisition must be as simple and as straightforward as possible. Having to re-acquire the contents of a 64 Gb iPad because of a glitch in the imaging tool could be extremely frustrating and time-consuming. By performing the decryption as a separate process, one can reduce the risk of this happening.
The Toolkit
Elcomsoft Phone Password Breaker is available to general public. We will also provide eligible parties with additional acquisition Toolkit to use on devices running iOS 4.x. We’ll also provide detailed instructions. The Toolkit will allow the following:- Extract hardware-dependent keys, file system keys and escrow keys from the device;
- Recover the passcode (subject to passcode length and complexity);
- Obtain bit-to-bit copy of device storage.
No comments:
Post a Comment