With hardware-backed full-disk encryption and additional protection of sensitive user data located in the keychain, Apple iOS is the most secure mobile operating system out there. Acquisition approaches that are traditional for Android and Windows Phone devices (namely, JTAG, ISP and chip-off) are completely meaningless for iOS devices running even years-old generations of the system. Bypassing screen lock password (passcode) has also been long considered to be useless due to the fact user data stored in the keychain is additionally encrypted with a secure key based on the passcode.

While we can’t do much with the former, our recent research shows that the latter is not entirely true. Bypassing the passcode does reveal quite a bit of information that can be useful for an investigation. And this is not just a theoretical research. We are building this functionality into a ready-to-use commercial tool, iOS Forensic Toolkit, to allow extracting data from locked iDevices – providing they have a jailbreak installed. The tool will allow pull available information from devices locked with an unknown passcode. That includes devices that were powered on (or rebooted) and never unlocked. Naturally, a pre-installed jailbreak is required in order to access the data.

So what exactly can be extracted from a locked device? We were able to gain access to all of the following information:

• Recent geolocation information (*)
• Incoming calls (numbers only) and text messages (**)
• App and system logs (installs and updates, net access logs etc.)
• Some information about mailboxes (folders, number of messages and attachments, recent activities (mail received/sent, timestamps, contacts names and addresses etc).
• SQLite temp files including WAL (Write-ahead logs)

(*) A limited amount of recent geolocation data is available since the main location database remains encrypted. Available information is limited to cellular tower and compass calibration data, which also includes coordinates.

(**) Incoming text messages are only retained unencrypted temporarily after the boot has finished but the unlock passcode has not been entered. The messages will be transferred into the main encrypted database immediately after the phone is unlocked. As a result, if you are acquiring a device that was booted but never unlocked, you will only be able to access text messages received by the device during the time it remained locked after the boot.

If, however, you are in a possession of an iPhone that was unlocked at least once after it was booted (such as if the device was seized in a turned-on state), the amount of data available for extraction will increase significantly. For example, the SMS database is unprotected after the first unlock after boot, allowing you pulling ALL text messages – and not just those received while the device remained locked.

On the first look, this doesn’t look like much. However, let’s look closer to what’s happening with an iPhone after the boot sequence has completed. After the boot sequence has finished, the iPhone will not attempt connecting to even a known Wi-Fi network (as the Wi-Fi password is encrypted with a key derived from the lock screen passcode – which has not been entered just yet). However, mobile data (3G/4G/LTE) is very much active, allowing the phone to actively communicate with the network. In practice, this means that both system and user-installed apps that work in background will perform the tasks they are intended to do.

Skype, Viber and Facebook Messenger all received push notifications with instant messages we’ve sent to the locked device, and stored the data into their corresponding WAL files. As a reminder, that happened before the phone was unlocked even once after the boot sequence. We were able to confirm that those messages can be extracted from the locked iPhone without even unlocking it once after reboot! That works even on 64-bit devices; however, for us to do the extraction, the device must have a jailbreak installed.

This doesn’t work for all apps though. For example, we activated a WhatsApp account on our test device. Shortly after the system has booted up, we sent a few messages to that account. The locked iPhone was unable to receive any of those WhatsApp messages.

So why does that work, what consequences does it have, and what does it all mean for the investigator? Let’s have a closer look.

Passcode-Based Encryption

As you may know, Apple’s security model relies heavily on the lock screen passcode. Not only does the passcode prevent unauthorized access to the “live” device; it also protects user data while the device remains locked. Since iOS 8, pretty much all user data is moved under umbrella of the keychain. The keychain is a secure storage area on the already hardware-encrypted disk. This area is additionally encrypted with an encryption key derived from the user’s passcode. Since the actual decryption key is calculated at the time the user enters the passcode, the keychain remains locked until the correct passcode is entered. This means that information such as contacts, call log, stored application data etc. remains securely encrypted while the device is locked with a passcode.

On this basis, Apple has made claims that it is technically impossible to unlock newer iOS devices, even going as far as to modify its official government request policy to exclude devices running iOS 8 and newer on the basis of technical unfeasibility:

On devices running iOS 8 and later versions, your personal data is placed under the protection of your passcode. For all devices running iOS 8 and later versions, Apple will not perform iOS data extractions in response to government search warrants because the files to be extracted are protected by an encryption key that is tied to the user’s passcode, which Apple does not possess.

The issue has become controversial during the recent case involving the suspect’s iPhone 5S that runs iOS 7, the last version of iOS that can presumably be unlocked by Apple.

That said, Apple does mention an exception. While it says 90 percent of its devices now run iOS 8, 10 percent are still using an older version. Technically, it will be possible for Apple to unlock those devices. Coincidentally, the iPhone in question is one such device. Apple, however, urges Orenstein not to force it to do so, saying that it would break the trust between Apple and its consumers and substantially harm the brand. Not to mention setting a legal precedent for similar cases. [SlashGear]

While DOJ dismisses Apple’s arguments against decrypting iOS communications citing Apple’s own licensing terms, the whole point of this case becomes moot as the suspect pleads guilty.

After guilty plea, judge confused as to why prosecutors still want iPhone unlocked. “I respectfully direct the government to explain why the application is not moot”, says United States Magistrate Judge James Orenstein in a court filing.

Regardless of the heated legal battle quoting 18-century laws and previous practice, what about the actual technical possibility of extracting information from locked devices? Is it indeed as impossible as Apple wants us to believe?

Our findings demonstrate it’s not entirely true. Some information is still available even if the device is in the locked state, and even if the device has been recently switched on or rebooted (and not unlocked after booting up). Namely, this information includes recent geolocation information (we were able to extract data recording information about nearby cell towers, enough to roughly estimate the device’s location), information about incoming calls (just the phone numbers and time/date), the complete text messages including the actual SMS content, a large number of records in the app and system logs, and so-called write-ahead logs (WAL) containing uncommitted information for various SQLite databases.

So why is the data there? Should it not be securely encrypted along with the rest of the data? In fact, doing that would not be technically possible.

Let’s say the phone is locked, and there is an incoming phone call. If the call is not logged, that would break the consistent user experience Apple is so proud off. The result? The call is logged, but that bit of information is not encrypted with the rest of the user’s data because the correct encryption key does not (yet) exist.

The same goes for text messages. If a new text message is received while the device is locked, there is no key stored in the device RAM to encrypt its content. As a result, the text message is stored temporarily unencrypted. It will be moved into the secure area quickly after the phone is unlocked, but remains available in plain view until the correct passcode is entered.

System logs and logs recording background application activities must be maintained regardless of lock status. Thus these logs are not part of the keychain, and can be extracted from the locked device. This includes WAL files, or SQLite write-ahead logs. These files are temporary SQLite databases that receive information to be committed into the main database at some point in the future. The thing is, the main database may not be available for reading or writing as the device is locked (because the database file is encrypted, and no decryption key exists prior to entering the correct passcode). As a result, the system retains newly added records in these temporary files, waiting for them to be merged with the main database once the main database becomes available (decrypted).

All that said, there is no technical problem pulling all that data from a locked iPhone – despite of what Apple is saying. However, for doing that, a third party (such as us) requires having a jailbroken device, with jailbreak already installed and active. Obviously, Apple does not have this in their way. From pure technical standpoint, Apple can (at least theoretically) extract at least that much data from a locked device. Yet, the company actively refuses to do so. For now, your options are limited to jailbroken devices and Elcomsoft iOS Forensic Toolkit.

Many thanks to Mattia Epifani, an author of excellent Learning iOS Forensics book, for his invaluable help on testing our software and preparing this article.