available online · a, ∗, elsayed e. hemayed a, b adepartment of computer engineering, faculty...

c o m p u t e r s & s e c u r i t y 8 2 ( 2 0 1 9 ) 1 9 6 – 2 2 6

Available online at www.sciencedirect.com

j o u r n a l h o m e p a g e : w w w . e l s e v i e r . c o m / l o c a t e / c o s e

Trusted Cloud Computing Architectures for

infrastructure as a service: Survey and systematic

literature review

Fady A. M. Ibrahim

a , ∗, Elsayed E. Hemayed

a , b

a Department of Computer Engineering, Faculty of Engineering, Cairo University, Giza 12613, Egypt b Zewail City of Science and Technology, University of Science and Technology, Giza 12578, Egypt

a r t i c l e i n f o

Article history:

Received 25 March 2018

Revised 20 November 2018

Accepted 27 December 2018

Available online 3 January 2019

Keywords:

Trusted Cloud Computing

IaaS

vTPM

vDRTM

Remote Attestation

Trusted Virtual Domain

a b s t r a c t

Cloud computing is no longer the future but the present. Security and trust are critical in

cloud computing, but how can cloud service tenants trust cloud service providers to store all

their private data on the cloud? Trusted computing is one of the new technologies in the last

decade, and the integration between cloud computing and trusted computing can create a

new architecture for infrastructure as a service that motivates more cloud service tenants to

trust cloud service providers. This paper provides a survey and systematic literature review

on the suggested architectures for this integration.

© 2018 Elsevier Ltd. All rights reserved.

1

Mpoit

2

s

Fao

wK

va

a

1

Vat

FSef

H

h0

. Introduction

any organizations such as financial institutions, health care roviders, and government agencies are skeptical of the cloud

wing to security concerns. These organizations require phys- cal and logical protection mechanisms to manage and main- ain their data at Cloud Service Providers (CSPs) ( Krautheim,010 ).

For Cloud Service Tenant(CSTs), Trusted Computing (TC) upports the use of Sensitive Application oN clouD(SANDs).or CSPs, TC attracts more CSTs, and thus, TC increases the doption of Cloud Computing(CC) to enable a wider share f the cloud market. Therefore, CSP revenues are increasing,hile the price for CSTs is decreasing ( Balogh et al., 2014; amhoua et al., 2015 ).

∗ Corresponding author. E-mail addresses: [email protected] (F. A. M. Ibrahim), hem

ha

ttps://doi.org/10.1016/j.cose.2018.12.014 167-4048/© 2018 Elsevier Ltd. All rights reserved.

In this paper, we survey through systematic literature re- iew the integration between TC and CC for Infrastructure as Service(IaaS). We begin by introducing virtualization, CC, TC,nd TCC in the next sections.

.1. Virtualization

irtualization starts from Software(SW) virtualization, such

s Java Virtual Machine, until Hardware(HW) virtualiza- ion, which can be divided into full and paravirtualization.ull virtualization emulates HW to allow a guest Operating ystem(OS) to run unmodified, whereas paravirtualization

mulates only the most necessary HW in order to increase per- ormance ( Berger et al., 2006; Hao and Cai, 2011 ). Both types ofW virtualization can be divided into (1) virtualization with

ost OS such as VMware player, (2) virtualization with man- gement OS, which is installed on Management VM(MVM),

[email protected] (E.E. Hemayed).

https://doi.org/10.1016/j.cose.2018.12.014

http://www.sciencedirect.com/science/journal/01674048

http://www.elsevier.com/locate/cose

http://crossmark.crossref.org/dialog/?doi=10.1016/j.cose.2018.12.014&domain=pdf

mailto:[email protected]

mailto:[email protected]


c o m p u t e r s & s e c u r i t y 8 2 ( 2 0 1 9 ) 1 9 6 – 2 2 6 197

such as Xen, and (3) virtualization without host or manage-ment OS such as VMware ESXi.

In addition to SW and HW virtualization, there is containervirtualization or OS-level virtualization, where there are con-tainers instead of Virtual Machines VMs. These containersshare the same kernel of the host OS, and each container hasits user mode. Containers are fast and consume less storage,but different types of OSs cannot exist on the same host OS( Hosseinzadeh et al., 2016 ).

Amazon EC2, International Business MachinesIBMBluemix, and Rackspace Cloud use the open source Xenas their Virtual Machine Monitoring(VMM), which is alsocalled hypervisor. Xen supports both full and paravirtualiza-tion. In Xen, MVM is called Domain Zero(Dom0), and otherVMs are called Domain User (DomU). From a security point ofview, an administrator can access MVM of Xen. In addition,the administrator can use xl dump-core command to obtaina memory snapshot of any VM and key finder tool to extractprivate keys from this memory snapshot. Moreover, theadministrator can use lvcreate command to create a logicalvolume in order to copy a virtual Disk (vDisk) ( Rocha et al.,2011; Xing et al., 2015; Zou et al., 2013 ).

1.2. Cloud computing

There is more than one service model for CC such as IaaS,Platform as a Service(PaaS), and Software as a Service(SaaS).Furthermore, there is X as a service(XaaS), which is used asa collective term for any other service ( Tupakula and Varad-harajan, 2015; Yeluri et al., 2012 ). In this study, we concentrateon IaaS.

Although there are many open source clouds such as Eu-calyptus, CloudStack, OpenStack, and OpenNebula, moving tothe cloud is not simple particularly for sensitive services suchas banking and health care. Currently, many businesses de-ploy only non-core applications in the public cloud and re-strict SANDs to dedicated HW ( Khan et al., 2011; Yeluri et al.,2012 ).

1.3. Cloud Computing security issues

CC presents new security challenges. Therefore, there is aneed to make an intrusion severity analysis for CC and specif-ically develop a scheme to assess the damage caused by anintrusion for a victim VM ( Arshad et al., 2013a; Arshad et al.,2013b ). Also, we need to trust the machines before interactingwith them ( Azad et al., 2018 ).

According to Arshad et al. (2012) , security issues in CC canbe classified into (1) vulnerabilities of VM/VMM and CSP in-terfaces, (2) insider threats of both CSP and CST, (3) confiden-tiality and availability, (4) authorization and access control,(5) spreading of licenses and agreements, (6) need to Feder-ated Identity Management (FIM) between CSP and CST, (7) lackof quality assurance and professional administrators ( Arshadet al., 2012 ).

CST’s VMs reside in servers, i.e., in Cloud Node (CNs) andalso move on network and storage. To protect these VMs, CSTshould limit what can be done with these VMs while they areon CNs and encrypt them on network and storage ( Rocha et al.,2011 ).

1.4. Trusted computing

Trusted Computing Group (TCG), which is the organizationthat develops open specifications for TC, specified in 2004 thata platform can be trusted if it always behaves in the expectedmanner for the intended purpose ( Hao and Cai, 2011; Ma et al.,2013 ).

1.4.1. Trusted Platform Module TCG specifies an HW called Trusted Platform Module (TPM) tobe the platform’s Root of Trust(RoT). TPM is a tamper-resistantand cost-effective chip, which generates random numbersand session keys and performs certain cryptographic opera-tions. Endorsement Key(EK) is an RSA key with 2048 bit lengthand is created by TPM’s manufacturer to prove the genuine-ness of TPM. This EK causes the platform to be uniquely iden-tified, which raises privacy concerns; thus, TPM generates anunlimited number of 2048-bit Attestation Identity Key (AIKs)as an alias of EK. AIK signs the data generated from TPM toprove that they come from a genuine TPM. After using TPM,the platform becomes a TC Platform (TCP) ( Hao and Cai, 2011;Kamhoua et al., 2015; Kashif et al., 2015; Khan et al., 2011 ).

TPM contains registers called Platform Configuration Reg-ister (PCR), where hashes of SWs are stored before these SWsare loaded on the platform. As PCRs can only be reset after asystem reboot, all values measured into it cannot be changed.If there are many SWs, PCR_EXTEND() can be used to replacethe PCR value with the hash of concatenating the new SW’shash and the original value of this PCR. The platform createsStored Measurement Log (SML), which contains a detailed listof hashed (measured) values and necessary meta-data of allSWs loaded on the platform since it was first booted, repre-senting the platform integrity ( Kamhoua et al., 2015; Kashifet al., 2015; Khan et al., 2011 ).

1.4.2. Trusted boot TC can be used for trusted boot, where the platform is bootedby a Core Root of Trust for Measurement (CRTM), which istrusted by default according to TCG specifications. CRTM is anexecutable and immutable code, which is invoked via CPU andremains constant in the platform to construct a Chain of Trust(CoT). CRTM can be a part of the BIOS, and sometimes BIOSwith CRTM is called TCG BIOS ( Akram and Ko, 2014; Kashifet al., 2015 ).

CRTM measures its integrity, which is stored in PCR 0and measures the motherboard configuration setting that isstored in PCR 1, and then measures and loads BIOS. BIOSmeasures firmware and its configuration, which are storedin PCR 2 and PCR 3, respectively. BIOS measures and loadsboot loader, which is stored in a fifth PCR. Boot loader mea-sures and loads kernel that is stored in a sixth PCR (the lasttwo PCR indexes are OS dependent). After loading kernel, CoTis extended through every OS component up to applicationsand their config files. Therefore, CRTM can be considered asa tamper-proof RoT at the platform base where CoT is built( Kamhoua et al., 2015 ).

1.4.3. Remote attestation

It is necessary to prove to other parties that this platformis trusted. TC uses Remote Attestation (RA) for this purpose,

198 c o m p u t e r s & s e c u r i t y 8 2 ( 2 0 1 9 ) 1 9 6 – 2 2 6

wc

aisrti

io

bqafainmiKsc

bobctta

Itcicpaa

WR

tbtpo

Tta

1

TaCTsfa

iVi

Tt

1

Tl

1

TStS

aicss

2

To

pes

av

wstp

tuttt‘fCi

here there is (1) an attestation requester, sometimes called

hallenger or verifier, who wants to know the platform state,nd (2) an attestation provider, who is the platform owner and

s sometimes called an issuer or attestor. Attestation requester ends an attestation request, which is also known as quote equest, to attestation provider, who answers by an attesta- ion reply, which is also known as quote reply. This operation

s known as quote operation. To protect from replay attack,.e., to ensure freshness, a random number, which is used only nce(nonce), is applied in quote operation ( Santos et al., 2009 ).

TPM attests the hash values inside PCRs by signing them

y AIK before these signed values are sent to attestation re- uester. AIK is certified by a Trusted Third Party(TTP) such

s Privacy Certification Authority(PCA). AIK is bound to CoT

or ensuring that AIK can only be used inside a specific TPM

ttached to a specific HW. TCG first used PCA, but PCA gets nvolved in every transaction; thus, PCA can cause a bottle- eck. Therefore, Brickell et al. (2004) proposed Direct Anony- ous Attestation(DAA), where TPM acts similar to a TTP that

s dedicated to the platform ( Han-zhang and Liu-sheng, 2010; amhoua et al., 2015 ). DAA was adopted by TCG in TPM 1.2 pecifications, whereas PCA was adopted in TPM 1.1 specifi- ations ( Yu et al., 2017; Zhenpeng et al., 2015 ).

The described RA in the previous paragraph can be called a inary-based RA, as it records and reports the binary identities f loaded SWs on the platform ( Kamhoua et al., 2015 ). Binary- ased RA suffers from certain limitations, such as the need to hange the reference hash values even for trivial changes in

he system. Furthermore, the hash values are measured at the ime of boot, not at the time of request, while current systems re permanently updated and can have a very long uptime.n addition, binary-based RA discloses the platform configura- ion, which can lead to security threats. Furthermore, an SW

an be considered as trusted, but this does not mean that it s trustworthy. This is because an SW may have any bug that an lead to a critical attacking vector ( Rocha et al., 2011; Tu- akula and Varadharajan, 2015; Zhenpeng et al., 2015 ). Several pproaches for RA were presented to solve these issues, such

s property-based RA and behavior-based RA ( Li et al., 2010 ).hen RA terminology is used alone, it means binary-based

A. In property-based RA, the binary identity of every SW is

ranslated to properties. This translation is usually achieved

y querying the property certificates, issued by TTP, to map

he binary identities of SW to properties. The absence of a roperty translation database restricts this type of RA. More- ver, the properties for a given set of SWs change over time.herefore, tracing all these changes imposes severe complexi-

ies ( Kamhoua et al., 2015; Sadeghi and Stüble, 2004; Tupakula nd Varadharajan, 2011 ).

.5. Trusted Cloud Computing

C is designed for personal computer, but CC is the present nd future of computing. Therefore, TC is being developed to C ( Shen et al., 2010 ). Xiao-hui and Xin-fang (2013) defined

CC as the combination of TC and CC, where CSP provides a ealed box execution environment to CST based on TCC Plat- orm(TCCP). Integrating TC with CC verifies cloud behaviors nd helps in proving trust ( Kamhoua et al., 2015 ).

As TCP is a physical platform with TPM, Trusted VM (TVM) s VM with virtual TPM(vTPM) ( Wan et al., 2012b ), Trusted

MM(TVMM) is VMM with TPM, and Trusted Cloud Node(TCN) s CN with TVMM ( Santos et al., 2009 ). As this study is aboutCC, the terminologies VM, VMM, and CN are used a lot, while

hey actually mean TVM, TVMM, and TCN, respectively.

.6. Contribution

he contribution of this paper can be summarized in the fol- owing list.

• Identifying the main points of research in integrating CC and TC.

• Comparing the several types of vTPM, Dynamic Root of Trust for Measurement (DRTM), virtual DRTM (vDRTM),and RA.

• Discussing the migration and cloning of VMs as well as Trusted Virtual Domains(TVDs).

• Confirming the importance of TCC as Google has started

using it on its cloud services.

.7. Paper organization

his paper starts by discussing the survey methodology in

ection 2 , followed by an explanation on what are required

o be virtualized to support TCC, which are TPM and DRTM in

ections 3 and 4 , respectively. RA is described in Section 5 ands CNs need to work together in a domain, TVDs is illustrated

n Section 6 . Additionally, VM cloning and migration are dis- ussed in Section 7 . Furthermore, additional features that can

upport TCC are described in Section 8 . Finally, the survey re- ults and the conclusion are given in Section 9 .

. Survey methodology

his survey is different from other surveys because previous nes have focused on either TC or CC. This survey tries to ex-and the theoretical and practical spectrum of computer sci- nce to include both of them integrated into one report. This urvey is needed to put the focus on TCC, and not TC nor CClone. According to our knowledge, there are no previous sur- eys that discuss this integration as we do.

This systematic literature review consists of three phases,hich are formulating the search, conducting the search, and

urvey results. The first and second phases are discussed in

his section, whereas the third is discussed at the end of this aper in Section 9.1 .

Phase 1 of the systematic literature review is formulating he search. The search string of this survey is constructed by sing the Boolean “AND” and two key terms. These two key erms have to be in the keywords that the author chooses for he paper. Therefore, the search string can be in the form “Au- hor_Keywords: ‘Trusted Computing’ AND Author_Keywords: Cloud Computing”. However, if the data source does not allow

or author’s keyword search, the search string will be “Trusted

omputing’’ AND ‘Cloud Computing’. Then, a manual search

s performed to attain the same results.


Table 1 – Number of total papers per data source.

Source Original Selected Additional Total

IEEE 57 24 12 36 ACM 25 2 8 10 Elsevier 24 4 – 4 Inspec 23 2 – 2 Wiely 8 1 – 1 Springer 129 4 6 10 Scopus 113 11 – 11 Others – – 12 12 Total 379 48 38 86

Phase 2 of the systematic literature review is conductingthe search, which was started at the beginning of 2017. Afterapplying the search string over the first seven data sourcesgiven in Table 1 , we obtain a list of 379 papers. We call these379 papers, the original papers in Table 1 . As this study con-centrates on integrating TC and CC for IaaS architecture, a se-lection is performed in three steps. Step 1 involves review-ing the title, abstract, and the conclusion and figures. Step2 involves examining at the full text if required. Step 3 in-volves avoiding duplication either in the case that the paperis present in more than one data source or the author cre-ates a new version of the paper. In addition, if the data sourcedoes not allow for language restriction, a manual discard willbe performed to achieve the same results. After applying thisprocedure, we obtain a list of 48 papers as our choice. We callthese 48 papers, the selected papers in Table 1 .

After that, the reference list in each selected paper is ex-plored. If the reference is related to our survey, it will be addedto what we call additional papers. Finally, we add the selectedand additional papers together to get the total number of pa-pers as shown in Table 1 .

These 86 papers are explored in the next sections. Theyare classified into (1) papers that discuss vTPM, DRTM, andvDRTM, (2) papers that discuss RA, (3) papers that discussTVDs, (4) papers that discuss VM cloning and migration, and(5) papers that suggested additional features that are com-
bined with TCC.
Fig. 1 – Survey taxonomy

In Fig. 1 , we show this classification to illustrate the taxon-omy of proposed systems of our survey. The main features, weconsider while evaluating these systems include the perfor-mance, the availability of implementation, and the possibilityof severe attacks.

3. vTPM

According to Wan et al. (2012a) and Shi et al. (2015) , vTPMmust (1) provide the same command set as TPM, (2) protectand manage all its keys and secrets, (3) be strongly associatedwith its VM and Trusted Computing Base(TCB), and (4) be dis-tinguishable from TPM.

Scarlata et al. (2008) proposed a generalized vTPM frame-work that supports different vTPM types similar to those dis-cussed in the next section and provides CST the choice to se-lect from them for every VM.

Sealing is an important feature in TC that generates anon-migratable TPM key pair with protection. The key pairis sealed to specific PCR(s); thus, to use the key, TPM mustcheck whether the current value of this/these PCR(s) is/areequal to the required value or not. TPM can generate a cer-tificate, to other parties, to certify that this key is sealed tothe required PCR(s) Hao and Cai (2011) . As an example, RyanRyan (2013) discussed how CSP can use TPM to store keys in away that makes them accessible only to specific applications.CST uploads data encrypted with some keys to a CSP, whichcan run the application that can access this key. No other ap-plication on CSP can access this key, and thus, the data canonly be manipulated by the allowed application.

vTPMs can be classified according to virtualization type,VMM type, and RA type. Sections 3.1, 3.2 , and 3.3 discuss eachone of these types of classification respectively.

3.1. Virtualization-type-based vTPM

vTPMs can be classified according to virtualization type.Therefore, the next sections discuss vTPMs that are built onSW, HW, and paravirtualizations. This classification is basedon the work of Wan et al. (2012a) .

of proposed systems.


Fig. 2 – SW-based vTPM ( Berger et al., 2006 ).

3Bv

tuctf

vtaoEeiv

mu

