Providing User Security Guarantees in Public Infrastructure Clouds · Providing User Security Guarantees in Public Infrastructure Clouds Nicolae Paladi, Christian Gehrmann, and Antonis

2168-7161 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TCC.2016.2525991, IEEETransactions on Cloud Computing

1

Providing User Security Guarantees in PublicInfrastructure Clouds

Nicolae Paladi, Christian Gehrmann, and Antonis Michalas

Abstract—The infrastructure cloud (IaaS) service model offers improved resource flexibility and availability, where tenants – insulatedfrom the minutiae of hardware maintenance – rent computing resources to deploy and operate complex systems. Large-scale servicesrunning on IaaS platforms demonstrate the viability of this model; nevertheless, many organizations operating on sensitive data avoidmigrating operations to IaaS platforms due to security concerns. In this paper, we describe a framework for data and operation securityin IaaS, consisting of protocols for a trusted launch of virtual machines and domain-based storage protection. We continue with anextensive theoretical analysis with proofs about protocol resistance against attacks in the defined threat model. The protocols allowtrust to be established by remotely attesting host platform configuration prior to launching guest virtual machines and ensureconfidentiality of data in remote storage, with encryption keys maintained outside of the IaaS domain. Presented experimental resultsdemonstrate the validity and efficiency of the proposed protocols. The framework prototype was implemented on a test bed operating apublic electronic health record system, showing that the proposed protocols can be integrated into existing cloud environments.

Index Terms—Security; Cloud Computing; Storage Protection; Trusted Computing

F

1 INTRODUCTION

Cloud computing has progressed from a bold vision to mas-sive deployments in various application domains. However,the complexity of technology underlying cloud computingintroduces novel security risks and challenges. Threats andmitigation techniques for the IaaS model have been underintensive scrutiny in recent years [1], [2], [3], [4], whilethe industry has invested in enhanced security solutionsand issued best practice recommendations [5]. From anend-user point of view the security of cloud infrastructureimplies unquestionable trust in the cloud provider, in somecases corroborated by reports of external auditors. Whileproviders may offer security enhancements such as protec-tion of data at rest, end-users have limited or no controlover such mechanisms. There is a clear need for usable andcost-effective cloud platform security mechanisms suitablefor organizations that rely on cloud infrastructure.

One such mechanism is platform integrity verificationfor compute hosts that support the virtualized cloud infras-tructure. Several large cloud vendors have signaled practicalimplementations of this mechanism, primarily to protectthe cloud infrastructure from insider threats and advancedpersistent threats. We see two major improvement vectorsregarding these implementations. First, details of such pro-prietary solutions are not disclosed and can thus not be im-plemented and improved by other cloud platforms. Second,to the best of our knowledge, none of the solutions providescloud tenants a proof regarding the integrity of computehosts supporting their slice of the cloud infrastructure. Toaddress this, we propose a set of protocols for trusted launchof virtual machines (VM) in IaaS, which provide tenantswith a proof that the requested VM instances were launchedon a host with an expected software stack.

Another relevant security mechanism is encryption ofvirtual disk volumes, implemented and enforced at compute

host level. While support data encryption at rest is offeredby several cloud providers and can be configured by tenantsin their VM instances, functionality and migration capabil-ities of such solutions are severely restricted. In most casescloud providers maintain and manage the keys necessaryfor encryption and decryption of data at rest. This furtherconvolutes the already complex data migration procedurebetween different cloud providers, disadvantaging tenantsthrough a new variation of vendor lock-in. Tenants canchoose to encrypt data on the operating system (OS) levelwithin their VM environments and manage the encryptionkeys themselves. However, this approach suffers from sev-eral drawbacks: first, the underlying compute host will stillhave access encryption keys whenever the VM performscryptographic operations; second, this shifts towards thetenant the burden of maintaining the encryption softwarein all their VM instances and increases the attack surface;third, this requires injecting, migrating and later securelywithdrawing encryption keys to each of the VM instanceswith access to the encrypted data, increasing the probabilitythan an attacker eventually obtains the keys. In this paperwe present DBSP (domain-based storage protection), a vir-tual disk encryption mechanism where encryption of data isdone directly on the compute host, while the key materialnecessary for re-generating encryption keys is stored inthe volume metadata. This approach allows easy migrationof encrypted data volumes and withdraws the control ofthe cloud provider over disk encryption keys. In addition,DBSP significantly reduces the risk of exposing encryptionkeys and keeps a low maintenance overhead for the tenant– in the same time providing additional control over thechoice of the compute host based on its software stack.

We focus on the Infrastructure-as-a-Service model – in asimplified form, it exposes to its tenants a coherent platformsupported by compute hosts which operate VM guests thatcommunicate through a virtual network. The system model



2

chosen for this paper is based on requirements identifiedwhile migrating a currently deployed, distributed electronichealth record (EHR) system to an IaaS platform [6].

1.1 ContributionWe extend previous work applying Trusted Computing tostrengthen IaaS security, allowing tenants to place hardsecurity requirements on the infrastructure and maintainexclusive control of the security critical assets. We proposea security framework consisting of three buiding blocks:

• Protocols for trusted launch of VM instances in IaaS;• Key management and encryption enforcement func-

tions for VMs, providing transparent encryption ofpersistent data storage in the cloud;

• Key management and security policy enforcement bya Trusted Third Party (TTP);

We describe several contributions that enhance cloudinfrastructure with additional security mechanisms:

1. We describe a trusted VM launch (TL) protocol whichallows tenants – referred to as domain managers – tolaunch VM instances exclusively on hosts with an at-tested platform configuration and reliably verify this.

2. We introduce a domain-based storage protection proto-col to allow domain managers store encrypted data vol-umes partitioned according to administrative domains.

3. We introduce a list of attacks applicable to IaaS environ-ments and use them to develop protocols with desiredsecurity properties, perform their security analysis andprove their resistance against the attacks.

4. We describe the implementation of the proposed pro-tocols on an open-source cloud platform and presentextensive experimental results that demonstrate theirpracticality and efficiency.

1.2 OrganizationThe rest of this paper is organized as follows. In Section 2we describe relevant related work on trusted virtual machinelaunch and cloud storage protection. In Section 3 we intro-duce the system model, as well as the threat model andproblem statement. In Section 4 we introduce the protocolcomponents, and the TL and DBSP protocols as formalconstructions. In Section 5, we provide a security analysisand prove the resistance of the protocols against the definedattacks, while implementation and performance evaluationresults are described in Section 6. We discuss the protocolapplication domain in Section 7 and conclude in Section 8.

2 RELATED WORK

We start with a review of related work on trusted VMlaunch, followed by storage protection in IaaS.

2.1 Trusted LaunchSantos et al. [1] proposed a “Trusted Cloud Compute Plat-form” (TCCP) to ensure VMs are running on a trustedhardware and software stack on a remote and initiallyuntrusted host. To enable this, a trusted coordinator storesthe list of attested hosts that run a “trusted virtual machinemonitor” which can securely run the client’s VM. Trustedhosts maintain in memory an individual trusted key used

for identification each time a client launches a VM. Thepaper presents a good initial set of ideas for trusted VMlaunch and migration, in particular the use of a trustedcoordinator. A limitation of this solution is that the trustedcoordinator maintains information about all hosts deployedon the IaaS platform, making it a valuable target to anadversary who attempts to expose the public IaaS providerto privacy attacks.

A decentralized approach to integrity attestation isadopted by Schiffman et al. [2] to address the limited trans-parency of IaaS platforms and scalability limits imposed bythird party integrity attestation mechanisms. The authorsdescribe a trusted architecture where tenants verify theintegrity of IaaS hosts through a trusted cloud verifier proxyplaced in the cloud provider domain. Tenants evaluate thecloud verifier integrity, which in turn attests the hosts.Once the VM image has been verified by the host andcountersigned by the cloud verifier, the tenant can allow thelaunch. The protocol increases the complexity for tenantsboth by introducing the evaluation of integrity attestationreports of the cloud verifier and host and by adding steps tothe trusted VM launch, where the tenant must act basedon the data returned from the cloud verifier. Our proto-col maintains the VM launch traceability and transparencywithout relying on a proxy verifier residing in the IaaS.Furthermore, the TL protocol does not require additionaltenant interaction to launch the VM on a trusted host,beyond the initial launch arguments.

Platform attestation prior to VM launch is also appliedin [7], which introduces two protocols – “TPM-based certi-fication of a Remote Resource” (TCRR) and “VerifyMyVM”.With TCRR a tenant can verify the integrity of a remotehost and establish a trusted channel for further commu-nication. In “VerifyMyVM”, the hypervisor running on anattested host uses an emulated TPM to verify on-demandthe integrity of running VMs. Our approach is in manyaspects similar to the one in [7] in particular with regardto host attestation prior to VM instance launch. However,the approach in [7] requires the user to always encrypt theVM image before instantiation, thus complicating imagemanagement. This prevents tenants from using commodityVM images offered by the cloud provider for trusted VMlaunches. We overcome this limitation and generalize thesolution by adding a verification token, created by thetenant and injected on the file system of the VM instanceonly if it is launched on an attested cloud host.

