SECURELY LAUNCHING VIRTUAL MACHINES

ON TRUSTWORTHY PLATFORMS IN A PUBLIC CLOUD

An Enterprise’s Perspective

Mudassar Aslam

, Christian Gehrmann

, Lars Rasmusson

and Mats Bj

orkman

Swedish Institute of Computer Science, Isafjordsgatan 22, Box 1263, SE-164 29 Kista, Sweden

alardalens H

ogskola, Box 883, SE-721 23 V

aster

as, Sweden

Keywords:

Security, Trusted Computing, Virtualization, Cloud Computing, IaaS.

Abstract:

In this paper we consider the Infrastructure-as-a-Service (IaaS) cloud model which allows cloud users to run

their own virtual machines (VMs) on available cloud computing resources. IaaS gives enterprises the possi-

bility to outsource their process workloads with minimal effort and expense. However, one major problem

with existing approaches of cloud leasing, is that the users can only get contractual guarantees regarding the

integrity of the offered platforms. The fact that the IaaS user himself or herself cannot verify the provider-

promised cloud platform integrity, is a security risk which threatens to prevent the IaaS business in general.

In this paper we address this issue and propose a novel secure VM launch protocol using Trusted Computing

techniques. This protocol allows the cloud IaaS users to securely bind the VM to a trusted computer conﬁgura-

tion such that the clear text VM only will run on a platform that has been booted into a trustworthy state. This

capability builds user conﬁdence and can serve as an important enabler for creating trust in public clouds. We

evaluate the feasibility of our proposed protocol via a full scale system implementation and perform a system

security analysis.

1 INTRODUCTION

In recent years, there has been a tendency to migrate

IT services like email, storage, and other applications

into the clouds due to cost and maintenance beneﬁts.

Several different cloud sourcing models exist. In this

paper we focus on the cloud model where the cloud

consumer is able to deploy full software systems (in-

cluding the operating system) on a shared common

infrastructure, or what is often referred to as the

Infrastructure-as-a-Service (IaaS) cloud model (Krutz

and Vines, 2010). This paper presents a novel tech-

nique for the secure launch of virtual machines in a

public cloud.

A small company without security skills or an or-

dinary IT service consumer might trust a public cloud

service provider and in some cases prefer cloud ser-

vices over self-hosted services with a belief that his or

her cloud provider can offer better security by recruit-

ing specialized staff and equipment. In contrast, most

large or medium size enterprises have higher security

requirements for their own or their business users sen-

sitive data; and if their data is compromised due to a

security breach in the cloud provider network, it will

results in serious legal and business setbacks. There-

fore, these enterprises are reluctant to host their ser-

vices in a public cloud unless they get trusted ways to

validate the contractual security guarantees provided

by the cloud provider.

The focus of our work is to introduce technical

ways to verify the security guarantees provided by the

cloud service provider. We achieve this by allowing

the cloud user to cryptographically bind the user vir-

tual machine (VM) to a trustworthy state of the provi-

sioned cloud platform. Furthermore, we ensure that

the whole launch process meets all expected major

security requirements of a high quality public service

with respect to authentication and secure transfer. Ac-

cording to our suggested VM launch protocol, a par-

ticular VM is not even sent to the provider network

if no platform with the expected security guarantees

can be offered by the IaaS cloud. Our proposed pro-

tocol uses a unique combination of state-of-the art

techniques for authentication, and remote attestation

together with TPM’s

sealing and a compact single

transfer protected VM launch command. The main

Trusted platform module.

511

Aslam M., Gehrmann C., Rasmusson L. and Björkman M..

SECURELY LAUNCHING VIRTUAL MACHINES ON TRUSTWORTHY PLATFORMS IN A PUBLIC CLOUD - An Enterprise’s Perspective.

DOI: 10.5220/0003928105110521

In Proceedings of the 2nd International Conference on Cloud Computing and Services Science (CLOSER-2012), pages 511-521

ISBN: 978-989-8565-05-1

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

contributions of this paper are the following:

• We design and propose a secure VM launch pro-

tocol for the clouds which enables veriﬁable trust

between the cloud user and provider.

• We implement the proposed protocol to evalu-

ate the feasibility of using TCG

mechanisms in

terms of implementation effort and complexity.

• We perform a security analysis of the proposed

protocol and show how expected security require-

ments are fulﬁlled.

The paper is organized as follows. In Section 2

we present the scenario we are addressing and rele-

vant security threats. In Section 3 we cover the ex-

isting body of literature in the area. In Section 4, we

describe the underlying architecture of the resource

platform which provides necessary foundation to de-

sign a trusted platform. We present out launch pro-

tocol in Section 5 followed by its implementation in

Section 6. Finally, we present a security analysis of

the proposed launch protocol in Section 7 and con-

clude in Section 8.

2 SCENARIO AND THREATS

2.1 Scenario

We are considering the IaaS cloud model from an en-

terprise’s perspective which is depicted in Figure 1.

There are two main stakeholders - the cloud Provider

and the cloud User. The provider can be the re-

source/platform manufacturer or a third party cloud

provider who provisions bare virtual machines to the

users through a Procurement Server. The users can

install any software stack, including OS on the pro-

cured VM. We consider an enterprise cloud user that

wants to outsource its business processes to the cloud

without compromising the security of its data and ap-

plications. In this paper, we consider secure VM man-

agement for this scenario and in particular the initial

process when the user wants to launch a VM on the

offered provider infrastructure. We analyze this VM

launch phase from a security perspective and suggest

protocols and principles for protecting it. This cov-

ers one phase of the VM life-cycle. Other important

phases are VM management once the VM has been

