ieee transactions on cloud computing, e-mail: {nicolae, chrisg}@sics.se, a.michalas@ . manuscript...

Providing User Security Guaranteesin Public Infrastructure Clouds

Nicolae Paladi, Christian Gehrmann, and Antonis Michalas

Abstract—The infrastructure cloud (IaaS) service model offers improved resource flexibility and availability, where tenants – insulated

from the minutiae of hardware maintenance – rent computing resources to deploy and operate complex systems. Large-scale services

running on IaaS platforms demonstrate the viability of this model; nevertheless, many organizations operating on sensitive data avoid

migrating operations to IaaS platforms due to security concerns. In this paper, we describe a framework for data and operation security

in IaaS, consisting of protocols for a trusted launch of virtual machines and domain-based storage protection. We continue with an

extensive theoretical analysis with proofs about protocol resistance against attacks in the defined threat model. The protocols allow

trust to be established by remotely attesting host platform configuration prior to launching guest virtual machines and ensure

confidentiality of data in remote storage, with encryption keys maintained outside of the IaaS domain. Presented experimental results

demonstrate the validity and efficiency of the proposed protocols. The framework prototype was implemented on a test bed operating a

public 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

Ç

1 INTRODUCTION

CLOUD computing has progressed from a bold vision tomassive deployments in various application domains.

However, the complexity of technology underlying cloudcomputing introduces novel security risks and challenges.Threats and mitigation techniques for the IaaS model havebeen under intensive scrutiny in recent years [1], [2], [3], [4],while the industry has invested in enhanced security solu-tions and issued best practice recommendations [5]. Froman end-user point of view the security of cloud infrastruc-ture implies unquestionable trust in the cloud provider, insome cases corroborated by reports of external auditors.While providers may offer security enhancements such asprotection of data at rest, end-users have limited or no con-trol over such mechanisms. There is a clear need for usableand cost-effective cloud platform security mechanisms suit-able for organizations that rely on cloud infrastructure.

One such mechanism is platform integrity verification forcompute hosts that support the virtualized cloud infrastruc-ture. Several large cloud vendors have signaled practicalimplementations of this mechanism, primarily to protect thecloud infrastructure from insider threats and advanced per-sistent threats. We see two major improvement vectorsregarding these implementations. First, details of such propri-etary solutions are not disclosed and can thus not be imple-mented and improved by other cloud platforms. Second, tothe best of our knowledge, none of the solutions providescloud tenants a proof regarding the integrity of compute hosts

supporting their slice of the cloud infrastructure. To addressthis, we propose a set of protocols for trusted launch of virtualmachines (VM) in IaaS, which provide tenants with a proofthat the requested VM instances were launched on a hostwith an expected software stack.

Another relevant security mechanism is encryption ofvirtual disk volumes, implemented and enforced at com-pute host level. While support data encryption at rest isoffered by several cloud providers and can be configuredby tenants in their VM instances, functionality and migra-tion capabilities of such solutions are severely restricted. Inmost cases cloud providers maintain and manage the keysnecessary for encryption and decryption of data at rest. Thisfurther convolutes the already complex data migration pro-cedure between different cloud providers, disadvantagingtenants through a new variation of vendor lock-in. Tenantscan choose to encrypt data on the operating system (OS)level within their VM environments and manage the en-cryption keys themselves. However, this approach suffersfrom several drawbacks: first, the underlying compute hostwill still have access encryption keys whenever the VM per-forms cryptographic operations; second, this shifts towardsthe tenant the burden of maintaining the encryption soft-ware in all their VM instances and increases the attack sur-face; third, this requires injecting, migrating and latersecurely withdrawing encryption keys to each of the VMinstances with access to the encrypted data, increasing theprobability than an attacker eventually obtains the keys. Inthis paper we present domain-based storage protection(DBSP), a virtual disk encryption mechanism whereencryption of data is done directly on the compute host,while the key material necessary for re-generating encryp-tion keys is stored in the volume metadata. This approachallows easy migration of encrypted data volumes and with-draws the control of the cloud provider over disk

� The authors are with the Security Lab, SICS Swedish ICT, Stockholm,Sweden. E-mail: {nicolae, chrisg}@sics.se, [email protected].

Manuscript received 27 Mar. 2015; revised 7 Dec. 2015; accepted 30 Jan.2016. Date of publication 4 Feb. 2016; date of current version 6 Sept. 2017.Recommended for acceptance by K.-K.R. Choo, O. Rana, and M. Rajarajan.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference the Digital Object Identifier below.Digital Object Identifier no. 10.1109/TCC.2016.2525991

IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 5, NO. 3, JULY-SEPTEMBER 2017 405

2168-7161� 2016 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.

encryption keys. In addition, DBSP significantly reducesthe risk of exposing encryption keys and keeps a low main-tenance overhead for the tenant – in the same time provid-ing additional control over the choice of the compute hostbased 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 modelchosen for this paper is based on requirements identifiedwhile migrating a currently deployed, distributed electronichealth record (EHR) system to an IaaS platform [6].

1.1 Contribution

We 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 enforcementby a 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 anattested platform configuration and reliably verify this.

2. We introduce a domain-based storage protectionprotocol to allow domain managers store encrypteddata volumes partitioned according to administra-tive domains.

3. We introduce a list of attacks applicable to IaaS envi-ronments and use them to develop protocols withdesired security properties, perform their securityanalysis and prove their resistance against the attacks.

4. We describe the implementation of the proposedprotocols on an open-source cloud platform andpresent extensive experimental results that demon-strate their practicality and efficiency.

1.2 Organization

The 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.1 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 formal con-structions. In Section 5, we provide a security analysis andprove 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 Launch

Santos et al. [1] proposed a “Trusted Cloud ComputePlatform” (TCCP) to ensure VMs are running on a trustedhardware and software stack on a remote and initiallyuntrusted host. To enable this, a trusted coordinator stores thelist of attested hosts that run a “trusted virtual machine mon-itor” which can securely run the client’s VM. Trusted hostsmaintain in memory an individual trusted key used for identi-fication each time a client launches a VM. The paper presentsa good initial set of ideas for trusted VM launch and migra-tion, in particular the use of a trusted coordinator. A limitationof this solution is that the trusted coordinator maintains infor-mation about all hosts deployed on the IaaS platform,makingit a valuable target to an adversary who attempts to exposethe public IaaS provider to 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. Oncethe VM image has been verified by the host and counter-signed by the cloud verifier, the tenant can allow the launch.The protocol increases the complexity for tenants both byintroducing the evaluation of integrity attestation reports ofthe cloud verifier and host and by adding steps to thetrusted VM launch, where the tenant must act based on thedata returned from the cloud verifier. Our protocol main-tains the VM launch traceability and transparency withoutrelying on a proxy verifier residing in the IaaS. Furthermore,the TL protocol does not require additional tenant interac-tion to launch the VM on a trusted host, beyond the initiallaunch arguments.