(kmtcd

ipirovt

Hcw

ls

u(oM

Fig. 3 – SW-based vTPM with vTPM_Creator ( Rongyu et al., 2013 ).

i

3Rv

BDt

(astS

(aPiCa

vvqvwsMfd

3HupV

2Vf

.1.1. SW-based vTPM (2006) erger et al. (2006) , researchers of IBM, proposed an SW-based

TPM that runs as a process, called vtpmd ( Ma et al., 2013 ), inhe user mode of OS. They proposed two architectures: the first ses normal TPM, and the second uses IBM’s PCIXCC external ard. Both of them implement full TPM specifications plus ex- ra functions for vTPM life cycle management. They used Xen

or implementation. In their architectures, as shown in Fig. 2 , there is a specific

TPM instance for every VM and a vTPM Manager that creates hese vTPM instances. Both vTPM instances and vTPM Man- ger exist in MVM. The vTPM driver is split into a client side r Front End(FE) driver at every VM and a server side or Back nd (BE) driver at MVM. They introduced the concept of a par- nt vTPM instance, which creates and manages child vTPM

nstances. Therefore, TPM can play the role as a parent for all TPM instances ( Berger et al., 2006 ).

vTPM migration: (1) Source vTPM instance creates a sym- etric key. (2) Source vTPM instance is locked to keep its state

naltered, while its state is encrypted by the symmetric key.3) The symmetric key is encrypted by a migratable storage ey owned by the parent of source vTPM instance. (4) The igratable storage key is migrated to the parent of destina-

ion vTPM instance. (5) The encrypted symmetric key and en- rypted state of source vTPM instance are sent to the target estination ( Berger et al., 2006 ).

Attestation requester needs to know whether vTPM or TPM

s used, as an SW-based vTPM does not offer the same security roperties as TPM. Therefore, special attributes are embedded

nside key certificates for this purpose. With vTPM, attestation

equester needs to know the measurements inside VM and

utside VM that provides vTPM. Therefore, the upper set of TPM’s virtual PCRS(vPCRS) is reserved for vTPM values, while he lower set is reserved for its TPM values ( Berger et al., 2006 ).owever, according to Hosseinzadeh et al. (2016) , this scenario onflicts with their migration protocol, as information sealed

ith lower vPCRS cannot be unsealed after migration. Some of the disadvantages of SW-based vTPM are as fol-

ows: (1) It is implemented in SW, and thus, cryptographic ecrets are not protected by HW ( Wan et al., 2012a . (2) It isnder the control of MVM, i.e., CSP can be a threat for CST

Kashif et al., 2015 ). Hence, Anderson et al. (2007) , researchers f HP, tried to implement vTPM instances in VMs instead of in

VM ( Wan et al., 2012a ).

It is worth mentioning that if the word vTPM is used alone,t typically means an SW-based vTPM.

.1.2. SW-based vTPM with vTPM_Creator (2013) ongyu et al. (2013) introduced a CST-configurable SW-based

TPM that consists of (1) a vTPM FE driver at VM, (2) vTPME driver, and (3) vTPM instance at vTPM_Creator, which is in

om0. vTPM_Creator allows CST to configure vTPM at creating ime and consists of (1) a vTPM Emulator, (2) vTPM Manager,3) vTPM BE driver, and (4) set of vTPM instances. Both vTPMs nd vTPM_Creator are shown in Fig. 3 . vTPM creation: (1) CST

ends a vTPM create request with the required security policy o vTPM_Creator. (2) vTPM_Creator constructs a TPM Control tructure(TPMCS) object with the received CST security policy.

3) TPM_Creator creates a vTPM instance using TPMCS object nd identifies it with a 4-byte VM ID. (4) vTPM Emulator copies CRs 0–8 of TPM into the corresponding vPCRS of vTPM as its nitial values. These vPCRS store the integrity measurement of N, while vPCRS 9–23 store the integrity measurement of VM

ccording to the defined security policy ( Rongyu et al., 2013 ). VM vTPM communication: (1) VM sends a TPM request to

TPM FE driver. (2) vTPM FE driver forwards the request to TPM BE driver. (3) vTPM BE driver appends VM ID to the re- uest before forwarding to vTPM Manager’s Req_Queue. (4) TPM Manager extracts the ID from the request and then for- ards it to the corresponding vTPM instance. (5) vTPM in-

tance processes the request and returns the result to vTPM

anager’s Ack_Queue. (6) vTPM Manager reads the result and

orwards it to the corresponding VM through vTPM BE and FE rivers ( Rongyu et al., 2013 ).

.1.3. HW-based vTPM (2008) W-assisted virtualization, such as Intel VT and AMD-V, is sed to enable efficient virtualization. Thus, the new Intel VT

rocessor has two new CPU modes: (1) VMX root in which

MM runs, and (2) VMX non-root in which VMs run ( Wan et al.,012a ). In addition, Xen provides the ability for smaller “helper Ms”, called stubs, to provide services such as HW emulation

or vTPMs ( Wan et al., 2012b ).


Fig. 4 – KVM-based vTPM Shi et al. (2015) .

Fig. 5 – Container-based vTPM ( Hosseinzadeh et al., 2016 ).

Stumpf and Eckert (2008) proposed an HW-based vTPM byusing an Intel VT, which allows each VM to use the completepower of TPM, as each VM is illuded that it has its own TPM.They extended the TPM command set in order to control aseparate vTPM context that can be saved and loaded for everyVM. They used some components, such as (1) a TPMCS thatis loaded into TPM each time a specific VM uses its vTPM, (2)protection rings that provide an HW-based protection to iso-late vTPM contexts, and (3) a vTPM BE driver that schedulesTPM commands invoked by VMs ( Hosseinzadeh et al., 2016;Wan et al., 2012a ).

3.1.4. Paravirtualization-based vTPM (2008) England and Loeser (2008) , researchers of Microsoft, proposeda paravirtualization-based vTPM that uses TPM wherever pos-sible to fairly share one TPM among all VMs. VMM providesevery VM an access to TPM by using a paravirtualization mod-ule. This module uses a hypercall interface that allows VMsto directly call VMM. TPM is multiplexed, while SWs are usedfor safe device sharing Hosseinzadeh et al. (2016) . The modulecontains (1) a scheduler, (2) command filter, and (3) contextmanager, which maintains VM–vTPM associations, and iso-lates TPM contexts of different VMs. This module uses a vTPMBE driver, whereas VMs use vTPM FE drivers ( Neisse et al., 2011;Wan et al., 2012a ).

This approach overcomes the limitations of the SW-basedvTPM or the need for HW-assisted virtualization. To achievethis, some TPM parts, such as PCRs and counters are repli-cated or partitioned similar to delegation tables and non-volatile storage. They suggested sharing of EK and StorageRoot Key(SRK) among all vTPMs, instead of a dedicated virtualEK (vEK) and virtual SRK (vSRK) for every vTPM. However, it isunclear how AIKs and other TPM keys are created and stored.Moreover, they provided only few details on their implemen-tation ( England and Loeser, 2008; Wan et al., 2012a ).

3.2. VMM-type-based vTPM

Furthermore, vTPMs can be classified according to VMM type.All previous vTPMs are built on Xen. Therefore, the next sec-tion discusses a vTPM that is built on Kernel-based VM(KVM),which is another famous VMM. In addition, we decide to addvTPM, which is built on containers, to this section.

3.2.1. KVM-based vTPM (2015) Shi et al. (2015) proposed a KVM-based vTPM, shown in Fig. 4 ,where vTPM instances are emulated by a QEMU as a stub do-main over KVM, i.e., is isolated from vTPM Manager in order toenhance security and to run at near-physical speed benefitingfrom HW-assisted virtualization. Their architecture consistsof (1) an HW layer that contains a TPM, Intel VT processor,and memory; (2) a kernel layer that contains a KVM module,vTPM Manager, and vTPM BE driver; and (3) a virtualizationlayer that contains VMs and the stub domain.

Upper encryption is the encryption of vTPM secrets by asymmetric key, while middle encryption is the asymmetric en-cryption of this symmetric key by a binding key, which is a TCkey used for encryption. Otherwise, lower encryption is theasymmetric encryption of this binding key by a storage key.Every VM has a unique ID, which is used as a key parameter

for generating the storage key. To isolate VMs from each other,every VM contains a unique encryption thread, and all encryp-tion processes are On The Fly Encryption(OTFE), where vTPMsecrets are transparently encrypted on write and decrypted onread ( Shi et al., 2015 ).

vTPM migration is based on a duplication mechanism, i.e.,secure migration of TPM 2.0 specifications, which is appliedon migratable keys. The vTPM migration steps are as follows:(1) Source CN sends a nonce signed by its AIK to destinationCN. (2) Destination CN verifies the signature; then, destinationCN sends the nonce and the public part of its storage key, bothsigned by its AIK, to source CN. (3) Source CN verifies the signa-ture. (4) Source CN encrypts the private part of its migratablekey by a symmetric (session) key and encrypts this symmetrickey using the public key of the storage key. Then, source CNsends both encrypted keys, signed by its AIK, concatenatedwith the public part of the migratable key to destination CN.(5) Destination CN verifies the signature. Then, destination CNdecrypts the symmetric key using the private part of its stor-age key and decrypts the migratable key using the symmetrickey ( Shi et al., 2015 ).

3.2.2. Container-based vTPM (2016) Hosseinzadeh et al. (2016) proposed two architectures forvTPM with container. In the first architecture, which is shownin Fig. 5 , all vTPMs are placed in a host OS kernel, and a ker-nel module is used to provide the required number of vTPMs.


Fig. 6 – Container-based vTPM with vTPM Manager ( Hosseinzadeh et al., 2016 ).

Cvutl

vTa

Tptto

3

vvt

3Sn

wm(sng(

tta

3

I

pa

sp

4a

TRqS

a

(

ef

t

s

Da

2

r

n

Icd1ah2t

S

ttueLt1v(

Sn

stlm(

v

4

4Mama

ontainer Manager, here as VMM, asks kernel to create a new

TPM when the container is created. vTPM is protected from

nauthorized access by other processes, as kernel is better han user space in limiting unauthorized access. However, this evel of protection is still less than that provided by VMM.

In the second architecture, which is shown in Fig. 6 , all TPMs are placed in a separate container, which has access to PM and exposes vTPM interfaces to other containers through

communication channel, such as local Unix domain socket.his architecture is less secure than the first, but easier in im- lementation, as vTPM is moved from kernel to a user space hat allows a daemon to process the requests from other con- ainers. Thus, they recovered this by making the daemon part f TCB ( Hosseinzadeh et al., 2016 ).

.3. RA-type-based vTPM

TPMs can be classified according to RA type. All previous TPMs are built on binary-based RA. Therefore, the next sec- ion discusses a vTPM that is built on property-based RA.

.3.1. Property-based vTPM (2008) adeghi et al. (2008) proposed a property-based vTPM using ew building blocks, consisting of (1) property management,hich reads and stores measurement values; (2) key manage- ent, which creates and loads keys, such as vEK and vSRK;

3) vTPM policy, which holds user-defined policy of vTPM in- tances; (4) cryptographic functions, which provide random

umber generation, hashing, and other functions; and (5) mi- ration controller, which migrates vTPM to another platform

Wan et al., 2012a ). Their vTPM migration protocol is based on the vTPM migra-

ion protocol of Berger et al. (2006) . However, they embedded

he migration procedure in a trusted channel, instead of using migratable TPM key ( Wan et al., 2012a ).

.4. vTPM comparison

n Table 2 , we compare SW-based, HW-based,aravirtualization-based, KVM-based, container-based, nd property-based vTPMs. The comparison criteria are

ecurity, performance, the availability of implementation, the ossibility of severe attacks, and the prediction of usage.

. Dynamic Root of Trust for Measurement nd virtual DRTM

he discussed CRTM in the introduction is a type of Static oot of Trust for Measurement(SRTM), which is simple, but re- uires a complete OS to be trusted before trusting any other W loaded later, i.e., it results in a large TCB. Moreover, BIOS orny other SW, if it needs to be updated, has to be considered Yeluri et al., 2012 ).

DRTM, also called late-launch, reduces the size of TCB by xcluding BIOS, boot loader, and OS, and can perform other unctions such as BIOS update ( Cheng et al., 2012 ). In DRTM,he trust properties of SWs can be ignored until a secure event,uch as VMM launch, triggers the system ( Yeluri et al., 2012 ).RTM launches at any time without system reboot and can

lleviate attacks such as TPM reset and BIOS attacks ( Dai et al.,015 ). This is performed by putting CPU in a clean state, whichepresents a new RoT such as reboot ( Rocha et al., 2011 ).

DRTM becomes possible by Intel Trusted Execution Tech- ology(Intel TXT) or AMD Secure Virtual Machine (AMD SVM).

ntel TXT is a set of enhanced HW components, such as pro- essor, chipset, and Input/Output(I/O) subsystems, which are esigned to protect from SW attacks. Intel TXT requires TPM

.2 and compatible BIOS, firmware, OS, and VMM. Intel TXT is vailable with Intel Xeon processor 5600 and E3/E5/E7, which

ave been shipped from Dell, NEC, and other suppliers since 010. Many SW vendors released versions of their products hat can use Intel TXT such as Xen, KVM, VMware, Red Hat,uSE, Canonical, and others ( Yeluri et al., 2012 ).

DRTM is invoked by Intel SENTER or AMD SKINIT instruc- ions with the following execution steps: (1) CPU requests TPM

o reset PCRs 17–23. (2) CPU hashes Authenticated Code Mod- le(ACMod) in Intel or Secure Loader Block (SLB) in AMD and

xtends the hash into PCR 17. (3) ACMod hashes Measured

aunched Environment(MLE), compares it with Launch Con- rol Policy(LCP) for verification and extends the hash into PCR

8; however, AMD skips this step. LCP is stored in the non- olatile memory of TPM and is set by the platform owner Toegl et al., 2011; Yeluri et al., 2012 ). (4) CPU loads (MLE) orLB that offers security guarantee, which depends on HW and

ot even on BIOS ( Dai et al., 2015 ). It is worth mentioning that TPM 1.2 specifications pre-

ented DRTM locality, which is used to classify the origin of he TPM command. TPM specifications assign locality 0 for egacy SRTM, locality 1 for OS, locality 2 for runtime environ-

ent of OS, locality 3 for applications, and locality 4 for DRTM

Dai et al., 2015 ). The next two sections discuss DRTM andDRTM, respectively.

.1. Dynamic Root of Trust for Measurement

.1.1. Flicker (2008) cCune et al. (2008) proposed Flicker as an architecture that

llows CSP to decrypt data only by an application that com- its an approved policy with CST. Flicker uses DRTM to launch

secure execution environment, which assumes a TCB as


Table 2 – Comparison between vTPM types.

SW HW Para KVM + HW Container Property-based

RA

Security Low High Medium High Low High Performance High TPM speed Medium TPM speed Low Medium

Implementation Available Available Unclear Available Not available Not available Severe Attacks Vulnerable Protected Possible Protected Possible Very protected Usage Past Present Need more

research Present Future Future

Fig. 7 – Trusted block as a service ( Hao and Cai, 2011 ).

small as 250 Lines of Code (LoC). Flicker achieves this smallLoC for only short-lived applications that get rid of importantfeatures such as networking and by freezing everything elseduring application execution. Flicker isolates sensitive codeby halting OS and switching into AMD SVM ( Dai et al., 2015;Luo et al., 2014; Ryan, 2013 ).

4.1.2. TrustVisor (2010) McCune et al. (2010) enhanced Flicker and proposed TrustVi-sor as a TVMM that protects sensitive code on legacy systemsby executing this code on an isolated environment. TrustVisorusually performs cryptographic operations by SW. Their rea-son is the slowness of TPM on legacy systems. This SW cryp-tographic capability comes at the expense of more than 2000LoC, which are added to TCB. TrustVisor allows applicationsto be on a full OS running in VM, but at the expense of a largerTCB (approximately 6000 LoC) ( Hao and Cai, 2011; Luo et al.,2014; Ryan, 2013 ).

4.1.3. Trusted Virtualization Environment(2011) Rocha et al. (2011) proposed a Trusted Virtualization Envi-ronment (TVE), which is a specific combination of VMM andMVM. TVE prevents the administrator from doing a snapshot,volume mount, and untrusted migration for any VM. Theyused DRTM to prove to CST that the modules performing VMlaunch, migrate, backup, or terminate are trusted. They calledthese modules Trusted Cloud Operation Module(TCOM). Theyused TrustVisor, as an implementation of DRTM, to extendTCOM hash into vTPM. Furthermore, TrustVisor isolates TCOMmemory during execution, thereby creating an Isolated Execu-tion Environment (IEE).

VM launch: (1) CST requests VM launch from a Cloud Con-troller(CCtrl) that replies by the selected CN. (2) Node Con-troller(NCtrl) uses TrustVisor to create IEE. (3) Launch TCOMstarts in IEE to prevent any administrator from obtaining sen-sitive data from MVM’s memory. (4) CST uses RA to trustlaunch TCOM. (5) CST sends decryption key of VM to launchTCOM. (6) Launch TCOM launches VM ( Rocha et al., 2011 ).

VM migrate: (1) CST uses RA to trust migrate TCOM atsource CN and launch TCOM at destination CN. (2) MigratedVM is encrypted during network transfer Rocha et al. (2011) .

VM backup: (1) CST uses RA to trust backup TCOM. (2)CST and backup TCOM establish a session key to encrypt VM.(3) Backup TCOM sends the encrypted VM to its destination( Rocha et al., 2011 ).

VM terminate: (1) CST uses RA to trust terminate TCOM.(2) Terminate TCOM cleans the storage and memory of termi-nated VM to prevent the next VM that uses the same mem-

ory region from reaching private data of the terminated VM( Rocha et al., 2011 ).

4.1.4. Trusted Block as a Service (2011) Hao and Cai (2011) proposed Trusted Block as a Service (TBaaS)to provide a private and verifiable environment for everySAND. The core idea is to provide TBaaS for every CST, whilepreventing CSP from accessing CST’s SAND. They tried to re-duce TCB by using SandVisor, as a tiny VMM that hides un-necessary details from TBaaS such as disabling external in-terrupts. SandVisor benefits from HW-assisted virtualizationto virtualize only the most necessary HW. Their architectureis shown in Fig. 7 .

TPM is dominated by SandVisor exclusively, while other de-vices such as network adapter are managed by a special do-main outside TCB. They used Diffie–Hellman between CST andTBaaS, and they prevented man in the middle attack by creat-ing a TPM key protected by sealing for every TBaaS ( Hao andCai, 2011 ).

They presented five protocols to satisfy SAND securitylevel, which are (1) TBaaS booting, (2) trusted block initializa-tion, (3) processing program installation, (4) sensitive applica-tion execution, and (5) return value fetch. DRTM is used to ini-tiate TBaaS booting, but they did not implement a prototype( Hao and Cai, 2011 ).

4.1.5. Trusted Cloud Service Platform Architecture(2012) Cheng et al. (2012) proposed a Trusted Cloud Service PlatformArchitecture(TCSPA), which allows CST to choose and config-ure CNs. TCSPA is shown in Fig. 8 , and its components areas follows: (1) a Control Interface, which allows CST to inter-act, (2) a Dynamic Resource Configuration (DRC), which config-ures CNs based on CST requirements, (3) an Attestation Agent,which proves the satisfaction of CST requirements using RA,


Fig. 8 – Trusted cloud service platform architecture ( Cheng et al., 2012 ).

ap

aAqtsresss

sqsq

ile

4Bvad

lt

wACo

sc

Fig. 9 – Secure Attested Software Base ( Balogh et al., 2014 ).

emCa

itg

2tP

4WF

(Tb

wafslmt(

wAta(

4

4R

wdavmc

nd (4) Abstract Service Platform(ASPs), which are resources rovided to CST that are not fixed to specific CNs.

Inside DRC, Policy Management accepts CSP instructions nd CST requirements. If there is no violation to Service Level greement(SLA), Policy Management will submit these re- uirements to Physical Resource Management, which will ei- her call ASP Management to create a new ASP or allocate re- ources to existing ASPs, or will call Platform Management to eset the physical resources to meet CST requirements. For xample, if the utilization of some type of VMMs reaches a pecific threshold, Platform Management will reorganize re- ources to supplement the VMM in shortage by resetting a pare CN, without reboot, using DRTM ( Cheng et al., 2012 ).

Attestation Agent proofs: (1) ASP proofs, which are mea- ured by DRC and extended into DRC’s PCRs to be used in

uote reply to Attestation Agent. (2) CN proofs, which are mea- ured by CN itself and extended into its PCRs to be used in

uote reply to Attestation Agent. If CST wants to verify its CN,t will issue a challenge to the Attestation Agent that will col- ect ASP and CN proofs and send them signed to CST ( Cheng t al., 2012 ).

.1.6. Secure Attested Software Base (2014) alogh et al. (2014) proposed an approach based on container irtualization to establish trust between CST and CSP by en- bling CSP to manage cloud without direct access to CST’s ata.

Proposed components are shown in Fig. 9 and are as fol- ows: (1) Certified Trusted Agent(Agent), which is a piece of SW

hat remotely manages VM. (2) Agent Execution Platform(AEP),hich is where Agents are uploaded and executed. (3) Secure ttested Software Base(SASB), which ensures the integrity of N. 4) Agent Code Reviewer (ACR), which ensures the integrity f Agents ( Balogh et al., 2014 ).

Agent Execution Platform, within MVM, and SASB are in- talled on every CN. SASB uses Intel TXT to offer DRTM. AEP ontains a list of certified Agents to verify Agents before their

xecution. As several Agents are executed on the same AEP to anage different VMs, each Agent is signed by the respective

ST. CSP delegate Agents to manage VMs without CST inter- ctions ( Balogh et al., 2014 ).

Their prototype uses Linux OpenVZ for container virtual- zation and Proxmox Virtual Environment to provide an API o manage VMs. Moreover, they used IAIK Advanced Crypto- raphic Trusted Virtual Security Module (acTvSM) ( Toegl et al.,011 ). The disadvantages of their approach include the need

o configure SASB, deploy AEP, review Agent code, and set up

ublic Key Infrastructure (PKI) ( Balogh et al., 2014 ).

.1.7. E2E Trusted Cloud Framework (2014) ang et al. (2014) proposed an End to End(E2E) Trusted Cloud

ramework which consists of (1) trusted boot and run of VMs,2) trusted cloud terminal at CST, which uses TPMs or Mobile rusted ModuleMTMs, and (3) Trusted Network Connect(TNC) etween CSP and CST.

VM protection mechanisms: (1) VM Image(VMI) encryption,hich is used to prevent a newly created VM from attacking

nother VM, can be performed if both VMs are instantiated

rom the same VMI. (2) Integrity measurement, which is as- ociated with important files, such as GRand Unified Boot- oader(GRUB), kernel, kernel modules, shared libraries, and

ay be some key applications. (3) RA, which is used to verify he trusted cloud terminal when it tries to access the cloud

Wang et al., 2014 ). For implementation, they used (1) TPM and Trusted Soft-

are Stack(TSS) version 2.0 to support Chinese Cryptographic lgorithms, (2) a proposed Unified Extensible Firmware In-

erface(UEFI) as TCB to get dynamic measurements for VMM

nd VMs, (3) Xen, and (4) Trusted boot(Tboot) on every TCNs Wang et al., 2014 ).

