Leveraging Hardware to Protect the Cloud

Virtualizing Trust
Establishing trust in computers, servers, networks, storage and mobile devices owned and controlled by a company is an ongoing and complex effort for any enterprise. For over ten years, experts from leading companies in a variety of technology areas have shared their expertise in several work groups within the Trusted Computing Group, developing open industry specifications to provide trust in all of these areas. For example, providing secure access to corporate networks, computers and servers from devices outside of the company’s control such as employee’s personal smartphones and partner’s/clients computers, while blocking unauthorized access has been addressed in TCG network standards, such as the Trusted Network Connect and IF-MAP metadata access protocol interface. However, the extent and complexity of cloud-based resource sharing requires even greater attention.

To address the security and trust issues associated with cloud computing, TCG established the Virtualized Platform Working Group (VPWG). The VPWG’s efforts to define the interfaces and services necessary to virtualize the trusted platform capabilities on a particular system have resulted in the Virtualized Trusted Platform Architecture Specification (Specification Version 1.0 Revision 0.26, September 27, 2011). Building on its existing standards, including the Trusted Platform Module that currently provides a hardware root of trust in over half a billion enterprise grade computers and servers, TCG has extended trust to the virtual space of cloud computing. Hardware-based trust implemented through a TPM is more secure than software-only based trust because software is vulnerable to the same attacks that it attempts to prevent.

TCG’s new architecture allows cloud-based systems to create virtualized instances of the TPM. This means that a single system can run multiple guests or virtual machines (VMs) and each machine acts as if it has its own physical TPM (pTPM). In reality, it is a virtual TPM. The vTPM is accomplished in software and is probably running a hardware-protected layer below the VM. From the VM’s perspective, it appears to have a physical system. However, a single virtualized platform can have multiple VMs each using its own distinct virtual TPM. Figure 1 shows the architectural shift that must occur to establish trust in a virtualized world. Some of the new terminology shown in the figure and used to discuss the architecture is summarized in Table 1.

Terminology

Table 1: Terminology used to develop a trusted virtualized platform capable of running cloud services

Figure 1: Transitioning from a non-virtualized to a virtualized platform

Layer 1 of the architecture consists of the physical platform components. Layer N is the top layer in the virtualization general architecture where multiple virtual machines operate independently. In between Layer 1 and Layer N are one or more layers in the architecture offering a virtualized platform to virtual machines running in Layer N.

To restrict or bound the scope of the effort, the software is assumed to run unmodified in a VM – there is no expectation of special virtualization-aware (paravirtualization) software in the VM in order to make the architecture work. In addition, the architecture allows a variety of different virtualization models including the absence of some features such as PC Client virtualization without migration support or addition of other features such as hop swap blade servers supporting migration. Other requirements include vTPM instance backup/restore, deep attestation of layers below the VM and the ability to migrate vPlatform (including the vTPM) along with the VM to another system.

While there are numerous issues and challenges to be addressed in establishing a trusted virtual architecture, some of the most critical are:

• Protecting the vPlatform state while in memory or on storage and ensuring this state across reboots or crashes
• Supporting different vPlatform versions per VM on the same system
• Maintaining vPlatform integrity with field upgrades and in backup/restore
• Preventing malicious duplication during vPlatform migration

In addition, for attestations the architecture must provide Remote Challenger detection of virtualization and deep attestations of VMs and the underlying VMM (defined in the scope but nevertheless challenging) as well as finding/ensuring the VM and VMM are on the same platform. The new architecture has addressed all of these aspects.

Architectural Model
The VPWG’s intent for the Virtual Platform Architectural specification is usage in both PC client and low-end (e.g., X86) server virtualization as well as high-end server virtualization. Figure 2 shows a possible architecture based on the specification. The boxes within each layer are components that perform defined roles in the architecture. Components can be part of existing features and don’t have to be standalone software modules. The interaction of components that occurs using application program interfaces (APIs) or protocols could be a topic for future standards.

