Apple and FBI: PIN Codes to Update Firmware, Code as Free Speech, Legislative Clarification

In three recent developments, Apple appears to want

(1) to develop a security improvement that would require a PIN code to update firmware

(2) to make a free-speech objection to the magistrate’s order that is develop software that enables the FBI to try a unlimited number of passcodes on the iPhone in question without the device erasing itself.

(3) Congress to pass legislation that clarifies what its responsibilities in such cases should be (based on the words at 28:45 of a recent Tim Cook interview on ABC News ).

On #1 (a security feature that would require a PIN code to be entered before a firmware update can be performed)

The broad implementation of such a feature would enhance security of all computing devices that use firmware in their boot-up sequences. In the late 1990's, the Chernobyl virus wiped out the boot-up firmware in hundreds of thousands of computers, thereby turning them into expensive bricks. Recognizing this problem, vendors have taken gradual steps to improve the security of firmware against unauthorized alterations or updates. However, they have long resisted requiring individual action by the computer user to update firmware. (Such actions may, for example, involve throwing a switch on the device to enable firmware updates, or as in the case of Apple iPhones if this feature is implemented, entering a PIN code.)

The reason for such resistance has been that requiring user action could inhibit the widespread distribution of a necessary firmware patch. At the individual consumer level, this isn’t much of a problem, but in corporate environments that may have hundreds of thousands of computers, requiring individual action for firmware updates would be an expensive proposition. Of course, the very point of such a security feature is to require exactly that—no updates without explicit user permission.

On this point, since I have long been concerned that the mechanisms for protecting firmware are inadequate, I’m very much for the idea that firmware updates should require explicit user permission. Since an attack against firmware can brick a device, it’s unlike the usual software-based cyberattacks that we usually see. And so the stakes with firmware are higher, in my view—thus warranting such special protective measures. And these measures should have been implemented long ago—it’s independent of any concerns that may have arisen with the latest FBI-Apple controversy.

On #2 (arguing that it violates free speech guarantees of the First Amendment to force a company to write software that it does not want to write)

The only relevant judicial precedent of which I am aware is the Bernstein vs US DOJ decision of 1999. In this case, a three-judge appellate panel for the U.S. Court of Appeals for the Ninth Circuit agreed with a lower-court ruling that source code was protected as speech by the First Amendment. Specifically, the panel held that certain export control regulations limiting Bernstein’s ability to distribute the source code for encryption software were a prior restraint on speech that violated First Amendment protections.

(The panel’s opinion was subsequently withdrawn by the full Court of Appeals when the U.S. government asked for an en banc rehearing, but that hearing never took place.)

The present case involving Apple and the FBI falls outside the parameters established in the appellate panel ruling. Most importantly, the Bernstein ruling involved source code; the appellate ruling explicitly declined to rule on whether object code was similarly protected. Also, Bernstein sought to distribute his source code, whereas Apple has no intention of distributing any code that it might have to develop in this case. Finally, any court hearing the Apple-FBI case would have to address the difference between rules that suppress speech—the Bernstein case—and rules that compel speech.

On November 28, 2001, the U.S. Court of Appeals for the Second Circuit acknowledged the same point, rejecting the idea that object code can be regulated only to a standard applicable to speech that is purely expressive, i.e., that object code required a First Amendment analysis that treats it as combining functional and expressive elements. If that’s true, object code would enjoy First Amendment protections to a lesser degree than source code.

On #3 (asking Congress to pass clarifying legislation)

I can only note with some irony that the tech community was initially concerned that Congress *would* get involved by passing legislation and was relieved by public reports that the Obama administration would not seek legislation on this topic.

I’m not sure how legislation would pan out, but I speculate that the fact that Apple is suggesting that Congress get into the act means that it thinks its legal hand in its appeal of the magistrate’s order is weak, and that an uncertain outcome in the hands of Congress is better than a likely defeat in court.