Apple vs. FBI (2016) Court Filing, retrieved on February 16, 2016, is part of . You can jump to any part in this filing . This part is 4 of 17. HackerNoon’s Legal PDF Series here A. Assistance Sought From Apple In sum, the government seeks an order that Apple assist in enabling the search commanded by the warrant by removing, for the SUBJECT DEVICE only, some of the additional, non-encryption barriers that Apple has coded into its operating system, such as the auto- erase function, the requirement that passwords be entered manually, and any software-invoked delay-upon-failure functions. While the government proposes a specific means of accomplishing this, the government requests that the order allow Apple to achieve the goals of the order in an alternative technical manner if mutually preferable. As an initial matter, the assistance sought can only be provided by Apple. As discussed in the attached declaration of SSA Pluhar, 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 software 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. Further to this point, Apple strictly and exclusively 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. These security features prevent other persons, including the government, from running any other software on the SUBJECT DEVICE to attempt to recover data or test passcodes. Apple has designed the iOS 9 operating system for its phones to encrypt the data files 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") which is fused into the phone itself during manufacture. Both passcode components are required in combination for the operating system to decrypt the phone's data files. When a user inputs her 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. 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 the encryption key materials required for decryption and hence renders the contents of the device permanently incapable of being decrypted after ten consecutive incorrect passcode attempts. If this auto-erase function is enabled, the operating system will instantly, irrecoverably, and without warning erase the encryption keys necessary for accessing stored data. There is no way to know by examining the outside of the phone whether or not this function has been enabled, although, in this instance, the government suspects that it has, for the reasons explained in the attached declaration of SSA Pluhar - including because the SBCDPH has stated that the SUBJECT DEVICE was provided to Farook with that function turned on, and the most recent backup from the iCloud showed the function turned on. Accordingly, trying successive passcodes risks permanently losing the ability to access the data on the SUBJECT DEVICE. cryptographically signed by Apple, only Apple is able to modify the iOS software to change the setting or prevent execution of the function. 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. 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 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, up to a 1-hour delay after the ninth failed attempt. Additional wait times can also be added into the software. In order to overcome these hurdles, the government seeks an order requiring Apple to assist in the execution of a search warrant using the capabilities that Apple has retained along within its encryption software, such that the government can attempt to determine the passcode without these additional, non-encryption features that Apple has coded into its operating system, for the SUBJECT DEVICE only. Apple's assistance would permit the government to electronically test passcodes without unnecessary delay or fear that the data subject to search under the warrant would be rendered permanently inaccessible. Given that these features were designed and implemented by Apple, that Apple writes and cryptographically signs the iOS, and that Apple routinely patches or updates its ios to address security features or other functionality, modifying these features is well within its technical capabilities. Specifically, in order to perform the search ordered in the warrant, the government requests that Apple be ordered to provide the FBI with a custom signed iPhone Software ("IPSW") 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")[3] and accordingly would not change the operating system on the actual SUBJECT DEVICE, the user data partition (i.e., where the contents of files created or modified by the user are stored), or system partition on the device's flash memory. Importantly, the SIF would be created with a unique identifier of the SUBJECT DEVICE so that the SIF would only load and execute on the SUBJECT DEVICE.[4] Once active on the SUBJECT DEVICE, the SIF would have three primary functions: (1) the SIF would bypass or disable the auto- erase function whether or not it has been enabled; (2) the SIF would enable the FBI to submit passcodes to the SUBJECT DEVICE for testing electronically (meaning that the attempts at the passcode would not have to be manually typed on the iPhone's screen; and (3) the SIF would not introduce any additional delay between failed passcode attempts beyond what is incurred by the hardware on the SUBJECT DEVICE. The SIF would be installed on the SUBJECT DEVICE at either a government facility, or alternatively, at an Apple facility (as is done when Apple recovers data from earlier iOS versions), but passcode attempts would be electronically submitted to the device by the government. This would allow the government to conduct the passcode attempts while Apple retains the SIF. The government further requests that the order permit Apple to satisfy these three goals, and installation and operation within the SUBJECT DEVICE, in an alternative technical manner if mutually preferable. [3] RAM is computer memory that is temporary and requires power to maintain the stored information; once the power is turned off, the memory is lost. [4] 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 risk to Apple iOS software as to any other Apple device. As an alternative, the government would be willing to test the passcodes remotely while the SUBJECT DEVICE is in Apple's possession. Continue Reading . Here About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case No. 15-0451M retrieved on September 25, 2023, from is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. archive.epic.org

Apple's Conundrum: Balancing Privacy and National Security

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

20% of All General Searches in the U.S. Go Through the Default on User-Downloaded Version of Chrome

Apple vs. FBI: The Battle for Your Digital Secrets

Christopher Pluhar's Declaration in Support of the FBI's efforts to Strong-arm Apple Inc.

Digital Privacy on Trial: The Apple-FBI Battle

Unlocking Secrets: The iPhone Encryption Battle

Access Denied: The FBI's Battle to Unlock the San Bernardino iPhone

20% of All General Searches in the U.S. Go Through the Default on User-Downloaded Version of Chrome

Apple vs. FBI: The Battle for Your Digital Secrets

Christopher Pluhar's Declaration in Support of the FBI's efforts to Strong-arm Apple Inc.

Digital Privacy on Trial: The Apple-FBI Battle

Unlocking Secrets: The iPhone Encryption Battle

Access Denied: The FBI's Battle to Unlock the San Bernardino iPhone

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps