Providing Secure Services for a Virtual Infrastructure Adrian Baldwin
Chris Dalton
Simon Shiu
HP Labs Bristol, UK
HP Labs Bristol, UK
HP Labs Bristol, UK
[email protected] [email protected] [email protected] Qasim Rajpoot Krzysztof Kostienko Birmingham University
∗
Birmingham University
[email protected] ABSTRACT Virtualization brings flexibility to the data center and enables separations allowing for better security properties. For these security properties to be fully utilized, virtual machines need to be able to connect to secure services such as networking and storage. This paper addresses the problems associated with managing the cryptographic keys upon which such services rely by ensuring that keys remain within the trusted computing base. Here we describe a general architecture for managing keys tied to the underlying virtualized systems, with a specific example given for secure storage.
Categories and Subject Descriptors D.4 [Software ]: Operating Systems; D.4.6 [Security and Protection]: Cryptographic controls
[email protected] such as secure network and storage drivers. The security of the system is underpinned by using the reduced trusted code base enabled by virtualization with TCG measurements [22] providing trust that the correct code base is running. In this paper we start by describing the necessary virtualization and trusted computing background before giving an overview of the secure service architecture. We give more details of the key management components, policies and a key exchange protocol that is at the heart of the system. Most of this paper describes the key management system in general terms, with Section 5 discussing usage examples including that of a storage system that has been prototyped. We finish with a discussion of other related work and conclusions.
2. General Terms Security
Keywords Key Management, TCG, Storage, Virtualization
1. INTRODUCTION Virtualization techniques such as Xen [5] provide an underlying mechanism to build flexible solutions within a data center making it easier to manage resources [12]. Whilst such solutions are in their early stages there are opportunities to build in security mechanisms, thereby ensuring high standards of separation and allowing for the communication of trust in the systems. The absence of security mechanisms supporting the flexibility enabled by virtualization could block the adoption of virtualization within data centers running production systems. Within this paper we demonstrate an approach for providing secure services to virtual machines by building on the security properties available within a virtualized data center. We base our work on the principle that cryptographic keys are best managed by binding them within limited services and hence mitigating the chance of disclosure or inappropriate use. Here we describe an architecture for a secure key delivery mechanism that provides keys for data center services ∗Krzysztof and Qasim worked on implementing these ideas as part of their MSc project supervised by HPLabs.
BACKGROUND
The concepts described within this background section underpin the architecture for the secure delivery of services within a virtualized environment and are crucial in making the security argument.
2.1
Virtualization
Virtualization is a mechanism for partitioning a physical system into multiple virtual systems where each appears as if it were a separate physical system (usually of the same form as the physical system). Typically, virtualization refers to the dividing of a physical computer system (CPU, memory, and I/O) between several virtual machines (VM) resembling that, or some subset of the overall hardware. There are different mechanisms for providing a virtual machine monitor; this paper is based on the assumption that the VMM is the only code running at the highest privileged level within the CPU and hence running underneath any operating system. Xen [5] provides such a virtualization layer that maintains separations between VMs and operates privileged instructions on their behalf. Xen also includes a management domain Dom 0 that controls the life-cycle of the VMs including communications between VMs and access to physical devices. A virtualized system attempts to provide an environment similar to a physical system and as part of this it has to virtualize network and storage devices. Within Xen the guest operating system contains a front-end device driver which communicates via sockets within the VMM to a back-end
driver that bridges to the appropriate physical device. Typically, within Xen the back-end drivers run within Dom 0 but they can be run within separate driver domains (separate VMs). From a security perspective, an application running in one VM needs to know that it will not be interfered with from another application running within a second virtual machine; in other words, that the VMM layer provides an adequate separation mechanism. Having different privilege levels within the CPU helps to maintain separations, but to trust this separation we must trust a software stack from the BIOS through the VMM and the privileged management domain. This software stack forms the trusted computing base (TCB) for a given VM and we therefore need to ensure that the correct code is running and that it works as expected. TCG mechanisms (as described below) provide measurement techniques that can address the first of these issues. We believe that the smaller and simpler the code base, the less likely it is to have bugs or unintended consequences and is more open to review. Within a conventional data center the TCB for a given application will be based on the OS which can involve millions of lines of code (for example, a typical Linux system has 6 million lines of code [9]). This can be contrasted with the virtualization approach, where the VMM is much simpler (e.g. typically Xen has around 100,000 lines of code). From an application perspective, it still needs to run on an OS and as such, virtualization has potentially increased the TCB with the addition of an extra layer. However, controls can be placed within the virtualization layer (e.g. network controls [14] or tagging [20]). When considering risks around separation, the TCB is reduced to the VMM and the privileged domain responsible for configuring these protections. The reliance on the correct configuration and hence trust in the privileged domain is addressed by disaggregating the control mechanisms [17], but could also be addressed with the introduction of strong audit mechanisms into the VMM.
that is running on the computer system; these measurement registers are set as the machine goes through its boot cycle and can later be extended but cannot be arbitrarily set to a chosen value. The boot cycle starts with the BIOS boot block that forms the core root of trust for measurement (CRTM). The PCR values are then extended during the boot process with the measurements of various BIOS components, followed by the boot loader and finally measurements from the OS. The PCR extension operation is a cryptographic hash (SHA1) of the previous value combined with the new measurement and hence the PCR value represents the result of a sequence of extension operations that is unlikely to be reached via another route. Measurements can, of course, also include service or application code. As measurements are made a storage measurement log (SML) is created recording the measurements being made so that others can check the chain of trust up to the values within the PCRs. The TCG specifications support the signing of the PCR values via attestation identity keys (AIK) residing within the TPM. This allows for the communication of the state of the computer system with other parties, who can then validate the values came from a given platform and decide whether to trust it. Remote attestation can be performed using attestation keys certified by a certificate authority, hence indicating the measurements come from a valid TPM. The TPM provides additional functions; of particular interest here is the secure storage mechanism used to protect keys. One of the storage functions is the ability to seal data with storage keys within the TPM so that the encrypted material will only be decrypted when a given set of PCR values are within the TPM. This functionality allows us to store data in a way that we know it will only be decrypted for an application with a given TCB. The TPM itself has very a limited storage capacity and hence the sealing function encrypts a data package for storage elsewhere.
2.3
Trusted Virtualization
2.2 TCG
Measurement of a system with virtualization is slightly more complex in that a number of additional components are introduced into the trusted computing chain. A basic TCG scheme can be used based on a single TPM extending the measurements to the virtualization layer [10] and hence allowing trust to be communicated over the full stack for a given system. This involves a measurement chain including the BIOS, the boot loader, the VMM layer (i.e. Xen), the image for Dom 0 along with the additional kernel modules and associated configuration files. Such measurements can produce attestations up to the base level of the systems but users will want further attestations up to the guest OS levels. This could be achieved by further extending the PCR measurements; however, the dynamic nature of this environment makes this complex.
The Trusted Computing Group (TCG) [22][16] publish a specification for trusted computing providing for the attestations of the state of a computing platform based on a Trusted Platform Module (TPM), which provides a hardware root of trust based on a chip bound to the motherboard of a computer. The TPM contains at least 16 Platform Configuration Registers (PCR) that can be filled with measurements (cryptographic hashes) of the software stack
A measurement agent within Dom 0 that is itself properly attested and measured can provide an indirection for measuring and communicating guest domain attestations. A simple extension of this leads to ideas of virtual TPMs (vTPM) [7] where each guest domain has a vTPM providing measurement services along with the other TPM functionalities. Such a vTPM provides measurements of the virtual machine
Virtualization also opens up options to cut-down an OS so that it consists of only those services required for a given application; particularly where we have special purpose applications, such as those providing secure services to other operating systems. One such approach to producing a minimal OS is described by Anderson et al[1] this enhances the minimal OS within the Xen distribution by adding a port of the GNU libc, and an inter-domain communication channel for communicating with other VMs hosted by the same VMM. This minimal OS allows for the creation of a small TCB with highly controlled connectivity for dedicated applications — a feature that is used within this work.
along with the chain of trust up to that point based on measurements from the real TPM. The vTPM approach also has additional advantages in that it can be extended to support virtual machine suspension and migration. Such vTPMs can be provided from within domain 0 or from within a separate minimal virtual machine linked to the VM it is supporting. The vTPM also provides an identity mechanism based on attestation keys. Cabuk et al [9] propose further extensions to the integrity measurement framework allowing the attestation of platform relationships and dependencies; hence allowing the TCB to be measured even when it depends on a number of VMs.
3. OVERVIEW Trusted virtualization provides a mechanism for measuring the TCB within a virtual infrastructure thereby helping to engender trust in solutions hosted in virtualized data centers. The security of such solutions is partly dependent on the strength of the separation mechanisms and hence the strength of the TCB. Such server separations provide only part of the story and it is essential that the separations are maintained in the way VMs are combined into a computing fabric with networking, storage and other services. For example, a customer given a virtual data center farm needs to trust the security of the virtual network, storage and the VMMs hosting their machines. Encryption provides one mechanism for providing separations within networks and storage but this relies on having key management solutions that are at least as strong as the other separation mechanisms within the virtual data center. In this paper we propose an approach to providing trusted key management enabling services such as secure networking and storage by building on the properties of trusted virtualization. Underlying our approach to key management is the idea that cryptographic keys should be linked to particular usage patterns and policies so that they cannot be used outside of a given context or set of policies. In previous work [3][2], we proposed using secure hardware running limited applications that both manage keys and the operations performed using the keys (as allowed by a policy linked to each key). For example, at a high level, we created a document safe where documents are encrypted/ decrypted by an application within a secure boundary holding the keys, encrypting data, checking policies bound to a document and checking that the requester was allowed to access the document. This approach not only physically protects the keys but the wrapping of keys around a service helps reduce the chances of mis-use as compared to the standard approach [19] of allowing an application access to a cryptographic API. In this paper, we drop the need for physical protection, assuming a reasonably secure data center boundary, but retain the idea that keys are maintained within a service with a limited API now delivered using trusted virtualization.
3.1 Architecture Figure 1 shows the basic architecture of our system for delivering secure services to virtual machines. Here we briefly outline the components and their relationships with the critical components discussed in more detail in the next section.
Figure 1: The architecture App VM This is the guest OS and related applications that require the secure services such as storage. This is an untrusted component assumed to be outside of the control of the data center management. Service Driver The service driver runs the back-end driver for a service. The driver domain is trusted with keys relevant to the service being provided and hence is part of the TCB. Here we need to ensure that it uses a minimal code base and that we can measure the device domain. Thus we base the device driver on the minimal OS [1] and measure it using TCG mechanisms. VMM A VMM such as Xen provides separation between the trusted code within the driver domain and the other domains running on the hardware, including the untrusted guest domain, and as such is a critical part of the TCB. Privileged Domain The privileged domain controls how the platform is configured, including enabling communication channels between the VMs, and hence is another component of the TCB. Ideally the functions will be disaggregated [17] hence reducing the need to trust such a large component. TPM We assume that the servers have TPMs attached along with a suitable BIOS containing a core root of trust for measurement and thus we can get attestations of the TCB. Key Manager is a central component managing the lifecycle of keys as defined by the data center management system. Service Key Manager The service key manager is a subcomponent within the driver domain responsible for requesting keys from the key manager and managing them locally. Data Center Management System Within the data center there will be some component that is responsible for taking customer requests for virtual data center infrastructure and provisioning them. This could be part of an automated configuration system or a more manual system taking commands from administrators. Either way the management system takes requests for services and passes them to the key manager.
Here we have outlined the components within our architecture for managing keys within the data center along with identifying those components that make up the TCB. An additional element to the architecture is the key request protocol that pulls keys into the secure service driver from the key manager. This protocol uses TCG attestations of the TCB along with policies within the key manager. The main elements of the architecture are described within the next section, along with how the appropriate security properties are achieved.
3.2 Key usage life-cycle Before giving a more detailed explanation of the components within the architecture, it is important to outline the life-cycle and flows of keys between various parties within the data center. We start off by identifying roles interacting within the overall framework. The service administrator role could be held by either the data center manager or the customer depending on the given scenario. Service Administrator Creates new service instances including key usage policies (for example, the type of machines that can be used with the service or how the policies can be changed). Data Center Manager Specifies any binding between a service and a virtual and physical platform within the limits specified by service administrator (e.g. specifying that a given guest domain is running on a given physical platform). Key Administrator Keys are critical items within an infrastructure and as such they may need to be backed up. A key administrator or security officer role is required to support the process of transferring keys to a new version of a key manager or a suitably secure backup device. Key Usage Module makes requests for a key to be given to a suitable driver domain for use by a particular guest OS. Customer Makes requests for a given infrastructure from the data center and hence interacts with the service administrator and data center manager. Service User The guest OS or application that uses the service on a virtual platform. This role does not take an active part in the system but is identified as the end user of the secure services. Figure 2 shows the life-cycle and flow of keys. The process starts with the customer configuring the data center fabric they require resulting in the service administrator issuing a “create key for service command”, for example, creating a key for a given disk. The create command is accompanied with usage policies that specify the type of system trusted to use the key along with the virtual machines that can be connected to the service. The key manager creates the key and keeps it bound to the policies. The data center manager may communicate information concerning the VMs that are being created and where they reside to the key manager (alternatively this could be communicated via a credential
Figure 2: The life-cycle and flow of keys.
held by the VMs themselves). This allows the key manager to validate that a given VM, as provisioned by the data center, is entitled to gain access to a given service. The details of how a key manager links to a management system will be determined by the details of the management system and hence we aim to keep these elements generic. As a VM requests a service, for example, as it boots or is later connected to the relevant device, the key usage module within the driver domain makes a request to the key manager including measurements of the TCB. Where policies allow, the key manager releases keys to the key usage module for use in providing the given service within the driver domain. Once a VM no longer requires a given service, the device driver will destroy its copy of the key. As the requirements change for a given customer, they may make requests for changes in the policies on how a given key and associated service can be used. For example a key associated with a particularly sensitive storage device may only be released to a system with a TCB containing all the recent critical patches – as a new patch is issued the policy could be changed. Finally, as the customer no longer needs the service the keys should be destroyed. The life-cycle of the keys may change according to given usage patterns; whilst communication services may have transient keys, storage services have long-term keys whose loss could lead to the loss of data. Here we identify the role of a key administrator who can backup keys into other, suitably secure, devices and hence protecting against data loss. The key administrator could also play a role in moving keys into a new version of the key manager; as such, this is a highly trusted role and it may prove necessary to have an additional checker role.
4.
REALIZING THE ARCHITECTURE
The two main components within the architecture are the key usage module within the driver domain that performs the measurement process, along with the key manager that stores and manages the keys. In this section, we describe these components and the protocol between them in more detail showing how they take advantage of the concepts described in the background section to provide a secure and trusted service environment.
4.1 Key Requester Module The driver domain is based on the minimal OS along with some application code for the specific service. Part of the code is the key requester module that requests keys and manages them within the driver domain. Within this section, we concentrate on this element responsible for collating measurements and communicating with the key manager. We need to trust the driver domain to manage keys, use them only as intended by the service and allow only appropriate VMs to connect to the service. This means that we need to measure the BIOS upwards including the VMM, privileged domain and driver domain. In Section 2.3, we describe how measurements are performed on a virtual platform either using a single physical TPM or vTPMs. Either of the measurement strategies is valid here, with the important factor being that we get a set of PCRs and a corresponding SML allowing us to validate the software layers that we are trusting. The key-requester module is responsible for getting such measurements and running one side of a key request protocol (described later in Section 4.3) to obtain the service keys. The guest VM using the service provided by the driver domain also needs measuring. These measurements can be included in the key exchange protocol and hence be validated by the key manager. Alternatively, policies specifying acceptable measurements can be passed back to the keyrequester module which can enforce them as the service is required. There are a number of service-specific issues that can arise in performing such measurements. For example, a standard service such as storage and networking should be able to use a standard driver within the guest OS but this will not support establishment of trust with the back-end driver through TPM measurements. As a service is provisioned by the privileged domain there needs to be a mechanism for accessing measurements of the VM to which it is being connected; this can be via external access to measurements from a vTPM or via a mechanism providing attestations including relationships between platform components [9]. Further issues can arise from the stage at which a device is being connected to the guest VM. For example, if the keys belong to a boot disk, the measurements available at the time when the keys are required can only include the measurements of the basic configuration of the VM and not the OS whose image that is contained on the encrypted disk. Once the driver domain has received the keys, they can be used in providing the intended service. The key requester module keeps an encrypted copy of the keys using the TCG sealing mechanism (see Section 2.2). This allows the driver domain to overwrite the unencrypted keys when not in continuous use. The sealing mechanism also ties the keys to the driver domain so that they cannot be accessed via other systems. The use of the sealing mechanism combined with a vTPM that allows migration could be used to allow the driver domain to migrate along with a guest VM without reference back to the key manager.
4.2 Key Manager The key manager is a particularly sensitive component in that it stores and manages keys for multiple services over their full lifetime. This makes it a point of attack either
Figure 3: The key manager architecture in an attempt to gain access to the raw keys or to subvert the mechanism so that an adversary can successfully request that keys be delivered to their platform. Within this section we describe the architecture of the key manager, which is based on the security principles of using a small known code base and virtualization to provide separation. This approach does assume that that the key manager is running within a physically secure data center and represents a loosening of previous designs using a secure hardware boundary to physically protect the keys [2].
4.2.1
Key manager architecture
The key manager has been split into two components (Figure 3), each of which is contained within their own minimal VM such that the two VMs communicate through an interdomain communication channel. The first component’s role is to manage communications with key requester modules and management systems and as such acts as a front end for the key manager. The second component is responsible for performing the trusted operations within the key manager. This key manager design reduces the chances that the trusted parts of the key manager become subverted as they are not directly accessible on a network and also helps in minimizing the code base of the trusted elements. The key manager could itself be mirrored with an interchange protocol being used to communicate policy changes between multiple systems. Such mirroring would allow for high availability as required within a data center. The scope of the key manager can also be broken up so that a key manager could be run per customer or per service type. Running the key managers on a virtual platform means that they are easy to replicate and segment for different services. The key manager has an audit-logging capability to log all key requests hence providing a trace of which systems have access to a given service. The use of chaining within an audit system [4] allows each customer to view and trust audit logs detailing how keys associated with their systems have been used.
4.2.2
Key Usage Policies
Keys within the key manager are managed and released to service device drivers according to a set of policies. There are actually three sets of policies following from the different
operations within the life-cycle of the keys (see Section 3.2). The first set of policies refer to the owner of the service protected by the keys and who can end the service or change the other policies. The second set of policies define the identity of guest domains that can be linked to a given service as controlled by information supplied from the service administrator and data center management system. The third set of policies specify the acceptable levels of trust required for the release of keys to a given platform. Keys need to be released to a driver for use with a given guest domain, and in forming this connection there is an underlying assumption of a unique identity for the guest domain. The identity could be bound up with a vTPM associated with a guest, or where there is no simple mechanism of reliably binding a unique identity to a guest OS, it is necessary for the key manager to have more detailed deployment information from the data center management system. The third group of policies concern the definition of the TCB that the owner is prepared to trust with a given set of keys and hence access to a given service. On the creation of a service the owner will have some idea of the acceptable risk level. For example, based on an understanding of the impact of data leakage they can select an appropriate required level of trust. The policies themselves define how to interpret the PCR values as supplied by the key requester module (including measurements of the guest OS). These policies could simply contain the necessary chain of hash values from a known tested implementation so that the key manager can reconstruct the final PCR values by looking at this list and the SML information. Such an approach lacks flexibility and would lead to the need to update many policies as software versions change or as patches are issued. Instead, an indirection can be introduced having white lists for different systems that define acceptable versions (and measurements) for each part of the software stack for a given risk level. Some configuration measurements may be more specific to the task. For example, on measuring a guest domain the measurements may be required to indicate that the configuration has only one network card. Hence, policies can be made up by reference to white lists and by comparing configuration files against a known set of measurements. Whilst white lists provide a degree of flexibility, they also create an additional trusted role, which could be taken by the service administrator or passed on to a trusted third party. Such a role would be responsible for ensuring white lists are up to date so that measurements of components with known vulnerabilities are removed and measurements including the latest patches and versions are included. The policy validator module within the key manager is responsible for interpreting the PCR values relayed to it from the key requester module and comparing them to known values within the white lists to check that they represent a trusted component. The storage measurement log that details what has been measured and the measurement sequence help in this interpretation. Additional elements could be added into the policies. For example, a list of Certificate Authorities (CA) trusted to endorse the attestation keys within the TPM (or vTPM) could be specified, or location elements could be specified so that a key manager with a list of server
locations can check that a given server is within a safe physical boundary (i.e. a data center).
4.2.3
The key manager database
At the heart of the key manager is a database containing keys, policies and the associated service identity. From a security perspective, it is important to keep the keys secure, protect the integrity of the policies and the binding between the keys, service identity and policies. The keys held within the key manager should only be available to the key manager and those driver domains to which they are shipped. To achieve this we seal the keys using the TPM or a vTPM associated with the back-end key manager VM. The sealing process ensures that the keys are only available where the PCR registers are the same as those used in sealing the data. We ensure that the keys are only available to the trusted key manager application (i.e. an application we trust to manage the keys and policies properly) by measuring from the BIOS through the minimal OS up to and including the application code. The binding between the key, service and policies is critical to the security of the system and hence we seal a combination of the key with the (SHA-1) hash of the service name and policy set. As part of the policy validation stage the integrity of the policy set for a given service should be checked against this hash value. The design of the key manager does not provide for persistent storage within the key manager back-end, and hence, the key manager database, including the sealed key and integrity check, needs to be transferred to the front-end key manager for persistent storage. This presents an additional issue of ensuring that the keys provided to the key manager are fresh (the current entry in the database cannot be replaced with an older version that may have a weaker policy). Preventing such replay attacks can be done by having an integrity check on the whole set of keys; this could simply be done by keeping a hash of the whole key database and ensuring that the key database matches this hash as it is loaded into memory. Schemes based on hash trees [15] (or other similar structures) provide a more efficient integrity check in that they do not require the entire key database to be in memory at any point and hence reduce the effort of maintaining the integrity measures. The overall integrity measure will reside in memory whist the key manager is running. Issues of freshness remain on restarting a given key manager where the root integrity measurement for the database could be sealed with freshness information derived from a management system or security officer. Where a replicated set of key managers is used, the freshness should be derived by replicating the key database from a mirrored key manager and hence ensuring policy updates are shared between all key managers.
4.3
The key exchange protocol
The key exchange protocol (Figure 4) is an extension of the integrity reporting protocol presented by Stumpf et al [21]. It exchanges measurements and the protected keys between the key manager and the key requester module. The protocol starts with the key requester module initiating a request by sending a nonce to the key manger who stores the nonce along with the arrival time; this is used to ensure the freshness and timeliness of the protocol. The key manager returns a nonce that the key requester module uses in a TPM Quote
5.1
Figure 4: The key exchange protocol
operation resulting in a set of PCR measurements signed with the attestation key. This signed structure then has the system measurement log and attestation certificate attached and is placed in an encrypted package for the key manager (preventing observers from gaining information about the state of a given VM). The front end of the key manager decrypts the package and checks the certificate (including for revocation). The package is then passed to the back-end of the key manager which validates the measurement package and performs the policy validation as described earlier. This leads to a validation result that is either a key, along with any additional usage policies that the driver domain is trusted to enforce, or it is an error message. This validation result is encrypted for the TPM of the key requester module and then signed along with the original client nonce (or an agreed transformation of the nonce) and returned. The key requester module can then validate that the package comes from the key manager and matches the initial request before passing the validation result to the TPM for decryption.
5. EXAMPLES So far we have described a mechanism for managing and delivering keys securely to driver domains that use the keys to deliver services to a guest VM. From a practical perspective, this work has been undertaken as part of a secure storage infrastructure as described below. We believe the approach is equally valid for other services that can be delivered with appropriate separation using cryptographic keys. Other obvious examples include using the key manager to set up encrypted network links between guest domains by having the back-end driver acting as part of a virtual switch (with the key allowing access to a encrypted VLAN), or to provide an encrypted link for a secure console device. Other less traditional services can be enabled by having this type of secure infrastructure. For example, an audit service for securely off loading log files can be provided to a guest VM where the keys are used to protect the log files (e.g. using a forward integrity scheme [6]) within a back-end audit device driver. We believe that as the acceptance of virtual data centers increases a number of services, including various management functions, will emerge and be enabled by having a key management infrastructure.
Secure Storage
A secure storage system could be provided to a virtual infrastructure via a correctly configured SAN with encryption managed within the OS. Our proposed system leads to an alternative secure storage system based on a smaller TCB where encryption is performed within a storage driver domain and the storage keys are managed and distributed by a simple key manager. This not only helps mitigate threats from mis-configuration but also reduces the likelihood that the key is lost through a subverted OS. Within our storage service we have a driver domain containing a modified iSCSI client performing block encryption based on a key schedule [2] primed with an initial key supplied through the key requester module. Alternative schemes [11] could use the key to secure additional meta-information to ensure the integrity of the disk. On the first request for the connection to a disk the driver makes a request to the key manager for access to a key associated with a given disk. The key is only provided if the system is in a trustable state. The key is then kept and managed within the relatively small driver domain — separate from the more complex multipurpose OS hosting the application. Currently, the binding between a particular VM and its storage driver domain is controlled by the privileged control plane (dom0). Measurements of that privileged domain must be included as part of the key release protocol. The creation of new disks or the movement of disks from one machine to another can be handled as normal through requests from the data center. A request to create a disk is carried out through a web interface to the front-end key manager where disk name and usage policies are specified. This leads to the creation of the key and its storage within the sealed key manager store. The request also includes the owner of the disk (and their public key) allowing for later changes to the policies or for the disk to be reassigned. Communications between the management system, or data owners and the key manager can be secured using public key techniques; with the web-based interface this can be done through a two-way SSL or TLS connection. The basic key management system has been prototyped for use as part of a secure storage system [18][13]. The key manager, key requester module and key exchange protocol have been implemented and linked to TCG measurements using the jTss TPM emulator.
6.
DISCUSSION
Virtualization brings the promise of more flexible IT infrastructures and architecturally a layer of indirection, or control point, where security mechanisms and policies can be introduced. Several security research groups are working on exploiting the control-point aspect of virtualized architectures. Perhaps most related to the work presented here is the Trusted Virtual Domain (TVD) approach to secure virtualized network provision [8]. The aim of the TVD work is to allow for groupings of virtual machines that share a common security policy and are able to express and enforce that shared security policy across members of that domain. As an example, within a domain, VMs may be able to communicate freely but the communication links between members of the domain may be encrypted or carried over a particular VLAN depending upon the network security policy
requirements set out for that domain. The TVD concept as described in [8] applies to network security policy controls only, however the concept could be applied to other aspects of resource control such as storage. The work we present here compliments the TVD concepts well. TVDs can be used to express high-level policies about the usage of services such as networking or storage within a domain. Our key management and release framework offers a strong way of controlling and validating access to resources from a particular VMM / service driver / VM combination. So we have a way of expressing security policies for a domain (TVD) and a way of controlling who can become a member that domain (our key management/release framework).
[10]
7. CONCLUSIONS
[12]
This paper has described a key management system for providing key storage and distribution services necessary for building a secure virtualized infrastructure. In doing so, we have demonstrated the advantages of using trusted virtualization along with a minimal trusted computing base to secure keys and the services supported by such cryptography.
[9]
[11]
[13]
[14]
8. REFERENCES [1] M. Anderson, M. Moffie, and C. Dalton. Towards trustworthy virtualisation environments: Xen library os security services. Technical Report HPL-2007-69, HP Labs, 2007. [2] A. Baldwin and S. Shiu. Encryption and key management in a san. In SISW ’02: Proceedings of the First International IEEE Security in Storage Workshop. IEEE Computer Society, 2002. [3] A. Baldwin and S. Shiu. Hardware encapsulation of security services. In ESORICS, volume 2808 of LNCS. Springer, 2003. [4] A. Baldwin and S. Shiu. Enabling shared audit data. Int. J. Inf. Secur., 4(4):263–276, 2005. [5] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, and A. Warfield. Xen and the art of virtualization. In SOSP ’03: Proceedings of the 19th ACM symposium on Operating systems principles. ACM, 2003. [6] M. Bellare and B. Yee. Forward integrity for audit logs. Technical report, UCSD tech report, 1997. [7] S. Berger, K. G. Ram´ on C´ aceres, R. Perez, R. Sailer, and L. van Doorn. vtpm: Virtualizing the trusted platform module. Technical Report RC23879, IBM Research, 2006. [8] S. Cabuk, C. I. Dalton, H. Ramasamy, and M. Schunter. Towards automated provisioning of secure virtualized networks. In CCS ’07: Proceedings
[15] [16] [17]
[18]
[19] [20]
[21]
[22]
of the 14th ACM conference on Computer and communications security, pages 235–245. ACM, 2007. S. Cabuk, D. Plaquin, T. Hong, and D. Murray. Improving policy verification capabilities of trusted platforms. Technical Report HPL-2008-71, HP Labs, 2007. T. Garfinkel, B. Pfaff, J. Chow, M. Rosenblum, and D. Boneh. Terra: a virtual machine-based platform for trusted computing. SIGOPS Oper. Syst. Rev., 37(5):193–206, 2003. C. Gebhardt and A. Tomlinson. Secure virtual disk images for grid computing. In APTC ’08: Proceedings of the 3rd Asia-Pacofoc Trusted Infrastructure Technologies Conference, 2008. M. Kallahalla, M. Uysal, R. Swaminathan, D. E. Lowell, M. Wray, T. Christian, N. Edwards, C. I. Dalton, and F. Gittler. Softudc: A software-based data center for utility computing. Computer, 37(11):38–46, 2004. K. Kostienko. Securing access of virtual resources to a shared storage facility based on tcg. Master’s thesis, University of Birmingham, October 2007. D. Kuhlmann, R. Landfermann, H. Ramasamy, M. Schunter, G. Ramunni, and D. Vernizzi. An open trusted computing architecture - secure virtual machines enabling userdefined policy enforcement. Technical Report RZ 3655, IBM Research, 2006. R. Merkle. Protocols for public key cryptography. In IEEE Symposium on Security and Privacy, 1980. C. Mitchell. Trusted Computing (Professional Applications of Computing. IEE Press, 2005. D. G. Murray, G. Milos, and S. Hand. Improving xen security through disaggregation. In VEE ’08: Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments, pages 151–160. ACM, 2008. Q. Rajpoot. Key management for secure storage in a virtualised data center. Master’s thesis, University of Birmingham, October 2007. RSA Labs. Pkcs#11 v2.11 cryptographic token interface standard, 2001. R.Sailer, T. Jaeger, E. Valdez, R. Perez, S. Berger, J. L. Griffin, and L. van Doorn. Building a mac-based security architecture for the xen opensource hypervisor. Technical Report RC23629, IBM Research, 2005. F. Stumpf, P. R. O. Tafreschi and, and C. Eckert. A robust integrity reporting protocol for remote attestation. In Proceedings of the Second Workshop on Advances in Trusted Computing, 2006. Trusted Computing Group. TCG pc specific implementation specification, 2003.
