20 I 0 International Conference On Computer Design And Appliations (ICCDA 2010)

Sealed Storage for Trusted Cloud Computing

Ge Cheng School of Mathematics and Computational Science

Xiangtan University Xiangtan 411105, China

chengge@ xtu.edu.cn

Abstract-In cloud computing, cloud user's sensitive data is in the control of a third part, which will lead to considerable risk

on the privacy and security of the data. To address this problem we propose a trusted cloud computing platform with

sealed storage ability (TSSC). TSSC enable Infrastructure as a

Service provider (IaaS) such as Amazon EC2 to provide

remote attestation to the IaaS user by an attestation delegation server and seal the IaaS user's sensitive data with their desired integrity of the IaaS configuration. We implement our solution

on Xen, and present a simple prototype based Nimbus. Our evaluation results show that the performance overhead of the solution is acceptable.

Keywords - cloud computing; trusted computing; remote attestation; sealed storage; Infrastructure as a Service

1. INTRODUCTION

Cloud computing provides flexible outsourcing computations and storage for enterprises and organizations, and enables resource-on-demand and pay-as-you-go computing models. There are broadly three varieties of cloud computing offerings, Infrastructure as a Service (IaaS), Software as a Service (SaaS) and Platform as a Service (PaaS). IaaS is more popular, which has many commercial providers such as Amazon[I], Flexiscale[2], OoOrid[3], IBM[4], etc. The providers allow their user outsources the equipment used to support operations, including storage, hardware, servers and networking components. The provider owns the equipment and is responsible for housing, running and maintaining it. The user typically pays on a per-use basis. However, this new technology brings new security challenges, especially the security and privacy of information stored and processed within the cloud. In this paper, we focus on the security and privacy problems in IaaS.

One of the security risks in cloud computing is that the cloud users lose control of their data when they transfer their information into the cloud for processing or utilize the cheap storage offered by the cloud. The security of such platform can not only be threatened by malicious attacks, such as defects, Trojan horses, and viruses but also by the management and the cloud administers' malicious act. While the first type of threats is relatively easy to eliminate with such as widely-deployed anti-virus software, the latter becomes very challenging. How can a cloud user trust that the cloud environment really exists as they were told and that the system is not compromised before he/she uses the cloud service and how can he/she believes that hislher sensitive

Alex K. Ohoussou School of Computer Science and Technology

Huazhong University of Science and Technology Wuhan, 430074, China ohouss@hotmail.com

data will be carefully protected once the environment is compromised. So, a computing system in cloud computing environments should be trusted by a remote client or user, for example, its declared quality of service is preserved, or user's valuable or privacy-sensitive data on clouds are protected from other entities including cloud service providers.

Trusted Computing Oroup (TCO) [5] has specified a small and low-cost Trusted Platform Module (TPM) hardware component to enhance the security of computer systems. Various mechanisms have been developed to use such hardware to generate a proof of a system's integrity, such as remote attestation and authenticated boot [6][7). Other approaches have been proposed to extend integrity measurement and verification up to application level [8][9][10]. These approaches provide a way to start with a small trusted computing base (TCB) including TPM and operating system (OS) kernel, and try to build a proof for the whole system by measuring each piece of software components according to the sequence of platform booting and application loading. Due to those abilities of trusted computing that can verifY whether the platform is a known­good implementation and is running with a known-good configuration, some researchers propose to apply trust in cloud computing [11][12).

Unfortunately, previously proposed TCO-Iike integrity measurement and attestation mechanisms have some shortcomings which make them unpractical in cloud computing. Firstly, resources are organized dynamically in cloud, so using these resources and organizing them generally haven't the synchronization and cloud users implement its operations through the cloud portal, while the remote attestation need direct interaction between TPM embedded platform and the challenger. Secondly, traditional approaches lack the ability to protect sensitive information when a system's integrity is broken during runtime in cloud computing. It is critical for cloud users to have the assurance that their sensitive data are protected once the trustworthiness of a cloud platform is compromised.