.2. virtual DRTM

.2.1. Credo (2011) aj et al. (2011) , researchers of Microsoft, proposed Credo,hich adds 15,737 LoC to Hyper-V to enable TC. Credo re- uces VM TCB by using emancipation, which is a set of mech- nisms employed by VMM to provide a Secure Execution En- ironment(SEE) for VM. These mechanisms protect the VM

emory and virtual CPU(vCPU) state and enhance VM se- recy and integrity by using sealing and RA. Credo protects VM


Fig. 10 – Credo ( Raj et al., 2011 ).

Fig. 11 – Trusted Execution Environment ( Dai et al., 2015 ).

from administrator and malware in root partition by removingroot partition from TCB. Credo uses a paravirtualization-basedvTPM ( England and Loeser, 2008 ) and Intel TXT. Credo is shownin Fig. 10 .

Launching Credo VMM: (1) VMM boot loader, which iscalled Hyper-V aware Dynamically Launched Measured En-vironment(HvDLME), is loaded into the memory before as-serting a DRTM event. (2) The platform hashes and launchesHvDLME, and uses locality 4 to save the hash in PCRs 17–18. (3)HvDLME hashes and launches VMM, and uses locality 2 to savethe hash in PCR 22. (4) VMM controls the Memory Manage-ment Unit(MMU) and TPM before starting root partition. VMMexports locality 0 through a paravirtualized interface that can-not reset resettable PCRs (PCRs 17–23) ( Raj et al., 2011 ).

Launching emancipated VM: (1) VM sends a hypercall totrigger a vDRTM event. (2) VMM suspends VM. (3) VMM cre-ates SEE for VM. (4) VMM hashes and saves the executionstate of VM in a vPCR called details vPCR, which is resettableonly when VM leaves SEE. (5) VMM resumes VM inside SEE( Raj et al., 2011 ).

If VM wishes to authenticate itself and its VMM, it willselect details vPCR as part of vTPM context, and then sendsquote request, via hypercall, with PCRs 17, 18, and 22 as wellas 23, as VMM loads vPCRS of vTPM context into PCR 23( Raj et al., 2011 ).

4.2.2. Trusted Execution Environment (2015) Dai et al. (2015) proposed a TEE to allow every CST to protectits SANDs. They used Xen technologies, such as paravirtual-ization, hypercall, and split driver model. Their architecturecan be extended to provide fine-grained protection, i.e., pro-tect a part of SAND in TEE.

As vTPM cannot determine the origin of a TPM command,they defined five localities for vDRTM. These localities are lo-cality 0 for DomU, locality 1 for TEE Kernel and SAND af-ter launch, locality 2 for TEE Kernel during launch, locality 3for auxiliary components, and locality 4 for virtual DynamicCRTM(vD-CRTM). Furthermore, LocalityModifier Flag is used toindicate the active locality, whereas TOSPresent Flag is used toindicate the existence of TEE ( Dai et al., 2015 ).

Architecture components are shown in Fig. 11 and are asfollows: (1) VMM, which contains vD-CRTM and TEE Core;(2) vTPM Domain, which contains TEE BE driver, vTPM BEdriver, vTPM instances, and vDRTM-enabled vTPM Manager,which can be called just vTPM Manager; (3) TEE Domain,which contains TEE Kernel, TEE FE driver, vTPM FE driver, andApp Loader; (4) DomU, which contains TEE Manager, TEE Init,

and another TEE FE driver; (5) Dom0; and (6) virtual Low PinCount(vLPC), which communicates vD-CRTM with vTPM Man-ager ( Dai et al., 2015 ).

TEE launch: (1) CST sends SAND launch request to TEEManager. (2) TEE Manager asks TEE BE driver (via TEE FE driver)to create TEE Domain; then, TEE BE driver sends TEElaunchhypercall to vD-CRTM. (3) vD-CRTM hashes CST keys, TEE Ker-nel, and SAND to be compared against their known values. (4)If the comparisons succeed, vD-CRTM will set LocalityModi-fier to 4 and TOSPresent to 1; then, it commands the corre-sponding vTPM instance to reset vPCRS 17–19 and to extendthe hash of CST keys into vPCR 17. (5) vD-CRTM controls TEECore, which uses Xen’s pause, to pause DomU, and uses Xen’screate to create TEE Domain, which inherits DomU’s vTPMinstance, as TEE Domain is a replacement of paused DomU( Dai et al., 2015 ).

SAND execute: (1) TEE Core loads TEE Kernel, which loadsTEE FE driver, vTPM FE driver, and App Loader. (2) App Loaderdecrypts SAND, extends the hash of SAND into vPCR 19, andresets vPCRS 20–22. (3) vTPM FE driver changes LocalityMod-ifier from 2 to 1. (4) App Loader loads SAND to be executed( Dai et al., 2015 ).

TEE destroy: (1) vTPM FE driver returns LocalityModifier to2. (2) App Loader gets the control, and if SAND has an output,App Loader will extend the output hash into vPCR 19, and thensends TEE exit request to TEE BE driver via TEE FE driver. (3)TEE BE driver sends TEEexit hypercall to vD-CRTM, which setsLocalityModifier and TOSPresent to 0. (4) TEE Core destroysTEE Domain and uses Xen’s unpause to unpause DomU ( Daiet al., 2015 ).

vLPC details: (1) vD-CRTM writes a TPM command with lo-cality and vTPM instance number on vLPC, and then sends vir-tual Interrupt Request(vIRQ) to vTPM BE driver, which sendsthe command to vTPM Manager. (2) vTPM Manager reformatsthe message to be sent to vtpmd that replies back. (3) vTPMManager writes the reply on vLPC and uses a hypercall to no-tify vD-CRTM ( Dai et al., 2015 ).


Table 3 – Comparison between DRTM types.

Flicker TrustVisor TVE TBaaS TCSPA SASB E2E

Security High Medium Medium High High High High Performance TPM speed High High but less

than TrustVisor TPMspeed TPMspeed Medium TPM speed

TCB LoC 250 6000 Not implemented

Not implemented

Not implemented

Not mentioned Not mentioned

Applications Limited General General General General In container General Implementation Available Available Not available Not available Not available Prototype Available Severe Attacks Very protected Possible Possible Protected Protected Protected Protected VM Migration Not applicable Not mentioned Available Not available Possible Not applicable Not mentioned

Table 4 – Comparison between vDRTM types.

Credo TEE TEE with rvTPM and TPMc

Security High High Higher Performance Medium High High but less than TEE Size Add 15 K LoC to Hyper-V 1.2 GB for TEE Kernel Not implemented Implementation Prototype Available Not available Attacks (1) VMM vulnerabilities (2)

DoS (1) co-location (2) CSP insider (3) VM rollback exploitation

(1) Co-location (2) CSP insider

Usage Azure does not use it till now

Future Future

i(

4JgTm

pi

Hc

lVdsV

4

Di

Ta

tt

a

ta

5

Roo

n

5

5GmaVct

2p

bis

2

ttTbt

2

T

One of the disadvantages of TEE is the limitation in deal- ng with malicious administrators and side-channel attacks Dai et al., 2015 ).

.2.3. TEE with rvTPM and TPMc (2016) in et al. (2016) discussed three challenges in CC and sug- ested three solutions. Two of these solutions are based on

C. The first challenge is to offer a secure execution environ- ent for SAND. They used TEE ( Dai et al., 2015 ) to allow multi-

le VMs to simultaneously enjoy DRTM. The second challenge s to offer time and state consistency among cloud services.ence, they used rollback-resilient vTPM(rvTPM) and TPM for loud(TPMc).

rvTPM protects VM against attacks that attempt to cause oss of application’s state, while TPMc monitors a group of Ms, which is called VM Group(VMG). All TPMc instances in

ifferent CNs should work consistently, and the nonvolatile torage should be shared among TPMc instances of the same MG ( Jin et al., 2016 ).

.3. DRTM and vDRTM comparisons

RTM is used to secure VMM, while vDRTM provides DRTM

nside VM itself. In Table 3 , we compare Flicker, TrustVisor,VE, TBaaS, TCSPA, SASB, and E2E. The comparison criteria re security, performance, LoC of TCB, the type of applications,he availability of implementation, the possibility of severe at- acks, and the prospect of VM Migration.

In Table 4 , we compare Credo, TEE, and TEE with rvTPM

nd TPMc. The comparison criteria are security, performance,he added size, the availability of implementation, the possible ttacks, and the prediction of usage.

. Remote attestation

A can be classified as binary-based or property-based. More- ver, can also be classified to RA that happens once or peri- dical. Furthermore, there is a behavior-based RA. Therefore,ext sections discuss all these types.

.1. Binary-based RA: Terra

.1.1. Original Terra (2003) arfinkel et al. (2003) proposed Terra as an integrity measure- ent architecture for VM environment ( Xu et al., 2012 ). Terra

llows applications to run either in open-box or closed-box M. Open-box VM runs a general purpose OS with its appli- ations, while closed-box VM runs SANDs, where SW stack is ailored to the security policy of these SANDs ( Rongyu et al.,013 ). Terra uses memory curtaining and sealed storage to rovide privacy and integrity for closed-box VM.

Terra builds a TVMM, which is secure from tampering even

y the administrator. For every closed-box VM, hashes of val- dated SWs are stored. Moreover, TVMM ensures that these tored hashes match hashes of loaded SWs ( Garfinkel et al.,003 ).

In Terra, a path to CSP is created to allow CST and CSP torust each other. For example, a home banking application at- ests its validity to a remote banking server. Both establish a ransport Layer Security(TLS) channel based on RA. Remote anking server also requires a certificate from the SW vendor o ensure from the validity of the SW version ( Garfinkel et al.,003 ).

Terra divides vDisks into (1) encrypted vDisks, where VMM uses encryption and Hash-based Message Authentica-


tion Code(HMAC) to ensure privacy and integrity; (2) integrity-checked vDisks, where TVMM uses HMAC to ensure integrity;and (3) raw vDisks. In addition, vDisks can be divided into at-tested and unattested, where any VM that requires RA mustboot from an attested vDisk ( Garfinkel et al., 2003 ).

TVMM needs to be protected from devices that use DirectMemory Access (DMA) and form malicious kernel modules,as both can modify the kernel. Therefore, DMA threats can behandled by I/O Memory Management Unit (IOMMU), and ker-nel modules can be excluded from TCB owing to their largeLoC ( Garfinkel et al., 2003 ).

They also suggested that Terra excludes MVM from TCB,but according to Li et al. (2012) , their MVM is just a simple Com-mand Line Interface(CLI), and all administrator works (such asVM create and shutdown) are actually implemented in VMM,which itself is trusted in Terra. Moreover, as Terra does notmeasure the environment before VM provisioning, Terra can-not guarantee a trusted boot for VM ( Rongyu et al., 2013 ).Furthermore, according to Berger et al. (2006) , Terra requiresvTPM, but they did not describe its design.

Terra is implemented using a VMware GSX server, and theydid not implement user interface ( Garfinkel et al., 2003 ).

5.1.2. Step after Terra (2012) Li et al. (2012) addressed the problem of providing a secure ex-ecution environment for VM under an untrusted MVM. Theyproposed an architecture that provides a secure network in-terface, secure storage, and secure run-time environment forDomU. DomU is protected from Dom0; thus, Dom0 is removedfrom TCB of DomU. However, Dom0 can carry out normal ad-ministrator tasks such as VM shutdown and migration. Theirwork can be considered as a step further than Terra.

For VM shutdown, TVMM needs to ensure that all memorypages are cleared before they are reallocated to a new VM. ForVM migration, they used the following steps: (1) All memorypages are encrypted before Dom0 on source CN can map thepages to its own address space. (2) A hash for every memorypage is calculated. (3) Memory pages are decrypted on desti-nation CN and their hashes are checked. (4) vCPU registers arealso encrypted and hashed before being transferred ( Li et al.,2012 ).

They also proposed an approach to protect all keys usedin their architecture, such as TLS and Virtual Private Network(VPN) keys as well as keys used in encryption of storage, vCPUregisters, and memory pages. All these keys are put in a singlefile, which is protected by a TPM key called the master key ( Liet al., 2012 ).

5.2. Binary-based RA:IMA

5.2.1. Original IMA (2004) Sailer et al. (2004) , researchers of IBM, presented the design ofIntegrity Measurement Architecture (IMA), as RA architecture,which extends TCG trust concepts. They extend Linux withhooks, called System Call Interceptors (SCIs) ( Xing et al., 2015 ),to measure the loaded SW and detect when changes occur tothis measurement. These hooks are inserted and controlledby Linux Security Modules(LSMs), such as Security-EnhancedLinux(SELinux). IMA measures dynamic loaders, shared li-braries, kernel modules, and executable files when they are

loaded into memory. They defined a protocol for RA based onthe integrity report protocol specified in TCG specifications( Xu et al., 2012 ).

One of the limitations is vulnerability to attacks in kernelmode, as IMA depends on kernel to verify LSMs ( Zhou et al.,2014 ).

5.2.2. PRIMA (2006) Jaeger et al. (2006) proposed a Policy-Reduced Integrity Mea-surement Architecture (PRIMA) as an improvement of IMA,which enhances privacy protection by reducing the numberof measured objects ( Xu et al., 2012 ).

5.2.3. myTrustedCloud (2011) UK myTrustedCloud project ( Wallom et al., 2011 ) studies theintegration of KVM-based cloud and VMM trust mechanismsbuilt upon IMA. The primary targeted sector of myTrust-edCloud is the energy industry, particularly the smart grid( Balogh et al., 2014 ).

5.2.4. Using IMA (2012) Wu et al. (2012) designed a series of role-based trusted proto-cols to guarantee that VMs execute only on TCN. They usedTTP to verify CN registration and interaction with other CNs.Every CN is equipped with TPM as well as IMA and Open Plat-form Trust Services (OpenPTS), which is an implementation ofTCG’s Platform Trust Services.

5.2.5. Out-of-the-Box Integrity Measurement Approach(2015)Xing et al. (2015) proposed an Out-of-the-Box Integrity Mea-surement Approach(OB-IMA), which measures processes andcritical files of VMs in a similar fashion to IMA, except that itis out-of-the-box. OB-IMA is implemented by Xen and Linuxwith few modifications to the existing SCI. However, OB-IMAcan be used in other virtualization platforms.

Hashing can be either in OS (in-the-box) or outside OS (out-of-the-box). Some limitations of in-the-box are vulnerabilityto malware and the need to modify OS. Out-of-the-box over-comes these limitations, but it has a semantic gap betweenthe inside and outside of VM; as an example, it needs to trans-late memory addresses to be used outside VM ( Xing et al.,2015 ).

Critical files, which OB-IMA can measure, include config,executable, script, and Java class files. In addition, they includekernel modules and any file that affects OS, such as programloaders or script interpreters. Generally, OB-IMA assumes thatfiles in directories such as /etc and /bin are critical files, whilefiles in directories such as /home are normal files. This canbe compared to IMA, which has no hook that can hash thesetypes of critical files ( Xing et al., 2015 ).

OB-IMA components are shown in Fig. 12 and are as fol-lows: (1) Syscall Capturer in VMM, (2) Integrity Manager inDom0, and (3) File Hasher in storage node. If CST runs a pro-cess or opens a file, Syscall Capturer will capture any systemcall (syscall) invoked by VM. Then, Syscall Capturer will informIntegrity Manager, which will hash the related files (with thehelp of File Hasher) and will extend the hashes into the asso-ciated PCR ( Xing et al., 2015 ).


Fig. 12 – Out-of-the-Box Integrity Measurement Approach

( Xing et al., 2015 ).

Fig. 13 – Trusted Cloud Computing Platform ( Santos et al., 2009 ).

5P

5SttauT

