The question I'm most interested in is whether newer iPhones are still subject to this attack. Unless I missed it, no answer to that question is presented here.
It sure feels to me like Apple is dancing around that issue. I'm betting that newer iPhones are still vulnerable, and Apple is a bit embarrassed at dropping the ball there. (The Secure Enclave stuff doesn't necessarily protect against this attack, it depends on how it's implemented and the official documentation doesn't quite say.)
If nothing sooner, it's going to be interesting to see what happens in the fall when iOS 10 and the iPhone 7 presumably will ship, along with a new version of Apple's iOS security guide. Diffing that with the 2015 edition could prove quite educational.
Yes, it seems pretty certain the Apple is going to lose this in court, and will be required to break the security on the 5c. But newer hardware with Secure Enclave could be rendered Apple-proof by preventing an update to the Secure Enclave firmware without first unlocking the phone (or still allow a locked upgrade, but wipe all user data when upgrading in that manner). The fact that they haven't said unambiguously that they can't get into newer hardware at all definitely makes it seem like they allow non-destructive updates to SE on a locked device.
I am not a security expert, but my understanding is that the main problems for the FBI are: a) There is a timed delay for trying new passwords after enough unsuccessful attempts and b) The phone will wipe itself after 10 unsuccessful attempts.
It's pretty much only sufficient to have (a) since the delays will make it take years to guess the password by brute force.
I just ctrl-f'd for "delay" in the security guidelines[0], which claim that the secure enclave is the one that enforces the timed delay[1], so I guess the only attack vector would be if you could somehow backdoor code onto the chip. I can't find anything in the guide from a quick skim, but I'd suspect the code is on a ROM chip or is somehow prevented from an upgrade without an unlock?
> I can't find anything in the guide from a quick skim, but I'd suspect the code is on a ROM chip or is somehow prevented from an upgrade without an unlock?
This is the big unanswered question. I suspect the same, but so far have not been able to find anything that actually says so. The code is not in ROM, as it can be updated, but it could wipe data if updated without an unlock. But I can't find anything saying whether it actually is. The mere fact that it's possible isn't enough, and their silence is a bit odd.
Seems like it'd be a pretty huge oversight if that vector were open, but I agree with you that it's not very confidence-inspiring if nothing about this is out there.
Depends on your threat model. It's possible that the Secure Enclave was just intended to be a defense in depth against malware and common criminals, not something that could keep Apple themselves out. If so, I'm sure they're re-evaluating that now.
The attack that the FBI is trying to facilitate by getting Apple to make a custom OS would only work up to the iPhone 5C and earlier models. Any iPhone with the TouchID and Secure Enclave would not be susceptible to this attack (it may be to other attacks). The Secure Enclave has a hardware enforced back-off delay that would stop the brute force attack. The older iPhone 5C does not have the Secure Enclave so the brute-force protection is implemented in the operating system. As such, Apple can load a new OS on the phone that does not have those protections.
The Secure Enclave's back-off delay is not hardware enforced, it's enforced by the software running in the SE. The big question is whether the SE's software can be updated without first unlocking the device and without wiping the user's data. If such an update restriction is in place, then newer phones would not be vulnerable. If no such restriction is in place then newer phones are vulnerable, they just need the SE software to be modified instead of the main OS software. So far, I have not been able to find any concrete information about whether or not the Secure Enclave in current phones have such restrictions.
Correct, I should have clarified - I mean the back-off is enforced by a distinct piece of hardware (vs it being enforced by the OS). So theoretically they could burn in the firmware for the SE at the point of manufacturing and it could not be updated, but you could still update the phone OS like normal. I imagine they will consider doing this going forward so they cannot comply with these types of requests from the government.
Burning in the firmware would do it, but I'm not sure they want to give up the ability to update this software. I'd say a better plan would be to give the SE a small amount of internal storage. Two 256-bit fields would do. Place a master key in one field, place a secure hash of the current firmware version in the other. On boot, if the firmware hash doesn't match but the firmware signature is valid, rewrite the master key with a new random value. Then build the firmware to allow updating the hash, but only if the phone is unlocked. The normal update procedure would then be: install update, tell SE about the new hash, reboot. A "forgot passcode" update would be unable to do that second part, and would then effectively wipe the phone.
You might want a third field, so you can store both "old" and "new" firmware hashes to temporarily bridge the gap in case the procedure got interrupted at just the wrong moment. But the point being, you could allow updates without this vulnerability, and it shouldn't be particularly hard.
Obviously, that doesn't mean they've actually done it yet. I imagine they will do something like your scheme or mine for the next hardware design.
It seems likely but I'm still not entirely convinced.
I can't entirely figure out how much the former Apple engineer quoted there was involved. He clearly knows how the SE firmware is loaded, but I'm not clear about the level of his knowledge from the SE side. The described mechanism of running a signed blob from RAM doesn't exclude some sort of wipe-on-update mechanism, but it would have to be very low level, part of the hardwired secure boot stuff.
The blog post that's quoted afterwards is total speculation and contains no information about this, even though it claims to.
So, probably, but still lacking a properly definitive statement.
It sure feels to me like Apple is dancing around that issue. I'm betting that newer iPhones are still vulnerable, and Apple is a bit embarrassed at dropping the ball there. (The Secure Enclave stuff doesn't necessarily protect against this attack, it depends on how it's implemented and the official documentation doesn't quite say.)
If nothing sooner, it's going to be interesting to see what happens in the fall when iOS 10 and the iPhone 7 presumably will ship, along with a new version of Apple's iOS security guide. Diffing that with the 2015 edition could prove quite educational.