A Remote Attestation Approach for a Secure Virtual Machine Migration ...

A Remote Attestation Approach for a Secure Virtual Machine Migration in Federated Cloud Environments Antonio Celesti, Angelo Salici, Massimo Villari and Antonio Puliafito Dept. of Mathematics, Faculty of Engineering, University of Messina Contrada di Dio, S. Agata, 98166 Messina, Italy. e-mail: {acelesti, asalici, mvillari, apuliafito}@unime.it

Abstract—Nowadays, cloud computing is considered as a new charming technology, where new opportunities in ICT world are becoming real. Cloud is appealing many IT companies, but the largest business is in hand of big cloud operators. In the near future the scenario could change, and becoming much more complex even involving small and medium providers. Cloud operators could collaborate to satisfy the increasing cloud customer demand. The security is one of the main aspects that might limit such a collaboration. This paper deals with the opportunity to leverage the Trusted Computing technology for encouraging the federation in trustiness among heterogeneous clouds. In this work, we describe how Trusted Computing may increase the security in clouds, in particular when VM migration takes place between federated providers. Keywords-Cloud Computing; Federation; Remote Attestation; Trusted Computing; Virtual Machine Migration.

I. I NTRODUCTION The current cloud computing vision is to enable the delivery of on-demand services at competitive costs, and without requiring a large capital investment in infrastructure [1]. Nowadays, one of the main challenges to address is to minimize the barriers of delivering services as utilities among different domains. This complex delivery scenario is labeled as Federation of Heterogeneous Cloud Infrastructures at IaaS level. Such an ecosystem includes hundreds of independent, heterogeneous clouds, able to transparently share physical resources. Many business operators have predicted that the process toward interoperable federated Intercloud environments will begin in the near future . But for the time being, the main problem for accomplishing such a goal, is that commercial virtualization systems typically offer non-standard management interfaces which are limited to their proprietary technologies and environments. Scientific initiatives are trying to pursue an abstraction layer that will allow to develop a set of high level management components that are not tied to any specific environment [2]. Moreover the standardization bodies are working to create standard interfaces that will enable interaction between distributed sites, allowing the federation of infrastructures (i.e., IEEE [3], ETSI [4]). One of the main concerns regarding the adoption of cloud computing is the Security. This concern becomes much more critical if we consider a federation of heterogeneous collaborating clouds. Recently, many initiatives are trying to address

security in emerging distributed complex scenarios and the one which seems the most promising is Trusted Computing (TC). TC has had controversial opinions during the last years. It has been seen as the way for reducing the anonymity of end-users using IT services. Richard M. Stalmann, the father of GNU Free Software in his essay: Free Software, Free Society: The Selected Essays[5] highlighted that behind the TC, there is a clear action, perpetrated by major IT companies, of tracing customers and not to assure them more security and privacy. For Stalmann PCs with this technology become treacherous computers. We totally agree with this vision in which TC might limit users freedom. However, TC is also finding many other application contexts. In [6], TC is proposed to build up an Anti-Forensics System for preventing the violation of user data used in a court of law. Tanebaum et al [7], used TC for designing a trustworthy voting system. Besides, it is possible to find in literature many other initiatives. In [8][9] TC was used in mobile and embededed systems. The TERESA (Trusted Computing Engineering for Resource Constrained Embedded Systems Applications, [10]) project is aimed to define, demonstrate and validate an engineering discipline for trust that is adapted to resource constrained embedded systems. Nowadays, thanks to cloud computing, TC is living a second life. If we give a look at the number of works facing the security issue on cloud exploiting TC we notice, in the last two years, a considerable contribution [11], [12][13], [14], [15] as well in the virtualization technology [16], [17], [18], [19]. Our work aims to increase the level of security at IaaS level in a scenario where cooperating cloud providers lend physical resources from other clouds. We specifically discuss how to apply the concepts of Trusted Computing (TC) and Remote Attestation (RA), in order to guarantee that a cloud provider needing to migrate a Virtual Machine (VM) into another cloud provider, that the destination hardware/software system is trusted. The paper is organized as follows. Section II, provides an overview about TC and RA. In Section III, we motivate why TC suits cloud computing. VM migration in federated cloud environment is presented in Section IV. In Section V, we discuss how to apply the RA protocol to a VM migration task in a cloud federation scenario, also providing the implementation highlights using the Java Trust Software