In this paper, we propose a trusted cloud computing platform with sealed storage ability (TSSC). TSSC allows the cloud user to remotely attest the cloud environment, but to avoid the cloud resource to be directly exposed to the cloud users by a remote attestation delegation service (ROS). The cloud users can determine whether the cloud backend satisfY the user's security requirement. Moreover, TSSC

978-1-4244-7164-5/$26.00 © 2010 IEEE V5-335 Volume 5

2010 International Conference On Computer Design And Appliations (ICCDA 2010)

provides sealed storage ability allowing the cloud user to bind their sensitive data with their desired cloud environment integrity by disk semantics reverse parsing technology, which will reduce the risk of data leakage once the trustworthiness of a cloud platform is compromised.

The remainder of this paper is organized as follows. In section II, we introduce some related work. In section III, we present the architecture of our design. In section IV, We describe our implementation. Section V analyses the runtime performance of our implementation and section VI concludes this paper.

I I. RLA TED WORK

Cachin [14] contains a survey of security issues in the context of cloud storage services and recent research addressing these issues; Armbrust [15] is a more general survey of cloud computing. Both of these papers point out some of the same challenges that motivate our work.

Peltier et[ll] propose a trusted cloud computing platform (TCCP) which enables laaS providers to serve a closed box execution environment that guarantees confidential execution of guest VMs. This system allows a customer to verifY if its computation will run securely, before requesting the service to launch a VM. TCCP assumes that there is a trusted coordinator hosted in a trustworthy external entity, however, it is impossible to make the backend of the cloud visible to the third part. Moreover, TCCP lacks the mechanism to protect cloud user's data, once the cloud backend nodes are compromised. Our mechanism is different. TSSC allows the cloud users to indirectly measure the cloud backend, which relies on a remote attestation delegation service (RDS) provided by the cloud provider. So, TSSC can seamlessly cooperate with the current cloud architecture. Further, TSSC provide sealed storage to reduce the leakage risk of cloud user's sensitive data.

Krautheim[12] provides a Private Virtual Infrastructure (PVI) that shares the responsibility of security in cloud computing between the service provider and client, decreasing the risk exposure of both. The challenge of PVI is similar to TCCP, which need exposure of every implementation detail to the cloud user and lacks sealed storage ability.

III. TSSC ARCHITECTURE

A. The components of TSSC TSSC doesn't need substantially changing of the cloud

architecture, but its functionality is built in the cloud management and resources layer. As Figure I shows, in cloud computing management layer there is a need of adding a remote delegation service (RDS). In each node, there is a need of a virtual machine monitor (VMM) with trusted boot ability and two additional modules-remote attestation module (RAM) and sealed storage module (SSM).

In TSSC, the cloud backend nodes are not required to run a special VMM that host customer's VMs, but they need a VMM that supports TCO-style chain of trust to the VMM layer with remote attestation and sealed storage ability. Security assurance in a cloud is ultimately limited with

VMM in the cloud backend nodes. The best choice is that the VMM can prevent the privileged cloud administrator form inspecting or compromising the cloud user's application or data in the VM. However, TSSC let's the cloud user decide whether the VMM can satisfY their security requirements.

RDS is a bridge for cloud users to attest the relevant backend nodes' integrity. RDS cooperates with the cloud resource management software and RAM, SSM in each cloud node to 1) attest the integrity of each node when cloud user's VM launches, migrates and return the results to the cloud users 2) monitor the integrity changes of the cloud node and achieve the sealed storage according to the integrity requirement of cloud user.

laaS I)crimclcr

/'1----,.,..-,--=::7"----1 Node E

VMM

i-_--;-;--:;--,-----;;;"TV"" M;;:M"----------1Node N

Hardware(TPM )

Figure 1. TSSC architecture

