In April 2015 I wrote about “Intelligent Key Management for the Cloud”. In that blog I described the various models for encryption and key management for virtual workloads running in IaaS including:

To sum up, there are three models for performing encryption and key management in the cloud: SSE, SSE-CPK and Client Side Encryption. Of the three, I think that only the client side encryption method with keys accessed only when needed from the customer’s on premise key manager earns the title of “Intelligent Key Management for the Cloud” because it gives the customer the most control over their data.

However there is still a problem even with client side encryption.  While running, the virtual machine will have the encryption keys in its memory. This memory could be attacked and a determined advisory could retrieve the data encryption key (DEK) used to encrypt the drive. In fact there is a lot more information in memory than just keys.   At one point or another, most of the data on the drive will have been processed in memory –Gartner recently discussed this in Key Management as a Service Exposes Different Risks to Data in Public Clouds. This “data in use” could be vulnerable to unauthorized access, insider threats or hypervisors hacks and vulnerabilities. That said, recent CPU flaws – particularly ‘Meltdown’ – have brought attention to the need for protection of memory, especially in cloud environments, to reduce potential exposure to such vulnerabilities.

Ultimately, these concerns lead to trust issues on the customer side. Enterprises today are reluctant to move their most sensitive data into the Cloud because of concerns with:

• • Confidentiality of data-at-rest
  • Confidentiality of data-in-use
  • Exposure to other tenants
  • Cloud Service Provider admin access
  • Cloud Infrastructure vulnerabilities
  • Undisclosed government access

Why is this? Because, the ultimate responsibility for data security remains with the Enterprise.

On the other hand the CSP has a concern with “liability” because they have potential access to customer data in use and at rest. They need to spend time and money on expensive controls to obtain certifications to build trust, but still have potential exposure to customer data in the end.

The solution to both the trust and liability problem is for the cloud service provider (CSP) to not have access to customer data in use or at rest, not even CSP administrators or hypervisors.  Encrypting both the storage and memory of a virtual machine is the answer, so long as the customer controls the process – not the CSP.

For encryption of virtual memory, AMD’s Secure Encrypted Virtualization (SEV) technology is available in their EPYC processor <here>.

The VM memory is encrypted in hardware, so not even the hypervisor can see its memory in plain text, and almost the entire memory space is encrypted transparently to the applications, so no application re-engineering is required.

But encrypting data in use (i.e. in memory) is only ½ of the solution.   Memory can be paged out or saved to the drive, so the drive needs to be encrypted too.  This is where SecureDoc CloudVM FDE (Full Drive Encryption) comes in to encrypt the disk volume, protecting data at rest, while VM memory encryption solves the problem of keys in clear text in memory that I pointed out 2 ½ years ago is solved too.

Better yet, CloudVM makes intelligent policy decisions regarding if and when the VM can boot.   It also plays a critical in role in enforcing policy that specifies CloudVM must only run on hardware with encrypted memory, even in a cloud environment.   If not, launching the VM will be halted before it even gets the encryption keys to boot:

To view a 3 minute demonstration of WinMagic’s CloudVM for Linux running with encrypted memory on an AMD EPYC processor, please click <here>