launched on the target platform and VM migration

from one cloud platform to another in order to allow

efﬁcient resource management. These later phases are

out of scope of the current paper and subject to future

Trusted computing group, http://www.trustedcomputin

ggroup.org/.

Cloud Provider

Provider Client

(PC)

User A

User Client (UC)

User B

User Client (UC)

Cloud

Cloud Platform

Hypervisor/VMM

Hardware

User A

TPM

Management

User B

Cloud Platform

Hypervisor/VMM

Hardware

User B

User A

TPM

Management

Procurement Server

Gateway

Provider Ref. Manifest Auth (PRA)

Figure 1: System overview.

work.

2.2 Threats

As we have previously discussed, migration from tra-

ditional business models to a cloud-based model has

business beneﬁts such as cost savings etc. However,

this comes together with new security threats that

prevent capitalizing the cloud advantages for many

enterprises (CircleID, 2009). These threats have been

identiﬁed by the research community (Aslam and

Gehrmann, 2011), (Vaquero et al., 2011) and the

alliance for cloud security (Threats, 2010). Below,

we shortlist the major threats relevant to virtual

machine launch in a public cloud.

1. Insecure Interfaces: Insecure interfaces and APIs

to cloud services could result in various security

issues related to conﬁdentiality, integrity, availability

and accountability. This means that the risk of

security breach exists right from the beginning, that

is, when the cloud user launches a VM. This risk

remains even after the launch due to the insecure

management interfaces (Threats, 2010).

2. User-client Authenticity: The attacker tries to

impersonate a legitimate user-client.

3. Provider Network Attacks: Internal (inside the

provider network) and external network attacks in the

cloud, e.g. DoS attack.

4. Disowning Malicious VM: The cloud user

repudiates the launch of a VM instance, for example

to deny the ownership of a misbehaving or malicious

VM.

5. Cloud Platform Authenticity: The attacker tries

to impersonate a cloud platform.

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

512

6. Insider Attacks: A rogue employee with admin-

istrative access within a cloud provider network can

install malicious code/software on the cloud platform

that can then easily leak user’s (i.e. enterprise)

conﬁdential data.

7. Mis-conﬁgured Cloud Platform: There is a risk

that the provider unintentionally installs a hostile

software package on the cloud platform or the cloud

node is not compliant to the promised security

proﬁle, that is, the cloud platform is not updated

with the latest security patches. These risks expose

the platform and hence the cloud users to known

vulnerabilities which could expose the platform for

possible attacks.

8. User-data Leak: The cloud provider tries to run

a user VM instance using received VM image on an

in-secure platform. The user starts using such a po-

tentially in-secure VM and risks of losing conﬁdential

data.

The ﬁrst four threats mentioned above are general

and well known for any distributed system while the

last four are more cloud-speciﬁc for which we pro-

pose mechanisms and solutions. The goal with the

overall security architecture (Section 4) and our se-

cure launch protocol (Section 5) is to address all these

listed threats. We revisit the threats list in the security

analysis in Section 7 and discuss if/how the threats

have been mitigated in our design.

3 RELATED WORK

The importance of security for clouds has been iden-

tiﬁed very early by the concerned stakeholders, and

the research community has responded by identi-

fying security threats and proposing many differ-

ent kinds of solutions. Consortia like Cloud Se-

curity Alliance

, Trusted Computing Group

and

other industrial-academic research alliances such as

TClouds

and EuroCloud

have already taken ini-

tiatives to address and solve security issues in the

clouds. As we have discussed in Section 2.2, several

reports and papers have been published that analyze

cloud security threats (CSA Guide, 2009), (Threats,

2010), (Aslam and Gehrmann, 2011) and (Vaquero

et al., 2011).

The TCG initiative for practical deployment of

trusted clouds (TMI, 2010) aims at proposing spec-

iﬁcations and reference models. The TMI working

http://www.cloudsecurityalliance.org

http://www.trustedcomputinggroup.org/

http://www.tclouds-project.eu/

http://www.eurocloud.org/

group, at its infancy, has only released a short white

paper so far (Cloud Computing and Security, 2010)

which identiﬁes the areas where TCG mechanisms

can provide security and trust in the clouds. While

details about how are still unavailable publically, we

have used the basic TCG mechanisms of secure boot,

remote attestation and sealing capabilities to propose

a mechanism that enables security and trust in the

clouds. There also exist some industrial proprietary

solutions like the Intel



TXT (Intel Trusted Execu-

tion Technology) which uses TCG and proprietary

hardware extensions to set up trustworthy cloud plat-

forms. The acTvSM Platform (acTvSM, 2010) is one

such prototype implementation. Our solution can be

built upon any such platform and additionally gives

the ability to the cloud user to verify the trustworthi-

ness of the platform before using the cloud.

There are other proposed solutions to implement

remote attestation as deﬁned by the TCG. (Huang and

Peng, 2009) and (Sailer et al., 2004) use TPM based

cryptographic attestations by sending Integrity Mea-

surement Log (IML) in combination with TPM Quote

which is securely computed by the Trusted Platform

Module (TPM Commands, 2007). The veriﬁer com-

pares the quoted response with a self-computed hash

value from the IML to check and decide about the

integrity of the target platform. (Landfermann et al.,

2006) propose an alternate scheme for remote attes-

tation by introducing property-based attestations in-

stead of cryptographic attestations to make it a scal-

able solution. (Haldar et al., 2004) also propose a sim-

ilar remote attestation technique to fulﬁll platform in-

tegrity requirements. All these papers mainly discuss

remote attestation techniques which could be used in

performing the integrity veriﬁcation step of our pro-