The RDS is under the control of the cloud provider, which may have the incentive to deceive the cloud user. To solve this problem, it is required that RDS has secrecy ("the adversary cannot see inside this space") and control ("the adversary cannot change what this space is doing") features, and even the platform owner can not compromise those features. The software itself cannot have those features, so the best way is to let the RDS run separately in a security co­processor platform analogous to IBM4785, which actually become the RDS into a neutral third party. Referring to former researches [8][9][10], the business computing platform is close to the secrecy and control feature. In this article we assume that RDS meets the above requirement.

RAM and SSM are two function modules of the VMM in each cloud node. RAM provides the integrity report of the cloud backend nodes to the RDS, which is the current platform's measurement signed by the platform authentication key (Attestation Identity Key, AIK). SSM dynamically encrypt and decrypt the data specified by cloud user, according to RDS's instructions to achieve sealed storage function.

B. TSSC attestation and sealed storage workflow The integrity of the cloud backend nodes is attested

remotely on the user's behalf to make sure it is un-tampered and trustworthy. The expected hash value is either from cloud node signed by the user or directly from the user's deployment request. TSSC will seal the user's data with this hash Value (in figure 2).

V5-336 Volume 5

20 I 0 International Conference On Computer Design And Appliations (ICCDA 2010)

I cloud user I � RM! : : , , : : Register I IE , ,

RDS remote attest ion ); ,

Sign ): , , , , ,

Rel�ote attesta5r- on < yM deploymen� )

: :Seal � �

re-attestation <:'VM migratio� or :VMM updating: ) , , : :Seal , , , , , , , , , , , , , , , ,

instrucfion , , , , , , , ,

ins true lion ). , , , , , , ,

Figure 2. TSSC attestation and sealed storage workflow

VMM registration: Before a cloud backend node is available, RAM of the node is required to register the integrity information of this node to RDS. The node's integrity information is based on the value of the platform configuration registers (Platform Configuration Register, PCR) in TPM embedded in the nodes.

RDS remote attestation: Cloud users firstly verify the integrity of RDS. When RDS is authenticated by a user, RDS generates a pair of asymmetric keys for this user, and takes the private key as the user's signature key. Cloud users can check the integrity information of the cloud backend nodes stored in the RDS, which the RAM of the nodes registers to the RDS before they are available. If the integrity information of the nodes meets the cloud users' security need. They sign the integrity of the cloud backend nodes and the location information of the data they want to seal, and then return them to RDS. The cloud user also needs to sign the hash value of his VM image, whether the VM image is provide by the cloud user or the cloud provider.

Nodes Attestation: Before the cloud user's virtual machines are deployed in a node, RDS interacts with the RAM to attest the node. RDS acquires the node's PCR value signed by AIK and compared with the value signed by cloud user to confirm whether the node's integrity (include the cloud user's VM image) is compromised after it registered, which can prevent the platform in an unsafe state. The node in an unsafe state is not allowed to provide resource services. If the node's integrity complies with cloud user's expectations, the RDS generate a sealed storage symmetric key for the user and send it to SSM in that node. RDS will safely store the user's sealed storage key by sealing with the current PCR value of the platform where it is hosted.

When VM migration, shutting down nodes temporarily for maintenance or upgrades, the RAM in the node which the VM will migrate to or the upgraded node will initiatively launch the attestation request to RDS to re-attest the platform.

Sealed storage: When the user's virtual machine deploys in the cloud nodes with expected integrity, SSM dynamically

encrypt the user-specified data when the data is stored to disk and decrypt them when they are read from the disk by the sealed storage symmetric key. Sealed storage is achieved in the VMM, which does not required to modify the as in the VM. So the VMM need analysis of the operation semantic and control the disk I/O of the guest as.

IV. IMPLEMENTATION

This section describes the implementation of our design. We introduce how to use trusted computing technology to provide remote attestation of the execution environment, and how to implement sealed storage.

A. Integrity attestation TSSC focuses on how to verify the trustworthiness of the