In [8], the authors described a protocol for trusted VMlaunch on public IaaS using trusted computing techniques.To ensure that the requested VM instance is launched ona host with attested integrity, the tenant encrypts the VMimage (along with all injected data) with a symmetric keysealed to a particular configuration of the host reflected inthe values of the platform configuration registers (PCR) ofthe TPM placed on the host. The proposed solution is suit-able in trusted VM launch scenarios for enterprise tenants asit requires that the VM image is pre-packaged and encryptedby the client prior to IaaS launch. However, similar to [7],this prevents tenants from using commodity VM imagesoffered by the cloud provider to launch VM instances ontrusted cloud hosts. Furthermore, we believe that reducingthe number of steps required from the tenant can facilitate



3

the adoption of the trusted IaaS model. We extend someof the ideas proposed in [8], address the above limitations– such as additional actions required from tenants – andalso address the requirements towards the launched VMinstance and required changes to cloud platforms.

2.2 Secure StorageCooper at al described in in [9] a secure platform architec-ture based on a secure root of trust for grid environments –precursors of cloud computing. Trusted Computing is usedas a method for dynamic trust establishment within the grid,allowing clients to verify that their data wil be protectedagainst malicious host attacks. The authors address the ma-licious host problem in grid environments, with three mainrisk factors: trust establishment, code isolation and gridmiddleware. The solution established a minimal trustedcomputing base (TCB) by introducing a security managerisolated by the hypervisor from grid services (which are inturn performed within VM instances). The secure architec-ture is supported by protocols for data integrity protection,confidentiality protection and grid job attestation. In turn,these rely of client attestation of the host running the respec-tive jobs, followed by interaction with the security managerto fulfill the goals of the respective protocols. We follow asimilar approach in terms of interacting with a minimal TCBfor protocol purposes following host attestation. However,in order to adapt to the cloud computing model we delegatethe task of host attestation to an external TTP as well asuse TPM functionality to ensure that sensitive cryptographicmaterial can only be accessed on a particular attested host.

In [10], the authors proposed an approach to protectaccess to outsourced data in an owner-write-users-readcase, assuming an “honest but curious service provider”.Encryption is done over (abstract) blocks of data, with adifferent key per block. The authors suggest a key derivationhierarchy based on a public hash function, using the hashfunction result as the encryption key. The scheme allows toselectively grant data access, uses over-encryption to revokeaccess rights and supports block deletion, update, insertionand appending. It adopts a lazy revocation model, allow-ing to indefinitely maintain access to data reachable priorto revocation (regardless of whether it has been accessedbefore access revocation). While this solution is similar toour model with regard to information blocks and encryp-tion with different symmetric keys, we propose an activerevocation model, where the keys are cached for a limitedtime and cannot be retrieved once the access is revoked.

The “Data-Protection-as-a-Service” (DPaaS) platform[11] balances the requirements for confidentiality and pri-vacy with usability, availability and maintainability. DPaaSfocuses on shareable logical data units, confined in isolatedpartitions (e.g. VMs of language-based features such as Caja,Javascript) or containers, called Secure Execution Environ-ments (SEE). Data units are encrypted with symmetric keysand can be stored on untrusted hardware, while containerscommunicate through authenticated channels. The authorsstress the verifiability of DPaaS using trusted computingand the use of the dynamic root of trust to guarantee thatcomputation is performed on a “secure” platform. The au-thors posit that DPaaS fulfills confidentiality and privacy re-quirements and facilitates maintenance, logging and audit;

provider migration is one of the aspects highlighted, but notaddressed in [11]. Our solution resembles DPaaS in the useof SEE based on software attestation mechanisms offeredby the TPM, and in the reliance on full disk encryption toprotect data at rest and support for flexible access controlmanagement of the data blocks. However, the architectureoutlined in [11] does not address bootstrapping the platform(e.g. the VM launch) and provides few details about thekey management mechanism for the secure data store. Weaddress the above shortcomings, by describing in detailand evaluating protocols to create and share confidentiality-protected data blocks. We describe cloud storage secu-rity mechanisms that allow easy data migration betweenproviders without affecting its confidentiality.

Graf et al. [12] presented an IaaS storage protectionscheme addressing access control. The authors analyse ac-cess rights management of shared versioned encrypted dataon cloud infrastructure for a restricted group and propose ascalable and flexible key management scheme. Access rightsare represented as a graph, making a distinction betweendata encryption keys and encrypted updates on the keysand enabling flexible join/leave client operations, similar toproperties presented by the protocols in this paper. Despiteits advantages, the requirement for client-side encryptionlimits the applicability of the scheme in [12] and introducesimportant functional limitations on indexing and search. Inour model, all cryptographic operations are performed ontrusted IaaS compute hosts, which are able to allocate morecomputational resources than client devices.

Santos et al. [13] proposed Excalibur, a system usingtrusted computing mechanisms to allow decrypting clientdata exclusively on nodes that satisfy a tenant-specifiedpolicy. Excalibur introduces a new trusted computing ab-straction, policy-sealed data to address the fact that TPMabstractions are designed to protect data and secrets on astandalone machine, at the same time over-exposing thecloud infrastructure by revealing the identity and softwarefingerprint of individual cloud hosts. The authors extendedTCCP [1] to address the limitations of binary-based attes-tation and data sealing by using property-based attesta-tion [14]. The core of Excalibur is ‘the monitor’, which is apart of the cloud provider, which organises computationsacross a series of hosts and provides guarantees to tenants.Tenants first decide a policy and receive evidence regardingthe status of the monitor along with a public encryptionkey, and then encrypt their data and policy using ciphertext-policy attribute-based encryption [15]. To decrypt, the storeddata hosts receive the decryption key from the monitorwho ensures that the corresponding host has a valid sta-tus and satisfies the policy specified by the client at en-cryption time. Our solution is similar to the one in [13],with some important differences: 1) In contrast with [13]our protocols were implemented as a code extension forOpenstack. Furthermore, the presented measurements weremade after we deployed the protocols for a part of theSwedish electronic health records management system inan infrastructure cloud. Thus, our measures are consideredas realistic since the experiments were done under a realelectronic healthcare system; 2) Excalibur is totally missinga security analysis. Instead authors only present the resultsof ProVerif (an automated tool) regarding the correctness



4

of their protocol. In addition to that, through our securityanalysis we introduced a new list of attacks that can beapplied to such systems. This is something that is totallymissing from related works such as [13] and it can beconsidered as a great contribution to protocol designerssince can avoid common pitfalls and design even betterprotocols in the future;

In [16] the authors presented a forward-looking designof a cryptographic cloud storage built on an untrusted IaaSinfrastructure. The approach aims to provide confidentialityand integrity, while retaining the benefits of cloud storage– availability, reliability, efficient retrieval and data sharing– and ensuring security through cryptographic guaranteesrather than administrative controls. The solution requiresfour client-side components: data processor, data verifier, cre-dential generator, token generator. Important building blocksof the solution are: Symmetric searchable encryption (SSE),appropriate in settings where the data consumer is also theone who generates it (efficient for single writer-single reader(SWSR) models); Asymmetric searchable encryption (ASE), ap-propriate for many writer single reader (MWSR) models,offers weaker security guarantees as the server can mounta dictionary attack against the token and learn the searchterms of the client; Efficient ASE, appropriate in MWSRscenarios where the search terms are hard to guess, offersefficient search but is vulnerable to dictionary attacks; Multi-user SSE, appropriate for single writer/many reader set-tings, allows the owner to – besides encrypting indexes andgenerating tokens – revoke user search privileges over data;Attribute based encryption, introduced in [17], provides userswith a decryption key with certain associated attributes,such that a message can be encrypted using a certain keyand a policy. In such a scheme, the message can only bedecrypted only if the policy matches the key used to encryptit; finally, proofs of storage allow a client to verify that dataintegrity has not been violated by the server.

The concepts presented in [16] are promising – espe-cially considering recent progress in searchable encryptionschemes [18]. Indeed, integrating searchable and attribute-based encryption mechanisms into secure storage solutionsis an important direction in our future work. However,practical application of searchable encryption and attribute-based encryption requires additional research.

Earlier work in [19], [20] described interoperable solu-tions towards trusted VM launch and storage protection inIaaS. We extend them to create an integrated framework thatbuilds a trust chain from the domain manager to the VMinstances and data in their administrative domain, and pro-vide additional details, proofs and performance evaluation.

3 SYSTEM MODEL AND PRELIMINARIES

In this section we describe the system and threat model, aswell as present the problem statement.

3.1 System Model

We assume an IaaS system model (e.g. OpenStack, a popularopen-source cloud platform) as in [21]: providers expose aquota of network, computation and storage resources to itstenants – referred to as domain managers (Figure 1). Domain

managers utilize the quota to launch and operate VM guests.Let DM = {DM1, . . . , DMn} be the set of all domain man-agers in our IaaS. Then, VMi =

{vmi

1, . . . , vmin

}is the

set of all VMs owned by each domain manager DMi. VMguests operated by DM are grouped into domains (similarto projects in OpenStack) which comprise cloud resourcescorresponding to a particular organization or administrativeunit. DM create, modify, destroy domains and manageaccess permissions of VMs to data stored in the domains.We refer to Di =

{Di

1, . . . , Din

}as the set of all domains

created by a domain manager DMi.

Scheduler Host

Storage hostStorage host Storage host

Storage abstraction agent

VM 1VM 1VM

smallVM

small

Compute Host

Infrastructure Cloud Provider

VM 1

VMmedium

