IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED …qsheng/papers/tpds-noor-2015.pdfCloudArmor: Supporting Reputation-based Trust Management for Cloud Services Talal H. Noor, Quan Z

IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 0, NO. 0, 2015 1

CloudArmor: Supporting Reputation-basedTrust Management for Cloud Services

Talal H. Noor, Quan Z. Sheng, Member, IEEE, Lina Yao, Member, IEEE, Schahram Dustdar, SeniorMember, IEEE, and Anne H.H. Ngu

Abstract—Trust management is one of the most challenging issues for the adoption and growth of cloud computing. The highlydynamic, distributed, and non-transparent nature of cloud services introduces several challenging issues such as privacy, security,and availability. Preserving consumers’ privacy is not an easy task due to the sensitive information involved in the interactionsbetween consumers and the trust management service. Protecting cloud services against their malicious users (e.g., such usersmight give misleading feedback to disadvantage a particular cloud service) is a difficult problem. Guaranteeing the availability ofthe trust management service is another significant challenge because of the dynamic nature of cloud environments. In this article,we describe the design and implementation of CloudArmor, a reputation-based trust management framework that provides a set offunctionalities to deliver Trust as a Service (TaaS), which includes i) a novel protocol to prove the credibility of trust feedbacks andpreserve users’ privacy, ii) an adaptive and robust credibility model for measuring the credibility of trust feedbacks to protect cloudservices from malicious users and to compare the trustworthiness of cloud services, and iii) an availability model to manage theavailability of the decentralized implementation of the trust management service. The feasibility and benefits of our approach havebeen validated by a prototype and experimental studies using a collection of real-world trust feedbacks on cloud services.

Index Terms—Cloud computing, trust management, reputation, credibility, credentials, security, privacy, availability.

F

1 INTRODUCTION

THE highly dynamic, distributed, and non-transparent nature of cloud services make the

trust management in cloud environments a significantchallenge [1], [2], [3], [4]. According to researchers atBerkeley [5], trust and security are ranked one of thetop 10 obstacles for the adoption of cloud computing.Indeed, Service-Level Agreements (SLAs) alone areinadequate to establish trust between cloud consumersand providers because of its unclear and inconsistentclauses [6].

Consumers’ feedback is a good source to assessthe overall trustworthiness of cloud services. Severalresearchers have recognized the significance of trustmanagement and proposed solutions to assess andmanage trust based on feedbacks collected from par-ticipants [7], [6], [8], [9]. In reality, it is not unusualthat a cloud service experiences malicious behaviors(e.g., collusion or Sybil attacks) from its users [6], [10].This paper focuses on improving trust managementin cloud environments by proposing novel ways toensure the credibility of trust feedbacks. In particular,

• Talal H. Noor, is with the College of Computer Science and Engineering,Taibah University, Yanbu, Medinah 46421-7143, Saudi Arabia.E-mail: [email protected]

• Quan Z. Sheng and Lina Yao are with the School of Computer Science,The University of Adelaide, Adelaide SA 5005, Australia.

• Schahram Dustdar is with the Distributed Systems Group, Vienna Uni-versity of Technology, Austria. Anne H.H. Ngu is with the Departmentof Computer Science, Texas State University, USA.

we distinguish the following key issues of the trustmanagement in cloud environments:

• Consumers’ Privacy. The adoption of cloud com-puting raise privacy concerns [11]. Consumers canhave dynamic interactions with cloud providers,which may involve sensitive information. There areseveral cases of privacy breaches such as leaks ofsensitive information (e.g., date of birth and ad-dress) or behavioral information (e.g., with whomthe consumer interacted, the kind of cloud servicesthe consumer showed interest, etc.). Undoubtedly,services which involve consumers’ data (e.g., inter-action histories) should preserve their privacy [12].

• Cloud Services Protection. It is not unusual that acloud service experiences attacks from its users.Attackers can disadvantage a cloud service by giv-ing multiple misleading feedbacks (i.e., collusionattacks) or by creating several accounts (i.e., Sybilattacks). Indeed, the detection of such malicious be-haviors poses several challenges. Firstly, new usersjoin the cloud environment and old users leavearound the clock. This consumer dynamism makesthe detection of malicious behaviors (e.g., feedbackcollusion) a significant challenge. Secondly, usersmay have multiple accounts for a particular cloudservice, which makes it difficult to detect Sybilattacks [13]. Finally, it is difficult to predict whenmalicious behaviors occur (i.e., strategic VS. occa-sional behaviors) [14].

• Trust Management Service’s Availability. A trust man-agement service (TMS) provides an interface be-


tween users and cloud services for effective trustmanagement. However, guaranteeing the availabil-ity of TMS is a difficult problem due to the un-predictable number of users and the highly dy-namic nature of the cloud environment [7], [6],[10]. Approaches that require understanding ofusers’ interests and capabilities through similaritymeasurements [15] or operational availability mea-surements [16] (i.e., uptime to the total time) areinappropriate in cloud environments. TMS shouldbe adaptive and highly scalable to be functional incloud environments.

In this paper, we overview the design and the imple-mentation of CloudArmor (CLOud consUmers creDi-bility Assessment & tRust manageMent of clOud seR-vices): a framework for reputation-based trust manage-ment in cloud environments. In CloudArmor, trust isdelivered as a service (TaaS) where TMS spans severaldistributed nodes to manage feedbacks in a decentral-ized way. CloudArmor exploits techniques to identifycredible feedbacks from malicious ones. In a nutshell,the salient features of CloudArmor are:

• Zero-Knowledge Credibility Proof Protocol (ZKC2P).We introduce ZKC2P that not only preserves theconsumers’ privacy, but also enables the TMS toprove the credibility of a particular consumer’sfeedback. We propose that the Identity Manage-ment Service (IdM) can help TMS in measuringthe credibility of trust feedbacks without breachingconsumers’ privacy. Anonymization techniques areexploited to protect users from privacy breaches inusers’ identity or interactions.

• A Credibility Model. The credibility of feedbacksplays an important role in the trust managementservice’s performance. Therefore, we propose sev-eral metrics for the feedback collusion detectionincluding the Feedback Density and Occasional Feed-back Collusion. These metrics distinguish mislead-ing feedbacks from malicious users. It also hasthe ability to detect strategic and occasional be-haviors of collusion attacks (i.e., attackers whointend to manipulate the trust results by givingmultiple trust feedbacks to a certain cloud servicein a long or short period of time). In addition,we propose several metrics for the Sybil attacksdetection including the Multi-Identity Recognitionand Occasional Sybil Attacks. These metrics allowTMS to identify misleading feedbacks from Sybilattacks.

• An Availability Model. High availability is an impor-tant requirement to the trust management service.Thus, we propose to spread several distributednodes to manage feedbacks given by users in adecentralized way. Load balancing techniques areexploited to share the workload, thereby alwaysmaintaining a desired availability level. The num-ber of TMS nodes is determined through an op-

erational power metric. Replication techniques areexploited to minimize the impact of inoperableTMS instances. The number of replicas for eachnode is determined through a replication determina-tion metric that we introduce. This metric exploitsparticle filtering techniques to precisely predict theavailability of each node.

The remainder of the paper is organized as follows.Section 2 briefly presents the design of CloudArmorframework. Section 3 introduces the design of the Zero-Knowledge Credibility Proof Protocol, assumptions andattack models. Section 4 and Section 5 describe thedetails of our credibility model and availability modelrespectively. Section 6 reports the implementation ofCloudArmor and the results of experimental evalua-tions. Finally, Section 7 overviews the related work andSection 8 provides some concluding remarks.

2 THE CLOUDARMOR FRAMEWORK

The CloudArmor framework is based on the serviceoriented architecture (SOA), which delivers trust as aservice. SOA and Web services are one of the mostimportant enabling technologies for cloud computing inthe sense that resources (e.g., infrastructures, platforms,and software) are exposed in clouds as services [17],[18]. In particular, the trust management service spansseveral distributed nodes that expose interfaces so thatusers can give their feedbacks or inquire the trust re-sults. Figure 1 depicts the framework, which consists ofthree different layers, namely the Cloud Service ProviderLayer, the Trust Management Service Layer, and the CloudService Consumer Layer.

