5 ms·

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

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. Here is a great technical rundown: https://blog.trailofbits.com/2016/02/17/apple-can-comply-with-the-fbi-court-order/ https://blog.trailofbits.com/2016/02/17/apple-can-comply-wit...

mikeash 11y ago
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.
- tantalor 11y ago
  > whether or not the Secure Enclave in current phones have such restrictions They don't, see https://www.techdirt.com/articles/20160218/10371233643/yes-backdoor-that-fbi-is-requesting-can-work-modern-iphones-too.shtml https://www.techdirt.com/articles/20160218/10371233643/yes-b...
  - mikeash 11y ago
    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.
- amckenna 11y ago
  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.
  - mikeash 11y ago
    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.

mikeash 11y ago

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.

tantalor 11y ago
> whether or not the Secure Enclave in current phones have such restrictions They don't, see https://www.techdirt.com/articles/20160218/10371233643/yes-backdoor-that-fbi-is-requesting-can-work-modern-iphones-too.shtml https://www.techdirt.com/articles/20160218/10371233643/yes-b...
- mikeash 11y ago
  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.
amckenna 11y ago
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.
- mikeash 11y ago
  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.