Platform attestation prior to VM launch is also applied in[7], which introduces two protocols – “TPM-based certifica-tion of a Remote Resource” (TCRR) and “VerifyMyVM”.With TCRR a tenant can verify the integrity of a remote hostand establish a trusted channel for further communication.In “VerifyMyVM”, the hypervisor running on an attestedhost uses an emulated TPM to verify on-demand the integ-rity of running VMs. Our approach is in many aspects simi-lar to the one in [7] in particular with regard to hostattestation prior to VM instance launch. However, theapproach in [7] requires the user to always encrypt the VMimage before instantiation, thus complicating image man-agement. This prevents tenants from using commodity VMimages offered by the cloud provider for trusted VM la-unches. We overcome this limitation and generalize thesolution by adding a verification token, created by the ten-ant and injected on the file system of the VM instance only ifit 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 on ahost 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)of the TPM placed on the host. The proposed solution is

406 IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 5, NO. 3, JULY-SEPTEMBER 2017

suitable in trusted VM launch scenarios for enterprise ten-ants as it requires that the VM image is pre-packaged andencrypted by the client prior to IaaS launch. However, simi-lar to [7], this prevents tenants from using commodity VMimages offered by the cloud provider to launch VM instan-ces on trusted cloud hosts. Furthermore, we believe thatreducing the number of steps required from the tenant canfacilitate the adoption of the trusted IaaS model. We extendsome of the ideas proposed in [8], address the above limita-tions – such as additional actions required from tenants –and also address the requirements towards the launchedVM instance and required changes to cloud platforms.

2.2 Secure Storage

Cooper and Martin described in in [9] a secure platformarchitecture based on a secure root of trust for gridenvironments – precursors of cloud computing. TrustedComputing is used as a method for dynamic trust estab-lishment within the grid, allowing clients to verify thattheir data wil be protected against malicious host attacks.The authors address the malicious host problem in gridenvironments, with three main risk factors: trust establish-ment, code isolation and grid middleware. The solutionestablished a minimal trusted computing base (TCB) byintroducing a security manager isolated by the hypervisorfrom grid services (which are in turn performed withinVM instances). The secure architecture is supported byprotocols for data integrity protection, confidentiality pro-tection and grid job attestation. In turn, these rely of clientattestation of the host running the respective jobs, followedby interaction with the security manager to fulfill the goalsof the respective protocols. We follow a similar approachin terms of interacting with a minimal TCB for protocolpurposes following host attestation. However, in order toadapt to the cloud computing model we delegate the taskof host attestation to an external TTP as well as use TPMfunctionality to ensure that sensitive cryptographic mate-rial 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 a dif-ferent 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, allowingto indefinitely maintain access to data reachable prior torevocation (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 privacywith usability, availability and maintainability. DPaaSfocuses on shareable logical data units, confined in isolatedpartitions (e.g., VMs of language-based features suchas Caja, Javascript) or containers, called Secure Execution

Environments (SEE). Data units are encrypted with symmet-ric keys and can be stored on untrusted hardware, while con-tainers communicate through authenticated channels. Theauthors stress the verifiability of DPaaS using trusted com-puting and the use of the dynamic root of trust to guaranteethat computation is performed on a “secure” platform. Theauthors posit that DPaaS fulfills confidentiality and privacyrequirements 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 offered bythe TPM, and in the reliance on full disk encryption to protectdata at rest and support for flexible access control manage-ment of the data blocks. However, the architecture outlinedin [11] does not address bootstrapping the platform (e.g., theVM launch) and provides few details about the key manage-ment mechanism for the secure data store. We address theabove shortcomings, by describing in detail and evaluatingprotocols to create and share confidentiality-protected datablocks. We describe cloud storage security mechanisms thatallow easy data migration between providers without affect-ing its confidentiality.

Graf et al. [12] presented an IaaS storage protection schemeaddressing access control. The authors analyse access rightsmanagement of shared versioned encrypted data on cloudinfrastructure for a restricted group and propose a scalableand flexible key management scheme. Access rights are rep-resented as a graph, making a distinction between dataencryption keys and encrypted updates on the keys andenabling flexible join/leave client operations, similar to prop-erties presented by the protocols in this paper. Despite itsadvantages, the requirement for client-side encryption limitsthe applicability of the scheme in [12] and introduces impor-tant functional limitations on indexing and search. In ourmodel, all cryptographic operations are performed on trustedIaaS compute hosts, which are able to allocatemore computa-tional 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 abstr-action, policy-sealed data to address the fact that TPM abstrac-tions are designed to protect data and secrets on a standalonemachine, at the same time over-exposing the cloud infrastruc-ture by revealing the identity and software fingerprint of indi-vidual cloud hosts. The authors extended TCCP [1] to addressthe limitations of binary-based attestation and data sealing byusing property-based attestation [14]. The core of Excalibur is‘the monitor’, which is a part of the cloud provider, whichorganises computations across a series of hosts and providesguarantees to tenants. Tenants first decide a policy andreceive evidence regarding the status of the monitor alongwith a public encryption key, and then encrypt their data andpolicy using ciphertext-policy attribute-based encryption [15].To decrypt, the stored data hosts receive the decryption keyfrom the monitor who ensures that the corresponding hosthas a valid status and satisfies the policy specified by theclient at encryption time. Our solution is similar to the onein [13], with some important differences: 1) In contrastwith [13] our protocols were implemented as a code extensionfor Openstack. Furthermore, the presented measurements

PALADI ET AL.: PROVIDING USER SECURITY GUARANTEES IN PUBLIC INFRASTRUCTURE CLOUDS 407

were made after we deployed the protocols for a part of theSwedish electronic health records management system in aninfrastructure cloud. Thus, our measures are considered asrealistic since the experiments were done under a real elec-tronic healthcare system; 2)Excalibur is totallymissing a secu-rity analysis. Instead authors only present the results ofProVerif (an automated tool) regarding the correctness of theirprotocol. In addition to that, through our security analysis weintroduced a new list of attacks that can be applied to suchsystems. This is something that is totally missing from relatedworks such as [13] and it can be considered as a great contri-bution to protocol designers since can avoid common pitfallsand design even better protocols in the future;

In [16] the authors presented a forward-looking designof a cryptographic cloud storage built on an untrustedIaaS infrastructure. The approach aims to provide confi-dentiality and integrity, while retaining the benefits ofcloud storage – availability, reliability, efficient retrievaland data sharing – and ensuring security through crypto-graphic guarantees rather than administrative controls.The solution requires four client-side components: dataprocessor, data verifier, credential generator, token generator.Important building blocks of the solution are: Symmetricsearchable encryption (SSE), appropriate in settings wherethe data consumer is also the one who generates it (effi-cient for single writer-single reader (SWSR) models);Asymmetric searchable encryption (ASE), appropriate formany writer single reader (MWSR) models, offers weakersecurity guarantees as the server can mount a dictionaryattack against the token and learn the search terms of theclient; Efficient ASE, appropriate in MWSR scenarioswhere the search terms are hard to guess, offers efficientsearch but is vulnerable to dictionary attacks; Multi-userSSE, appropriate for single writer/many reader settings,allows the owner to – besides encrypting indexes and gen-erating tokens – revoke user search privileges over data;Attribute based encryption, introduced in [17], providesusers with a decryption key with certain associated attrib-utes, such that a message can be encrypted using a certainkey and a policy. In such a scheme, the message can onlybe decrypted only if the policy matches the key used toencrypt it; finally, proofs of storage allow a client to verifythat data integrity has not been violated by the server.

