I got a request today that I thought was odd. I administer a VMware cluster for a school district and am familiar with disk-based encryption and encrypted VMotion. I had never heard of encryption in memory. My boss was given a heads-up that it’s something that our vulnerability scans were catching and I don’t see even a mention of that in any documentation that I have. Today we are running the most current version of VCenter 7 Update 3 and ESXi to match. If necessary we can upgrade to enable any required feature.
Iirc it’s a checkbox toggle on some no hardware, and hypervisor reboot, and that’s it right?
1 Like
I believe these are the docs you’re looking for:
TLDR the feature is called SEV and SEV-ES and AFAIK its only for newer AMD CPU’s.
The only other VM encryption stuff I can find is the usual stuff about just encrypting the disk.
2 Likes
We have some very nice hosts in my opinion. Dell R740s and R750s. From Xeon(R) Gold 6126 to Xeon(R) Gold 6326, but nothing Epyc. Thank you for the heads up. There are interesting features you lose by enabling that feature as well I see like vMotion and powered-on snapshots.
Isn’t encrypted memory made to counteract cold boot attacks (IIRC)? If my RAM is soldered (as in some laptops), this would not be a problem, theoretically, right?
I believe the point of SEV on AMD is to protect a hypervisor escape from one VM reading the contents of another. Or at least raise the bar for effort significantly - I believe each VM gets its own key to its own area of memory.
I.e., its not to protect against a memory freeze attack on a client machine.
I could be wrong though.
2 Likes
An attacker with hardware access could replace or reflash the UEFI firmware flash chip with firmware that reads out memory and dumps it out over ethernet. In the age of UEFI modular firmware and UNDI interfaces it might not even need much development time.
1 Like
Believe this is why apple uses the Secure Enclave inside the SOC on their devices.
(possible implementation flaws aside, this is the theory/design decision behind going that route at least)
A lot depends on what we’re defending against…
If we implement any mechanism for encrypting data that goes to RAM, we should answer what attack vectors we have.
The attacker may want to achieve one of two things. Make modifications to the data in memory in order to cause the desired effect or make a dump for later analysis.
In memory, the attacker can obtain a lot of data, sometimes even entire passwords or cryptographic keys.
A hostile VM that manages to break out of isolation and touches an area in memory it is not allowed to access. Here, both dump and data modification are a threat. If the entire content of the memory is encrypted, we prevent attempts to modify the content quite significantly, but it is still possible to perform a dump although such data will have zero usefulness.
Another threat model is tempest side-channel attacks. Here, the attacker does not penetrate the software layer, but listens to the electromagnetic echo coming from the pc.
Interception of data from mere information to entire cryptographic keys. Here, encryption will protect us as much as possible, but it will not prevent leakage.
Would it be possible, however, to make modifications in the memory hmm … I have not heard of a successful attack, but I may be wrong.
Physically taking dimms to dump or modify… Freezing dimms to extremely low temperatures to keep data supposedly works, I don’t know personally never tested.
When it comes to memory encryption, it must be a zero-trust implementation, i.e. the data is never manipulated by the machine in decrypted form. Otherwise, with tempest side-channel attacks data leakage is sometimes possible and does not have to come directly from RAM.
There is definitely less paranoia when we limit ourselves only to the issue of virtualization. Many times, due to bugs, hostile code has been able to get out of the VM and do bad things to the host. Will encrypting the entire contents of the memory protect the host from a hostile vm? I have some concerns.
Zero trust environment, something like cloud providers are starting to offer.
Your data should never be decrypted even for a moment, it’s encrypted on the disk, it’s encrypted in the ram, and the cpu processes the encrypted data. The machine doesn’t need to see what it’s doing, it just needs to know how to do it.
Just like network transmission, it is not interested in what data format it carries. It’s supposed to do abc and nothing else. Another challenge is to create such an environment that will be able to perform any function and at the same time operate on encrypted data…
2 Likes
That’s what you’re looking for then: Securing Virtual Machines with Intel Software Guard Extensions
But yes you’re loosing vmotion and VM snapshot with RAM(!).
1 Like
Your insights are valued and well appreciated. Thank you very much.
1 Like
I’m not trying to be smart ass, I’m just rambling without much sense. 
Hey I am learning from you. If I wasnt so deep in my profession, I would love to have been a pentester. Maybe in another life.
1 Like