On February 16, 2016, a magistrate judge in the Central District of California issued an order, under the All Writs Act, compelling Apple to assist the FBI in searching an iPhone 5C that belonged to Syed Rizwan Farook. Farook was one of the terrorists participating in the December 2, 2015 mass shooting at the Inland Regional Center in San Bernadino, California. 1)
Within less than 24 hours, many articles and blog posts materialized dissecting the order and pondering its implications. 2) The public commentary and outrage even resulted in Tim Cook, CEO of Apple, posting an open letter on Apple’s website restating the case for encryption technology and vowing to fight the order. 3) Commentators have varied from describing what the FBI is seeking from a “Master Key” to a design flaw to a non-issue. I have a more concerning thought, which is the purpose of this blog post.
Observe this language from the order:
“Providing the FBI with a signed iPhone … Software Image File (“SIF”) that can be loaded onto the SUBJECT DEVICE. The SIF will load and run from Random Access Memory (“RAM”) and will not modify the iOS on the actual phone, the user data partition or system partition on the device’s flash memory. … The SIF will be loaded via Device Firmware Upgrade (“DFU”) mode, recovery mode, or other applicable mode available to the FBI.” 4)
The language mirrors that in the Declaration of Christopher Pluhar which was submitted in support of the government’s motion. The suggested purpose of this assistance is to (1) circumvent the phone’s wipe-after-10-failed-lock-code-entries feature, (2) remove software delays between lock code attempts, and (3) allow unlock codes to be transmitted programmatically to the device. Essentially, the FBI wants help being able to brute forth the 4 digit pin code that locks the iPhone so they can get at its data. (Brute forcing a 4 digit lock code is trivial if the erase after 10 failures feature is disabled.) That, however, is not the danger that this order represents.
The form of assistance specified in the order, as suggested by the FBI, is that Apple should provide a modified version of iOS that can be loaded onto the device which will render the three assistances requested. That method, if possible, will result in a jurisprudential work around to the legislative process and the present debate over phone security and the limits of government backdoors. The key to understanding this is the language describing the Signed SIF’s characteristics. It must (1) be loaded via, inter alia, recovery mode, (2) be loaded and run from RAM, and (3) not modify any of the flash memory. The FBI just requested that the court compel Apple into creating a method of live booting iOS on an iPhone. Let’s call this fbiOS.
What is live booting? In simple terms, a Live Boot environment boots an entire operating system into a computer system’s memory rather than installing it to storage. 5) These types of environments are very common in Linux distributions to let users test or experience Linux without having to commit to installing it – and many specialized distributions dedicated to forensics, penetration testing, or recovery functionality also exist. 6)
Why does the FBI seem to want this? The key element, is the specification of DFU or Recovery Mode as one of the ways the hypothetical live bootable custom fbiOS must be loadable. (See “iOS Security” September 2015, available at https://www.apple.com/business/docs/iOS_Security_Guide.pdf )) Ordinarily, these two modes are used for restoring an iPhone (or other iOS device) that has become inoperable – and importantly without the lock code.
“When an iOS device is turned on, its application processor immediately executes code from read-only memory known as the Boot ROM. This immutable code, known as the hardware root of trust, is laid down during chip fabrication, and is implicitly trusted. The Boot ROM code contains the Apple Root CA public key, which is used to verify that the Low-Level Bootloader (LLB) is signed by Apple before allowing it to load. This is the first step in the chain of trust where each step ensures that the next is signed by Apple. When the LLB finishes its tasks, it verifies and runs the next-stage bootloader, iBoot, which in turn verifies and runs the iOS kernel.” 7)
If any stage of the secure boot chain fails, it triggers Recovery Mode which permits the iOS install to be updated or restored. If the Boot ROM fails (the first step) it enters DFU mode. Recovery Mode allows either attempting to “update” which reinstalls iOS without loss of data or “restore” which results in loss of data – think of it as the difference between reinstalling an operating system over itself to repair corruption of the operating system and having to do a clean install because the file system became corrupted. 8)
Let’s put these pieces together. Restore Mode will let you reinstall iOS without deleting the device’s data and without inputting the lock code. The FBI wants to be able to put its proposed fbiOS on the device in this mode – while leaving the data undisturbed. It wants its fbiOS to disable all software based security measures and provide a way for it to programmatically brute force lock codes. Finally, it wants fbiOS to load and run completely in memory.
If it successfully compels Apple to do these discrete things, it will be able to argue to future courts in future cases that Apple should make any number of features available to assist in investigations because it already demonstrated being able to do the hard part – creating fbiOS that can live boot a phone from recovery mode with custom modifications – so any other changes are trivial and not burdensome.
Imagine this one step further – since this proposed fbiOS is a validly signed version of iOS, the FBI could slip fbiOS onto any investigatory target – and that installation would leave no trace once the phone was rebooted. The ability to surreptitiously install fbiOS on an iPhone or other iOS device gives the FBI exactly what it has been craving – its own bespoke backdoor. Imagine instead of allowing them to brute force your passcode, it simply waited for the next time you entered it before cheerfully texting it to the FBI – or waited until you unlocked your phone to begin streaming its contents to them as those contents became readable to the application processor. If this parade of horribles came to be, you can be sure every other government would want their own version of fbiOS – and the security progress made over the last few years would vanish in a heartbeat.
The first item of good news is, what the FBI requested may not be possible. Whether it is technologically plausible to boot an iPhone from recovery mode with a modified version of iOS is a question only someone with much more in-depth knowledge of iPhone hardware than I possess can answer – if the answer is no (or becomes no for future iPhones) then the parade of horribles is called off for bad weather. Although, it would be a more murky question if DFU mode was used to modify the Low-Level Bootloader first, and then the modified LLB used to facilitate an fbiOS style live boot from Recovery Mode.
The second item of good news is, the FBI’s request to disable the delay between passcode attempts may only be possible, if at all, in this particular case because it is an older iPhone. The phone here is an iPhone 5C which has the older A6 processor. “On devices with an A7 or later A-series processor, the delays are enforced by the Secure Enclave. If the device is restarted during a timed delay, the delay is still enforced, with the timer starting over for the current period.” 9) The A7 chip, with the Secure Enclave feature, debuted in the iPhone 5S in 2013. Apple’s continued emphasis on building in hardware based security mechanisms may have headed this entire problem off before it started.
The third item of good news is we can expect rigorous briefing of the issues present in this case from Apple itself, and a plethora of Amici Curiae.
The opinions expressed in this blog post are mine alone, and are not the opinions of my firm. Likewise, this post is not intended as nor conveyed for the purpose of providing legal advice. I am a lawyer, but I am not your lawyer.
1. ↑ See “Memorandum of Points and Authorities” included with “Government’s Ex Parte Application for Order Compelling Apple Inc to Assist Agents in Search” at 1 [Rec Doc not available] Case No. ED 15-CR-0451M.
2. ↑ See “EFF to Support Apple in Encryption Battle” available at https://www.eff.org/deeplinks/2016/02/eff-support-apple-encryption-battle; See “Some note on Apple decryption San Bernadino Phone” available at http://blog.erratasec.com/2016/02/some-notes-on-apple-decryption-san.html; See “No, A Judge Did Not Just Order Apple To Break Encryption On San Bernadino Shooter’s iPhone, But To Create A New Backdoor” available at https://www.techdirt.com/articles/20160216/17393733617/no-judge-did-not-just-order-apple-to-break-encryption-san-bernardino-shooters-iphone-to-create-new-backdoor.shtml
3. ↑ See “A Message to Our Customers” available at http://www.apple.com/customer-letter/
4. ↑ Order Compelling Apple, Inc. to Assist Agents In Search at 2 [Rec Doc not available] Case No. ED 15-CR-0451M (emphasis added).
5. ↑ See generally “Live CD” available at https://en.wikipedia.org/wiki/Live_CD
6. ↑ See e.g. https://livecdlist.com/
7. ↑ Id. at p 5 (discussing the “Secure boot chain” of an iOS device).
8. ↑ See “If you can’t update or restore your iPhone, iPad, or iPod touch” available at https://support.apple.com/en-us/HT201263
9. ↑ Id. at p 12; See also Id. at p 7 (explaining the Secure Enclave).