T(i

toCfttptl

lns

CC

Tko

Fig. 14 – Launching VM in TCCP ( Santos et al., 2009 ).

Fig. 15 – Migrating VM in TCCP ( Santos et al., 2009 ).

k

ap

Cb

e

fispnto

(bip

(T

i

tCt

.3. Binary-based RA: Trusted Cloud Computing Platform

latform

.3.1. Original TCCP (2009) antos et al. (2009) proposed a TCCP, which uses TCG specifica- ions to provide a closed-box execution environment guaran- ees privacy and integrity for VMs. Thus, no one including the dministrator can inspect or tamper VMs. TCCP allows CST to se RA to validate the integrity of CN. This is similar to what erra did, but Terra cannot handle VM migration or reboot.herefore, TCCP focuses on RA of CN during VM migration

Neisse et al., 2011; Rongyu et al., 2013 ). The TCCP architecture s shown in Fig. 13 .

TCB of TCCP includes TVMM and Trusted Coordina- or(TCrd), which cooperate to guarantee the execution of VMs n TCNs. External Trusted Entity(ETE) hosts TCrd and provides N information to TCrd. ETE, which may be the TPM’s manu-

acturer ( Han-zhang and Liu-sheng, 2010 ), needs to be main- ained by a third party, which cannot collude with CSP. This hird party can be one of the Certification Authority(CA) com- anies, such as VeriSign. In addition, they defined the “VM ini- ial state” as VMI and CST’s public key, which is used for ssh

ogin ( Santos et al., 2009 ). The VM launch steps are shown in Fig. 14 and are as fol-

ows: (1) CST encrypts “VM initial state” and its hash by a ewly generated session key and encrypts the session key it- elf and a nonce by the public part of TCrd’s trusted key. Then,ST sends all of these to CCtrl. (2) CCtrl chooses and informs N to host VM; then, CCtrl gives all that it has from CST to CN.his CN adds a new nonce and its ID to the encrypted session

ey, and then encrypts all of these twice (by the private part f CN’s trusted key and by the public part of TCrd’s trusted

ey) before sending to TCrd. (3) TCrd decrypts the session key,dds the two nonces, and encrypts all of these twice (by the rivate part of TCrd’s trusted key and by the public part of theNs’s trusted key) before sending to CN, which is now able to oot VM. (4) CN sends its identity and CST’s nonce to CST, bothncrypted by the session key ( Santos et al., 2009 ).

The VM migration steps are shown in Fig. 15 and are as ollows: (1) Source CN encrypts a nonce and destination CN

dentity by the private part of its trusted key. Then, source CN

ends its identity and this encryption, both encrypted by the ublic part of TCrd’s trusted key, to TCrd. (2) TCrd encrypts the once and public part of destination CN’s trusted key twice (by

he private part of TCrd’s trusted key and by the public part f source CN’s trusted key) before sending to the source CN.

3) Source CN encrypts another nonce and new session key y the private part of its trusted key. Then, source CN sends ts identity and this encryption, both encrypted by the public art of the destination CN’s trusted key, to the destination CN.

4) and (5) Destination CN repeats what source CN does with

Crd in steps 1 and 2. (6) Destination CN sends its nonce usedn steps 4 and 5 encrypted by the session key to the source CNo acknowledge the acceptance of the session key. (7) Source N transfers the “VM state” and its hash, both encrypted by

he session key, to destination CN ( Santos et al., 2009 ).


Fig. 16 – Improved Trusted Cloud Computing Platform

( Han-zhang and Liu-sheng, 2010 ).

Fig. 17 – Distributed TCCP ( Sen et al., 2015 ).

The disadvantages of TCCP: (1) The authors claimed thatthey used the private part of EK in RA during CN registration.According to TCG specifications, EK cannot be used in RA asthis is the role of AIK Khan et al. (2011) . (2) They used the ter-minology “trusted key,” which is used for encryption and de-cryption. This means, in case this is a TPM key, they are speak-ing about the legacy key. According to TCG specifications, thelegacy key is the least secure key that TPM can generate. (3)In step 6 of VM migration, destination nonce is sent to sourceCN. We believe that it should be the second nonce created bythe source CN. (4) They sometimes encrypt, then sign, and inother times, sign then encrypt; we recommend sign and thenencrypt to prevent replay attack with another signature. (5)Moreover, according to Yu et al. (2017) , TVMM overloads TPMuntil it becomes a bottleneck of CN, and TCrd becomes a bot-tleneck of the entire system.

5.3.2. Improved TCCP (2010) Han-zhang and Liu-sheng (2010) proposed an improved TCCP,shown in Fig. 16 , to decrease the dependence on TCrd. TheirTVMM combines vTPM and Terra. They classified VMs into (1)standard VM, (2) standard VM with vTPM, or (3) closed-box VM(because of using Terra) with vTPM.

If vTPMs exist in Dom0, vTPMs will be subjected to tamper-ing because of the administrator who controls Dom0. Thus,they created Trusted Host VM(THVM), which includes vTPMManager and vTPM instances. In addition, as THVM runs atthe highest privilege level, tampering is prevented even by theadministrator ( Han-zhang and Liu-sheng, 2010 ).

The role of managing CNs is transferred to one of the CNsthemselves. Hence, There are two types of CNs: (1) ordinaryCN and (2) CN, which has additional functionalities to manageordinary CNs (such as PCA capability). CN offers two types ofRA: (1) from CRTM up to Dom0 and (2) from CRTM up to THVM( Han-zhang and Liu-sheng, 2010 ).

In their architecture, the purpose of TCrd is to inform CSPabout rogue TPMs. In addition, they proposed Trusted Coordi-nator Manager (TCrdM) to support their hierarchical design.Therefore, if CN boots or reboots, it will contact TCrdM to de-termine its corresponding TCrd ( Han-zhang and Liu-sheng,2010 ).

5.3.3. TCCI (2013) Banirostam et al. (2013) proposed a Trusted Cloud ComputingInfrastructure(TCCI), which extends TCCP by adding ClusterController(ClsCtrl) between CCtrl and NCtrl.

5.3.4. Distributed TCCP(2015) Sen et al. (2015) proposed a Distributed TCCP(DTCCP), wherethe workload is distributed among several Helper VMsHVMsinstead of a single TCrd in order to minimize bottlenecks.From their point of view, TCCP has some disadvantages: (1)TCrd is a bottleneck, as it manages all CNs; (2) CCtrl cannotstop VMs that contain malicious codes; and (3) TCCP does notmake any profiling of CST or any pattern detection for ex-ploited VMs.

In DTCCP, which is shown in Fig. 17 , CCtrl manages a set ofClsCtrl, each in turn controls a specific cluster that contains aset of CNs. For every cluster, there is a single HVM to offloadsome of TCrd tasks. CN that hosts HVM is called a Helper CNand can be selected randomly by TCrd. After selection, HVMinforms all CNs of its cluster about its identity. TCrd maintainsa list of all Helper CNs and updates it whenever necessary.Every HVM has a database of all CNs within its cluster, whileTCrd has all databases of all HVMs. If HVM crashes, a new HVMwill be launched and will get its database from TCrd. HVM canadd/remove CNs to/from its cluster and can also shut themdown if necessary ( Sen et al., 2015 ).

They used the CN registration protocol of TCCP, but in VMlaunch and migration protocols, they just used HVM instead ofTCrd. Furthermore, they add a new protocol for VM migrationto another cluster. As TCCP, they did not implement a fullyfunctional prototype ( Sen et al., 2015 ).

5.4. Binary-based RA: Others

5.4.1. CERTICLOUD (2011) Bertholon et al. (2011) proposed CERTICLOUD, which uses twoprotocols: (1) TPM-based Certification of a Remote Resource,which asserts the integrity of a remote resource; and (2) Verify


Mi

a

5PVaptliVlt

5KataetS

cq

atqa

dlrpa(w

5

5Ndtp

otic

a

nfisdtcC

Fig. 18 – BonaFides ( Neisse et al., 2011 ).

Aa

2

waace

S

h(

5X

wS

O

oav

Iwc

Lami

2

5Littrc

fV

n(C

yVM, which allows CST to detect any tampering attempt on

ts VM ( Liu et al., 2013a ). They used security analysis tools suchs AVISPA and Scyther to validate their proposed protocols.

.4.2. Trusted Launch Protocol (2012) aladi et al. (2013) proposed a trusted launch protocol, for M, which uses binding and sealing to provide integrity guar- ntees to CST. The protocol does not require secure pre- ackaging of VMI on CST side. Moreover, the protocol requires he participation of CST, CCtrl, TCN, TTP, but allows CSP to se- ect TCN without involving CST to provide full scheduling flex- bility. The protocol ensures that no alteration to the launched

MI can be performed without CST permission. CST can uti- ize TCN to verify the integrity of the launched VMI. Their pro- otype is based on OpenStack, and they used TPM 1.2.

.4.3. Game Theoretic Approach (2015) amhoua et al. (2015) proposed a game theoretic approach to nalyze the feasibility of an open source cloud and to discuss he effectiveness of TC on CC. While open source SWs allow

ttackers to have deep understanding of SWs, they are also asier in finding security patches. In addition, as CSTs have he capabilities to verify the genuineness of an open source W, their confidence to CSP increases.

All implemented SWs are examined on the open source loud by a binary-based RA. By RA of VMM, attestation re- uester can verify the strength of VMM isolation capability,nd hence, decide whether VMs are subject to co-location at- acks or malicious VM Introspection. Moreover, RA of VM re- uires the support of vTPM, which is managed by vTPM Man- ger ( Kamhoua et al., 2015 ).

CSP has the option to offer TC, and each CST has the free- om to use TC or not. However, CSP can be exploited by a ma-

icious CST because of using open source SWs. Therefore, CSP equires each CST to take advantage of open source and re- ort all discovered vulnerability to CSP. In case of a successful ttack, CSP will repay to CST if CST is able to prove the attack using TC). If TC is used, the rate of attack detection in cloud

ill be greater than that without TC ( Kamhoua et al., 2015 ).

.5. Periodical RA

.5.1. BonaFides (2011) eisse et al. (2011) proposed BonaFides, which guarantees the etection of any malicious modifications to cloud infrastruc- ure to CSTs. Existing approaches for RA in cloud are em- loyed usually when VM is booted/migrated, library is loaded,r application is executed. Therefore, an attacker can modify he system in-between RAs. BonaFides goes one step further: t verifies the integrity of HW and SW at runtime whenever loud infrastructure is changed, i.e., it performs periodical RA,nd it focuses on RAs of CNs rather than those of VMs.

The BonaFides structure is shown in Fig. 18 . Its compo- ents are as follows: (1) Cloud Certifier, a TTP, which speci- es the cloud infrastructure’s requirements, e.g., the VMM ver- ion, and whose kernel modules are allowed to access DMA

evices. (2) Attestation Service(AS), part of Dom0, which takes he hashes on configurable periodical intervals or whenever hanges are detected. (3) Storage Service(SS), part of Cloud

ertifier, which stores the hashes after querying them from

S. (4) Certification Dashboard, which is notified by SS when

n undesired change in HW or SW is detected ( Neisse et al.,011 ).

BonaFides hashes VMM and kernel, kernel modules, net- ork/storage SWs, and system config files of Dom0. When

file change is detected, Dom0 triggers the AS that sends quote request. After receiving quote reply and (SML), AS hecks the integrity of all files, and sets up file change watch- rs, which are configured by kernel modules of Dom0. Finally,S verifies the integrity of (SML) ( Neisse et al., 2011 ).

One of the limitations is lack of flexibility, as BonaFides ashing timing is determined by the system designer Zhou et al., 2014 ).

.5.2. Real-time (2012) u et al. (2012) proposed a real-time RA architecture for IaaS,hich dynamically verifies whether the runtime behavior of W is trusted or not. It can deal with Time Of Check to Timef Use (TOCTOU) and code injection attacks.

Real-time Measurement Agent (in VMM) monitors the state f VM and informs the Local Attestation Agent (in Dom0) for ny change and measures the real-time state of VM. Then, it alidates the trust state according to the reference manifest.n addition, for each i time, CST sends a new quote request ith nonce i to the Local Attestation Agent that generated the

orresponding quote reply ( Xu et al., 2012 ). CoT of CN is constructed from HW, boot loader, VMM, and

ocal Attestation Agent, and is implemented by Trusted GRUB

nd Tboot. VM kernel is measured by Tboot, while VM kernel odules and executable files are measured by IMA. They mod-

fied Xen and IMA to be suitable to their prototype ( Xu et al.,012 ).

.5.3. T-YUN (2013) iu et al. (2013a) proposed T-YUN, where TTP periodically ver- fies the integrity of CN, while CN periodically verifies the in- egrity of VMs. TTP maintains a database to record the in- egrity information of trusted SWs. If CN is updated, CSP will egister its new version to TTP. They implemented a proof-of- oncept emulator to evaluate T-YUN.

VM launch: (1) CST provides the specifications of VM in the orm of (SML). (2) CST generates a symmetric key to encrypt MI and its hash. (3) CST sends to CCtrl through a secure chan-el the symmetric key encrypted by the public key of TTP and

SML) as well as encrypted VMI and its hash. (4) CCtrl selects N according to (SML). (5) CN sends the encrypted symmetric


key to TTP. (6) TTP verifies the integrity of CN before decrypt-ing the symmetric key and sending it back to CN. (7) CN usesthe symmetric key to decrypt VMI and its hash. (8) CN bootsVM after verifying its hash. (9) CN sends the running config-uration of launched VM to CCtrl that forwards it to CST. (10)CST verifies the integrity of its VM based on (SML) ( Liu et al.,2013a ).

VM Migration: (1) CCtrl selects destination CN and sendsits information to source CN. (2) Source CN asks TTP to obtainthe public key of destination CN. (3) TTP verifies the integrityof source and destination CNs before sending the public key ofdestination CN to source CN. (4) Source CN generates a sym-metric key to encrypt the migrated VMI and its hash. (5) SourceCN sends to destination CN the symmetric key encrypted bythe public key of destination CN as well as the encrypted mi-grated VMI and its hash. (6) Destination CN uses its privatekey to decrypt the symmetric key. (7) Destination CN uses thesymmetric key to decrypt the migrated VMI and its hash. (8)Destination CN resumes VM after verifying its hash ( Liu et al.,2013a ).

5.6. Property-based RA

5.6.1. Basic (2011–2013) Xin et al. (2011) proposed a property-based RA into a cloud en-vironment, where CST can verify CN properties without dis-closing critical information of CN.

Ma et al. (2013) tried to provide property-based RA to CSTwithout any interference from CSP. They supposed that CNhas a trusted agent, which communicates with other trustedagents within VMs, and the profile of VM is stored in its CN.

Property-based RA process: (1) CST asks for property-basedRA; hence, the trusted agent of VM sends a request to thetrusted agent of CN. (2) CN replies using the VM profile andits hash, both signed by CN’s AIK. (3) VM verifies the signaturewith its vTPM, and then encrypts the VM profile by a sessionkey to be sent to CST. (4) CST decrypts the VM profile ( Ma et al.,2013 ).

5.6.2. TPrCA (2014) Varadharajan and Tupakula (2014) proposed a trusted modelfor CC, which helps to detect and prevent attacks usingproperty-based RA between CST’s VM and Cloud Service Cus-tomer (CSC). They extended NCtrl, part of VMM, with whatthey called Trusted Property Certification Authority (TPrCA),which consists of Transaction Control (TrCtrl), TransactionStore (TrStr), and Process Validation (PrVal). If there is a varia-tion in the behavior of VM from the certified properties, TPrCAwill isolate this VM, or at least terminate the malicious pro-cess. Their implementation is based on Xen, and they pro-posed three properties for their architecture.

Preventing property. TPrCA ensures that traffic from VMhas a correct source IP address. The traffic with correct sourceIP address is logged in TrStr and forwarded to CSC; otherwise,TrCtrl drops the traffic, and a report is issued to CST and CSC.If CST is malicious, it will not reply, and CSP can terminate thisVM ( Varadharajan and Tupakula, 2014 ).

Reactive property. If CSC detects a malicious traffic fromVM, CSC will report to TrCtrl, which will validate the reportby checking TrStr. CSP can also use an attack analyzer, which

can host a snapshot image of the vulnerable VM in an isolatedenvironment. If the reported traffic is found in TrStr logs, andthe attack analyzer confirms the existence of malicious be-havior, TPrCA will isolate this VM. Either CST is malicious, orexternal attacker floods CSC by a spoofed source IP address ofVM. CSC will know from TPrCA if the received traffic originatesfrom VM or not. In some cases, a malicious CSC can also craftmalicious traffic with a spoofed source IP address of VM andreports to TPrCA, but CSP can reveal this claim by using TrStr( Varadharajan and Tupakula, 2014 ).

Proactive property. CST reports the security tools that areused for securing its VM. PrVal creates a list of all runningprocesses within VM. If VM is compromised, these securitytools will not be detected in the PrVal report, and TPrCA willdrop the traffic. Moreover, all VM processes reported by PrValis compared to the list reported by CST. If there is any variationin the two lists, then VM will be malicious, and TPrCA will dropthe traffic. This ensures that zero-day attacks on VM are onlypossible by known applications ( Varadharajan and Tupakula,2014 ).

5.6.3. TTAC (2014) Tupakula and Varadharajan (2015) proposed Trusted Trans-action Assurance Component (TTAC), which enables CSP tomonitor and certify the traffic from CST’s VM to CSC. Theyused a property-based RA, where attestation requester is CSCand attestation provider is VM, and they used the same threeproperties used by TPrCA. They developed ALOPA as a simplelogic-based language to express property relationships andtheir specifications.

TTAC components: (1) Transaction Validation Component,which drops any traffic with a spoofed source IP address. (2)Transaction Logging Component, which logs VM traffic. (3) Re-port Generation Component, which generates signed reportsupon request from Transaction Validation Component, whichare sent to VM and CSC in case of successful reports, but sentto VM-administrator and CSC in case of failure reports. (4)Customer Feedback Component, which receives the feedbackfrom CSC. (5) Proactive Detection, which plays the role of PrValin TPrCA and is a sub-component of Transaction ValidationComponent ( Tupakula and Varadharajan, 2015 ).

For the third property, if there is a variation in the num-ber of processes reported by Proactive Detection and VM, thecomparison will be repeated to handle the race scenario. If thevariation still exists after many repetitions, VM will be con-sidered malicious. To minimize overhead, this property willbe verified only when a new traffic is initiated ( Tupakula andVaradharajan, 2015 ).

5.6.4. RAA-TCCP (2015) Yan and Bin (2015) proposed a Remote Anonymous Attesta-tion of TCCP (RAA-TCCP) protocol, which realizes the iden-tity and integrity of CN. RAA-TCCP neither uses attribute cer-tificate nor AIK certificate, which simplifies certificates man-agement. This is done by using offline TTP and Property-Based Ring Signature (PBRS) ( Wenqiang and Shaozhen, 2009 ).In PBRS, members of the same property form a ring, and eachmember can be in other rings. Because of the number of mem-bers within the same property, the identity of the signer canbe hidden in the ring.


Fig. 19 – Trusted Access Protocol ( Chang et al., 2015 ).

mPtCta

