3 ms·
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
by 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 agoBurning 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.