A Technical Autopsy of the Apple - FBI Debate Using iPhone Forensics

The technical basics of the case is that FBI is trying to compel Apple Inc. to help create a new capability installed on the suspect's iPhone that would enable with the following degraded security mechanisms:

1. Allow the FBI to submit passcode "electronically via the physical device port"
2. Will not wipe underlying data after 10 incorrect passcode attempts
3. Will not cause any delays after an incorrect passcode attempts

Here is what we know about the device in question so far. From court documentation we know it is an Apple iPhone 5C, model A1532, running iOS 9 [1], with serial number FFMNQ3MTG2DJ and IMEI 358820052301412[2]. Using the serial number and IMEI, we can garner some additional information that's crucial to answering the technical questions by using free website imei.info and other resources. This particular model of iPhone contains an A6 chip. The provider is Verizon and the data capacity could be either 16 or 32 GB. The device is locked with a user generated, numeric passcode [3].

• [1] Compel Order 16 Feb 2016 PDF Pg 6, Lines 2-3
• [2] Compel Order 16 Feb 2016 PDF Pg 3, Lines 19-22
• [3] Compel Order 19 Feb 2016 PDF Pg 10, Lines 12-13

VIDEO WEBCAST — A Technical Autopsy of the Apple - FBI Debate using iPhone forensics

Apple - FBI: The Details, Details, Details...

For many years, mobile forensic analysts had it easy. With iOS devices using the A4 chip (iPhone 4, iPad) and older (running iOS 7 or older) we were able to make physical images handily. A physical image is the closest thing we get to a bit by bit forensic image of the entire device. These are sometimes referred to as "the good ole days" by those of us doing mobile forensics. A physical image was considered ideal, because it gave us access to all the data stored on the phone. As time has moved forward, it has gotten more and more difficult to pull complete physical images from mobile devices of all varieties. More often, we're able to obtain forensic backups or logical extractions of portions of the data from mobile devices.

Starting with Apple A5 chip (iPhone 4S, iPad 2) and any iOS version we can still acquire a physical and/or logical image, but we will need the passcode as well as jailbreak software, or a device that's been previously jailbroken by the user.

The San Bernardino iPhone central to this discussion contains the A6 chip (found in the iPhone 5, iPhone 5C) and based on court documentation from the case, some version of iOS 9 is installed on the device. For this particular device, we would still need the passcode and jailbreak software to get a physical dump or just the passcode to get a logical extraction or forensic backup of the file system.

These "it depends" scenarios get complicated, and sometimes a great reference document is needed to keep track of it all. Devon Ackerman, Special Agent/Forensic Examiner provided the great spreadsheet shown in the below images to us, and has given permission to share it.

IOS Device and Current Known Forensics Capabilities

iOS | Forensic Reference Key

Why can't the FBI dump the iPhone like a hard drive?

iOS devices offer increased levels of encryption with each new release. The Apple A5 (and newer) chips offer the greatest amount of encryption and are the most difficult Apple devices so far to access when locked. These iOS devices are encrypted with 256bit AES encryption at the hardware level. The encryption key is stored between the flash memory and system area on the iOS device. This area of is referred to as "effaceable storage." Hardware level encryption important because resulting extractions will only allow viewing of the file system and metadata, while leaving file contents unreadable due to encryption. Using the passcode to unlock the device prior to acquisition allows decryption of the data and renders it usable.

The iPhone 4S, which debuted the A5 chip, featured beefed up security which decreased the number of commands available in the boot loader, and consequently made it more difficult to physically acquire the device. The A6, A7, and A8 chips have followed suit and have become increasingly secure with each new chip release. The iPhone 4 has an bootrom exploit (24kpwn) which is used by commercial mobile forensic tools and non-commercial methods to physically access the device and bypass a lock. In the A5, A6, and A7 chips this exploit has been patched. This patch occurred well before the release of the iPhone 6 and the A8 chip.

