2010 10th IEEE International Conference on Computer and Information Technology (CIT 2010)

A practical approach to improve the data privacy of virtual machines

Jinzhu Kong National University of Defense Technology Computer School Changsha, China kongjinzhu@gmail.com Abstract
Cloud computing can provide users dynamically scalable, shared resources over the internet, but users usually fear about security threats and loss of control of data and systems. This paper presents a practical architecture to protect the data confidentiality for guest virtual machines. With this solution, even the cloud computing service providers cannot access the private data of their clients. This is very important and attractive for the cloud clients. In our work, we utilize virtualization technology and trusted computing technology to construct a secure and robust virtualization platform. On this platform, we customize the guest virtual machine operating system, strengthen the isolation between virtual machines, and therefore, greatly improve the data privacy of cloud services. With our solution, the cloud service provider can compromise the availability, but not the confidentiality of the guest virtual machines. ratio, companies trust internal IT systems over cloud based technologies due to fear about security threats and loss of control of data and systems[1]. As a result, security is one of the top issues that users will consider for cloud computing. The security requirements usually fall into four categories: confidentiality, integrity, recoverability, and availability. For most cloud computing clients, data confidentiality is the preliminary property that must be guaranteed. In general, people or company will never risk letting their private data be freely accessed by cloud computing providers. Cloud computing providers need to promise this data privacy property to attract more clients. In practice, cloud service can be grouped into three categories: software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS) [2]. IaaS is an evolution of virtual private server offerings [3], it depends heavily on the underlying infrastructure: virtualization. Virtualization software is usually called hypervisor, it allows a single physical server to host many guest virtual machines (VM), and the guest VMs are provided to clients as the cloud computing service. The guest VMs enable individual developers and companies to deploy their own operating systems and applications without the cost and complexity of buying servers and setting them up. After that, clients may send their data to the VM and provide their dedicated services. Commercial examples of IaaS include the Amazon's EC2 [4], etc. This paper aims to proposing a virtualization solution to achieve data confidentiality for guest virtual machines. With this solution, even the IaaS cloud computing service providers cannot access the private data of their clients. This is very important and attractive for the clients. The solution only emphases on data confidentiality, Service provider can still easily break down the availability and integrity of the clients services and data. But these misbehaviors can be

1. Introduction
Cloud computing is derived from several technologies: virtualization, distributed application design, grid, and IT management. It can provide dynamically scalable, shared resources over the Internet and avoids large upfront costs. Cloud computing is getting more and more concerns and promises to change the future of computing. However, A survey about cloud computing conducted by Kelton Research at the beginning of 2009, shows that the clear majority (61 percent) of companies are not using cloud computing technologies at that time, and the vast majority (84 percent) of those that currently depend on internal IT systems have no plans to switch to cloud computing technologies in the next 12 months. The survey shows that, by a 5 to 1
978-0-7695-4108-2/10 $26.00 2010 IEEE DOI 10.1109/CIT.2010.173 936

detected easily, and will finally impair the service providers commercial credibility. The basic idea of the our solution is to combine machine virtualization technology with trusted computing technology to achieve the privacy of the virtual machines; by running a modified OS inside the VM, enhance the clients data confidentiality against the service provider. Our work is based on the type-1 hypervisor, such as Xen [5], which runs on bare hardware and hosts a privileged domain (called dom0) and several guest virtual machines (called guest VM). An application named Qemu[6] running in dom0 provides virtual platform and devices for guest VMs. We do not trust dom0 and Qemu because they both are controlled by the cloud computing service provider. Based on the trust computing technologies, we can verify the boot sequence of the target machine and make sure the trusted hypervisor is running on it. With the hypervisor, we can strongly isolate the clients memory from dom0s, mediate the IO accesses between Qemu and guest VMs to prevent guest VMs data from being stolen. Finally, our solution needs to modify the guest kernel to remove all device drivers other than hard disk and network card drivers, disable ACPI and kernel BIOS calls, because dom0 may embed Trojan horses in these codes. The next section introduces the virtualization and trusted computing technologies. Section 3 presents the detailed design of the presented solution to show how the data privacy is achieved. In section 4, we evaluate the solution and state that it may prevent all kinds of attacks from untrusted dom0. We discuss related work in section 5 and conclude in section 6.