The concepts presented in [16] are promising – especiallyconsidering 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 popu-lar open-source cloud platform) as in [21]: providers exposea quota of network, computation and storage resources to itstenants – referred to as domain managers (Fig. 1). Domainmanagers utilize the quota to launch and operate VM guests.LetDM ¼ DM1; . . . ; DMnf g be the set of all domain manag-

ers in our IaaS. Then, VMi ¼ vmi1; . . . ; vm

in

� �is the set of all

VMs owned by each domain manager DMi. VM guestsoperated by DM are grouped into domains (similar to proj-ects in OpenStack) which comprise cloud resources corre-sponding 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 ¼ Di1; . . . ; D

in

� �as the set of all domains cre-

ated by a domain managerDMi.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. Wedenote the set of all compute hosts as CH ¼ CH1; . . . ;fCHng. We denote a VM instance vmi

l running on a compute

host CHi by vmil 7!CHi and its unique identifier by idvmi

l .The Security Profile (SP ) , defined in [19], is a function of

the verified andmeasured deployment of a trusted computingbase – a collection of software components measurable dur-ing a platform boot. Measurements are maintained in pro-tected storage, usually located on the same platform. Weexpand this concept in Section 4. Several functionally equiva-lent configurations may each have a different security pro-file. We denote the set of all compute hosts that share thesame security profile SPi as CHSPi . VMs intercommunicate

through a virtual network overlay, a “software definednetwork” (SDN). A domain manager can create arbitrarynetwork topologies in the same domain to interconnect theVMswithout affecting network topologies in other domains.

I/O virtualization enables device aggregation and allowsto combine several physical devices into a single logicaldevice (with better properties), presented to a VM [22].Cloud platforms use this to aggregate disparate storagedevices into highly available logical devices with arbitrarystorage capacity (e.g., volumes in OpenStack). VMs are pre-sented with a logical device through a single accessinterface, while replication, fault-tolerance and storageaggregation are hidden in the lower abstraction layers. Werefer to this logical device as storage resource (SR); as a

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


storage unit, an SR can be any unit supported by the diskencryption subsystem.

3.2 Threat Model

We share the threat model with [1], [8], [19], [20], which isbased on the Dolev-Yao adversarial model [23] and furtherassumes that privileged access rights can used by a remoteadversary ADV 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 raised theissue of hardware tampering en route to deployment sites[27], [28]. We assume that the cloud provider has taken nec-essary technical and non-technical measures to preventsuch hardware tampering.

Physical Security.We assume physical security of the datacentres where the IaaS is deployed. This assumption holdsboth when the IaaS provider owns and manages the datacenter (as in the case of AmazonWeb Services, Google Com-pute Engine, Microsoft Azure, etc.) and when the providerutilizes third party capacity, since physical security can beobserved, enforced and verified through known best practi-ces by audit organizations. This assumption is important tobuild higher-level hardware and software security guaran-tees for the components of the IaaS.

Low-Level Software Stack. We assume that at installationtime, the IaaS provider reliably records integrity measure-ments of the low-level software stack: the Core Root of Trustfor measurement; BIOS and host extensions; host platformconfiguration; Option ROM code, configuration and data;Initial Platform Loader code and configuration; state transi-tions and wake events, and a minimal hypervisor. We as-sume the record is kept on protected storage with read-onlyaccess and the adversary cannot tamper with it.

Network Infrastructure. The IaaS provider has physicaland administrative control of the network. ADV is in fullcontrol of the network configuration, can overhear, create,replay and destroy all messages communicated betweenDM and their resources (VMs, virtual routers, storageabstraction components) and may attempt to gain access toother domains or learn confidential information.

Cryptographic Security. We assume encryption schemesare semantically secure and the ADV cannot obtain theplain text of encrypted messages. We also assume the signa-ture scheme is unforgeable, i.e., the ADV cannot forge thesignature 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 [29] and focus on ADV that aim to com-promise 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 is toinject a malicious program or back door into the VM image,prior to instantiation. Once the VM is launched and startsprocessing potentially sensitive information, the maliciousprogram can leak data to an arbitrary remote location with-out the suspicion of the domain manager. In this case, theVM instance will not be a legitimate instance and in particu-lar not the instance the domain manager intended to launch.We call this type of attack a VM Substitution Attack:

Definition 1 (Successful VM Substitution Attack). Assumea domain manager, DMi, intends to launch a particular vir-tual machine vmi

l on an arbitrary compute host in the setCHSPi . An adversary,ADV, succeeds to perform a VM substi-tution attack if she can find a pair ðCH; vmÞ : CH 2 CHSPi ;

vm 2 VM; vm 6¼ vmil; vm7!CH, where vm will be

accepted byDMi as vmil .

A more complex attack involves reading or modifyingthe information 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). AssumeDMi wishes to launch a VM vmi

l on a compute host in the setCHSPi . An adversary, ADV, succeeds with a CH substitution

attack iff 9 vmil 7!CHj; CHj 2 CHSPj ; SPj 6¼ SPi: vmi

l

will be accepted byDMi.

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 fall backoption in case the malicious program is removed or pre-vented from functioning as intended. ADV may choose acombined VM and CH substitution attack, which allows a mod-ified VM to be launched on a compromised host and presentit toDMi as the intended VM:

Definition 3 (Successful Combined VM and CH Substitu-tion Attack). Assume a domain manager, DMi, wishes tolaunch a virtual machine vmi

l on a compute host in theset CHSPi . An adversary, ADV, succeeds to perform a com-bined CH and VM substitution attack if she can find a pairðCH; vmÞ; CH 2 CHSPj ; SPj 6¼ SPi; vm 2 VM; vm 6¼vmi

l; vm7!CH, where vm will be accepted byDMi as vmil .

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

vm7!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 arbitrary virtual

1. In 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 covered byextending the domain manager role such that it is allowed not to a dis-tinct entity but a role that is possibly shared between domain managersthat belong to different organizations.


machine vmil on a compute host in the set CHSPi . An adversary

ADV succeeds with a storage CH substitution attack if shemanages to launch vmi

l 7! CHj, CHj 2 CHSPj , SPj 6¼ SPi

and Divmi

l\ Dj

vmil

6¼ ;.

If access to the data storage resource is given to all VMslaunched by DMi, ADV may attempt to gain access bylaunching a VM that appears to have been launched by DMi.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 adver-sary ADV succeeds to perform a domain violation attack if

she manages to launch an arbitrary VM, vmjm 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 of thispaper’s contribution. These protocols are successively appliedto deploy a cloud infrastructure providing additional userguarantees of cloud host integrity and storage security. Forprotocol purposes, each domain manager, secure componentand trusted third party has a public/private key pair (pk=sk).The private key is kept secret, while the public key is sharedwith the community.We assume that during the initializationphase, each entity obtains a certificate via a trusted certifica-tion authority. We first describe the cryptographic primitivesused in the proposed protocols, followed by definitions of themain protocol components.

4.1 Cryptographic Primitives

The set of all binary strings of length n is denoted by 0; 1f gn,and the set of all finite binary strings as 0; 1f g�. Given a setU , we refer to the ith element as vi. Additionally, we use thefollowing notations for cryptographic operations through-out the paper:

� For an arbitrary message m 2 0; 1f g�, we denote byc ¼ Enc K;mð Þ a symmetric encryption of m usingthe secret key K 2 0; 1f g�. The corresponding sym-metric decryption operation is denoted by m ¼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 bym ¼ DecskðcÞ ¼ DecskðEncpkðmÞÞ.

� A digital signature over a message m is denoted bys ¼ SignskðmÞ. The corresponding verification oper-ation for a digital signature is denoted byb ¼ Verifypkðm; sÞ, where b ¼ 1 if the signature is

valid and b ¼ 0 otherwise.� A Message Authentication Code (MAC) using a

secret key K over a message m is denoted bym ¼ MACðK;mÞ.

� We denote by t ¼ RANDðnÞ a random binarysequence 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 return.3

4.2 Protocol Components

Disk encryption subsystem. a software or hardware compo-nent for data I/O encryption on storage devices, capable toencrypt storage units such as hard drives, software RAIDvolumes, partitions, files, etc. We assume a software-basedsubsystem, such as dm-crypt, a disk encryption subsystemusing the Linux kernel Crypto API.

Trusted Platform Module (TPM). a hardware crypto-graphic co-processor following specifications of the TrustedComputing Group (TCG) [30]; we assume CH are equippedwith a TPM v1.2. The tamper-evident property facilitatesmonitoring CH integrity and strengthens the assumption ofphysical security. An active TPM records the platform boottime software state and stores it as a list of hashes in plat-form configuration registers. TPM v1.2 has 16 PCRsreserved for static measurements (PCR0 - PCR15), clearedupon a hard reboot. Additional runtime resettable registers(PCR16-PCR23) are available for dynamic measurements.Endorsement keys are an asymmetric key pair stored insidethe TPM in the trusted platform supply chain, used to createan endorsement credential signed by the TPM vendor to cer-tify the TPM specification compliance. A message encrypted(“bound”) using a TPM’s public key is decryptable onlywith the private key of the same TPM. Sealing is a specialcase of binding – bound messages are only decryptable inthe platform state defined by PCR values. Platform attes-tation allows a remote party to authenticate a target platformand obtain a guarantee that it – up to a certain level in theboot chain – runs software that is identical to the expectedone. To do this, an attester requests – accompanied by anonce – the target platform to produce an attestation quoteand the measurement aggregate, or Integrity MeasurementList (IML). The TPM generates the attestation quote – asigned structure that includes the IML and the receivednonce – and returns the quote and the IML itself. The attes-tation quote is signed with the TPMs Attestation Identity Key(AIK). The exact IML contents are implementation-specific,but should contain enough data to allow the verifier to estab-lish the target platform [31] integrity. We refer to [30] for adescription of the TPM, and to [7], [19], [20] for protocolsthat use TPM functionality.

Trusted Third Party. an entity trusted by the other compo-nents. TTP verifies the TPM endorsement credentials onhosts operated by the cloud provider and enrolls the respec-tive TPMs’ AIKs by issuing a signed AIK certificate. Weassume that TTP has access to an access control list (ACL)describing access and ownership relations between and .Furtermore, TTP communicates with CH to exchange integ-rity attestation data, authentication tokens and crypto-graphic keys. TTP can attest platform integrity based on the

2. Alternative notations used for clarity are mf gpk or mh ipk.

3. We assume that a true random function in our constructions isreplaced by a pseudorandom function the input-output behaviour ofwhich is “computationally indistinguishable” from that of a true ran-dom function.


integrity attestation quotes and the valid AIK certificatefrom a TPM, and seal data to a trusted host configuration.Finally, TTP can verify the authenticity of DM and performnecessary cryptographic operations. In this paper, we treatthe TTP as a “black box” with a limited, well-defined func-tionality, and omit its internals. Availability of the TTP isessential in the cloud scenario – we refer the reader to therich body of work on fault tolerance for approaches tobuilding highly available systems.

Secure Component (SC). this is a verifiable execution mod-ule performing confidentiality and integrity protectionoperations on VM guest data. SC is present on all CH and isresponsible for enforcing the protocol; it acts as a mediatorbetween the DM and the TTP and forwards the requestsfrom DM to either the TTP or the disk encryption subsys-tem. SC must be placed in an isolated execution environ-ment, as in the approaches presented in [25], [26].

4.3 Trusted Launch Construction