posed protocol.

The architecture introduced by (Jansen et al.,

2006) presents ways to protect the conﬁdentiality of

the user VM by leveraging on the sealing mechanism

supported by TPM. We enforce sealing of the user

VM to a platform state in a slightly different way.

Our approach allows a remote user to seal the user

VM to the target platform by encrypting his/her VM

using a special purpose TPM-based bind key, which

can only be used for decryption if the target platform

is in a known good state. The user can also validate

the required sealing properties (i.e. attested platform

state, non-migratable TPM key) through our proposed

approach of certifying the bind key. Finally, (Gasmi

et al., 2007) propose a trusted channel which focuses

on the integrity of the target platform in establish-

ing a secure session. The trusted channels also fea-

tures trusted computing mechanisms for establishing

trust between end entities. Different from such an on-

SECURELYLAUNCHINGVIRTUALMACHINESONTRUSTWORTHYPLATFORMSINAPUBLICCLOUD-An

Enterprise'sPerspective

513

line solution, we propose a VM launch procedure that

does not require that the VM is scheduled when actu-

ally transferred to the IaaS provider from the user, but

it can be stored protected until it is actually scheduled

on the target platform.

4 CLOUD PLATFORM SECURITY

ARCHITECTURE

Naturally, the most important component in creating

trust in an IaaS model, is the design of the shared re-

sources, i.e. the cloud platform. The cloud platform

must be both ﬂexible enough to allow multiple users

to run their services, and at the same time it should

be easy to manage and have the needed security com-

ponents to prove to the user that it is trustworthy and

can protect the user data in a good way. Below, we

discuss the platform security architecture we assume

and that we partly

have designed. Key parts of this

architecture have been veriﬁed in an implementation

which is discussed in Section 6.

4.1 Cloud Platform Architecture

In order to allow multiple users to run their services

on a shared cloud platform, we consider the XEN

hypervisor (Chisnall, 2007) for platform virtualiza-

tion. However, the platform architecture is ﬂexible to

use other hypervisors like KVM

or VMware

with

some adaptations. The platform runs a Management

Virtual Machine in the privileged domain i.e. dom0

along with other less privileged user domains (domU)

running User Virtual Machines belonging to different

cloud users (see Figure 2). The architecture divides

the platform into four layers of abstraction where

the Services Layer presents our implemented modules

(see Section 6) which are fundamental in the trusted

VM launch.

The management VM runs our implemented Man-

agement Agent at Application Layer which interacts

with other entities of the network (internal and ex-

ternal) and performs services for them. The Services

Layer has four major components which interact with

each other and perform all security and trust manage-

ment operations. The Compartment Manager (CM)

performs the leading role by using services of other

components. Other than the management of overall

VM life-cycle, the main tasks performed by the CM

We use a combination of state-of-the-art technologies

and new designs.

http://www.linux-kvm.org/

http://www.vmware.com/virtualization/

are unsealing and running/launching user VMs. The

CM uses the services of the Integrity Manager (IM)

which performs various tasks pertaining to platform

trust establishment. It uses TPM features and per-

forms tasks like making runtime integrity measure-

ments and reporting platform state for remote attes-

tation. In principle, the CM calls IM functions for

validating trust before launching a user VM. The Cre-

dential Manager (CredM) keeps the credentials of the

licensed users to make access checks of VMs prior to

launch, logs launch events and transfers licensing in-

formation to the licensing engine. The Policy Man-

ager (PM) handles platform security policies for the

cloud platforms, for example, a platform access pol-

icy which allows/disallows particular operations on

the platform according to the client (user or provider)

access rights. Furthermore, PM can be used to en-

force licensing policies for different softwares and/or

resource usage.

The underlying Virtualization Layer makes virtual

instances of hardware resources so that every user

VM can have its own virtual hardware. However,

the architecture design choice for the hardware TPM

to virtualize it or not depends upon its intended use.

Virtualizing TPM instances as proposed by (Berger

et al., 2006) allows every user VM to use the fea-

tures offered by TPM (e.g. platform attestation, in-

tegrity reporting etc.). Though virtual TPMs allow

the cloud users to beneﬁt from the security features

offered by TPM, it results in increased size of Trusted

Computing Base (TCB) which can expose security

vulnerabilities due to hierarchical trust dependen-

cies (Van Doorn, 2007). Therefore, we consider not

to virtualize the TPM and limit its use to the hypervi-

sor and Management VM which sufﬁce the user re-

quirement of validating target cloud platform prior

to his/her VM launch. Similar models are proposed

by (Haldar et al., 2004) and (Jansen et al., 2006)

where the TCB is only up until the level of the hy-

pervisor.

4.2 Platform Credentials

In the process of platform integrity veriﬁcation (see

Section 5.2), the cloud platform is required to report

runtime measurements to the verifying user-client.

The reported values can only be trusted if they are

signed by the TPM. The cloud platform should there-

fore have an asymmetric key pair for attestation, a so

called Attestation Identity key pair, K

AIK

. The secret

part of this key (SK

AIK

) can ONLY be used inside the

TPM chip and never leaves the TPM unencrypted.

The corresponding public part, PK

AIK

is registered

with a trusted third party usually called Privacy CA

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

514

Component forming the TCB

Management VM

Integrity

Manager

Compartment

Manager

Policy

Manager

Operator Credential

Manager

Management Agent

Native Device Driver

Back-end

Driver

CRTMMMU

Memory

CPU TPM

Devices

vMemory

Event Channel

vDevices

vCPU

vMMU

Operator A

App S/W

Front-end

Driver

Operator OS

Operator C