VMi VMj

SRi1 SRi

2 SRj1

Dj1Di

1

Compute HostCHCHi

CHj

Image repository

Network host

Indentity management

Trusted Third Party

SC

TPM

Domain Manager

DM

SC

TPM

Fig. 1. High level view of the IaaS model introduced in Section 3.

Requests for operations on VMs (launch, migration, ter-mination, etc.) received by the IaaS are managed by a sched-uler that allocates (reallocates, deallocates) resources fromthe pool of available compute hosts according to a resourcemanagement algorithm. We assume in this work computehosts that are physical – rather than virtual – servers. We de-note the set of all compute hosts as CH = {CH1, . . . , CHn}.We denote a VM instance vmi

l running on a compute hostCHi by vmi

l 7→ CHi and its unique identifier by idvmil .

The Security Profile (SP ) , defined in [19], is a function ofthe verified and measured deployment of a trusted comput-ing base – a collection of software components measurableduring a platform boot. Measurements are maintained inprotected storage, usually located on the same platform.We expand this concept in Section 4. Several functionallyequivalent configurations may each have a different securityprofile. We denote the set of all compute hosts that share thesame security profile SPi as CHSPi . VMs intercommunicatethrough a virtual network overlay, a “software definednetwork” (SDN). A domain manager can create arbitrarynetwork topologies in the same domain to interconnect theVMs without affecting network topologies in other domains.

I/O virtualization enables device aggregation and allowsto combine several physical devices into a single logical de-vice (with better properties), presented to a VM [22]. Cloudplatforms use this to aggregate disparate storage devicesinto highly available logical devices with arbitrary storagecapacity (e.g. volumes in OpenStack). VMs are presentedwith a logical device through a single access interface, whilereplication, fault-tolerance and storage aggregation are hid-den in the lower abstraction layers. We refer to this logicaldevice as storage resource (SR); as a storage unit, an SR canbe any unit supported by the disk encryption subsystem.

3.2 Threat ModelWe share the threat model with [1], [19], [20], [8], which isbased on the Dolev-Yao adversarial model [23] and further



5

assumes that privileged access rights can used by a remoteadversaryADV to leak confidential information.ADV , e.g.a corrupted system administrator, can obtain remote accessto any host maintained by the IaaS provider, but cannotaccess the volatile memory of guest VMs residing on thecompute hosts of the IaaS provider. This property is basedon the closed-box execution environment for guest VMs, asoutlined in Terra [24] and further developed in [25], [26].

Hardware Integrity: Media revelations have raisedthe issue of hardware tampering en route to deploymentsites [27], [28]. We assume that the cloud provider has takennecessary technical and non-technical measures to preventsuch hardware tampering.

Physical Security: We assume physical security ofthe data centres where the IaaS is deployed. This as-sumption holds both when the IaaS provider owns andmanages the data center (as in the case of Amazon WebServices, Google Compute Engine, Microsoft Azure, etc.)and when the provider utilizes third party capacity, sincephysical security can be observed, enforced and verifiedthrough known best practices by audit organizations. Thisassumption is important to build higher-level hardware andsoftware security guarantees for the components of the IaaS.

Low-Level Software Stack: We assume that at in-stallation time, the IaaS provider reliably records integritymeasurements of the low-level software stack: the Core Rootof Trust for measurement; BIOS and host extensions; hostplatform configuration; Option ROM code, configurationand data; Initial Platform Loader code and configuration;state transitions and wake events, and a minimal hypervisor.We assume the record is kept on protected storage withread-only access and the adversary cannot tamper with it.

Network Infrastructure: The IaaS provider has phys-ical and administrative control of the network. ADV is infull control of the network configuration, can overhear, cre-ate, replay and destroy all messages communicated betweenDM and their resources (VMs, virtual routers, storage ab-straction components) and may attempt to gain access toother domains or learn confidential information.

Cryptographic Security: We assume encryptionschemes are semantically secure and theADV cannot obtainthe plain text of encrypted messages. We also assume thesignature scheme is unforgeable, i.e. the ADV cannot forgethe signature of DMi and that the MAC algorithm correctlyverifies message integrity and authenticity. We assume thatthe ADV , with a high probability, cannot predict the outputof a pseudorandom function. We explicitly exclude denial-of-service attacks and focus on ADV that aim to compro-mise the confidentiality of data in IaaS.

3.3 Problem Statement

The introduced ADV has far-reaching capabilities to com-promise IaaS host integrity and confidentiality. We define aset of attacks available to ADV in the above threat model.

Given that ADV has full control over the network com-munication within the IaaS, one of the available attacks isto inject a malicious program or back door into the VMimage, prior to instantiation. Once the VM is launched andstarts processing potentially sensitive information, the mali-cious program can leak data to an arbitrary remote location

without the suspicion of the domain manager. In this case,the VM instance will not be a legitimate instance and inparticular not the instance the domain manager intended tolaunch. We call this type of attack a VM Substitution Attack:Definition 1 (Successful VM Substitution Attack). Assume

a domain manager, DMi, intends to launch a particularvirtual machine vmi

l on an arbitrary compute host in theset CHSPi

. An adversary, ADV , succeeds to perform aVM substitution attack if she can find a pair (CH, vm) :CH ∈ CHSPi

, vm ∈ VM, vm 6= vmil, vm 7→ CH ,

where vm will be accepted by DMi as vmil .

A more complex attack involves reading or modifying theinformation processed by the VM directly, from the logsand data stored on CH or from the representation of theguest VMs’ drives on the CH file system. This might benon-trivial or impossible with strong security mechanismsdeployed on the host; however, ADV may attempt to cir-cumvent this through a so-called CH Substitution Attack – bylaunching the guest VM on a compromised CH .Definition 2 (Successful CH Substitution Attack). Assume

DMi wishes to launch a VM vmil on a compute host

in the set CHSPi. An adversary, ADV , succeeds with

a CH substitution attack iff ∃ vmil 7→ CHj , CHj ∈

CHSPj, SPj 6= SPi: vmi

l will be accepted by DMi.

Depending on the technical expertise of DMi, ADV maystill take the risk of deploying a concealed – but feature-rich – malicious program in the guest VM and leave a fallback option in case the malicious program is removed orprevented from functioning as intended. ADV may choosea combined VM and CH substitution attack, which allows amodified VM to be launched on a compromised host andpresent it to DMi as the intended VM:Definition 3 (Successful Combined VM and CH

Substitution Attack). Assume a domain manager,DMi, wishes to launch a virtual machine vmi

l

on a compute host in the set CHSPi. An adver-

sary, ADV , succeeds to perform a combined CHand VM substitution attack if she can find apair (CH, vm), CH ∈ CHSPj

, SPj 6= SPi, vm ∈ VM,vm 6= vmi

l, vm 7→ CH , where vm will be accepted byDMi as vmi

l .

Denote by Divm the set of storage domains that vm ∈ VM,

vm 7→ CHi can access. We define a successful storage computehost substitution attack as follows1:Definition 4 (Successful Storage CH Substitution Attack).

A DMi wishes to launch or has launched an arbitraryvirtual machine vmi

l on a compute host in the set CHSPi.

An adversary ADV succeeds with a storage CH substi-tution attack if she manages to launch vmi

l 7→ CHj ,CHj ∈ CHSPj , SPj 6= SPi and Di

vmil∩ Dj

vmil6= ∅.

If access to the data storage resource is given to all VMslaunched by DMi, ADV may attempt to gain access by

1In this definition we exclude the possibility of legal domain shar-ing which would be a natural requirement for most systems. However,with our suggested definition, the legal sharing case can be coveredby extending the domain manager role such that it is allowed not toa distinct entity but a role that is possibly shared between domainmanagers that belong to different organizations.



6

launching a VM that appears to have been launched byDMi.Then, ADV would be able to leak data from the domainowned by DMi to other domains. This infrastructure-levelattack would not be detected by DMi and requires carefulconsideration. A formal definition of the attack1 follows.Definition 5 (Successful Domain Violation Attack). Assume

DMi has created the domains in the set Di. An ad-versary ADV succeeds to perform a domain violationattack if she manages to launch an arbitrary VM, vmj

m

on an arbitrary host CHj , i.e. vmjm 7→ CHj , where

Dj

vmjm∩ Di 6= ∅.

4 PROTOCOL DESCRIPTION

We now describe two protocols that constitute the core ofthis paper’s contribution. These protocols are successivelyapplied to deploy a cloud infrastructure providing addi-tional user guarantees of cloud host integrity and storage se-curity. For protocol purposes, each domain manager, securecomponent and trusted third party has a public/private keypair (pk/sk). The private key is kept secret, while the publickey is shared with the community. We assume that duringthe initialization phase, each entity obtains a certificatevia a trusted certification authority. We first describe thecryptographic primitives used in the proposed protocols,followed by definitions of the main protocol components.

4.1 Cryptographic PrimitivesThe set of all binary strings of length n is denoted by {0, 1}n,and the set of all finite binary strings as {0, 1}∗. Given aset U , we refer to the ith element as vi. Additionally, weuse the following notations for cryptographic operationsthroughout the paper:

• For an arbitrary message m ∈ {0, 1}∗, we denoteby c = Enc (K,m) a symmetric encryption of musing the secret key K ∈ {0, 1}∗. The correspond-ing symmetric decryption operation is denoted bym = Dec(K, c) = Dec(K,Enc(K,m)).