We 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 part ofit). TL comprises a public-key encryption scheme, a signa-ture scheme and a token generator. Fig. 2 shows the proto-col 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 forDMi;� (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 gen-

erates a token by executing t ¼ RANDðnÞ and calculates the

hash (H1) of the VM image (vmil) intended for launch, the

hash (H2) of pkDMi, and the required security profile SPi.

Finally, Divmi

ldescribes the set of domains that vmi

l with the

identifier idvmil shall have access to; the six elements are

concatenated into: m1 ¼ t kH1 kH2 kSPikidvmilkDi

vmil

� �.

DMi encryptsm1 with pkTTP by running c1 ¼ EncpkTTP m1ð Þ.Next,DMi generates a random nonce r and sends the fol-

lowing 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 sDMi. Upon reception, the scheduler

assigns the VM launch to an appropriate host with a secu-rity profile 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 signaturesDMi

and nonce r. When SC first receives a TL:Requestmes-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 [30]

Fig. 2. Message flow in the trusted VM launch protocol.


using the TPM_CERTIFY_KEY TPM command; we denotethis signed structure by sTCI. 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. SCalso requests the TPM to sign the message with skAIK, pro-ducing sAIK . AttestData includes the following:

- the public TPM bind key pkTPM;- the TPM_CERTIFY_INFO structure;- sTCI : signature of TPM_CERTIFY_INFO using skAIK;- IML, the integrity measurement list;- the TCI-certificate;Upon reception, TTP verifies the integrity and freshness

of TL:AttestRequest, checking respectively the signaturesAIK and nonce r. Next, TTP verifies – according to its ACL

– the set Divmi

lto ensure that DMi is authorised to allow

access to the requested domains for vmil and decrypts the

message m1 :¼ DecskTTP c1ð Þ, decomposing it into t; 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; AttestDatah i, andoutputs a result bit b. If the attestation result is posi-tive, b ¼ 1; otherwise, b ¼ 0. We denote this by b :¼AttestVerifyðc1; sAIK;AttestDataÞ.

2. AttestToken is a probabilistic algorithm that producesa TPM-sealed attestation token. The input of the algo-rithm is the result of AttestVerify, the message m to besealed and the CH AttestData. If AttestVerify evalu-ates to b ¼ 1, the algorithm outputs an encrypted mes-sage c2. We write this as c2 AttestTokenðb;m;AttestDataÞ. Otherwise, if AttestVerify evaluates tob ¼ 0, AttestToken returns ?.

In the attestation step, TTP first runs AttestVerify to deter-mine the trustworthiness of the target CHi. In AttestVerify,TTP verifies the signature sTCI and sAIK against a valid AIKcertificate contained in AttestData and examines the entriesprovided in the IML. AttestVerify returns b ¼ 0 and TTPexits the protocol if the entries differ from values expectedfor the security profile SPi. Otherwise, AttestVerify returnsb ¼ 1 and TTP runs AttestToken to generate a newencrypted attestation token for CHi. Having verified thatthe entries in IML conform to the security profile SPi, TTPgenerates a symmetric domain encryption key, DKi, to pro-tect the communication between the SC and TTP in future

exchanges. Finally, TTP seals m2 ¼ tkH1kH2kDKikidvmil

� �to the trusted platform configuration of CHi, using the key

pkTPM received through the attestation request. Theencrypted message (c2 AttestTokenðb;m2; AttestDataÞ;r), along with a signature (sTTP ) produced using skTTP isreturned 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

plain text m2 ¼ tkH1kH2kDKikidvmil

� �only if the platform

state of CHi has remained unchanged. SC calculates thehash (H 01) of the VM image supplied for launch and verifies

that its identifier matches the expected identifier idvmil ; SC

also calculates the hash of pkDMireceived from the cloud

provider, denoted by H 02. Finally, SC verifies that H1 ¼ H 01and only in that case injects t into the VM image. Likewise,SC verifies that the public key registered by DMi with thecloud provider in step TL:Setup has not been altered, i.e.,H2 ¼ H 02 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 vmil verifies the authenticity of DMi. This is done by

establishing a secure pre-shared key TLS session [32]

between vmil andDMi using t 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 components

through a VM instance vmil running on CHi. We assume

that vmil has been launched following the TL protocol. The

DBSP protocol includes a public and a private encryptionscheme, a pseudorandom function for domain key genera-tion, a signature scheme and a random generator. Fig. 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 domain Dik 2 Di

vmil. The request

is intercepted by the SC, which proceeds to retrieve from

TTP a symmetric encryption key for the domainDik.

DBSP:DomKeyReq: SC sends to TTP a request to gener-

ate keys for the domain Dik. The request contains the target

storage resource SRi, hash H2 of pkDMi, the nonce r and

metaik, containing the unique domain identifier and the

security profile required to access the domain Dik, i.e.,

metaik ¼ Dik; SPi

� �pkTTP

; SC uses the symmetric key DKi

received during TL:Attestation to protect message confi-dentiality, and the local TPM to sign the message withskAIK, producing sAIK (see DBSP:DomKeyReq in Fig. 3).

Upon the reception of DBSP:DomKeyReq, TTP verifiesthe freshness and integrity of the request and proceeds tothe next protocol step, DBSP:DomKeyGen, only if this veri-fication succeeds.

DBSP:DomKeyGen: A probabilistic algorithm enabling

TTP to generate a symmetric encryption key (Kik) and integ-

rity key (IKik) for a domainDi

k. TTP generates a nonce using


a random message mi 2 0; 1f gn by executing ni ¼ RANDmið Þ. Next, TTP uses a PRF to generate the keys for domain

Dik, by evaluating the following:

Kik ¼ PRF KTTP ;D

ikkSPikni

� ;

IKik ¼ PRF KTTP ;D

ikkni

� ;

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

perimeter of TTP,Kik is a symmetric encryption key to confi-

dentiality protect the data and IKik a symmetric key to ver-

ify the integrity of the stored data.TTP seals Ki

k and IKik to the trusted configuration of CHi

by calculating c3 ¼ EncpkTPM KikkIKi

k

� . TTP encrypts the

generated nonce ni and the provided security profile SPi byevaluating c4 ¼ EncKTTP

nikSPið Þ to later use it for verifica-

tion. Next, TTP generates a message authentication code

m by evaluating mik ¼ MACðKTTP ; nikSPiÞ. The domain

key generation algorithm is denoted by c3; c4;mik

� DBSP:DomKeyGenðni;KTTP ; skTPMÞ.

Having generated the domain key, TTP responds to the

DBSP:DomKeyReq by sending c3; c4;mik;metaik; r

� �with

the signature sTTP . Upon reception, SC first verifies messageintegrity and freshness, and calls the local TPM to unseal c3,

producing KikkIKi

k if and only if CHi remains in the earlier

trusted state. Next, SC storesmetaik, c4 and mik in the domain

header and uses Kik; IKi

k as inputs to the disk encryptionsubsystem on CHi, which decrypts and verifies the data

integrity of the mounted volume hosting Dik before provid-

ing plain text access to vmil .

To recreate the encryption and integrity keys for thedomain Di

k, SC sends a request similar to DBSP:

DomKeyReq, adding to the message the values c4 and mik,

which are stored in the domain header. Upon reception,TTP verifies the integrity of the received value c4 by calcu-

lating mik ¼ MACðKTTP ; nikSPiÞ. If the integrity verification

of c4 is positive, TTP decrypts it to nikSPi ¼ DecskTTP c4ð Þand calculates the domain key as in DBSP:DomKeyGen,using the existing token ni instead of generating a new one.4

5 SECURITY ANALYSIS

We now analyse the TL and DBSP protocols in the presenceof an adversary. We prove the security of both schemesthrough 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 adversaryADV 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 issuccessful. In turn, this step only succeeds if at least oneof the following two options is true:

a. The secure component SC uses a different token,t0 6¼ t accepted by DMi in the final secure channelestablishment.

b. The secure component SC on CH uses the very

same token t used byDMi when launching vmil .

Option a can only succeed ifADV can break the mutualauthentication in the secure channel setting. Given thatthe selected secure channel scheme is sound and t is suffi-ciently long and selected using a sound random genera-tion process, the ADV fails to break the last protocol step.Hence, as long as the secure channel protocol is sound,the overall protocol construction is also sound against thisattack option.

Option b can only succeed if the adversary either man-ages to guess a value t0 ¼ t when launching vm or

Fig. 3. Message flow in the domain-based storage protection protocol.

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


manages to either obtain t when DMi launches vmil or

replace the association between t and vmil with an associ-

ation between t and vm when DMi launches vmil , by

attacking any of the protocol steps preceding the finalmutual authentication step. A successful attack in thiscase has the probability t0 ¼ t equals to 1=2n, where n isthe length of the token value and is infeasible if n is largeenough. Below, we show why the adversary also failswith respect to the last option.

� TL:Token. Assume the adversary intercepts theTL:Token message. Then the adversary has twooptions: she might either try to modify theTL:Token message (option 1) with the goal to

replace the association between t and the vmil with

t and vm, or she might try obtain the secret value t(option 2) and then launch vm with this t valueon an arbitrary valid provider platform. We dis-cuss both these options below.- TL:Token Option 1: A modification can only

be achieved by the adversary by either break-ing the public key encryption scheme usedto produce c1 or trying to make this modifica-tion on c1 by direct modification (withoutfirst decrypting it) and sign the modifiedc1 with an own selected private key. The for-mer option fails due to the assumption ofpublic key encryption scheme soundnessand the latter due to that modifying a publicencrypted structure without knowledge ofthe private key is infeasible.

- TL:Token Option 2: Direct decryption of c1fails due to the assumption of soundness ofthe public key encryption scheme used toproduce c1. The only remaining alternativefor the adversary is relaying the TL:Token toa platform CH 0 2 CHSPi , which is under thefull control of the adversary. Further, ADVfollows the protocol and issues the commandTL:AttestRequest using the intercepted c1,AttestData and sAIK . However, this fails atthe TL:Attestation step since AttestData doesnot contain a valid AIK certificate unless theadversary has managed to get control of avalid platform in the provider network witha valid certificate or she has managed tobreak the AIK certification scheme. The for-mer option violates the assumption of phy-sical security of the provider computingresources while the latter option violates theassumption of a sound public key and AIKcertification schemes.

� TL:AttestRequest. The adversary could eithertry to impersonate this message with the goalof obtaining t or the association between t

and vmil . This impersonation attempt fails as

the whole sent structure is signed with thepkAIK with a secure public key signingscheme. Furthermore, attempts to resend anold valid TL:AtttestRequest fail as the H1 ver-ification that the SC receives in return fails as

it does point on the old VM. Similarly, anyattempts to modify TL:AttestRequest fail asthe whole structure is signed with a securesignature scheme.

� TL:Attestation. Any attempt by the adversaryto obtain t would be equal to breaking thepublic key encryption of TL:AttestToken. Sim-ilarly, any attempt tomodify c2 fails due to thefact that modification of a public encryptedstructure without knowledge of the privatekey is unfeasible if the public key encryptionscheme is sound. Any attempt by the adver-sary to replace an old recorded validTL:AttestToken message fails as such mes-sages do contain a VM image hash H1 differ-ent than the one expected by the SC. tu

Proposition 2 (CH Substitution Soundness). The TLprotocol 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.

An adversary ADV trying to launch vmil on CHj 2 CHSPj ,

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

mutual authentication step in the trusted launch proce-dure is successful. In turn, this step can only succeed if atleast one of the following two options is true:

a. The secure component SC is using a differenttoken, t0 6¼ t that is accepted by DMi in the finalsecure channel establishment.

b. The secure component SC on CHj is using thevery same token t used by DMi when launchingvmi

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

Option b can only succeed if the adversary either man-ages to guess a value t0 ¼ t when launching vmi

l or man-ages to induce the TTP to seal the token t to theconfiguration of CHj. Finding t0 ¼ t is infeasible for theadversary as shown in Proposition 1. Below, we showwhy the adversary also fails with respect to the secondoption.

Assume ADV intercepts the TL:Token message. Then

it has two options: either attempt to launch vmil on a com-

pute host CHj =2 CHSPi or on CHj 2 CHSPi .

- TL:Token CHj =2 CHSPi : TheADV can replace thefollowing information from the TL:Token mes-sage: SPi with SPj, pkDMi

with pkADV , which is a

public key generated by the ADV and sc1 with

sADV ¼ SignskADV ðc1Þ. By doing this, she can suc-

cessfully 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 withthe preference ofDMi contained in c1.

- TL:Token CHj 2 CHSPi : The ADV can replace thefollowing information from the TL:Token mes-sage: pkDMi

with pkADV , which is a public key

generated by the ADV and sc1 with sADV ¼SignskADV ðc1Þ. By doing this, he can successfully


proceed beyond the TL:AttestRequest step sinceSC is unable to detect the substitution. However,this attack fails at the TL:Attestation step since thepkAIK key used to produce the signature sAIK isnot among the keys enrolled with the TTP accord-ing to Section 4.2.

The cases of TL:AttestRequest and TL:Attestation failas demonstrated in Proposition 1. tu

Proposition 3 (Combined VM and CH SubstitutionSoundness). The TL protocol is sound against the VM andCH substitution attack.

Proof. The exculpability of the VM substitution attack andthe CH substitution attack implies that the TL protocol issecure against the combined VM and CH substitutionattack. tu

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

Proof. Adversary ADV can only succeed with a storageCH substitution attack if she manages to launch a VM

instance vmil 7! CHi, CHi 2 CHSPi on a host CHj 2

CHSPj , SPj 6¼ SPi and Divmi

l\ Dj

vmil

6¼ ;. This can only be

achieved if she requests launch of vmil on a platform with

profile SPj. According to Proposition 2 and Proposition 3,

such launch requests are rejected by DMi; however, thisdoes not prevent theADV from attempting these options.The following two alternatives are available to theadversary:

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 theTL:AttestRequest step fails as shown in the proof ofProposition 1. In this case, the platform controlled byADV does not get the symmetric keyDKi in return to theattestation request. Without access to DKi, the onlyremaining option for the adversary is to attempt to breakthe final key request or the disc encryption scheme. Thusthe following options are available:

� DBSP:DomKeyReq : The first option is to inter-cept a valid DBSP:DomKeyReq message for a

storage domain Dik 2 Di

vmiland replace the inter-

cepted signature sAIK with her own own signa-ture, s0AIK over the very same encrypted request

(encrypted with a valid DKi). However, similarto the earlier attempt to perform aTL:AttestRequest, this fails since the ADV doesnot have access to a valid attestation key. Anyother attempt to send the adversary’s own DBSP:DomKeyReq fails for the same reason.

� DBSP:DomKeyGen : The remaining option is toobserve a valid DBSP.DomKeyGen for a domain

Dik 2 Di

vmiland attempt to access the encrypted

storage keys. The latter fails due to the assump-tion of the TPM public key scheme soundness.

� Attack Storage Encryption Scheme: The remainingoption for the ADV in this case is to directly breakthe disc encryption scheme. However, this isinfeasible according to the disc encryption schemesoundness.

Option b: According to this option, the ADV trieslaunching vmi

l using TL:Token on a platform with profileSPj using its own credentials. The following impersona-tion alternatives are available:

� Own token: The adversary ADV sends a TL:Tokenmessage required by the protocol:

EncpkTTPðt k H1 k H2 k SPj k idvmil k Di

vmilÞ;

SPj; pkADV ; r; s ADV , where H2 either is thehash of pkDMi

or the hash of pkADV . If the first

option is used, the SC obtains in return toTL:AttestRequest, i.e. the TL:Attestation message,a sealed value with a hash H 02 6¼ H2 which causesthe SC to abort the launch. If the second option isused, the complete launch procedure succeeds asexpected. However, when the SC later requeststhe key for SRi using the DBSP: DomKeyReqmessage, it includes the hash H2 of the the ADVpublic key (pkADV) in the encrypted and signedrequest. ADV cannot change the hash value inthis request unless she breaks the signaturescheme of the request. Upon receiving therequest, TTP identifies that ADV is not allowed to

access Dik 2 Di

vmiland 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 vm with accessrights to the intended domain and uses it tolaunch an own valid TL:Token message: c1; SPj;pkADV ; r; sADV . However, in this case theTL:AttestRequest fails as the profile in c1 does notmatch the platform attested data. Furthermore, ifthe SC receives a reply to TL:AttestRequest, i.e. aTL:Attestation message, it would receive a sealedvalue with a hash H 02 6¼ H2, causing the SC toabort the launch. tu

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

Proof. Similar to the proof of Proposition 4,ADV has the fol-lowing two options:

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

under its control (i.e., outside the providerdomain).

b. The ADV launches vmjm 7!CHj on a valid platform

in the provider network.Option a: This option fails in analogy with the proof of

Proposition 4, as ADV fails to successfully launch vmjm

and her remaining options are to either attack the finalkey request or the disc encryption scheme, which bothfail (see proof of Proposition 4).

Option b: In analogy with the proof of Proposition 4,ADV has only two options available: a full imperso-nation with an own chosen token of type EncpkTTPðt kH1 kH2 kSPjkidvmj

mkDj

vmjm

Þ; SPj; pkADV ; r; sADV ,


Dj

vmjm

� Di, or a partial impersonation reusing an

observed c1 of type c1; SPj; pkADV ; r; sADV for a subset oftarget storage domain. Both options fail in analogy withthe arguments presented for the proof of Proposition 4. tu

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 hosts con-nected on a Cisco Catalyst 2960 switch with 801.2 q support.We used Linux CentOS, kernel version 2.6.32-358.123.2.openstack.el6.x86_64 and the OpenStack IaaS platform5 (ver-sion Icehouse) using KVM virtualization support. The proto-type IaaS includes one “controller” running essentialplatform services (scheduler, PKI components, SDN controlplane, VM image storage, etc.) and three compute hosts run-ning the VM guests. The topology of the prototype SDNreflects three larger domains of the application-level deploy-ment (front-end, back-end and database components) inthree 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 Fig. 4). It uses ageneric server architecture where the SC daemon handleseach request in a separate process. An inter process commu-nication (IPC) protocol defines the types of messages proc-essed by the SC. The IPC protocol uses sychronous callswith several types of requests for the respective SC opera-tions; the response contains the exit code and response data.A detailed architecture of SC, including the main librariesthat it relies on, is presented in Fig. 5.

