IEEE TRANSACTIONS ON CLOUD COMPUTING 1 A …bxb/Papres/2016.5.pdf · A Protocol for Preventing Insider Attacks in Untrusted Infrastructure-as-a ... isolated environment without

IEEE TRANSACTIONS ON CLOUD COMPUTING 1

A Protocol for Preventing Insider Attacks inUntrusted Infrastructure-as-a-Service Clouds

Imran Khan, Zahid Anwar, Behzad Bordbar, Eike Ritter, and Habib-ur Rehman

Abstract—Recent technical advances in utility computing have allowed small and medium sized businesses to move theirapplications to the cloud, to benefit from features such as auto-scaling and pay-as-you-go facilities. Before clouds are widelyadopted, there is a need to address privacy concerns of customer data outsourced to these platforms. In this paper, we presenta practical approach for protecting the confidentiality and integrity of client data and computation from insider attacks such ascloud clients as well as from the Infrastructure-as-a-Service (IaaS) based cloud system administrator himself. We demonstratea scenario of how the origin integrity and authenticity of health-care multimedia content processed on the cloud can be verifiedusing digital watermarking in an isolated environment without revealing the watermark details to the cloud administrator.Finally to verify that our protocol does not compromise confidentiality and integrity of the client data and computation or degradeperformance, we have tested a prototype system using two different approaches. Formal verification using ProVerif tool showsthat cryptographic operations and protocol communication cannot be compromised using a realistic attacker model. Performanceanalysis of our implementation demonstrates that it adds negligible overhead.

Index Terms—Cloud Computing, Trusted Computing, Protocol, Late Launch, Digital Watermarking

F

1 INTRODUCTION

CLOUD Computing is an exciting and promisingnew paradigm that allows clients to outsource

storage and computational resources on demand.While cloud computing bases on current technologiessuch as virtualization and service oriented architec-ture, the major driving factors of this technology arethe advancement in machine architecture, the require-ment to process and/or maintain large data sets andhigh bandwidth network channels. Additionally, fea-tures such as multi-tenancy, auto-scaling and low costenables cloud computing to flourish more successfullythan its predecessor- the Grid.

One third of the IT company respondents in a recentcloud computing survey [23], stated that they arealready using cloud based services. An additional 40%respondent companies are in a transitionary phase to-

• Imran Khan is with the Department of Computer Science, NationalUniversity of Computer and Emerging Sciences, FAST-NUCES, Is-lamabad, Pakistan. E-mail: [email protected].

• Zahid Anwar is with the National University of Science and Tech-nology (NUST), Islamabad, Pakistan and with the University ofNorth Carolina at Charlotte, USA. Emails: [email protected],[email protected].

• Behzad Bordbar is with the School of Computer Science, University ofBirmingham, Edgbaston, Birmingham, UK.E-mail: [email protected].

• Eike Ritter is with the School of Computer Science, University ofBirmingham, Edgbaston, Birmingham, UK.E-mail: [email protected].

• Habib-ur Rehman is with the Department of Computer Science atAl Imam Mohammad Ibn Saud Islamic University (IMSIU), Riyadh,KSA. E-mail: [email protected]

• This work was conducted at and supported by the National Univer-sity of Computer and Emerging Sciences (FAST-NUCES), Islamabad,Pakistan, National University of Sciences and Technology (NUST),Islamabad, Pakistan and University of Birmingham, Birmingham, UK.

wards adopting cloud based services. Recently iCloudhas played the role of a crime fighter [24], servingto track down the iPhone of a passenger which wasstolen on a cruise ship. In this work, our focus ison the Infrastructure as a Service (IaaS) based cloudmodel. As IaaS resides at the lowest level, it allowsthe development of verifiable security solutions andthen layer the software stack on top of it.

Companies are adopting cloud based IT solutionsas public clouds become the source of a rich andnovel range of IT solutions ranging from massive on-line collaborative content storage to health-care work-flow management systems. At the converse, the wideadoption of cloud based services is badly sufferingdue to confidentiality and security concerns especiallyfrom insider attacks [1]. One way to ensure confi-dentiality in the cloud environment is to constantlystore customer data in encrypted form and decryptit on the cloud platform on the fly when being re-trieved or being operated on. However this approachis not practical due to its high computational cost[43][44] and in case of a untrusted cloud platformthe confidentiality of the data can be compromisedat the point the data is decrypted for computation.Researchers have proposed homomorphic encryptionschemes [2], that allow computations to be carriedout on encrypted content, producing an encryptedresult which, when decrypted, matches the result ofoperations performed on the plaintext. However sofar only primitive operations are supported and thereis a large amount of overhead. Moreover there is astrong requirement to make the operations of the IaaSbased cloud transparent to clients. That means thatclients be able to verify the underlying cloud platform


and services, to ensure that the platform owner isnot compromising the integrity and confidentiality oftheir data and computation.

In current research work [12][11], on cloud plat-forms security has predominantly focused eitheron protecting these platforms from malicious cloudclients or on protecting cloud clients from each other’sunwanted activities. The problem of protecting clientsfrom the possible malicious acts of insiders such ascloud providers is not adequately addressed. Thereare organizations, for instance health-care and mil-itary, which are hesitant to move to cloud basedservices due to confidentiality concerns. Thereforepractical solutions in this direction are required forwide adoption of cloud based services.

In this paper, we propose an approach to ensure theconfidentiality and integrity of client data and com-putation on the cloud platform. This is to ensure thatprivate data is not exposed to internal parties suchas the cloud administrator and other cloud clients.Our approach makes use of remote attestation [4],and a late launch based technique, called Flicker [29],to verify the integrity of the cloud platform. Thistechnique secures the virtual machine (VM) launchoperation and further allows the launched VM to per-form operations on sensitive data in full isolation. Totest our approach, we have implemented a prototypeby extending a popular open source cloud computingsolution known as Eucalyptus [15]. The extra integrityverification processing overhead of our approach isfound to be minimal. To illustrate the practicality ofour proposed protocol, we have demonstrated how itcan be used to verify presence of a hidden watermarkin a health-care multimedia context. This is done in amanner that preserves the confidentiality of the wa-termark contents and the integrity of the verificationprocess. The contribution of our work is as follows:

• We propose a protocol for secure launch of aclient VM on a trusted cloud node. Other thansecure launch, our second proposed protocol en-ables a client to protect the confidentiality andintegrity of its data and computation from otherclient applications in the cloud and from thecloud system administrator.

• In our proposed protocol architecture, the TrustedComputing Base (TCB) is reduced to the sizerequirement of the Flicker based code executedand its input and output. The software stackfrom the BIOS up to the virtual machine monitor(VMM) level is thus removed from the suggestedTCB of client sensitive code executed on the cloudplatform.

• In a virtualized cloud environment, past systemconfiguration cannot guarantee current or futuretrustworthiness of a system. We have shownhow to provide assurance to clients in such anenvironment.

• We have verified the confidentiality and integrity

security properties of our proposed protocols us-ing the ProVerif automatic cryptographic protocolverifier. We have also verified that our proposedprotocols are secure against man-in-the-middleattacks.

The rest of the paper is organized as follows. Sec-tion 2 provides background knowledge about TrustedComputing, cloud virtualization environments andprotocol verification. The design and details of ourproposed protocols are presented in Section 3. Imple-mentation details are presented in Section 4. Verifica-tion of security properties of our proposed protocolsis discussed in Section 5. Evaluation is presented inSection 6. Section 7 provides a review of related workand existing research. Finally, we have concluded thediscussion on our work in section 8.

2 PROBLEM BACKGROUND

2.1 Trusted ComputingMajor hardware vendors, including Intel, Dell and HP,have founded a consortium called Trusted ComputingGroup (TCG). The objective of this group is to buildtrust in computing devices such as PDAs, mobiledevices and PCs and to provide a transparent viewof the platform software stack to its owner. Accordingto the TCG specifications [20], all electronic devicescomplying with TCG standards should be equippedwith a hardware chip called Trusted Platform Module(TPM) [20]. A TPM is a secure storage area wherecryptographic keys and other secure data can bestored. The key and data stored inside the TPM isprotected from malicious alteration. The data storedinside the TPM normally includes platform configu-ration status. The platform status stored inside TPMcan then be provided to external entities, through aprocess called Remote Attestation, to convey platformtrustworthiness. The Trusted Computing Base (TCB)of a system is the collection of all hardware, firmware,and/or software modules that are vital for the securityof the overall system. Any vulnerabilities occurringinside the TCB can compromise the security of theentire system.

