A Technical Perspective on the Apple iPhone Case
eff.org
eff.org
Some questions to ask:
- Has the FBI stated that they do not already have the pin for the device? They did state that the device is locked but I didn't see it stated that they don't already have the pin. So do they? It's not a crazy question. They have a good reason to pretend they don't have it.
- Has the FBI stated that the device was ever in the physical possession of the suspect during the time since the last backup? Or are we all just assuming this? This information is not going to be given voluntarily.
- If one FBI agent has provided testimony that he and some Apple engineers could find no feasible alternative, that should be taken as the findings of just that one agent, not the entire government. What about the rest of the FBI? What about the NSA? If these questions aren't asked, the FBI has no reason to answer.
The key derivation function is known, right?
- FBI wants to turn Apple's "good security" campaign into something that makes them look like they are not willing to help with the terrorism investigation (thereby, if all goes according to plan, the public will value their own security less than national security).
- FBI wants to be sure the data stays intact. It would be bad for them if they took out the chip and it got cleared. (This is clear in the document; it says the OS should run solely in RAM and make no writes to disk.)
- FBI wants to do this again in the future. Once the software is made and signed, it will be easy for Apple to (a) give it to them so it can be used for other phones or (b) run it themselves on the other phone. If Apple refuses the second time around, FBI can always take out the chip and do it themselves.
- FBI doesn't know everything that Apple knows about where the data is stored on the filesystem, assuming they can get as far as the filesystem. It's easier for them to have a proper UI they can use the phone through.
Removing the storage chips from the device would mean breaking a very strong key, perhaps 128-bit AES, which is not a desirable offline brute-force attack.
That strong key is derived from the PIN combined with a unique device ID which cannot feasibly be extracted from the processor. So an offline attack needs to crack full AES, but an online attack by running modified OS code on the device itself means only the weak PIN needs to be attacked (just 10,000 distinct combinations, roughly equivalent to a 13 or 14 bit key).
I mean it might take a lot of practice but if you have the time and money and chip samples to practice on...
One thing is for sure- for phones with TouchID where you only need to enter the pin on reboot, it makes sense to make the pin something other than numeric and longer than 4 digits.
EDIT: This seems like a pretty good primer on iOS full disc encryption. http://www.darthnull.org/2014/10/06/ios-encryption
Difficult doesn't necessarily mean impossible: https://www.technologyreview.com/s/519201/tamper-proof-chips...
Is it publicly known how the key is physically stored in the chip and if there is active tamper resistance?
It might be a lot of work to break out the tiny probes and the tunneling microscopes or whatever and get the key that way, but at the current level of terrorist attacks in the US the FBI should be afford the resources for that.
As I understand it, for an offline attack on the encrypted contents of the flash, you would need that UID.
Like, is there some kind of chip microscope or reverse engineering process that can not just look at circuitry, but also detect flash memory state?
UPDATE: answered earlier by tzs: https://www.technologyreview.com/s/519201/tamper-proof-chips... It's expensive, but seems well within reach of governments for targeted investigations.
For example the recent error 53 bug, in theory all they had to do was roll back a commit. But it still took weeks to get it out.
Edit: Another developer here thinks there's probably a developer soft-switch to disable the 10-strikes feature anyway; if that's true then it's even more trivial?
The creation of this backdoor would likely rank as one of the highest pressure coding events in the security engineering groups lives. Yeah, they'll just whip that up in no time.
Anyone who codes these secure systems would reasonably estimate the perfectly safe removal of all these security features combined with adding an automated PIN entry system, and then lets not forget the creation of a secure environment to isolate this code from any possible misuse... somewhere on the order of man-years to develop, test, document, and deploy. Much can be done in parallel, so it's on the order of a team of 6 - 10 engineers working for at least two to three months straight.
2) I agree the automated PIN entry system makes things more difficult and if Apple pointed out that it would be far faster in terms of combined "hacking" + development time to just have people do the PIN entry the FBI would probably back down on that request.
3) Oh, you're absolutely right, it would take a great deal of additional effort to secure that code in the leaky sieve that's Apple's internal server infrastructure. I wouldn't want it to end up in the wild like the iOS, OSX and all the pro-app source code did (what, what?)
You really think Tim and Dan are just going to let an engineer whip up a build with these features and sign it willy nilly with their production code-signing key, deploy it to the subject phone, and just start punching out PINs? If Apple hasn't already spent several man-years of engineering time on just investigation and tech support for this particular case I would be shocked.
You claimed creating this build should be easier than a public release. From my perspective it's an order-of-magnitude harder, because it's a new process which must be developed and scrutinized from top to bottom and not a well-oiled machine. I've worked inside Apple, and this is not a negative reflection on the competency of their developers in any way. For Pete's sake, this backdoor isn't getting developed as a late-night hackathon!
Of course we're just throwing speculative arguments past each other so it's not so productive. I think I know what I'm talking about, and so do you, but it doesn't really matter much either way :-/
Summary
EFF supports Apple's stand against creating special software to crack
their own devices. As the FBI's motion concedes, the All Writs Act requires
that the technical assistance requested not be "unduly burdensome," but
as outlined above creating this software would indeed be burdensome,
risky, and go against modern security engineering practices.
Trotting out bullshit secondary arguments to try to come up with excuses beyond that are not only unnecessary but are potentially damaging to the root case of protecting personal data from government interception, especially when inevitably others will come out of the woodwork to contradict those statements. We don't need to come out on the wrong side of this and have the general public distrust tech companies any more than they already do.
You make a good observation that the EFF and Apple are on the same side here. I just don't see how that's a surprise, given that all the control of users' devices Apple exerts is primarily for the purpose of protecting the privacy of the user, something EFF also cares about.
In this case, we also know that Apple's control of users' devices has another motive: having the final say over what kind of 3rd party software users are allowed to use and install. Apple uses this control to censor apps that they deem inappropriate or directly compete with their own software, amongst other inscrutable whims.
Surely that would just make one a mindless hater, no?
Actually having 'full' control over one's own hardware is pretty much impossible (and AFAIK will remain so for the foresee-able future without some major changes among the companies that make hardware and write firmware).
Apple has a varied track record on the degree to which users are allowed to have control, they do better on OSX and worse on iOS (which is a big reason I use Android and a MacBook Pro).
That said, this particular incident is an example of Apple standing up for the right of consumer to control their devices , particularly to control who has access to the data on them).
As such, it seems completely reasonable for the EFF (and the rest of us) to support Apple in this case. Failure to do so because you dislike some of Apple's other decision is cutting off the nose to spite the face
You may be missing it, yes.
As I understand it, the issue is not about software, but about the security keys. It isn't about some code being written, but about signing that code with the root certificate of all iOS devices.
Nobody is celebrating their closed-source codebase as a paragon of security. If Apple used open source code, sure the FBI could pay a third party to write the code, but Apple would still be right to refuse to sign it.
[edit: softened tone]