The Cloud Service Provider Layer. This layer consistsof different cloud service providers who offer one orseveral cloud services, i.e., IaaS (Infrastructure as aService), PaaS (Platform as a Service), and SaaS (Soft-ware as a Service), publicly on the Web (more detailsabout cloud services models and designs can be foundin [19]). These cloud services are accessible throughWeb portals and indexed on Web search engines suchas Google, Yahoo, and Baidu. Interactions for this layerare considered as cloud service interaction with users andTMS, and cloud services advertisements where providersare able to advertise their services on the Web.

The Trust Management Service Layer. This layer consistsof several distributed TMS nodes which are hosted inmultiple cloud environments in different geographicalareas. These TMS nodes expose interfaces so that userscan give their feedback or inquire the trust results in adecentralized way. Interactions for this layer include: i)cloud service interaction with cloud service providers, ii)service advertisement to advertise the trust as a serviceto users through the Internet, iii) cloud service discoverythrough the Internet to allow users to assess the trustof new cloud services, and iv) Zero-Knowledge CredibilityProof Protocol (ZKC2P) interactions enabling TMS to


Fig. 1. Architecture of the CloudArmor Trust Management Framework

prove the credibility of a particular consumer’s feed-back (details in Section 3).

The Cloud Service Consumer Layer. Finally, this layerconsists of different users who use cloud services. Forexample, a new startup that has limited funding canconsume cloud services (e.g., hosting their services inAmazon S3). Interactions for this layer include: i) servicediscovery where users are able to discover new cloudservices and other services through the Internet, ii) trustand service interactions where users are able to givetheir feedback or retrieve the trust results of a particularcloud service, and iii) registration where users establishtheir identity through registering their credentials inIdM before using TMS.

Our framework also exploits a Web crawling ap-proach for automatic cloud services discovery, wherecloud services are automatically discovered on the In-ternet and stored in a cloud services repository. Moreover,our framework contains an Identity Management Service(see Figure 1) which is responsible for the registrationwhere users register their credentials before using TMSand proving the credibility of a particular consumer’sfeedback through ZKC2P.

3 ZERO-KNOWLEDGE CREDIBILITY PROOFPROTOCOL (ZKC2P)Since there is a strong relation between trust and iden-tification as emphasized in [20], we propose to usethe Identity Management Service (IdM) to help TMS inmeasuring the credibility of a consumer’s feedback.However, processing the IdM information can breachthe privacy of users. One way to preserve privacy isto use cryptographic encryption techniques. However,there is no efficient way to process encrypted data [11].Another way is to use anonymization techniques toprocess the IdM information without breaching the pri-vacy of users. Clearly, there is a trade-off between highanonymity and utility. Full anonymization means better

privacy, while full utility results in no privacy pro-tection (e.g., using a de-identification anonymizationtechnique can still leak sensitive information throughlinking attacks [21]).

Thus, we propose a Zero-Knowledge Credibility ProofProtocol (ZKC2P) to allow TMS to process IdM’s infor-mation (i.e., credentials) using the Multi-Identity Recog-nition factor (see details in Section 4.2). In other words,TMS will prove the users’ feedback credibility withoutknowing the users’ credentials. TMS processes cre-dentials without including the sensitive information.Instead, anonymized information is used via consistenthashing (e.g., sha-256). The anonymization process cov-ers all the credentials’ attributes except the Timestampsattribute.

3.1 Identity Management Service (IdM)

Since trust and identification are closely related, ashighlighted by David and Jaquet in [20], we believe thatIdM can facilitate TMS in the detection of Sybil attacksagainst cloud services without breaching the privacy ofusers. When users attempt to use TMS for the first time,TMS requires them to register their credentials at thetrust identity registry in IdM to establish their identities.The trust identity registry stores an identity record rep-resented by a tuple I = (C, Ca, Ti) for each user. C is theuser’s primary identity (e.g., user name). Ca representsa set of credentials’ attributes (e.g., passwords, postaladdress, and IP address) and Ti represents the user’sregistration time in TMS. More details on how IdMfacilitates TMS in the detection of Sybil attacks can befound in Section 4.2.

3.2 Trust Management Service (TMS)

In a typical interaction of the reputation-based TMS, auser either gives feedback regarding the trustworthi-ness of a particular cloud service or requests the trust


assessment of the service1. From users’ feedback, thetrust behavior of a cloud service is actually a collectionof invocation history records, represented by a tuple H= (C, S, F , Tf ), where C is the user’s primary identity, Sis the cloud service’s identity, and F is a set of Qualityof Service (QoS) feedbacks (i.e., the feedback representseveral QoS parameters including availability, security,response time, accessibility, price). Each trust feedbackin F is represented in numerical form with the rangeof [0, 1], where 0, 1, and 0.5 means negative, positive,and neutral feedback respectively. Tf is the timestampswhen the trust feedbacks are given. Whenever a userc requests a trust assessment for cloud service s, TMScalculates the trust result, denoted as Tr(s), from thecollected trust feedbacks as follows:

Tr(s) =∑|V(s)|

c=1 F(c, s) ∗ Cr(c, s, t0, t)|V(s)|

∗ (χ ∗ Ct(s, t0, t))(1)

where V(s) denotes the trust feedbacks given to cloudservice s and |V(s)| represents the total number oftrust feedbacks. F(c, s) are trust feedbacks from thecth user weighted by the credibility aggregated weightsCr(c, s, t0, t) to allow TMS to dilute the influence ofthose misleading feedbacks from attacks. F(c, s) is heldin the invocation history record h and updated inthe corresponding TMS. Ct(s, t0, t) is the rate of trustresult changes in a period of time that allows TMS toadjust trust results for cloud services that have beenaffected by malicious behaviors. χ is the normalizedweight factor for the rate of changes of trust resultswhich increase the adaptability of the model. Moredetails on how to calculate Cr(c, s, t0, t) and Ct(s, t0, t)are described in Section 4.

3.3 Assumptions and Attack Models

In this paper, we assume that TMS is handled by atrusted third party. We also assume that TMS commu-nications are secure because securing communicationsis not the focus of this paper. Attacks such as Man-in-the-Middle (MITM) is therefore beyond the scope of thiswork. We consider the following types of attacks:

• Collusion Attacks. Also known as collusive mali-cious feedback behaviors, such attacks occur whenseveral vicious users collaborate together to givenumerous misleading feedbacks to increase thetrust result of cloud services (i.e., a self-promotingattack [22]) or to decrease the trust result of cloudservices (i.e., a slandering attack [23]). This type ofmalicious behavior can occur in a non-collusive waywhere a particular malicious user gives multiplemisleading feedbacks to conduct a self-promotingattack or a slandering attack.

• Sybil Attacks. Such an attack arises when ma-licious users exploit multiple identities [13], [22]

1. We assume a transaction-based feedback where all feedbacks areheld in TMS

to give numerous misleading feedbacks (e.g., pro-ducing a large number of transactions by creatingmultiple virtual machines for a short period oftime to leave fake feedbacks) for a self-promotingor slandering attack. It is interesting to note thatattackers can also use multiple identities to dis-guise their negative historical trust records (i.e.,whitewashing attacks [24]).

4 THE CREDIBILITY MODEL

Our proposed credibility model is designed for i) theFeedback Collusion Detection including the feedback den-sity and occasional feedback collusion, and ii) the SybilAttacks Detection including the multi-identity recogni-tion and occasional Sybil attacks.

4.1 Feedback Collusion Detection4.1.1 Feedback DensityMalicious users may give numerous fake feedbacks tomanipulate trust results for cloud services (i.e., Self-promoting and Slandering attacks). Some researchers sug-gest that the number of trusted feedbacks can helpusers to overcome such manipulation where the num-ber of trusted feedbacks gives the evaluator a hintin determining the feedback credibility [25]. However,the number of feedbacks is not enough in determiningthe credibility of trust feedbacks. For instance, supposethere are two different cloud services sx and sy andthe aggregated trust feedbacks of both cloud servicesare high (i.e., sx has 89% positive feedbacks from 150feedbacks, sy has 92% positive feedbacks from 150 feed-backs). Intuitively, users should proceed with the cloudservice that has the higher aggregated trust feedbacks(e.g., sy in our case). However, a Self-promoting attackmight have been performed on cloud service sy , whichmeans sx should have been selected instead.