Figure 2: A three-layer architecture possibility using a Privileged VM (VM #1) that can manage the other VMs

The architecture allows for improved administrator tools to back up the contents of the vTPM and restore it later. This can’t be accomplished with the physical TPM. There are specific advantages for data centers as well.

One of the advantages occurs when the data center’s management wants to roll out new versions of software as a pilot or in a test environment before going into production. With a virtualized system, the production system can be running in one VM and the test system running in another VM on the same physical system. This architecture allows the test system to use the latest version of the TPM.

Creating a Virtual Trusted Platform
Several situations could result in a new VM being instantiated including local configuration change, a VM being migrated to the system, or even system demand has gone up so another local VM instance is required. Since the VMM is the vPlatform "manufacturer," it is responsible for constructing the vTPM and vCRTM on-the-fly. This may be as simple as adding a state to a vPlatform table. Next, the VMM instantiates the vPlatform state with the created instance for use only by an associated VM. The instantiated vCRTM and vTPM are dedicated to the new VM and appear as their physical equivalents (so the VM doesn’t know it’s virtualized). They allow an unmodified VM to execute without recognizing that the TPM and CTRM are not physical components.

Operational Example
Attestation becomes much more complicated and more interesting when a virtualized platform is involved. In a non-virtualized system, attestation simply involves the trusted computing portions of the operating system providing evidence about the current operational state of the physical system to a remote party (Remote Challenger). The Remote Challenger decides the level of trust for the platform before allowing access to its resources.

When attesting a virtualized system, the VM performs all the same attestation-oriented tasks it would do if it was actually running on hardware. First, the Remote Challenger uses the attestation protocol and discovers that it is communicating with a VM. Since the VM is not directly running on hardware, the VM can be compromised by the VMM layer below it. If a malware controlled VMM was running below the VM, it would be possible to compromise the VM in a way that Remote Challenger could not detect by only obtaining an attestation of the VM.

The remote party has to determine how to attest the layer below the VM and decide whether it’s trustworthy. Because of the nesting architecture that the specification supports, there may be additional software layers below the first VMM, so attestation chains down the different layers until it’s convinced that the system is trustworthy. The credentials (X.509 certificates) associated with each layer indicate when the layer is running in a virtualized environment and how to contact the layer below to obtain more attestation evidence. This model allows for the arbitrary nesting of virtualization layers since the Remote Challenger can obtain an attestation about the VM and then attest each layer below until reaching the bottom using the credential information.

Now that we have discussed how to attest a virtualized platform, let’s discuss another complexity – VM migration.

Figure 3 shows how the new architecture can perform remote attestation of a VM that can be migrated while the Remote Challenger is using it. For remote attestation, the Remote Challenger obtains VM attestation evidence and certificates from an Attestation agent in the VM (shown as Guest OS in the yellow box) just like it would if the system wasn’t virtualized. During this process the Remote Challenger learns that the platform is virtualized. The integrity validator in the Remote Challenger then compares the obtained attestation data against the integrity policy and decides whether it’s trustworthy. Similarly, the Remote Challenger also obtains VMM integrity evidence and certificates from the Deep Attestation Service of a Privileged VM (capable of returning information about the VMM shown as a green box) and verifies that evidence as well.

Figure 3: Accomplishing remote attestation, migration and migration notification with the Virtualized Trusted Platform Architecture

VM migration is supported by the attestation architecture. For example, a data center with several virtualized platforms and a VM instance running on one physical machine might require migration when that platform needs to be rebooted to install patches. Maintaining availability of the VMs’ services requires moving the VMs that were running on the rebooting machine to another so that customers who are accessing those VMs are not even aware of the transition.

After a Remote Challenger has performed, an attestation of a VM and VMM as described above (and shown in steps 1-4), its policy may require attestation evidence about the Migration System and more detail about when the VM might be migrated. If the VM could be migrated at any time, some Remote Challengers may opt to register for a Migration Notification (shown as Step 10). This enables the Remote Challenger to use the VM and if a migration event occurs, the Remote Challenger can obtain attestation evidence about the new VMM and platform hosting the VM. This architecture allows the VM to be moved at any time and optionally allow Remote Challengers to re-assess their trust decisions.

Implementing Cloud Security
In the past, TCG did not specify how to virtualize the physical trusted hardware present in systems offering cloud-based services. Since many cloud-based offerings are implemented on top of a group of virtualized servers, this made it challenging to protect the offerings with a TPM. With this 2011 open standard, the Virtualized Trusted Platform Architecture, that situation has changed dramatically. As a result, vendors are encouraged to develop products that are consistent with this architecture to make it easy for customers and cloud providers to use the TCG-based security of the TPM. This new specification also leverages the widely deployed TCG Trusted Network Connect architecture as the basis for performing the attestations. For example, the TNC protocol stack could run within each of the VMs enabling TPM-based assessments of the VM.