If you've lost that key you can't get in anyway. That's what a factory reset (which would not include the old decryption key) update is for. That scenario, updating with removal of the previous configuration, is pretty much baked in for both the case you mentioned and the reselling/refurbishing the device circumstances.
It's very difficult to bootstrap something like that and also make it updatable. If the key can be changed, then some software X can update it, and that software itself must verify the key. You have X updating Y and Y being ultimately responsible for updating X. Not so simple.
Given that nothing like that is out there as far as I know, you'd need a more specified model to prove it's even possible. It's not obvious from the proposal above.
- loader A stores a (PubKey,NextLoader) and has the ability to blank (via actual blanking or deletion of an encryption key) the entire device.
- loader A provides a new-key(PubKey,NextLoader) method which blanks the remainder of the device.
- Loader A also provides a update-loader(NextLoader) method that doesn't, but also doesn't update the PubKey. Before accepting the new NextLoader, it verifies it against the stored pub key.
Could also allow things like updating the PubKey if the update is signed by the previous PubKey
Spec presumes only access is via the loader A api, PubKey would really need to be stored somewhere safe (HSM, TPM, etc) to discourage direct hardware access.
Probably also could use the PubKey to encrypt the NextLoader.
New phones ship either:
- without a pubkey or next-loader, and require initial provisioning to do anything (fairly inconvenient)
- ship with a flag set that prevents updating the loader, ie: requires updating the key (less secure, probably need to specify further how this occurs to avoid the security hazard from un-updated phones from being too great).
It doesn't. The model I presented presumes that it is unchangeable.
> anyone with physical access for five minutes can permanently brick the phone, without opening it
Pick one:
- you can always get your phone working, even if you forget your key & only you can apply updates to any software on the phone. Anyone can replace the loader (but this wipes all other data).
- you can always get your phone working, even if you forget your key & only a third party can provide new versions of the loader.
- if you forget your key, your phone is permanently bricked.
> Also, how can loader A modify itself?
It can't.
In general though, it's fairly straight forward to have code copy itself into ram & run from there while overwriting it's source. The problem is that opens the potential to brick the phone (just like any method that allows updating the loader).
To avoid bricking in all cases, one _must_ assume that there is some un-replaceable software (or hardware mechanism to start software).
Lots of things become possible once one is willing to decap ICs to get at the internals.
I'd expect security consious parts (ie: all of the theoretical "loader A") would need to run in SRAM (ie: ram that is in the same IC and thus harder to get at than external DRAM chips) or some other mechanism.
At that point, it becomes a question of physical hardening within the ICs. Some manufacturers have done things like put metal layers over fuses (to prevent them from being changed), I'd imagine the same could be done (at some cost) for a larger area of the chip. I'd imagine HSMs (hardware security modules) and TPMs (though these aren't as good) probably implement some of that. There also exist some chips targeted towards security purposes (not aware of any processors off hand) that could be used .
Perhaps the ability to completely restore shouldn't require your own signature.