Stack (JTSS) libraries. Section VII provides an overview of other related works regarding TC applied to cloud computing. Conclusions are summarized in Section VIII. II. T RUSTED C OMPUTING OVERVIEW Trusted Computing (TC), defined by the Trusted Computing Group (TCG) [20], combines hardware and software security to enhance the security of the computing environment in a wide variety of computing platform and implementations. The main goal of trusted computing is to provide stronger security than traditional software-based security systems and to enforce the integrity of a system when it interacts with other ones. The distinguishing feature of the TCG technology is the incorporation of “roots of trust” into computer platforms. A complete set of Roots of Trust has at least the minimum functionality necessary to describe the platform characteristics that affect the trustworthiness of the platform. TC implies the adoption of an hardware device called Trusted Platform Module (TPM). The TCG has defined the specification for this widely implemented hardware security component that is able to provide the platform roots of trust and to extend its trust to other parts of the platform by building a chain of trust. The TPM is basically a secure microcontroller with added cryptographic functionalities. It offers facilities for the secure generation of cryptographic keys and since each TPM chip has an unique and secret RSA key burned in as it is produced, i.e., the Endorsement Key (EK), it is capable to perform platform authentication. The TPM includes capabilities such as machine authentication, hardware encryption, signing, secure key storage and attestation. The TPM makes the encryption and signing stronger by storing keys in protected hardware storage. A trusted computing system enables the detection of unauthorized hardware/software modification collecting information about its current configuration. This information cannot be stored inside the TPM device since it may become very large and so they are stored in a log outside the TPM, called Stored Measurement Log (SML). Manipulations of the SML will be detected because the digest of the original sequence is securely stored inside the TPM. For this purpose the TPM provides a set of registers called Platform Configuration Registers (PCR) that can be used to store hash values. There are at least 16 PCRs in a TPM that store platform configuration measurements. PCRs cannot be written directly. The process of modifying a PCR value is called extension and it ensures that previous states of the system will not be ignored. Moreover, it preserves the order of the hardware software modification. The PCR state is calculated according to the following formula: P CR[n] = SHA − 1{P CR[n] + event} The event represents any hardware/software modification. The state of the hardware/software system can be easily verified applying the SHA-1 algorithm to the values picked up from the SML. The Remote Attestation (RA) is the protocol by which a client authenticates itself in a remote service provider.

Differently from a common authentication, the RA protocol guarantees to the service provider that the client runs authorized hardware/software. The main goal of the remote attestation is to assure to a remote computer that the local PC is a trusted platform and to show its current configuration. For each TPM the public part of the EK is certified by a certification authority. Using the private part of its EK, the TPM can sign assertions about the trusted computer’s state. During the attestation process a remote computer asks for attestation to a local party. The local party generates a public/private key pair called “Attestation Identity Key” (AIK) using the TPM’s EK, that assures its security. The local party sends the AIK public part to a trusted third party, called Privacy Certification Authority (PCA), that generates a AIK certificate after validating the attestator’s TPM EK. The certificate is signed by the PCA and sent back to the local party that can now send its PCR values signed with AIK, SML and the received AIK certificate to the remote computer. The remote computer can now verify the AIK certificate with the CPA public key, verify the signature on the PCR values using the AIK, recalculate this value from the fingerprint list within SML (by applying the PCR’s extend operation on these fingerprints), recalculate this value with PCR’s value. If the PCR value and SML do not match, it implies that the SML had been tampered, and the verifier should decide not to trust the local party. If they do match, the verifier goes through the fingerprint list in SML and looks for any unapproved entity. If no bad entities found, the remote computer can decide that the local party is trustworthy. The Security of the attestation report relies on the AIK which is certified by the Privacy Certification Authority on the basis of the EK. III. W HY SHOULD CLOUDS ADOPT TC? Unfortunately in cloud computing one of the main risks in using virtualization technology is the possibility to corrupt the hardware/software configuration of the server where the VMs are hosted. Cloud customers need to know the level of security that providers can guarantee, whereas the cloud providers need to monitor their internal architecture, in particular the hypervisor behavior and verify its authenticity and integrity. In order to mitigate these threats and assuring trustiness in federated clouds, we identify a set of capabilities based on TC. As we have already mentioned TC is an effort to bring some of the properties of closed, proprietary systems to open, commodity systems. This is done using a combination of hardware and software components. Furthermore, these components allow to check and enforce the integrity of a system, and authenticate itself to remote systems. TC essentially provides three main mechanisms very useful for cloud environments: • Secure boot: to ensure that the system is booted into a trusted operating system that adheres to some given security policy. If such a mechanism is not provided, an adversary could boot the system into a modified operating system that bypasses the security policy.

Fig. 1. Trusted Computing and TPM module: the system before and after VM migration.