A Xen-based system consist of several items that work together: hypervisor, dom0 , user-space tools, domU ( guest VM ). The Xen hypervisor abstracts the hardware for the virtual machines, controls the execution of virtual machines as they share the common processing environment. Dom0 is a privileged VM, it runs a full-fledged operating system, it is always booted by the hypervisor. Dom0 is used for platform management. Xen supports two kinds of virtualizations: paravirtualization and fully virtualization. Fully virtualization needs Intel VT or AMD-V hardware supports, it can provide better isolation between VMs without the need to modify guest operating system. In our work, we use fully virtualized Xen VMs. Every fully virtualized VM requires its own Qemu daemon, which exist in dom0. In the existing Xen architecture, dom0 takes full control of all virtual machines running on the same host. When evaluate the trustworthiness of the guest VM, dom0 have to be included in the Trusted Computing Base (TCB), this implies that the system administrator must be trusted, which impairs the usefulness of Xen in clouding computing.

2.2. Trusted computing

Trusted Computing is a category of technology developed and promoted by the Trusted Computing Group. It is usually based on a TPM integrated on the motherboards. It includes some technologies: such as Remote attestation, sealed storage and authenticated booting. The TPM specification prescribes a way of building up a chain of trust in the platform so that when interacting with a particular application on a platform, a report can be obtained on the software stack that was executed on the platform. This report is a list of Platform Configuration Registers (PCR) configuration values signed and certified by the TPM [7]. To sign its PCRs, the TPM uses the private portion of an Attestation Identity Key (AIK) pair. The verifier uses the public AIK to validate the signature and then checks the PCR values. In this paper, we leverage the above virtualization technology and trusted computing technology to construct a secure and robust virtualization platform.

2. Background
2.1. Virtualization
Virtualization refers to the abstraction of computer resources, it is a key feature of cloud computing.Many virtualization technologies have been proposed and implemented, such as Xen, VMware. VMware is a commercial software that implements full virtualization. The Xen hypervisor is an opensource project that is being developed in University of Cambridge. We focus our work on Xen because it is open-source and well accepted. Xen hypervisor has been used in many commercial virtualization products , it acts as the engine of the Amazon Elastic Compute Cloud.[4]

3. Architecture
3.1. Design goal

937

(1) Provide VM platforms to cloud computing users, users can then integrate an OS, middleware, application software on the platform at their own discretion. (2) Administrator and other users of the virtualization system are impossible to hack into the target VM. Only the valid user can boot the target VM. (3) The mechanisms used to protect the data privacy can be easily verified.

VT-D or SVM: With them, Xen can provide better isolation between VMs without the need to modify guest operating system.

3.4. Untrusted part

We do not trust dom0 and the Qemu running in it, because they are both controlled by the cloud computing provider. However, our guest VM still needs the virtual firmware, virtual platform and devices produced by the Qemu. So, we need a further analysis of Qemu, which is discussed in detail in section 4.6.

3.2. Overview of our architecture

Our implementation is very simple in theory namely, protect the data privacy of guest VMs with help of a trusted Xen hypervisor. In practice we need to thoroughly analyze the virtualization system and make a clear separation between correlative components. Figure 1 gives an overview of the implementation. We divide our Xen-based system into three parts: the trusted part; untrusted part; protected part (not including the bios and grub). This division is based on two technologies: (1) trust computing, which provides a trustable hardware platform that can act as a core root of trust, (2) virtualization, which provides isolation between different VMs.

3.5. Protected part

As illustrated in Figure1, this part includes all the guest VM environment. As mentioned before, we focus our work on how to protect the data privacy of the guest VMs. The service providers can still compromise the availability and integrity of the clients services and data, but they cannot steal the clients secrets. It is worth noting that we exclude bios and grub out of the protected part. Its because, we do not care about the load process of the kernel and initrd image, we only care the load result, that is, whether the kernel is in the right address and is in correct state when we boot the guest operating system.

