DMcCunney wrote:I think we are talking past each other. You can hack storage mediums to run code directly from the medium, but where it that code actually executing? I'm willing to bet it's not on the micro controller that controls the storage medium. (If nothing else, incompatible instruction sets an no or insufficient RAM.)
Yes, on the micro controller. See
https://spritesmods.com/?art=hddhack for example, he actually boots up a stripped down linux on the controller on the harddisk in the end.
You'd be amazed if you knew the amount of hidden micro controllers in everyday items that's hackable. Did you know that all Bluetooth devices has a CPU and some RAM that can be hacked to some extent? See
BlueBorne.
DMcCunney wrote:I have a machine that does something like you are mentioning - it is designed so that code can be paged into memory directly from disk, and start executing as soon enough loaded for the CPU to begin execution. It doesn't have to load the entire program to begin running it. (It's a relatively ancient Unix box using an MFM drive, and various tricks were used to get performance.)
It's a bootstrap loader then. It was quite common on the early generation computers. For example, DataGeneral's Nova-series had one instruction that paged in a given block from a device and ran it.
DMcCunney wrote:In the case in question, the question is "Even if Owl could successfully access the encrypted contents of the Key, where might any programs stored on it run?" I don't see "on whatever embedded controller is in the Key" as a plausible answer.
I would say that any programs stored in the Key could probably be run on any Federation system available. We know that the key must contain a "controller" since the it can erase the content if someone tries to force a decryption. Considering the context my guess is that someone went to considerable effort to protect the contents of the Key and that includes a lot of anti-tamper protection which also means fiddling with the "controller" and it's "firmware" probably results in a wipe.
My guess is that when you want to read a particular file that's stored on the Key you need to supply a decryption key for the file in question so it can be decrypted and sent. This precludes anyone from getting the file encrypted and then brute-forcing a decryption. Send the wrong decryption key for a file too many times - wipe.
Also, has anyone considered the implication of that the Key is also a verifier? My guess is that it's not enough to have the decryption key - you must also in all likelihood answer a question truthfully for it to be activated.
Now.. I wonder what that question would be...