Strong isolation: to prevent the system from being compromised after it has been booted, and to prevent applications from tampering with each other. • Remote attestation: to certify the authenticity of hardware/software being run by a remote party. The first two cases allow to avoid any feared risks of runtime isolation corruption. Remote attestation, in our event, can be used for a safe service relocation. In fact in case of VM migration, the hypervisor could check the site where to migrate the VM, and therefore to analyse its TC attestations, before and after migration, as shown by the attestations in Figure 1 on the right side. Figure 1 shows also a stack of layers belonging to hardware and software contexts. These levels describe the conformation of a virtualized site. The attestation documents may list all the stages and parts fairly certified (before and after VM migration). The attestation is referred to a simplified list of layers, the TPM hardware module can perform an indepth analysis of all the components and software modules compounding the whole system. •

IV. V IRTUAL M ACHINE M IGRATION IN F EDERATED C LOUD E NVIRONMENT Differently from the common definition of cloud computing, cloud federation refers to mesh of cloud providers that are interconnected based on open standards to provide a universal decentralized computing environment where everything is driven by constraints and agreements in a ubiquitous, multi-provider infrastructure. Federation is an emerging topic in cloud computing. Until now, the cloud ecosystem has been characterized by the steady rising of hundreds of independent and heterogeneous cloud providers, managed by private subjects which yield various services to their clients. Considering the cloud computing ecosystem, besides large cloud providers, small cloud providers cannot directly compete with mega-providers such as Amazon, Google, and Saleforce. The result is that often small/medium cloud providers have

to exploit services of mega-providers in order to develop their business logic and their cloud-based services. Federation aims to address this issue promoting a cooperation among small/medium cloud providers, thus enabling the sharing of computational and storage resources. This allows another form of pay-per-use economic model for ICT societies, universities, research centers and organizations that commonly do not fully exploit the resources of their own physical infrastructure. The advantage of transforming a physical datacenter in a cloud virtualization infrastructure in the perspective of cloud federation is twofold. On one hand, small/medium cloud providers which rent resources to other providers can optimize the use of their infrastructure, which often are under utilized, and at the same time earning money for the renting of their resources. On the other hand, external small/medium cloud providers can elastically scale their logical virtualization infrastructure borrowing resources and paying them to other providers. In such a context, cloud providers can decide to establish partnerships with other providers for many reasons. A cloud provider can run out of storage and computing resources due to peak of requests, hence needing of external capabilities; a cloud provider needs to instantiate distributed services, hence it has to rent external resources offered by other providers placed in different geographical locations; a cloud provider needs to migrate data in other providers due to fault-tolerance, reaction to cyber attacks, resource optimization, SLA violation, power saving, etc. Currently, several works are appearing in both academia and industry areas. Ranjan and Buja [21] describe a decentralized and distributed cloud federation based on the Aneka middleware that combines PaaS enterprise clouds, overlay networking, and structured peer-to-peer techniques to create scalable wide-area networking of compute nodes for highthroughput computing. Rochwerger et al [1] address the federation between several IaaS RESERVOIR-based clouds. An even more decentralized vision is offered in Cloud@Home [22], a PRIN Project founded by the Italian Ministry of Education facing the cloud federation problem from the point of view of the volunteer computing paradigm. Other initiatives aiming to develop virtual infrastructure management systems with features supporting the IaaS cloud federation are CLEVER [23] and OpenNebula [24] Regardless the reasons pushing clouds to establish a partnership with other clouds, one of the major issues affecting cloud federation is service relocation. Considering IaaS clouds, service relocation means to migrate a VM from a cloud virtualization infrastructure to another. In many cases, a cloud provider migrating a VM does not know the environment where the VM will be relocated and it does not have any warranty against illegal corruption of the destination infrastructure. This practice raises several issues due to technology compliance, performance and security. In this work, we specifically focus on a particular aspect of the security. During migration, several vulnerability have been picked out and different approaches have been proposed to enhance the security from both the point of view of the