App S/W

Front-end

Driver

Operator OS

Operator B

App S/W

Front-end

Driver

Operator OS

Application Layer

Services Layer

H/W Layer

Virtualization Layer

Figure 2: Cloud platform architecture.

who issues an identity certiﬁcate for the platform, a so

called AIK-Certiﬁcate according to the TCG attesta-

tion key and certiﬁcate principles (TCG Architecture

Overview, 2007).

Our proposed VM launch protocol (see section

5) also supports the conﬁdentiality of user data and

programs/applications - a security requirement iden-

tiﬁed in (Aslam and Gehrmann, 2011). This can be

achieved by cryptographically binding the user VM

to a cloud platform which is booted into a trustwor-

thy state. We create a non-migratable (TPM 1.1) or

certiﬁed-migratable (TPM 1.2) asymmetric key pair

in the TPM which is used for such cryptographic

binding. We refer to this key as bind key and denote

it by K

bind

. The public part of this key is denoted by

bind

, and the corresponding private part by SK

bind

We create this key pair using the TPM CreateKey()

command (TPM Commands, 2007), and also state

the required value of Platform Conﬁguration Regis-

ters (PCRs) to use this key. A TPM key created in

this way can only be used for decryption if the cloud

platform is booted into a trustworthy state. In order

to prove to a remote user that K

bind

is a TPM key and

is bounded to a trustworthy platform state, it is signed

together with the deﬁned PCRs using SK

AIK

though

the TPM

CertifyKey() command (TPM Commands,

2007) (see Section 6).

4.3 Platform Secure Boot

We assume trusted boot (IMM, 2006), (Sailer et al.,

2004) for our cloud platform bootstrapping in which

the hash of every loaded code component is recorded

in the TPM PCRs by the TPM extend operation. In

order to make the hash values in the PCRs meaning-

ful, a corresponding Event Structure which contains

the component’s meta-data as well, is also recorded

in a so called Integrity Measurement Log (IML) ﬁle.

The values in the TPM PCRs along with IML are se-

curely reported to the user as runtime measurements

in the platform integrity veriﬁcation (see Section 5.2).

5 SECURE VM LAUNCH

PROTOCOL

The cloud platform security architecture presented in

the previous sections and the performed pre requisites

provide a basis for implementing the TCG mecha-

nisms like remote attestation, sealing and key bind-

ing. We use these features of the TCG to design and

implement a secure VM launch protocol. The VM

launch process is divided into three main and distinct

phases which are shown in Fig. 3 and described in the

following sections.

5.1 Connect and Discovery

In order to protect the internal virtual resources, the

provider needs to authenticate all resource requests

towards the network through the provider gateway,

which authenticates the user-client and establishes a

secure session with the user-client. Similarly, the

user-client must make sure that it connects to a trusted

cloud provider network. We use IPsec (Frankel and

Krishnan, 2011) to establish a standard VPN session

between the user-client and the provider network. We

use certiﬁcate-based key exchange for the session es-

tablishment for which both entities are assumed to

have their digital certiﬁcates issued by a mutually

trusted CA.

After the establishment of the IPsec connection,

the user-client sends a resource discovery request to

the Procurement Server which pools a list of avail-

able resources and presents them to the user-client.

The user-client selects one of the presented resources

which matches his criteria (feature-set, security, pol-

icy, resource location etc.). The user-client then goes

through the billing and payment cycle which is not

part of our protocol and is not covered here. Once

the payment is done, the user-client gets a resource

deﬁnition ﬁle which is a provider-signed XML ﬁle

containing all important information about the pro-

cured resource. This includes 1) the URI of the re-

source which is used to connect to the resource, 2)

a link to access reference measurements of the pro-

cured platform which are used in the platform in-

tegrity veriﬁcation to be performed in the next step,

3) links to platform usage policies which are enforced

on the platform, e.g. licensing, 4) a list of clients (user

or provider) who can access this platform along with

their access rights, and 5) links to any other Service

Level Agreements (SLAs). The externally linked ﬁles

SECURELYLAUNCHINGVIRTUALMACHINESONTRUSTWORTHYPLATFORMSINAPUBLICCLOUD-An

Enterprise'sPerspective

515

are integrity protected by including their checksums

in the provider signed resource.xml ﬁle. This resource

deﬁnition ﬁle is important in the sense that it presents

the provider statement about the integrity state of the

procured platform. The novelty of our solution lies

in that the user can validate the proclaimed integrity

of the provisioned resource. This validation is per-

formed in the next step of the VM launch protocol.

5.2 Platform Integrity-veriﬁcation

Before launching the VM to the procured platform,

the user-client needs to validate the integrity of the

target platform as proclaimed by the provider. This

is done according to the TCG attestation procedure

(TCG Architecture Overview, 2007). We use an attes-

tation protocol similar to the one described in (Huang

and Peng, 2009) and (Sailer et al., 2004). The attesta-

tion starts with the user-client sending a nonce (N) to

the cloud platform with a request to report its integrity

state. The Management Agent requests the Integrity

Manager to generate an Attestation Response. The at-

testation response contains the current state of PCRs

and the Integrity Report. The IM requests the TPM to

get the current state of PCRs signed with SK

AIK

(see

Section 4.2). This is done using the TPM Quote (TPM

Commands, 2007) command. The Integrity Report,

current PCR state and the AIK-Certiﬁcate are sent

back to the user-client. The user-client validates the

AIK-Certiﬁcate, nonce and the signatures and com-

pares the received Integrity Report with the Reference

Manifests (RM) collected from Provider Reference

Manifest Authority (PRA) using the link provided in