To overcome this problem, we introduce the con-cept of feedback density to support the determinationof credible trust feedbacks. Specifically, we considerthe total number of users who give trust feedbacksto a particular cloud service as the feedback mass, thetotal number of trust feedbacks given to the cloudservice as the feedback volume. The feedback volume isinfluenced by the feedback volume collusion factor whichis controlled by a specified volume collusion threshold.This factor regulates the multiple trust feedbacks extentthat could collude the overall trusted feedback volume.For instance, if the volume collusion threshold is setto 15 feedbacks, any user c who gives more than 15feedbacks is considered to be suspicious of involving ina feedback volume collusion. The feedback density ofa certain cloud service s, D(s), is calculated as follows:

D(s) =M(s)

|V(s)| ∗ L(s)(2)

where M(s) denotes the total number of users who givefeedback to cloud service s (i.e., the feedback mass).


Fig. 2. Occasional Attacks Detection

|V(s)| represents the total number of feedbacks givento cloud service s (i.e., the feedback volume). L(s)represents the feedback volume collusion factor, calculatedas follows:

L(s) = 1 +

∑h∈V(s)

|Vc(c,s)|∑c=1

∑|Vc(c,s)|>ev(s)

|Vc(c, s)||V(s)|

(3)

This factor is calculated as the ratio of the number offeedback given by users |Vc(c, s)| who give feedbacksmore than the specified volume collusion thresholdev(s) over the total number of trust feedbacks receivedby the cloud service |V(s)|. The idea is to reduce thevalue of the multiple feedbacks which are given fromthe same user.

For instance, consider the two cloud services in theprevious example, sx and sy where sx has 89% andsy has 92% positive feedbacks, from 150 feedbacks.Assume that the Feedback Mass of sx is higher than sy(e.g., M(x) = 20 and M(y) = 5) and the total numberof trust feedbacks of the two services is |Vc(c, x)| = 60and |Vc(c, y)| = 136 feedbacks respectively. We furtherassume that the volume collusion threshold ev is setto 10 feedbacks. According to Equation 2, the FeedbackDensity of sx is higher than sy (i.e., D(x) = 0.0953 andD(y) = 0.0175). In other words, the higher the FeedbackDensity, the more credible are the aggregated feedbacks.

4.1.2 Occasional Feedback Collusion

Since collusion attacks against cloud services occur spo-radically [14], we consider time as an important factorin detecting occasional and periodic collusion attacks(i.e., periodicity). In other words, we consider the totalnumber of trust feedbacks |V(s)| given to cloud services during a period of time [t0, t]. A sudden change inthe feedback behavior indicates likely an occasionalfeedback collusion because the change of the numberof trust feedbacks given to a cloud service happenabruptly in a short period of time.

To detect such behavior, we measure the percentageof occasional change in the total number of feedbacksamong the whole feedback behavior (i.e., users’ behav-ior in giving feedbacks for a certain cloud service). Theoccasional feedback collusion factor Of (s, t0, t) of cloudservice s in a period of time [t0, t], is calculated as

follows:

Of (s,t0, t) = 1−

(∫ t

t0|V(s, t)| dt

)−(∫ t

t0∆f (s, t)dt

)∫ t

t0|V(s, t)| dt

where∆f (s, t) =

Cµ (|V(s, t)|) if |V(s, t)| ≥

Cµ (|V(s, t)|)|V(s, t)| otherwise

(4)

where the first part of the numerator represents thewhole area under the curve which represents the feed-back behavior for the cloud service s (i.e., a

∪a′, b

∪b′

and c∪

c′ in Figure 2). The second part of the numeratorrepresents the intersection between the area under thecurve and the area under the cumulative mean of the to-tal number of trust feedbacks (i.e., the area a′

∪b′∪c′ in

Figure 2). Cµ (|V(s, t)|) represents the mean of all pointsin the total number of trust feedbacks and up to thelast element because the mean is dynamic and changesfrom time to time. The denominator represents thewhole area under the curve. As a result, the occasionalcollusion attacks detection is based on measuring theoccasional change in the total number of trust feedbacksin a period of time. The higher the occasional changein the total number of trust feedbacks, the more likelythat the cloud service has been affected by an occasionalcollusion attack.

4.2 Sybil Attacks Detection

4.2.1 Multi-Identity RecognitionSince users have to register their credentials at theTrust Identity Registry, we believe that Multi-IdentityRecognition is applicable by comparing the values ofusers’ credential attributes from the identity records I.The main goal of this factor is to protect cloud servicesfrom malicious users who use multiple identities (i.e.,Sybil attacks) to manipulate the trust results. In a typicalTrust Identity Registry, the entire identity records I arerepresented as a list of m users’ primary identitiesCp = p1, p2, ..., pm (e.g., user name) and a list of n cre-dentials’ attributes Ca = a1, a2, ..., an (e.g., passwords,postal address, IP address, computer name). In otherwords, the entire Cp×Ca (Consumer’s Primary Identity-Credentials’ Attributes) Matrix, denoted as IM , coversall users who registered their credentials in TMS. Thecredential attribute value for a particular consumer vc,tis stored in TMS without including credentials withsensitive information using the ZKC2P (see Section 3).

We argue that TMS can identify patterns in users’anonymous credentials. Malicious users can use similarcredentials in different identity records I. Thus, wetranslate IM to the Multi-Identity Recognition Matrix,denoted as MIRM , which similarly covers the entireidentity records I represented as the entire Cp × Camatrix. However, the value for a particular consumerqc,t in the new matrix represents the frequency of the


credential attribute value for the same particular con-sumer vc,t in the same credential attribute (i.e., attributeat). The frequency of a particular credential attributevalue vc,t, denoted as qc,t, is calculated as the number oftimes of appearance (denoted as Ap) that the credentialvalue appears in the tth credential attribute normalizedby the total number of identity records (i.e., the lengthof at) as follows:

qc,t =

∑c=mc=1 (Ap(vc,t))

|at|(5)

Then, the Multi-Identity Recognition factor Mid is cal-culated as the sum of frequencies of each credentialattribute value for a particular consumer normalizedby the total number of identity record as follows:

Mid(c) = 1−

(t=n∑t=1

qc,t

)(6)

where the sum of qc,t represents the similar credentialsdistributed over different identity records I and Mid(c)represents the opposite (i.e., at least that the consumerhas fairly unique credentials).

4.2.2 Occasional Sybil AttacksMalicious users may manipulate trust results to disad-vantage particular cloud services by creating multipleaccounts and giving misleading feedbacks in a shortperiod of time (i.e., Sybil attacks). To overcome theoccasional Sybil attacks, we consider the total numberof established identities |I(s)| for users who give feed-backs to cloud service s during a period of time [t0, t].The sudden changes in the total number of establishedidentities indicates a possible occasional Sybil attack.To detect such behavior, we measure the percentage ofoccasional change in the total number of establishedidentities among the whole identity behavior (i.e., allestablished identities for users who gave feedback to aparticular cloud service). Similarly, the occasional Sybilattacks factor Oi(s, t0, t) of cloud service s in a periodof time [t0, t], is calculated as follows:

Oi(s,t0, t) = 1−

(∫ t

t0|I(s, t)|dt

)−(∫ t

t0∆i(s, t)dt

)∫ t

t0|I(s, t)| dt

where∆i(s, t) =

Cµ (|I(s, t)|) if |I(s, t)| ≥

Cµ (|I(s, t)|)|I(s, t)| otherwise

(7)

4.3 Feedback CredibilityBased on the proposed credibility metrics, TMS dilutesthe influence of those misleading feedbacks by assign-ing the credibility aggregated weights Cr(c, s, t0, t) toeach trust feedback as shown in Equation 1. Cr(c, s, t0, t)is calculated as follows:

Cr(c, s, t0, t) =1

λ∗ (ρ ∗ D(s) + ϕ ∗ Of (s, t0, t)+

Ω ∗Mid(c) + ι ∗ Oi(s, t0, t))(8)