Additionally, most logical files stored on the user partition of the disk are protected by a per-file encryption called Data Protection. This means that if we were able to get a dump of the data from the phone via chip-off or JTAG techniques (either of which could be destructive to the device) the contents of the files would still be encrypted. The following screenshots shows a physical image from a device with Data Protection. The file system is readable, however the file contents are encrypted.

iPhone Physical Image - Note the file system structure and associated metadata:

iPhone Physical Image

Data Protection Encrypted IMG_0001.JPG File

Decrypted IMG_0001.JPG File

As far as we are aware, it is not possible at this time to extract the iPhone hardware keys along with a brute force of the passcode to decrypt the file contents.

What about those auto-magical password cracking tools I see on CSI Cyber?

Just because you see actor-investigators, actor-analysts, and actor-technicians quickly and effortlessly solve all the nearly-impossible tech problems presented to them in the span of an hour long episode does not necessarily mean things ever work that way in real life. Remember, these shows are largely fiction with a few juicy tidbits of truth thrown in here and there for good measure. Brute force password cracking on TV rarely fails, and is usually successful just barely in the nick of suspense filled time.

Three (real) and popular commercially available password cracking solutions for iPhone are described below:

1. One of the auto-password guessing tools is called the IP-BOX. The IP-BOX is a black box that originates from phone unlocking, hacking, and repair market which can be used to defeat simple 4 digit pass codes on iOS devices running versions of iOS through iOS8.1.2. Following testing and validation, this box has been used by law enforcement (with valid legal authority) quite effectively to unlock iPhones for evidentiary purposes, until the exploits being leveraged the device were patched by Apple. Again, from the court documentation available, the San Bernardino iPhone is likely running some version of iOS9, thus the IP-BOX would not be effective.

2. Cellebrite's Advanced Investigative Services (CAIS) offers an iPhone unlocking service using tools and processes that are proprietary and publicly unknown. We are aware of a number of great success stories related to use of Cellebrite's services to unlock iPhones in criminal cases. Use of this service requires an agency to provide the physical device to Cellebrite in hopes of getting the device and passcode in return. This service is advertised to only work on the iPhone4S (or newer) devices running iOS 8.0 to 8.4.1. The service also states that the "device wipe" functionality is bypassed. Cellebrite also has a user lock recovery tool for use on iOS and Android devices that relies on brute force attacks. This tool is only effective with iOS devices running versions of iOS 7.

3. Secure View's svStrike is similar to the IP-BOX, but with added capabilities including the ability to brute force up to a 6-digit passcode (versus 4-digit). The documentation does not state whether the "device wipe" functionality can be bypassed.

You have the suspects thumb, could the FBI just use Touch ID on the Apple iPhone?

If only. Unfortunately, the iPhone we're talking about here was an iPhone 5c, and Touch ID was introduced with the more fully featured iPhone 5s.

Ironic, isn't it? One less security feature to attempt to exploit actually means this particular iPhone is more secure.

Assuming an alternate universe, where the suspect had a Touch ID capable model of iPhone and Touch ID was enabled by the suspect, there would have been a very limited time window during which his hands could have been used to attempt to unlock the phone. Let's face it though - there was a whole lot going on in those first few hours of terror. Mass casualties and injured people, a large crime scene, stretched resources and buckets of adrenaline. Search warrants were being written and executed. The existence of this particular iPhone likely was not yet even known, let alone who it belonged to. To quarterback after the fact and say that the cops should have matched the dead terrorist's thumb to this particular iPhone in the midst of the chaos is asking people who are already heros to have been comic book super heros.

Here are the technical limitations they would have faced: According to Apple's security documentation to use Touch ID, users must set up their device to require entry of a passcode to unlock it. When a recognized enrolled fingerprint is scanned via Touch ID, the device unlocks without asking for the device passcode. The passcode can be used instead of a fingerprint, and the passcode is still required when the device is restarted, when the device has not been unlocked for more than 48 hours, when the device has received a remote lock command, after five unsuccessful attempts to match a fingerprint, or when setting up or enrolling new fingerprints with Touch ID.