resource deﬁnition XML ﬁle in the previous step (see

Figure 1). The role of PRA is to create/aggregate,

sign and publish reference metrics for each cloud plat-

form (IMM, 2006). Once the validations are success-

ful, the user-client then computes the hash (h1) of the

received Attestation Response which is used to bind

the next VM launch step to the current integrity veri-

ﬁcation step of the launch protocol.

5.3 VM Launch

The ﬁnal stage of the proposed protocol is the actual

launch of the user VM. We protect user data and ap-

plications (user programs) by cryptographically bind-

ing them to the cloud platform using the TPM. Such

binding mechanism fulﬁlls an important security re-

quirements, that is, the user data is available only if

the cloud platform is running trusted software compo-

nents thus protecting data conﬁdentiality against mal-

ware. The platform-sealed launch introduced here is

done by using a specially created non-migratable or

certiﬁed-migratable, asymmetric key (K

bind

) which is

created in the pre-launch phase (see Section 4.2). The

user-client requests for the PK

bind

along with assur-

ances that the K

bind

is a non-migratable or certiﬁed-

migratable TPM key, and it can only be released/used

if the cloud platform is in the trusted state as attested

in the previous step. The cloud platform loads K

bind

User Client (UC)

Public Cloud

Cloud

Platform

IPsec Security Association

(IKE, Mutual Authentication)

Resource Response

: resource

.xml

Validate(Cert

AIK

, Sign

AIK

, N)

Validate(Integrity Report)

Compute h1 = hash(Attestation Response)

Closed Network

Public Network

Secure Channel Established

Attestation Request: N

Attestation Response

: Sign

AIK

{

PCR

Cert

AIK

Key Request

Key Response

bind

TPM

CERTIFY

INFO

Sign

AIK

{

TPM

CERTIFY

INFO

}

Cert

Sign

{

Enc

(

VM Image

Policy

UserSW

)

Enc

bind

(

)

}

Validate(Sign

AIK

)

Validate(TMP_CERTIFY_INFO2)

Generate K

Compute h2 = hash(Key Response)

Compute h

= hash (h1 + h2)

Management

Agent

TCB

CredM: Validate(Cert

, Sign

)

IM: Validate(h)

PM: Validate User License

IM: Unseal(K

bind

)

IM: Dec_SK

bind

)

IM: Dec_K

(VM

OVF

)

CM: Launch(VM Instance)

CredM: Get(PK

bind

)

IM: Get Seal State Info

IM: Sign

AIK

(PCR, N)

CM: Request(IML)

IM: Generate Integrity Report (IR)

CredM: Cert

AIK

IM = Integrity Manager, CM = Compartment Manager, PM = Policy Manager, CredM = Credential Manager

Resource Discovery

Resource Connect: resource.xml

Launch

Success

Resource Discovery

Platform Integrity-

Verification

VM Launch

Procurement Server

Gateway

Figure 3: VM launch protocol.

and calls TPM CertifyKey() command (TPM Com-

mands, 2007). The validation result of this com-

mand includes a TPM CERTIFY INFO structure which

is sent to the user-client along with K

bind

. The

TPM

CERTIFY INFO structure is K

AIK

signed which

certiﬁes that K

bind

is a non-migratable TPM key.

The TPM CERTIFY INFO structure includes the digest

for K

bind

which is compared against the computed

digest of the received K

bind

to authenticate the re-

ceived K

bind

. The TPM CERTIFY INFO structure also

includes the required PCR INFO digest which is com-

pared against the expected/trusted PCR hash value to

ensure that K

bind

can only be used when the platform

is in a trusted state.

After all validations, the user-client generates a

symmetric key K

V M

which is used to encrypt the VM

package

which contains the VM image, any user

credentials and user applications which will run in

The VM is packaged using Open Virtualization Format

(OVF).

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

516

the user VM instance. The K

V M

is encrypted with

bind

to ensure the required platform-binding prop-

erties stated earlier. In order to cryptographically

bind the different protocol steps - attestation, bind

key exchange and launch - the user-client computes

the hash of Key Response message(h2), appends it

to h1(computed in previous stage), and computes h

which is also sent to the cloud platform. Finally, the

user-client signs the VM Launch command (shown

below) so that the user cannot repudiate the VM

launch later on.

Cert

, Sign

V M

{V M

OV F

}, PK

bind

V M

}, h]

The cloud platform performs the necessary valida-

tions and checks the user license for VM launch

rights, and (optionally) also updates the correspond-

ing charging records. It then loads the bind key, de-

crypts the K

V M

, decrypts the VM package and asks

the Compartment Manager to run the user VM in-

stance. Finally, a SUCCESS or FAIL launch message

is returned to the user-client. After successful VM

launch the user-client can then connect to the running

VM instance for any management operation.

6 IMPLEMENTATION

The Secure VM Launch Protocol, as presented in the

previous section, requires multiple entities/platforms

communicating with each other in a complete IaaS

provisioning system (see Figure. 1). In order to setup

a complete framework and test a running prototype

of the launch protocol, we implemented the required

functionalities for the following entities:

• User-provider client.

• Procurement server.

• Cloud platform: management agent.

In the following sections, we discuss the implementa-

tion of these different entities in more details.

6.1 User-provider Client

The cloud user needs a client for resource pro-

curement, VM launch and its later management

Similarly, the provider also needs a client for the

management and administrative tasks on the provi-

sioned cloud platform. In our prototype, we have

implemented a single client that can run in two

operational modes, i.e. launch and manage, and

thus can be used by the user or provider. In this

paper, we only focus on the cloud user using the

VM management is not covered in this paper.