where ρ and D(s) denote the Feedback Density factor’snormalized weight and the factor’s value respectively.ϕ and Of (s, t0, t) denote the parameter of the occasionalfeedback collusion factor and the factor’s value respec-tively. Ω denotes the Multi-identity Recognition normal-ized weight and Mid(c) denotes the factor’s value. ιdenotes the occasional Sybil attacks’ normalized weightand Oi(s, t0, t) denotes the factor’s value. λ representsthe number of factors used to calculate Cr(c, s, t0, t). Ifonly feedback density is considered, λ will be 1. If allcredibility factors are considered, λ will be 4. All themetrics of the credibility model complement each otherin detecting malicious behaviors and their influence canbe adjusted using the above mentioned parameters.

4.4 Change Rate of Trust ResultsTo allow TMS to adjust trust results for cloud servicesthat have been affected by malicious behaviors, weintroduce an additional factor called the change rate oftrust results. The idea behind this factor is to compensatethe affected cloud services by the same percentage ofdamage in the trust results. Given Con(s, t0) the conven-tional model (i.e., calculating the trust results withoutconsidering the proposed approach) for cloud service sin a previous time instance, Con(s, t) the conventionalmodel for the same cloud service calculated in a morerecent time instance, the credibility aggregated weightsCr(c, s, t0, t), and et(s) the attacks percentage threshold.The change rate of trust results factor Ct(s, t0, t) iscalculated as follows:

Ct(s, t0, t) =

Con(s,t0)Con(s,t) + 1 if Con(s, t) < Con(s, t0)

and

1− Cr(c, s, t0, t) ≥ et(s)

0 otherwise(9)

where Con(s,t0)Con(s,t) represents the change rate of trust re-

sults for cloud service s during a period of time [t0, t].The idea behind adding 1 to this ratio is to increasethe trust result for the affected cloud services. Thechange rate of trust results will only be used if theconventional model in the more recent time instanceis less than the conventional model in the previoustime instance and the attacks percentage during thesame period of time [t0, t] (i.e., 1 − Cr(c, s, t0, t)) islarger or equal to the attacks percentage threshold. Forinstance, if the conventional model in the current timefor cloud service a is less than the conventional model10 days ago, a will not be rewarded because the attackspercentage is less than the attacks percentage threshold(e.g., 1− Cr(c, a, t0, t) = 20% and et(a) = 30%).

The change rate of trust results is designed to limitthe rewards to cloud services that are affected by slan-dering attacks (i.e., cloud services that have decreasedtrust results) because TMS can dilute the increased trustresults from self-promoting attacks using the credibility


factors (i.e., Cr(c, a, t0, t)). The adaptive change rateof trust results factor can be used to assign differentweights using χ the normalized weight factor as shownin Equation 1.

5 THE AVAILABILITY MODEL

Guaranteeing the availability of the Trust ManagementService (TMS) is a significant challenge due to theunpredictable number of invocation requests that TMShas to handle at a time, as well as the dynamic natureof the cloud environments. In CloudArmor, we proposean availability model, which considers several factorsincluding the operational power to allow TMS nodesto share the workload and replication determination tominimize the failure of a node hosting TMS instance.These factors are used to spread several distributedTMS nodes to manage trust feedbacks given by usersin a decentralized way.

5.1 Operational Power

In our approach, we propose to spread TMS nodesover various clouds and dynamically direct requests tothe appropriate TMS node (e.g., with lower workload),so that its desired availability level can be alwaysmaintained. It is crucial to develop a mechanism thathelps determine the optimal number of TMS nodesbecause more nodes residing at various clouds meanshigher overhead (e.g., cost and resource consumptionsuch as bandwidth and storage space) while lowernumber of nodes means less availability. To exploit theload balancing technique, we propose that each nodehosting a TMS instance reports its operational power.The operational power factor compares the workloadfor a particular TMS node with the average workloadof all TMS nodes. The operational power for a particularTMS node, Op(stms), is calculated as the mean of theEuclidean distance (i.e., to measure the distance betweena particular TMS node workload and the mean of theworkload of all TMS nodes) and the TMS node work-load (i.e., the percentage of trust feedbacks handled bythis node) as follows:

Op(stms) =1

2∗

√( V(stms)

V(alltms)− V(meantms)

V(alltms)

)2

+

V(stms)

V(alltms)

)(10)

where the first part of the equation represents the Eu-clidean distance between the workload of node stms andthe average workload of all nodes where V(meantms)denotes the mean of feedbacks handled by all nodes.The second part of the equation represents the ratio offeedbacks handled by a particular node V(stms) overthe total number of feedbacks handled by all nodesV(alltms).

Based on the operational power factor, TMS uses theworkload threshold ew(stms) to automatically adjustthe number of nodes Ntms that host TMS instances bycreating extra instances to maintain a desired workloadfor each TMS node. The number of nodes Ntms isadjusted as follows:

Ntms =

Ntms + 1 if Op(stms) ≥ ew(stms)

or Ntms < 1

Ntms otherwise

(11)

5.2 Replication Determination

In CloudArmor, we propose to exploit replication tech-niques to minimize the possibility of the crashing of anode hosting a TMS instance (e.g., overload) to ensurethat users can give trust feedbacks or request a trustassessment for cloud services. Replication allows TMSinstance to recover any lost data during the down timefrom its replica. In particular, we propose a particlefiltering approach to precisely predict the availabilityof each node hosting a TMS instance which then willbe used to determine the optimal number of the TMSinstance’s replicas. To predict the availability of eachnode, we model the TMS instance as an instantaneous(or point) availability.

To predict the availability of each node, TMS in-stance’s availability is modeled using the point avail-ability model [26]. The point availability probability isdenoted as:

A(stms, t) = 1− F (t) +

∫ t

0

m(x)(1− F (t− x))dx (12)

where 1 − F (t) denotes the probability of no failurein (0, t], m(x)dx denotes the probability that any re-newal points in interval (x, x + dx], and 1 − F (t − x)represents the probability that no further failure occursin (x, t]. This availability function is a function of thetime parameter and can be estimated for different timepoints. In our work, the failure free density followsthe exponential distribution and the renewal densityfunction follows the exponential distribution in timedomain, f(t) = λe−λt, and m(t) = µe−µt. It is noteasy to observe the pattern of A(stms, t). We thereforeconduct the Laplace transform of Equation 12 as below:

A(stms, s) =1− f(s)

s(1− f(s)m(s))=

s+ µ

s(s+ µ+ λ)(13)

where f(s) and m(s) are the Laplace transforms of thefailure-free and renewal density functions. Equation 13in time domain can be obtained using:

A(stms, t) = 1− λ

µ(1− e−µt) (14)

For more technical details, interested readers can referto [26].

To this point, we can model the TMS instance’savailability prediction problem via defining the state


function and measurement function respectively byusing:

z(t+ 1) = A(stms, t) + ϵz

y(t+ 1) = z(t+ 1) + ϵy

where ϵz ∼N (0, σ2z), ϵy ∼ N (0, σ2

y)

(15)

We use the particle filtering technique to estimate andtrack the availability. A particle filter is a probabilisticapproximation algorithm implementing a Bayes filterand a sequential Monte Carlo method [27]. It maintainsa probability distribution for the estimated availabilityat time t, representing the belief of the TMS instance’savailability at that time.

We initialize a uniformly distributed sample set rep-resenting TMS instance’s availability state. We assigneach sample a same weight w. When the availabilitychanges, the particle filter will calculate next availabilityby adjusting and normalizing each sample’s weight.These samples’ weights are proportional to the obser-vation likelihood p(y|z). The particle filters randomlydraw samples from the current sample set whose prob-ability can be given by the weights. Then we canapply the particle filters to estimate the possible nextavailability state for each new particle. The predictionand update steps will keep going until convergence.

We calculate the weight distribution by consideringthe bias resulted from the routing information betweenusers and TMS instances (e.g., routing-hops betweenthe user and the instances or whether user and TMSinstances are in the same IP address segment). The Se-quential Importance Sampling (SIS) algorithm consistsof recursive propagation of the weights and supportpoints as each measurement is received sequentially.To tackle the degeneracy problem, we adopt a moreadvanced algorithm with resampling [28]. It has lesstime complexity and minimizes the Monte-Carlo vari-ation. The overall particle filtering based estimationmethodology is summarized in Algorithm 1.

Based on the predicted availability of the TMS in-stance A(stms, t), the availability threshold denoted asea that ranges from 0 to 1 and the total number of stms

replicas denoted r are calculated. The desired goal ofthe replication is to ensure that at least one replica isavailable, represented in the following formula:

ea(stms) < A(stms, t)r(stms) (16)

where A(stms, t)r(stms) represents the probability of at

least one TMS instance’s replica is available. As a result,the optimal number of TMS instance’s replicas can becalculated as follows:

r(stms) > logA(stms,t)(ea(stms)) (17)

5.3 Trust Result CachingDue to the fact that several credibility factors are consid-ered in CloudArmor when computing the trust resultfor a particular cloud service, it would be odd if the

Algorithm 1 Particle Filtering based Algorithm1. Initialization: compute the weight distribution Dw(A(stms)) ac-cording to prior knowledge on replicas, e.g., the IP address of serverhosting replicas etc.2. Generation: generate the particle set and assign the particle setcontaining N particles

• generate initial particle set P0 which has N particles, P0 =(p0,0, p0,1, ...p0,N−1) and distribute them in a uniform distribu-tion in the initial stage. Particle p0,k = (A(stms)0,k, weight0,k)

• assign weight to the particles according to our weight distribu-tion Dw(A(stms)).

3. Resampling:• Resample N particles from the particle set from a particle set

Pt using weights of each particles.• generate new particle set Pt+1 and assign weight according to

Dw(A(stms))

4. Estimation: predict new availability of the particle set Pt based onavailability function A(stms, t).5. Update:

• recalculate the weight of Pt based on measurement m, wt,k=∏(Dw(A(stms)t,k))(

1√2πσy

)exp(−δA(stms)2t,k

2σ2y

), where

δA(stms)k = mA(stms)−A(stms)t,k• calculate current availability by mean value of pt(A(stms)t)

6. Go to step 3 and iteration until convergence

TMS instance retrieves all trust feedbacks given to aparticular cloud service and computes the trust resultevery time it receives a trust assessment request froma user. Instead we propose to cache the trust resultsand the credibility weights based on the number ofnew trust feedbacks to avoid unnecessary trust resultcomputations. The caching process is controlled bytwo thresholds: one for users eCache(c) and one forcloud services eCache(s). If the TMS instance receives atrust assessment request from a user, it should use thetrust result in the cache as much as possible, insteadof computing the trust result from scratch. The TMSinstance updates the cache based on the number of newtrust feedbacks (i.e., since the last update) given by aparticular consumer |Vc(c, s)|Cache and the number ofnew trust feedbacks given to a particular cloud service|V(s)|Cache. The caching process is briefly shown inAlgorithm 2.

5.4 Instances Management

In CloudArmor, we propose that one TMS instanceacts as the main instance while the rest instances act asnormal instances. The main instance is responsible for theoptimal number of nodes estimation, feedbacks reallo-cation, trust result caching (consumer side), availabilityof each node prediction, and TMS instance replication.Normal instances are responsible for trust assessmentand feedback storage, the trust result caching (cloudservice side), and frequency table update. Algorithm 3shows the brief process on how TMS instances aremanaged.

Unlike previous work such as [8] where all invocationhistory records for a certain client is mapped to aparticular TMS instance (e.g., all feedback given to a


Algorithm 2 Trust Results & Credibility WeightsCaching AlgorithmInput: s, Output: T r(s)

Count |Vc(c, s)|Cache /*TMS instance counts the total number of newtrust feedbacks given by a particular consumer*/if |Vc(c, s)|Cache ≥ eCache(c) then /*TMS determines whether a re-calculation is required for credibility factors related to the consumer*/

Compute J (c); Compute B(c)Compute Mid(c); Compute Cr(c, s)

end ifCount |V(s)|Cache /*TMS instance counts the total number of newtrust feedbacks given to a particular cloud service*/if |V(s)|Cache ≥ eCache(s) then /*TMS determines whether arecalculation is required for credibility factors related to the cloudservice including the trust result*/

Compute D(s); Compute Cr(c, s)Compute T r(s)

end if

Algorithm 3 Instances Management Algorithm1. Initialization: tmsid(0) computes Op(stms) for all trust manage-ment service nodes if any2. Generation: tmsid(0) estimates Ntms and generates additionaltrust management service nodes if required3. Prediction: tmsid(0) predicts new availability of all trust manage-ment service nodes A(stms, t) using Algorithm 14. Replication: tmsid(0) determines r(stms), and generate replicasfor each trust management service node5. Caching: tmsid(0) starts caching trust results (consumer side)and tmsid(s) start caching trust results (cloud service side) usingAlgorithm 26. Update: All tmsid(s) update the frequency table7. Check Workload 1: tmsid(0) checks whether ew(stms) is triggeredby any tmsid(s) before reallocationif Op(stms) ≥ ew(stms) and V(stms) ≥ V(meantms) then

go to next stepelse

go to step 3end if8. Reallocation:

• tmsid(0) asks tmsid(s) which triggered ew(stms) to reallocateall trust feedbacks of the cloud service that has the lowest |V(s)|to another tmsid(s) that has the lowest V(stms)

• perform step 6

9. Check Workload 2: tmsid(0) computes Op(stms) for all trustmanagement service nodes and checks whether ew(stms) is triggeredfor any tmsid(s) after reallocationif Op(stms) ≥ ew(stms) and V(stms) ≥ V(meantms) then

go to step 2else

go to step 3end if

certain cloud service in our case), in our approach,each TMS instance is responsible for feedbacks givento a set of cloud services and updates the frequencytable. The frequency table shows which TMS instanceis responsible for which cloud service and how manyfeedbacks it has handled. Example 1 illustrates howfeedbacks can be reallocated from one TMS instance to adifferent instance. In this example, there are three TMSinstances and the workload threshold ew(stms) is set

Example 1: Reallocation (ew(stms) = 50%)

Frequency Table Before Reallocation (Step 1)(tmsid(1), |V(1)|: 200, |V(2)|: 150, |V(3)|: 195)(tmsid(2), |V(4)|: 30, |V(5)|: 20, |V(6)|: 45)(tmsid(3), |V(7)|: 90, |V(8)|: 35, |V(9)|: 95)

Check Workload (Step 2)(tmsid(1), Op(1tms): 0.617)(tmsid(2), Op(2tms): 0.278)(tmsid(3), Op(3tms): 0.205)

Frequency Table After Reallocation (Step 3)(tmsid(1), |V(1)|: 200, |V(3)|: 195)(tmsid(2), |V(2)|: 150, |V(4)|: 30, |V(5)|: 20, |V(6)|: 45)(tmsid(3), |V(7)|: 90, |V(8)|: 35, |V(9)|: 95)

to 50%. TMS instance tmsid(1) triggers the threshold,therefore according to Algorithm 3, the trust feedbacksfor the cloud service (2) are reallocated to tmsid(2),which has the lowest feedbacks.

6 IMPLEMENTATION AND EXPERIMENTALEVALUATION

In this section, we report the implementation and ex-perimental results in validating the proposed approach.Our implementation and experiments were developedto validate and study the performance of both thecredibility model and the availability model.

6.1 System ImplementationThe trust management service’s implementation is partof our large research project, named CloudArmor2,which offers a platform for reputation-based trust man-agement of cloud services [29], [30], [31], [9]. The plat-form provides an environment where users can givefeedback and request trust assessment for a particularcloud service. Specifically, the trust management service(TMS) consists of two main components: the Trust DataProvisioning and the Trust Assessment Function.

The Trust Data Provisioning. This component is responsi-ble for collecting cloud services and trust information.We developed the Cloud Services Crawler module basedon the Open Source Web Crawler for Java (crawler4j3)and extended it to allow the platform to automaticallydiscover cloud services on the Internet. We imple-mented a set of functionalities to simplify the crawlingprocess and made the crawled data more comprehen-sive (e.g., addSeeds(), selectCrawlingDomain(),addCrawlingTime()). In addition, we developed theTrust Feedbacks Collector module to collect feedbacksdirectly from users in the form of history records andstored them in the Trust Feedbacks Database. Indeed,users typically have to establish their identities for thefirst time they attempt to use the platform throughregistering their credentials at the Identity ManagementService (IdM) which stores the credentials in the Trust

2. http://cs.adelaide.edu.au/∼cloudarmor3. http://code.google.com/p/crawler4j/


Identity Registry. Moreover, we developed the IdentityInfo Collector module to collect the total number ofestablished identities among the whole identity behav-ior (i.e., all established identities for users who gavefeedbacks to a particular cloud service).