2.2 Remote AttestationIn remote attestation, the platform (firmware andsoftware) configuration is captured and stored in atamper resistant and cost effective chip called a TPM.Confidential information is held inside the TPM andis then signed and reported to a remote entity forverification and attestation purposes. This entire pro-cess is termed as remote attestation by the TCG [20].In remote attestation, to the TPM chip some form ofintegrity measurement system such as Linux IntegrityMeasurement Architecture (IMA) [21], is needed togenerate and report the attestation of the system to theremote entity. TPMs [20], store platform integrity in


the form of hashes of loaded software in data registerscalled Platform Configuration Registers (PCRs). Quoteoperation is used to attest the values of TPM PCRs.TPM Quote comprises of a subset of PCRs values to-gether with a nonce all signed by a TPM EndorsementKey (EK). The private part of the EK is used forsigning purposes during Quote generation and is usedto convince remote verifiers that assertions in the TPMQuote have been signed by a trusted TPM.

2.3 VirtualizationAccording to Sempolinski et al. [28], there are six fun-damental components of a generic cloud computingstack; (1) hardware and OS, (2) VMM, (3) VM diskimage archive, (4) front-end, (5) network and (6) cloudframework. Among these, virtualization is the keyenabling technology of an IaaS based cloud. Virtual-ization, cost effectively abstracts system resources andsupports multiple and heterogeneous operating sys-tems simultaneously on a single hardware platform.In addition to the computation resources, the net-working resources are also virtualized. Xen and KVMare two of the most popular open source VMMs [28].A typical VMM generally includes a hypervisor whichin turn supports and executes multiple clients VMs.Particularly in case of Xen a special administrativeVM called dom0, runs and controls client guest VMs.The dom0 VM runs under the control of a platformowner.

2.4 Late LaunchLate launch [20], commonly refers to technologies thatallow the execution of a secure kernel or secure VMon a system after running un-trusted software. Thismeans that the chain of trust is not started fromsystem boot but is rather initiated dynamically at alater stage. Certain family of processors from bothIntel and AMD provides an implementation of thistechnology. Intel named its implementation ’TrustedeXecution Technology (TXT)’ [30] while AMD callstheir technology ’Secure Virtual Machine (SVM)’ [3].

TPM v1.2 allows for dynamic PCRs (PCRs 17-23),which can be reset without rebooting the system. Latelaunch on Intel systems consists of calling the GET-SEC [SENTER] instruction in CPU protection ring0,which takes as an argument a physical memory ad-dress range. This memory range is called MeasuredLaunch Environment (MLE). The processor protectsthe MLE against various attacks through hardwarebased defenses. The processor disables direct memoryaccess (DMA) to the MLE memory pages. Interruptsand debuggers are also disabled to protect the MLElaunch.

To invoke a late launch with SENTER, first of allthe Authenticated Code Module or ACMod must beloaded into memory. The ACMod is then executed af-ter the platform’s chipset (with its built-in public key)

verifies the signature and extends its measurementinto PCR 17. ACMod then measures the equivalentof an AMD SLB i.e. Measured Launch Environment(MLE) [30], extends the measurement into PCR 18,and then executes it. For further information, we referthe reader to Flicker [29].

2.5 Sealed StorageOne of the key features provided by the TPM for se-curing sensitive code and data is sealed storage. A TPMcontains a special 2048-bit key called Storage Root Key(SRK). The private part of the SRK never leaves theTPM in plaintext. The storage key is used to seal otherdata and sensitive information. The seal operationtakes a set of PCRs as input, and then encrypts thegiven data using the SRK. The seal operation outputscipher text C along with the list of PCRs provided andits corresponding values.

The corresponding unseal operation takes ciphertext C and the PCRs list as input. It then comparesthe PCRs list against their current values. It decryptsC only if a match occurs and then decrypts thesuggested data. All these operations take place insidethe TPM.

2.6 FlickerFlicker [29], is an infrastructure based on late launchtechnology for secure execution of a small piece of se-curity sensitive code, called Piece of Application Logic(PAL), on systems where BIOS, OS and DMA devicesare not trusted. A PAL is a piece of application logicthat performs a well defined task. Flicker executes thePAL in full isolation on the system from all other soft-ware and hardware (including OS and VMM). Thisisolation is possible due to hardware enhancementsin modern commodity platforms from both Intel andAMD (AMD’s secure virtual machine Technology andIntel’s TXT). On Intel platforms, invoking a Flickersession suspends the current execution environment(OS and VMM) and then executes the SENTER in-struction for setting up the secure environment forPAL execution. At the end of Flicker session, theprevious execution environment is resumed.

The main goal of the Flicker architecture is to mini-mize the mandatory TCB of a security sensitive code.Thus, the attestation provided is both meaningfuland provable to a remote party due to a small TCB.Fig. 1 shows the minimization in TCB by using Flicker.Suppose we want to execute App n, which containssecurity sensitive code S. The left hand side of Fig. 1shows the execution of App n in a standard model.Here the shaded region shows the suggested TCB ofApp n. In a standard model the chain of trust startsfrom machine boot. The suggested TCB in this case isvery large and consists of BIOS, boot loader, OS and soforth. The right hand side of Fig. 1, shows the scenariowhen Flicker is used. In this case, the suggested TCB


Fig. 1. TCB of applications running with and withoutFlicker protection [29]

is minimized, and includes CPU (in some situationsadditional chipsets), TPM and the Flicker frameworkused to execute security sensitive code S in completeisolation.

2.7 Protocol Verification

We will later define security protocols for secure VMlaunch and secure computation. As the adversary isactively looking for weaknesses, correctness of secu-rity protocols is very important. However, significantflaws have been found in widely used protocols, oftenyears after the protocol has been defined. Examplesare the Needham-Schroeder public-key protocol [33]which was found to have a serious flaw 17 yearslater [34], the SAML-based Single Sign-On for GoogleApps [35], or the still re-occurring flaws in widelyused protocols such as openssl [36] and openssh [37].Formal models have been developed for reasoningprecisely about security protocols in order to detectsuch flaws. Models based on process calculi (e.g. ap-plied pi-calculus [38]) model the participants in asecurity protocol as processes and the messages ascommunication between processes.

Automated tools for the verification of securityprotocols based on these models have been devel-oped, e.g. ProVerif [39] and SATMC [40]. We willuse ProVerif which is well suited to handle the kindof security property required in this paper. We willverify a correspondence property, which states thata certain event is always preceded by another event.This property enforces that the decryption of a virtualmachine happens only with a key that the client hassent.

3 DESIGNIn the first part of this section, we will introducethe two definitions ”Level I security” and ”Level IIsecurity” that are frequently used in the rest of thepaper and are very significant to our protocol design.

3.1 Level I vs Level II securityTrusted Computing and remote attestation enable aremote party to challenge a given platform and verifyits security properties remotely. If the current state ofa system is successfully verified, the remote party cantrust this system for future operations. Here we intro-duce two definitions related to Trusted Computing.

Definition 1

Level I security: Platform Integrity Attestation, wherebefore transferring computation and data, a remoteparty verifies through remote attestation, that thetarget platform belongs to the actual cloud hostingprovider as well as executes trustworthy hardware,firmware and software. The client can then trust thechallenged platform after verifying its current statethrough remote attestation for future operation.

Definition 2

Level II security: Integrity and confidentiality, wherea remote party not only verifies the integrity of thetarget platforms hosting provider, hardware, firmwareand software but also requires additional securitymeasures to ascertain that the confidentiality andintegrity of sensitive operations executed on the targetplatform will not be compromised. Level II securityassurance can be provided with Intel TXT technologybased mechanism called Flicker and will be detailedin the coming sections.

Trusted Computing and remote attestation is basedon the concept of trust. If we verify the current statusof a platform using remote attestation which showsthat the platform current status is trustworthy thatmeans that the platform is running some well-knowngood software stack (configuration). Then tradition-ally [17][18], on the basis of current trust the platformis trusted for future operations. The basis for thisargument is that if the current platform status is well-known and trustworthy then the platform is likelyto behave expectedly in the future and hence canbe trusted for future operations. Our above Level Isecurity definition corresponds to this property.