3.6. The relations between the three parts

The trusted part is built upon the hardware root of trust. The physical platform configuration is measured by the trusted bootloader, it loads and measures itself and the hypervisor, and stores the measurements in the hardware TPM. Users can use remote attestation to verify the boot process, and make sure that the trusted Xen hypervisor is running on the physical machine. We use a modified Xen hypervisor, it is adapted to support verification of the guest VM kernel image. As shown in Figure 1, the hypervisor is responsible for CPU scheduling and memory partitioning among VMs. It has no knowledge of networking, external storage devices, video, or any other common I/O functions found on a computing system. The guest VMs in protected part rely on the hypervisor to provide scheduling and memory protection, and they depend on the Qemu in dom0 to provide virtual devices and services, such as network, storage, video, virtual firmware, etc. Qemu is responsible for booting the guest VMs.

Figure 1. Overview of the architecture. The system is separated into three parts. Box 1 contains the trusted part, box 2 contains untrusted part, box 3 contains protected part.

3.3. trusted part

This part includes the hardware platform, a trusted bootloader and a trusted Xen hypervisor. The hardware should support the following techniques: TPM: TPM provide a secure environment for authenticated booting, secure storage and secure IO. It is the security base of our architecture. IOMMU: with IOMMU, we can prevent malicious dom0 device drivers from compromising the system address spaces through DMA.

938

Figure 2 illustrate the Qemu and guest VM relations in our architecture. We only activate virtual network devices and virtual disk devices. To prevent dom0 from hacking into the guest VM, We modify the guest VM kernel as follows: a) Disable mouse, vga console, frame buffer, keyboard, serial, sound in the kernel configure file. These are not necessary to remote users, and they may disclose critical information to the cloud service administrator. b) Disable the ACPI configure option. We do not trust the code in the ACPI tables and BIOS, because they are provided by Qemu, and may include Trojan horses. Without ACPI, the kernel can still work in the legacy mode to initialize devices. With the help of hypervisor, bios calls can be avoided during the kernel boot process. c) Disable the kernel debug options to prevent malicious administrator from tapping the kernel. d) Enable dm-crypt option, it will provide transparent encryption of block devices using the kernel cryptapi. We rely on it to protect guest VMs virtual disks. e) Only include necessary device drivers.

Finally, create a boot disk image, install grub on the disk image, and put the kernel and initrd on it. Send these two disk images to the dom0 on the cloud server. To protect the data privacy in the boot process, we separate the boot process into the following seven steps. ( As shown in Figure 4 ) (1) After remote attestation, the remote user sends a boot request to dom0. (2) Dom0 use Qemu to launch the specific guest VM. In the guest VM, grub loads the encrypted kernel and initrd images to the appointed address. (3) The kernel wrapping code executes a hypercall, ask the hypervisor to decrypt the images. (4) The hypervisor challenges the remote user. (5) The remote user gives the PASS-BOOT encrypted with the hypervisors public key, the hypervisor decrypt the guest VM kernel and initrd. (6) Hypervisor transfers control to the guest VM, the guest VM kernel continues its work and commit several checks to make sure it is placed in the right address and in a correct state. (7) After the kernel getting up, the PASS-FILE is used to mount the encrypted file systems. Now, a new secure guest system starts to work.

Figure 3. The wrapped kernel and initrd image Figure2. Qemu and guest VM in our architecture

Figure 4. The guest VM boot process.

3.7. Guest VM boot process.

We must guarantee that only the valid user can boot the guest VM and the boot process is absolutely safe. Before boot the guest VM, the user need to prepare the boot disk image and root disk image. Firstly, create an encrypted disk image, install the root file system on it, store the password (call it PASSFILE) of this disk image in initrd. Secondly, compile the kernel, encrypt the kernel and initrd with a password (call it PASS-BOOT), then wrap the encrypted kernel into a pack. The wrapping code includes a hypercall, which ask the hypervisor to decrypt the kernel and initrd. Figure 3 shows the kernel pack.

In the above process, dom0 can only see the encrypted password, and has no chance to hack into the boot process. Only the valid user can boot the guest VM.