The Trust Assessment Function. This function is respon-sible for handling trust assessment requests from userswhere the trustworthiness of cloud services are com-pared and the factors of trust feedbacks are calculated(i.e., the credibility factors). We developed the FactorsCalculator for attacks detection based on a set of fac-tors (more details on how the credibility factors arecalculated can be found in Section 4). Moreover, wedeveloped the Trust Assessor to compare the trust-worthiness of cloud services through requesting theaggregated factors weights from the Factors Calculatorto weigh feedbacks and then calculate the mean of allfeedbacks given to each cloud service. The trust resultsfor each cloud service and the factors’ weights for trustfeedbacks are stored in the Trust Results and FactorsWeights Storage.

6.2 Experimental EvaluationWe particularly focused on validating and studying therobustness of the proposed credibility model againstdifferent malicious behaviors, namely collusion andSybil attacks under several behaviors, as well as theperformance of our availability model.

6.3 Credibility Model ExperimentsWe tested our credibility model using real-world trust feedbacks on cloud services. Inparticular, we crawled several review websitessuch as cloud-computing.findthebest.com,cloudstorageprovidersreviews.com, andCloudHostingReviewer.com, and where usersgive their feedbacks on cloud services that they haveused. The collected data is represented in a tuple Hwhere the feedback represents several QoS parametersas mentioned earlier in Section 3.2 and augmented witha set of credentials for each corresponding consumer.We managed to collect 10,076 feedbacks given by 6,982users to 113 real-world cloud services. The collecteddataset has been released to the research communityvia the project website.

For experimental purposes, the collected data wasdivided into six groups of cloud services, three of whichwere used to validate the credibility model againstcollusion attacks, and the other three groups were usedto validate the model against Sybil attacks where eachgroup consists of 100 users. Each cloud service groupwas used to represent a different attacking behaviormodel, namely: Waves, Uniform and Peaks as shownin Figure 3. The behavior models represent the totalnumber of malicious feedbacks introduced in a partic-ular time instance (e.g., |V(s)| = 60 malicious feedbacks

(a) Waves

(b) Uniform

(c) Peaks

Fig. 3. Attacking Behavior Models

when Tf = 40, Figure 3(a)) when experimenting againstcollusion attacks. The behavior models also representthe total number of identities established by attackersin a period of time (e.g., |I(s)| = 78 malicious identitieswhen Ti = 20, Figure 3(c)) where one malicious feed-back is introduced per identity when experimentingagainst Sybil attacks. In collusion attacks, we simu-lated malicious feedback to increase trust results ofcloud services (i.e., self-promoting attack) while in Sybilattacks we simulated malicious feedback to decreasetrust results (i.e., slandering attack). To evaluate therobustness of our credibility model with respect tomalicious behaviors (i.e., collusion and Sybil attacks),we used two experimental settings: I) measuring therobustness of the credibility model with a conventionalmodel Con(s, t0, t) (i.e., turning Cr(c, s, t0, t) to 1 for alltrust feedbacks), and II) measuring the performance ofour model using two measures namely precision (i.e.,how well TMS did in detecting attacks) and recall (i.e.,how many detected attacks are actual attacks). In ourexperiments, TMS started rewarding cloud services thathad been affected by malicious behaviors when theattacks percentage reached 25% (i.e., et(s) = 25%), sothe rewarding process would occur only when therewas a significant damage in the trust result.

We conducted 12 experiments where six of whichwere conducted to evaluate the robustness of our cred-ibility model against collusion attacks and the rest forSybil attacks. Each experiment is denoted by a letterfrom A to F, as shown in Table 1.

TABLE 1Behavior Experimental Design

MaliciousBehaviors

ExperimentalSetting

Waves Uniform Peaks

Collusion I A B C

Attacks II A′ B′ C′

Sybil I D E F

Attacks II D′ E′ F ′


A A′

B B′

C C ′

Conventional Credibility Model

Legend Precision Recall

Fig. 4. Robustness Against Collusion Attacks

6.3.1 Robustness Against Collusion Attacks

For the collusion attacks, we simulated malicious usersto increase trust results of cloud services (i.e., self-promoting attack) by giving feedback with the rangeof [0.8, 1.0]. Figure 4 depicts the analysis of six experi-ments which were conducted to evaluate the robustnessof our model with respect to collusion attacks. In Fig-ure 4, A, B, and C show the trust result for experimentalsetting I , while A′, B′, and C ′ depict the results forexperimental setting II .

We note that the closer to 100 the time instance is,the higher the trust results are when when the trust iscalculated using the conventional model. This happensbecause malicious users are giving misleading feedbackto increase the trust result for the cloud service. Onthe other hand, the trust results show nearly no changewhen calculated using the proposed credibility model(Figure 4 A, B and C). This demonstrates that ourcredibility model is sensitive to collusion attacks and isable to detect such malicious behaviors. In addition, wecan make an interesting observation that our credibilitymodel gives the best results in precision when theUniform behavior model is used (i.e., 0.51, see Figure 4B′), while the highest recall score is recorded whenthe Waves behavior model is used (i.e., merely 0.9, seeFigure 4 A′). Overall, recall scores are fairly high whenall behavior models are used which indicate that mostof the detected attacks are actual attacks. This meansthat our model can successfully detect collusion attacks(i.e., whether the attack is strategic such as in Waves

D D′

E E′

F F ′

Conventional Credibility Model

Legend Precision Recall

Fig. 5. Robustness Against Sybil Attacks

and Uniform behavior models or occasional such as inthe Peaks behavior model) and TMS is able to dilutethe increased trust results from self-promoting attacksusing the proposed credibility factors.

6.3.2 Robustness Against Sybil AttacksFor the Sybil attacks experiments, we simulated mali-cious users to decrease trust results of cloud services(i.e., slandering attack) by establishing multiple identi-ties and giving one malicious feedback with the rangeof [0, 0.2] per identity. Figure 5 depicts the analysis ofsix experiments which were conducted to evaluate therobustness of our model with respect to Sybil attacks.In Figure 5, D, E, and F show the trust results forexperimental setting I , while D′, E′, and F ′ depict theresults for experimental setting II .

From Figure 5, we can observe that trust resultsobtained by using the conventional model decreasewhen the time instance becomes closer to 100. This isbecause of malicious users who are giving misleadingfeedback to decrease the trust result for the cloudservice. On the other hand, trust results obtained byusing our proposed credibility model are higher thanthe ones obtained by using the conventional model(Figure 5 D, E and F ). This is because the cloudservice was rewarded when the attacks occurred. Wealso can see some sharp drops in trust results obtainedby considering our credibility model where the highestnumber of drops is recorded when the Peaks behaviormodel is used (i.e., we can see 5 drops in Figure 5 F


(a) Actual Availability VS. Esti-mated Availability

(b) Trust Results Caching ErrorRate

Fig. 6. Availability Prediction and Caching Accuracy

which actually matches the drops in the Peaks behaviormodel in Figure 3(c)). This happens because TMS willonly reward the affected cloud services if the percentageof attacks during the same period of time has reachedthe threshold (i.e., which is set to 25% in this case).This means that TMS has rewarded the affected cloudservice using the change rate of trust results factor.Moreover, from Figure 5 D′, E′ and F ′, we can see thatour credibility model gives the best results in precisionwhen the Waves behavior model is used (i.e., 0.47, seeFigure 4 D′), while the highest recall score is recordedwhen the Uniform behavior model is used (i.e., 0.75,see Figure 4 A′). This indicates that our model cansuccessfully detect Sybil attacks (i.e., either strategicattacks such as in Waves and Uniform behavior modelsor occasional attacks such as in the Peaks behaviormodel) and TMS is able to reward the affected cloudservice using the change rate of trust results factor.

6.4 Availability Model ExperimentsWe tested our availability model using the same datasetwe collected to validate the credibility model. How-ever, for the availability experiments, we focused onvalidating the availability prediction accuracy, trustresults caching accuracy, and reallocation performanceof the availability model (i.e., to validate the threeproposed algorithms including Particle Filtering basedAlgorithm, Trust Results & Credibility Weights CachingAlgorithm, and Instances Management Algorithm).