client program in the launch mode. This is done by

specifying the ’launch’ argument along with a ’user

certiﬁcate’ which authenticates the cloud user to the

Procurement Server and Cloud Platform. The client

program can be executed as follows:

# runClient launch user.cer

The client program running in launch mode by the

cloud user connects to the Procurement Server(see

Section 6.2) and receives a resource.xml ﬁle (see

Section 5.1) if a resource is procured successfully.

The resource.xml ﬁle is then parsed to locate the

URI of the procured cloud platform and connects to

it for Integrity Veriﬁcation before ﬁnally sending the

VM Launch request.

6.2 Procurement Server

Conceptually, the Procurement Server can be a com-

bination of multiple entities like cloud controller

which pools and allocates cloud resources, Payment

and Licensing engines to sell available cloud re-

sources. However, our implementation of the Pro-

curement Server is limited to listening to the user-

client requests for available resources and generating

the signed resource.xml ﬁle to be sent back to the

user-client who can then use this ﬁle to connect to the

procured resource.

6.3 Cloud Platform: Management

Agent

The cloud platform which runs the VM instance for

the user, performs the integrity veriﬁcation and VM

launch functionalities for the user. It runs a Manage-

ment Agent in the privileged domain which can ac-

cess TPM services. The Management Agent and its

modules can use TPM services only through the TCG

Software Stack (TSS, 2007) for which we use a Java-

based implementation of the TSS called jTSS, devel-

oped at the Institute for Applied Information Process-

ing and Communication (IAIK), Graz University of

Technology.

The Management Agent listens for the client re-

quests to launch his/her VM and runs the VM launch

protocol. The sequence of messages between the

user-client and the Management Agent perform Plat-

form Integrity Veriﬁcation (see Section 5.2) and VM

Launch (see Section 5.3). For this purpose, three im-

portant response messages are generated by the Man-

agement Agent:

• Attestation response.

SECURELYLAUNCHINGVIRTUALMACHINESONTRUSTWORTHYPLATFORMSINAPUBLICCLOUD-An

Enterprise'sPerspective

517

• Bind-key response.

• Launch response.

These response messages are generated using the

modules in the Services Layer, most notably the In-

tegrity Manager and the Compartment Manager, and

are discussed in the following sections.

6.3.1 Attestation Response

The Attestation Response contains the 1) PCR Quote,

2) Integrity Report and 3) the AIK Certiﬁcate.

The PCR Quote is generated by the hardware TPM

using SK

AIK

which is accessed by calling the

getQuote(expectedPcrComposite, N) method of

the Integrity Manager. The Compartment Man-

ager uses the requestIML() method to load the In-

tegrity Report and the AIK Certiﬁcate is loaded using

the getAikCertificate() method of the Credential

Manager. Finally, the generated Attestation Response

is sent to the user-client for integrity veriﬁcation.

6.3.2 Bind-key Response

The purpose of sending the Bind-Key Response to the

user-client is to allow the user to validate that the

bind

is a TPM-based key and it can only be used if

the platform is in the state veriﬁed by the user-client

in the previous step of integrity veriﬁcation. This is

achieved by calling the certifyBindKey() method

of the Integrity Manager which loads K

bind

and K

AIK

to generate a K

AIK

signed TPM CERTIFY INFO struc-

ture. The bind-key response message is sent to the

user-client which includes PK

bind

along with a K

AIK

signed TPM CERTIFY INFO structure which can only

be generated by the TPM thereby certifying K

bind

6.3.3 Launch Response

The Launch Response is a simple SUCESS mes-

sage for the user-client or a detailed ERROR mes-

sage in case of a failed launch. The Launch Response

message is generated by the getLaunchResponse()

method of the Management Agent which performs

validations for user certiﬁcate, signature and the re-

ceived hash value (h). Furthermore, it calls the

decryptKvm() method of the Integrity Manager to

get the symmetric key K

V M

, which is required to de-

crypt the received VM package. Since K

V M

is en-

crypted with PK

bind

(a TPM-based key), the Integrity

Manager requests the TPM to use the correspond-

ing SK

bind

to decrypt K

V M

. The bind key (K

bind

)

is created (see Section 4.2) with the property that it

can be used for decryption only if the TPM PCRs

have the same value as stated at the time of key cre-

ation

. This implies that only a platform in a good

known state (i.e. veriﬁed integrity state) can get de-

crypted K

V M

and hence can decrypt the VM package.

Once the VM package is successfully decrypted, the

Compartment Manager uses the unpackage() and

launchVM() methods to launch the user VM.

7 SECURITY ANALYSIS

We analyze the security of our launch protocol in the

following sections along with reﬂections on the way

threats identiﬁed in section 2.2 are addressed. The

summary of the security analysis is presented in the

Table 1.

7.1 Authentication

Due to the well known vulnerabilities, (Somorovsky

et al., 2011), we decided to not fully rely on and use

the existing cloud interfaces and APIs for VM launch.

Instead, we used existing well established protocols

such as IKE (with certiﬁcate-based key exchange) and

IPSec for the establishment of a virtual private net-

work (VPN) between the user-client and the provider

network. The mutual authentication of both entities

protects against any impersonation attempts by the at-

tacker (Threats 2 and 3). The user-client also checks

the authenticity of the cloud platform during platform

integrity veriﬁcation (Section 5.2). We also ensure

that only the authenticated cloud platform receives

and runs the user VM by sealing the VM image to

the target cloud platform (Threat 5)

7.2 Conﬁdentiality

The conﬁdentiality of the user applications and data is

ensured by binding the VM image to the trusted cloud

platform (Threat 8). This is done by using the bind