hypervisor and the whole cloud [14], [25], [26], [27]. However, the cloud federation scenario is rather different from the traditional one including an independent cloud managing its own physical datacenter. In fact, in this latter case, the cloud provider has the full awareness of the hardware and software installed in each server of its datacenter. If the datacenter is protected from the external world by powerful and efficient firewall, the only threat can come from the inside. In this case a solution can be to enforce authorized employers with hard policies, frequently checking the integrity of the datacenter. How highlighted in the following Section, these policies cannot be applied to a federated cloud environment. V. R EMOTE ATTESTATION FOR VM M IGRATION IN F EDERATED C LOUD E NVIRONMENTS VM migration is a field of research which is becoming more and more popular especially with the advent of cloud computing and the federation perspective. In this Section, we specifically focus on a particular aspect of the security: how to guarantee a cloud provider migrating a VM that the destination cloud is not corrupted offering trusted software/hardware configurations. In order to address such a scenario, we propose an approach based on the remote attestation protocol. A. Security Concerns About Migrating/Migrated VMs In order to accomplish a secure VM migration, it is needed to assure the integrity of both the whole system installed within the VM and the physical hypervisor server hosting the VM itself. The VM system includes the guest OS and processes, instead the physical hypervisor server includes the OS and all the processes needed for the correct functioning of the virtualization system. Usually, the security of the OS and processes installed within the VM is responsibility of the user owner of the VM itself. A different discussion reserves how to guarantee the integrity of the physical hypervisor server which will host a migrated VM. In this case, the cloud provider which has migrated the VM and the owner of the VM (i.e., the cloud provider itself or a cloud clients) does not have any control over the hardware/software system where the VM has been relocated. Furthermore, the situation becomes more complicated if we consider the fact that cloud providers are reluctant to grant the full access/control of their system to third parties. In the following we discuss a typical situation which can take place in a federated cloud environment. Cloud provider A wants to migrate a VM into a cloud provider B, but cloud provider A is not aware of the hardware/software installed in the destination cloud B. In order to clarify this scenario, being as more generic as possible, in Figure 2, we represented cloud providers A and B, by means of a generic three-layer stack model [28] including a Virtual Machine Manager (VMM) layer, a Virtual Infrastructure Manager (VIM) layer, and a Cloud Manager (CM) layer. Let us suppose that the two clouds interact by means of such a mechanism: Cloud A needs to migrate a VM, hence it asks for a given hardware/software configuration in the destination server (e.g., kernel 2.6.21,

Fig. 2.

Concerns in a VM migration scenario.

hypervisor kvm-17, Gentoo Linux OS). Cloud B answers saying that it is able to provide a hosting service according to those features. This raises several security concerns in cloud A: • how can cloud A to be sure that cloud B really offers a hosting service with kernel 2.6.21, hypervisor kvm-17, Gentoo Linux OS? • proved that cloud B really offers an hosting service with the required configuration, how can cloud A be sure that in the future cloud B does not change the configuration of the server hosting the VM? • how can cloud A to be sure that the destination server in cloud B will not be corrupted by an attacks performed by third subjects against cloud provider B? These security concerns are very sensitive in the perspective of a future global market of federated cloud-based service and currently, the cloud federation adoption is slowed by the lack of powerful trusted mechanisms. In fact, providers need to give guarantees to other providers about their trustiness and reliability in order to improve their business, hence their profits. Apart from, the federation scenario, the aforementioned concerns are related also to traditional non-federated cloud providers offering hosting services. For example, the two major mega-providers offering VM hosting services, i.e. Amazon EC2 and Rackspace Cloud Servers, do not offer any guarantee to the end user about the integrity of the software/hardware platform where the VMs are hosted. The end-users have only to trust them on the basis of what they assert. This model is convenient and applicable for scenario including single end-user or small/medium society, but it is not suitable to the financial area. For this reason financial companies, like bank and assurance groups do not take cloud computing into great consideration despite of its obvious advantages and they are reluctant to migrate their systems in the cloud. B. RA for Enhancing Security of VM Migration The RA protocol, can be adopted to guarantee security before and after the VM migration. In this way the provider who migrates the VM can be sure that the hardware/software platform in the destination cloud is trusted. In the following, we discuss how to adapt the protocol to the scenario previously

Fig. 3.

Remote attestation protocol for VM migration.

introduced. Figure 3 depicts an example where IaaS cloud A wants to migrate a VM from Server 5, placed in its own datacenter, into server 10 of IaaS cloud B datacenter. Cloud A needs a target software/hardware configuration to migrate the VM and Cloud B has to prove that it is able to supply the hosting service according to the required conditions. In step 1. CM A sends a migration request to CM B specifying the required hardware/software configuration for the hosting. CM B accepts the request and starts the remote attestation procedure in order to prove that its system is trusted. Cloud B selects Server 10 from its datacenter and using its integrated TPM: • • •

•

creates the AIK asymmetric keys (public/private); creates the TPM Object; creates the “collate” identity request. Collate is a method which pulls out certificates and the AIK from the TPM and envelop them in a packet symmetrically codified with the session key. According to the TC terminology, this packet is called TPM IDENTITY REQ and its content is called “identity proof”; reads the EK certificate from the TPM non-volatile memory.