• We denote by pk/sk a public/private key pair for apublic key encryption scheme. Encryption of mes-sage m under the public key pk is denoted byc = Encpk (m)2 and the corresponding decryptionoperation by m = Decsk(c) = Decsk(Encpk(m)).

• A digital signature over a message m is denotedby σ = Signsk(m). The corresponding verifica-tion operation for a digital signature is denoted byb = Verifypk(m,σ), where b = 1 if the signature isvalid and b = 0 otherwise.

• A Message Authentication Code (MAC) using asecret key K over a message m is denoted byµ = MAC(K,m).

• We denote by τ = RAND(n) a random binary se-quence of length n, where RAND(n) represents arandom function that takes a binary length argumentn as input and gives a random binary sequence ofthis length in return3.

2Alternative notations used for clarity are {m}pk or 〈m〉pk.3We assume that a true random function in our constructions

is replaced by a pseudorandom function the input-output behaviourof which is “computationally indistinguishable” from that of a truerandom function.

4.2 Protocol Components

Disk encryption subsystem: a software or hardwarecomponent for data I/O encryption on storage devices, ca-pable to encrypt storage units such as hard drives, softwareRAID volumes, partitions, files, etc. We assume a software-based subsystem, such as dm-crypt, a disk encryption sub-system using the Linux kernel Crypto API.

Trusted Platform Module (TPM): a hardwarecryptographic co-processor following specifications of theTrusted Computing Group (TCG) [29]; we assume CH areequipped with a TPM v1.2. The tamper-evident propertyfacilitates monitoring CH integrity and strengthens the as-sumption of physical security. An active TPM records theplatform boot time software state and stores it as a listof hashes in platform configuration registers (PCRs). TPMv1.2 has 16 PCRs reserved for static measurements (PCR0- PCR15), cleared upon a hard reboot. Additional runtimeresettable registers (PCR16-PCR23) are available for dynamicmeasurements. Endorsement keys are an asymmetric key pairstored inside the TPM in the trusted platform supply chain,used to create an endorsement credential signed by the TPMvendor to certify the TPM specification compliance. A mes-sage encrypted (“bound”) using a TPM’s public key is de-cryptable only with the private key of the same TPM. Sealingis a special case of binding – bound messages are onlydecryptable in the platform state defined by PCR values.Platform attestation allows a remote party to authenticatea target platform and obtain a guarantee that it – up toa certain level in the boot chain – runs software that isidentical to the expected one. To do this, an attester requests– accompanied by a nonce – the target platform to producean attestation quote and the measurement aggregate, orIntegrity Measurement List (IML). The TPM generates theattestation quote – a signed structure that includes the IMLand the received nonce – and returns the quote and theIML itself. The attestation quote is signed with the TPMsAttestation Identity Key (AIK). The exact IML contents areimplementation-specific, but should contain enough datato allow the verifier to establish the target platform [30]integrity. We refer to [29] for a description of the TPM, andto [7], [19], [20] for protocols that use TPM functionality.

Trusted Third Party (TTP): an entity trusted bythe other components. TTP verifies the TPM endorsementcredentials on hosts operated by the cloud provider andenrolls the respective TPMs’ AIKs by issuing a signed AIKcertificate. We assume that TTP has access to an accesscontrol list (ACL) describing access and ownership relationsbetween DM and D. Furtermore, TTP communicates withCH to exchange integrity attestation data, authenticationtokens and cryptographic keys. TTP can attest platformintegrity based on the integrity attestation quotes and thevalid AIK certificate from a TPM, and seal data to a trustedhost configuration. Finally, TTP can verify the authenticityof DM and perform necessary cryptographic operations.In this paper, we treat the TTP as a “black box” with alimited, well-defined functionality, and omit its internals.Availability of the TTP is essential in the cloud scenario – werefer the reader to the rich body of work on fault tolerancefor approaches to building highly available systems.



7

Secure Component (SC): this is a verifiable execu-tion module performing confidentiality and integrity pro-tection operations on VM guest data. SC is present on allCH and is responsible for enforcing the protocol; it acts asa mediator between the DM and the TTP and forwards therequests from DM to either the TTP or the disk encryptionsubsystem. SC must be placed in an isolated executionenvironment, as in the approaches presented in [25], [26].

4.3 Trusted Launch ConstructionWe now present our construction for the TL, with four par-ticipating entities: domain manager, secure component, trustedthird party and cloud provider (with the ‘scheduler’ as partof it). TL comprises a public-key encryption scheme, asignature scheme and a token generator. Figure 2 shows theprotocol message flow (some details omitted for clarity).

TL.Setup : Each entity obtains a public/private key pairand publishes its public key. Below we provide the list ofkey pairs used in the following protocol:

• (pkDMi , skDMi ) – public/private key pair for DMi;• (pkTTP, skTTP) – public/private key pair for TTP;• (pkTPM, skTPM) – TPM bind key pair;• (pkAIK, skAIK) – TPM attestation identity key pair;

TL.Token : To launch a new VM instance vmil , DMi

generates a token by executing τ = RAND(n) andcalculates the hash (H1) of the VM image (vmi

l) in-tended for launch, the hash (H2) of pkDMi , and the re-quired security profile SPi. Finally, Di

vmil

describes theset of domains that vmi

l with the identifier idvmil shall

have access to; the six elements are concatenated into:m1 =

{τ ‖H1 ‖H2 ‖SPi‖idvmi

l‖Divmi

l

}. DMi encrypts m1

with pkTTP by running c1 = EncpkTTP (m1).Next, DMi generates a random nonce r and sends the

following arguments to initiate a trusted VM launch proce-dure: 〈c1, SPi, pkDMi , r〉, where c1 is the encrypted messagegenerated in TL.Token, SPi is the requested security profileand pkDMi is the public key of DMi. The message is signedwith skDMi , producing σDMi

. Upon reception, the schedulerassigns the VM launch to an appropriate host with a securityprofile SPi, e.g. host CHi. In all further steps, the noncer and the signature of the message are used to verify thefreshness of the received messages.

Upon reception, SC verifies message integrity andTL.Token freshness by checking respectively the signatureσDMi

and nonce r. When SC first receives a TL.Request mes-sage, it uses the local TPM to generate a new pair of TPM-based public/private bind keys, (pkTPM, skTPM), which canbe reused for future launch requests, to avoid the costly keygeneration procedure. Keys can be periodically regeneratedaccording to a cloud provider-defined policy. To prove thatthe bind keys are non-migratable, PCR-locked, public/pri-vate TPM keys, SC retrieves the TPM_CERTIFY_INFO struc-ture, signed with the TPM attestation identity key pkAIK [29]using the TPM_CERTIFY_KEY TPM command; we denotethis signed structure by σTCI. TPM_CERTIFY_INFO containsthe bind key hash and the PCR value required to use thekey; PCR values must not necessarily be in a trusted state tocreate a trusted bind key pair. This mechanism is explainedin further detail in [19].

Next, SC sends an attestation request (TL.AttestRequest)to the TTP, containing the encrypted message (c1) generatedby DMi in TL.Token, the nonce r and the attestation data(AttestData), used by the TTP to evaluate the security profileof CHi and generate the corresponding TPM bind keys.SC also requests the TPM to sign the message with skAIK,producing σAIK . AttestData includes the following:

- the public TPM bind key pkTPM;- the TPM_CERTIFY_INFO structure;- σTCI : signature ofTPM_CERTIFY_INFO using skAIK;- IML, the integrity measurement list;- the TCI-certificate;

Upon reception, TTP verifies the integrity and freshness ofTL.AttestRequest, checking respectively the signature σAIK

and nonce r. Next, TTP verifies – according to its ACL – theset Di

vmil

to ensure that DMi is authorised to allow accessto the requested domains for vmi

l and decrypts the messagem1 := DecskTTP (c1), decomposing it into τ, H1, H2, SPi.Finally, TTP runs an attestation scheme to validate thereceived attestation information and generate a new attes-tation token.

Definition 6 (Attestation Scheme). An attestation scheme,denoted by TL.Attestation, is defined by two algorithms(AttestVerify,AttestToken) such that:

1. AttestVerify is a deterministic algorithm that takesas input the encrypted message from the requestingDMi and attestation data, 〈c1, AttestData〉, and out-puts a result bit b. If the attestation result is posi-tive, b = 1; otherwise, b = 0. We denote this byb := AttestVerify(c1, σAIK , AttestData).

2. AttestToken is a probabilistic algorithm that pro-duces a TPM-sealed attestation token. The input ofthe algorithm is the result of AttestVerify, the mes-sage m to be sealed and the CH AttestData. IfAttestVerify evaluates to b = 1, the algorithm out-puts an encrypted message c2. We write this asc2 ← AttestToken(b,m,AttestData). Otherwise, ifAttestVerify evaluates to b = 0, AttestToken returns ⊥.

In the attestation step, TTP first runs AttestVerifyto determine the trustworthiness of the target CHi. InAttestVerify, TTP verifies the signature σTCI and σAIK

against a valid AIK certificate contained in AttestDataand examines the entries provided in the IML. AttestVerifyreturns b = 0 and TTP exits the protocol if the entries differfrom values expected for the security profile SPi. Other-wise, AttestVerify returns b = 1 and TTP runs AttestTokento generate a new encrypted attestation token for CHi.Having verified that the entries in IML conform to thesecurity profile SPi, TTP generates a symmetric domainencryption key, DKi, to protect the communication be-tween the SC and TTP in future exchanges. Finally, TTPseals m2 =