6.1.2 Application Description

The prototype also includes a distributed EHR systemdeployed over seven VM instances. This system contains oneclient VM, two front-end VMs, two back-end VMs, a

database VM and an auxiliary external database VM. Six ofthe VM instances operate onMicrosoftWindows Server 2012R2, with one VM running the client application operates onWindows 7. The components of the EHR system communi-cate using statically defined IP addresses on the respectiveVLANS described in Section 6.1.1. Load balancing function-ality provided by the underlying IaaS allots the load amongfront-end and back-end VM pairs. The hosts of the clusterare compatible with the TL protocol, which allows an infra-structure administrator to perform a trusted launch of VMinstances on qualified hosts. Similarly, the infrastructureadministrator can apply the DBSP protocol to protect sensi-tive information stored on the database servers.

6.2 Performance Evaluation

Trusted launch. Fig. 6 shows the duration of a VM launchover 100 successful instantiations: the TL protocol extendsthe duration of the VM instantiation (which does notinclude the OS boot time) on average by 28 percent. How-ever, in our experiments we have used a minimalistic VMimage (13.2 MB), based on CirrOS,7 while launching largerVM images takes significantly more time and proportion-ally reduces the overhead induced by TL.

DBSP Processing time. Table 1 shows a breakdown of thetime required to process a storage unlock request, an aver-age of 10 executions. Processing a volume unlock requeston the prototype returns in �2.714 seconds; however, thisoperation is performed only when attaching the volume to aVM instance and does not affect the subsequent I/O opera-tions on the volume. A closer view highlights the share ofthe contributing components in the overall overhead com-position. Table 1 clearly shows that the TPM unseal opera-tion lasts on average �2.7 seconds, or 99.516 percent of theexecution time. According to Section 4.2, in this prototypewe use TPMs v1.2, since a TPM v2.0 is not available on com-modity platforms at the time of writing. Given that the vastmajority of the execution time is spent in the TPM unsealoperation, implementing the protocol with a TPM v2.0 mayyield improved results.