cloud backend nodes. Cloud users directly attest the integrity of RDS and indirectly attest the integrity of cloud backend nodes by RDS. In our implementation, a single platform with TPM hosted RDS, and the cloud user must attest RDS's platform's Startup configuration and the dynamic measurements that have taken place on the attesting system since it has been booted. RDS adopts the IMA architecture to extend integrity measurement and verification up to application level. RDS uses the TPM's protected storage of the TPM aggregate to protect the integrity of the measurement list. Once a measurement is taken, it cannot be changed or deleted without causing the aggregate hash of the measurement list to differ from the TPM aggregate [6]. However, the cloud user must also ensure that RDS has the measurement architecture correctly in place so that all necessary measurements could be actually initiated and carried out.

As for the cloud backend node, in our implementation, we take Xen [20] as the VMM and modify the TOrub[17] to support Xen trusted boot. TOrub is an enhancement of the open-source boot loader for adding the TCO measurement capability. In each node, TPM stores the hash values of configuration information in PCRs during the process of system boot. As Trusted Orub is installed, during the process of measurement, Xen is measured and the Stored Measurement Log (SML) which records the measurement series is updated. The measurement result can be signed with the private key of an AIK, alias of the unique Endorsement Key (EK), and reported to RDS by the RAM in order to provide the evidence that the VMM has not been compromised. Since Xen take DomO as privilege VM to manage the VMM, the as in DomO also need to adopt IMA to provide application level chain of trust.

B. Sealed storage At the VMM layer, most of the operations captured are

low-level operations, which are closely related to specific system architecture. For example the disk operation information intercepted by the VMM may be the physical block number or virtual disk port and the parameters of reading and writing operations (depending on the implementation of the VMM). However, the data location information which the cloud users want to seal is described with higher level semantics , for example directories and

V5-337 Volume 5

20 10 International Conference On Computer Design And Appliations (ICCDA 2010)

files. Our implementation uses disk semantics reverse parsing technology to get the directories and files disk operation semantic from low level disk block operation semantics by establishing the map between these low-level disk block to the directories and files by the B1ktap of Xen[18]. Blktap is a user-mode driver which directly manages disk activity with relatively small performance cost. SSM intercepts file operations in the user-mode of DomO when a disk data is processed by the tapdisk driver of Blktap.

To get the directories and files disk operation semantic, SSM establishes the map between these low-level disk block to the directories and files. The file system divides high-level file into logical blocks and maintains the map between logical block to physical block. On the contrary, reverse semantic parsing maps the low level disk blocks to the directories and files. For example, ext2 is split up in blocks, and organized into block groups, analogous to cylinder groups in the Unix File System. Each block group may contain a copy of the superblock and block group descriptor table, and all block groups contain a block bitmap, an inode bitmap, and an inode table and followed by the actual data blocks.

SSM translates the directory structure and files into the corresponding disk block number they occupied by creating some data structures in its memory space which is similar to virtual file system of UNIX operation. Low-level operation information obtained by VMM can be matched in these data structures to derive the high-level operational semantics. For example, assuming that the corresponding disk block of file letc/init.dlrc is 211105,211106, and the file letc Iprofile are 223,236. If the low-level operational information obtained by VMM is read 211,105 disk blocks, it may be inferred that the high-level semantics read the file letc/init.dlrc.

SSM builds a structure called sealed file to record the translated results according to location information of the data which cloud user's want to seal. For any disk operation, the operation's block number is hashed into the sealed_file. If the record's block number is found in sealed_file, it indicates that this disk 1/0 operation is accessing the sealed data. SSM blocks it, encrypts or decrypts it by the seal storage symmetric key. If the block numbers are not matched, SSM does not take any action and the disk operation continues.