6.4.1 Availability Prediction AccuracyTo measure the prediction accuracy of the availabilitymodel, we simulated 500 nodes hosting TMS instancesand set the failure probability for the nodes as 3.5percent, which complies with the findings in [32]. Themotivation of this experiment is to study the estimationaccuracy of our approach. We simulated TMS nodes’availability fluctuation and tracked their fluctuation ofavailability for 100 time steps (each time step counted asan epoch). The actual availability of TMS nodes and cor-responding estimated availability using our particle fil-ter approach were collected and compared. Figure 6(a)shows the result of one particular TMS node. From thefigure, we can see that the estimated availability is veryclose to the actual availability of the TMS node. Thismeans that our approach works well in tracing andpredicting the availability of TMS nodes.

(a) Number of TMS Nodes VS.Feedbacks

(b) Number of TMS Nodes VS.Workload Threshold

Fig. 7. Reallocation Performance

6.4.2 Trust Results Caching AccuracyTo measure the caching accuracy of the availabilitymodel, we varied the caching threshold to identifythe optimal number of new trust feedbacks that TMSreceived to recalculate the trust result for a particularcloud service without having a significant error in thetrust results. The trust result caching accuracy is mea-sured by estimating the root-mean-square error (RMSE)(denoted caching error) of the estimated trust result andthe actual trust result of a particular cloud service. Thelower the RMSE value means the higher accuracy in thetrust result caching. Figure 6(b) shows the trust resultcaching accuracy of one particular cloud service. Fromthe figure, we can see that the caching error increasesalmost linearly when the caching threshold increases.The results allow us to choose the optimal cachingthreshold based on an acceptable caching error rate.For example, if 10% is an acceptable error margin, thecaching threshold can be set to 50 feedbacks. It is worthmentioning that the caching error was measured on realusers’ feedbacks on real-world cloud services.

6.4.3 Reallocation PerformanceTo validate the reallocation performance of the avail-ability model, we used two experimental settings: I)comparing the number of TMS nodes when using thereallocation of trust feedbacks and without reallocationwhile increasing the number of feedbacks (i.e., when theworkload threshold ew(stms) = 25%); II) comparing thenumber of TMS nodes when using the reallocation oftrust feedbacks and without reallocation while varyingew(stms). The lower the number of TMS nodes, the morecost efficient TMS is. Figure 7(a) shows the results ofexperimental settings I. We can observe that the totalnumber of TMS nodes when using the reallocation oftrust feedbacks technique is fairly low and more stablethan the total number of TMS nodes when realloca-tion is not used (i.e., even when the total number offeedbacks is high). Figure 7(b) shows the results ofexperimental settings II. From the figure, we can seethat the higher the workload threshold the lower thenumber of TMS nodes. However, the number of TMSnodes when using the reallocation of trust feedbackstechnique is lower than the number of TMS nodes whenreallocation is not considered. This means that ourapproach has advantages in minimizing the bandwidthcost by reducing the total number of TMS nodes.


7 RELATED WORK

Over the past few years, trust management has beena hot topic in the area of cloud computing [33], [14],[10]. Some of the research efforts use policy-based trustmanagement techniques. For example, Ko et al. [34]propose TrustCloud framework for accountability andtrust in cloud computing. In particular, TrustCloudconsists of five layers including workflow, data, system,policies and laws, and regulations layers to addressaccountability in the cloud environment. All of theselayers maintain the cloud accountability life cycle whichconsists of seven phases including policy planning,sense and trace, logging, safe-keeping of logs, report-ing and replaying, auditing, and optimizing and rec-tifying. Brandic et al. [7] propose a novel approachfor compliance management in cloud environments toestablish trust between different parties. The approachis developed using a centralized architecture and usescompliant management technique to establish trust be-tween cloud service users and cloud service providers.Unlike previous works that use policy-based trust man-agement techniques, we assess the trustworthiness of acloud service using reputation-based trust managementtechniques. Reputation represents a high influence thatcloud service users have over the trust managementsystem [35], especially that the opinions of the variouscloud service users can dramatically influence the repu-tation of a cloud service either positively or negatively.

Some research efforts also consider the reputation-based trust management techniques. For instance,Habib et al. [6] propose a multi-faceted Trust Man-agement (TM) system architecture for cloud computingto help the cloud service users to identify trustworthycloud service providers. In particular, the architecturemodels uncertainty of trust information collected frommultiple sources using a set of Quality of Service (QoS)attributes such as security, latency, availability, and cus-tomer support. The architecture combines two differenttrust management techniques including reputation andrecommendation where operators (e.g., AND, OR, andFUSION) are used. Hwang et al. [4] propose a securityaware cloud architecture that assesses the trust for bothcloud service providers and cloud service users. To as-sess the trustworthiness of cloud service providers, theauthors propose the trust negotiation approach and thedata coloring (integration) using fuzzy logic techniques.To assess the trustworthiness of cloud service users,they develop the Distributed-Hash-Table (DHT)-basedtrust-overlay networks among several data centers todeploy a reputation-based trust management technique.Unlike previous works which do not consider the prob-lem of unpredictable reputation attacks against cloudservices, we present a credibility model that not onlydetects the misleading trust feedbacks from collusionand Sybil attacks, but also has the ability to adaptivelyadjust the trust results for cloud services that have beenaffected by malicious behaviors.

8 CONCLUSION

Given the highly dynamic, distributed, and non-transparent nature of cloud services, managing and es-tablishing trust between cloud service users and cloudservices remains a significant challenge. Cloud serviceusers’ feedback is a good source to assess the overalltrustworthiness of cloud services. However, malicioususers may collaborate together to i) disadvantage acloud service by giving multiple misleading trust feed-backs (i.e., collusion attacks) or ii) trick users into trust-ing cloud services that are not trustworthy by creatingseveral accounts and giving misleading trust feedbacks(i.e., Sybil attacks). In this paper, we have presentednovel techniques that help in detecting reputation-based attacks and allowing users to effectively identifytrustworthy cloud services. In particular, we introducea credibility model that not only identifies misleadingtrust feedbacks from collusion attacks but also detectsSybil attacks no matter these attacks take place in along or short period of time (i.e., strategic or occasionalattacks respectively). We also develop an availabilitymodel that maintains the trust management service at adesired level. We have collected a large number of con-sumer’s trust feedbacks given on real-world cloud ser-vices (i.e., over 10,000 records) to evaluate our proposedtechniques. The experimental results demonstrate theapplicability of our approach and show the capabilityof detecting such malicious behaviors.

There are a few directions for our future work. Weplan to combine different trust management techniquessuch as reputation and recommendation to increase thetrust results accuracy. Performance optimization of thetrust management service is another focus of our futureresearch work.

ACKNOWLEDGMENTS

Talal H. Noor’s work was supported by King Abdul-lah’s Postgraduate Scholarships, the Ministry of HigherEducation: Kingdom of Saudi Arabia. Quan Z. Sheng’swork has been partially supported by Australian Re-search Council (ARC) Discovery Grant DP140100104and FT140101247. The authors would like to thank theanonymous reviewers for their valuable feedback onthis work.

REFERENCES[1] S. M. Khan and K. W. Hamlen, “Hatman: Intra-Cloud Trust

Management for Hadoop,” in Proc. CLOUD’12, 2012.[2] S. Pearson, “Privacy, Security and Trust in Cloud Computing,”

in Privacy and Security for Cloud Computing, ser. Computer Com-munications and Networks, 2013, pp. 3–42.

[3] J. Huang and D. M. Nicol, “Trust Mechanisms for Cloud Com-puting,” Journal of Cloud Computing, vol. 2, no. 1, pp. 1–14, 2013.

[4] K. Hwang and D. Li, “Trusted Cloud Computing with SecureResources and Data Coloring,” IEEE Internet Computing, vol. 14,no. 5, pp. 14–22, 2010.

[5] M. Armbrust, A. Fox, R. Griffith, A. Joseph, R. Katz, A. Konwin-ski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia, “AView of Cloud Computing,” Communications of the ACM, vol. 53,no. 4, pp. 50–58, 2010.


[6] S. Habib, S. Ries, and M. Muhlhauser, “Towards a Trust Man-agement System for Cloud Computing,” in Proc. of TrustCom’11,2011.