{τ‖H1‖H2‖DKi‖idvmi

l

}to the trusted plat-

form configuration of CHi, using the key pkTPM receivedthrough the attestation request. The encrypted message(c2 ← AttestToken(b,m2, AttestData), r), along with asignature (σTTP ) produced using skTTP is returned to SC.

Upon reception, SC checks the message integrity andfreshness before unsealing it using the corresponding TPMbind key skTPM. The encrypted message is unsealed to the



8

DM VM SC TTP

⟨c1 =

{τ‖H1‖H2‖SPi‖idvmi

l‖Divmi

l

}pkTTP

, SPi, pkDMi, r, σDMi

⟩TL.RequestTL.Request

〈c1, AttestData, r, σAIK〉

TL.AttestRequestTL.AttestRequest

⟨c2 =

{τ‖H1‖H2‖DKi‖idvmi

l

}pkTPM

, r, σTTP

⟩TL.Attestation(TL.AttestVerify,TL.AttestToken)TL.Attestation(TL.AttestVerify,TL.AttestToken)

Inject token τ

Challenge token τ

Response Token

Token InjectionToken Injection

Fig. 2. Message Flow in the Trusted VM Launch Protocol.

plain text m2 ={τ‖H1‖H2‖DKi‖idvmi

l

}only if the plat-

form state of CHi has remained unchanged. SC calculatesthe hash (H ′1) of the VM image supplied for launch andverifies that its identifier matches the expected identifieridvmi

l ; SC also calculates the hash of pkDMi received fromthe cloud provider, denoted by H ′2. Finally, SC verifies thatH1 = H ′1 and only in that case injects τ into the VMimage. Likewise, SC verifies that the public key registeredby DMi with the cloud provider in step TL.Setup has notbeen altered, i.e.H2 = H ′2 and only in that case injects pkDMi

into the VM image prior to launching it.In the last protocol step, DMi verifies that vmi

l has beenlaunched on a trusted platform with security profile SPi,while vmi

l verifies the authenticity of DMi. This is doneby establishing a secure pre-shared key TLS session [31]between vmi

l and DMi using τ as the pre-shared secret.

4.4 Domain-Based Storage Protection Construction

We now continue with a description of the DBSP protocol.Along with three of the entities already active in the TL

protocol – domain manager, secure component, the trusted thirdparty – DBSP employs a fourth one: the storage resource. Inthis case, DMi interacts with the other protocol componentsthrough a VM instance vmi

l running on CHi. We assumethat vmi

l has been launched following the TL protocol. TheDBSP protocol includes a public and a private encryptionscheme, a pseudorandom function for domain key genera-tion, a signature scheme and a random generator. Figure 3presents the DBSP protocol mesage flow.

DBSP.Setup: We assume that in TL.Setup, each entityhas obtained a public/private key pair and published pk.

Assume DMi requests access for a certain VM vmil to a

storage resource SRi in the domainDik ∈ Di

vmil. The request

is intercepted by the SC, which proceeds to retrieve fromTTP a symmetric encryption key for the domain Di

k.DBSP.DomKeyReq: SC sends to TTP a request to gen-

erate keys for the domain Dik. The request contains the

target storage resource SRi, hash H2 of pkDMi , the noncer and metaik, containing the unique domain identifier andthe security profile required to access the domain Di

k, i.e.,metaik =

{Di

k, SPi

}pkTTP

; SC uses the symmetric key DKi

received during TL.Attestation to protect message confiden-tiality, and the local TPM to sign the message with skAIK,producing σAIK (see DBSP.DomKeyReq in Figure 3).

Upon the reception of DBSP.DomKeyReq, TTP verifiesthe freshness and integrity of the request and proceedsto the next protocol step, DBSP.DomKeyGen, only if thisverification succeeds.

DBSP.DomKeyGen: A probabilistic algorithm enablingTTP to generate a symmetric encryption key (Ki

k) andintegrity key (IKi

k) for a domain Dik. TTP generates a

nonce using a random message mi ∈ {0, 1}n by executingni = RAND (mi). Next, TTP uses a PRF to generate the keysfor domain Di

k, by evaluating the following:

Kik = PRF

(KTTP , D

ik‖SPi‖ni

),

IKik = PRF

(KTTP , D

ik‖ni

),

where KTTP is a master key that does not leave the security



9

SR SC TTP

⟨{SRi, H2,metaik, AttestData, r

}DKi

, σAIK

⟩DBSP.DomKeyReqDBSP.DomKeyReq Request to generate keys for the domain Dik

⟨{c3, c4, µik,meta

ik, r}, σTTP

⟩DBSP.DomKeyGenDBSP.DomKeyGen Verifies the state of CH & generates Kik, IKi

k

⟨metaik, c4, µ

ik

⟩to the header of the domain

WriteDBSPHeader to Storage Resource

Unlock Volume by releasing Kik

Fig. 3. Message Flow in the Domain-Based Storage Protection Protocol.

perimeter of TTP, Kik is a symmetric encryption key to

confidentiality protect the data and IKik a symmetric key

to verify the integrity of the stored data.TTP seals Ki

k and IKik to the trusted configuration of

CHi by calculating c3 = EncpkTPM(Ki

k‖IKik

). TTP encrypts

the generated nonce ni and the provided security profileSPi by evaluating c4 = EncKTTP

(ni‖SPi) to later use itfor verification. Next, TTP generates a message authenti-cation code µ by evaluating µi

k = MAC(KTTP , ni‖SPi).The domain key generation algorithm is denoted by(c3, c4, µ

ik

)← DBSP.DomKeyGen(ni,KTTP , skTPM).

Having generated the domain key, TTP responds to theDBSP.DomKeyReq by sending

{c3, c4, µ

ik,meta

ik, r}

withthe signature σTTP . Upon reception, SC first verifies mes-sage integrity and freshness, and calls the local TPM tounseal c3, producing Ki

k‖IKik if and only if CHi remains

in the earlier trusted state. Next, SC stores metaik, c4 andµik in the domain header and uses Ki

k, IKik as inputs to

the disk encryption subsystem on CHi, which decrypts andverifies the data integrity of the mounted volume hostingDi

k before providing plain text access to vmil .

To recreate the encryption and integrity keys for the do-main Di

k, SC sends a request similar to DBSP.DomKeyReq,adding to the message the values c4 and µi

k, which arestored in the domain header. Upon reception, TTP veri-fies the integrity of the received value c4 by calculatingµik = MAC(KTTP , ni‖SPi). If the integrity verification ofc4 is positive, TTP decrypts it to ni‖SPi = DecskTTP (c4) andcalculates the domain key as in DBSP.DomKeyGen, usingthe existing token ni instead of generating a new one4.

5 SECURITY ANALYSIS

We now analyse the TL and DBSP protocols in the presenceof an adversary. We prove the security of both schemes

4Key retrieval is currently not covered in the security analysis dueto space limitations

through a theoretical analysis, showing that our protocolsare resistant to the attacks presented in Section 3.3.

Proposition 1 (VM Substitution Soundness). The TL proto-col is sound against the VM substitution attack.

Proof : An adversary ADV trying to launch vm 6= vmil on

CH can only get vm accepted by DMi if the last mutualauthentication step in the trusted launch procedure is suc-cessful. In turn, this step only succeeds if at least one of thefollowing two options is true:

a. The secure component SC uses a different token, τ ′ 6= τaccepted by DMi in the final secure channel establish-ment.

b. The secure component SC on CH uses the very sametoken τ used by DMi when launching vmi

l .

Option a can only succeed if ADV can break the mutualauthentication in the secure channel setting. Given that theselected secure channel scheme is sound and τ is sufficientlylong and selected using a sound random generation process,theADV fails to break the last protocol step. Hence, as longas the secure channel protocol is sound, the overall protocolconstruction is also sound against this attack option.

Option b can only succeed if the adversary either man-ages to guess a value τ ′ = τ when launching vm or managesto either obtain τ when DMi launches vmi

l or replace theassociation between τ and vmi

l with an association betweenτ and vm when DMi launches vmi

l , by attacking any ofthe protocol steps preceding the final mutual authenticationstep. A successful attack in this case has the probabilityτ ′ = τ equals to 1/2n, where n is the length of the tokenvalue and is infeasible if n is large enough. Below, we showwhy the adversary also fails with respect to the last option.

• TL.Token. Assume the adversary intercepts theTL.Token message. Then the adversary has two op-tions: she might either try to modify the TL.Token



10

message (option 1) with the goal to replace the as-sociation between τ and the vmi

l with τ and vm,or she might try obtain the secret value τ (option2) and then launch vm with this τ value on anarbitrary valid provider platform. We discuss boththese options below.

- TL.Token Option 1: A modification can onlybe achieved by the adversary by either break-ing the public key encryption scheme usedto produce c1 or trying to make this modifi-cation on c1 by direct modification (withoutfirst decrypting it) and sign the modified c1with an own selected private key. The formeroption fails due to the assumption of publickey encryption scheme soundness and the lat-ter due to that modifying a public encryptedstructure without knowledge of the privatekey is infeasible.

