Encryption is important, encryption within a VM even more important. But the question is how to do this securely without allowing the encryption keys to be seen by an administrator of the virtual environment and that supports vMotion or LiveMigration. The solution is per VM encrypted memory, but something that makes use of hardware, out of band key exchange, and supports vMotion or LiveMigration. This may be a tall order but I believe it is necessary to fully realize Secure Multi-Tenancy.
Secure Multi-Tenancy (SMT) is all about protecting the data from all who do not have access to manipulate or view such data. Current SMT thoughts are in the direction of Integrity and Confidentiality as Availability is well understood. To do this, I have suggested that we need to have better encryption or digital signatures available to the VM, and generally this implies hardware encryption via some device like TPM/TXT/HSM, etc. The reason for this is:
An administrator or hacker with administrative privileges within a virtual environment can reduce the hay-stack to search for an encryption key by dumping memory of a VM without the VM knowing. This includes current CPU register settings.
An administrator or hacker with administrative privileges within a virtual environment can make a virtual disk copy without the VM knowing.
An administrator or hacker with administrative privileges within a virtual environment can dump CPU non-deterministic events without the VM knowing (but only if VMware Fault Tolerance is in use) which may aid in determining the encryption algorithm in use.
I hear everyone asking Would good auditing detect such behavior? Perhaps, and that depends on how the act was accomplished. There are many ways around any ‘known’ audit system. In addition, most systems do not impose continuous auditing or Mandatory Access Controls (MAC). So in essence, you may never know these actions took place or if you do, you may detect them too late to prevent such an attack.
So the solution is to actually encrypt the memory in use. But such encryption would need to:
- Be per VM
- Be within the hypervisor kernel, preferably making use of the AES&I speedups of the Intel Westmere chips (or similar AMD chips) so that most of the encryption is performed in hardware (TPM/TXT)
- Be able to use external, per VM, encryption keys.
- Use an out-of-band mechanism to pass the keys to a given host.
- Support vMotion or LiveMigration.
With new memory over-commit mechanisms in place, we have paved the way for memory encryption on a single host by a hypervisor. This could be done today with the proper code, but it would not support vMotion or LiveMigration. For this we need a way to pass the encryption keys in a safe manner.
We have this same problem with TPM/TXT today. If a VM is moved from host to host, the TPM/TXT PCRs need to be recreated using the new TPM/TXT device within the new hardware. This is one reason TPM/TXT is currently limited to just ensuring the hypervisor is trusted.
But we are close, we could easily solve the key exchange issue by implementing some form of Diffie-Hellman key exchange as a part of vMotion or LiveMigration. This of course would require vMotion or LiveMigration data transfer to be properly encrypted using pre-shared keys or certificates.
So to the hypervisor vendors, give us encrypted memory and encrypted vMotion or LiveMigration. Then we can finally start to seriously implement SMT.
Share this Article:
Latest posts by Edward Haletky (see all)
- Common Product Security Questions - November 23, 2016
- Sorry Support: Not Getting My Data - November 18, 2016
- Moving to the Future: Strategies for Handling Data Scale - November 14, 2016