Encrypting and decrypting disk I/O inevitably bring performance cost. SSM uses the replication and lazy synchronization scheme mechanisms [19] to minimize performance overhead. Replication reduces the number of cryptographic operations by keeping multiple decrypted versions of the same files; lazy synchronization further minimizes the overhead triggered by an update on one of the replicated files. SSM keeps the copies of decrypted files, and the encryption is performed only when the file is initially created. Once the decrypted file is created, it continues to be used without incurring any further encryption until there is a need to synchronize file to disk.

V. SYSTEM EVALUATION

Our cloud experiment environment is based on Nimbus [21] which includes a set of open source tools that provide an

"Infrastructure-as-a-Service (IaaS)" cloud computing solution. The experiment environment consists of 5 machines connected with a 100Mbps Ethernet. Cloud users login cloud portal through Pentium III machines with 10Hz, 512MB RAM and red hat Linux installed. The remote attestation delegation server is Pentium 4 machines with 20Hz, 20B RAM and Federal Linux installed with TPM 1.2 and IMA patch. The Nimbus middleware is a Pentium 4 with 30Hz, 20B RAM and Federal Linux installed. Two Nimbus resource nodes are Pentium IV with 2 0Hz, 2 OB RAM, TPM 1.2 running Debian Linux in a Xen environment with modified TOrub and IMA patch. The Xen-based VM image involved in our experiment is Fedora 8 OS and 750MB in sIze.

While the presented features are required for effective remote attestation in cloud environments, they create a certain amount of overhead. The transmission time is extended due to the extra remote attestation, and the decryption/encryption also consumes some time compared to a completely unsecured cloud operation.

40

30

"' " ,§ ,,20 Q)

E i)' C. Q)

o 10

2 4

Figure 3. TSSC trusted deployment overhead

We deploy cloud user's virtual machine methods in different situation. The first one is the traditional nimbus cloud, which's deployment time is mainly spent on resource scheduling and launching a remote VM. The second one is a deployment with the integrity attestation we proposed. Except resource scheduling and VM launch, the time spent by VMM and VM remote attestation, measurement should be calculated. We conduct the experiments for the above two methods 50 times respectively, and calculated the average of the various steps every ten times.

The result is shown in Fig3 that the extra time for TSSC to attest cloud backend node is about 18 seconds, which is almost twice compared with the ordinary Nimbus deployment. Most of the time (about 16 seconds) is spent on the measurement and verification of virtual machine image, which depends on the size of the image file and the computing capability of resource nodes. It is acceptable because compared to the virtual machine running time the proportion of start-up time is very small, so that an increase of twice start-up overhead is acceptable.

V5-338 Volume 5

20 I 0 International Conference On Computer Design And Appliations (ICCDA 2010)

2.2 2.1 2.0 1.9 1.8 1.7 1.6 1.5 1.4 1.3 1.2 1.1 1.0 0.9 0.8 �'-����-r�������

5 6 File size

Figure 4. TSSC sealed storage overhead

10 11

The decryption/encryption also consumes some time compared to a completely unsecured cloud operation. We perform a micro-benchmark by varying runtime write file size. Figure 4 shows the results. As expected, runtime penalty increases as the file size increases. If the file size is small enough (less than 4MB), the performance degradation is less than 15%. When the decryption synchronization hits 10MB, it takes almost twice as long. Because the program runs with localized, this sealed storage mechanism will not bring much performance overhead. Note that these benchmark results are obtained from the un-optimized implementation.

VI. CONCLUDE AND FURTHER WORK

This paper proposes TSSC for improving the security and privacy of the cloud user's data stored and processed within the cloud, which based on trusted computing and VMM technology. In TSSC, the environment is measured and the user can decide whether the environment is trustworthy or not, and then cloud user's sensitive data is sealed according to hislher integrity requirement. For example, if the user requires high privacy protection for his/her data that required the VMM prevents privileged users from inspecting or modifYing them. The user needs to choose a virtual machine monitor (TVMM) with the ability to satisfY hislher privacy protection requirement. TSSC can guarantee that it can't lie to the user by measuring the integrity of the cloud backend nodes and sealing the data. Our implementation confirms that the performance overhead caused by TSSC is acceptable. Since the security ability of TSSC is eventually depend on the design of the VMM in each cloud backend nodes, we plan to go into detail about the design of the trusted VMM in the near future.