5Cci(e

wwc

att

pCaftte

robc

5

5Jtbe

fl

a

csiC

Trp

Cqtta

5

5Zstmiomm

BTl

D

srm

wt

sinADe

wiTp

2

5

5Xbp

RAA-TCCP forms the abstract of the groups and the binary etric of PCRs into one or more properties. RAA-TCCP, using

BRS, verifies the ring signature to judge CNs. RAA-TCCP has wo phases: (1) proof preparation, where CN ensures it has EK

ert, PCRs, and ring signature key; and (2) proof implementa- ion, where ring signature proves CN security properties ( Yan

nd Bin, 2015 ).

.6.5. Trusted Access Protocol (2015) hang et al. (2015) proposed a trusted access protocol for CC by onstructing a trusted access authentication framework us- ng RA. The framework, which is shown in Fig. 19 , consists of 1) CN with TPM and Trusted Measurement Log(TML) ( Huang t al., 2013 ); (2) CST machine with TPM, TML, and Smart Card,hich is distributed by CSP; (3) Attestation Proxy Server(APS) ith Security Policy DB(SPD); and (4) CA, which provides AIK

ertificates to all other parties. They used TCG’s TNC to verify the identity and platform

uthentications of CST machine and CN. For identity authen- ication, CST and CN authenticate each other while CST puts he Smart Card into its machine. For platform authentication,latform integrity and security properties of CST machine and

N are stored into their corresponding TML as the platform

uthentication information. CN asks APS to verify the plat- orm authentication information of CST and vice versa. SPD is he place where the standard values of the platform authen- ication information for both CST and CN are stored ( Chang t al., 2015 ).

Trusted access protocol phases: (1) Registration, where CST

egisters at CN. (2) Login and Authentication, where CST logins n CN after mutual authentication of identity and platform

etween CST and CN ( Chang et al., 2015 ). One of the short- omings can be the direct interaction between CST and CN.

.7. Periodical Property-based RA

.7.1. CORA (2015) ian-hong (2013) proposed a Dynamic Property Trusted Attes- ation (DPTA), which overcomes the static feature of property- ased RA. Hence, Zhenpeng et al. (2015) proposed a Client Ori- nted Remote Attestation (CORA) based on DPTA and DAA, but

or CC. CORA does not expose classified information such as ocation of CN.

CORA is built on Eucalyptus and uses TTP that issues DAA

nd SLA certificates to CNs. Every CN uses its TPM to hash itsonfiguration; then, TTP maps the hashes into properties to is- ue SLA certificate. CCtrl verifies SLA certificate before adding ts properties to the list of properties of all CNs. CCtrl assigns N for CST’s VM according to the properties requested by CST.hey added life service for certificates, based on DPTA, to pe- iodically update SLA certificates, which updates the list of roperties of all CNs at CCtrl ( Zhenpeng et al., 2015 ).

Their proposed protocols include (1) Issuing DAA and SLA

ertificates Protocol, which is executed by TTP based on a re- uest from CN; (2) CN Registration Protocol, which allows CN

o register to CCtrl; and (3) CST Request and Verification Pro- ocol, which allows CST to submit a service request to CCtrl nd verify CN’s properties ( Zhenpeng et al., 2015 ).

.8. Behavior-based RA

.8.1. DTSTM (2014) hou et al. (2014) proposed a Dynamic Tree Style Trust Mea- urement Model (DTSTM) to measure VM based on behavior race, i.e., sequence of states instead of current state. Their

easurement methods are as follows: (1) Integrity-based, dur- ng VM boot, which measures VMM, MVM, and initial state f config files. (2) Behavior-trace-based, during VM run, which

easures state at one moment and traces behavior after that oment. DTSTM consists of (1) upper part, which includes CRTM,

IOS, boot loader, Dom0 Kernel, Dom0 OS, and Dynamic rusted Measurement Agent (DTMA) (part of Dom0); and (2) ower part, which includes DTMA components, DomU Kernel,omU OS, and DomU applications ( Zhou et al., 2014 ).

DTMA components: (1) Measurement Agent, which mea- ures SWs during DomU boot, monitors behavior of SWs, and

emeasures SWs in case of update. (2) Secure Storage, which

aintains keys, PCRs, and vPCRS. (3) Component Manager,hich manages SW install, update, or delete, and stores cer-

ificates of SW properties in an SW list ( Zhou et al., 2014 ). If SW is updated, Component Manager will trigger Mea-

urement Agent to remeasure SW again, and modify its record

n the SW list. After building conventional CoT, DTMA can start ew DomU and monitor its behavior. Security of Measurement gent is ensured by separating the trust relationship between

om0 and DomU by using SCI and VM Introspection ( Zhou

t al., 2014 ). Proposed algorithms: (1) Tree Construction Algorithm,

hich will be invoked by Component Manager, when DomU

s created to construct a tree structure of DomU’s SWs. (2) ree Measurement Algorithm, which will be invoked by Com- onent Manager if the status of SW is changed ( Zhou et al.,014 ).

.9. Integrated RA

.9.1. CPTBA (2013) ie and Du (2013) integrated the property-based RA and

ehavior-based RA into CC. They called this integration Com- onent Properties and System Behavior (CPTBA).


Table 5 – Comparison between Remote Attestation types.

Binary Periodical Property Periodical property

Behavior

Security High High Very high Very high Extremely high Performance Very fast Fast Above medium Medium Medium

Implementation Very easy Easy Hard Very hard Extremely hard Severe Attacks Protected Protected Very protected Very protected Extremely

protected

Table 6 – Comparison between binary-based RA types.

Terra IMA TCCP

Main Idea run SANDs in closed-box VM

Extend Linux with SCIs Closed-box with integrity for VM

Performance TPM speed Hooks slow TPM speed TPM and TCrd are overloaded

Implementation implemented using VMware GSX

Implemented using RedHat not implemented

Attacks 1) attacking open-box VM

(2) co-location attacks (1) Kernel mode attacks (2) vulnerable to malware

1) vulnerabilities of VM

Cons 1) no environment measurement before VM

provisioning (2) cannot guarantee VM trusted boot

(1) Lack of directory protection (2) attacker can change metadata file

(1) The claiming of using EK

in RA 2) TVMM overloads TPM 3) TCrd is a bottleneck

VM Migration not available not mentioned available

5.10. Remote Attestation comparisons

In Table 5 , we compare binary-based, periodical binary-based,property-based, periodical property-based, and behavior-based RA. The comparison criteria are security, performance,the possibility of implementation, and the protection againstsevere attacks.

In Table 6 , we compare the types of binary-based RA whichare Terra, IMA, and TCCP. The comparison criteria are the mainidea, performance, way of implementation, possible attacks,cons, and the availability of VM Migration.

6. Trusted Virtual Domain

Trusted Virtual Domain (TVD) can be defined as a group ofrelated VMs running on separate CNs into a single networkwith specific security policies. TVD ensures that CSTs’ dataare not disclosed to each other, and malicious code cannotspread mutually ( Liu et al., 2013a ). Techniques such as VirtualLAN (VLAN) and VPN are used to implement TVD ( Wan et al.,2012b ).

Sailer et al. (2005) , researchers of IBM, presented Secure Hy-pervisor (sHype) as a Mandatory Access Control (MAC) frame-work integrated into Xen. Moreover, sHype can be consideredas a VMM that hashes SW using TPM as well as manages inter-VM resource access control (resource sharing) and isolation ofVMs on a single CN. sHype supports two types of MAC models,which are Simple-Type Enforcement and Chinese Wall ( Baloghet al., 2014; Qiang et al., 2013; Zhang and Chen, 2013 ). It isworth mentioning that McCune et al. (2006) proposed Shamon,which extends sHype by using IP security(IPsec) and SELinux,

which can be considered as a MAC implementation ( Qianget al., 2013 ).

6.1. TVDc (2008)

Berger et al. (2008) , researchers of IBM, proposed a Trusted Vir-tual Datacenter (TVDc), as an implementation to TVD, to se-cure the cloud by using vTPM and sHype. TVDc provides strongisolation of VMs by enforcing MAC policies of sHype through-out the data center ( Kamhoua et al., 2015; Wan et al., 2012b ),but VMs in the same VLAN are open to each other withoutMAC enforcement ( Qiang et al., 2013 ).

6.2. PVI (2010)

Krautheim (2010) proposed a Trusted Virtual EnvironmentModule (TVEM), which is designed as a new SW appliance forTPM virtualization. TVEM serves as a virtual security modulefor cloud applications to make CST trust its VM and make CSPand CST share responsibility of data. One of the limitations ofTVEM is its large TCB ( Balogh et al., 2014; Hao and Cai, 2011 ).

In his architecture, which is shown in Fig. 20 , CN is calledTrusted Computing Fabric Platform (TCFP), which hosts Vir-tual ServerS (VSs) for CSTs. VS is a coupled VM, compris-ing a normal VM and another one called Locator Bot (LoBot),which is responsible for security services. LoBot is instanti-ated and managed by a management center, called PrivateVirtual Infrastructure Factory(PVIF), which is outside all CNs( Krautheim, 2010 ).

He also presented PVI, based on TVD, which is responsiblefor the communication between PVIF and LoBots. PVI providesRoT and separates the responsibility of security management


Fig. 20 – Private Virtual Infrastructure ( Krautheim, 2010 ).

Fig. 21 – Trusted Virtual Domain Security ( Tupakula and

Varadharajan, 2011 ).

bW

6

TDwptnitiawT

viautmt

ct

(

w

Fig. 22 – Trusted Virtual Private Datacenter ( Wan et al., 2012b ).

(n

2

6

WttvatkiabduT

saCdv

(ttVnpct

vaj

6

Qm

etween CSP and CST ( Kashif et al., 2015; Krautheim, 2010; an et al., 2012b ).

.3. TVDSEC (2011)

upakula and Varadharajan (2011) proposed a Trusted Virtual omain Security (TVDSEC) as a new technique that can deal ith zero-day attacks in TVDs. For each TVD, specific security olicies are developed for all VMs in this TVD. If communica- ion to VM does not satisfy the security policies, this commu- ication will be prohibited. Before CN can join TVD, admin-

strator validates whether CN has the capabilities to enforce hese security policies. If so, then TVD proxy, which is shown

n Fig. 21 , is implemented on Dom0 to enforce TVD policies nd to validate VMs before allowing them to join TVD. VMM

ill have two TVD proxies, if it hosts VMs from two different VDs.

As VMM has complete control of the resources and good

isibility of the internal state of VMs, the security tools placed

n VMM have the capabilities of performing both host-based

nd network-based Intrusion Detection System (IDS). CRTM is sed to ensure the secure state of VMM and VMs during boot ime. However, as there is a possibility for VM to be compro-

ised during runtime, TVDSEC monitors all VM communica- ions ( Tupakula and Varadharajan, 2011 ).

TVD proxy components: (1) Sec_Pol, which enforces the se- urity policies for communication inside TVD (e.g., to ensure hat correct physical and IP addresses are originated from VM).2) Trans_Str, which is where Sec_Pol writes logs. (3) Trans_Ctrl,

hich records CNs that hosts other VMs within the same TVD.

4) Dom_Sec, which enforces the security policies for commu- ication among different TVDs ( Tupakula and Varadharajan,011 ).

.4. TVPDc (2012)

an et al. (2012b) proposed a Trusted Virtual Private Datacen- er (TVPDc) as an extension to TVDc. In TVPDc, TVM hosts he guest OS and Trusted Agent Service (TAS), which includes TPM. Every TVPDc has a trusted management center outside ll CNs, called Trusted Virtual Factory (TVF), which is similar o PVIF. TVF assigns a vTPM instance to TVM, creates vTPM

eys, plays the role of CA for vTPM’s vEK, and has the author- ty to shutdown TVPDc completely. MVM has access to TPM

nd runs vTPM Manager, which manages all communications etween TVM and its vTPM. The vTPM driver is split into FE river at TVM and BE driver at MVM. For implementation, they sed Intel vPro (which provides Intel VT and Intel TXT) and

PM 1.2 on every CN. Their proposed CN is shown in Fig. 22 . Their TVMM uses Xen isolation, which is extended by

Hype, to enable strong isolation among VMs. TVPDc’s Stor- ge Area Network (SAN) isolation is based on Capability-based

ommand Security (CbCS), which is an extension of SCSI stan- ards. VM can access the associated vDisk only, if it has the alid credential ( Wan et al., 2012b ).

The TVPDc deployment protocol consists of three phases.1) logical deployment, where TVF and CCtrl mutually authen- icate each other and set up a secure communication channel o allow TVF to send TVPDc’s deployment policies to CCtrl; (2) M provisioning, where CCtrl selects a CN that meets TVF’s eeds. Then, CN informs TVF on the selection and provides a roperty-based RA to verify its security properties. If CN suc- eeds, TVF will permit the transmission of the instantiated VM

o CN; (3) joining TVPDc, where CN orders TPM to load vEK,SRK, and virtual AIK(vAIK) into VM’s vTPM. Then, VM boots nd provides a property-based RA to TVF, which allows VM to oin TVPDc ( Wan et al., 2012b ).

.5. CloudAC (2013)

iang et al. (2013) proposed the name Logic Virtual Do- ain (LVD) as an extension to TVD to describe the dynamic


Fig. 23 – CloudAC ( Qiang et al., 2013 ).

collection of VMs running on different CNs to run a distributedapplication. They proposed CloudAC, which is a multilayeraccess control architecture for LVD, with the aim of provid-ing isolation, information flow, and resource sharing controlsamong multiple VMs.

The CloudAC architecture is shown in Fig. 23 , and its com-ponents are as follows: (1) LVD Master (in CCtrl), which storesand configures policies for LVD and is globally unique for eachLVD; (2) LVD Agent Factory (in Dom0), which generates LVDAgents in each CN; (3) LVD Agent (in Dom0), which sets ac-cess control policies for LVD in CN and is unique for LVD perCN; (4) LVD Policy Info, which is part of the LVD Agent, whereLVD policies are stored; (5) Secure Control Module (in Dom0),which is designed for network access control; and 6) Local Pol-icy Driver (in VMM), which is designed for local storage accesscontrol ( Qiang et al., 2013 ).

LVD protocol: (1) LVD Agent Factory sends VM creation re-quest to LVD Master, which replies by a nonce for quote oper-ation. (2) LVD Agent Factory sends quote reply to LVD Master,which verifies quote reply, and replies by LVD policies. (3) LVDAgent Factory creates LVD Agent, which caches LVD policiesinto LVD Policy Info and asks Secure Control Module to createVM. (4) Secure Control Module creates VM ( Qiang et al., 2013 ).

Information flows among VMs can be controlled by MACpolicies, but VM may observe the behavior of other VMs byaccessing shared resources, such as shared storage. This typeof information flow is called covert channel, which is avoidedin CloudAC by adopting a new MAC model called PrioritisedChinese Wall (PCW) ( Cheng et al., 2008; Qiang et al., 2013 ).

CloudAC implements access control in three layers: (1)Inter-LVD. For VM to send or receive a message to or from VMin another LVD, Decentralised Information Flow Control (DIFC)( Myers and Liskov, 2000 ) is used, as it can delegate the task ofpolicies definition to individual applications. For vDisks, if in-formation flow between two LVDs in a specific direction is per-mitted, VM in first LVD can write to vDisk in second LVD, whileVM in second LVD can read from vDisk in first LVD and viceversa. (2) Intra-LVD. They used Bell-LaPadula, whose policies

use four security classes: usual, common, secret, and top se-cret. In addition, they used Discretionary Access Control (DAC),whose policies use “send right”, which means that VM is ableto send a message to other VMs, or “own right”, which meansthat VM can pass the “send right” to other VMs. (3) CN itself.They used PCW, which can avoid the covert channel amongVMs on the same CN. Furthermore, for VM to join LVD, theyused Chinese Wall or PCW based on CST requirements ( Qianget al., 2013 ).

6.6. CDCoT (2012)

Abbadi (2012) proposed a Domain CoT(DCoT) and Collaborat-ing Domains CoT(CDCoT) to facilitate RA in cloud and hidecloud application details. The cloud application is bound to asingle combined CoT, which attests to a cluster of CNs thathave the same configuration ( Kamhoua et al., 2015 ). However,he defined domain as a container that includes related re-sources, and there are physical, virtual, and application do-mains. He also moved RoT to his suggested trust anchors,which are layer oriented and represent a pool of resourcesat each layer. Attestation requester needs to verify the trustanchor at a given layer before building CoT. If attestation re-quester trusts the trust anchor, then all resources attested bythe trust anchor will be trusted.

The trust anchor layers are (1) physical layer trust anchor,which is a set of physical CDCoT; (2) virtual layer trust anchor,which is a set of virtual CDCoT; and (3) application layer trustanchor ( Abbadi, 2012 ).

6.7. TVD comparison

In Table 7 , we compare TVDc, PVI, TVDSEC, TVPDc, CloudAC,and CDCoT. The comparison criteria are the security, perfor-mance, implementation, vTPM type, and protection againstsevere attacks.

7. VM cloning and migration

Danev et al. (2011) and Liang et al. (2013) proposed a VM–vTPM migration protocol, but only in private cloud. Hong et al.(2013) and Fan et al. (2015) proposed a VM–vTPM live migra-tion protocol, without the restriction of private cloud. In thenext sections, we discuss some of VM migration and cloningprotocols.

7.1. VM Migration: InterCSPs (2011)

Celesti et al. (2011) applied RA to secure VM migration in feder-ated cloud to allow source CSP to ensure that CN at destinationCSP is trusted. In order to secure VM migration, the integrity ofboth VM and its CN needs to be assured. For implementation,they used Java Trusted SW Stack (jTSS), Java Cryptography Ex-tension, and IAIK TCcert. They also made up their PCA withX509 certificates.

Federated cloud refers to a mesh of CSPs that are intercon-nected based on open standards to provide a universal servicein multi-provider infrastructure. Such system includes hun-dreds of independent and heterogeneous clouds to transpar-ently share physical resources. DepSky is an example of an


Table 7 – Comparison between Trusted Virtual Domain Types.

TVDc PVI TVDSEC TVPDc CloudAC CDCoT

Security Low Low Medium Low Low Medium

Performance High High Medium High High Medium

Implementation Prototype Available Available Available Prototype Not available vTPM Type SW SW (TVEM) Not mentioned SW SW Their own Severe Attacks Vulnerable Vulnerable Possible Vulnerable Vulnerable Possible

Fig. 24 – VM Migration: InterCSPs ( Celesti et al., 2011 ).

o

2

(sl

bAAbadrCtP

(te

7

ZMpac

Fig. 25 – VM Migration: Protection Aegis for LiveMigration

( Zhang and Chen, 2013 ).

oimdopa

gomc

mtsdttp

F

rmtuptotg

pen source cloud federation ( Celesti et al., 2011; Rocha et al.,011 ).

The protocol steps are shown in Fig. 24 and are as follows: 1) Source CSP sends a migration request to destination CSP pecifying the required HW and SW. (2) Destination CSP se- ects CN that creates AIK, which is sent with EK certificate,oth encrypted by PCA’s public key, to PCA. (3) PCA retrieves IK by decrypting the received message, and then PCA creates IK certificate. (4) PCA replies with AIK certificate encrypted

y EK of destination CN. (5) Destination CSP announces the cceptance of VM migration. (6) Source CSP sends a nonce to estination CN. (7) Destination CN sends AIK certificate, quote eply that includes nonce, and (SML) to source CSP. (8) Source SP gets PCA public key to verify AIK certificate, and uses AIK

o verify quote reply. Then, source CSP compares the received

CRs with PCRs calculated from (SML) and verifies the nonce.9) VM is migrated and source CSP is able to periodically check he integrity of PCRs at destination CN by using RA ( Celesti t al., 2011 ).