key which is cryptographically bound to the provider-

stated and user-validated state of the platform. This

means that the user data and applications cannot be

accessed even if the VM image is used to create a VM

instance on another compromised platform because it

cannot be decrypted on any platform other than the

trusted one. However, a provider with administra-

tive access to the cloud platform can get a memory

dump of the running user VM to extract user creden-

tials (Rocha and Correia, 2011). Similarly, an insider

The platform is not required to be in the expected state

at the time of key creation.

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

518

Table 1: Security analysis of our proposed mechanisms to mitigate threats.

Threat Security Service Applied Mechanism

1. Insecure Interfaces Authentication IPSec, IKE association

2. User Client Authenticity Authentication IPSec, IKE association

3. Provider Network Attacks Authentication Gateway, IPSec

4. Disowning Malicious VM Non-repudiation User-signed VM Launch

5. Cloud Platform Authenticity

Authentication Remote Attestation, VM Sealing

6. Insider Attacks

Platform Integrity Remote Attestation

7. Mis-conﬁgured Cloud Platform

Platform Integrity Remote Attestation

8. User-data Leak

Conﬁdentiality VM Sealing

Solved by our proposed techniques.

can migrate the running VM to a compromised plat-

form to generate more possibilities of breach of con-

ﬁdentiality. Our proposed approach to protect against

such insider attacks is to restrict the access of such

sensitive administrative tasks (e.g taking snapshot of

the running VM, VM migration, etc.) by enforc-

ing access rights through the Policy Manager mod-

ule. The resource.xml ﬁle, which represents the

procured resource, contains a list of clients (provider

and user) with their access permissions which could

be reviewed by the user before launching his VM. The

details of a trusted Policy Manager with Access Con-

trol Module, which could allow sensitive administra-

tive tasks like VM migration, is a subject of future

work.

Another aspect of data and applications conﬁden-

tiality is the protection against attacks from a mali-

cious VM running in parallel on the same physical

platform. It is very hard to give any ﬁrm guarantees

with respect to the secure isolation provided by any

virtualization layer (Ormandy, 2007). We use XEN

which is a widely used open virtualization layer that

has been and is subject to continuous in depth security

analysis.

7.3 Integrity

The cloud platform integrity is an important secu-

rity requirement for a cloud user which is achieved

by using the TCG mechanism of remote attestation,

thereby addressing threat 6 and 7. We presented the

complete architecture (see Section 4) required for the

platform integrity veriﬁcation performed in the launch

protocol which allows the cloud user to verify the

compliance of the cloud platform to the promised se-

curity proﬁle (Threat 8). However, the Boot Security

and provisioning of the Reference Measurements are

critical in deﬁning the overall integrity of the plat-

form. For example, if the published reference metrics

include bad software or softwares with vulnerabili-

ties, the security of the platform becomes question-

able. Hence, provisioning of high quality reference

metrics assumes good softwares as well, which is a

challenge in the proposed architecture.

7.4 Non-repudiation

Both parties should have mechanisms to prove the

transaction/action in case of repudiation by the other

party (Threat 4). Two such critical actions and cor-

responding security requirements are 1) a proof that

the cloud user has requested and paid for the resource

to launch his VM, and 2) a proof that the cloud user

has actually sent a request to run his VM instance (so

that he cannot disown it later). In our protocol, non-

repudiation is achieved by sending a provider signed

resource.xml for the ﬁrst action and the signature

of the cloud user on the VM Launch request for the

second action.

7.5 Replay Protection

The cloud user sends a nonce (N) in the attestation

request which is returned in the attestation response

(signed TPM Quote). The Attestation Response and

the Bind-key Response are hashed to keep session

binding and protect against replay attacks. The ran-

domness in the hash values (h,h1 and h2) comes from

the original nonce (N) sent in the attestation request.

8 CONCLUSIONS

In this paper we have addressed one of the major hur-

dles for enterprises to shift their business processes

to the clouds, i.e. lack of security guarantees. We

identiﬁed major security threats with respect to vir-

tual machine provision in IaaS. Many of the identi-

ﬁed threats are general and well known for any dis-

tributed system for which standard security mecha-

nisms already exist. We proposed a novel launch pro-

tocol which uses standard security mechanisms for

the known threats and combined those with trusted

computing techniques to ﬁll the trust deﬁcit between

SECURELYLAUNCHINGVIRTUALMACHINESONTRUSTWORTHYPLATFORMSINAPUBLICCLOUD-An

Enterprise'sPerspective

519

cloud stakeholders. In addition, we have designed a

complete software architecture needed to run the pro-

tocol and protect the VM data. Our protocol enables

technical trust which allows cloud users to validate

the security guarantees given by the cloud provider

before using the provisioned service. We also imple-

mented the designed protocol to evaluate its feasibil-

ity in terms of implementation effort and complex-

ity. Finally, we performed security analysis to val-

idate that all security requirements are fulﬁlled and

all identiﬁed threats have been addressed comprehen-

sively. In our analysis, we showed how a user VM can

strongly be bounded to a particular platform to ful-

ﬁll users’ security requirements. However, this strong

binding also limits the ﬂexibility with respect to load

management, platform upgrade, etc. These limita-

tions can be reduced by adding trusted VM migration

mechanism to the solution. Our suggested architec-

ture allows opportunities for such extensions but the

details are left for future research.

REFERENCES

acTvSM (2010). Advanced Cryptographic

Trusted Virtual Security Module.

http://www.iaik.tugraz.at/content/research/trusted co

mputing/actvsm/.

Aslam, M. and Gehrmann, C. (2011). Security Considera-