ACKNOWLEDGEMENT

This work is supported by the National Natural Science Foundation of China under grant No.1 0771178 and the Key

Project of Chinese Ministry of Education under grant No. 208093.

REFERENCES

[I] Amazon Elastic Compute Cloud (EC2), http://aws.amazon.com/ec2/

[2] Flexiscale public cloud, http://www.fiexiant.com/products/flexiscale/

[3] Gogrid, http://www.gogrid.com/

[4] Blue cloud, http://wwwibm.comlibm/cloud/

[5] Trusted Computing Group. https://www. trustedcomputinggroup.orgl, 2003.

[6] S. W. Smith, "Outbound Authentication for Programmable Secure Coprocessors," International Journal of Information Security, Springer: Berlin, 2004; 3(1):28-41.

[7] H. Maruyama, F. Seliger, N. Nagaratnam, T Ebringer, S Munetoh, Yoshihama S, and TNakamura, "Trusted Platform on Demand," Technical Report RT0564, IBM, 2004.

[8] R. Sailer, X Zhang, T Jaeger, and LV. Doom, "Design and Implementation of a TCG-based Integrity Measurement Architecture," Proce. 13th Conference on USENIX Security Symposium, USENIX Association, 2004, pp. 223-238.

[9] R. MacDonald, S.W Smith, J Marchesini, and O. Wild, "Bear an Open-source Virtual Secure Coprocessor Based on TCPA," Technical Report TR2003-471, Dartmouth College, 2003.

[10] TJaeger, R. Sailer, U. Shankar, "PRIMA: Policy Reduced Integrity Measurement Architecture," Proc. 11th ACM Symposium on Access Control Models and Technologies, ACM Press, 2006, pp. I 9-28.

[II] N. Santos, K. P. Gummadi, and R. Rodrigues, 'Towards Trusted Cloud Computing," Proc. HotCloud, June 2009.

[12] F. J Krautheim, "Private Virtual Infrastructure for Cloud Computing," Proc. HotCloud, June 2009.

[13] Sealed storage, http://en.wikipedia.org/wiki/Trusted_Computing# Sealed_storage

[14] C Cachin, L Keidar, and A. Shraer, "Trusting the Cloud," ACM SIGACT News, 40(2):81-86, June 2009.

[15] M. Armbrust, A Fox, R. Griffith, A D. Joseph, R. H. Katz, A Konwinski, G. Lee, D. A Patterson, A. Rabkin, 1. Stoica, and M. Zaharia, "Above the Clouds: A Berkeley View of Cloud Computing," Technical Report EECS-2009-28, University of Cal ifornia at Berkeley, February 2009.

[16] J G. Dyer, M. Lindemann, R. Perez, R. Sailer, L.v. Doom, and S. W. Smith, "Building the IBM 4758 Secure Coprocessor," IEEE Computer 2001,34(10):57-66.

[17] Trusted Grub, Applied Data Security at University of Bochum, http://www.prosec.rub.de/trustedgrub.html

[18] AWarfield, "Virtually Persistent Data," Xen Developer's Summit (Fall 2006), 2006.

[19] J Yang and K. G. Shin, "Using Hypervisor to Provide Data Secrecy for User Applications on a Per-Page Basis," Proc. fourth ACM SIGPLAN/SIGOPS international conference on virtual execution environments, Mar. 2008, pp.71-80.

[20] B. Dragovic, K. Fraser, S Hand, THarris , A Ho, L Pratt, AWarfield, P. Barham, and R. Neugebauer, "Xen and the Art of Virtualization," Proc. ACM Symposium on Operating Systems Principles, pp. 2003, pp.l64-I77.

[21] Nimbus, http://workspace.globus.org.

V5-339 Volume 5