.2. VM Migration: PALM (2013)

hang and Chen (2013) proposed a Protection Aegis for Live igration (PALM) as a prototype for their VM live migration

rotocol. They used a VMM-based process protection, which

voids a trusting guest OS, while ensuring the security of exe- ution environment. Therefore, it provides a curtained mem-

ry and sealed storage for protected process. VMM interposes nteractions between protected process and guest OS via a

id-way buffer and encrypts data flowing to guest OS while ecrypting data flowing to protected process. They focused

n memory protection during VM migration and ignored disk rotection because of using network file systems, such as NFS nd iSCSI.

In PALM, protected memory page is tracked by VMM to uarantee that it is exclusively mapped by the processes that wn it, and not even kernel. Metadata of these processes are aintained in VMM including register values, memory en-

ryption keys, and others ( Zhang and Chen, 2013 ). They added to VMM (1) Data Protector, which encrypts

emory pages on source CN and decrypts them on destina- ion CN; (2) Metadata Manager, which collects metadata on

ource CN; and (3) Security Guard, which reconstructs meta- ata on destination CN. Moreover, they added to Dom0 (not rusted) (1) a Migration Manager, which performs VM migra- ion; (2) a Comm Agent, which performs integrity reporting rotocol ( Zhang and Chen, 2013 ). All of these are shown inig. 25 .

VM live migration phases: (1) Pre-copy. While VM is still unning, Migration Manager maps a batch of encrypted VM

emory pages in its memory space, sends the pages to des- ination CN, unmaps the batch, and maps the next batch

ntil all pages are sent. VMM tracks dirtied pages and re- orts to Migration Manager, which starts a new round to send

hese dirtied pages. (2) Stop-and-copy. When pre-copy thresh- ld is reached, Migration Manager suspends VM and sends he rest of memory pages to destination CN. In addition, Mi- ration Manager sends the metadata received from Metadata


Table 8 – Comparison between vm migration and cloning types.

Inter CSP PALM TVMCM

Type VM migration VM migration VM cloning Implementation Implemented using jTSS,

IAIK TCcert and JCE Implemented using Xen and Linux

Not implemented

vTPM Not mentioned Not mentioned SW-based Memory Not mentioned Protected page by page Protected by TCVMM

Storage Not mentioned Ignored due to NFS and iSCSI

Protected by TCVDM

Attacks (1) Man in the middle attack (1) Vulnerabilities of VM to attack destination CSP

(1) vulnerabilities of VMM

Manager encrypted by a session key, which is created by theirintegrity reporting protocol. (3) Resumption. After receiving allthe memory pages, VMM of destination CN locates and de-crypts all memory pages. Then, Migration Manager of destina-tion CN receives the encrypted metadata before passing themto VMM ( Zhang and Chen, 2013 ).

7.3. VM Cloning: TVMCM (2012)

Ma et al. (2012) proposed a Trusted VM Clone Model(TVMCM),which consists of (1) a Trusted Clone of Virtual MemoryModel(TCVMM), which has two phases and (2) a Trusted Cloneof Virtual Disk Model(TCVDM).

TCVMM first phase: (1) Source CN verifies destination CNby RA. (2) TPM_CreateInstance is called to create a new vTPMinstance, which inherits the values of PCRs 1–7 from TPM ofdestination CN and communicates with vTPM of source VMfor other vPCR values. (3) Source VM verifies destination VMby RA ( Ma et al., 2012 ).

TCVMM second phase: (1) Source VM sends to destinationVM one memory page and its hash, as well as a signature byAIK on this hash. (2) Destination VM copies the received mem-ory page after verifying the signature. (3) These two steps arerepeated for every memory page ( Ma et al., 2012 ).

TCVDM uses the same process of verifying the signature onmemory page for vDisk block. When destination VM is created,an empty vDisk and a bitmap are assigned to it. The bits of thebitmap are used as flags to determine whether the vDisk blockis cloned or cloning is in progress ( Ma et al., 2012 ).

7.4. VM cloning and migration comparison

In Table 8 , we compare InterCSPs, PALM, and TVMCM. Thecomparison criteria are the main idea, performance, way ofimplementation, possible attacks, cons, and the availability ofVM Migration.

8. Using additional features to support TCC

This section starts by discussing modifying some TCG Proto-cols. The remaining sections discuss some additional featuresthat can be combined with TCC.

8.1. Modifying TCG protocols

8.1.1. OOAP (2014) TCG proposed: (1) Object-Independent Authorization Proto-col(OIAP) and Object-Specific Authorization Protocol (OSAP) totransmit authorization evidence from TPMs to requesters; and(2) AuthData Insertion Protocol (ADIP), AuthData Change Pro-tocol (ADCP), and Asymmetric Authorization Change Protocol(AACP) to generate and modify authorization data. However,some researchers discovered certain vulnerabilities in OIAPand OSAP. Therefore, Luo et al. (2014) proposed an authoriza-tion protocol through a secure channel between a process thatrequests a TPM command and TPM or vTPM, to protect CST’ssensitive data from unauthorized access in TCCPs. This proto-col assembles OIAP, OSAP, and AACP. Hence, its name is OIAP–OSAP–AACP Protocol (OOAP), which is compatible with TCGTPM command formats.

8.1.2. Based-IF-MAP (2014) In 2008, TCG’s TNC Working Group released the initial specifi-cations of Interface for Metadata Access Points (IF-MAP) pro-tocol, which creates a structured procedure to store, correlate,and retrieve identity, access control, and security posture in-formation about users and devices on a network. Therefore,resources in cloud can be identified and assigned to appropri-ate requests using IF-MAP. In addition, in 2013, TCG’s TrustedMulti-Tenant Infrastructure(TMI) Working Group published itsreference framework ( Chi et al., 2014 ).

Chi et al. (2014) proposed an access control model, based onIF-MAP and the reference framework of TMI Working Group,to regulate the access of cloud resources. They added a serverfor IF-MAP, which stores information on endpoints, users, andflows in the network. They used eXtensible Access ControlMarkup Language (XACML) to represent all IF-MAP data andoperations in XML format. They illustrated their proposed ar-chitecture and its message workflow.

8.2. Access control

8.2.1. CV(2010) Schiffman et al. (2010) proposed a Cloud Verifier, which playsthe role of a verification proxy, to verify the integrity and ac-cess control enforcement abilities of CNs. Their verificationprotocol can be summarized as follows: (1) CST sends quoterequest to Cloud Verifier. (2) Cloud Verifier verifies itself to CST,and forwards quote request to CN. (3) CN sends quote reply to


Ca

8Spttmkfs

8Lc

St(CV

8

EgAipCuaVz

2

8Kac

wTtufmmwc

8S

tSvbc2T

dtCe

tt

8SefVsa

f

8

TtZSt(

8Rttt(

p

8RRApbdi

8A(ccf

ws

c

8G

blbf

loud Verifier, which forwards it to CST. (4) CST starts its VM

fter verifying quote reply.

.2.2. RBAC (2010) hen et al. (2010) integrated TCP into CC, where CST binds its ersonal ID, stander certificate from CA, and role information

o be verified by CSP, which accepts or rejects CST’s access to he cloud using a Role-Based Access Control (RBAC). Every CN

aintains a master secret key (we assume it is EK), and this ey is used to generate a unique sub-key (we assume it is AIK) or every possible configuration. Moreover, they used sealing o that data cannot be decrypted in different configurations.

.2.3. SAL and CUM (2012) iu and Wang (2012) proposed a model for identity authenti- ation and access control, and TC is used to strengthen them.ervice in this model may need multiple VMs. These VMs have o register their identities into a Service Authentication List SAL). If VM can no longer support one service, VM will inform

onfiguration Update Module(CUM), which will select a new

M to replace the old one before updating SAL.

.3. Eucalyptus

lastic Utility Computing Architecture for Linking Your Pro- rams To Useful Systems is an open source alternative to mazon EC2. Eucalyptus is designed as a modular system us-

ng replaceable and extensible components, where each com- onent has a well-defined web service. Eucalyptus includes Ctrl, ClsCtrl, and NCtrl. CCtrl is a web interface that can be sed to add and remove VMIs or CSTs. Eucalyptus provides web interface to CST to launch, manage, and terminate its Ms. Eucalyptus CNs can be powered by Xen or KVM ( Han- hang and Liu-sheng, 2010; Khan et al., 2011; Santos et al.,009; Sule et al., 2016 ).

.3.1. Trusted Eucalyptus (2011) han et al. (2011) implemented a new trusted Eucalyptus by dding RA and making some modification to traditional Eu- alyptus, which includes (1) a Trusted Integrity Verifier(TIV),hich is added to act as TTP, so that it verifies the integrity of CN particularly TVMM, and secures VM launch and migra-

ion; (2) NCtrl, which proves TCN integrity, at boot or reboot sing TPM and IMA, to TIV; (3) TVMM, which protects VMs rom being inspected or tampered by any party, including ad-

inistrator, and coordinates with TIV to limit VM launch and

igration to only TCNs; and (4) Storage Controller, which is here VMIs are stored in encrypted form to restrict VM exe-

ution only on TCNs.

.3.2. Excalibur (2012) antos et al. (2012) proposed Excalibur, based on Eucalyptus,o provide a secure IaaS that can create VMs with known

Ws. Any VM is securely launched with a symmetric key (for Disk) and asymmetric key (for TLS). Excalibur allows data to e sealed or unsealed only by CNs whose configuration (se- urity status) matches a predefined policy. Excalibur contains 2,000 LoC, which makes it very difficult for CST to evaluate CB even if Excalibur is an open-source ( Ryan, 2013 ).

Excalibur steps: (1) CST decides a policy and encrypts its ata. (2) CSP decrypts this data if its security status satisfies he policy specified by CST. (3) The security status is sent to ST in the form of key certificates and quote reply. ( Santos t al., 2012 ).

One of the shortcomings can be the long time of keeping he symmetric and asymmetric keys in memory, which makes hem vulnerable to attacks ( Ryan, 2013 ).

.3.3. Evaluate CoT of CN (2016) ule et al. (2016) presented some security mechanisms that nable CST to evaluate the trust level of Eucalyptus using uzzy logic. In their work, CoT is established from CRTM to MM, where the final trust is the minimum offered by all tages that are part of CoT. They represented each stage of CoT

s a node in a graph and calculated the trust level of CN usinguzzy logic based on this graph.

.4. Hybrid trust

rust can be classified into three types as follows: (1) Hard

rust, which is based on HW such as TPM, AEGIS, ARM Trust- one, and M-Shield (most of them are based on TPM). (2) oft trust, which can be based on reputation, context, or con- ent. (3) Hybrid trust, which combines both of the above types Akram and Ko, 2014 ).

.4.1. RepCloud (2011) uan and Martin (2011) proposed RepCloud as a reputa- ion system for managing decentralized RA in cloud, which

hey called Decentralized Attestation. Decentralized Attesta- ion integrates RA with reputation system inside the cloud

Kamhoua et al., 2015 ). In RepCloud, CNs are treated as peers ineer to peer networks to calculate reputation ( Liu et al., 2013a ).

.4.2. NeuronVisor (2014) uan and Martin (2015) proposed NeuronVisor as a Cloud

oot of Trust(cRoT) framework, which enforces Decentralized

ttestation to determine a single cRoT for each cloud ap- lication. They also hide the cloud implementation details y enforcing the property-based RA, but the lack of a well- eveloped property translation prohibits the effectiveness of

ts implementation ( Kamhoua et al., 2015 ).

.4.3. Digital Trust Framework (2014) kram and Ko (2014) proposed an architecture that includes

1) Trusted Platform HW, (2) Trusted Platform OS, (3) Cloud Or- hestrator, (4) Virtual Trusted Agents, and (5) VMs. Cloud Or- hestrator manages network, storage, and all other resources or VMs. Every VM can have a dedicated Virtual Trusted Agent,hich can be built on TCP’s RoT. This architecture, which is

hown in Fig. 26 , can also support hybrid trust, where soft trustan be built on top of hard trust.

.4.4. Evaluate Trust of CSP (2014) u et al. (2014) proposed a tree structured trust model in cloud,y distributing trust evaluation to multiple CNs, using fuzzy ogic to calculate the trust value of CSP based on CST feed- ack. They combined trust evaluation from CN via TPM and

rom VM via vTPM, where the first CoT consists of CRTM, BIOS,


Fig. 26 – Digital Trust Framework ( Akram and Ko, 2014 ).

Fig. 27 – Dedicated Trusted Monitoring VM ( Zou et al., 2013 ).

GRUB, and VMM, and the second CoT consists of VM SWs.They used CloudSim and MathLab for evaluation.

8.5. Out-of-box Monitoring

8.5.1. Dedicated Trusted Monitoring VM (2013) Zou et al. (2013) proposed a Monitoring VM, which plays therole of TTP dedicated for monitoring purpose. As securitymonitoring has to inspect the internal state of guest OS, itmay not satisfy the required generality of Monitoring Tools,i.e., Monitoring Tools may not fit with all OSs. To solve thisissue, they proposed the idea of a monitoring driver, whichprovides a uniform interface for Monitoring Tools. There aredifferent types of monitoring drivers corresponding to differ-ent guest OSs so that Monitoring Tools can be independent ofguest OSs.

The architecture is shown in Fig. 27 and its components areas follows: (1) Event Sensor for Dom0 (in VMM), which inter-cepts the privileged operations taken by Dom0 onto DomUsand sends them to Dom0 Daemon. (2) Event Sensor for DomU

(in VMM), which intercepts the system calls of DomUs andprovides a communication interface to monitoring drivers,which are administrated by Monitoring Module. (3) Monitor-ing Tools (in Monitoring VM), which administers both Dom0Daemon and Monitoring Module ( Zou et al., 2013 ).

TPM is used to provide RA and trusted boot, while vTPM isused to provide isolated TCB for every CST. Inside MonitoringVM, there is one AS for every CST, and this AS is controlledby one Linux user, who can only access the monitoring infor-mation and vTPM instances belonging to this CST ( Zou et al.,2013 ).

Monitoring VM is launched by Dom0, but as Dom0 is vul-nerable to attacks and is controlled by the administrator, theintegrity measurement of Monitoring VM is performed byVMM. There are different CoTs. The first is CRTM, BIOS, GRUB,VMM, and Monitoring VM CoT; and the second is CRTM, BIOS,GRUB, VMM, and Dom0 CoT. Moreover, there is a specific CoTinside Monitoring VM for every CST ( Zou et al., 2013 ).

Their prototype is based on OpenNebula and Xen as well asIntel VT to support SCI. In Xen, VMM does not implement anyfile system. Therefore, Dom0 restores Monitoring VM before itis measured by VMM ( Zou et al., 2013 ).

8.5.2. Monitoring Tools Inside Dom0 (2013) Zou and Zhang (2013) designed an out-of-box fine-grainedmonitoring for applications on cloud using SCI and VM Intro-spection. They used sealed storage to improve CoT in orderto provide dual verifiable trusted boot. In addition, they ex-tended CoT to include memory by including Monitoring Tools,in Dom0, which monitors VM memory using memory virtual-ization technologies and Xenaccess.

8.6. IPsec and Predicate Encryption

8.6.1. IPsec: DTP (2015) Kashif et al. (2015) proposed a Distributed Trust Protocol (DTP)as a protocol between CSP and CST. DTP uses IPsec, basedon generated TPM keys, for communication between CSP andCST. Both MVM and VMs are under the control of CSP, but TPMof CST’s machine has direct access to VM and can remotelycheck VM integrity during boot.

Their prototype machine at CST uses Ubuntu with SW-based TPM emulator, TCG Device Driver Library,IAIK jTSS,and Public Key Cryptography Standard(PKCS) #11. In emulatedTPM, simulation of TPM driver is performed by a Linux kernelmodule called tpmd_dev; hence, the device /dev/tpm and dae-mon service tpmd exist ( Kashif et al., 2015 ).

DTP steps: (1) CST sends the public part of its AIK and anonce to CSP. The entire message is encrypted with a CSP pub-lic key. (2) CSP creates a session key and encrypts it with thepublic part of AIK. The entire message is signed with CSP’sprivate key before sending to CST. (3) Upon CST request, VM isbooted according to trusted boot process. (4) Every componentof VM is measured; then, this measurement is sent encryptedby the public part of AIK to CST. In case CST’s VM is rebooted,all VM components must be remeasured ( Kashif et al., 2015 ).

Some of the limitations of DTP are (1) using AIK in encryp-tion and (2) sending protocol messages without signing thenencrypting in each step. Furthermore, they used an emulated


Fig. 28 – Self-Service Cloud ( Butt et al., 2014 ).

ve

8YVocbntpoCr

8

BeZ

em(

h(

o

(Ue

Cpv

ntmc

ihme

Ctgacw2

adVfi

kTdtc(

p

ersion of TPM at CST, but TPM is available now in every mod- rn laptop or personal computer.

.6.2. Predicate Encryption (2016) u et al. (2017) proposed a trusted measurement model for Ms using (1) predicate encryption based on TPM and (2) penCA as RoT for CNs. They modified the boot loader and

alled it Trusted Boot Loader (TRB). Thus, CoT for their trusted

oot includes BIOS, TRB, Host OS Kernel (HOK), Guest OS Ker- el (GOK), and any other loaded applications. They designed a

rusted module to form a measure algorithm for VMs. For im- lementation, they used KVM and its integrated vTPM. More- ver, they developed authentication mechanisms for VM and

ST. They connected TPM to an FPGA via a bridge for obtaining esults.

.7. Self-Service Cloud (2014)

utt et al. (2014) proposed a Self-Service Cloud (SSC), where ach CN, shown in Fig. 28 , consists of (1) System Domain

ero (SDom0), which manages HW resources, schedules VMs,xecutes device drivers, and manages I/O, but cannot map

emory or registers of other VMs; (2) System Domain Builder SDomB), which creates VMs in response to CST requests,

Table 9 – Comparison betweenadditional features that support

Access Control Eucalyptus Hybrid Trust OM

Main Idea using access control with TC

into cloud

integrating TC

into Eucalyptus Combining TC

with reputation Dm

Implementation Schiffman et al. Schiffman et al. (2010) : preliminary

1) Trusted Eucalyptus: prototype 2) Excalibur: available

(1) RepCloud &

NeuronVisor: prototype (2) Gu et al. (2014) : available

p

vTPM Type not mentioned 1) Trusted Eucalyptus &

Excalibur: not mentioned 2) Sule et al. ( Sule et al., 2016 ): SW

(1) NeuronVisor: used (2) Akram

and Ko (2014) &

Gu et al. (2014) : SW

(2am

Severe Attacks protected possible possible p

osts vTPMs, and is a part of TCB; (3) User Domain Service UDomS), which can hold specific privileges over CST VMs,r can serve as I/O BE for CST VMs; (4) User Domain User

UDomU), which presents DomU in conventional Xen; and (5) ser Domain Zero (UDom0), which manages UDomUs and del- gates privileges over UDomUs to UDomSs.