- TL.Token Option 2: Direct decryption of c1 failsdue to the assumption of soundness of thepublic key encryption scheme used to pro-duce c1. The only remaining alternative forthe adversary is relaying the TL.Token to aplatform CH ′ ∈ CHSPi

, which is under thefull control of the adversary. Further, ADVfollows the protocol and issues the commandTL.AttestRequest using the intercepted c1, At-testData and σAIK . However, this fails at theTL.Attestation step since AttestData does notcontain a valid AIK certificate unless the ad-versary has managed to get control of a validplatform in the provider network with a validcertificate or she has managed to break the AIKcertification scheme. The former option vio-lates the assumption of physical security of theprovider computing resources while the latteroption violates the assumption of a soundpublic key and AIK certification schemes.

• TL.AttestRequest. The adversary could either try toimpersonate this message with the goal of obtainingτ or the association between τ and vmi

l . This im-personation attempt fails as the whole sent structureis signed with the pkAIK with a secure public keysigning scheme. Furthermore, attempts to resend anold valid TL.AtttestRequest fail as the H1 verificationthat the SC receives in return fails as it does pointon the old VM. Similarly, any attempts to modifyTL.AttestRequest fail as the whole structure is signedwith a secure signature scheme.

• TL.Attestation. Any attempt by the adversary toobtain τ would be equal to breaking the public keyencryption of TL.AttestToken. Similarly, any attemptto modify c2 fails due to the fact that modification ofa public encrypted structure without knowledge ofthe private key is unfeasible if the public key encryp-tion scheme is sound. Any attempt by the adversaryto replace an old recorded valid TL.AttestToken mes-sage fails as such messages do contain a VM imagehash H1 different than the one expected by the SC. �

Proposition 2 (CH Substitution Soundness). The TL proto-col is sound against the CH substitution attack.

Proof : DMi intends to launch a virtual machine vmil on an

arbitrary compute host CHi with a security profile SPi. Anadversary ADV trying to launch vmi

l on CHj ∈ CHSPj,

SPj 6= SPi, can only get vmil accepted by DMi if the last

mutual authentication step in the trusted launch procedureis successful. In turn, this step can only succeed if at leastone of the following two options is true:

a. The secure component SC is using a different token,τ ′ 6= τ that is accepted by DMi in the final securechannel establishment.

b. The secure component SC on CHj is using the verysame token τ used by DMi when launching vmi

l .Option a is impossible as proved in Proposition 1. Option

b can only succeed if the adversary either manages to guessa value τ ′ = τ when launching vmi

l or manages to inducethe TTP to seal the token τ to the configuration of CHj .Finding τ ′ = τ is infeasible for the adversary as shown inProposition 1. Below, we show why the adversary also failswith respect to the second option.

Assume ADV intercepts the TL.Token message. Then ithas two options: either attempt to launch vmi

l on a computehost CHj /∈ CHSPi

or on CHj ∈ CHSPi.

- TL.Token CHj /∈ CHSPi: The ADV can replace

the following information from the TL.Token mes-sage: SPi with SPj , pkDMi with pkADV , which isa public key generated by the ADV and σc1 withσADV = SignskADV (c1). By doing this, she cansuccessfully proceed beyond the TL.AttestRequeststep since SC is not able to detect the substitution.However, this attack fails at the TL.Attestation stepsince the AttestData sent to the TTP evaluates to asecurity profile SPj 6= SPi in contradiction with thepreference of DMi contained in c1.

- TL.Token CHj ∈ CHSPi: The ADV can replace the

following information from the TL.Token message:pkDMi with pkADV , which is a public key generatedby the ADV and σc1 with σADV = SignskADV (c1).By doing this, he can successfully proceed beyondthe TL.AttestRequest step since SC is unable to de-tect the substitution. However, this attack fails atthe TL.Attestation step since the pkAIK key used toproduce the signature σAIK is not among the keysenrolled with the TTP according to Section 4.2.

The cases of TL.AttestRequest and TL.Attestation fail asdemonstrated in Proposition 1. �

Proposition 3 (Combined VM and CH Substitution Sound-ness). The TL protocol is sound against the VM and CHsubstitution attack.

Proof : The exculpability of the VM substitution attack andthe CH substitution attack implies that the TL protocolis secure against the combined VM and CH substitutionattack. �

Proposition 4 (Storage CH Substitution Soundness). TheDBSP protocol is sound against the storage CH attack.

Proof : Adversary ADV can only succeed with a storage CHsubstitution attack if she manages to launch a VM instance



11

vmil 7→ CHi, CHi ∈ CHSPi

on a host CHj ∈ CHSPj,

SPj 6= SPi andDivmi

l∩Dj

vmil6= ∅. This can only be achieved

if she requests launch of vmil on a platform with profile

SPj . According to Proposition 2 and Proposition 3, suchlaunch requests are rejected by DMi; however, this doesnot prevent the ADV from attempting these options. Thefollowing two alternatives are available to the adversary:

a. TheADV launches vmil 7→ CHj on a platform under

its own control (i.e. outside the provider domain).b. The ADV launches vmi

l 7→ CHj on a valid platformin the provider network.

Option a: This option implies that the TL.AttestRequeststep fails as shown in the proof of Proposition 1. In this case,the platform controlled byADV does not get the symmetrickey DKi in return to the attestation request. Without accessto DKi, the only remaining option for the adversary is toattempt to break the final key request or the disc encryptionscheme. Thus the following options are available:

• DBSP.DomKeyReq : The first option is to intercepta valid DBSP.DomKeyReq message for a storagedomain Di

k ∈ Divmi

land replace the intercepted sig-

nature σAIK with her own own signature, σ′AIK overthe very same encrypted request (encrypted with avalid DKi). However, similar to the earlier attemptto perform a TL.AttestRequest, this fails since theADV does not have access to a valid attestationkey. Any other attempt to send the adversary’s ownDBSP.DomKeyReq fails for the same reason.

• DBSP.DomKeyGen : The remaining option is toobserve a valid DBSP.DomKeyGen for a domainDi

k ∈ Divmi

land attempt to access the encrypted stor-

age keys. The latter fails due to the assumption of theTPM public key scheme soundness.

• Attack Storage Encryption Scheme: The remaining op-tion for the ADV in this case is to directly break thedisc encryption scheme. However, this is infeasibleaccording to the disc encryption scheme soundness.

Option b: According to this option, the ADV tries launchingvmi

l using TL.Token on a platform with profile SPj using itsown credentials. The following impersonation alternativesare available:

• Own token: The adversary ADV sends a TL.Tokenmessage required by the protocol:EncpkTTP

(τ ‖ H1 ‖ H2 ‖ SPj ‖ idvmi

l ‖ Divmi

l

), SPj ,

pkADV , r, σADV , where H2 either is the hash of pkDMi

or the hash of pkADV . If the first option is used,the SC obtains in return to TL.AttestRequest, i.e.the TL.Attestation message, a sealed value with ahash H ′2 6= H2 which causes the SC to abort thelaunch. If the second option is used, the completelaunch procedure succeeds as expected. However,when the SC later requests the key for SRi using theDBSP.DomKeyReq message, it includes the hash H2

of the the ADV public key (pkADV ) in the encryptedand signed request. ADV cannot change the hashvalue in this request unless she breaks the signaturescheme of the request. Upon receiving the request,

TTP identifies that ADV is not allowed to accessDi

k ∈ Divmi

land does not return the storage keys in

DBSP.DomKeyGen.• Legitimate token: In this option, the ADV observes a

valid c1 in TL.Token for another vmwith access rightsto the intended domain and uses it to launch an ownvalid TL.Token message: c1, SPj , pkADV , r, σADV .However, in this case the TL.AttestRequest fails asthe profile in c1 does not match the platform at-tested data. Furthermore, if the SC receives a replyto TL.AttestRequest, i.e. a TL.Attestation message, itwould receive a sealed value with a hash H ′2 6= H2,causing the SC to abort the launch. �

Proposition 5 (Domain Violation Attack). The DBSP pro-tocol is sound against the domain violation attack.

Proof : Similar to the proof of Proposition 4, ADV has thefollowing two options:

a. The ADV launches vmjm 7→ CHj on a platform

under its control (i.e. outside the provider domain).b. The ADV launches vmj

m 7→ CHj on a valid plat-form in the provider network.

Option a: This option fails in analogy with the proof ofProposition 4, as ADV fails to successfully launch vmj

m

and her remaining options are to either attack the final keyrequest or the disc encryption scheme, which both fail (seeproof of Proposition 4).

Option b: In analogy with the proof of Proposi-tion 4, ADV has only two options available: a fullimpersonation with an own chosen token of typeEncpkTTP

(τ ‖H1 ‖H2 ‖SPj‖idvmj

m‖Dj

vmjm

), SPj , pkADV ,

r, σADV , Dj

vmjm⊆ Di, or a partial impersonation reusing

an observed c1 of type c1, SPj , pkADV , r, σADV for a subsetof target storage domain. Both options fail in analogy withthe arguments presented for the proof of Proposition 4. �

6 IMPLEMENTATION AND RESULTS

We next describe the implementation of the TL and DBSPprotocols followed by experimental evaluation results.

6.1 Test bed Architecture

We describe the infrastructure of the prototype and thearchitecture of a distributed EHR system installed and con-figured over multiple VM instances running on the test bed.

6.1.1 Infrastructure Description