In this case, because of the iPhone 5C hardware, Touch ID wasn't even an option. Therefore we face the following passcode options: 1) A four digit simple passcode. This is the most common passcode for pre-iOS 9 devices. 2) A six digit PIN, introduced with iOS 9. More digits means more difficulty and more time for a brute force attack. 3) A complex passcode. Complex alphanumeric passcodes can also be used on iOS devices, making our brute force attempts even more difficult. Most forensic tools can crack simple passcodes if the iOS version is supported. At best, complex passcodes can be bypassed if the iOS device can enter DFU mode (not damaged) and the device is supported for physical acquisition, which is not the case with this iPhone.

Oh, so it's just a Apple iPhone pin code, why can't the FBI just brute force it now?

Brute force can be attempted and may work using the tools discussed above.

However, should the user have their iPhone enabled to wipe after 10 failed attempts, the data on the device could be wiped and rendered useless within minutes of running the brute force attack. This is the risk we aim to avoid, at all costs.

iPhone Touch ID Settings

While iOS devices used to warn the user of an impending wipe of the device following too many failed passcode entry attempts, this is not the case anymore. Based upon data found in iCloud backups and information provided by the employer-owner of the phone, investigators in the San Bernardino case have reason to believe that the Erase Data function was turned on. A blind brute-forcing attempt to break the passcode in this case would not have been wise.

Could the Apple iPhone iCloud backups be of help to the FBI?

Yes. If the device has iCloud backups enabled then the backup files can be recovered. In this case, the last iCloud backup file that was recovered and examined by the FBI was dated October 19, 2015 which is over a month before the attacks occurred. [1] iCloud backup files contain user data as specified through their specific iPhone settings including email, contacts, calendars, photos, and Apple keychain data. iCloud backups are only performed when the device is connected to a WiFi network and plugged in. As long as the settings are turned on and maintained, iCloud backups would occur regularly when connected to a WiFi network. Any changes to the configuration of the iCloud backup settings require the user's iCloud password and the correct password to be entered into the iPhone. If the password to the user's iCloud account changes, the device user would need the enter the new password into the device prior to successfully backup their data into the iCloud.

The iCloud password was remotely reset by the owner of the device, San Bernardino County, hours after the attack eliminating the possibility of an automatic backup if the device connected with a known WiFi network.[2] Also, a Mobile Device Management (MDM) solution should be considered by any government or corporate owned phones used by employees. MDM solutions would help prevent locking out the organization from the phone that they own and could secure the data for eventual examination.

• [1] Compel Order 16 Feb 2016 PDF Pg 23, Lines 19-22
• [2] Compel Order 19 Feb 2016 PDF Pg 23, Lines 22-24

I heard Apple has helped out the FBI before, why is this different?

Previously, when presented with search warrants compelling their assistance, Apple has provided law enforcement agencies with the extracted contents of older iPhone devices running iOS 7 or older. They did this by running a specialized RAM disk on the devices to bypass the passcode to obtain the data. As of iOS 8 Apple has stated that this process is no longer an option due to how the encryption process has changed. From Apple's "Legal Process Guidelines"

"For all devices running iOS 8.0 and later versions, Apple will not perform iOS data extractions as data extraction tools are no longer effective. The files to be extracted are protected by an encryption key that is tied to the user's passcode, which Apple does not possess."

I hear Apple holds the key, can you explain?

One ring key to rule them all! When an iOS device boots it verifies the Boot ROM code against the Apple Root CA public key, this is the first step in the secure boot chain. This ensures that iOS devices will only boot with Apple provided iOS software. If another version of the iOS software was created (either by Apple or other 3rd parties) the device would still be required to verify the Boot ROM against the Apple Root CA public key to successfully load. Only Apple has a copy of their private key and this is a critical reason why the government cannot simply write their own version of iOS.

One of the critical security mechanisms for distributable software is this verification process. If a private key is lost or stolen, hackers could write backdoors, espionage software, or other malicious capabilities into their software that the device would automatically trust and load that malcode.