decrypts the symmetrically encrypted package using the session key; • retrieves the “identity prof”; • retrieves the AIK from the identity proof; • creates the certificate for the AIK; • creates the symmetrically encrypted package using session key and containing the AIK certificate; • creates an asymmetrically encrypted package using the Server 10’ s EK of Cloud B containing the session key. After that, in step 3b the PCA sends to CM B the symmetric and asymmetric packages. In step 4, Server 10 starts the activation procedure and retrieves the AIK certificate. In step 5a, CM B notifies the VM migration acceptation. In step 5b, CM A sends an obligation to certify the identity request to CM B, sending a NONCE (i.e. a random number) to prove that the procedure is up-to-date. In step 5c, Server 10: • calculates PCR “Quote”. It calculates the hash SHA-1 for the selected PCR index and sign it with the AIK. The Quote is a digitally signed report of PCR contents and is calculated picking up the values from the PCR’s registers applying the following formula: •

DIGEST = . . . + SHA − 1{SHA − 1{P CR[n]+

In step 2, CM B obtains a public key from the PCA. In step 3a CM B sends a collate identity request to the PCA which: • •

decrypts the asymmetrically encrypted package using PCA private key; retrieves the session key;

+P CR[n + 1]} + P CR[n + 2]} + . . . retrieves SML; retrieves AIK certificate. After that, CM B sends these data along with the NONCE to • •

CM A. In step 6, CM A obtains a PCA public key, and after that it: • verifies certificate signature for AIK certificate using PCA public key; • uses the AIK to verify the PCM “Quote” signature; • checks l’SML to verify that Cloud B runs authorized hardware/software in Server 10; • calculates the PCR value from SML entries; • compares the received PCR with PCR calculated from SML; • verifies the NONCE to check the answer freshness. In step 7, if all the previously steps are successfully executed, the VM will be migrated into server 10 of cloud B. In the future, CM A will be able to periodically check the integrity of the PCR of Server 10 where the VM has been migrated, comparing the PCR calculated from the SML with the current PCR received by means of the remote attestation protocol. If the two values match, cloud A can be sure that its VM is hosted in a trusted hardware/software system in cloud B. This means that no changes have been made on server 10 by cloud B or by hackers. VI. I MPLEMENTATION BASED ON IAIK API S

access to the TPM, since a TPM has limited resources and can only communicate with one client. The figure depicts two parts (highlighted with different boundary areas); in the top part there is the possibility to switch between the real TPM against the emulated. The implementation we made follows both approaches, emulated (software version) and real (hardware). In order to widely test the proposed scenario, we also integrated a TPM software emulator [29]. The emulated approach was introduced to extend the possibility to easily test more scenarios with many machines even without TPM hardware. The main stack of our implementation is totally transparent respect to the above mentioned approaches, that implies it can be used regardless the type of adopted TPM. In the emulated version the PCR is partially filled with fake data, as it is not possible to track the boot phases. We used the Linux version in which the TPM module is considered as a Device. The emulator is developed according to the TCG Device Driver Library (TDDL). In the bottom part of Figure 4 the software stack is presented. Here JTSS represents a Java version of TSS. The TCcert Tool is a software tool which allows to create special types of certificates. Finally the JCE (Java Cryptography Extension) is a set of APIs and implementations of cryptographic functionalities. It provides the security functionality of the default JDK, including message authentication codes, hash functions, asymmetric, symmetric, stream, etc. We also made up and customize our PCA with X509 certificates, thus for simplifying the work to be done and focusing on the design of the protocol. Part of PCA Java code is shown in the following. A. The Java code: details of some meaningful parts used in our implementation Hereby several parts of Java code, used in our implementation, are described. The following Java code creates a new object the TcIContext able to interact with the TPM module. The code shows how to open and close the connection. The overall interactions with the hardware and software TMP need to instantiate up a TcIContext(hContext).

Fig. 4. IAIK Java Software with TPM hardware and software adopted in our implementation.

The Institute for Applied Information Processing and Communication (IAIK) of the Graz University of Technology (AT), is developing many libraries and making Source Code for setting up a valuable security framework written in Java. We selected their code for developing and testing our Trusted Federated Clouds. Figure 4 depicts the libraries we used as the basis of our implementation. The TCG has defined a Software Stack to simplify the access from software modules to TPM. It is refereed with the acronym TSS. In particular TSS defines an Application Programming Interface to operating systems and applications, hence it is possible to use the functionality provided by a TPM. The main purpose of a TSS is to multiplex

