The custom firmware that the FBI would like Apple to produce in order to unlock the San Bernardino iPhone would be the most straightforward way of accessing the device, allowing the federal agency to rapidly attempt PIN codes until it found the one that unlocked the phone.
But it's probably not the only way to achieve what the FBI wants. There may well be approaches that don't require Apple to build a custom firmware to defeat some of the iPhone's security measures.
The iPhone 5c used by the San Bernardino killers encrypts its data using a key derived from a combination of an ID embedded in the iPhone's processor and the user's PIN. Assuming that a 4-digit PIN is being used, that's a mere 10,000 different combinations to try out. However, the iPhone has two protections against attempts to try every PIN in turn. First, it inserts delays to force you to wait ever longer between PIN attempts (up to one hour at its longest). Second, it has an optional capability to delete its encryption keys after 10 bad PINs, permanently depriving access to any encrypted data.
The FBI would like to use a custom firmware that allows attempting multiple PINs without either of these features. This custom firmware would most likely be run using the iPhone's DFU mode. Device Firmware Update (DFU) mode is a low-level last resort mode that can be used to recover iPhones that are unable to boot. To use DFU mode, an iPhone must be connected via USB to a computer running iTunes. iTunes will send a firmware image to the iPhone, and the iPhone will run that image from a RAM disk. For the FBI's purposes, this image would include the PIN-attack routines to brute-force the lock on the device.
Developing this firmware should not be particularly difficult—jailbreakers have developed all manner of utilities to build custom RAM disks to run from DFU mode, so running custom code from this environment is already somewhat understood—but there is a problem. The iPhone will not run any old RAM disk that you copy to it. It first verifies the digital signature of the system image that is transferred. Only if the image has been properly signed by Apple will the phone run it.
The FBI cannot create that signature itself. Only Apple can do so. This means also that the FBI cannot even develop the code itself. To test and debug the code, it must be possible to run the code, and that requires a signature. This is why it is asking for Apple's involvement: only Apple is in a position to do this development.
Do nothing at all
The first possibility is that there's simply nothing to do. Erasing after 10 bad PINs is optional, and it's off by default. If the erase option isn't enabled, the FBI can simply brute force the PIN the old-fashioned way: by typing in new PINs one at a time. It would want to reboot the phone from time to time to reset the 1 hour delay, but as tedious as the job would be, it's certainly not impossible.
It would be a great deal slower on an iPhone 6 or 6s. In those models, the running count of failed PIN attempts is preserved across reboots, so resetting the phone doesn't reset the delay period. But on the 5c, there's no persistent record of bad PIN trials, so restarting the phone allows an attacker to short-circuit the delay.
Why it might not work
Obviously, if the phone is set to wipe itself, this technique wouldn't work, and the FBI would want to know one way or the other before starting. It ought to be a relatively straightforward matter for Apple to tell, as the phone does have the information stored in some accessible way so that it knows what to do when a bad PIN is entered. But given the company's reluctance to assist so far, getting them to help here may be impossible.
Update: It turns out that this bug was fixed in iOS 8.1, so it probably wouldn't work after all.
Acid and laserbeams
One risky solution that has been discussed extensively already is to use lasers and acid to remove the outer layers of the iPhone's processor and read the embedded ID. Once this embedded ID is known, it's no longer necessary to try to enter the PIN directly on the phone itself. Instead, it would be possible to simply copy the encrypted storage onto another computer and attempt all the PINs on that other computer. The iPhone's lock-outs and wiping would be irrelevant in this scenario.
Why it might not work
The risk of this approach is not so much that it won't work, but that if even a tiny mistake is made, the hardware ID could be irreparably damaged, rendering the stored data permanently inaccessible.
Jailbreak the thing
The iPhone's built-in lockouts and wipes are unavoidable if running the iPhone's operating system... assuming that the iPhone works as it is supposed to. It might not. The code that the iPhone runs to enter DFU mode, load a RAM image, verify its signature, and then boot the image is small, and it should be simple and quite bullet-proof. However, it's not impossible that this code, which Apple calls SecureROM, contains bugs. Sometimes these bugs can enable DFU mode (or the closely related recovery mode) to run an image without verifying its signature first.
There are perhaps six known historic flaws in SecureROM that have enabled jailbreakers to bypass the signature check in one way or another. These bugs are particularly appealing to jailbreakers, because SecureROM is baked into hardware, and so the bugs cannot be fixed once they are in the wild: Apple has to update the hardware to address them. Exploitable bugs have been found in the way SecureROM loads the image, verifies the signature, and communicates over USB, and in all cases they have enabled devices to boot unsigned firmware.
If a seventh exploitable SecureROM flaw could be found, this would enable jailbreakers to run their own custom firmwares on iPhones. That would give the FBI the power to do what it needs to do: it could build the custom firmware it needs and use it to brute force attack the PIN. Some critics of the government's demand have suggested that a government agency—probably the NSA—might already know of such a flaw, arguing that the case against Apple is not because of a genuine need to have Apple sign a custom firmware but merely to give cover for their own jailbreak.
Why it might not work
Of course, the difficulty with this approach is that it's also possible that no such flaw exists, or that even if it does exist, nobody knows what it is. Given the desirability of this kind of flaw—it can't be fixed through any operating system update—jailbreakers have certainly looked, but thus far they've turned up empty-handed. As such, this may all be hypothetical.
reader comments
212