In a letter emailed from FBI Press Relations in the Los Angeles Field Office, the FBI admitted to performing a reckless and forensically unsound password change that they acknowledge interfered with Apple’s attempts to re-connect Farook’s iCloud backup service. In attempting to defend their actions, the following statement was made in order to downplay the loss of potential forensic data:
“Through previous testing, we know that direct data extraction from an iOS device often provides more data than an iCloud backup contains. Even if the password had not been changed and Apple could have turned on the auto-backup and loaded it to the cloud, there might be information on the phoen that would not be accessible without Apple’s assistance as required by the All Writs Act Order, since the iCloud backup does not contain everything on an iPhone.”
This statement implies only one of two possible outcomes:
Either they are Wrong, and were Reckless…
It is true that an iCloud backup does not contain everything on an iPhone. There is a stateful cache containing third party application data that is not intended to come off of the phone. This is where most private content such as Wickr, Telegram, and Signal databases would live. However, this information also does not come off the phone in a direct backup either. Similarly, all commercial forensics tools use the same backup facility as iTunes for iOS 9, meaning none of them can get the stateful cache either.
The backup conduit provides virtually the same data as an iCloud backup. In fact, an iCloud backup arguably provides more data than a direct logical extraction because they are incremental, and contain older backups. Desktop backups can sometimes even contain less content, as they exclude photos that have already been synced to iCloud. There are a few small exceptions to this, such as keychain data, which will only come off the phone in a direct backup if backup encryption is turned on. Ironically, if Farook’s phone has backup encryption turned on (which is likely), the FBI won’t be able to get anything from a direct copy, because the contents will be encrypted. Even if they found the device to have backup encryption off (and turned it on), they’re still not going to get the data they actually need off of the device (e.g. the cached third party application data); getting passwords doesn’t mean much when you can just subpoena every content provider for the data anyway.
…or the government will Compel More Assistance, and mislad the courts.
As I said, there is in fact more data available on the device than comes off in any backup. The only way to get to this data, however, would be for Apple to digitally decrypt and extract the contents of the file system, and provide them with a raw disk image. This is similar to what Apple has done in the past, except they would now also have to write a new decryption and extraction tool specifically for the new encryption scheme that was introduced in iOS 8, and carried into 9.
This second possibility is far more sinister than simply being wrong about the quality of iCloud data. If the government actually does intend to get a hold of this “extra” data that only Apple can provide, then that means they will be following up their original AWA order with a second order, requiring Apple to build a second tool to decrypt and extract this content from the device. Their original order required Apple to build a backdoor brute force tool. It did not require Apple to perform any kind of extraction of the raw disk for them. If a second order is coming, this means two important things:
- The attorneys for the FBI provided an incomplete, and misleading explanation of assistance to the courts, which intentionally hid the extra assistance that Apple will later be required to provide in order to finish this task – assistance which, when combined with the original list of work, may be considered unreasonable by the court.
- Requiring Apple to break into and image the phone for them anyway would completely obsolete the necessity of designing a backdoor tool from the first order.
In other words, if the FBI is planning to have Apple perform a physical extraction of this extra data, then they are forcing Apple to create this backdoor tool for a separate reason, as it is completely unnecessary if Apple will be forced to extract the contents of the device in the end. It would also mean that all of this extra work is being hidden from both the courts and from Apple, possibly because the combination of the two AWA orders would have constituted “unreasonable” assistance in the court’s view. It completely modifies the purpose of the first order as well; we’ve now gone from having a single tool with a very specific purpose to having two separate tools to create a modular platform for the government to use (via the courts) as each piece becomes needed. The middle overlap for these two components is the entirely redundant and useful only for a law enforcement agency looking for a modular forensics toolkit at their disposal, and such work would never have been necessary if Apple simply broke the PIN and delivered a disk image as a lab service.
The motives, then, for forcing the creation of this backdoor tool, would of course be to create a tool that they can compel for use in the future, and has very little to do with the device they’re trying to get into now.
The Third, and Sloppiest, Option…
There is a third option here, and that is that FBI doesn’t care about the forensic integrity of the device at all, and is willing to risk allowing applications to self-destruct their own contents by following the extremely unsafe practice of using the iPhone’s user interface to read content. I’ve written about why this equates to dumpster diving in another blog post.
This ultimately isn’t what FBI’s statement indicated, and if you read the wording, they are speaking in the context of a direct copy of data. Still, this is a frightening idea, and given the mishandling of the iCloud account password, it’s at least possible to conceive someone may be thinking about the phone as forensically expendable in this way.