/ / open t h e c o n n e c t i o n w i t h TPM T c I C o n t e x t h C o n t e x t = new T c T s s C o n t e x t F a c t o r y ( ) . newContextObject ( ) ; hContext . connect ( ) ; .......... / / c l o s e t h e c o n n e c t i o n w i t h TPM hContext . closeContext ( ) ;

In this part there is the setup for accomplishing the interaction between the Cloud TC-Attestant (in our case Cloud B, Server 10) and the PCA. This procedure happens between steps 3.4 and 3.b depicted in Figure 3. .... CloudBServer10PCR P c r = new CloudBServer10PCR ( h C o n t e x t ) ; C l o u d B S e r v e r 1 0 P C A C o n n e c t i o n con = new CloudBServer10PCAConnection ( ) ; b y t e [ ] PKblob = con . CAPubReq ( ) ; C l o u d I d e n t i t y i d e n t i t y = new C l o u d t I d e n t i t y ( h C o n t e x t ) ; O b j e c t [ ] r e t u r n e d = i d e n t i t y . R e q u e s t ( PKblob ) ; T c B l o b D a t a CIRB = ( T c B l o b D a t a ) r e t u r n e d [ 0 ] ; con . S e n d R e q u e s t ( CIRB ) ; / / h e r e t h e I d e n t i t y i s p r e p a r e d t o be s e n t t o PCA T c B l o b D a t a c r e d e n t i a l = i d e n t i t y . A c t i v a t e ( symPackage , asymPackage ) ; ...

The identity is sent to PCA guaranteeing the confidentiality of data: symPackage, asymPackage. The following Java code allows the interaction with TPM. In this case we obtain pubEKB, the public Endorsement Key from the TMP of Server 10: TcITpm hTpm = h C o n t e x t . g e t T p m O b j e c t ( ) ; TcIPolicy tpmPolicy = hContext . c r e a t e P o l i c y O b j e c t ( T c T s s C o n s t a n t s . TSS POLICY USAGE ) ; t p m P o l i c y . s e t S e c r e t (OWNER MODE, OWNER) ; t p m P o l i c y . a s s i g n T o O b j e c t ( hTpm ) ; TcIRsaKey pubEK = hTpm . getPubEndorsementKeyOwner ( ) ; pubEKB = pubEK . g e t A t t r i b D a t a ( T c T s s C o n s t a n t s . TSS TSPATTRIB KEY BLOB , TcTssConstants . TSS TSPATTRIB KEYBLOB PUBLIC KEY ) ; .......

Before using the Endorsement Key some policy and attributes need to be set. All IN/OUT data streamed to/from the TMP have to be encapsulated into a Blob file that is the TcBlobData. Hereby our PCA creates the CloudB Server 10 AIK certificate, after that it has received a new public key generated on TPM. ..... T c B l o b D a t a CIRB = T c B l o b D a t a . n e w B y t e A r r a y ( CIRBbyte ) ; / / decrypt pahse T c T p m I d e n t i t y P r o o f I d P r o o f = b u i l d . D e c r y p t ( CIRB ) ; build . Verify ( IdProof ) ; / / c r e a t e t h e CloudB S e r v e r 10 AIK c e r t i f i c a t e TcBlobData c r e d = b u i l d . A I K C e r t i f i c a t e ( I d P r o o f ) ; / / r e s p o n s e t o Cloud A encoded = b u i l d . Response ( IdProof , cred ) ; ......

VII. R ELATED W ORKS The combination of Trusted Computing and Cloud Computing has recently attracted a great deal of attention recently. Mohammed Achemlal et al. [30] have studied the possibility of using TCG specification to establish trust in Cloud Computing. They describe the architecture, the functions and the properties of TPM and analyze several approaches to adapt TPM in order to build trust in cloud computing. Berger et al [31] propose a virtual TPM (vTPM) architecture providing a protocol for secure vTPM migration between hardware platforms based on a strong association between a virtual TPMs, the hardware TPM of the platform and between a virtual TPM and its virtual machine. Virtual Machine migration is one of the most desirable virtualization features for Cloud Computing by facilitating fault tolerance, load balance and hardware maintenance. In [31] the vTPM instance migration is based on migratable TPM storage keys and it is enabled using asymmetric and symmetric keys to encrypt and package TPM state on the source virtual TPM and decrypt the state on the destination vTPM. F. Zhang et al. in [14] present a prototype system based on Xen and GNU Linux called PALM (Protection Aegis for Live Migration of VMs). This work presents a secure migration system able to preserve integrity and privacy protection during and after VM live migration for hypervisor. Garfinkel et al. in [32] have proposed a flexible architecture for trusted computing, called Terra, based on the trusted virtual