[7] I. Brandic, S. Dustdar, T. Anstett, D. Schumm, F. Leymann, andR. Konrad, “Compliant Cloud Computing (C3): Architecture andLanguage Support for User-Driven Compliance Management inClouds,” in Proc. of CLOUD’10, 2010.

[8] W. Conner, A. Iyengar, T. Mikalsen, I. Rouvellou, and K. Nahrst-edt, “A Trust Management Framework for Service-OrientedEnvironments,” in Proc. of WWW’09, 2009.

[9] T. H. Noor, Q. Z. Sheng, and A. Alfazi, “Reputation AttacksDetection for Effective Trust Assessment of Cloud Services,” inProc. of TrustCom’13, 2013.

[10] T. H. Noor, Q. Z. Sheng, S. Zeadally, and J. Yu, “Trust Man-agement of Services in Cloud Environments: Obstacles andSolutions,” ACM Computing Surveys, vol. 46, no. 1, pp. 12:1–12:30, 2013.

[11] S. Pearson and A. Benameur, “Privacy, Security and Trust IssuesArising From Cloud Computing,” in Proc. CloudCom’10, 2010.

[12] E. Bertino, F. Paci, R. Ferrini, and N. Shang, “Privacy-preservingDigital Identity Management for Cloud Computing,” IEEE DataEng. Bull, vol. 32, no. 1, pp. 21–27, 2009.

[13] E. Friedman, P. Resnick, and R. Sami, Algorithmic Game The-ory. New York, USA: Cambridge University Press, 2007, ch.Manipulation-Resistant Reputation Systems, pp. 677–697.

[14] K. Ren, C. Wang, and Q. Wang, “Security Challenges for thePublic Cloud,” IEEE Internet Computing, vol. 16, no. 1, pp. 69–73, 2012.

[15] F. Skopik, D. Schall, and S. Dustdar, “Start Trusting Strangers?Bootstrapping and Prediction of Trust,” in Proc. of WISE’09, 2009.

[16] H. Guo, J. Huai, Y. Li, and T. Deng, “KAF: Kalman FilterBased Adaptive Maintenance for Dependability of CompositeServices,” in Proc. of CAiSE’08, 2008.

[17] T. Dillon, C. Wu, and E. Chang, “Cloud Computing: Issues andChallenges,” in Proc. of AINA’10, 2010.

[18] Y. Wei and M. B. Blake, “Service-oriented Computing and CloudComputing: Challenges and Opportunities,” Internet Computing,IEEE, vol. 14, no. 6, pp. 72–75, 2010.

[19] P. Mell and T. Grance, “The NIST Definition of CloudComputing,” Sep 2011, accessed: 05/06/2012, Available at:http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145 cloud-definition. pdf.

[20] O. David and C. Jaquet, “Trust and Identification in the Light ofVirtual Persons,” pp. 1–103, Jun 2009, accessed 10/3/2011, Avail-able at: http://www.fidis.net/resources/deliverables/identity-of-identity/.

[21] B. Fung, K. Wang, R. Chen, and P. Yu, “Privacy-preserving DataPublishing: A Survey of Recent Developments,” ACM ComputingSurveys, vol. 42, no. 4, pp. 1–53, 2010.

[22] J. R. Douceur, “The Sybil Attack,” in Proc. of IPTPS’02, 2002.[23] S. Ba and P. Pavlou, “Evidence of the Effect of Trust Building

Technology in Electronic Markets: Price Premiums and BuyerBehavior,” MIS Quarterly, vol. 26, no. 3, pp. 243–268, 2002.

[24] K. Lai, M. Feldman, I. Stoica, and J. Chuang, “Incentives for Co-operation in Peer-to-Peer Networks,” in Proc. of the 1st Workshopon Economics of Peer-to-Peer Systems, 2003.

[25] L. Xiong and L. Liu, “Peertrust: Supporting Reputation-basedTrust for Peer-to-Peer Electronic Communities,” IEEE Transac-tions on Knowledge and Data Engineering, vol. 16, no. 7, pp. 843–857, 2004.

[26] A. Birolini, Reliability Engineering: Theory and Practice. Springer,2010.

[27] L. Yao and Q. Z. Sheng, “Particle Filtering Based AvailabilityPrediction for Web Services,” in Proc. of ICSOC’11, 2011.

[28] S. Maskell and N. Gordon, “A Tutorial on Particle Filters forOn-line Nonlinear/Non-Gaussian Bayesian Tracking,” in TargetTracking: Algorithms and Applications (Ref. No. 2001/174), IEEE.IET, 2001, pp. 2–1.

[29] T. H. Noor and Q. Z. Sheng, “Trust as a Service: A Framework forTrust Management in Cloud Environments,” in Proc. of WISE’11,2011.

[30] T. H. Noor, Q. Z. Sheng, A. H. Ngu, A. Alfazi, and J. Law,“CloudArmor: A Platform for Credibility-based Trust Manage-ment of Cloud Services,” in Proc. of CIKM’13, 2013.

[31] T. Noor and Q. Z. Sheng, “Credibility-Based Trust Managementfor Services in Cloud Environments,” in Proc. of ICSOC’11, 2011.

[32] S. M. Kim and M.-C. Rosu, “A Survey of Public Web Services,”in Proc. of WWW04, 2004.

[33] K. Hoffman, D. Zage, and C. Nita-Rotaru, “A Survey of Attackand Defense Techniques for Reputation Systems,” ACM Comput-ing Surveys, vol. 42, no. 1, pp. 1–31, 2009.

[34] R. Ko et al., “TrustCloud: A Framework for Accountability andTrust in Cloud Computing,” in Proc. SERVICES’11, 2011.

[35] C. Dellarocas, “The Digitization of Word of Mouth: Promiseand Challenges of Online Feedback Mechanisms,” ManagementScience, vol. 49, no. 10, pp. 1407–1424, 2003.

Talal H. Noor is an assistant professor at theCollege of Computer Science and Engineer-ing, Taibah University, Yanbu, Saudi Arabia. Hereceived the Ph.D. degree in Computer Sci-ence from the University of Adelaide, Australia.His research interests include cloud comput-ing, service-oriented computing, security andprivacy, and trust management.

Quan Z. Sheng is an associate professorand Head of the Advanced Web TechnologiesGroup at School of Computer Science, theUniversity of Adelaide. He received the PhDdegree in computer science from the Univer-sity of New South Wales and B.E from Bei-hang University. His research interests includeWeb technologies, distributed computing, Webof Things, big data analytics, and pervasivecomputing. He is the recipient of ARC FutureFellowship in 2014, Chris Wallace Award for

Outstanding Research Contribution in 2012, and Microsoft ResearchFellowship in 2003. He is the author of more than 190 publications.

Lina Yao is currently a PostDoc and an asso-cate lecturer at School of Computer Science,the University of Adelaide. She received PhDand M.Sc, both in Computer Science, from theUniversity of Adelaide and B.E from ShandongUniversity. Her research interests include Webmining, Internet of Things, Ubiquitous comput-ing and Service Oriented Computing.

Schahram Dustdar is Full Professor of Com-puter Science (Informatics) with a focus onInternet Technologies heading the DistributedSystems Group at the Vienna University ofTechnology. He is a member of the AcademiaEuropaea: The Academy of Europe, Informat-ics Section (since 2013), recipient of the ACMDistinguished Scientist award (2009), and theIBM Faculty Award (2012). He is an AssociateEditor of IEEE Transactions on Services Com-puting, ACM Transactions on the Web, and

ACM Transactions on Internet Technology and on the editorial boardof IEEE Internet Computing. He is the Editor-in-Chief of Computing(an SCI-ranked journal of Springer).

Anne H.H. Ngu is currently a full Professor withthe Department of Computer Science at TexasState University-San Marcos. From 1992-2000,she worked as a Senior Lecturer in the Schoolof Computer Science and Engineering, Univer-sity of New South Wales (UNSW), Australia.She has held research scientist positions withTelecordia Technologies and Microelectonicsand Computer Technology (MCC). She was asummer faculty scholar at Lawrence LivermoreNational Laboratory from 2003-2006. Her main

research interests are in large-scale discovery and integration of in-formation services, scientific and business process automation, agentsystems and Internet of Things.

Documents

IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED …qsheng/papers/tpds-noor-2015.pdfCloudArmor: Supporting Reputation-based Trust Management for Cloud Services Talal H. Noor, Quan Z