The test bed resides on four Dell PowerEdge R320 hostsconnected on a Cisco Catalyst 2960 switch with 801.2qsupport. We used Linux CentOS, kernel version 2.6.32-358.123.2.openstack.el6.x86 64 and the OpenStack IaaS plat-form5 (version Icehouse) using KVM virtualization support.The prototype IaaS includes one “controller” running essen-tial platform services (scheduler, PKI components, SDN con-trol plane, VM image storage, etc.) and three compute hostsrunning the VM guests. The topology of the prototype SDN



12

Compute hostLocal cloud platform services

nova-api nova-scheduler nova-compute

OperatingSystem

Hardware NIC

TCP/IP

VT-x

KVM

iSCSI-initiator

TPM

SC

libvirt-hook

dm-crypt

libvirt

QEMU

VM 1

Storage host

* Remote host attestation* Key management

Trusted Third Part

Fig. 4. Placement of the SC in the prototype implementation.

reflects three larger domains of the application-level de-ployment (front-end, back-end and database components)in three virtual LAN (VLAN) networks.

The compute hosts use libvirt6 for virtualization func-tionality. We modified libvirt 1.0.2 and used the “libvirt-hooks” infrastructure to implement the SC for the TL andDBSP protocols. SC unlocks the volumes on compute hostsand interacts with the TPM and TTP (see Figure 4). Ituses a generic server architecture where the SC daemonhandles each request in a separate process. An inter processcommunication (IPC) protocol defines the types of messagesprocessed by the SC. The IPC protocol uses sychronouscalls with several types of requests for the respective SCoperations; the response contains the exit code and responsedata. A detailed architecture of SC, including the mainlibraries that it relies on, is presented in Figure 5.

libvirt

nova-compute

TPM trousers

libcryptsetup dm-cryptTTPClient

IPCEndpoint

MetadataController

SCCore

StorageHost

UserVM

KernelCode

IPCInitiator

Trusted Third Party

Fig. 5. Close-up view of the secure component implementation architec-ture, presented as a combination of components and existing libraries.

6.1.2 Application DescriptionThe prototype also includes a distributed EHR systemdeployed over seven VM instances. This system containsone client VM, two front-end VMs, two back-end VMs,a database VM and an auxiliary external database VM.Six of the VM instances operate on Microsoft WindowsServer 2012 R2, with one VM running the client applicationoperates on Windows 7. The components of the EHR systemcommunicate using statically defined IP addresses on therespective VLANS described in Section 6.1.1. Load balanc-ing functionality provided by the underlying IaaS allots theload among front-end and back-end VM pairs. The hostsof the cluster are compatible with the TL protocol, whichallows an infrastructure administrator to perform a trusted

5OpenStack project website: https://www.openstack.org/6Libvirt website: http://libvirt.org/

TABLE 1Overhead for unlocking a volume with DBSP (all times in ms)

Process Event TimeQEMU Begin handle unlock request 0.083SC Requesting key from TTP 0.609SC Unseal key in TPM 2700.870SC Unlocking volume with cryptsetup 11.834QEMU End handle unlock request 26

TOTAL 2714.004

launch of VM instances on qualified hosts. Similarly, theinfrastructure administrator can apply the DBSP protocol toprotect sensitive information stored on the database servers.

6.2 Performance evaluation

0 20 40 60 80 100

VM Launch number

10000

12000

14000

16000

18000

20000

22000

Duration,ms

Trusted VM launch

Vanilla VM launch

Fig. 6. Overhead induced by the TL protocol during VM instantiations.

Trusted launch: Figure 6 shows the duration of a VMlaunch over 100 successful instantiations: the TL protocolextends the duration of the VM instantiation (which doesnot include the OS boot time) on average by 28%. However,in our experiments we have used a minimalistic VM image(13.2 MB), based on CirrOS 7, while launching larger VMimages takes significantly more time and proportionallyreduces the overhead induced by TL.

DBSP Processing time: Table 1 shows a breakdown ofthe time required to process a storage unlock request, anaverage of 10 executions. Processing a volume unlock re-quest on the prototype returns in ≈2.714 seconds; however,this operation is performed only when attaching the volumeto a VM instance and does not affect the subsequent I/Ooperations on the volume. A closer view highlights the shareof the contributing components in the overall overheadcomposition. Table 1 clearly shows that the TPM unsealoperation lasts on average ≈2.7 seconds, or 99.516% of theexecution time. According to Section 4.2, in this prototypewe use TPMs v1.2, since a TPM v2.0 is not available oncommodity platforms at the time of writing. Given that thevast majority of the execution time is spent in the TPMunseal operation, implementing the protocol with a TPMv2.0 may yield improved results.

DBSP Encryption Overhead: Next, we examine theprocessing overhead introduced by the DBSP protocol.

7CirrOS project website: https://launchpad.net/cirros

https://www.openstack.org/



13

Figure 7 presents the results of a disk performance bench-mark obtained using IOmeter8. To measure the effect ofbackground disk encryption with DBSP, we attached twovirtual disks to a deployed server VM described in 6.1.2. Thestorage volumes were physically located on a different hostand communicating over iSCSI. We ran a benchmark withtwo parallel workers on the plaintext and DBSP-encryptedvolumes over 12 hours. Next, we disabled in the host BIOSthe AES-NI acceleration, created and attached a new volumeto the VM and reran the benchmark. This has producedthree performance data result sets: plaintext, DBSP en-cryption and DBSP encryption with AES-NI acceleration.Figure 7 summarises the total IO, read IO and write IO results.It is visible that the measurements ‘4 KiB aligned (DBSP) withAES-NI’ and ‘1 MiB (DBSP) with AES-NI’ are roughly on parwith the plaintext baseline: ‘4 KiB aligned’ and ‘1 MiB’. Theperformance overhead induced by background encryptionis at 1.18% for read IO and 0.95% for write IO. We canexpect that this performance penalty will be further reducedas the hardware support for encryption is improved. Diskencryption without hardware acceleration (‘4 KiB aligned(DBSP)’ and ‘1 MiB (DBSP)’) is significantly slower, asexpected, with a performance penalty of respectively 49.22%and 42.19% (total IO). It is important to reemphasize that theruntime performance penalty is determined exclusively bythe performance of the disk encryption subsystem. DBSPonly affects the time required to unlock the volume when itis attached to the VM instance, as presented in Table 1.

0

20

40

60

80

100

120

140

160

180

4 KiB aligned 1 MiB 4 KiB aligned(DBSP)

1 MiB (DBSP) 4 KiB aligned(DBSP) w. AES-NI

1 MiB (DBSP) w.AES-NI

Iops

Read Iops

Write Iops

Fig. 7. Benchmarks results on identical drives: plaintext, with DBSP, withDBSP and AES-NI acceleration.

7 APPLICATION DOMAIN

The presented results are based on work in collaborationwith a regional public healthcare authority to address someof its concerns regarding IaaS security. We have deployedthe prototype described in Section 6, further extended byintegrating a medication database, and evaluated it throughend-user validation and performance tests. Our resultsdemonstrate that it is both possible and practical to providestrong platform software integrity guarantees to IaaS ten-ants and efficiently isolate their data using established cryp-tographic tools. Platform integrity guarantees allow tenantsto take better decisions on both workload migration to thecloud and workload placement within IaaS. This contrastswith the current, “flat” trust model, where all IaaS hostsdeclare the same – but unverifiable for the tenant – trust level.

8IOmeter project website: http://iometer.org

An essential conclusion of this practical exercise is thatthe additional cost of providing security guarantees can beeffectively offset by composing cloud services from differentcompeting providers, without having to delegate the trustamong these providers. Thus, in our cloud model the ten-ant can purchase cheaper cloud disk storage without anyadditional risk for data confidentiality.

Another conclusion is that while organizations operatingon sensitive data, e.g. public healthcare authorities, considerthe risks of migrating data to IaaS clouds as unacceptable,the majority of available providers use commercial-off-the-shelf (COTS) cloud platforms with limited capabilities toenhance the security of their deployments, failing to meetthe customer requirements. This demonstrates the need toincorporate integrity verification and data protection mech-anisms into popular COTS cloud platforms by default. Wehope that these important lessons will inspire new secure,usable and cost-effective solutions for cloud services.

On the practical side, specifically regarding the role ofthe TTP, we envision two scenarios. The TTP could either bemanaged by the tenant itself (for organizations with enoughresources and expertise), or by an external organization(similar to a certificate authority). The first scenario allowsthe tenant to retain the benefits of cloud services alongwith additional security guarantees. Similarly, in the secondscenario, smaller actors can obtain the same benefits withoutthe need to invest into own attestation infrastructure. Inboth scenarios, in order to protect the cloud provider theTTP would only operate on a physical slice of the resources(i.e. a subset of compute hosts) that correspond to therespective tenant domains.

8 CONCLUSION

From a tenant point of view, the cloud security modeldoes not yet hold against threat models developed for thetraditional model where the hosts are operated and used bythe same organization. However, there is a steady progresstowards strengthening the IaaS security model. In thiswork we presented a framework for trusted infrastructurecloud deployment, with two focus points: VM deploymenton trusted compute hosts and domain-based protection ofstored data. We described in detail the design, implemen-tation and security evaluation of protocols for trusted VMlaunch and domain-based storage protection. The solutionsare based on requirements elicited by a public healthcareauthority, have been implemented in a popular open-sourceIaaS platform and tested on a prototype deployment of adistributed EHR system. In the security analysis, we intro-duced a series of attacks and proved that the protocols holdin the specified threat model. To obtain further confidencein the semantic security properties of the protocols, we havemodelled and verified them with ProVerif [32]. Finally, ourperformance tests have shown that the protocols introducea insignificant performance overhead.