Now consider a cloud virtualized environment withthe system administrator running in dom0 and con-trolling the overall environment of the cloud NodeController (NC). After initial attestation to the client,the system administrator can then run any arbitraryprocess in dom0, get access to client memory andcan thus compromise his data confidentiality andintegrity. It shows that the client cannot trust thecurrent cloud node configuration on the basis of aprevious verification. Therefore, only Level I securityassurance is not sufficient for the virtualized cloudenvironment.

According to our proposed protocol, the client firstverifies the platform configuration before launchinghis VM in the cloud. After VM launch, the clientcomputation on normal data is performed as usualin the cloud environment. However, when the clientwants some computation on highly sensitive data


then it cannot simply rely only on Level I security.As the client has previously verified cloud platformduring VM launch then according to Level I securityit can trust the platform for sensitive computation aswell. However, the problem is that the cloud systemadministrator can run an arbitrary process in dom0after initial verification and hence can compromiseclient confidentiality and integrity. Therefore, we pro-pose Level II security whereby computation on clientsensitive data is performed in full isolation fromthe cloud system administrator. Such assurance isachieved through our proposed approach based onlate launch and the Intel Trusted eXecution Tech-nology (TXT) hardware based mechanism, Flicker.Flicker architecture employs a TPM chip based onIntel’s Trusted eXecution Technology (TXT) for stor-age of session configuration representing a hash ofthe computation. After launch of the Flicker sessionthe Flicker specific kernel executing user sensitivecomputation has isolated access to the full platformprocessing capabilities.

In terms of security requirements, cloud clients canbe divided into two broad categories. One categoryof clients fully trusts cloud providers for its dataand encrypted form on the CS and computation. Forexample, a banking application wants to find the hourof the day at which the highest number of clients havevisited the bank. The other category of clients needsstrong assurances from the cloud platform owner inorder to trust it for its sensitive data and computation.For example, a health-care application wants to findthe address of a particular patient without revealingprivate attributes, such as the type of disease, insidethe cloud platform.

We propose that there should be two different setsof infrastructure within a cloud for these two differentcategories of clients. For the first category, the currentcloud offering with isolation provided by the under-lying virtualization technology is sufficient. However,for the second category of clients, NCs should beequipped with a TPM chip and have support for latelaunch mechanism. The primary goal of our proposedprotocol architecture is to support the security needsof the second category clients.

Here we present a protocol architecture for secureVM launch and for ensuring a secure execution en-vironment for client sensitive data and computationinside a client guest VM on a cloud platform. Fig. 2shows a general cloud design. The client VMs arestored on Cloud Storage (CS). For a security sensi-tive client, its corresponding VM will be stored inencrypted form on CS. The Client VM executes onthe NC whereas the Cloud Controller (CC) providesan interface to the client. For the protocol detailsdescribed in this section, we assume the case of asecurity sensitive client on an Intel machine.

Cloud Controller: Eucalyptus, OpenStack, Open Nebula

User

DHCPDNS

Node Controller (NC)

Hypervisor

VM VMCloud

Storage

Fig. 2. Generalized architecture of a cloud environ-ment

3.2 Secure VM LaunchThe client VM is stored in an encrypted form on theCS, so that it can only be launched on trusted NCs.The purpose of the secure VM launch protocol is toget the VM decryption key DkVM securely from theclient, decrypt the VM and then launch it on a trustednode.

The protocol proceeds in two phases. In the firstphase, we certify the public keys of the client (pkc)and Flicker (pkf ). This is performed by using theTPMs of the client and the NC to establish a securechannel between the client and the Flicker session-using the secure channel protocol of Flicker [29].

In the first step, the client sends a request to theNC for its VM launch. When the NC receives thisrequest, it initiates a Flicker session and executes PALP and extends PCR 18 with the measurement of PALP and with its input and output (Flicker session con-figurations). P is an application code used to generateFlicker asymmetric keys and support the VM decryp-tion process. Here we represent the private and publicportion of the Flicker asymmetric key by Pkf andpkf respectively. The private part of the asymmetrickey Pkf generated inside Flicker is then sealed for thesubsequent invocation of the same Flicker session. Thepurpose of this asymmetric key pair is to get the VMdecryption key DkVM securely from the client. In thenext step, NC then sends the Flicker public key pkf

and the TPM Quote of the system to the client. WhenNC generates a Quote, it includes the value of PCR18 in the Quote operation and hence Quote reflects theFlicker session configurations signed with the TPMprivate key. Attestation from the Flicker session canconvince the client that the PAL P executed insideFlicker protections and that the public key pkf wasa valid output of the session. After verifying the TPMQuote the client then establishes a secure channel tothe Flicker session.

Inside the Flicker session, PCR 18 is extended withthe measurement of PAL and with its input andoutput (Flicker session configurations). The output inthis case is the public part of the Flicker asymmetric


Decrypt VM with

DkVM

{na , pub(Pkc)} pub(Pkf)

NC

TPM Flicker Session

{na , nf } pub(Pkc)

{ nf , DkVM} pub(Pkf)

Client

{na , pub(Pkc)} pub(Pkf)

{na , nf } pub(Pkc)

Makes VM available to NC

{ nf , DkVM} pub(Pkf)

Fig. 3. Secure VM launch protocol

key pkf generated inside the Flicker session. In thisway, extending the measurement of PAL output intoPCR 18 enables the NC to convince the client thatthe Flicker asymmetric key pkf was indeed generatedinside Flicker protection. The client can check thevalue of PCR 18 in the TPM Quote to verify whether alegitimate PAL was executed and the asymmetric keypkf was indeed generated inside the Flicker session.The client can verify this by re-computing the SHA1hash of the PAL and its output (asymmetric key inthis case) and matching it with the value of PCR 18.If the NC self generates the asymmetric key pkf andsends it to the client, the client will see a difference inthe value of PCR 18 from the Quote sent by the NC.

The second phase consists of the protocol to se-curely communicate the VM decryption key DkVM

to the Flicker session and is illustrated in Fig. 3.Here Pkc and Pkf are the private keys of the clientand the Flicker respectively and pub is the functiongenerating the public key from the private key. na

and nf are nonces which are used to protect againstreplay attacks. According to our protocol, the clientsends NC the nonce na and its public key pkc, bothencrypted with the Flicker public key pkf . Therefore,the message can only be decrypted inside the Flickersession. The NC then initiates a Flicker session withthe client message as its input.

Inside the Flicker session, the nonce and the publickey of the client pkc are verified. After verification,the Flicker generates a new nonce nf . The nonce nf ,the public key of the client pkc and the private key ofthe Flicker session Pkf are stored in the TPM usingsealed storage. Flicker then returns nonces na and nf

encrypted with the client public key pkc so that onlythe corresponding client can decrypt the message.The NC then forwards the message to the client. Theclient then verifies nonce na from the message to

Node Controller (NC)

Hypervisor

Dom0 Guest__________

__________

... PAL

PAL

Flicker Session

TPM

Fig. 4. Confidentiality sensitive computation

make sure that the message was indeed sent fromthe corresponding Flicker session. The client then con-structs a message with the VM decryption key DkVM

and nonce nf encrypted with Flicker public key pkf .The message is then forwarded for the correspondingFlicker session to the NC.

The NC then captures the message and initiates an-other Flicker session and provides the client messageas its input. Inside the Flicker session the nonce nf ,the public key of the client pkc and the private key ofFlicker Pkf are read from sealed storage. The noncenf is verified and then the VM is decrypted withthe decryption key DkVM . The decrypted VM is thenmade available to the NC which launches the VM andconnects the client to its VM. The sealed storage is usedas described in Section 2.5 above, ensuring that onlysame Flicker sessions can read or write this storage.

3.3 Confidentiality Sensitive ComputationAfter secure VM launch through the protocol pro-posed in section 4.2, the next step is to ensure theconfidentiality of client sensitive data and computa-tion. Here we present a protocol for confidentialitysensitive computation based on Level II security.

