3

Is it possible to deploy software in such a way that a rogue actor who has physical access to the hardware is unable to glean any information on the code that is running or what is being stored in memory?

I know there are some more “experimental” approaches such as encrypting data at RAM level and storing unencrypted data in the CPU cache (e.g. TRESOR). Are there any other ways of solving this currently? Will something like a fully homomorphic encryption scheme help with this once they become practical speed-wise?

  • TRESOR keeps encryption keys in the x86 debug registers, not CPU cache. – forest Sep 10 '18 at 2:34
2

Full memory encryption is out of the experimental stage, but I can't name any hosting services using it yet. It's supported as an operating mode for AMD Epyc and Ryzen Pro - https://developer.amd.com/amd-secure-memory-encryption-sme-amd-secure-encrypted-virtualization-sev/ - so we'll probably see it available soon.

The intent is specifically to prevent a rogue admin from stealing the data from client VM operating in his cloud infrastructure.

The encryption used is AES in tweaked ECB mode, lacking authentication, so it's not a secure system. Specific attacks on it have been proposed: https://arxiv.org/ftp/arxiv/papers/1712/1712.05090.pdf

Homomorphic encryption is very far from being practical for remote hosting - if you can afford the overhead, you can run it on a Raspberry. The interest in it is currently aimed at privacy-preserving public records for voting and transactions. Homomorphic encryption really comes into its own in a blockchain context, so we're likely to see more applications.

It's possible to design a system that protects the data even with compromised hardware. But the x86 architecture wasn't designed with attacks in mind, and it's proving difficult to work around its implicit trust. Since you're asking about current ways, the most straightforward way to get provable security is building an ASIC that enforces authenticated encryption ("There is only one mode of operation, and that is secure") and only accepts signed commands and data.

However, even current insecure memory encryption (strong cipher, weak mode) does make it more difficult to surreptitiously steal your the data. It won't do for classified or highly valuable information, which is worth risking exposure for, but, combined with active security measures and oversight, can make opportunistic data mining a lot less likely.

1

Is it possible to deploy software in such a way that a rogue actor who has physical access to the hardware is unable to glean any information on the code that is running or what is being stored in memory?

No, this is impossible, for the following reasons:

  1. Physical access pretty much always means game over, so this alone would be a strong indication that what you want is not doable.

  2. No matter how much you try to protect your code and the data it produces, in the end the processor has to have access to both the machine code of your program and the data it works with. Even if your code self-decrypts and encrypts every piece of data before it is moved from a CPU register into RAM, the encryption keys must still be stored somewhere (possibly in registers, too, but that only means they're harder to access - not impossible). I can imagine various ways to access this data, such as dumping the whole RAM into a file, running the code in a debugger, suspending the machine and store away the suspended state for inspection after the machine wakes up again, changing the kernel or libc to help spying on your code and so on.

I don't understand what you mean with "will something like a fully homomorphic encryption scheme help with this", but I doubt very much that it will change point 2, whatever it is.

TPMs provide a way to store keys and do encryption and decryption inside the TPM, so the keys aren't exposed, but again, this only makes it more difficult to get at the relevant information, not impossible.

  • It's not completely impossible, but it is difficult. For example, the vCage technology allows removing trust for anything but the physical chipset itself (RAM, PCI devices, even the BIOS isn't trusted), and remote attestation can allow even a remote boot to be measured. I'm not sure how vCage deals with JTAG, though. Perhaps it only runs on systems with JTAG disabled. – forest Feb 20 '18 at 2:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.