vSecurity gets a boost from TPM/TXT

During the Virtualization Security Podcast on 6/22, Steve Orrin of Intel and Dennis Morreau of RSA joined us to discuss the impact of Intel Westmere chips built-in Trusted Platform Module (TPM) and Trusted Execution Technology (TXT) on Cloud and Virtualization Security. TPM is not all that new, but TXT’s usage in virtualization security is new. Both together can form a hardware root of trust for the virtual environment.
At the moment however, these technologies are limited to just providing a secure launch of a well known hypervisor within the hardware. As such they have not been extended to the virtual machine. TXT however solves a very important issue that at the time the book VMware vSphere and Virtual Infrastructure Security was written had theoretical solutions, I speak of Blue Pill style attacks. There were rumors of Hyperguard or Guard Hype tools becoming available, but they are only research projects. TXT on the other hand, offers protection from Blue Pill style attacks.
What is Blue Pill?
Blue Pill is a family of attacks that take advantage of Intel-VT and AMD RVI technologies to run a hypervisor below the currently running operating system. In essence, allow the running of a rogue hypervisor, an undetectable, until now, attack that is the ultimate in root-kits: a hardware root-kit.
Guard Hype and Hyperguard are hypervisor emulators which are designed to catch rogue hypervisors (hardware root-kits) by ensuring the instructions to install them are protected as well as other critical instructions. TXT on the other hand is providing trusted measurements of the launch environment instead of emulation.
Solution and Why this is Good
Unlike Guard Hype and Hyperguard the new TPM/TXT tries to create a measured secure lauch of a well-known hypervisor. In this way, it protects against rogue hypervisors. How does it do this?

TPM can be used to ensure that the boot volume of an operating system has not been modified (Xen and ESXi support this out of the box, ESX requires some changes but it is possible)
TXT then measures and produces cryptographically sound hashes or checksums (referred to as PCRs within the technology) of the various aspects of the boot procedure such as the loaded code segment and allows or disallows the hypervisor from booting based on various hash comparisons to well-known hypervisor information stored within the hardware.

What this process does is provide a trusted hardware root where the OS that you intended to boot was actually booted. In essence, if for example you have set the TXT Launch Control Policy within the BIOS to only allow VMware vSphere 4 to boot on this host and someone instead tried to boot VMware Virtual Infrastructure 3, Xen, Hyper-V, or some home grown hypervisor TXT would disallow these operating systems from booting guaranteeing that what you expect to have running on the host is actually running.
This provides a hardware root of trust up through the hypervisor. The TXT APIs allow management tools and hypervisors to query the PCRs and therefore KNOW they are running on trusted hardware and that no other hypervisor is running.
Usage
RSA is working with VMware to tie TXT to the management tools. As demoed at RSA Conference 2010, InfoSec 2010, and EMCWorld 2010 RSA is making the most of TXT. They are working to ensure that when

  • you vMotion  a VM from host to host, that only a Trusted host can be the target.
  • you deploy a VM to a host, that only a Trusted host can be the target
  • you add hosts into a cluster, that the hosts are a Trusted host

This gives secure sites one more tool to ensure the VMs land on acceptable hosts. In this case ones with a Trusted hardware root. In essence, this adds yet another policy check that can be built into the virtualization management tools. Since this is a security policy setting you may actually have untrusted and trusted hosts, where what you want to land on trusted hosts are the VMs that contain or can access sensitive data.
The Issues
TPM/TXT is a boot time option, while there are APIs available to be used by third parties and hypervisor vendors there only two current ways to ensure that a host has not been compromised after boot:

  • Draconian: Cycle the power on the host and have it boot once more
  • Dynamic: Relaunch the hypervisor/OS on the host (still a bit draconian as you would first have to migrate all VMs off the host)

Ideally, we need a dynamic mechanism to reread the hosts boot volume (TPM) and measure the appropriate memory regions of the hypervisor (code segment, txt segments, etc.) to ensure that nothing has changed while the hypervisor was running. Ensuring a boot or launch is secure is a long way from knowing if the system is STILL the same one you originally were using. With hypervisor up times in the years not months, this is a very large issue that still needs to be worked.
The Future
At the moment the TPM/TXT technology only reaches up to the hypervisor kernels and some management tools, but it does not extend to the VMs yet. We can have a secure launch of a hypervisor but not a secure launch of a VM, yet! The future of TPM/TXT is bright and has so many uses:

  • Secure Launch of a VM using a virtual TPM based on the hardware TPM (much like the Cisco Palo vNetwork adapters) I am not suggesting a software TPM, but a hardware TPM.
  • Update of the hardware based virtual TPM with data from other TPMs so that PCRs for VMs migrated to a host are maintained
  • Make use of Intel Westmere and related CPU chipsets to use the builtin AES encryption performance enhancements to provide hardware encryption of virtual disks
  • Make use of Intel Westmere and related CPU chipsets to use the builtin AES encryption performance enhancements to provide hardware encryption of virtual memory
  • Make use of Intel Westmere and related CPU chipsets to use the builtin AES encryption performance enhancements to provide hardware encryption of virtual networks

While I mention Intel Westmere chips, please be aware that AMD has a similar technology in their most modern chip sets as well.
TPM/TXT provides the foot hold within the hardware we need to provide a hardware root of trust to actually implement Secure Multi-Tenancy. We are still in the crawling stages with this new technology and if we can build TPM/TXT to include onboard hardware encryption and key storage we are a long way to ensuring the Integrity and Compliancy of our data with-in the virtual environment and cloud.