On Tuesday, a federal judge ordered Apple to assist the authorities in breaking into a locked iPhone 5C used by Syed Farook, who killed 14 in San Bernardino in December. According to the FBI, the phone might contain critical information about connections with Islamic terrorist groups. Apple opposed the motion and published an open letter at https://www.apple.com/customer-letter/ saying that “The United States government has demanded that Apple take an unprecedented step which threatens the security of our customers. We oppose this order, which has implications far beyond the legal case at hand.”

So what is the government asking, does Apple have it, and is it technically possible to achieve what they are asking? Let’s try to find out.

What the Government is Asking Apple

Effectively, the government is asking Apple to write a tool very similar to iOS Forensic Toolkit. Apple would need to develop a custom boot image just for that device, including the tool to either enumerate passcodes. However, Apple challenges this request citing their customers’ privacy and creating a dangerous precedent of using the All Writs Act of 1789.

So What’s The Problem?

It may sound strange, but the main problem is, what the FBI is asking is technically feasible. If Apple agrees to develop software for breaking into this one iPhone, what goes next? Will they be ordered to use this software on more devices, or will they be ordered to hand the software to the FBI and keep shut about it?

Can They Really Do It?

Yes they can. The device in question runs old-generation hardware that lacks the much touted secure enclave, which by itself is a dedicated security processor found in Apple’s later devices (iPhone 5S and all newer models). As a result, any and all passcode-related policies are controlled by Apple’s iOS, and iOS alone. There is no dedicated security chip to slow down passcode attempts by introducing artificial delays. Yes, the delays are there, but they are controlled by iOS (in software) rather than by firmware of a dedicated security chip.

What if Farook used a newer iPhone? Would it change anything? Not much, really. Apple controls the whole thing from firmware and microcode of all individual components down to the last icon in the operating system. They can (and they did in the past) update firmware of Secure Enclave. The last update to Secure Enclave introduced the delay. There’s no technical reason to prevent Apple reversing the change in yet another update.

So Apple have technical capabilities to do what they are asked to do. But is there such an urge for the FBI to make such a request, or are there any other ways to extract information?

Alternatives

Reading existing publications, we have more questions than answers. Did the FBI check if a cloud backup is available for that backup? Did they examine Farook’s computer? Was there an iTunes backup, or maybe a cloud authentication token? Judging from bits and pieces of information available online (particularly, “running iOS 8 or 9”), it does not seem that the FBI has contacted Apple about obtaining a cloud backup at all (or maybe there was no cloud backup available). So let’s try to find out what options are available if Apple refuses to cooperate (or fails to provide technical assistance to the point they are requested to do).

The iCloud

Government agencies routinely use cloud services as sources of evidence. Cloud acquisition can help solve cases that would otherwise appear hopeless. So what about the cloud, and how can it help during this investigation?

Recent versions of iOS have the ability to automatically back up information from the device into Apple’s cloud service. Cloud backups are recommended by default. They are made automatically every time the user charges their device while connected to a known Wi-Fi network.

Apple reported some 750 million active iCloud users. In other words, chances are pretty great that the iPhone 5C in question was configured to produce cloud backups. Depending on the version of iOS running on the device, cloud backups could be stored either in iCloud (iOS 8.x) or iCloud Drive (iOS 9.x).

A full cloud backup can be requested from Apple with a court order. Apple has everything needed to decrypt these backups. The encryption key is stored alongside the backup itself, so decrypting the data should not be a problem.

So what’s available in a cloud backup? At least the following information is there:

• Contacts and Contact Favorites
• Messages (including iMessages)
• Call history
• Application data
• Device settings
• Camera roll (photos and videos)
• Purchases (music, movies, TV, apps, books)
• Mail accounts
• Network settings (saved Wi-Fi hotspots, VPN settings etc)
• Paired Bluetooth devices
• Offline web application cache/database
• Safari bookmarks, cookies, history, offline data
• Geolocation history and places
• And much more

Compared to full pledged physical acquisition, cloud backups are limited in some ways. They contain NO downloaded mail, NO application cache, LIMITED app data, and LIMITED amount of geolocation data. Keychain acquisition is also iffy (requires a secret key extracted from the device itself via physical acquisition), but pulling that key is not something impossible if one has the ability to boot a custom image.

Some Data Available Unencrypted Even if Passcode Is Unknown

So far, we haven’t seen a single mention of the fact that *some* data is still available (unencrypted) even if the device is locked with a passcode. Back in November last year, we published a comprehensive blog post about this exact issue: http://blog.elcomsoft.com/2015/11/extracting-data-from-locked-iphones/

At very least, the following information is available (quoting from our November article):

• 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.

Of course, to actually obtain this information one must first jailbreak the device… or boot a custom signed image, which should not be a problem for Apple. For jailbroken iPhones, our in-house tool, Elcomsoft iOS Forensic Toolkit, can pull as much data even if the passcode is unknown. In fact, since the iPhone 5C in question is a 32-bit device, we could pull more from a jailbroken device by attacking the passcode.

Could ElcomSoft Break that iPhone?

Multiple journalists have reached us asking if ElcomSoft could do anything to break that iPhone. After all, we already have a physical acquisition toolkit that works in cases just like that, right?

The thing is, in order to bypass passcode protection (and in order to pull anything at all from a locked device), one must be able to load a custom module. This can be done on jailbroken devices. This can also be done by booting a custom image. However, since iPhone 4S, any custom boot image must be signed by Apple in order for the device to agree to boot it. (It was also the case for earlier devices, yet an exploit was discovered allowing us to circumvent signature verification).

Theoretically, if ElcomSoft were given a valid key to sign a boot image, we could quickly pull some unencrypted data from the device, then run a passcode attack in order to try to break the passcode. If a 4-digit numerical passcode was used, the attack would finish in less than 30 minutes. A 6-digit numerical password would take several days. Alphanumerical passwords could take years to break depending on their length and complexity.

Having the correct passcode, we could use our old and proven 32-bit acquisition process to pull and decrypt the disk image of the device. Depending on the size of that image, this would probably take another 30-50 minutes or so.

In other words, we could do it in less than a day *if* the device is protected with a 4-digit numeric passcode, or in several days if 6 digits were used. If the device is protected with a long alphanumerical password, we could only pull a very limited set of data.