Ok, I get it. This is hard. Can they get the data from anywhere else? I heard the FBI has other cellphone evidence from the Apple iPhone. Surely this can this be used? (...and don't call me Shirley!)

Some data related to use of the iPhone 5c likely exists in other locations, including the suspect's iCloud account, the hard drive of any computers the iPhone was backed up to, the carrier, and potentially other cloud based accounts related to apps in use on the phone. Also, conversations have at least two sides, and anyone the suspect was communicating with could have relevant information stored within their phones as well.

With iOS 9, if Apple Continuity was turned on, perhaps there might even be relevant mobile phone related data stored on other iOS/OS X devices. But considering that the suspects may have discarded computing devices and hard drives in a nearby lake, this potential lead could be a dead end as well.

According to the court filing, two other cell phones were examined in this case. Both of those phones were found "destroyed" and "discarded" in a dumpster behind the residence. These phones may contain information useful to the investigation, or which could potentially lead to the passcode for the iPhone 5c. Many times, "destroyed" phones can be repaired to get to relevant evidence, many times pass codes are more easily recovered from different mobile devices, and many times passcodes are reused between devices. Time will tell.

If the FBI can get to the Apple iPhone data, what else can they find?

If the FBI can get to the data, a plethora of information may be accessible. The iPhone most likely contains recent conversations, call logs, Internet searches, chats, application usage, locational data and much more. Our smartphones are the most personal devices we own and contain information that provide deep insight into our lifestyle.

Merely successfully getting to the data is sometimes just the first challenge. If we are able to successfully dump the phone after obtaining or bypassing a passcode, data stored by the apps themselves often contains encrypted data. This scenario is increasingly common, as app developers work to make user data more secure and are implementing data-at-rest security features like encrypted databases, or encrypted content within databases. For example, Threema, is a commonly used secure communications app that is used world-wide. The data associated with the application is all encrypted when data is dumped from the iPhone. If the user relied upon third-party applications like Threema to chat, it's likely the FBI would be faced with an additional hurdle - encryption that Apple cannot help with.

Can Apple even do what the FBI is asking for?

From what we know about iPhones, the A6 chip, and iOS 9, the answer is: Probably. Apple may be the only ones who currently can. Which is not to say someone else outside Apple and the FBI won't come up with a creative solution to this problem. Our bets aren't on McAfee's social engineering attack though. Dan Guido from Trail of Bits describes this in a bit more technical detail, and Jonathan Zdziarski also agrees that Apple would be technically able to comply with the order given the hardware and iOS version involved.

This is interesting, may I have more information?

We have found the articles below well written and useful for learning more about this topic.

• Trail of Bits - "Apple can comply with the FBI court order"
• DarthNull.org - "Put away the tin-foil: The Apple unlock case is complicated enough"
• Jonathan Zdziarski - Apple's technical capabilities under FBI AWA order
• Charles Riley - All This #FBiOS Hubbub Boils Down to Just One (Technical) Thing
• Devon Ackerman - iOS Imaging Spreadsheet

Documentation from Apple:

• iOS Security Guide
• Legal Process Guidelines

About the Authors:

• Heather Mahalik is leading the forensic effort as a Principal Forensic Scientist and Team Lead for Oceans Edge, Inc. and has extensive experience in digital forensics which began in 2003. She is currently a senior instructor for the SANS Institute and is the course lead for FOR585: Advanced Smartphone Forensics.
• Cindy Murphy is a Detective with the City of Madison, WI Police Department where she has been involved in digital forensics since 1999. She is a certified SANS instructor co-author of FOR585: Advanced Smartphone Forensics.
• Sarah Edwards is a senior digital forensic analyst who has worked with various federal law enforcement agencies. Her research and analytical interests include Mac forensics, mobile device forensics, digital profiling, and malware reverse engineering. Sarah is the lead author for FOR518: Mac Forensics.

** Above Joe Friday "Just the FAQs" - Photo by Brian Moran @brianjmoran