DBSP Encryption Overhead. Next, we examine the proc-essing overhead introduced by the DBSP protocol. Fig. 7presents the results of a disk performance benchmarkobtained using IOmeter.8 To measure the effect of back-ground disk encryption with DBSP, we attached two virtualdisks to a deployed server VM described in 6.1.2. The stor-age volumes were physically located on a different host and

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

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

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

7. CirrOS project website: https://launchpad.net/cirros8. IOmeter project website: http://iometer.org


communicating over iSCSI. We ran a benchmark with twoparallel workers on the plaintext and DBSP-encrypted vol-umes over 12 hours. Next, we disabled in the host BIOS theAES-NI acceleration, created and attached a new volume tothe VM and reran the benchmark. This has produced threeperformance data result sets: plaintext, DBSP encryptionand DBSP encryption with AES-NI acceleration. Fig. 7 sum-marises the total IO, read IO and write IO results. It is visiblethat the measurements ‘4 KiB aligned (DBSP) with AES-NI’and ‘1 MiB (DBSP) with AES-NI’ are roughly on par withthe plaintext baseline: ‘4 KiB aligned’ and ‘1 MiB’. The per-formance overhead induced by background encryption is at1.18 percent for read IO and 0.95 percent for write IO. Wecan expect that this performance penalty will be furtherreduced as the hardware support for encryption isimproved. Disk encryption without hardware acceleration(‘4 KiB aligned (DBSP)’ and ‘1 MiB (DBSP)’) is significantlyslower, as expected, with a performance penalty of respec-tively 49.22 and 42.19 percent (total IO). It is important toreemphasize that the runtime performance penalty is deter-mined exclusively by the performance of the disk encryp-tion subsystem. DBSP only affects the time required tounlock the volume when it is attached to the VM instance,as presented in Table 1.

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

cryptographic tools. Platform integrity guarantees allowtenants to take better decisions on both workload migrationto the cloud and workload placement within IaaS. This con-trasts with the current, “flat” trust model, where all IaaShosts declare the same – but unverifiable for the tenant – trustlevel.

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 tenantcan purchase cheaper cloud disk storage without any addi-tional 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 eitherbe managed by the tenant itself (for organizations withenough resources and expertise), or by an external organiza-tion (similar to a certificate authority). The first scenarioallows the tenant to retain the benefits of cloud servicesalong with additional security guarantees. Similarly, in thesecond scenario, smaller actors can obtain the same benefitswithout the need to invest into own attestation infrastruc-ture. In both scenarios, in order to protect the cloud pro-vider the TTP would only operate on a physical slice of theresources (i.e., a subset of compute hosts) that correspondto the respective tenant domains.

8 CONCLUSION

From a tenant point of view, the cloud security model doesnot yet hold against threat models developed for the tradi-tional model where the hosts are operated and used by thesame organization. However, there is a steady progresstowards strengthening the IaaS security model. In this workwe presented a framework for trusted infrastructure clouddeployment, with two focus points: VM deployment ontrusted compute hosts and domain-based protection of

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

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

TABLE 1Overhead for Unlocking a Volume with DBSP (All Times in Ms)

Process Event Time

QEMU 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


stored data. We described in detail the design, implementa-tion 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 [33]. 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 futurework are strengtheningthe trust model in cloud network communications, data geo-location [34], and applying searchable encryption schemes tocreate secure cloud storage mechanisms. Our results showthat it is possible and practical to provide strong platform soft-ware integrity guarantees for tenants and efficiently isolatetheir data using established cryptographic tools. With reason-able engineering effort the framework can be integratedinto production environments to strengthen their securityproperties.

REFERENCES

[1] N. Santos, K. P. Gummadi, and R. Rodrigues, “Towards trustedcloud computing,” in Proc. Conf. Hot Topics Cloud Comput., 2009, p. 3.

