4 ms·
This really isn't difficult to do: - loader A stores a (PubKey,NextLoader) and has the ability to blank (via actual blanking or deletion of an encryption key)
by codys 11y ago
This really isn't difficult to do:
- 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).
- ikeboy 11y ago>loader A provides a new-key(PubKey,NextLoader) method which blanks the remainder of the device. Assuming this updates the loader, that means anyone with physical access for five minutes can permanently brick the phone, without opening it. Are we sure we want that? Also, how can loader A modify itself?
- codys 11y ago> Assuming this updates the loader 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).
- ikeboy 11y agoI'm coming around to believing it's possible. Now I'm wondering whether you can place malicious RAM in the phone that changes instructions on the fly. Is that feasible?
- codys 11y agoLots 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 .
- ikeboy 11y agoWouldn't the regular ram also need hardening? If I can modify the ram, I can change the OS that's loaded to ram. Does this hardening slow it down?