They also propose a layer that facilitates interaction among Ns and between CST and CSP. This layer is called control lane, which consists of (1) CCtrl, which plays the role of con- entional CCtrl, but does not directly interact with CST VMs,or CST; (2) NCtrl of SDom0, which monitors resource utiliza-

ion and controls VM scheduling, but cannot create, read, or odify VMs; and (3) dashboard, which is a part of TCB and

onsists of (a) FE, which is an interface in which CST can spec-fy inter-VM dependencies and upload VMIs, and (b) BE, which

andles all cloud components on behalf of CST, obtains place- ent decisions from CCtrl, and forwards VMIs to CNs ( Butt

t al., 2014 ). CST cannot interact directly with UDom0; instead, each

ST has a dedicated dashboard VM, which is the implemen- ation of dashboard. Dashboard VM is an interface to CST, re- ardless of the number of UDom0s on different CNs. To cre- te dashboard VM, (1) CST sends an encrypted message that ontains a nonce and a symmetric key to SDom0, which for- ards this message to SDomB via a new hypercall to VMM;

) SDomB communicates with TPM to decrypt the message,s SDomB has the corresponding vTPM; (3) SDomB places the ecrypted nonce and symmetric key in the new dashboard

M; (4) SDomB sends the quote reply to the CST to be veri- ed; (5) if it succeeds, CST will reply by the private part of TLSey encrypted by the symmetric key; and (6) a private part of LS key is used to establish a TLS channel between CST and

ashboard VM. After creating dashboard VM, the first CST VM

hat should be booted on CN is UDom0, which can then ac- ept VMIs from dashboard VM to create UDomUs and UDomSs Butt et al., 2014 ).

They proposed a language for CST to specify inter-VM de- endencies. This language allows CST to specify whether VMs

TCC.

ut-of-box onitoring

IPsec and Predicate Encryption

Self-Service Cloud

edicated VM to onitor VMs using TC

using encryption based on TPM keys

creating dedicated Dom0 for each CST

rototype 1) IPsec: prototype 2) Predicate: available

available

1) Zou et al. (2013) : SW

) Zou and Zhang Zou nd Zhang (2013) : not entioned

1) IPsec: SW 2) Predicate:KVM

SW

ossible 1) IPsec: vulnerable 2) Predicate: protected

very protected if HW-based vTPM

is used


must be co-located on the same CN, or can be located ondifferent CNs. The inter-VM dependencies can be either (1)Grant_Privilege, which makes UDomS to have specific privi-leges over UDomU, such as mapping the memory, and regis-ters to implement something similar to VM Introspection; (2)Set_Backend, which makes UDomS serve as the I/O BE for an-other VM for a specific device type, such as a network adapterto implement something similar to IDS ( Butt et al., 2014 ).

8.8. Others

8.8.1. Business Intelligence (BI) (2009) Chow et al. (2009) proposed the usage of sealing, RA, andprivacy-enhanced Business Intelligence (BI) to resolve the is-sue of storing CST data at CSP. Thus, CST uses encryptionschemes to protect its data form CSP, but without any con-trol over cloud infrastructure from CST ( Cheng et al., 2012; Maet al., 2013 ).

8.8.2. Security Duty Separation: MTCEM (2010) Li et al. (2010) proposed a Multi Tenancy Trusted Comput-ing Environment Model (MTCEM), which supports the securityduty separation between CSP and CST. Therefore, CSP securesTCN and its TVMM, while CST secures TVM. MTCEM recom-mends the use of TTP as an optional auditor so that CST canask TTP to ensure that CSP provides TCN. The specific metricsto evaluate whether CN is trusted should be agreed betweenCST, CSP, and TTP and documented into SLA.

Regarding the limitations of MTCEM, they assumed thatRoT can be defined from boot loader rather than from CRTM.

Table 10 – Number of S elected, A dditional, and T otal papers pe

Source ∗ 2003 2004 2005 2006 2007 2008 2009

∗IEEE S – – – – – – –A – – 1 1 – 1 –T – – 1 1 – 1 –

ACM S – – – – – – –A 1 – – 1 – 2 1 T 1 – – 1 – 2 1

Elsevier S – – – – – – –A – – – – – – –T – – – – – – –

Inspec S – – – – – – –A – – – – – – –T – – – – – – –

Wiely S – – – – – – –A – – – – – – –T – – – – – – –

Springer S – – – – – – –A – – – – – 3 –T – – – – – 3 –

Scopus S – – – – – – –A – – – – – – –T – – – – – – –

Others S – – – – – – –A – 1 – 1 1 – 1 T – 1 – 1 1 – 1

Total S – – – – – – –A 1 1 1 3 1 6 2 T 1 1 1 3 1 6 2

This was caused by the lack of TPMs in CNs, which was ac-ceptable when they published their paper in 2010.

8.8.3. Petri Net (2013) Liu et al. (2013b) integrated TCC with a security supervisingsystem based on Place/Transition Network(Petri Net) to pro-mote the development of CC in Anhui province of China. PetriNet is a mathematical modeling language to describe dis-tributed systems in a directed bipartite graph.

To build the security supervising system, (1) they moni-tored every CN in real time, (2) they used service compositionto reduce the number of supervising models before verifyingtheir original purpose using functional analysis, and (3) if theyfind untrusted CN, the system will repair, separate, or evendelete this CN ( Liu et al., 2013b ).

8.8.4. Federated Identity Management(2014) Ghazizadeh et al. (2014) proposed the use of TC, FederatedIdentity Management(FIM), and OpenID Web Single Sign-Onto construct a TCCP and to solve identity theft in cloud. Theysimulated their proposed model in.Net environment ( Changet al., 2015 ).

8.9. Additional features comparison

In Table 9 , we compare access control, Eucalyptus, hybridtrust, out-of-box monitoring, IPsec, and SSC. The comparisoncriteria are the main idea, implementation, vTPM type, andprotection against severe attacks.

r data source in each year.

2010 2011 2012 2013 2014 2015 2016 Total

3 6 7 2 1 3 2 24 1 3 2 3 – – – 12 4 9 9 5 1 3 2 36 – – – – 2 – – 2 1 2 – – – – – 8 1 2 – – 2 – – 10 – – – 2 1 1 – 4 – – – – – – – –– – – 2 1 1 – 4 – – – 1 1 – – 2 – – – – – – – –– – – 1 1 – – 2 – – – – – 1 – 1 – – – – – – – –– – – – – 1 – 1 – – – 1 – 1 2 4 – – – 1 – 2 – 6 – – – 2 – 3 2 10 – – 1 3 4 3 – 11 – – – – – – – –– – 1 3 4 3 – 11 – – – – – – – –1 1 1 3 2 – – 12 1 1 1 3 2 – – 12 3 6 8 9 9 9 4 48 3 6 3 7 2 2 – 38 6 12 11 16 11 11 4 86


Fig. 29 – Number of selected, additional, and total papers in each year.

Fig. 30 – Percentage of data sources in selected, additional, and total papers.

9

9

Pr

Tdsi

ds

9

Ooo

pp

cmCtaT

Ctpatdt

o

. Survey results, discussion, and conclusion

.1. Survey results

hase 3 of the systematic literature review is synthesizing the esults of the search, which is illustrated in detail in Table 10 .he searched data sources, number of selected papers per ata source in each year, number of additional papers per data ource in each year, and number of their total per data source n each year are listed in Table 10 .

Figs. 29 and 30 demonstrate the numbers of selected, ad- itional, and total papers as classified by year and by data ource, respectively.

.2. Discussion and conclusion

ur manuscript will aid future researches to identify the tax- nomy of the main topics in TCC. We provide a comparison

f the suggested different types under each topic. This com-

arison will help future researchers to investigate more in the romising systems.

Furthermore, any researcher who wants to secure CC will onsider TC as an essential way to provide trust and to attract ore CSTs to join the cloud. Nowadays, CSPs such as Google

loud Platform (GCP) are providing vTPM, secure boot, and in- egrity monitoring to their CSTs. This means both academia nd professionals are going to research more and more into

CC. Motivating more CSTs to use the cloud is very important for

SPs and the whole cloud system. TCC, which is discussed in

his study can motivate CSTs to use cloud services. In this pa- er, we discussed the integration between CC and TC in IaaS rchitectures. Furthermore, we surveyed the integration be- ween TC and CC through systematic literature review. In ad- ition, we demonstrated the virtualization of TPM and DRTM

o make them suitable to the cloud environment. Container virtualization will have a great future between

ther virtualization technologies owing to its light weight.


In addition, non-binary-based RAs will lead attestation tech-nologies. Currently, support for TPM 2.0 is added to Xen 4.6,whereas vTPM Manager and vTPM instances are each imple-mented as stub domains on Xen. Furthermore, vTPM supportis currently added to OpenStack.

9.3. Future challenges

There are several future challenges that are facing TCC, suchas HW attacks, federated cloud, and vTPM performance. Usu-ally, all papers assume in their attack analysis that TPM chipis not accessible to any attacker, and no one can reach its HW.Therefore, there is a need to find a way to confront these typesof attacks.

As HW-based vTPMs are the most secure vTPMs, we need toincrease their performance to be able to handle the increaseddemand of using vTPMs. In addition, the era of federated cloudcomes, CSP must be ready to migrate VMs with their vTPMs toanother CSP. Moreover, TVD needs to be spread between CSPsand not only one CSP.

As vTPM and DRTM now have support from Intel and AMD,vDRTM should also have support from microprocessors ven-dors. For property-based RA, we need to map the binary iden-tities of SW to properties to provide the property translationdatabase that is necessary for property-based RA. Further-more, we need to encourage more CSTs to choose TCC servicefrom CSP.

R E F E R E N C E S

Abbadi IM. Clouds trust anchors. In: Proceedings of the IEEE 11th

international conference on trust, security, and privacy in

computing and communications; 2012. p. 127–36. doi: 10.1109/TrustCom.2012.107 .

Akram RN, Ko RKL. Digital trust - trusted computing and beyond: a position paper. In: Proceedings of the IEEE 13th internationalconference on trust, security, and privacy in computing and

communications; 2014. p. 884–92. doi: 10.1109/TrustCom.2014.116 .

Anderson M.J., Moffie M., Dalton C.I.. Towards trustworthy virtualisation environments: Xen Library OS security service infrastructure. HP Technical Report2007, HP:88–111.

Arshad J , Azad MA , Jokhio IA , Townend P . Intrusion damage assessment for multi-stage attacks for clouds. IET Commun

2013a;7:1304–15 .Arshad J, Townend P, Xu J. A novel intrusion severity analysis

approach for clouds. Future Gen Comput Syst 2013b;29(1):416–28. doi: 10.1016/j.future.2011.08.009 .

Arshad J, Townend P, Xu J, Jie W. Cloud computing security: opportunities and pitfalls. Int J Grid High Perform Comput 2012;4(1):52–66. doi: 10.4018/jghpc.2012010104 .

Azad MA, Bag S, Hao F, Salah K. M2M-REP: reputation system for machines in the internet of things. Comput Secur 2018;79:1–16. doi: 10.1016/j.cose.2018.07.014 .

Balogh Z , Gatial E , Hluch ̀y L , Toegl R , Pirker M , Hein DM . Agent-based cloud resource management for secure cloud

infrastructures. Comput Inform 2014;33(6):1333–55 .Banirostam H, Hedayati A, Zadeh AK, Shamsinezhad E. A trust

based approach for increasing security in cloud computing infrastructure. In: Proceedings of the UKSim 15th

international conference on computer modelling and

simulation; 2013. p. 717–21. doi: 10.1109/UKSim.2013.39 .

Berger S , Cáceres R , A Goldma K , Perez R , Sailer R , V Doorn L . vTPM: virtualizing the trusted platform module. In: Proceedings of the 15th conference on USENIX security symposium; 2006. p. 305–20 .

Berger S, Cáceres R, Pendarakis D, Sailer R, Valdez E, Perez R, Schildhauer W, Srinivasan D. TVDc: managing security in the trusted virtual datacenter. SIGOPS Oper Syst Rev 2008;42(1):40–7. doi: 10.1145/1341312.1341321 .

Bertholon B, Varrette S, Bouvry P. Certicloud: a novel TPM-based

approach to ensure Cloud IaaS security. In: Proceedings of the IEEE fourth international conference on cloud computing; 2011. p. 121–30. doi: 10.1109/CLOUD.2011.71 .

Brickell E, Camenisch J, Chen L. Direct anonymous attestation. In: Proceedings of the ACM 11th conference on computer and

communications security (CCS); 2004. p. 132–45. doi: 10.1145/1030083.1030103 .

Butt S, Ganapathy V, Srivastava A. On the control plane of a self-service cloud platform. In: Proceedings of the ACM

symposium on cloud computing (SOCC); 2014. p. 10:1–10:13. doi: 10.1145/2670979.2670989 .

Celesti A, Salici A, Villari M, Puliafito A. A remote attestation

approach for a secure virtual machine migration in federated

cloud environments. In: Proceedings of the first international symposium on network cloud computing and applications (NCCA); 2011. p. 99–106. doi: 10.1109/NCCA.2011.23 .

Chang Y, Zhang Z, Wang J. A security protocol for trusted access to cloud environment. Recent Adv Electr Electron Eng 2015;8(2):135–44. doi: 10.2174/2352096508666150804214204 .

Cheng G, Jin H, Zou D, Ohoussou AK, Zhao F. A prioritized Chinese wall model for managing the covert information

flows in virtual machine systems. In: Proceedings of the ninth

international conference for young computer scientists; 2008. p. 1481–7. doi: 10.1109/ICYCS.2008.534 .

Cheng Y, Li XY, Ling MQ. A trusted cloud service platform

architecture. In: Proceedings of the international conference on information science and applications; 2012. p. 1–6. doi: 10.1109/ICISA.2012.6220973 .

Chi Y, Liu H, An G. An access control architecture based on

IF-map for cloud environments. Proceedings of the institution

of engineering and technology conference; 2014. p. 677–81 .doi: 10.1049/ic.2014.0178 .

Chow R, Golle P, Jakobsson M, Shi E, Staddon J, Masuoka R, Molina J. Controlling data in the cloud: outsourcing computation without outsourcing control. In: Proceedings of the ACM workshop on cloud computing security (CCSW); 2009. p. 85–90. doi: 10.1145/1655008.1655020 .

Dai W, Jin H, Zou D, Xu S, Zheng W, Shi L, Yang LT. TEE: a virtual DRTM Based Execution Environment for Secure Cloud-End

Computing. Future Generation Computer Systems 2015;49:47–57. doi: 10.1016/j.future.2014.08.005 .

Danev B, Masti RJ, Karame GO, Capkun S. Enabling secure VM-vTPM migration in private clouds. In: Proceedings of the 27th annual computer security applications conference (ACSAC); 2011. p. 187–96. doi: 10.1145/2076732.2076759 .

England P, Loeser J. Para-virtualized TPM sharing. In: Proceedings of the first international conference on trusted computing and trust in information technologies; 2008. p. 119–32. doi: 10.1007/978-3-540-68979-9_9 .

Fan P, Zhao B, Shi Y, Chen Z, Ni M. An improved vTPM-VM Live migration protocol. Wuhan Univ J Nat Sci 2015;6(20):512–20. doi: 10.1007/s11859-015-1127-4 .

Garfinkel T, Pfaff B, Chow J, Rosenblum M, Boneh D. Terra: a virtual machine-based platform for trusted computing. SIGOPS Oper Syst Rev 2003;37(5):193–206. doi: 10.1145/1165389.945464 .

Ghazizadeh E, Zamani M, Ab Manan Jl, Alizadeh M. Trusted

computing strengthens cloud authentication. Sci World J 2014;2014. doi: 10.1155/2014/260187 .

https://doi.org/10.1109/TrustCom.2012.107


http://refhub.elsevier.com/S0167-4048(18)30271-2/sbref0003





https://doi.org/10.1016/j.future.2011.08.009

https://doi.org/10.4018/jghpc.2012010104









https://doi.org/10.1109/UKSim.2013.39








https://doi.org/10.1145/1341312.1341321

https://doi.org/10.1109/CLOUD.2011.71

https://doi.org/10.1145/1030083.1030103

https://doi.org/10.1145/2670979.2670989

https://doi.org/10.1109/NCCA.2011.23

https://doi.org/10.2174/2352096508666150804214204

https://doi.org/10.1109/ICYCS.2008.534

https://doi.org/10.1109/ICISA.2012.6220973

https://doi.org/10.1049/ic.2014.0178

https://doi.org/10.1145/1655008.1655020


https://doi.org/10.1145/2076732.2076759

https://doi.org/10.1007/978-3-540-68979-9_9

https://doi.org/10.1007/s11859-015-1127-4

https://doi.org/10.1145/1165389.945464

https://doi.org/10.1155/2014/260187


G

H

H

H

H

H

J

J

J

K

K

K

K

L

L

L

L

L

L

L

M

M

M

M

M

M

N

P

Q

R

R

R

R

R

R

u L, Wang C, Zhang Y, Zhong J, Ni Z. Trust model in cloud

computing environment based on fuzzy theory. Int J Comput Commun Control 2014;9(5):570–83. doi: 10.15837/ijccc.2014.5.1276 .

an-zhang W, Liu-sheng H. An improved trusted cloud

computing platform model based on DAA and privacy CA

scheme, 13; 2010. p. 33–9. doi: 10.1109/ICCASM.2010.5622643 .ao J, Cai W. Trusted block as a service: towards sensitive

applications on the cloud. In: Proceedings of the IEEE 10th

international conference on trust, security, and privacy in

computing and communications; 2011. p. 73–82. doi: 10.1109/TrustCom.2011.13 .

ong Z, Juan W, HuanGuo Z. A trusted VM-vTPM Live migration

protocol in clouds. Proceedings of the first international workshop on cloud computing and information security, 2013 .doi: 10.2991/ccis-13.2013.70 .

osseinzadeh S, Laurén S, Leppänen V. Security in

container-based virtualization through vTPM. In: Proceedings of the IEEE/ACM ninth international conference on utility and

cloud computing (UCC); 2016. p. 214–19. doi: 10.1145/2996890.3009903 .

uang T , Zhang Z , Chen Q , Chang Y . A method for trusted usage control over digital contents based on cloud computing. Int J Digit Content Technol Appl 2013;7(4):795–802 .

aeger T, Sailer R, Shankar U. PRIMA: policy-reduced integrity measurement architecture. In: Proceedings of the ACM 11th

symposium on access control models and technologies (SACMAT); 2006. p. 19–28. doi: 10.1145/1133058.1133063 .

ian-hong Y . Trusted dynamic attestation mechanism based on

property certificate. J Chin Comput Syst 2013;34:2349–53 .in H, Dai W, Zou D. Theory and methodology of research on

cloud security. Sci China (Inf Sci) 2016. doi: 10.1007/s11432-016-5549-1 .

amhoua CA , Ruan A , Martin A , Kwiat KA . On the feasibility of anopen-implementation cloud infrastructure: a game theoretic analysis. In: Proceedings of the IEEE/ACM eighth international conference on utility and cloud computing (UCC); 2015. p. 217–26 .

ashif UA, Memon ZA, Balouch AR, Chandio JA. Distributed trust protocol for IaaS cloud computing. In: Proceedings of the 12th

international Bhurban conference on applied sciences and

