Apple, iPhones, and encryption

Much of the world appears to be watching—and commenting on—the battle between Apple and the US government over the code running on a particular iPhone. That phone was used by one of the shooters in the San Bernardino terrorist attack in December and its contents are protected by the encryption used by the iOS operating system. There are many facets to the case; its outcome could pose threats to individual privacy as well as the computer industry as a whole. Closer to home, perhaps, is the danger that government overreach could imperil the use and deployment of free software.

The phone in question is an iPhone 5C that was owned by the San Bernardino County Health Department but used by its employee, Syed Rizwan Farook, who was one of the two people who perpetrated the attack. Farook was subsequently killed during a shootout with police, but the phone was recovered. Early on, a mistake was made in the investigation, when the iCloud password for the phone was reset by the Health Department. That prevented the phone from backing up its recent data to the Apple-controlled iCloud site, which would have allowed the company to provide that information to investigators.

That means that there may be useful information stored on the phone itself that did not make it to the iCloud backup. But access to the phone is protected by a four-digit PIN that will unlock the encryption on the device. Because there are only 10,000 possible PINs, brute forcing the phone would seem like a plausible option, but there is a catch. The iOS version that is used on the phone will erase its filesystem key if ten incorrect PINs are entered, which means the flash storage can no longer be decrypted. That auto-erase feature is optional, but it is unknown if it is enabled on the target phone. That set the stage for the US government to ask Apple to create an "update" to iOS that would circumvent the feature.

$ sudo subscribe today

Subscribe today and elevate your LWN privileges. You’ll have access to all of LWN’s high-quality articles as soon as they’re published, and help support LWN in the process. Act now and you can start with a free trial subscription.

Updates to iPhones can only be created by Apple because it holds the key needed to sign the code such that the phone will install it. The FBI (or other agencies) could undoubtedly create the code needed, but cannot install it on the phone without the proper signature. So the government first asked Apple to provide such an update and, after the company declined, then has tried to use the courts to compel the company to do so.

There has been a lot of back-and-forth between Apple and the government over the last few weeks as the conflict has largely played out in public. The judge in the case has ordered Apple to assist by providing code that eliminates or bypasses the auto-erase feature of the phone, allows the FBI to submit PINs electronically (rather than enter them via the touchscreen), and gets rid of the delays introduced between PIN entries. Apple is fighting the court order, with a hearing scheduled for March 22.

The government is arguing that the All Writs Act from 1789 applies and that it can use that act to force Apple to comply with the order. Apple strongly disagrees, as its final filing [PDF] that it made before the hearing noted:

The US government has clearly been using the heinous nature of the attack to try to stir up public opinion—and potentially legislative action—against Apple. That has led to calls for Apple boycotts and various types of intemperate posturing by US presidential candidates, state legislators, and the like. Apple has also been trying to sway public opinion, but seems to be fighting an uphill battle at least partly because of the technical nature of the issue. In addition, in today's landscape, terrorism seems to trump privacy at nearly every turn.

While there is a question about how much useful information may reside on the phone, the government seems to be thinking there may be evidence of additional participants in the plot—or perhaps some kind of "dormant cyber pathogen". While that information, if present, might be useful, there are other ways to access at least some of that data. Call records and SMS metadata, for example. Or it may be possible to remove the flash chip to back up its contents and restore it after any failed attempts as Daniel Kahn Gillmor has suggested.

There are a number of concerns that Apple has expressed regarding creating the ordered iOS update. For one thing, if that update falls into the wrong hands, it could lead to widespread decryption of its customers' phones, which is something that the encryption feature is meant to avoid. Beyond that, though, is the likelihood that lots of other law-enforcement agencies will want to use the precedent to force Apple to effectively break the encryption on other phones. A New York prosecutor has already said that there are 175 encrypted phones that he would like access to. The further this code spreads, the more likely it is to fall into the wrong hands.

Apple's resistance has led to renewed calls for mandated backdoors into encryption, of course. There is a persistent and pernicious myth that somehow encryption systems can be made strong enough to resist criminals and others who would like break into them, but still leave a way for legitimate authorities to access the data. It is a kind of magical thinking that is regularly shot down by cryptography and security experts, but still rears its head periodically. When lawmakers can point to the investigation of a horrible crime that is being thwarted by encryption, those calls for a backdoor only increase.

But the truth of that matter is that any kind of backdoor enforced on Apple (and Google, Microsoft, et al.) is only going to lead to those products not being used by terrorists and other criminals. The cryptography cat is out of the bag and no amount of legislation will put it back. Those who want to communicate in ways that cannot be intercepted will find ways to do so.

And that leads us back to free software, which is instrumental in providing freely available strong encryption. Eventually, lawmakers will realize (as agencies like the NSA already have) that free software is a threat to their dream of backdoors. If someone can buy an Android phone, say, and put their own custom firmware on it, they can ensure (within some limits, obviously) that the encryption in that system does not implement the backdoor. When faced with situations like that, lawmakers typically take that next step and ban the "circumvention" mechanism being used.

If events follow this path—and there is certainly a strong possibility that they won't—it could well be a nightmare for the privacy-conscious as well as for free-software developers and advocates. We have already seen signs that device makers may disallow third-party firmware on their devices due to government regulations. That could certainly expand, such that finding "jail breaks" will be needed to put the code of our choice on "our" devices.

The end game in this dystopian scenario would extend that kind of "protection" to more general-purpose computers: laptops, desktops, and servers, for example. That has been a persistent worry over the years with technologies like DRM, UEFI Secure Boot, and remote attestation of running software being seen as having the potential to enforce this kind of control. Even under those conditions, though, one suspects that criminals, at least, would find ways around this kind of draconian, authoritarian regime.

Encryption is simply a tool. It can be used for an enormous number of important and entirely legitimate tasks, but it can also be used by the "bad guys". As many have noted, that is true of many, if not all, tools. Forcing companies to circumvent the features they have added to protect their customers' data will ultimately not be effective, but it also will have many unintended (hopefully) side-effects that make it a dangerous step down a slippery slope. Apple is on the right side of this fight.

Note: you can avoid this step in the future by logging into your LWN account.