> See also: iOS jailbreaking, Android rooting, console homebrew, etc.
Let's go back a step: Why do all of those things exist?
It seems like it would be fairly easy. Use ARM TrustZone or Intel TXT trusted environments to host a non-writeable firmware, with one-time-programmable key storage, verifies that the contents of the boot memory are correctly signed by the key. If it is, then boot. If not, don't (copy in and verify a last-known-good backup image or something).
If the manufacturer wants to create an update, they take the code to the CTO's office safe, and compile and sign the image with the air-gapped machine that holds the private key.
If the private key is not leaked, jailbreaking is impossible. Doesn't seem that hard.
I am just a junior dev with a minimum knowledge of cryptography. This cannot possibly be a unique or new idea. It's literally the purpose of those modules and the purpose of code signing. So what are the business reasons for why it isn't done this way? Some ideas:
0. They didn't think of it, and I just gave them the idea. Unlikely.
1. Resources required to implement this (hardware read-only keystore, crypto primitives in the bootloader, reboot scan time, backup boot image storage space plus incoming image storage space, etc) are too expensive.
2. The possibility of losing the key and having devices they mathematically can't modify without a complete recall and replacement is too terrifying.
3. They don't care relative to the effort to implement it. They talk and litigate like they care, why doesn't this message get carried down to the new product department?
4. Decision makers don't understand the difference between the "security" obfuscation measures they're being sold right now, and potential, actual mathematically secure models proposed to them.
5. They are incompetent to actually build this. They have some pretty smart people, and accomplish other impressive projects, so this seems unlikely.
6. There's a flaw in my scheme that makes it no better than existing methods that can be jailbroken.
Let's go back a step: Why do all of those things exist?
It seems like it would be fairly easy. Use ARM TrustZone or Intel TXT trusted environments to host a non-writeable firmware, with one-time-programmable key storage, verifies that the contents of the boot memory are correctly signed by the key. If it is, then boot. If not, don't (copy in and verify a last-known-good backup image or something).
If the manufacturer wants to create an update, they take the code to the CTO's office safe, and compile and sign the image with the air-gapped machine that holds the private key.
If the private key is not leaked, jailbreaking is impossible. Doesn't seem that hard.