machine monitor and able to interface with underlying trusted hardware. Their goal is providing strong isolation between applications running in different hypervisors. Terra partitioned a tamper-resistant hardware platform into multiple, isolated virtual machines. Their architecture allows applications to run in a open box VM with the semantics of a modern open platform, or in a closed box VM that provide the functionality of running on a dedicated closed platform. Z. Shen and Q. Tong in [11] propose a method to build a trusted computing environment for cloud computing by integrating the trusted computing platform into cloud computing system. The authors transfer the security features (authentication, confidentiality and integrity) of a Trusted Computing Platform with trusted platform module to a Cloud Computing System. Their main goal is to provide to a Cloud Computing system some important security functions: authentication, communication security and data protection. W. Han-zhang and H. Liu-sheng in [33] propose a trusted cloud computing platform model based on the Direct Anonymous Attestation scheme and Privacy CA scheme. The authors in [33] describe a detailed design including a virtual machine management and an informal security analysis. VIII. C ONCLUSIONS AND R EMARKS In this work we applied TC adapting the RA protocol to assure security in VM migration in a federated cloud environmet. Many IT experts foresee a consistent market in cloud computing, and the biggest cloud operators might be not able to satisfy the end-users requests. A possible solution is to accomplish dynamic cooperation among operators. This raises a lot of security concerns. The main result of our work is to propose a way for encouraging the federation among cloud operators at IaaS level, promoting new emerging security approaches. In this work we applied the RA protocol in a different way than usual, developing several security modules, in order to improve the security in a scenario of VM migration where cloud migrating VMs can be sure that the destination system will be trusted. Thanks to the easy configuration procedure and due to the wide distribution of TPM modules inside hardware platforms, it might represent a valid low-cost solution for a large number of cloud operators. R EFERENCES [1] B. Rochwerger, D. Breitgand, A. Epstein, D. Hadas, I. Loy, K. Nagin, J. Tordsson, C. Ragusa, M. Villari, S. Clayman, E. Levy, A. Maraschini, P. Massonet, H. Munoz, and G. Toffetti, “Reservoir - when one cloud is not enough,” Computer, vol. 44, pp. 44–51, 2011. [2] A. Celesti, F. Tusa, M. Villari, and A. Puliafito, “How to enhance cloud architectures to enable cross-federation,” in Proceedings of IEEE CLOUD ’10, pp. 337–345, IEEE, July 2010. [3] April 2011. IEEE works towards cloud interoperability standards: http://www.cloudcomputingzone.com/2011/04/ieee-works-towardscloud-interoperability-standards/. [4] 2011. ETSI-Standards in the Cloud: a transatlantic mindshare, http://www.etsi.org/WebSite/NewsandEvents/2011 09 STANDARDSINTHECLOUD.aspx. [5] 2011. Free Software Free Society: Selected Essays of Richard M. Stallman, 2nd Edition, http://www.gnu.org/philosophy/can-you-trust.html.

