The FBI Knocking on Apple's Door: Can You Unlock this iPhone, Please?

IV. Requested Assistance

10. I know based on my training and experience, knowledge of this case and review of Apple's publicly available information that the SUBJECT DEVICE is an iPhone 5c that was designed, manufactured, and sold by Apple. Apple also wrote and owns the software operating system marketed under the name of "iOS," and thus is the owner of the operating system for the phone at issue. Apple's software licensing agreement specifies that its software is "licensed, not sold," and otherwise prohibits users from transferring any ownership of the iOS software.

11. Apple strictly controls the hardware and software that is used to turn on and run its phones. According to Apple's "white papers" and other publicly available information about the security of its iOS programs, Apple has designed its mobile device hardware as well as its operating system software to only permit and run software that has been "signed" cryptographically by Apple using its own proprietary encryption methods. Apple has also added hardware- enforced features to the A6 processor found in the iPhone 5C which verifies software using Apple's cryptographic signature, that Apple devices can only run verified/signed software during the booting process (when the phone is being turned on). These features prevent the government from running any other software on the SUBJECT DEVICE to attempt to recover data.

12. In addition, an iPhone 5c is encrypted by a combination of two components one user-determined passcode, and one unique 256- bit Advanced Encryption Standard ("AES") key (referred to as a "UID") fused into the phone itself during manufacture. Both passcode components are required in combination for the phone to decrypt its contents. When a user inputs the user-determined passcode, the phone conducts a complex calculation as determined by Apple's software (and unknown to the government) which combines the UID with the user passcode. If the result is accurate, the data is decrypted.

13. If one does not know the user-determined passcode, it is possible, although time-consuming, to manually input passcodes one at a time until the passcode is determined. Apple, however, has also designed and written code for additional non-encryption-based features which the government cannot overcome on its own. First, Apple has designed a non-encryption, auto-erase function as part of its iOS, which destroys encryption key material required for decryption, and hence renders the contents of the device incapable of being decrypted after ten consecutive incorrect passcode attempts. If this erase function is enabled, iOS will instantly, irrecoverably, and without warning erase the encryption keys necessary for accessing stored data. Because iOS software must be cryptographically signed by Apple, only Apple is able to modify the iOS software to change the setting or prevent execution of the function. There is no way to know by examining the outside of the phone whether or not this function has been turned on in the SUBJECT DEVICE, although, in this instance, I suspect that it has because I am told by an employee of SBCDPH that the SUBJECT DEVICE was provided to Farook with the auto-erase function turned on, and I know from my review of the most recent backup from the iCloud that it showed the function turned on.

14. Relatedly, Apple has designed and written code for another non-encryption based feature in that its iOS operating system is coded to invoke time delays which escalate after repeated, unsuccessful passcode entries. This means that after each failed passcode entry, the user must wait a period of time before another attempt can be made. From Apple documentation and testing, the time delays for the iPhone 5C are invoked by Apple software upon failed login attempts. Apple documentation states that the software invokes no delay for the first four attempts; a 1-minute delay after the fifth attempt; a 5-minute delay after the sixth attempt; a fifteen minute delays after the seventh and eight attempt; and a 1- hour delay after the ninth attempt. Additional wait times can also be added into the software.

15. In order to allow the government to perform the search ordered in the warrant, and the ability to test passcodes to decrypt the SUBJECT DEVICE without unnecessary delay or fear that the data subject to search under the warrant would be rendered permanently inaccessible, the government requests that Apple be ordered to provide the FBI with a signed iPhone Software file, recovery bundle, or other Software Image File ("SIF") that can be loaded onto the SUBJECT DEVICE. The SIF would load and run from Random Access Memory ("RAM") and would not modify the iOS on the actual phone, the user data partition or system partition on the device's flash memory. The SIF would be coded by Apple with a unique identifier of the phone so that the SIF would only load and execute on the SUBJECT DEVICE. Since Apple's software currently has the capability to query hardware for unique identifiers (serial numbers, ECID, IMEI, etc.), the SIF could be created to only function on the SUBJECT DEVICE, which would mitigate any perceived security risk to Apple iOS software. The SIF would be loaded via Device Firmware Upgrade ("DFU") mode, recovery mode, or other applicable mode available to the FBI. In addition, Apple could run the SIF from within its facility, allowing passcodes to be tested electronically via remote network connection.

16. Once active on the SUBJECT DEVICE, the SIF would have three important functions: (1) the SIF would bypass or disable the auto-erase function whether or not it has been enabled on the SUBJECT DEVICE, meaning that multiple attempts at the passcode could be made without fear that the data subject to search under the warrant would be rendered permanently inaccessible; (2) the SIF would enable the FBI to submit passcodes to the SUBJECT DEVICE for testing electronically via the physical device port, Bluetooth, Wi- Fi, or other protocol available on the SUBJECT DEVICE (meaning that the attempts at the passcode would not have to be manually typed on the phone's screen), or alternately, Apple could be given the phone as is done when Apple recovers data from earlier iOS versions, but provide the government remote access to the SUBJECT DEVICE through a computer allowing the government to conduct passcode recovery analysis. This would allow the government to conduct the analysis without Apple actually providing the government with the SIF; and (3) the SIF would not introduce any additional delay between passcode attempts beyond what is incurred by the Apple hardware.

17. Based on my (and the CEAU's) review of available information about Apple's programs, Apple has the technological capability of providing this software without it being an undue burden. Apple routinely patches security or functionality issues in its iOS operating system and releases new versions of its operating system to address issues. I know from my training and experience, and that of my fellow agents, that providers of electronic communications services and remote computing services sometimes must write code in order to gather the information necessary to respond to subpoenas and other process, and that this is not a large burden.

18. However, in an abundance of caution, the government also requests that the order permit Apple to satisfy the three goals of the SIF and the loading of the SIF onto the SUBJECT DEVICE in an alternative technical manner if mutually preferable.

I declare under penalty of perjury that the foregoing is true and correct to the best of my knowledge and belief. Executed on February 16, 2016, Riverside, California.