The computation inside the security sensitive clientVM is divided into two categories, normal computa-tion and security sensitive computation. The normalcomputation takes place as usual on the virtualizedplatform with the system administrator running indom0. The same procedure however, cannot be fol-lowed for security sensitive computation as an in-sider such as the system administrator can run ar-bitrary processes in dom0 and can compromise theconfidentiality of client data and computation. Theintegrity information exchanged during VM launchcannot guarantee this protection.

In our proposed protocol the computation on sensi-tive data is organized as PAL, which executes insideFlicker protection. The sensitive data is only visibleto the client PAL inside the Flicker session and isprocessed there in full isolation from the rest of thesystem, as shown in Fig. 4. In this way, confidentiality


Flicker Session

Guest VM Client

{nc , pub(Pkc)} pub(Pkf)

{nc , ng } pub(Pkc)

{ng , Dkf} pub(Pkf)

get Dkf

decrypt f Process f

Fig. 5. Confidentiality sensitive computation protocol

of client data is enforced. Consider as way of illus-tration that the client has a confidential file f storedin encrypted form on the NC. He wishes to performsome computation on f, without revealing its contentto cloud NC system administrator.

Similar to the protocol used for secure VM launch,we first establish a secure channel between the clientand the Flicker session using the TPM. The detailedprotocol which is used afterwards is shown in Fig. 5.The client starts by forwarding a nonce nc andpub(Pkc) to its VM on the Node Controller (NC).The client VM then executes PAL C inside Flickerprotection. After verifying nonce nc and client publickey pkc, the Flicker then sends nonce nc and its nonceng encrypted with the client public key pkc to its VMrunning on the NC. The client VM then forwardsthe message from the Flicker session to the clientapplication.

After verifying nonce nc, the client then forwardsthe message containing file f decryption key DKf

along with nonce ng encrypted with Flicker public keypkf to the Flicker session on the NC. The client guestVM on the NC captures the messages, initiates theFlicker session and forwards the message as input tothe session. In this way, the DKf will only be acquiredby PAL C executed inside the Flicker session. Theclient VM subsequently executes PAL C inside Flickerprotection and decrypts file f with DKf . File f is thenprocessed inside the Flicker session and the resultis then returned to the client VM after processing finside Flicker protection. The entire process showsthat f is only visible in plaintext inside the Flickersession. In this way, the client can perform sensitivecomputation on the cloud node in full isolation fromthe underlying NC software stack. In this way, clientconfidentiality is ensured, protecting the data fromother guest VMs and the NC system administrator.

3.4 Privacy-preserving watermark verification ofhealth-care data on the cloud

We present a scenario based on the proposed ap-proach for ensuring patient privacy by protectingdata confidentiality and integrity of the watermark[42] verification process on an untrusted cloud forlaboratory test results in the health-care domain. Wa-termarking is a method of secretly transferring digitalinformation through a carrier signal, such as an image.Here we consider as an example multimedia contentfrom a particular health-care scenario. A public figuresuch as a politician (John) is admitted to clinic C formedical treatment. There is a strong requirement thatthe particulars of the medical condition of the visitingpolitician be kept highly confidential. John’s physicianat C decides that Magnetic resonance imaging (MRI)of John’s head is required for diagnosing his ailmentand as a result John visits laboratory L for his headMRI.

C hosts health-care application, P for managingpatient data on a cloud platform. Johns‘ MRI imagemust be transferred from L’s database to P in orderto diagnose Johns‘ disease. As the cloud platformis potentially untrusted, there are two main require-ments for the MRI image to be transferred from L toP. Firstly, in order to ensure confidentiality of Johns‘medical data, the MRI image should be transferredfrom L to P in such a manner that the information-watermark in the MRI image should only be viewableto P. Secondly, the application will necessitate non-repudiation or undeniable information (a proof) fromL that the MRI image for patient John was indeedforwarded by L. This is necessary for C, so that incase of a conflict, a wrong MRI image (for example aforgery) sent by the laboratory or an attacker, it maybe easily detected.

Using digital watermarking, L secretly transfers toP, the MRI image along with a unique watermarkM as proof of origin. The pseudo code for hiddenwatermark transfer along with Johns‘ MRI image isshown in the Table 1. In the given pseudo code,L first creates a watermark M that combines thepatient ID and the Lab-ID of L. The watermark Mis then embedded into MRI image I using Watermarkencoding algorithm A and session key K, creating awatermarked image I . Session key K is used in theembedding process so that only the receiver with keyK can decode the image for the given watermark. Fornon-repudiation and integrity check, L signs the hash(SHA1) of I and stores it in i. For secure transfer, keyK is encrypted with P’s public key pkp and stored insec. L then forwards the watermarked image (I), signswatermark image hash (i) and forwards the encryptedkey (sec) to P.

P first verifies the signature and then the integrityof the received watermark image by re-computinghash of I and comparing it with i. As the cloud


Notation: I: Image to be watermarked; !: Watermarked image; K: Session key A: Watermarking algorithm; P-ID: Patient ID; Lab-ID: L laboratory ID "#$: Private key of L laboratory; %#$: Public key of L laboratory "#&: Private key of P cloud application %#&: Public key of P cloud application Pseudo code: L laboratory: M ← (P-ID, Lab-ID) // Generate a watermark !← encode.A(I, K, M) // Embed a watermark (← "#$ (hash(!)) // For non-repudiation and integrity check sec← %#&(K) // Encrypt K with P public key