4. Evaluation
In this work, we aim to improve the data privacy of guest VMs and prevent potential attacks come from two kind of sources: the owner of the hardware machine and the cloud service administrator (in our case, dom0) .We evaluate our system confidentiality in the following aspects:

4.1. Hardware platform

In our implementation, we use a TPM-based trusted loader, OSLO [8], to boot the physical server. It
939

leverages the Dynamic Root of Trust for Measurement (DRTM) to secure the boot process. With the help of the loader, our trusted hypervisor finally takes over the machine. Users can use TPM-based attestation to verify the software stack running on the physical machine. If a malicious program alters part of the boot loader or operating system, the cloud customer can detect the change quickly and reliably. So, users can be ensured that the hardware platform is trustworthy.

failure will be logged in a temporary buffer, and the user can use remote attestation to acquire the information.

4.6. Virtual devices

Qemu connects the untrusted part and protected part, so, we must treat it very carefully. It provides all virtual devices for guest VMs: network interface card (NIC), disk, vga, mouse, keyboard, serial, sound, Qemu also provides other virtual platform chips such as Programmable Interval Timer (PIT), Programmable Interrupt Controller (PIC), bus controller (e.g., PCI bus controller) and virtual firmware. In our work, we modify the guest kernel, and only allow several specific NIC drivers and IDE driver leave in the kernel. ACPI and bios codes are disallowed to execute in the kernel initialization process, so, dom0 cannot compromise the guest system by embedding Trojan horses in these codes. A few bios calls are moved into the kernel wrapping code, such as E820 call, they are executed before the kernel initialization and the results are saved in appointed addresses. In rare cases, guest kernel needs to read some system information from the bios data area, which may be tampered by the dom0. We research these situations and find these malicious modifications do affect the kernel behavior to some extent, but they cannot lead to privacy leakage. In all the above situations, the machine owner and system administrator can break down the data availability, integrity and recoverability of the guest VMs, but they cannot break down the data confidentiality. It should be noted that we only provide a mechanism to prevent the cloud provider from hacking into the guest VM, the guest OS still needs effective measures to protect attacks from the internet.

4.2. Memory isolation

The Xen hypervisor allows multiple VMs to run at the same time. A VM may only manipulate its own page table to include pages which it has been granted explicit access. Even dom0, confined by IOMMU, cannot access the memory of other VMS. Therefore, the cloud service administrator cannot undermine the confidentiality of the memory space.

4.3. Storage
A virtual block disk (VBD) in guest VMs, may exist as a file in dom0, or as a physical disk or partition. All disk I/O in VMs need the help of dom0, so, dom0 may inspect into the data block and tamper their contents. In our work, we protect our virtual disks using the dm-crypt API. Dm-crypt is a transparent disk encryption subsystem, it is implemented as a device mapper target and can encrypt whole virtual disks. Dom0 can only reveal the data in encrypted form. Data secrecy, integrity, ordering and freshness are protected up to the strength of the cryptography used. If the dom0 or other hostile code tries to modify the encrypted data, the guest VM will just terminate.

4.4. Network
The virtual network driver is implemented as a virtual split device that has a front end in the guest VM and a back end in Qemu. Dom0 services just like a router. We make no effort to protect network I/O, as this is addressed by existing technologies such as SSL. Users can also use Virtual Private Networking (VPN) to perfectly protect the confidentiality and integrity of the network.

5. Related work
The European Network and Information Security Agency (ENISA) assesses the risks and benefits of cloud economies from a security point of view [9]. ENISA lists the top security risks, including, loss of governance, isolation failure, data protection, malicious insider, etc. Kelton Research conducts on survey of the cloud computing in 2009 and analyzes the status quo of cloud computing. There are many endeavors have been made to improve the data privacy. The Terra [10] architecture proposes moving the entire application into a separate VM with its own application-specific software stack tailored to its assurance needs, but Terras security

4.5. Guest VM boot process

The kernel and initrd image are all encrypted by the user. Dom0 cannot get the plain-text password, therefore, it cannot decrypt the kernel image. If the dom0 modifies the kernel or initrd image, the hypervisor will fail when decrypting the images, the