technology (IBCAST); 2015. p. 275–9. doi: 10.1109/IBCAST.2015.7058516 .

han I, Rehman HU, Anwar Z. Design and deployment of a trusted Eucalyptus Cloud. In: Proceedings of the IEEE international conference on cloud computing (CLOUD); 2011. p. 380–7. doi: 10.1109/CLOUD.2011.105 .

rautheim FJ . Building trust into utility cloud computing, [Ph.D. thesis], Catonsville, MD, USA. University of Maryland - Baltimore County; 2010 .

i C, Raghunathan A, Jha NK. A trusted virtual machine in an

untrusted management environment. IEEE Trans Serv Comput 2012;5(4):472–83. doi: 10.1109/TSC.2011.30 .

i XY, Zhou LT, Shi Y, Guo Y. A trusted computing environment model in cloud architecture, 6; 2010. p. 2843–8. doi: 10.1109/ICMLC.2010.5580769 .

iang X, Jiang R, Kong H. Secure and reliable VM-vTPM migration

in private cloud. In: Proceedings of the second international symposium on instrumentation and measurement, sensor network, and automation (IMSNA); 2013. p. 510–14. doi: 10.1109/IMSNA.2013.6743327 .

iu C, Lin J, Fang B. T-YUN: trustworthiness verification and audit on the cloud providers. IEICE Trans Inf Syst 2013a;E96.D(11):2344–53. doi: 10.1587/transinf.E96.D.2344 .

iu H, Wang S. The analysis and design of trusted computing applied into cloud. In: Proceedings of the IEEE control and

system graduate research colloquium (ICSGRC); 2012. p. 5–9. doi: 10.1109/ICSGRC.2012.6287124 .

iu L, Fang Xw, Liu Xw, Ji J. Study on security supervising and

managing methods of the trusted cloud computing based on

Petri Net. In: Proceedings of the eighth international conference on bio-inspired computing: theories and

applications (BIC-TA); 2013b. p. 579–85. doi: 10.1007/978-3-642-37502-6_70 .

uo D, Wu X, Zheng X, Hu Y. OOAP: a novel authorization

protocol for access to sensitive data in trusted cloud

computing platforms. Int J Secur Appl 2014;8(6):397–404. doi: 10.14257/ijsia.2014.8.6.34 .

a W , Li X , Shi Y , Guo Y . TVMCM: a trusted VM clone model in

cloud computing. In: Proceedings of the sixth international conference on new trends in information science, service science, and data mining (ISSDM); 2012. p. 607–11 .

a W, Liu Y, Lv CG. A novel service oriented approach of trustworthiness attestation in cloud computing, 04; 2013. p. 1567–71. doi: 10.1109/ICMLC.2013.6890852 .

cCune JM, Jaeger T, Berger S, Caceres R, Sailer R. Shamon: a system for distributed mandatory access control. In: Proceedings of the 22nd annual computer security applications conference (ACSAC); 2006. p. 23–32. doi: 10.1109/ACSAC.2006.47 .

cCune JM, Li Y, Qu N, Zhou Z, Datta A, Gligor V, Perrig A. TrustVisor: efficient TCB reduction and attestation. In: Proceedings of the IEEE symposium on security and privacy; 2010. p. 143–58. doi: 10.1109/SP.2010.17 .

cCune JM, Parno BJ, Perrig A, Reiter MK, Isozaki H. Flicker: an

execution infrastructure for TCB minimization. In: Proceedings of the third ACM SIGOPS/EuroSys European

conference on computer systems; 2008. p. 315–28. doi: 10.1145/1352592.1352625 .

yers AC, Liskov B. Protecting privacy using the decentralized

label model. ACM Trans Softw Eng Methodol (TOSEM) 2000;9(4):410–42. doi: 10.1145/363516.363526 .

eisse R, Holling D, Pretschner A. Implementing trust in cloud

infrastructures. In: Proceedings of the IEEE/ACM 11th

international symposium on cluster, cloud and grid

computing (CCGrid); 2011. p. 524–33. doi: 10.1109/CCGrid.2011.35 .

aladi N., Gehrmann C., Aslam M., Morenius F.. Trusted launch of virtual machine instances in public IaaS environments; SpringerBerlin Heidelberg. p. 309–323. doi: 10.1007/978- 3- 642- 37682- 5 _ 22 .

iang W, Zou D, Wang S, Yang LT, Jin H, Shi L. CloudAC: a cloud-oriented multilayer access control system for logic virtual domain. IET Inf Secur 2013;7:51–9. doi: 10.1049/iet-ifs.2012.0094 .

aj H , Robinson D , Tariq TB , England P , Saroiu S , Wolman A . Credo: trusted computing for Guest VMs with a Commodity Hypervisor. Microsoft Research; 2011 .

ocha F, Abreu S, Correia M. The final frontier: confidentiality and

privacy in the cloud. Computer 2011;44(9):44–50. doi: 10.1109/MC.2011.223 .

ongyu H, Shaojie W, Lu J. A user-specific trusted virtual environment for cloud computing. Inf Technol J 2013;12(10):1905–13. doi: 10.3923/itj.2013.1905.1913 .

uan A, Martin A. RepCloud: achieving fine-grained cloud TCB

attestation with reputation systems. In: Proceedings of the sixth ACM workshop on scalable trusted computing (STC); 2011. p. 3–14. doi: 10.1145/2046582.2046586 .

uan A, Martin A. NeuronVisor: Defining a Fine-Grained Cloud

Root-of-Trust. In: Proceedings of the sixth international conference on trusted systems (INTRUST); 2015. p. 184–200. doi: 10.1007/978-3-319-27998-5_12 .

yan MD. Cloud computing security: the scientific challenge, and

a survey of solutions. J Syst Softw 2013;86(9):2263–8. doi: 10.1016/j.jss.2012.12.025 .

https://doi.org/10.15837/ijccc.2014.5.1276

https://doi.org/10.1109/ICCASM.2010.5622643


https://doi.org/10.2991/ccis-13.2013.70

https://doi.org/10.1145/2996890.3009903






https://doi.org/10.1145/1133058.1133063



https://doi.org/10.1007/s11432-016-5549-1






https://doi.org/10.1109/IBCAST.2015.7058516

https://doi.org/10.1109/CLOUD.2011.105



https://doi.org/10.1109/TSC.2011.30

https://doi.org/10.1109/ICMLC.2010.5580769

https://doi.org/10.1109/IMSNA.2013.6743327

https://doi.org/10.1587/transinf.E96.D.2344

https://doi.org/10.1109/ICSGRC.2012.6287124

https://doi.org/10.1007/978-3-642-37502-6_70

https://doi.org/10.14257/ijsia.2014.8.6.34






https://doi.org/10.1109/ICMLC.2013.6890852

https://doi.org/10.1109/ACSAC.2006.47

https://doi.org/10.1109/SP.2010.17

https://doi.org/10.1145/1352592.1352625

https://doi.org/10.1145/363516.363526

https://doi.org/10.1109/CCGrid.2011.35

https://doi.org/10.1007/978-3-642-37682-5_22

https://doi.org/10.1049/iet-ifs.2012.0094








https://doi.org/10.1109/MC.2011.223

https://doi.org/10.3923/itj.2013.1905.1913

https://doi.org/10.1145/2046582.2046586

https://doi.org/10.1007/978-3-319-27998-5_12

https://doi.org/10.1016/j.jss.2012.12.025


Sadeghi AR, Stüble C. Property-based attestation for computing platforms: caring about properties, not mechanisms. In: Proceedings of the workshop on new security paradigms (NSPW); 2004. p. 67–77. doi: 10.1145/1065907.1066038 .

Sadeghi AR, Stüble C, Winandy M. Property-based TPM

virtualization. In: Proceedings of the 11th international conference on information security; 2008. p. 1–16. doi: 10.1007/978-3-540-85886-7_1 .

Sailer R, Jaeger T, Valdez E, Caceres R, Perez R, Berger S, Griffin JL, van Doorn L. Building a MAC-based security architecture for the Xen open-source hypervisor. In: Proceedings of the 21st annual computer security applications conference (ACSAC); 2005. p. 276–85. doi: 10.1109/CSAC.2005.13 .

Sailer R , Zhang X , Jaeger T , Van Doorn L . Design and

implementation of a TCG-based integrity measurement architecture, 13; 2004. p. 223–38 .

Santos N , Gummadi KP , Rodrigues R . Towards trusted cloud

computing. Proceedings of the workshop on hot topics in

cloud computing (HotCloud), 2009 .Santos N , Rodrigues R , Gummadi KP , Saroiu S . Policy-sealed data:

a new abstraction for building trusted cloud services. In: Proceedings of the 21st USENIX security symposium; 2012. p. 175–88 .

Scarlata V., Rozas C., Wiseman M., Grawrock D., Vishik C.. TPM

virtualization: building a general framework; Springer, Vieweg Verlag. p. 43–56. doi: 10.1007/978- 3- 8348- 9452- 6 _ 4

Schiffman J, Moyer T, Vijayakumar H, Jaeger T, McDaniel P. Seeding clouds with trust anchors. In: Proceedings of the ACMworkshop on cloud computing security workshop (CCSW); 2010. p. 43–6. doi: 10.1145/1866835.1866843 .

Sen P, Saha P, Khatua S. A distributed approach towards trusted

cloud computing platform. In: Proceedings of the applications and innovations in mobile computing (AIMoC); 2015. p. 146–51. doi: 10.1109/AIMOC.2015.7083844 .

Shen Z, Li L, Yan F, Wu X. Cloud computing system based on

trusted computing platform, 1; 2010. p. 942–5. doi: 10.1109/ICICTA.2010.724 .

Shi Y, Zhao B, Yu Z, Zhang H. A security-improved scheme for virtual TPM based on KVM. Wuhan Univ J Nat Sci 2015;20(6):505–11. doi: 10.1007/s11859-015-1126-5 .

Stumpf F, Eckert C. Enhancing trusted platform modules with

hardware-based virtualization techniques. In: Proceedings of the second international conference on emerging security information, systems, and technologies; 2008. p. 1–9. doi: 10.1109/SECURWARE.2008.23 .

Sule MJ, Li M, Taylor G. Trust modeling in cloud computing. In: Proceedings of the IEEE symposium on service-oriented system engineering (SOSE); 2016. p. 60–5. doi: 10.1109/SOSE.2016.32 .

Toegl R, Pirker M, Gissing M. acTvSM: a dynamic virtualization

platform for enforcement of application integrity. In: Proceedings of the second international conference on

trusted systems (INTRUST); 2011. p. 326–45. doi: 10.1007/978-3-642-25283-9_22 .

Tupakula U, Varadharajan V. TVDSEC: trusted virtual domain

security. In: Proceedings of the IEEE fourth international conference on utility and cloud computing (UCC); 2011. p. 57–64. doi: 10.1109/UCC.2011.18 .

Tupakula U, Varadharajan V. Trust enhanced security for tenant transactions in the cloud environment. Comput J 2015;58(10):2388–403. doi: 10.1093/comjnl/bxu048 .

Varadharajan V, Tupakula U. Counteracting security attacks in

virtual machines in the cloud using property based

attestation. J Netw Comput Appl 2014;40:31–45. doi: 10.1016/j.jnca.2013.08.002 .

Wallom D, Turilli M, Martin A, Raun A, Taylor G, Hargreaves N, McMoran A. myTrustedCloud: trusted cloud infrastructure for security-critical computation and data managment. In:

Proceedings of the IEEE third international conference on

cloud computing technology and science; 2011. p. 247–54. doi: 10.1109/CloudCom.2011.41 .

Wan X, Xiao Z, Ren Y. Building trust into cloud computing using virtualization of TPM. In: Proceedings of the fourth

international conference on multimedia information

networking and security; 2012a. p. 59–63. doi: 10.1109/MINES.2012.82 .

Wan X, Zhang X, Chen L, Jin H. TVPDc: a model for secure managing virtual infrastructure in IaaS cloud. In: Proceedings of the eighth international conference on computational intelligence and security (CIS); 2012b. p. 136–41. doi: 10.1109/CIS.2012.38 .

Wang J, Zhao B, Zhang H, Yan F, Yu F, Zhang L, Hu H. POSTER: an

E2E trusted cloud infrastructure. In: Proceedings of the ACM

SIGSAC conference on computer and communications security (CCS); 2014. p. 1517–19. doi: 10.1145/2660267.2662383 .

Wenqiang W, Shaozhen C. An efficient attribute-based ring signature scheme, 1; 2009. p. 147–50. doi: 10.1109/IFCSTA.2009.43 .

Wu X, Xie X, Li C. Research and implementation of a role-based

trustworthiness mechanism for IaaS, 01; 2012. p. 313–17. doi: 10.1109/CCIS.2012.6664419 .

Xiao-hui L, Xin-fang S. Analysis on cloud computing and its security. In: Proceedings of the eighth international conference on computer science education (ICCSE); 2013. p. 839–42. doi: 10.1109/ICCSE.2013.6554026 .

Xie F, Du YY. Research on cloud computing security based on the remote attestation, 321; 2013. p. 2657–64 . doi: 10.4028/www.scientific.net/AMM.321-324.2657 .

Xin S, Zhao Y, Li Y. Property-based remote attestation oriented to cloud computing. In: Proceedings of the seventh international conference on computational intelligence and security; 2011. p. 1028–32. doi: 10.1109/CIS.2011.229 .

Xing B, Han Z, Chang X, Liu J. OB-IMA: out-of-the-box integrity measurement approach for guest virtual machines. Concurrency and computation: practice and experience 2015;27(5):1092–109. doi: 10.1002/cpe.3273 .

Xu Z, Yu A, Yang W. Real-time remote attestation of IaaS cloud, 01; 2012. p. 292–7. doi: 10.1109/CCIS.2012.6664415 .

Yan L, Bin X. Design and implementation of remote anonymous attestation protocol based on trusted cloud computing platform. Open Cybern Syst J 2015;9:415–21. doi: 10.2174/1874110X01509010415 .

Yeluri R, Castro-Leon E, Harmon RR, Greene J. Building trust and

compliance in the cloud for services. In: Proceedings of the annual SRII global conference; 2012. p. 379–90. doi: 10.1109/SRII.2012.49 .

Yu Z, Zhang W, Dai H. A Trusted architecture for virtual machineson cloud servers with trusted platform module and certificate authority. J Signal Process Syst 2017;86(2):327–36. doi: 10.1007/s11265-016-1130-9 .

Zhang F, Chen H. Security-preserving live migration of virtual machines in the cloud. J Netw Syst Manag 2013;21(4):562–87. doi: 10.1007/s10922-012-9253-1 .

Zhenpeng L, Xu W, Yifan L, Ding G, Xianchao Z. Client oriented

remote attestation model in cloud environment. Int J Secur Appl 2015;9(10):395–404. doi: 10.14257/ijsia.2015.9.10.36 .

Zhou Zj, Wu L, Hong Z, Xu Mf, Pan F. DTSTM: dynamic tree style trust measurement model for cloud computing. Trans Internet Inf Syst 2014;8(1):305–25. doi: 10.3837/tiis.2014.01.018 .

Zou B, Zhang H. Integrity protection and attestation of security critical executions on virtualized platform in cloud computingenvironment. In: Proceedings of the IEEE international conference on green computing and communications and

IEEE Internet of Things and IEEE cyber, physical, and social computing; 2013. p. 2071–5. doi: 10.1109/GreenCom-iThings-CPSCom.2013.388 .

https://doi.org/10.1145/1065907.1066038

https://doi.org/10.1007/978-3-540-85886-7_1

https://doi.org/10.1109/CSAC.2005.13















https://doi.org/10.1007/978-3-8348-9452-6_4

https://doi.org/10.1145/1866835.1866843

https://doi.org/10.1109/AIMOC.2015.7083844

https://doi.org/10.1109/ICICTA.2010.724

https://doi.org/10.1007/s11859-015-1126-5

https://doi.org/10.1109/SECURWARE.2008.23

https://doi.org/10.1109/SOSE.2016.32

https://doi.org/10.1007/978-3-642-25283-9_22

https://doi.org/10.1109/UCC.2011.18

https://doi.org/10.1093/comjnl/bxu048

https://doi.org/10.1016/j.jnca.2013.08.002

https://doi.org/10.1109/CloudCom.2011.41

https://doi.org/10.1109/MINES.2012.82

https://doi.org/10.1109/CIS.2012.38

https://doi.org/10.1145/2660267.2662383

https://doi.org/10.1109/IFCSTA.2009.43

https://doi.org/10.1109/CCIS.2012.6664419

https://doi.org/10.1109/ICCSE.2013.6554026

https://doi.org/10.4028/www.scientific.net/AMM.321-324.2657

https://doi.org/10.1109/CIS.2011.229

https://doi.org/10.1002/cpe.3273

https://doi.org/10.1109/CCIS.2012.6664415

https://doi.org/10.2174/1874110X01509010415

https://doi.org/10.1109/SRII.2012.49

https://doi.org/10.1007/s11265-016-1130-9

https://doi.org/10.1007/s10922-012-9253-1

https://doi.org/10.14257/ijsia.2015.9.10.36

https://doi.org/10.3837/tiis.2014.01.018

https://doi.org/10.1109/GreenCom-iThings-CPSCom.2013.388


Z

Fnv

c

DscLive

f

ta

Hgwgifiattso

t

Aae

ou D, Zhang W, Qiang W, Xiang G, Yang LT, Jin H, Hu K. Design

and implementation of a trusted monitoring framework for cloud platforms. Future Gen Comput Syst 2013;29(8):2092–102. doi: 10.1016/j.future.2012.12.020 .

ady is a Ph.D. candidate who is interested in web and mobile tech- ologies. He got his M.Sc. in computer engineering from Cairo Uni- ersity, Egypt. His research interest includes computer networks,omputer security, cloud computing, and operating systems.

r. Hemayed is currently working as a Professor at Cairo Univer- ity and as a consultant for visual surveillance systems in spe- ific and IT systems in general. He got his Ph.D. from University of ouisville, KY in 1999. He got the Graduate Deans Citation Award

n recognition of excellent achievement as a candidate for an ad- anced degree and the John M. Houchens Prize in recognition of xcellent doctoral dissertation. He got his master and his B.Sc.rom Cairo University in 1992 and 1989 respectively. From 2007

o 2014, Dr Hemayed was working as an Assistant Professor then

n Associate Professor at Cairo University. From 2004 to 2007, Dr.emayed was working as an Assistant Professor of software en- ineering in the UAE University. From 1999 to 2005, Dr Hemayed

as working in Trendium Inc, Florida in the area of software en- ineering and network performance. He occupied different levels n Trendium starting as a senior member of technical staff and

nally as a VP of Technical Services and Solution Development nd Member of the Corporate Executive Team. He was awarded

he year 2005 Trendium Pioneer in recognition of the contribution

o the architecture of Trendium Products. He worked also as a Re- earch Scientist Assistant in Cairo University, Egypt and University f Louisville, USA from 1989 to 1994 and from 1994 to 1999, respec-ively. Dr. Hemayed is a senior member of IEEE and a member ofCM and has been a regular reviewer of international conferences nd journals. He has published over 70 papers. His research inter- st includes computer vision, machine learning and data analytic.


available online · a, ∗, elsayed e. hemayed a, b adepartment of computer engineering, faculty...

Documents