[2] J. Schiffman, T. Moyer, H. Vijayakumar, T. Jaeger, and P.McDaniel, “Seeding clouds with trust anchors,” in Proc. ACMWorkshop Cloud Comput. Security, 2010, pp. 43–46.

[3] N. Paladi, A. Michalas, and C. Gehrmann, “Domain based storageprotection with secure access control for the cloud,” in Proc. Int.Workshop Security Cloud Comput., 2014, pp. 35–42.

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

[5] Top Threats Working Group, “The notorious nine cloud comput-ing top threats 2013,” Cloud Security Alliance, Tech. Rep.,Feb. 2013.

[6] A. Michalas, N. Paladi, and C. Gehrmann, “Security aspects ofe-health systems migration to the cloud,” in Proc. 16th Int. Conf.E-health Netw., Appl. Serv., Oct. 2014, pp. 228–232.

[7] B. Bertholon, S. Varrette, and P. Bouvry, “Certicloud: A novelTPM-based approach to ensure cloud IaaS security,” in Proc. IEEEInt. Conf. Cloud Comput., 2011, pp. 121–130.

[8] M. Aslam, C. Gehrmann, L. Rasmusson, and M. Bj€orkman,“Securely launching virtual machines on trustworthy platforms ina public cloud - an enterprise’s perspective.,” in Proc. CLOSER,2012, pp. 511–521.

[9] A. Cooper and A. Martin, “Towards a secure, tamper-proof gridplatform,” in Proc. 6th IEEE Int. Symp. Cluster Comput. Grid, 2006,pp. 373–380.

[10] W. Wang, Z. Li, R. Owens, and B. Bhargava, “Secure and efficientaccess to outsourced data,” in Proc. ACM Workshop Cloud Comput.Security, 2009, pp. 55–66.

[11] D. Song, E. Shi, I. Fischer, and U. Shankar, “Cloud data protectionfor the masses,” IEEE Comput., 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 Proc. IEEE 31stSymp. Reliable Distrib. Syst., 2012, pp. 469–474.

[13] N. Santos, R. Rodrigues, K. P. Gummadi, and S. Saroiu,“Policy-sealed data: A new abstraction for building trustedcloud services,” in Proc. 21st USENIX Security Symp., 2012,pp. 175–188.

[14] A.-R. Sadeghi and C. St�uble, “Property-based attestation for com-puting platforms: Caring about properties, not mechanisms,” inProc. Workshop New Security Paradigms, 2004, pp. 67–77.

[15] A. Sahai, “Ciphertext-policy attribute-based encryption,” in Proc.IEEE Symp. Security Privacy, 2007.

[16] S. Kamara and K. Lauter, “Cryptographic cloud storage,” in Proc.Financial Cryptography and Data Security, vol. 6054 of Lecture Notesin Computer Science, 2010, pp. 136–149.

[17] A. Sahai and B. Waters, “Fuzzy identity-based encryption,” inProc. 24th Annu. Int. Conf. Theory Appl. Cryptograph. Techn., 2005,pp. 457–473.

[18] S. Kamara and C. Papamanthou, “Parallel and dynamic search-able symmetric encryption,” in Financial Cryptography and DataSecurity, New York, NY, USA: Springer, 2013, pp. 258–274.

[19] N. Paladi, C. Gehrmann, M. Aslam, and F. Morenius, “TrustedLaunch of Virtual Machine Instances in Public IaaS Environ-ments,” in Proc. 15th Int. Conf. Inform. Security Cryptol., 2013,pp. 309–323.

[20] N. Paladi, C. Gehrmann, and F. Morenius, “Domain-based storageprotection (DBSP) in public infrastructure clouds,” in Proc. SecureIT Syst., 2013, pp. 279–296.

[21] P. Mell and T. Gance, “The NIST definition of cloud computing,”National Inst. Standards Technol., Gaithersburg, MD, USA,Tech. Rep. 800-145, Sep. 2011.

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

[23] D. Dolev and A. C. Yao, “On the security of public key protocols,”IEEE Trans. Inform. Theory, vol. 29, no. 2, pp. 198–208, Mar. 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 Operat. Syst. Rev., vol. 37, no. 5, pp. 193–206, 2003.

[25] A. Seshadri, M. Luk, N. Qu, and A. Perrig, “SecVisor: A tinyhypervisor to provide lifetime kernel code integrity for commod-ity OSes,” ACM SIGOPS Operat. Syst. Rev., vol. 41, no. 6, pp. 335–350, 2007.

[26] F. Zhang, J. Chen, H. Chen, and B. Zang, “Cloudvisor: Retrofittingprotection of virtual machines in multi-tenant cloud with nestedvirtualization,” in Proc. 23rd ACM Symp. Operat. Syst. Principles,2011, pp. 203–216.

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

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

[29] A. Michalas, N. Komninos, N. Prasad, and V. Oleshchuk, “Newclient puzzle approach for dos resistance in ad hoc networks,” inIEEE Int. Conf. Inform. Theory Inform. Security, Dec. 2010, pp. 568–573.

[30] Trusted Computing Group, “TCG Specification, ArchitectureOverview, revision 1.4,” Trusted Computing Group Incorporated,Tech. Rep., 2013.

[31] B. Parno, J. M. McCune, and A. Perrig, Bootstrapping Trust in Mod-ern Computers, New York, NY, USA: Springer, vol. 10, 2011.

[32] P. Eronen and H. Tschofenig, “Pre-shared key ciphersuites fortransport layer security (TLS),” Tech. Rep., RFC 4279, Dec. 2005.

[33] B. Blanchet, “An efficient cryptographic protocol verifier based onprolog rules,” in Proc. 14th IEEE Comput. Security Found. Workshop,2001, p. 82.

[34] N. Paladi and A. Michalas, ““One of our hosts in anothercountry”: Challenges of data geolocation in cloud storage,” inProc. 4th Int. Conf. Wireless Commun., Veh. Technol., Inform. Aerosp.Electron. Syst., May. 2014, pp. 1–6.

Nicolae Paladi is currently working toward thePhD degree at the Lund University andresearcher in the Security Lab at the SICS. Hisresearch interests include distributed systemssecurity with a special focus on cloud computing,infrastructure security, Internet security, virtuali-zation and mobile platform security, trusted com-puting, as well as selected topics on privacy,anonymity, and personal data protection.


Christian Gehramann received the PhD degreefrom the Lund University and is also an associateprofessor at the Lund University. He is headingthe Security Lab at the SICS. The security lab hasaround 12 members and is performing appliedresearch in security in virtualized systems, secu-rity for IoT, cryptography, authentication theory,security in cellular networks, and on the Internet.He has conducted communication and computersecurity research for more than 20 years.

Antonis Michalas received the PhD degree innetwork security from the Aalborg University,Denmark, and later he worked as postdoctoralresearcher at the Security Lab, SICS. He is cur-rently an assistant professor at the University ofWestminster in London, United Kingdom. Hisresearch interests include private and secureevoting systems, reputation systems, privacy indecentralized environments, cloud computing,and privacy preserving protocols in participatorysensing applications.

" For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


ieee transactions on cloud computing, e-mail: {nicolae, chrisg}@sics.se, a.michalas@ . manuscript...

Documents