940

infrastructure depends heavily on the privileged management VM. Microsofts Next-Generation Secure Computing Base (NGSCB) [11] is also aiming to provide a system-wide solution that includes hardware, operating system kernel and an execution environment. Derek G. Murray uses disaggregation to shrink the TCB of a virtual machine in a Xen-based system, in their work the VM-building functionality is moved into a separated, trusted VM which runs alongside dom0. A major limitation of this approach is that the dom0 kernel must be included in the TCB [12]. Nizzas work presents an architecture that allows to build applications with a much smaller TCB. It is based on a kernelized architecture and on the reuse of legacy software using trusted wrappers[13]. Flicker leverages new commodity processors from AMD and Intel to establish a mechanism that can support secure execution even the surrounding operating system is completely compromised [14].

environment and give many suggestions to improve our work.

8. References
[1] Kelton Research, 2009 Global Survey of Cloud Computing, Jan 2009. [2] Sun Microsystems, Introduction to cloud computing architecture white paper, June 2009. [3] Wikipedia, http://en.wikipedia.org/wiki/Cloud_computing. [4] Amazon Web Service, http://aws.amazon.com/. [5] P. Barham, et,al, Xen and the art of virtualization. In Proceedings of the nineteenth ACM symposium on operating systems principles, pages 164177. ACM Press New York, NY, USA, 2003. [6] Qemu, http://wiki.qemu.org/. [7] TCG: Trusted Computing Group. https:// www.trustedcomputinggroup.org [8] B. Kauer. OSLO: Improving the Security of Trusted Computing. In Proceedings of the 16th USENIX Security Symposium. USENIX Association, 2007. [9] ENISA, Cloud Computing: Benefits, risks and recommendations for information security, Nov,2009. [10] T. Garfinkel, B. Pfaff, J. Chow,M. Rosenblum, and D. Boneh. Terra: a virtual machine-based platform for trusted computing. In Proceedings of the 19th ACM Symposium on Operating Systems Principles, pages 193206. ACM Press New York, NY, USA, 2003. [11] A. Carroll, M. Juarez, J. Polk, and T. Leininger. Microsoft Palladium: A business overview. http:// www.microsoft.com/PressPass/ features/2002/jul02/0724palladiumwp.asp,August 2002. [12] Murray, D. Improving Xen security through disaggregation. In Proceedings of the Fourth ACM SIGPLAN/SIGOPS international conference on Virtual Execution Environments. 2008. [13] H. Hrtig, M. Hohmuth, N. Feske, C. Helmuth, A. Lackorzynski, F. Mehnert and M. Peter. The Nizza Secure-System Architecture. In IEEE CollaborateCom 2005. San Jose, USA. Dec 2005. [14] Jonathan M. McCune, et al, Flicker: an execution infrastructure for tcb minimization, Proceedings of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008, April 01-04, 2008, Glasgow, Scotland UK.

6. Conclusion
In our work, we focus on improving the data privacy in cloud computing, and try to find a solution to prevent the potential attacks come cloud service provider (in our case, dom0). By using the Xen-based virtualization technology and TPM-base trusted computing technology, we construct a secure and robust virtualization platform. Based on this platform, we divide the whole system into three parts: trusted part, untrusted part, protected part. We place the dom0 and the Qemu application in the untrusted part, because they are controlled by the cloud service provider. To achieve better isolation between VMs, we customize the guest VM operating system, disable all the unnecessary virtual devices, and disallow code from untrusted part to be executed in the guest VM. These modifications greatly improve the data privacy of the guest VM. Finally, we evaluate our system confidentiality in the following aspects: hardware platform, memory isolation, storage, network, guest VM boot process, Qemu virtual devices. The evaluation shows that our architecture provides a good solution to protect the confidentiality of the cloud clients. In future research, we will concentrate on the control and data flow analysis and policy analysis about the Qemu virtual driver models in greater detail.

7. Acknowledgements
We would like to thank my colleagues in TU Dresden, they offer us an excellent research

941