Slashdot Mirror
Apple's iPhone Already Has a Backdoor
Nicola Hahn writes: As the Department of Justice exerts legal pressure on Apple in an effort to recover data from the iPhone used by Syed Rizwan Farook, Apple's CEO has publicly stated that "the U.S. government has asked us for something we simply do not have, and something we consider too dangerous to create. They have asked us to build a backdoor to the iPhone." But, as one Windows rootkit developer has observed, the existing functionality that the FBI seeks to leverage is itself a backdoor. Specifically, the ability to remotely update code on a device automatically, without user intervention, represents a fairly serious threat vector. Update features marketed as a safety mechanism can just as easily be wielded to subvert technology if the update source isn't trustworthy. Something to consider in light of the government's ability to steal digital certificates and manipulate network traffic, not to mention the private sector's lengthy history of secret cooperation.
Related: wiredmikey writes: Apple said Monday it would accept having a panel of experts consider access to encrypted devices if US authorities drop efforts to force it to help break into the iPhone of a California attacker. Apple reaffirmed its opposition to the US government's effort to compel it to provide technical assistance to the FBI investigation of the San Bernardino attacks, but also suggested a compromise in the highly charged legal battle.
In his first public remarks since Apple CEO Tim Cook said he would fight the federal magistrate's order, FBI Director James Comey claimed the Justice Department's request is is about "the victims and justice."
In his first public remarks since Apple CEO Tim Cook said he would fight the federal magistrate's order, FBI Director James Comey claimed the Justice Department's request is is about "the victims and justice."
In the context of this article it is worth pointing out the letter that Tim Cook sent out to Apple employees:
http://arstechnica.com/tech-po...
I believe he makes good points, and where ever we end up, it should be because of proper discussion understanding implications, rather than because 'Apple is evil' mantra, that will end up burning everyone.
Jumpstart the tartan drive.
Every OS does not have that problem. I'm not even sure that iOS does. It's possible Apple has a way to forcibly push an over the air OS update to your phone, but I don't recall ever hearing any confirmation of that. As far as non-mobile OSes, the only one I've ever heard about forcing updates on you is Windows 10.
>> Literally EVERY OS has this concern
I'm not sure you understand the concern then. The feature in question is, "ability to remotely update code on a device automatically, without user intervention"
Windows allows you to disable automatic updates (even on Windows 10). Linux famously allows you to only put the specific code you want into your OS. (Google "compile kernel", etc.) If iPhones require automated updates or they will stop functioning, I'd say that concern is still fairly unique to the iPhone platform.
What they're talking about is putting the phone into Device Firmware Update mode, like this. Only then will they be able to update it remotely and on the newest iPhones that'd also wipe the encryption keys. But not on the model in question here.
Live today, because you never know what tomorrow brings
A normal update does require you to unlock the phone to accept the update. They're talking about leveraging recovery mode which can be used to force load an image onto a phone that might be otherwise unusable. See here - https://support.apple.com/en-u...
There is no vulnerability here. There are no such thing as "automatic updates" of iOS. There are "auto-downloaded" updates... but you ALWAYS have to install them manually... and to do so you need to unlock the device AND put in your iCloud username and password.
There is NO backdoor here.
Wrong.
It's still unclear; does the FBI want to give the phone to Apple so they can break in, or do they want apple to give them the tools to do it themselves?
The order clearly states that Apple is not required to provide the software created. Many people, including myself, believe that there is an unspoken motivation in this case to have a precedent which allows law enforcement to force software companies to produce software to enable access to encrypted systems, but it is a supposition not substantiated by the court documents.
The court documents compel Apple to create software which will make it easy for the DOJ to break in, but not that Apple do the final step of actually breaking in.
If it's the former, then Apple should get it done, then destroy the tools and cal it a day.
Which Apple probably would have done if the DOJ had made the request under seal to keep it secret, as Apple requested. However, the government made it a public request, which supports the idea that the government wants either a legal precedent or an excuse to ask Congress to change the laws so they can force software companies to create hacking software.
What is clear is that getting the data from the phone is not secondary to the Us vs Them bullshit going on now.
I think that must be a typo. It is clear that this debate is not about this case, but rather what the DOJ can successfully force software companies to do, or an excuse to get new legislation so they can force hacking by software companies.
This is all distraction, as operating system configuration and patching is not a "backdoor'.
The best response to the FBI's request I've read thus far comes from the noted IOS forensics security guru, Jonathan Zdziarski where he wrote the following
An instrument is the term used in the courts to describe anything from a breathalyzer device to a forensics tool, and in order to get judicial notice of a new instrument, it must be established that it is validated, peer reviewed, and accepted in the scientific community. It is also held to strict requirements of reproducibility and predictability, requiring third parties (such as defense experts) to have access to it. I've often heard Cellebrite referred to, for example, as the Cellebrite instrument in courts. Instruments are treated very differently from a simple lab service, like dumping a phone. I've done both of these for law enforcement in the past: provided services, and developed a forensics tool. Providing a simple dump of a disk image only involves my giving testimony of my technique. My forensics tools, however, required a much thorough process that took significant resources, and they would for Apple too.
The tool must be designed and developed under much more stringent practices that involve reproducible, predictable results, extensive error checking, documentation, adequate logging of errors, and so on. The tool must be forensically sound and not change anything on the target, or document every change that it makes / is made in the process. Full documentation must be written that explains the methods and techniques used to disable Apple's own security features. The tool cannot simply be some throw-together to break a PIN; it must be designed in a manner in which its function can be explained, and its methodology could be reproduced by independent third parties. Since FBI is supposedly the ones to provide the PIN codes to try, Apple must also design and develop an interface / harness to communicate PINs into the tool, which means added engineering for input validation, protocol design, more logging, error handling, and so on. FBI has asked to do this wirelessly (possibly remotely), which also means transit encryption, validation, certificate revocation, and so on.
Once the tool itself is designed, it must be tested internally on a number of devices with exactly matching versions of hardware and operating system, and peer reviewed internally to establish a pool of peer-review experts that can vouch for the technology. In my case, it was a bunch of scientists from various government agencies doing the peer-review for me. The test devices will be imaged before and after, and their disk images compared to ensure that no bits were changed; changes that do occur from the operating system unlocking, logging, etc., will need to be documented so they can be explained to the courts. Bugs must be addressed. The user interface must be simplified and robust in its error handling so that it can be used by third parties.
Once the tool is ready, it must be tested and validated by a third party. In this case, it would be NIST/NIJ (which is where my own tools were validated). NIST has a mobile forensics testing and validation process by which Apple would need to provide a copy of the tool (which would have to work on all of their test devices) for NIST to verify. NIST checks to ensure that all of the data on the test devices is recovered. Any time the software is updated, it should go back through the validation process. Once NIST tests and validates the device, it would be clear for the FBI to use on the device. Here is an example of what my tools validation from NIJ looks like: https://www.ncjrs.gov/pdffiles...
During trial, the court will want to see what kind of scientific peer review the tool has had; if it is not validated by NIST or some other third party, or has no acceptance in the scientific community,
Something which I had been questioning from the day I heard the phone was not the terrorist's but owned by a country government in California, couldn't something such as AirWatch be used to unlock the phone?
My answer came over the weekend when I read this article which stated the county paid for but never installed such software.
Having been responsible for setting up iPhones for a state agency, one of the steps was installing AirWatch which we did have to use on a few occasions when people locked themselves out.
Not installing such software is either incompetence or laziness on the part of the IT folks who handed out these phones.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
You have a few factual errors. The passcode wasn't changed. The iCloud account password was. The distinction matters quite a bit, since one is used to unlock the phone, while the other is used by the phone to access external Apple services, including iCloud Backup. The hope here was that they could initiate an automatic iCloud backup by charging the iPhone while it was in range of a recognized WiFi network. Apple has the ability to access data that's backed up to iCloud, so they'd be able to provide the FBI with the lawfully-requested contents of the iPhone if a fresh backup were initiated, and they could do so without needing to build malicious tools.
Unfortunately, the iPhone belonged to the county (since the shooter was a government employee). For reasons that are unknown but very suspicious since the iCloud backup technique is known to the FBI and has proven useful in the past, in the day immediately after the attack, the FBI ordered the county to reset the user's iCloud password, which the county was able to do by logging into his work e-mail that was tied to his iCloud account and initiating the password reset from there. As a result, the iPhone now lacks the correct credentials to create an iCloud backup. The FBI then tried to downplay the matter in the footnote of some court documents by implying offhandedly that it was local yokels who made a mistake, until the "local yokels" spoke up in their own defense by pointing out that they were acting on FBI orders.
So, going back to your original question, the FBI wants one thing: a change in precedent that allows them to put a stop to strong encryption. Demanding access to the current contents of the phone (despite already having a recent backup) while sabotaging the best known way to get at it is just a means to that end.