This work has covered only a fraction of the IaaS attacklandscape. Important topics for future work are strength-ening the trust model in cloud network communications,data geolocation [33], and applying searchable encryptionschemes to create secure cloud storage mechanisms. Our re-sults show that it is possible and practical to provide strong

http://iometer.org



14

platform software integrity guarantees for tenants and ef-ficiently isolate their data using established cryptographictools. With reasonable engineering effort the framework canbe integrated into production environments to strengthentheir security properties.

REFERENCES

[1] N. Santos, K. P. Gummadi, and R. Rodrigues, “Towards trustedcloud computing,” in Proceedings of the 2009 Conference on HotTopics in Cloud Computing, HotCloud’09, (Berkeley, CA, USA),USENIX Association, 2009.

[2] J. Schiffman, T. Moyer, H. Vijayakumar, T. Jaeger, and P. McDaniel,“Seeding Clouds With Trust Anchors,” in Proceedings of the 2010ACM Workshop on Cloud Computing Security, CCSW ’10, (NewYork, NY, USA), pp. 43–46, ACM, 2010.

[3] N. Paladi, A. Michalas, and C. Gehrmann, “Domain based storageprotection with secure access control for the cloud,” in Proceedingsof the 2014 International Workshop on Security in Cloud Computing,ASIACCS ’14, (New York, NY, USA), ACM, 2014.

[4] M. Jordon, “Cleaning up dirty disks in the cloud,” Network Secu-rity, vol. 2012, no. 10, pp. 12–15, 2012.

[5] Cloud Security Alliance, “The notorious nine cloud computing topthreats 2013,” February 2013.

[6] A. Michalas, N. Paladi, and C. Gehrmann, “Security aspects ofe-health systems migration to the cloud,” in the 16th InternationalConference on E-health Networking, Application & Services (Health-com’14), pp. 228–232, IEEE, Oct 2014.

[7] B. Bertholon, S. Varrette, and P. Bouvry, “Certicloud: a novel tpm-based approach to ensure cloud IaaS security,” in Cloud Computing,2011 IEEE International Conference on, pp. 121–130, IEEE, 2011.

[8] M. Aslam, C. Gehrmann, L. Rasmusson, and M. Bjorkman, “Se-curely launching virtual machines on trustworthy platforms in apublic cloud - an enterprise’s perspective.,” in CLOSER, pp. 511–521, SciTePress, 2012.

[9] A. Cooper and A. Martin, “Towards a secure, tamper-proof gridplatform,” in Cluster Computing and the Grid, 2006. CCGRID 06.Sixth IEEE International Symposium on, vol. 1, pp. 8–pp, IEEE, 2006.

[10] W. Wang, Z. Li, R. Owens, and B. Bhargava, “Secure and efficientaccess to outsourced data,” in Proceedings of the 2009 ACM workshopon Cloud computing security, pp. 55–66, ACM, 2009.

[11] D. Song, E. Shi, I. Fischer, and U. Shankar, “Cloud data protectionfor the masses,” IEEE Computer, vol. 45, no. 1, pp. 39–45, 2012.

[12] S. Graf, P. Lang, S. A. Hohenadel, and M. Waldvogel, “Versatilekey management for secure cloud storage,” in Proceedings of the2012 IEEE 31st Symposium on Reliable Distributed Systems, pp. 469–474, IEEE Computer Society, 2012.

[13] N. Santos, R. Rodrigues, K. P. Gummadi, and S. Saroiu, “Policy-Sealed Data: A New Abstraction for Building Trusted Cloud Ser-vices,” in Presented as part of the 21st USENIX Security Symposium(USENIX Security 12), (Bellevue, WA), pp. 175–188, USENIX, 2012.

[14] A.-R. Sadeghi and C. Stuble, “Property-based attestation for com-puting platforms: Caring about properties, not mechanisms,” inProceedings of the 2004 Workshop on New Security Paradigms, NSPW’04, (New York, NY, USA), pp. 67–77, ACM, 2004.

[15] A. Sahai, “Ciphertext-policy attribute-based encryption,” in InProceedings of the IEEE Symposium on Security and Privacy, 2007.

[16] S. Kamara and K. Lauter, “Cryptographic cloud storage,” in Fi-nancial Cryptography and Data Security, vol. 6054 of Lecture Notes inComputer Science, pp. 136–149, Springer Berlin Heidelberg, 2010.

[17] A. Sahai and B. Waters, “Fuzzy identity-based encryption,” inAdvances in Cryptology–EUROCRYPT 2005, Springer, 2005.

[18] S. Kamara and C. Papamanthou, “Parallel and dynamic searchablesymmetric encryption,” in Financial Cryptography and Data Security,pp. 258–274, Springer, 2013.

[19] N. Paladi, C. Gehrmann, M. Aslam, and F. Morenius, “TrustedLaunch of Virtual Machine Instances in Public IaaS Environ-ments,” in Information Security and Cryptology (ICISC’12), vol. 7839of Lecture Notes in Computer Science, pp. 309–323, Springer, 2013.

[20] N. Paladi, C. Gehrmann, and F. Morenius, “Domain-Based StorageProtection (DBSP) in Public Infrastructure Clouds,” in Secure ITSystems, pp. 279–296, Springer, 2013.

[21] P. Mell and T. Gance, “The NIST Definition of Cloud Computing,”tech. rep., National Institute of Standards and Technology, 2011.

[22] C. Waldspurger and M. Rosenblum, “I/O virtualization,” Commu-nications of the ACM, vol. 55, no. 1, pp. 66–73, 2012.

[23] D. Dolev and A. C. Yao, “On the security of public key protocols,”Information Theory, IEEE Transactions on, vol. 29, no. 2, 1983.

[24] T. Garfinkel, B. Pfaff, J. Chow, M. Rosenblum, and D. Boneh,“Terra: A virtual machine-based platform for trusted computing,”in ACM SIGOPS Operating Systems Review, vol. 37, ACM, 2003.

[25] A. Seshadri, M. Luk, N. Qu, and A. Perrig, “SecVisor: A tiny hy-pervisor to provide lifetime kernel code integrity for commodityOSes,” ACM SIGOPS Operating Systems Review, vol. 41, no. 6, 2007.

[26] F. Zhang, J. Chen, H. Chen, and B. Zang, “Cloudvisor: retrofittingprotection of virtual machines in multi-tenant cloud with nestedvirtualization,” in Proceedings of the Twenty-Third ACM Symposiumon Operating Systems Principles, pp. 203–216, ACM, 2011.

[27] G. Greenwald, “How the NSA tampers with US-made Internetrouters,” The Guardian, May 2014.

[28] S. Goldberg, “Why is it taking so long to secure internet routing?,”Communications of the ACM, vol. 57, no. 10, pp. 56–63, 2014.

[29] Trusted Computing Group, “TCG Specification, ArchitectureOverview, revision 1.4,” tech. rep., 2007.

[30] B. Parno, J. M. McCune, and A. Perrig, Bootstrapping Trust inModern Computers, vol. 10. Springer, 2011.

[31] P. Eronen and H. Tschofenig, “Pre-shared key ciphersuites fortransport layer security (TLS),” 2005.

[32] B. Blanchet, “An efficient cryptographic protocol verifier basedon prolog rules,” in Computer Security Foundations Workshop, IEEE,pp. 0082–0082, IEEE Computer Society, 2001.

[33] N. Paladi and A. Michalas, ““One of our hosts in another country”:Challenges of data geolocation in cloud storage,” in Wireless Com-munications, Vehicular Technology, Information Theory and AerospaceElectronic Systems, 2014 4th International Conference on, pp. 1–6, May2014.

Nicolae Paladi is currently a PhD student atLund University and researcher in the SecurityLab at SICS. His research interests include dis-tributed systems security with a special focuson cloud computing, infrastructure security, In-ternet security, virtualization and mobile platformsecurity, trusted computing, as well as selectedtopics on privacy, anonymity and personal dataprotection.

Christian Gehramann Christian Gehrmann isheading the Security Lab at SICS. The securitylab has around 12 members and is performingapplied research in security in virtualized sys-tems, security for IoT, cryptography, authentica-tion theory, security in cellular networks and onthe Internet. Christian Gehrmann has conductedcommunication and computer security researchfor more then 20 years. He holds a PhD fromLund University and is also an associate profes-sor at Lund University.

Antonis Michalas Antonis Michalas receivedhis PhD in Network Security from Aalborg Uni-versity, Denmark. He is currently a postdoctoralresearcher it the the Security Lab at SICS. Hisresearch interests include private and securee-voting systems, reputation systems, privacyin decentralized environments, cloud computingand privacy preserving protocols in participatorysensing applications. He has published a signif-icant number of papers in field-related journalsand conferences.

Documents

Providing User Security Guarantees in Public Infrastructure Clouds · Providing User Security Guarantees in Public Infrastructure Clouds Nicolae Paladi, Christian Gehrmann, and Antonis