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.
The Article was indeed very enlightening. Everyone is looking to secure their data. Data kept in memory is actually the final frontier. With that said the concept I think is going to be easier said than done.
1. First to Encrypt you must use a Symmetric Key and Keep it somewhere.
2. You must also decrypt what is in memory, instruction by instruction. There is not an easy way to predict the path the user will choose. You may get some benefit from Pipelining. This is exactly how read ahead caches work in the processor. You will get some benefit but not all that much. Remember that this one more thing to slow down the machine.
3. When you do decrypt it you must put it somewhere unless you encrypt as you go… (This would be like starting your program, go to lunch, then come back and maybe it will be on your screen.) Exaggerated? Maybe so, but in reality not by much.
4. If you go the route of decrypting it while it is in main cache. Then first you must also have a place to put it (you should be thinking Direct [not sharable] memory overhead here]. So you must have a place to store the encrypted CodeSegment/DataSegment/ExtendedSegment/StackSegment, then have probably more space (assuming you compressed it too) to store the extracted result.
5. Finally if you are breached, what have you really gained other than exercising your processor?
Just some thoughts.
Tim Pierson
Hello Tim,
This would be handled the same way as Memory Compression would be handled. Since the vCPU is a hypervisor construct it can do all that is necessary to decrypt memory as needed and send the instructions to the physical processor much the same way as compressed memory would work (outside the VM). The VM does not even know memory compression is happening. So I believe the groundwork has already been done.
There are also CPUs in the works that have encrypted sides to them as I saw at RSA Conference. Perhaps this may be the ultimate way to go.
Best regards,
Edward aka Texiwill