[6] W. Goh, P. C. Leong, and C. K. Yeo, “A trusted platform module based anti-forensics system,” in Network and Service Security, 2009. N2S ’09. International Conference on, pp. 1 –5, june 2009. [7] N. Paul and A. Tanenbaum, “The design of a trustworthy voting system,” in Computer Security Applications Conference, 2009. ACSAC ’09. Annual, pp. 507 –517, dec. 2009. [8] M. Alzomai and A. Jandsang, “The mobile phone as a multi otp device using trusted computing,” in Network and System Security (NSS), 2010 4th International Conference on, pp. 75 –82, sept. 2010. [9] T. Winkler and B. Rinner, “Trustcam: Security and privacy-protection for an embedded smart camera based on trusted computing,” in Advanced Video and Signal Based Surveillance (AVSS), 2010 Seventh IEEE International Conference on, pp. 593 –600, 29 2010-sept. 1 2010. [10] 2011. Trusted Computing Engineering for Resource Constrained Embedded Systems Applications (TERESA),http://www.teresa-project.org/. [11] Z. Shen and Q. Tong, “The security of cloud computing system enabled by trusted computing technology,” in Signal Processing Systems (ICSPS), 2010 2nd International Conference on, vol. 2, pp. V2–11 –V2– 15, july 2010. [12] Z. Shen, L. Li, F. Yan, and X. Wu, “Cloud computing system based on trusted computing platform,” in Intelligent Computation Technology and Automation (ICICTA), 2010 International Conference on, vol. 1, pp. 942 –945, may 2010. [13] X.-Y. Li, L.-T. Zhou, Y. Shi, and Y. Guo, “A trusted computing environment model in cloud architecture,” in Machine Learning and Cybernetics (ICMLC), 2010 International Conference on, vol. 6, pp. 2843 –2848, july 2010. [14] F. Zhang, Y. Huang, H. Wang, H. Chen, and B. Zang, “Palm: Security preserving vm live migration for systems with vmm-enforced protection,” in Trusted Infrastructure Technologies Conference, 2008. APTC ’08. Third Asia-Pacific, pp. 9 –18, oct. 2008. [15] M. Achemlal, S. Gharout, and C. Gaber, “Trusted platform module as an enabler for security in cloud computing,” in Network and Information Systems Security (SAR-SSI), 2011 Conference on, pp. 1 –6, may 2011. [16] Z. Qiang, C. Dong, W. Yunlong, and D. Zhuang, “The out-of-band virtualization model of network storage based on trusted computing,” in Natural Computation (ICNC), 2010 Sixth International Conference on, vol. 8, pp. 4354 –4357, aug. 2010. [17] Z. Qiang, W. Yunlong, C. Dong, and D. Zhuang, “Research on the security of storage virtualization based on trusted computing,” in Networking and Digital Society (ICNDS), 2010 2nd International Conference on, vol. 2, pp. 237 –240, may 2010. [18] B. Jiang, “Trusted computing based on virtualization,” in Internet Technology and Applications, 2010 International Conference on, pp. 1 –4, aug. 2010. [19] M. Schramm and A. Grzemba, “The benefits of combining trusted computing with virtualization techniques,” in Applied Electronics (AE), 2010 International Conference on, pp. 1 –4, sept. 2010. [20] Trusted Computing Group (TCG): http://www.trustedcomputinggroup.org/. [21] R. Ranjan and R. Buyya, “Decentralized overlay for federation of enterprise clouds,” in Handbook of Research on Scalable Computing Technologies, 2009. [22] V. Cunsolo, S. Distefano, A. Puliafito, and M. Scarpa, “Applying software engineering principles for designing cloud@home,” in CCGRID, pp. 618–624, 2010. [23] F. Tusa, A. Celesti, M. Paone, M. Villari, and A. Puliafito, “How cleverbased clouds conceive horizontal and vertical federations,” in ISCC, pp. 167–172, 2011. [24] D. S. Milojicic, I. M. Llorente, and R. S. Montero, “Opennebula: A cloud management tool,” IEEE Internet Computing, vol. 15, no. 2, pp. 11–14, 2011. [25] C. Xianqin, W. Han, W. Sumei, and L. Xiang, “Seamless virtual machine live migration on network security enhanced hypervisor,” in ICBNMT ’09. 2nd IEEE International Conference on Broadband Network Multimedia Technology, pp. 847 –853, oct. 2009. [26] L. YamunaDevi, P. Aruna, D. Sudha Devi, and N. Priya, “Security in virtual machine live migration for kvm,” in International Conference on Process Automation, Control and Computing (PACC), pp. 1 –6, july 2011. [27] W. Wang, Y. Zhang, B. Lin, X. Wu, and K. Miao, “Secured and reliable vm migration in personal cloud,” in 2nd International Conference on

[28] [29] [30] [31]

[32] [33]

Computer Engineering and Technology (ICCET), vol. 1, pp. V1–705 –V1–709, april 2010. B. Sotomayor, R. S. Montero, I. M. Llorente, and I. Foster, “Virtual infrastructure management in private and hybrid clouds,” IEEE Internet Computing, vol. 13, pp. 14–22, 2009. 2011. Software-based TPM Emulator, http://tpm-emulator.berlios.de/. M. Achemlal, S. Gharout, and C. Gaber, “Trusted platform module as an enabler for security in cloud computing,” in Network and Information Systems Security Conference, pp. 1 –6, 2011. S. Berger, R. Caceres, K. A. Goldman, R. Perez, R. Sailer, and L. van Doorn, “vtpm: virtualizing the trusted platform module,” in Proceedings of the 15th conference on USENIX Security Symposium, vol. 15, pp. 1 –6, 2006. T. Garfinkel, B. Pfaff, J. Chow, M. Rosenblum, and D. Boneh, “Terra: a virtual machine-based platform for trusted computing,” in Proceedings of SOSP, pp. 193–206, 2003. W. Han-zhang and H. Liu-sheng, “An improved trusted cloud computing platform model based on daa and privacy ca scheme,” in International Conference on Computer Application and System Modeling (ICCASM), pp. V13–33 – V13–39, 2010.