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.
AFAIK having to grind off the chip package and probe the chip would apply to the iPhone 6, but the iPhone 5C does not have hardware protection for keys.
I should have been more specific: The iPhone 5C does require signed system software, and the system software enforces safeguards on key access. In contrast, on the iPhone 6, it may not be the case that an "evil update" of system software could be sufficient to subvert the ways keys that are already stored in the hardware secure enclave are protected, and you would have to try to probe the hardware.
Many (if not most) chips that need to be secure keep any secrets like private keys on a region of silicon that is tamper resistant. When you attempt to open the package, the region is destroyed beyond recovery.
Am I missing something here, or is there no reason the FBI couldn't desolder the 5C's Toshiba NAND flash chip, read its encrypted contents, and perform the desired offline brute-force attack themselves?
- 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.
That's been covered by most of the articles on the topic, but not very clearly in this article.
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).
Secure chips that store private keys generally keep them on a part of the silicon die that can't be analyzed like the rest of the chip. Any attempt to open the chip package (take off the black plastic/epoxy covering the die) results in the destruction of the secure region and methods of reading state in semiconductors (using electron microscopy) require you to somehow expose the silicon holding the private key.
Interesting, how does that work exactly? I would've thought with an accurate map of the chip package and a precise grinder you could shave off just what you wanted to expose.
I mean it might take a lot of practice but if you have the time and money and chip samples to practice on...
Apparently this iPhone 5C pre-dates the "Secure Enclave." So the key is somewhere else. Possibly a place vulnerable to a physical readout, possibly not.
10k distinct combinations-- if, and only iff, they used a 7 digit all numeric pin. The odds of this are not bad for most people, but in this case the person who had this phone has shown better than the average criminals level of OpSec.
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.
I've been wondering this as well. Even with the key derivation function, I'd imagine the CPU also has some secure keys stored in it as well, and these keys are so long that it wouldn't be feasible to brute force it. I'm not sure if thats how the architecture works but thats what I'm thinking.
What times these are. The EFF is supporting a security-by-partial-obscurity company who loves to control what its customers can do with their own devices just so that the FBI can't set a terrible legal precedent, possibly worldwide. Enemy of our enemy is our friend this time, I suppose.
This is a ridiculous non sequitur. Doesn't matter who the company is, the fact that Apple is trying to fight a court order that is on shaky legal ground, and would set a terrible precent, is what the EFF is supporting.
As the EFF explains, there are important details about how iPhones' security operates that are not public. Since when do we support an obscure security that depends on Apple's control instead of a public security in the hands of the end user? Answer: since defending Apple's control of users' devices is also defending against the FBI setting a terrible legal precedent.
Their control of users' devices is for the purpose of keeping out malware, not quite the evil thing you're making it out to be.
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.
All control is always sold to users and citizens under the guise of security. Governments do this, companies do this.
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.
I dunno why you're getting down voted here. There is definitely some major nerd cognitive dissonance going on. The ability to have full control over one's own hardware is supposed to be a core tenant of hacker-dom. Amazing how quickly it's been thrown out in this case.
I don't get it either. A black box that prevents you from running your own code on it = bad. A black box that encrypts your data and keeps it away from the evil gubbermint (let's be clear here, that _is_ what the community is saying) = good ? It's confusing.
The iPhone has never prevented you from running your own code on it. It shipped with a javascript SDK and then within the year they opened it up to objective-c programs. They charge you $99 a year for the certificate signing service, but it's really no big deal... if you can afford an iPhone you can afford $99 a year. (Hell, I think these days you don't even need to be a paid developer, the free developers can run their code on their phones.)
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.
"The ability to have full control over one's own hardware" is a core tenant of the FOSS software movement. FOSS is certainly not synonymous with hacker-dom nor with HN.
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
I'm not sure what part of their secure enclave system counts as 'obscurity' and it wouldn't make sense to hate on a company just for the sake of hating on them when they're doing the right thing this time.
Surely that would just make one a mindless hater, no?
Honest question - would this case look like if the iPhone ran some GPL3 FSF-friendly OS? Since all the source code would be publicly available, and the FBI would have installation privileges thanks to the GPLv3, could they just install whatever they wanted?
Would it be possible to physically "scan" the secure enclave chip to determine the secrets contained therein such as the burned-in unique device key and PIN?
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?
This article is silly. We're talking about making some changes to an existing codebase and dumping it on to a device. The remote code-entry thing yes is a little bit complicated I agree but disabling the "wipe on 10 bad tries" function is probably nothing more than commenting out a few lines of code. It would take them a few days to have someone type in 9999 passwords but they'd still get there.
For publicly-shipped software sure, but we're not talking about that. We're talking about what is effectively a test build on a device that would be in Apple's possession. Different kettle of fish, isn't it?
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?
Because if Apple somehow is compelled to create the functionality, but then fucks it up and the device gets wiped, that'll go down just wonderfully. So yeah, they'll just load up a quick build off a development machine and start entering PINs and hope it works!
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.
1) Obviously they'd test it on other devices first. Also I would expect the government to waive Apple's liability should things "fuck up". But somehow, I think you underestimate Apple's competency.
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 may recall the PIN counter code was buggy the first time they wrote it. It took a patch release to ensure the counter would be incremented even if power was cut immediately after the invalid result was returned. This is part of what leads me to believe the security system which ensures the counter is incremented is non-trivial and therefore its removal may also be non-trivial due to cross-dependencies.
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 :-/
Snowden has been tweeting about skepticism being warranted. Especially skepticism of the FBI statements, since law enforcement is allowed under law to lie (at least out of court) and mislead in order to further cases.
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 article is heavily biased. It is not balanced in any way. They start with a desired conclusion, and then work backwards to construct the answer to the questions.
I totally agree with you. I understand the whole argument of "if we start unlocking / decrypting our own (Apple's) phones for the government that would be bad" and Apple / their defenders should stick with that, not peddle falsehoods because they feel that's not convincing enough.
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.
I also agree with this, though that is to be expected. This whole case is massively problematic because the guy was guilty beyond doubt and in a nasty way. The law should not be punitive though, we want justice not revenge. We should not compromise our own standards to pursue potential guilty parties.
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.
So the FBI says the law suggests it not be "unduly burdensome". The EFF response is that they agree it is burdensome but they did not mention unduly so that won't pass. Then they suggest it is risky and goes against modern security engineering practices both of which are irrelevant to the FBI and the law.
51 comments
[ 5.2 ms ] story [ 111 ms ] threadDifficult 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.
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
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.
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]
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
Surely that would just make one a mindless hater, no?
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 :-/
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.
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.