tions for Virtual Platform Provisioning. In ECIW ’11:

Proceedings of the 10th European Conference on In-

formation Warfare and Security, pages 283–290, UK.

The Institute of Cybernetics at the Tallinn University

of Technology, Academic Publishing Limited.

Berger, S., C

aceres, R., Goldman, K. A., Perez, R., Sailer,

R., and van Doorn, L. (2006). vTPM: Virtualizing the

Trusted Platform Module. In USENIX-SS’06: Pro-

ceedings of the 15th Conference on USENIX Security

Symposium, Berkeley, CA, USA. USENIX Associa-

tion.

Chisnall, D. (2007). The Deﬁnitive Guide to the Xen Hyper-

visor (Prentice Hall Open Source Software Develop-

ment Series). Prentice Hall PTR, Upper Saddle River,

NJ, USA.

CircleID (2009). Survey: Cloud Computing ’No Hype’,

But Fear of Security and Control Slowing Adoption.

http://www.circleid.com/posts/20090226 cloud comp

uting hype security/.

Cloud Computing and Security (2010). Cloud

Computing and Security - A Natural Match.

http://www.trustedcomputinggroup.org/resources/clo

ud computing and security a natural match.

CSA Guide (2009). Security guidance for crit-

ical areas of focus in cloud computing.

http://www.cloudsecurityalliance.org/guidance/csagu

ide.v2.1.pdf.

Frankel, S. and Krishnan, S. (2011). IP Security (IPsec) and

Internet Key Exchange (IKE) Document Roadmap.

RFC 6071 (Informational).

Gasmi, Y., Sadeghi, A.-R., Stewin, P., Unger, M., and

Asokan, N. (2007). Beyond Secure Channels. In STC

’07: Proceedings of the 2007 ACM Workshop on Scal-

able Trusted Computing, pages 30–40, New York, NY,

USA. ACM.

Haldar, V., Chandra, D., and Franz, M. (2004). Seman-

tic Remote Attestation - A Virtual Machine directed

approach to Trusted Computing. In USENIX Virtual

Machine Research and Technology Symposium, pages

29–41.

Huang, X. and Peng, Y. (2009). An Effective Approach

for Remote Attestation in Trusted Computing. In

WISA 2009 : Proceedings of the 2nd International

Symposium on Web Information Systems and Applica-

tions, pages 80–83, FIN-90571, OULU, FINLAND.

Academy Publisher.

IMM (2006). TCG Infrastructure Archi-

tecture Part-II - Integrity Management.

http://www.trustedcomputinggroup.org/resources.

Jansen, B., Ramasamy, H. V., and Schunter, M. (2006).

Flexible Integrity Protection and Veriﬁcation Archi-

tecture for Virtual Machine Monitors. In The Second

Workshop on Advances in Trusted Computing (WATC

06 Fall.

Krutz, R. L. and Vines, R. D. (2010). Cloud Security:

A Comprehensive Guide to Secure Cloud Computing.

Wiley Publishing.

Landfermann, R., Kuhlmann, D., Kuhlmann, D., L, R.,

Ramasamy, H. V., Ramasamy, H. V., Schunter,

M., Schunter, M., Ramunno, G., Ramunno, G.,

Vernizzi, D., and Vernizzi, D. (2006). D.: An Open

Trusted Computing Architecture – Secure Virtual Ma-

chines Enabling User-deﬁned Policy Enforcement.

www.opentc.net.

Ormandy, T. (2007). An empirical Study into the Secu-

rity Exposure to Hosts of Hostile Virtualized Environ-

ments. In CanSecWest.

Rocha, F. and Correia, M. (2011). Lucy in the sky without

diamonds: Stealing conﬁdential data in the cloud. De-

pendable Systems and Networks Workshops, 0:129–

134.

Sailer, R., Zhang, X., Jaeger, T., and van Doorn, L. (2004).

Design and implementation of a tcg-based integrity

measurement architecture. In Proceedings of the 13th

conference on USENIX Security Symposium - Vol-

ume 13, SSYM’04, pages 16–16, Berkeley, CA, USA.

USENIX Association.

Somorovsky, J., Heiderich, M., and Jensen, M. (2011). All

your clouds are belong to us: security analysis of

cloud management interfaces. computing security.

TCG Architecture Overview (2007). TCG

Speciﬁcation Architecture Overview.

http://www.trustedcomputinggroup.org/resources.

Threats, C. (2010). Top Threats to Cloud Computing. Tech-

nical Report Version 1.0, Cloud Security Alliance.

TMI (2010). TCG Trusted Multi-Tenant Infrastructure.

http://www.trustedcomputinggroup.org/developers/tr

usted multitenant infrastructure.

TPM Commands (2007). TPM Speciﬁca-

tion, TPM Main Part-III Design Principles.

http://www.trustedcomputinggroup.org/resources.

CLOSER2012-2ndInternationalConferenceonCloudComputingandServicesScience

520

TSS (2007). TCG Software Stack (TSS) Speciﬁcation.

http://www.trustedcomputinggroup.org/resources.

Van Doorn, L. (2007). Trusted Computing Challenges. In

STC ’07: Proceedings of the 2007 ACM Workshop on

Scalable Trusted Computing, pages 1–1, New York,

NY, USA. ACM.

Vaquero, L. M., Rodero-Merino, L., and Mor

an, D. (2011).

Locking the sky: a survey on iaas cloud security. Com-

puting, 91:93–118.

SECURELYLAUNCHINGVIRTUALMACHINESONTRUSTWORTHYPLATFORMSINAPUBLICCLOUD-An

Enterprise'sPerspective

521