by Virgil Vaduva

For all the criticism Apple receives from users about its products, design or pricing, there is one thing that Apple should be commended for, namely the focus on security of their users’ data and implementation of encryption across all their mobile devices by default. In fact both Apple and Google now enable full device encryption by default on all devices running iOS version 8 or Android Marshmallow (version 6); this means that full disk encryption will be mandatory for all users.

This decision has broad implications from a security perspective: devices which are stolen or lost will be safe from malicious users which attempt to recover data from them via brute force attacks against a users’ password, causing the device to be “wiped out.”  Malicious users will also be unable to mount the encrypted volume of a device in order to read data from it.

Of course, the government has a problem with this.

The recent case of the San Bernardino shooting spree is what brings us here. One of the shooters’ iPhone (model 5c) was encrypted and the FBI is unable to brute force the password. And when the FBI cannot get it their way, they go to a judge and ask for a piece of paper that would force someone to help them out, in this case, Apple.

In a document titled “Order compelling Apple Inc to Assist Agents in Search,” a Federal magistrate ordered Apple to take several steps to undermine the security of the suspect’s iPhone.

SB Shooter Order Compelling Apple Asst iPhone

The steps demanded in the order including (1) bypassing the auto-erase feature, (2) allow the FBI to repeatedly submit passwords to unlock the device and (3) eliminate the delay introduced by using incorrect passwords.  If you don’t think that is bad enough, the FBI is even demanding a custom-built iOS release which has the three features specified above disabled, hard-coded with the phone’s UDID that can be loaded on the phone via the native Device Firmware Upgrade method, which would allow the FBI to continue brute-force attempts against the device.

This order is unprecedented and a blatant overreach (as usual) by the FBI investigators. Without any evidence that the phone contains any data useful to their investigation, the FBI is attempting to force a corporate entity to spend time and resources to build a custom operating system to subvert most of the security controls originally implemented in the OS.

The good news is that Apple said no. Yesterday,  Apple’s CEO Tim Cook wrote a public letter excoriating the FBI for their request and explaining how this is an unprecedented attack on the privacy of all mobile device users and also an attack on Apple’s ability to design and release secure software. In no uncertain terms, Cook said that Apple will oppose this order and the company will not comply with it:

While we believe the FBI’s intentions are good, it would be wrong for the government to force us to build a backdoor into our products. And ultimately, we fear that this demand would undermine the very freedoms and liberty our government is meant to protect.

The future will tell how far the FBI is willing to go to pursue their schemes. Will they arrest Apple employees if they refuse to comply? Will they fine Apple?

And what dangerous precedent will this establish? If anything good will come out of it, I am hoping that it will force both Apple and Google to build even more secure devices, which will be impervious to such out of band attacks in the future, even with orders from Federal judges.

I wholly support Apple for their stance on privacy and security, and so should you.

Virgil Vaduva is a Libertarian security professional, journalist, photographer and overall liberty freak. He spent most of his life in Communist Romania and participated in the 1989 street protests which led to the collapse of the Ceausescu regime. He can be reached at vvaduva at truthvoice.com.

The FBI wants backdoors in all your crypto, and UK Prime Minister David Cameron made backdoors an election promise, but as Stanford lawyer/computer scientist Jonathan Mayer writes, there’s no way to effectively backdoor modern platforms without abolishing the whole idea of computers as we know them, replacing them with an imaginary and totalitarian computing ecosystem that does not exist and probably never will.

Mayer gives the example of how stopping Android users from using crypto would require the abolition of third-party app stores, rolling back the state of the art in Web-based apps, introducing kill-switches to the platform that lets Google delete your apps and the data associated with them, and preventing jailbreaking at all costs.

He mentions that the same is true for Ios, though that’s not exactly right — it’s a felony to jailbreak many Ios devices (Iphones, but not Ipads, are temporarily exempted from this thanks to a Copyright Office ruling that expires this year), and it’s a felony to run a third-party Ios app store and supply jailbreaking tools for Ios.

DRM-locked ecosystems are already designed to prevent users from running code that their users desire, and so it’s conceptually a lot easier to understand how a government could simply say to all those companies — Sony, Nintendo, Apple, Nest, John Deere, etc — that the law required them to only approve apps with backdoors and then help the companies with their existing project of vigorously prosecuting jailbreak tool-makers, and get a much more airtight seal around users’ ability to use good crypto.

One option: require Google to police its app store for strong cryptography. Another option: mandate a notice-and-takedown system, where the government is responsible for spotting secure apps, and Google has a grace period to remove them. Either alternative would, of course, be entirely unacceptable to the technology sector—the DMCA’s notice-and-takedown system is widely reviled, and present federal law (CDA 230) disfavors intermediary liability.

This hypothetical is already beyond the realm of political feasibility, but keep going. Assume the federal government sticks Google with intermediary liability. How will Google (or the government) distinguish between apps that have strong cryptography and apps that have backdoored cryptography?

There isn’t a good solution. Auditing app installation bundles, or even requiring developers to hand over source code, would not be sufficient. Apps can trivially download and incorporate new code. Auditing running apps would add even more complexity. And, at any rate, both static and dynamic analysis are unsolved challenges—just look at how much trouble Google has had identifying malware and knockoff apps.

Continue with the hypothetical, though. Imagine that Google could successfully banish secure encryption apps from the official Google Play store. What about apps that are loaded from another app store? The government could feasibly regulate some competitors, like the Amazon Appstore. How, though, would it reach international, free, open source app repositories like F-Droid or Fossdroid? What about apps that a user directly downloads and installs (“sideloads”) from a developer’s website?

The only solution is an app kill switch.3 (Google’s euphemism is “Remote Application Removal.”) Whenever the government discovers a strong encryption app, it would compel Google to nuke the app from Android phones worldwide. That level of government intrusion—reaching into personal devices to remove security software—certainly would not be well received. It raises serious Fourth Amendment issues, since it could be construed as a search of the device or a seizure of device functionality and app data.4 What’s more, the collateral damage would be extensive; innocent users of the app would lose their data.

Designing an effective app kill switch also isn’t so easy. The concept is feasible for app store downloads, since those apps are tagged with a consistent identifier. But a naïve kill switch design is trivial to circumvent with a sideloaded app. The developer could easily generate a random application identifier for each download.5

Google would have to build a much more sophisticated kill switch, scanning apps for prohibited traits. Think antivirus, but for detecting and removing apps that the user wants. That’s yet another unsolved technical challenge, yet another objectionable intrusion into personal devices, and yet another practice with constitutional vulnerability.

You Can’t Backdoor a Platform [Jonathan Mayer]