L laboratory ),(,+,-.////0 P cloud application

P cloud application: P verifies signature and applies integrity check using !, ( , %#$ Flicker(!, 123) // P initiates flicker session K ← "#&(sec) // Gets session key K to decode ! M ← decode.A(!, K) // Gets embedded watermark M Gets P-ID // Gets patient ID Gets Lab-ID // Gets Lab-ID of L laboratory

TABLE 1Digital watermarking application running under

Flicker-based isolation

platform is untrusted, P then checks the watermarkinside the Flicker session using the following pro-cedure: sec is first decrypted using P’s private keyPkp, to get key K. Watermark M is then obtained byusing the watermark decoding algorithm A, sessionkey K and watermark image I . The patient ID andLab ID is then verified from the obtained watermarkM. As watermark is obtained and checked for thepatient ID and Lab ID inside the Flicker session, itsvalue remains confidential from the cloud platformadministrator, other super users and clients.

4 IMPLEMENTATIONIn this section, we present a brief description ofour proof-of-concept implementation of the proposedprotocol architecture.

For the realization of remote attestation, we usedthe most popular and widely used approach calledIntegrity Measurement Architecture (IMA) [21]. IMAis based on binary attestation. When configured, IMAcalculates and extends hashes of all software com-ponents loaded after the boot process into relevantPCRs. To preserve privacy of the NC, we have usedthe Attestation Identity Key (AIK) for signing PCRsvalues during the Quote generation. We have used aTrusted Java [6] based software stack known as JavaTrusted Software Stack (jTSS) for communicating withthe TPM through the TPM driver.

We have used the open source IaaS based cloud-Eucalyptus for our testing due to availability of itsvarious modular features such as CC and NC. Thedesign of Eucalyptus [15], is an open-source answerto the commercial Amazon EC2 cloud and is API-compatible with EC2. Other open source IaaS basedcloud systems such as OpenStack [25], Nimbus [27]and OpenNebula [26], may also be used. Most ofthese platforms have the ability to be deployed asan overlay on top of highly decentralized resourceconfigurations, for instance multiple clusters, work-station pools, distributed storage, and locally storedrunning virtual disks. Eucalyptus in particular hasa hypervisor-agnostic architecture and supports twowell known hypervisors, Xen and KVM. The ma-jority of Eucalyptus components have well definedweb-service based interfaces (described by WSDLdocuments) and are developed using standard Web-services packages such as Apache, Axis2 and Ram-part.

The NC is the core component of the Eucalyptuscloud where client VMs execute and is a major focusof our discussion. In our particular implementationthe Eucalyptus NC is an HP elitebook 8560 laptopwith 2.2 GHz processor and 4 GB of primary memory.NC is running Linux kernel 2.6 in dom0 and Xen isused as VMM. Eucalyptus NCs are divided into twogroups, one for normal clients and one for securitysensitive ones. For security sensitive clients, the NCis also equipped with a TPM chip and supports theIntel TXT technology.

As a typical cloud based VM can be up to 2GB in size, it will be computationally infeasible toencrypt or decrypt the entire VM. A VM normallyconsists of three images: a boot disk image, a kernelimage and an initial ramdisk image. Therefore, froma performance prospective, it is desirable to encryptonly that portion of a VM image which is importantfrom a security point of view. The kernel is themost fundamental part of the operating system ofa VM, and supports user level application requestsvia system calls. We want to ensure that a clientVM is running with a client provided trusted kernel.Therefore, instead of encrypting the entire VM, weencrypted only the kernel. The Linux kernel we usedin our experimentation was 50 MB in size. Therefore,here in our discussion, whenever we mention VMencryption or decryption, we are only referring to thekernel.

The Eucalyptus NC is the central point of ourdiscussion, as client, VMs actually execute on the NC.In the original Eucalyptus design, the NC receivesa request from the CC for VM launch which thenlaunches the VM from the CS. However in case ofthe security sensitive group of NCs, the VM to belaunched is stored in encrypted form on the CS. Afterreading an encrypted VM from the CS, the NC firstexecutes a special PAL P inside the Flicker protection,


by calling the SENTER instruction. P is trusted bythe client and includes the functionality needed tosupport getting the VM decryption key DkVM fromthe client. After getting the VM decryption key DkVM

using the protocol described in the previous section,the NC then launches the VM and connects the clientto its VM.

According to default Flicker implementation, thePAL can have a maximum size of 512 KB and can haveinput and output as a maximum size of 116 KB. Wehave made changes to the Flicker code to allow it toread encrypted VM as input and to return a decryptedVM as output. We then pass the VM image and itsdecryption key as input to the Flicker session fordecryption, so that it can be launched after returningfrom the Flicker session. The VM is then decryptedinside the Flicker session, and is made available to theNC as output of the Flicker session. The decryptedVM is then launched by the NC. In this way, VMlaunch is restricted to trusted NC only.

5 VERIFICATIONThe suggested protocol ensures confidentiality andintegrity of the clients’ data. We use ProVerif [39]to automatically verify that the data is not revealedto the attacker and that the protocols proposed donot suffer from man-in-the-middle attacks. Checkingthese two properties is sufficient to ensure confi-dentiality because we show that only the client canaccess the data, and secondly no other principal canmasquerade as the client. We make the followingassumptions:

• The attacker has access to all communication(except the communications on private channels).We assume that the cloud provider may be partof the attacker.

• The attacker may modify, replay and re-arrangemessages but not break cryptography.

• Neither the Flicker session nor the TPM nor theclient is compromised. However, the attacker caninteract with the Flicker session.

• The public keys of the client and Flicker can beused to provide a secure communication channelbetween the client and the Flicker session. Forthis purpose we use the TPM as described insection 2.2.

ProVerif is based on the applied pi-calculus [38],which models a security protocol as follows: Agentsare modeled as processes, and messages betweenagents are modeled as communication between pro-cesses. The attacker is modeled as the environmentand hence has access to all communication (exceptthe communications on private channels).

ProVerif transforms the protocol specified as a pro-cess into Horn clauses. The Appendix at the end ofthis paper lists the ProVerif code. There are two files,one for the verification that only the client can access

the data, and the other one for the verification thatman-in-the-middle attacks are not possible. The givencode consists of the following parts:

• Description of the channels involved in the pro-tocols (line 3-7).

• Description of the cryptographic operations suchas symmetric and asymmetric encryption (lines8-19).

• The property that only the client can access thedata is formalized as the property that the at-tacker does not get access to the virtual machineof the client (line 23).

• The absence of a man-in-the-middle attack ismodeled by the query whether one event (theFlicker session has received the key for the virtualmachine) is always preceded by another uniqueevent (the client has sent the key for the virtualmachine) (line 22-29).

• Description of client and the Flicker session (lines31-56).

Since we assume that the attacker has access to ring0 and therefore has full access to the node controller,the node controller is effectively part of the attacker.Hence there is no agent (process) corresponding to thenode controller in our model.

When we run ProVerif on both files, it terminatesvery quickly and shows that both queries are true. Allthree protocols were verified and satisfy confidential-ity.

The integrity of the data is guaranteed as the virtualmachines are encrypted with a key which is knownonly to the client.

6 EVALUATION AND DISCUSSIONAlthough we conducted our experimentation on Intelbased machines but the work can easily be adapted toan AMD based architecture. On an AMD architecture,the SKINIT instruction is used to invoke a Flickersession whereas in our Intel based machine the Flickersession is started with GETSEC [SENTER]. Howeverthe security property and protection provided by aFlicker on both machines is similar. On an Intel ma-chine, the attestation requires at least PCRs 17 and 18to be sure that a given PAL is executed inside Flickerprotection. While in case of an AMD architecture itis reduced to only PCR 17. The reason is that anAMD architecture does not use a chipset module forlaunching a Flicker session.

Our approach provides security at two differentlevels with varying TCB size. Before launching a VM,the client attests the integrity of the entire platformand the suggested TCB starts from the BIOS up to theVMM. This attestation depicts the current behaviorof the platform. After trusting the current platformbehavior and VM launch, our approach takes careof protecting client confidentiality and integrity on


Tim

e (m

s)

0

200

400

600

800

1000

1200

SE

NTE

R

PC

R E

xten

d

TPM

Quo

te

Sea

l

Uns

eal

RS

A K

ey G

en

29.43

1.27

756.37 810.3

98.9

190.6

2200

2200

VM

Dec

rypt

4.1

Pas

s D

ecry

pt

Protocol operations

Fig. 6. Performance evaluation

the NC from the cloud clients and cloud system ad-ministrator through isolated Flicker based execution.The property of our isolated Flicker based sensitivecomputation is that it has very small TCB. The sug-gested TCB consists only of Flicker code, its inputand output, and the client PAL. In our confidentialitysensitive computation protocol, input to the Flickersession is an encrypted file and Flicker output is theresult of performing some computation on that file(decrypted inside Flicker). So for client based sensitivecomputation, it is not required to trust the softwarestack from BIOS up to the VMM.

Initially a guest VM needs two Flicker sessionsto perform computation on sensitive encrypted data.The first session is used to get the decryption keyof encrypted confidential data from the client. Thesecond Flicker session is then used to process thegiven data. Subsequent operations on the same con-fidential data will need only a single Flicker session,as the guest VM has now the key for data decryptionand performing operation on data inside the Flickersession.

The Flicker session suspends the normal executionof a cloud node and runs in full isolation. This canbe considered a type of financial loss to the platformowner because the platform resources are not fullyand efficiently utilized. In order to avoid the suspen-sion of normal execution on a node, McCune et al.[14] suggest an architecture to have only a subset ofCPU cores assigned to a Flicker session while normalexecution continues on other cores. This way secureand normal execution will take place at the sametime on the same cloud node. Further research isdesirable in this direction in order to enable executionof sensitive and normal code side by side on the sameplatform.

We call an outsource computation as sensitive if it

operates on some confidential data. According to ourprotocol, confidential data is only processed insideFlicker protection. So sensitive computation can onlyprocess sensitive data inside Flicker protection. Asa result, confidentiality of both data and sensitivecomputation is preserved. According to our proposedprotocol, sensitive computation executes as PAL in-side Flicker protection. Therefore a client can enforcethrough remote attestation used by our protocol thatonly client trusted outsourced computation can accessclient confidential data. Hence, clients can send de-cryption key for confidential encrypted data to onlythose Flicker sessions whose computation the clienttrusts.

In this paper, our main focus is on protection ofthe PAL from the cloud system administrator andall other software running in the system. Here wediscuss how to protect the Node Controller (NC) froma malicious PAL. The NC can only allow executionof legitimate PALs, by verifying it in some manner,e.g. using proof carrying code [9]. X86 architecturehas 4 privilege rings, with ring 0 and ring 3 beingmost and least privileged respectively. As GETSEC[SENTER] is a privileged instruction used to launch aFlicker session, therefore a Flicker session can only beinvoked by code executing in CPU protection ring 0.In this way, the NC allows execution of only legitimatePALs that it trusts or verifies in some manner [9].

Inside a Flicker session, paging is being disabledand segmentation is enabled, and the PAL is exe-cuted in CPU protection ring 3. The NC sets relevantsegment register [29], to define the memory regionthe PAL can access. The PAL executes in CPU ring 3protections and hence it can only access the memorydefined in the segment registers. We have extendedthe default input/output size to allow for VM encryp-tion/decryption. In this way the PAL can only accessthe memory limited by segment registers and cannotaccess the memory region of other processes and VMs.

Here we consider the performance aspects of ourprotocol. The performance intensive operation can becategorized into those that occur inside the Flicker ses-sion and those that occur outside. The most expensiveoperation outside the Flicker session was the TPMQuote operation which took 756.37ms (millisecond),as shown in Fig. 6. The Flicker session was invokedon the NC with the SENTER instruction with a totalexecution time of 29.4ms. PCR extend operation wasused to extend the measurement of PAL into PCR 18which took 1.27ms. The asymmetric 1024-bit RSA keyfor the Flicker was generated in 190.6ms. The sealingand unsealing of the private part of the RSA key wasperformed in 98.9ms and 810.3ms respectively. TheVM key was decrypted using 1024-bit RSA key in4.1ms. The PAL then decrypts the VM with clientsupplied 128-bit Advance Encryption Standard (AES)symmetric key which took 2.2 seconds.

As mentioned earlier, our audience is security sen-


sitive clients whose main concern is security and con-fidentiality of their data and computation. Therefore,the tradeoff overhead is acceptable for the isolationand security features obtained by using our proposedprotocol.

7 RELATED WORKOur work benefits from related work in trusted com-puting, trusted virtual machine monitors and special-ized encryption based approaches. Several approachesin the first two categories are based on reliance ona trusted hypervisor also known as trusted virtualmachine monitor (TVMM) [17][18]. The suggestedTVMM model prevents platform administrators andother super users from examining or modifying clientVMs. TVMM has the property of being able to defendits own integrity on the deployed platform. Hyper-visors are unfortunately complex software and as aresult inflate the Trusted Computing Base (TCB). Dueto hypervisors’ complexities and large TCB there aremany challenges that need to be addressed for theemergence of a practical TVMM.

Approaches that rely on a Trusted Computing

Base

We further classify approaches that make use of aTCB into two generic categories, i.e. trusted virtualmachine monitor and modified VMM. Approachesin the first category build their solution on top ofan existing TVMM assuming that it would providethe desired properties of confidentiality and integrityand a root of trust. Whereas modified VMM basedapproaches detail certain modifications to the designof existing hypervisor’s for providing desired root oftrust.

Trusted virtual machine monitor based approachesTerra [17] is one of the initial and influential re-

search works that aims to provide secure closed boxexecution environment and an open general purposesystem side by side on a single platform. Terra isbased on a TVMM to make the function of a singlenode communicating in a distributed environment,transparent. This approach protects client compu-tation integrity and confidentiality by providing aclosed-box execution environment to a user VM fromthe platform administrator interference and inspec-tion. The TVMM provides an interface to a man-agement VM for allowing the allocation of memory,storage and other resources to the client VM. TVMMallows remote parties to trust the client VM closed-boxexecution environment by providing the attestation ofthe environment to the remote parties.

A technique for achieving client computational in-tegrity and data confidentiality in an IaaS based cloudis presented in Khan et al. [22]. The technique is basedon using remote attestation and a trusted virtualmachine monitor (based on a TVMM). A trusted thirdparty is used for the establishment of trust between

cloud clients and cloud nodes. The cloud providerfirst attests and registers its nodes with a trustedthird party which in turn verifies the cloud platformproperties using remote attestation.

Modified VMM based approachesMurray et al. [19], analyzed the Xen architecture

and proposed architectural recommendations for theemergence of a TVMM based on the Xen hypervisor.In order to reduce the TCB and make the attestationmore meaningful, they presented a technique basedon disaggregation property in a Xen based envi-ronment. The technique moves the domain buildingprocess of the administrative domain into a specialdomain called DomB which is removed from the TCB.

Another approach called Self-Service Cloud (SSC)[32], attempts to restrict the privileged administrativedomain in Xen from examining client VM computa-tion and data. SSC divides administrative rights intoa per-client administrative domain and system-widedomain. The given model provides clients the abilityto manage privileged system operations related totheir own VMs.

CloudVisor [31], uses nested virtualization for pre-venting the administrative domain from encroachingupon the integrity and confidentiality of client VMs.CloudVisor divides the virtualization functionalityinto VM management and security protection. Themanagement VM is responsible for management ofclient VMs while a tiny security monitor that runsbeneath a commodity VMM such as Xen providesprotection of client VMs integrity and confidentiality.Nested virtualization however imposes high over-heads because privileged operations must be handledby both the bare-metal and nested hypervisor’s, slow-ing down I/O intensive client applications.

TVEM [10], provides a virtual environment on acloud platform to ensure protection of client data andcomputation. TVEM is a software based applianceand is supported by hardware based solutions, i.e.Intel Virtualization Technology for Directed I/O (VT-d) [13] and Trusted eXecution Technology (TXT). Sep-arate responsibilities are assigned to the informationowner and the service provider in the proposed vir-tual environment. Virtual environment is the softwarecomponent encompassing layers from the operatingsystem to the application software in the VM, and iscontrolled by the information owner. TVEM providesthe information owner the ability to attest the virtualenvironment for the desired integrity and confiden-tiality properties.

Dewan et al. [16], present a technique to guard criti-cal data of a client application running in a virtualizedenvironment where a VM may include malware. Theproposed approach uses a lightweight hypervisor forfine grained software-based run time memory pro-tection. It places application critical data in protectedmemory regions and then registers it with the clientapplication. Access to the protected memory region is


controlled by the VMM on the basis of authenticityof an application. The approach also suggests a datalocker component for the VMM to prevent leakageof the application persistent storage to malwares androotkits.

Specialized encryption based approaches

Lei et al. [5], proposed homomorphic encryptionschemes [2] for performing sensitive computation onencrypted data inside an untrusted cloud platformthat provides input/output confidentiality and result-ing integrity. The authors have shown how commonengineering and scientific computational tasks such asmatrix inversion computation (MIC) can be securelyoutsourced to an untrusted cloud platform. The origi-nal matrix is encrypted before being outsourced to thecloud and then processed in encrypted form. Trans-formation is applied on the result received from thecloud to get accurate inversion of the original matrix.Homomorphic encryption, however limits the typesof operations that can be performed. Moreover thisapproach overburdens the client and is not desirablefor thin client environments, such as mobile devices,with limited resources.

Vimercati et al. [8], consider a cloud scenario wherestorage and computation services are used from dif-ferent cloud providers. Data resides in encrypted formon a storage provider and is transferred to a com-putation provider for processing in encrypted form.The outcome of the result is then again encryptedand returned to the client, which then transforms theresult into clear text and verifies its integrity. The mainshortcoming of this approach is that if limited com-putation needs to be performed on the data the clientwill still need to outsource storage and computationfrom multiple providers. Also it needs to bear thereservation and communication overhead involved inmoving the data to the computation service provider.

A protocol for providing confidentiality and con-trolling access to the data in the cloud is proposed byTysowski et al. [7]. The given approach recommendsmodifications to attribute-based encryption to controlaccess to data based on possession of certain attributesby authorized users. The data owner determines at-tributes required for data access to protect data con-fidentiality from unauthorized users. The data ownerthen generates, encrypts and then uploads data to thecloud to be accessed only by authorized users.

Ports et al. [41], attempt to protect application codeand its data from the compromise of untrusted operat-ing system in a virtualized environment by providingencrypted view of the memory pages of a clientapplication to the operating system. The proposedapproach allows a protected application running ina virtual machine (VM) to interact directly with theVMM through a user level code, called shim. Thedirect communication between the shim and VMMallows the application to protect its resources, suchas files in memory. However, the proposed approach

does not consider a cloud environment where theattacker is potentially more powerful and may havecontrol of the platform and communication channelin addition to the operating system.

Unlike existing approaches our proposed protocolconsiders user computation integrity and data con-fidentiality against a powerful attacker such as anuntrusted cloud system administrator. The applica-tion code is executed with hardware protection, incomplete isolation from a potentially compromisedVMM. Cryptographic operations and computation isperformed at the provider side, which allows supportfor thin clients, such as mobile devices.

8 CONCLUSION AND FUTURE WORKIn the last few years, cloud computing has experi-enced very high growth rates and is showing greatprospects. One of the biggest challenges to the wideadoption of cloud based services is client confiden-tiality and integrity concerns. In this paper, we havepresented and formally verified a practical solution toaddress this problem. Our solution includes a protocolfor secure VM launch which enables clients to verifycloud platform configuration before launching theirVMs on the cloud. In addition, a protocol for perform-ing sensitive computations in a cloud environmentis presented. We have formally verified the securityproperties of our proposed protocols using ProVerif.Currently our implementation is for Intel based sys-tems but it can easily be adapted to AMD. Evaluationresults show that our solution is practical in termsof performance. In the future, we are planning toperform rigorous penetration testing of our protocolusing an actual deployment.

ACKNOWLEDGMENTS

We wish to thank Chris Dalton from HP lab Bristol forhis valuable advice and many enjoyable discussions.

REFERENCES

[1] N. Kroes. “Setting up the European Cloud Partnership”. WorldEconomic Forum, 2012.

[2] M. Naehrig, K. Lauter, and V. Vaikuntanathan. “Can homomor-phic encryption be practical?”. In Proceedings of the 3rd ACMworkshop on Cloud computing security workshop, pp. 113-124,New York, USA, 2011.

[3] Advanced Micro Devices. AMD64 virtualization: Secure virtualmachine architecture reference manual. AMD Publication no.33047 rev. 3.01, May 2005.

[4] G. Coker, J. Guttman, P. Loscocco, A. Herzog, J. Millen, B.OHanlon, J. Ramsdell, A. Segall, J. Sheehy, and B. Sniffen. “Prin-ciples of remote attestation”. International Journal of InformationSecurity, Volume 10, Issue 2, pp. 63-81, 2011.

[5] X. Lei, X. Liao, T. Huang, H. Li and C. Hu. “OutsourcingLarge Matrix Inversion Computation to A Public Cloud”. IEEETransactions on Cloud Computing, Volume 1, Issue 2, pp. 78-89,2013.

[6] Trusted-Java: Jsr321: Trusted computing api for java(tm) (2009)Available at: http://jcp.org/en/jsr/detail?id=321. Accessed on06/09/2013.


[7] P. Tysowski and M. Hasan. “Hybrid Attribute- and Re-Encryption-Based Key Management for Secure and Scalable Mobile Applicationsin Clouds”. IEEE Transactions on Cloud Computing, Volume 1,Issue 2, pp. 172-186, 2013.

[8] S. di Vimercati, S. Foresti, S. Jajodia, S. Paraboschi and P. Sama-rati.“Integrity for Join Queries in the Cloud”. IEEE Transactions onCloud Computing, Volume 1, Issue 2, pp. 187-200, 2013.

[9] X. Leroy. “Formal certification of a compiler back-end, or: program-ming a compiler with a proof assistant”. In 33RD Proceedings ofACM Symposium on Principles of Programming Languages,2006.

[10] F. Krautheim, D. Phatak, and A. Sherman. “Introducing thetrusted virtual environment module: a new mechanism for rootingtrust in cloud computing”. In Proceedings of the 3rd internationalconference on Trust and trustworthy computing, 2010.

[11] A. Baldwin, C. Dalton, S. Shiu, K. Kostienko, and Q. Rajpoot.“Providing secure services for a virtual infrastructure”. OperatingSystems Review-ACM Special Interest Group on OperatingSystems, Volume 43, Issue 1, PP. 44-51, 2009.

[12] P. Colp, M. Nanavati, J. Zhu, W. Aiello, G. Coker, T. Deegan,P. Loscocco, and A. Warfield. “Breaking up is hard to do: securityand functionality in a commodity hypervisor”. In Proceedings ofthe Symposium on Operating Systems Principles, PP. 189-202,2011.

[13] Intel Corporation. “Intel Virtualization Technology for DirectedI/O”. Intel Publication no. D51397-004 rev. 1.2, 2008.

[14] J. McCune, B. Parno, A. Perrig, M. Reiter, and A. Seshadri.“How low can you go? Recommendations for hardware-supportedminimal TCB code execution”. In Proceedings of the ACM Con-ference on Architectural Support for Programming Languagesand Operating Systems (ASPLOS), 2008.

[15] D. Nurmi, R. Wolski, C. Grzegorczyk, G. Obertelli, S. Soman,L. Youseff, and D. Zagorodnov. “The Eucalyptus Open sourceCloud computing System”. In Proceedings of the 9th IEEE/ACMInternational Symposium on Cluster Computing and the Grid,China, 2009.

[16] P. Dewan, D. Durham, H. Khosravi, M. Long, and G. Nagab-hushan. “A Hypervisor-Based System for Protecting Software Run-time Memory and Persistent Storage”. In Proceedings of the Springsimulation Multi-Conference, SpringSim, Boston, USA, 2008.

[17] T. Garfinkel, B. Pfaff, J. Chow, M. Rosenblum, and D. Boneh.“Terra: A Virtual Machine-Based Platform for Trusted Computing”.In Proceedings of the ACM Symposium on Operating SystemsPrinciples, 2003.

[18] N. Santos, K. Gummadi, and R. Rodrigues. “Towards TrustedCloud Computing”. In Proceedings of the Hot Topics in CloudComputing, USA, 2009.

[19] D. Murray, G. Milos, and S. Hand. “Improving Xen securitythrough disaggregation”. In Proceedings of the International Con-ference on Virtual Execution Environments, New York, USA,2008.

[20] TCG Specification Architecture Overview.https://www.trustedcomputinggroup.org. Accessed on05/09/2013.

[21] R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn. “Design andImplementation of a TCG-based Integrity Measurement Architec-ture”. In Proceedings of the 13th USENIX Security Symposium,San Diego, USA, 2004.

[22] I. Khan, H. Rehman, and Z. Anwar. “ Design and Deploymentof a Trusted Eucalyptus Cloud”. In Proceedings of the 4th IEEEInternational Conference on Cloud Computing, Washington,USA, 2011.

[23] Research: 2012 State of Cloud Computing.http://reports.informationweek.com/abstract/5/8658/cloud-computing/research-2012-state-of-cloud-computing.html.Accessed on 04/06/2013.

[24] Cloud computing to the rescue!Stolen iPhone tracked via iCloud(2012).http://www.gmanetwork.com/news/story/259410/scitech/technology/cloud-computing-to-the-rescue-stolen-iphone-tracked-via-icloud. Accessed on 08/09/2013.

[25] The OpenStack Community “OpenStack Cloud Software”.http://www.openstack.org/, 2011. Accessed on 11/09/2013.

[26] The OpenNebula Project “OpenNebula: The Open Source Toolkitfor Cloud Computing”. http://opennebula.org/, 2011. Accessedon 15/08/2013.

[27] Nimbus Home Page. http://www.nimbusproject.org/. Ac-cessed on 15/08/2013.

[28] P. Sempolinski, and D. Thain. “A Comparison and Critiqueof Eucalyptus, OpenNebula and Nimbus”. In Proceedings of theInternational Conference on Cloud Computing Technology andScience, Indianapolis, USA, 2010.

[29] J. McCune, B. Parno, A. Perrig, M. Reiter, and H. Isozaki.“Flicker: An execution infrastructure for TCB minimization”. InProceedings of the ACM European Conference in ComputerSystems, 2008.

[30] Intel. Intel Trusted Execution Technology Mea-sured Launched Environment Developers Guide.http://download.intel.com/technology/security/downloads/315168.pdf, 2008.

[31] F. Zhang, J. Chen, H. Chen, and B. Zang. “CloudVisor:Retrofitting Protection of Virtual Machines in Multi-tenant Cloudwith Nested Virtualization”. In Proceedings of the ACM Sympo-sium on Operating Systems Principles, 2011.

[32] S. Butt, H. Cavil, A. Srivastav, and V. Ganapathy. “Self-serviceCloud Computing”. In Proceedings of the ACM Conference onComputer and Communications Security, 2012.

[33] R. Needham and M. Schroeder. “Using encryption for authen-tication in large networks of computers”. Communications of theACM, Volume 21, Issue 12, 1978.

[34] G. Lowe. “Breaking and Fixing the Needham-Schroeder Public-keyProtocol using CSP and FDR”. In Proceedings of the 2nd Interna-tional Workshop on Tools and Algorithms for the Constructionand Analysis of Systems, pages 147-66. Springer-Verlag, 1996.

[35] A. Armando, R. Carbone, L. Compagna, J. Cuellar and LTobarra. “Formal Analysis of SAML 2.0 Web Browser Single Sign-On: Breaking the SAML-based Single Sign-On for Google Apps”. InProceedings of the 6th ACM workshop on Formal methods insecurity engineering, Pages 1-10, New York, USA. 2008.

[36] OpenSSL vulnerabilities. Available at:https://www.openssl.org/news/vulnerabilities.html.Accessed on 12/12/2014.

[37] M. lbrecht, K. aterson and G. Watson. “Plaintext Recovery At-tacks against SSH”. In Proceedings of the 30th IEEE Symposiumon Security and Privacy, pages 16-26, 2009.

[38] M. Arapinis, T. Chothia, E. Ritter and M. Ryan. “AnalyzingUnlinkability and Anonymity Using the Applied Pi Calculus”. In the23rd IEEE Computer Security Foundations Symposium (CSF),pages 107-121, IEEE Computer Society, 2010.

[39] “ProVerif: Cryptographic protocol veri-fier in the formal model”. Available at:http://prosecco.gforge.inria.fr/personal/bblanche/proverif/.Accessed on 10/10/2014.

[40] A. Armando, R. Carbone and L. Compagna. “Satmc: A SAT-based model checker for security critical systems”. In the 20ThInternational Conference on Tools and Algorithms For TheConstruction and Analysis Of Systems, France, 2014.

[41] D. Ports and T. Garfinkel. “Towards application security on un-trusted operating systems”. In Proceedings of the 3rd conferenceon Hot topics in security, Berkeley, USA, 2008.

[42] V. Potdar, S. Han and E. Chang. “A survey of digital imagewatermarking techniques”. in the Proceedings of the IEEE 3rdInternational Conference on Industrial Informatics (INDIN),Perth, Australia, 2005.

[43] C. Hota, S. Sanka, M. Rajarajan and S. Nair, “Capability basedCryptographic Data Access Control in Cloud Computing”. in Inter-national Journal of Advanced Networking and Applications,Volume 01, Issue 01, 2011.

[44] K. Seny and L. Kristin, “Cryptographic Cloud Storage”. In theProceedings of the 14th International Conference on FinancialCryptography and Data Security, Tenerife, Spain, 2010.

APPENDIXTable 2, contains ProVerif code used for the verification ofsecurity properties of our proposed protocol.


1 set verboseClauses = explained. 2 3 free !"#$:bitstring [private]. 4 free getQuote:bitstring. 5 free c, d: channel. 6 free e, f, g: channel [private]. 7 free success: bitstring. 8 9 (* encryption and decryption functions *) 10 fun enc (bitstring, bitstring, bitstring): bitstring. 11 fun dec (bitstring, bitstring): bitstring. 12 fun senc (bitstring, bitstring, bitstring): bitstring. 13 fun sdec (bitstring, bitstring): bitstring. 14 fun pub (bitstring): bitstring. 15 16 (* decryption followed by encryption produces original message *) 17 equation forall xk: bitstring, xr:bitstring, xm: bitstring; sdec(xk, 18 senc(xk, xr, xm)) = xm. 19 20 equation forall xk: bitstring, xr:bitstring, xm: bitstring; dec(xk, 21 senc(pub(xk), xr, xm)) = xm. 22 23 query attacker (!"#$). 24 25 26 27 28 29 30 31 32 (* the actions of the client *) 33 let client(%&':bitstring) = 34 in (e, pubF:bitstring); 35 new na:bitstring; 36 new r1:bitstring; 37 out (c, enc (pubF, r1, (na, pub(%&')))); 38 in (c, x:bitstring); 39 let (=na, nF:bitstring) = dec (%&', x) in 40 new r2:bitstring; 41 out (c, enc (pubF, r2, (nF, !"#$))). 42 43 44 (* the action of the flicker session *) 45 let flicker = 46 new %&(: bitstring; 47 out (e, pub (%&()); 48 out (c, pub (%&()); 49 in (c, x:bitstring); 50 let (xna:bitstring, xpubC:bitstring) = dec (%&(, x) in 51 new nF:bitstring; 52 new r:bitstring; 53 out (c, enc (xpubC, r, (xna, nF))); 54 in (c, y:bitstring); 55 let (=nF, !"#$:bitstring) = dec (%&(, y) in 56 out (c, success). 57 58 (* the specification of the whole system: key generation, afterwards running client and flicker in parallel *) 59 process 60 ! ((new %&':bitstring; out(c, pub(%&')); (client (%&'))) | flicker)

TABLE 2ProVerif security verification code

I mran Khan received his M.S. degrees inComputer Sciences in 2009 from the Na-tional University of Computer and Emerg-ing Sciences, Islamabad, Pakistan. Imranhas worked as Software Developer andresearcher at University of Birmingham,UK, Security Engineering Research Group(SERG) IMSciences, Pakistan, on systemand web security related projects. Imran hasseveral distinction including Higher educationCommission of Pakistan (HEC) MS leading

to PhD Fellowship and International Research Support InitiativeProgram (IRSIP) Fellowship to UK. Currently he is pursuing his PhDfrom FAST-NUCES Islamabad.

Z ahid Anwar received his Ph.D. and M.S.degrees in Computer Sciences in 2008 and2005 respectively from the University of Illi-nois at Urbana-Champaign (UIUC), USA. Za-hid has worked as a software engineer andresearcher at IBM, New York, USA, Intel,Oregon, USA, Motorola, Schaumburg, Illi-nois, USA and the National Center for Su-percomputing Applications (NCSA), Urbana,Illinois, USA on various projects related toinformation security and operating system

design. Currently he is an Assistant Professor at the School ofElectrical Engineering and Computer Science, National Universityof Sciences and Technology (NUST), Islamabad, Pakistan and anAssociate member of the Graduate Faculty in the Software andInformation Systems Department at the University of North Carolinaat Charlotte, USA.

B ehzad Bordbar has his BSc, MSc andPh.D in Mathematics (PhD from Sheffield,UK). Following his PhD, he worked as aresearcher on a number of projects at Uni-versity of Ghent, Belgium and University ofKent, UK. He is currently affiliated to theSchool of Computer Science, University ofBirmingham, UK, where he teaches coursesin Software Engineering and Distributed Sys-tems. In recent years, he has had closecollaborative research with various academic

and industrial organizations, among them Ghent University, OsakaUniversity, Colorado State University, BT, IBM and HP research lab-oratories. His research activities are mostly aimed at using modellingto produce more dependable software and systems in shorter devel-opment cycles and at a lower cost. His current research projectsare dealing with Formal methods, Model Analysis, Software Tools,Model Driven Development and Fault-tolerance in Service OrientedArchitectures and Cloud.

E ike Ritter obtained his masters’ degreefrom Erlangen, Germany and his PhD fromCambridge. Following his PhD, he worked asa researcher in Cambridge and Oxford be-fore joining Birmingham University to whichhe is currently affiliated to. He has workedon categorical logic and type theory. Hiscurrently research interests are in security,in particular in design and verification ofprotocols, security for mobile phones andhardware-based systems.

H abib-ur Rehman has completed his doc-toral studies (Dr.-Ing.) in 2009 at the Tech-nische Universitaet Carolo Wilhelmina zuBraunschweig, Germany. He is currently As-sistant Professor in the Department of Com-puter Science at Al Imam Mohammad IbnSaud Islamic University (IMSIU), Riyadh,KSA. His primary research interests are thedesign and development of network proto-cols, schemes and models with a focus onthe issues of Routing, MAC, streaming, se-

curity, information sharing and cloud computing.

Documents

IEEE TRANSACTIONS ON CLOUD COMPUTING 1 A …bxb/Papres/2016.5.pdf · A Protocol for Preventing Insider Attacks in Untrusted Infrastructure-as-a ... isolated environment without