Trust Evaluation in Cross-Cloud Federation: Survey and Requirement Analysis Trust Evaluation in Cross-Cloud Federation: Survey and Requirement Analysis

USAMA AHMED, COMSATS University Islamabad, Lahore Campus, Pakistan and Government College University
IMRAN RAZA, and
SYED ASAD HUSSAIN, COMSATS University Islamabad, Lahore Campus

ACM Comput. Surv., Vol. 52, No. 1, Article 19, Publication date: January 2019.
DOI: https://doi.org/10.1145/3292499

Cross-Cloud Federation (CCF) is beneficial for heterogeneous Cloud Service Providers (CSPs) for leasing additional resources from each other. Despite the benefits of on-demand scalability and enhanced service footprints for better service quality, the adoption of CCF is however mainly hindered due to the lack of a comprehensive trust model. The basic aim of such a model should be to address the security and performance concerns of a home CSP on its foreign peers before placing its users’ data and applications in their premises. A transitivity of users’ trust on home CSP and home CSP's trust on its foreign CSPs marks the uniqueness of trust paradigm in CCF. Addressing the concerns of cloud-to-cloud trust paradigm is inevitable to achieve users’ trust in a federation. Various trust models have been proposed in literature for conventional and multi-cloud computing environments. They focus on user requirements but none on federation perspective. Their applicability to CCF for addressing the concerns of cloud-to-cloud trust paradigm requires further consideration. For this reason, we have first outlined the general characteristics of CCF as being dynamic, multi-level and heterogeneous. Afterwards, cloud-to-cloud trust paradigm is proposed based on a set of unique principles identified as (i) trust bi-directionality, (ii) trust composition, (iii) delegation control, and (iv) Resource awareness. An insightful review of Trust Management Systems (TMS) proposed in literature reveals their shortcomings in addressing the requirements of cloud-to-cloud trust paradigm. To overcome these shortcomings, we suggest that some challenges can be merely addressed by aligning the existing methods to the nature of CCF. The remaining challenges require entirely new mechanisms to be introduced. A demonstration of this concept is presented in the form of a requirement matrix suggesting how the characteristics and properties of both CCF and the TMS are influenced by each other. This requirement matrix reveals the potential avenues of research for a TMS aimed specifically for CCF.

CCS Concepts: • Security and privacy → Trust frameworks; Security requirements; • Networks → Cloud computing;

Additional Key Words and Phrases: Cross-cloud, federation, inter-cloud, trust, reputation, trust models

ACM Reference format:
Usama Ahmed, Imran Raza, and Syed Asad Hussain. 2019. Trust Evaluation in Cross-Cloud Federation: Survey and Requirement Analysis. ACM Comput. Surv. 52, 1, Article 19 (January 2019), 37 pages. https://doi.org/10.1145/3292499

1 INTRODUCTION

The standard model of cloud computing [1] dictates the usage of multiple clouds to realize elasticity, reliability, and enhanced Quality of Service (QoS). This model can be further classified into multi-cloud and federated cloud architectures [2]. In multi-cloud architecture, a user takes service from multiple CSPs signing multiple Service Level Agreements (SLAs), unique for each CSP. In multi-cloud, a customer is solely responsible for resource provisioning and application brokering. However, federated clouds offer composite services that are aggregated from services offered by more than one CSP. Federated clouds are helpful for CSPs to cope with unexpected variations in resource demands by leasing infrastructure from other providers. In a federated cloud architecture, a user signs a single SLA with its home CSP, which may further be leasing service(s) from other foreign CSPs of the federation.

A federation may comprise of CSPs with homogenous infrastructures, well known to each other due to long-term contracts or it may comprise of unknown CSPs with heterogeneous infrastructures sharing resources for a limited period [3]. The former has the benefit of longstanding trustworthy relationship. However, it lacks the benefits of scalability and diversity in service composition when it comes to varying computing and geographical demands of diverse application platforms. The latter, known as the cross-cloud federation, tends to offer benefits over its counterpart in terms of scalability and diverse service composition [4]. CSPs participating in cross-cloud federation are not bound by the limitations of their collaborators but are free to choose from a dynamic pool of resources shared by the heterogeneous peers.

Despite these benefits, CSPs are hesitant to contribute to cross-cloud federation, mainly due to the lack of confidence and trust among CSPs [5]. Trust establishment has been a major concern in cloud computing and it has been a focus of research for some time. Cloud customers have always remained hesitant for cloud adoption due to the fear of losing control over their applications and data entrusted to a CSP [68]. It is not because the users have mistrust in capabilities of cloud computing; rather, they primarily doubt CSPs’ intentions and trueness [9].

This problem of trust establishment between a Cloud Service User (CSU) and CSP is already sufficiently explored in literature. A lot of work has been done in this regard ranging from trust evaluation methods [1020] to frameworks [2131], models [3243] and comprehensive TMS [4448]. A few works have been reported suggesting the inter-cloud model as a mean to establish trust by virtue of increased security and complexity [4953]. Apart from this, trust establishment has been reported in literature for multi-cloud [5457] and federated clouds [58]. The primary objective of these works is to facilitate the CSUs in establishing trust on its CSP thus offering a customer-to-cloud trust perspective. Cross-cloud federation, however, presents a novel prospect of this approach by involving the notion of cloud-to-cloud trust. This perspective dictates the need for establishing trust between CSPs participating in the federation to enable a home CSP to place its customers’ data in other CSPs’ premises with confidence [58]. This transitivity of trust, i.e., user's trust on a home CSP and a CSP's trust on its sub-providers, makes cross-cloud trust paradigm more complex. It is a fact that behavior of federated service from a CSP is reflective of the behavior of multilevel sub-providers, unfamiliar to each other. A violation of contract by a CSP participating at any level of a federation can have a cascading effect on the performance of home CSP [59], thus affecting the user. Therefore, commitment with the user requires a home CSP to become part of a fully trusted federation.

Despite of extensive work on TMS for conventional and multi-cloud architectures, a void however, has been observed in trust evaluation for cross-cloud federation. This is because of the fact that multi-cloud architecture shares a certain set of similarities with conventional cloud computing regarding trust evaluation. Both of these models focus on facilitating the user regarding the selection of best trustworthy CSP. Moreover, these models deal with individual CSPs to form a single level and direct relationship with the user. Selecting one best CSP in the case of conventional clouds and more than one in the case of multi-clouds requires the same trust evaluation procedures. Therefore, the TMS employed in conventional cloud computing are applicable in multi-cloud architecture with little or no modification and vice-versa, but not in case of federation [15]. A detailed analysis and a comparative study of the existing trust models in cloud computing and exploring their applicability to the cross-cloud federation is the need of the day.

Trust management in cloud computing have always been reviewed from perspective of users’ trust on cloud provider. The earlier works in this area focused on the need and significance of users’ trust in cloud computing [6063]. Recent surveys [6470] have highlighted shortcomings of TMS based on the context of trust between a user and cloud provider. For trust management in inter-cloud computing model and its underlying architectures including CCF it is presumed that they inherit a same set of trust requirements as that of conventional cloud computing. To the best of our knowledge, the difference in trust requirements of customer-to-cloud and cloud-to-cloud trust perspectives has not been reported as yet. This survey establishes the uniqueness of CCF and thoroughly investigate the challenges of cloud-to-cloud trust paradigm. It also proposes to determine the difference in trust requirements of CCF so as to establish the relevance of already available trust models with CCF trust context. We argue and establish in this article that the overall requirements for trust evaluation in cross-cloud federation should stem from the general concepts in trust evaluation amalgamated with the specific requirements of cross-cloud federation encompassing the architectural and operational principles of federation.

The key contributions of this article are threefold and can be summarized as follows:

This article is further divided into six sections. Section 2 provides the overview of inter-cloud computing model. A detailed view of cross-cloud federation is presented in Section 3. Section 4 overviews the TMS highlighting all available mechanisms of trust establishment in cloud computing along with the general principles of trust as dictated by the nature of cross-cloud federation. Section 5 surveys the state-of-the-art prototypes in trust management for cloud computing. Section 6 presents a quantifiable analysis of referenced literature along with a matrix of consolidated requirements to achieve trust in cross-cloud federation. The aim of this section is to outline and briefly discuss different parameters of trust establishment affecting each other uniquely in the perspective of cross-cloud federation. Section 7 concludes the overall discussion.

2 INTER-CLOUD MODEL

The section first overviews the inter-cloud model in the perspective of its utility for high-performance and scalable computing needs. Afterwards, details of multi-cloud and federated cloud architectures are discussed to distinguish them on basis of their properties.

2.1 Overview

Cloud computing has seen enormous evolution since the time of its inception. The standard model of cloud computing [1], in which a client uses a single distant cloud data center and poses numerous challenges related to connectivity, availability, latency, location, jurisdiction, and integrity of data. Unavailability of cloud services due to network or data-center failure, for instance, can leave thousands of customers without access to critical services. Recent years have seen an increased dependency on the cloud with the soaring amounts of data being generated and uploaded by every user. Utility of this data ranges from large-scale storage and high-performance computations to real-time decision support systems utilizing intelligent technologies like Internet of Things (IoT), V2X communications and Augmented Reality (AR) etc. For this reason, depending on a single distant cloud provider proves hard to provide sufficient responsiveness and dependability to customers spread across the globe. This has diverted the focus of research to enhance the basic model of cloud computing for accessibility, elasticity, reliability and enhanced QoS. Cloud computing landscape is now filled with Edge Computing (EC) and inter-cloud models to support a variety of autonomous and intelligent systems respective to their needs. Both these models share a set of similarities derived from conventional cloud computing, but they are not a replacement to each other.

The concept of edge computing is to bring the cloud in the proximity of user. This can be done by implementing a limited cloud-like functionality in the edge devices like routers, switches, base stations etc. These mini-clouds, linked to their parent clouds, act on the data generated by user aimed for a prompt decision support, e.g., in an autonomous vehicle or healthcare. The data is aggregated and analyzed, and after the decision, less data is ultimately sent from the edge to the core network for further analytics. Currently, there are three implementations of edge computing, namely (i) fog computing, (ii) Mobile Edge Computing (MEC), and (iii) cloudlet. However, the lack of standardization affects the classification of features of each of these implementations [71].

The edge computing technologies mostly complements the IoT systems and smart devices in terms of responsiveness in decision-making. The infrastructure or devices employed for edge computing are not comparable to their core counterparts both in terms of functionality and in terms of computational prowess. Edge computing has its shortcomings in case of storing and computing large scales of data such as high-performance computing with no real-time requirements. To enhance the capability of conventional cloud computing for such type of data, usage of multiple clouds as inter-cloud model has appeared as a de-facto resolution. A few seminal works [7275] state different circumstances in which the usage of multiple clouds can be taken to advantage. Inter-cloud terminology has also been termed as “cloud of clouds” [76] and as “Cloud Fusion” [77]. A formal definition of inter-cloud model is given below [2].

“A cloud model that, for the purpose of guaranteeing service quality, such as the performance and availability of each service, allows on-demand reassignment of resources and transfer of workload through an interworking of cloud systems of different cloud providers based on coordination of each consumer's requirements for service quality with each provider's SLA and use of standard interface.”

The inter-cloud model facilitates consumers to engage various cloud providers for distribution of their workloads in order to attain the benefits that include (i) multiple geographical locations, (ii) application resilience, and (iii) avoidance of vendor lock-in. CSPs can also have significant incentive from participating in inter-cloud architecture, e.g., in terms of resource elasticity. Ensuring enough resources by over-provisioning at all times for unanticipated workload spikes is always costly in terms of price and power consumption of data center. Keeping excessive resources in a ready state all times lead to increased Capital Expenditure (CAPEX) and Operational Expenditure (OPEX). Cloud providers can use the inter-cloud for on-demand expansion and to transfer their excess workloads to other clouds when required. This can also lead to improved SLA between customers and cloud providers as it is known that workloads can be shifted to other clouds in case of data center outage or resource scarcity.

2.2 Inter-Cloud Architectural Classification

Inter-cloud model can be broadly categorized into two types of architectures, (i) multi-cloud and (ii) federation, as shown in Figure 1. Basic differences between both the architectures are summarized in Table 1 and are elaborated in the next subsection.

Fig. 1.
Fig. 1. Inter-cloud architectures. (a) Multi-cloud architecture; (b) Federation architecture.
Table 1. Differences between Multi-Cloud and Federation Architectures
Criteria Multi-Cloud Federation
Service Providers Multiple Multiple
Portfolio Independent Collaborative
Provider Interconnection None Static (Horizontal) Dynamic (Cross-cloud)
Service Composition Single level (i.e., customer to CSP) Multilevel
Service Junction Cloud Delivery Platform (Service/Libraries) Federation entry point (Home cloud)
Service Agreement Multiple (per cloud based) Single (Home cloud)
User-Provider Relationship Dynamic Static
Provisioning Customer or its representative service Home cloud
Scheduling Multi-cloud API's Transparent to user

2.2.1 Multi-Cloud Architecture. Multi-cloud architecture advocates the use of various independent CSPs to facilitate a consumer and results in a relationship governed by individual agreements of respective clouds. Cloud consumers can avail diversity in their services in terms of both vendors and location making their businesses more flexible to policies, availability requirements and governance. To fully reap the benefits of multiple clouds, different architectural patterns [78] are proposed in literature for distributing resources among multiple cloud providers. These patterns can be identified as (i) replication of application, (ii) multi-tiered applications, (iii) logic fragmentation, and (iv) data fragmentation. These patterns are elaborated in the Figure 2 .

Fig. 2.
Fig. 2. Architectural patterns for multi-cloud deployments. (a) Replication of application, (b) Multi-tiered applications, (c) Logic fragmentation, (d) Data fragmentation.

Fig. 3.
Fig. 3. Multi-cloud architecture classification.

However, application-specific requirements should not be violated when utilizing these patterns. Appropriate methods for resource provisioning and scheduling must take care of the application requirements in terms of performance and control [2]. These methods usually fall in the category of application brokering. Resource provisioning, scheduling, data and application security, and the like are the direct responsibility of cloud consumers or their representative service. Application brokering for multi-cloud can be broadly categorized into two sets of mechanisms as shown in Figure 3:

  • Services: Application provisioning is the responsibility of a service at client side. This service may be hosted within the client premises or externally. Several inter-cloud services include OPTIMIS [79], Contrail [80], mOSAIC [81], STRATOS [82] as ongoing research projects. Commercially available services include RightScale [83], EnStratus [84], Scalr [85], and Kaavo [86] as notables among many others.
  • Libraries: Most of the time, it is required to embed the brokerage functionality into the application. Such brokers can directly manage the application provisioning and scheduling across multiple clouds. This approach may use inter-cloud libraries such as the LibCloud [87], JClouds [88] and DeltaCloud [89] etc.

2.2.2 Federation Architecture. Contrary to the multi-cloud, interconnecting and sharing infrastructures of two or more cloud providers is called cloud federation. This concept offers the advantages such as traffic load balancing and accommodating unusual spikes in resource demand [75, 79]. In cloud federation, cloud providers can lease their vacant resources to other cloud providers such that the leased resources act as a temporary portion of buyer's infrastructure.

Cloud federation is beneficial to cloud providers from two perspectives. First, it is helpful in generating revenue out of idle or underutilized resources. Second, it allows CSPs to accommodate unusual spikes in resource demand by expanding without making heavy investments in infrastructure. The basic idea of federation is to provide transparent access to a number of resources and services that are distributed among multiple independent providers. As an important aspect of federated services, customer-facing SLA must be extended somehow to service partners. Usually, a cloud federation is realized in the following two ways [3]:

  • Horizontal Federation. Two or more CSPs come in contact with each other for the price and usage provisions agreed beforehand, to facilitate resource exchange and service composition. It allows CSPs to share information related to infrastructure, behavior and QoS leading to better trust assessment. There is no requirement for the discovery of resources as the relationships are static and long-term. However, it lacks scalability and diversity in service composition for dealing with varying demands of diverse application platforms.
  • Cross-cloud Federation. It is realized when two or more unfamiliar CSPs come in contract with each other at runtime [4]. It is a dynamic and diverse offering advantage to CSPs for expanding their service footprints easily on varying platforms. Cross-cloud federation has several phases such as discovery (searching for candidate clouds/resources), matching (selecting the provider that closely matches the requirements), authentication (a context of trust relationship established between the selected clouds), and so on.

3 CROSS-CLOUD FEDERATION

This section first presents the overview of general characteristics and functionality of a cross-cloud federation. A real-time scenario of a working federation is presented to elaborate why, how and when relationships are formed within a CCF. Further a subsection presents a detailed insight on the most important concepts of Inter-layer and Intra-layer resource federation to lease resources. This section also reveals the details on how the federation is viewed, managed, and maintained by its participating entities. In the later subsection, all these basic concepts are employed to establish the uniqueness of cross-cloud trust paradigm.

3.1 Overview of CCF

In a cross-cloud federation, any event of resource lease triggered by a home CSP with respect to a specific consumer is termed as a transaction. All further resource leases that originate pertaining to this transaction are its sub-transactions. In a generalized approach, any transaction (or sub-transaction) passes through several phases, starting from the discovery of resources, matchmaking and authentication [4]. The discovery process finds resources required by a Home CSP from Foreign CSPs willing to lease their additional resources. Discovered resources must fulfill some minimum criteria, e.g., QoS parameters, location and/or availability at any given duration of time, and so on. Once a set of resources meeting the minimum requirements are found, the best matching resource is selected and negotiated for terms of use. The process of authentication is then carried out to establish a relationship context between the CSPs. The basic properties of a cross-cloud federation can be summarized as follows:

  1. Highly Dynamic Structure. Relationships between CSPs are short-term and frequently updated. The underlying structure of federation is therefore highly dynamic.
  2. Multilevel Composite Service Formation. Service contracts and composition occur in layers, forming new contracts hierarchically linked to their parent contracts. A violation of any provision in a subset of contracts may affect other dependent services in a cascading manner such that the overall service composition is affected.
  3. Heterogeneity in Service Providers. Different clouds joining the federation may have different infrastructure, security requirements, and contracting languages [72, 90]. This offers the benefits of diversity and scalability in service composition.

Cross-cloud federation has its utility across a number of different application domains, ranging from research & academia, engineering & construction, financial industry, real-time data processing, and online gaming, to name a few. For example, consider the case of Massively Multiplayer Online Games (MMOGs). A large number of players across the globe uses these MMOGs to become a part of a huge and dynamic virtualized world. However, due to the high workload variability with stringent QoS requirements [91], implementation of a highly scalable MMOG service is definitely an enormous challenge. Traditionally, aggressive over-provisioning of resources is used for MMOG services to handle the worst-case scenarios [92]. However, a large portion of these resources remains unused at all times. Any typical MMOG service can benefit from cross-cloud federation in order to alleviate the need of aggressive overprovisioning for achieving better scalability. Such a scenario can be further elaborated by considering a MMOG service hosted in a cloud, which is a part of cross-cloud federation made up of four CSP as illustrated in Figure 4.

Fig. 4.
Fig. 4. A cross-cloud federation supporting MMOG application.

Each CSP in the federation owns a set of distinguished virtualized resources within their infrastructure. A consumer ‘n’ (Individual / End User / Enterprise) has signed a contract SLAn with one of the CSPs in federation against the MMOG service(s) offered by that CSP. This SLAn contains various threshold bound parameters related to QoS, e.g., maximum latency, network availability, user limit, and the like, serving as a guarantee to the performance of that CSP. This CSP now acts as a home CSP while other CSPs in the federation are Foreign CSPs with respect to that consumer. Among all CSPs in the federation, the only entity bound to provide a guaranteed gaming experience to user is the home CSP. No foreign CSP in the federation is by any means liable to provide direct service delivery to the consumer and hence not accountable to the consumer.

In this figure, the home CSP is unable to provide a guaranteed MMOG service delivery to the End User with SLA1 at any point in time ‘t’ due to resource scarcity. For this reason, it must lease resources from its federated peers after signing a SLA with them. This SLA must be a subset of the contract signed between home CSP and End User [4, 5]. In this illustration, the home CSP has leased resources from foreign CSPs A and B, after signing sub-contracts as ‘SLA1-a and ‘SLA1-b with CSP A and B, respectively. Both CSP A and B are now legally bound to provide the contracted resources to the requester CSP A not violating the parameter thresholds mentioned in ‘SLA1-a and ‘SLA1-b for an upright performance. Further, at any point in time “tn+1, to maintain the service delivery parameters mentioned in the ‘SLA1-b, foreign CSP B feels the need to lease a set of resources from CSP C. Another SLA is to be signed between B and C as ‘SLA1-b-c being a subset of ‘SLA1-b, thus forming a hierarchy of service contracts within the federation. All concepts related to CCF explained in the further sections refers to the scenario of Figure 4.

3.2 Core Concepts of CCF

Following the illustration in Figure 4, we have identified three core concepts that are necessary to develop a comprehensive understanding of the CCF. The first concept is the ‘Federated resource’, which describes how resource leasing or borrowing takes place between CSPs. The second one is ‘Federation visibility’, which defines how a federation is perceived by different actors within the CCF. The third one is the ‘Federation management’, which discusses the architectural choices for all underlying mechanisms within the federation. Details of these concepts are as follows:

Federated Resource. Cross-cloud federation presents a complex scenario of sharing resources at each layer of the cloud service model [93, 94]. A federated resource is the type of resource [3] being leased in any transaction. This concept relates to the formation of composite services from different CSPs. Figure 5 illustrates the concept of inter-layer and intra-layer resource federation [94] between a home CSP and a foreign CSP. Both CSPs have the same software or application layer (SaaS) at the top, the middleware layer (PaaS), and the OS and infrastructure layer (IaaS) at the bottom.

At the home CSP, a service, e.g., an application request, is bound to be fulfilled as long as it is within SLA criteria. Users access the application layer of the home cloud, which evaluates the abundance of local resources to serve the requests within the SLA limits. If the application layer is unable to serve the request as per SLA, it forwards the request towards the foreign CSP hosting the same service. This phenomenon is indicated by a line from the home cloud to the foreign cloud in Figure 5 and is called intra-layer federation.

Fig. 5.
Fig. 5. Inter-layer and Intra-layer resource federation.

Fig. 6.
Fig. 6. Operational architectures for cross-cloud federation: (a) Centralized, (b) Peer-to-peer.

The same is the case while federating services at any layer of the cloud service model. However, in a case when the foreign cloud does not host the same application, the request can be delegated to the lower layers. For instance, the SaaS layer can forward the request to PaaS layer, which means provisioning necessary platform software to host the application. Similarly, if that is not feasible, the PaaS layer can send a request to IaaS layer to deliver raw virtual machines so that necessary platform software can be installed. This concept is known as inter-layer federation.

Federation Visibility: A very important concept at the core of cross-cloud federation is federation visibility. Different actors in the federation may have different perspectives of the federation. For example, end users have a limited visibility level, which means that they can access and visualize the cloud federation as a single entity. Different levels of federation visibility are as follows.

  1. End Users. Have a limited visibility level just to access and utilize services.
  2. Enterprise. Obtains resources and services from the cloud and offers them to end users in a transparent way.
  3. Developers. Their visibility is restricted to the APIs provided by their home CSP.
  4. Cloud Service Providers. They have complete visibility of the federation to which they are a part. However, CSPs may or may not share details regarding their internal infrastructures.

Federation Management. The entire process of resource leasing can either use P2P [4] or centralized [95] mechanism for discovery and shortlisting of resources before finalizing a resource exchange. Hence, from an architectural perspective, a federation can be managed in either of these two ways [2], i.e., Peer-to-Peer (P2P) or centralized as shown in Figure 6.

In P2P mechanisms, clouds communicate, negotiate, and exchange resources with each other using their inbuilt agents and without any third party involvement. The basic problems of discovering and exchanging resources may be solved using the concept of presence from Session Initiation Protocol (SIP), Instant Messaging and Presence Service (IMPS) and the Extensible Messaging and Presence Protocol (XMPP) as suggested by Celesti et al. [4]. However, establishing a trust context between peers may require a centralized trusted Identity Providers (IdPs) to facilitate authentication.

In centralized federation, a central entity such as a broker is responsible to facilitate resource exchanges among CSPs. This entity operates as a repository to keep an inventory of available cloud providers’ resources. A traditional cloud broker as defined by National Institute of Standards and Technology (NIST) [1] is “an entity that administers the use, performance and delivery of cloud services” by negotiating a relation among CSPs and customers. Previous research on conventional cloud computing has strongly advocated the use of a cloud broker following the same explanation [9698]. However, this description of a broker requires reconsideration with the advent of cloud federation and its increased adoption by service providers for enabling composite services [99]. Recent work emphasizing the necessity of brokerage for cloud federation includes a comparison of brokerage frameworks by Massimo et al. [3], a collaboration framework for federation by Demchenko et al. [100] and inter-layer federation architecture [94] along with a survey of federation challenges by Toosi et al. [101]. The utility of brokerage in cloud federation has been established in recent works by Buyya et al. [73, 102] and in a broker based cross-cloud federation manager [95].

3.3 Cross-cloud Trust Paradigm

Despite the benefits that can be availed from a cross-cloud federation, CSPs are hesitant to contribute in it, mainly due to the lack of confidence and trust among the participants of federation [5]. Trust establishment has been a major concern in cloud computing and a lot of research has been done for TMS. The reason is that consumers primarily doubt CSPs’ intentions and trueness instead of mistrusting their capabilities [9]. Moreover, consumers’ hesitation for cloud adoption is due to the fear of losing control over their applications and data entrusted to their cloud provider [68]. Therefore, the research on trust establishment in cloud computing has always attributed itself for attaining consumers’ trust on a CSP.

Trust management is also necessitated in multi-cloud architecture [53]. However, the TMSs in multi-cloud architecture lack diversity and have been mostly the same as that of conventional cloud computing. The fact is, that multi-cloud architecture shares many similarities with conventional cloud computing regarding trust evaluation. First, both types of TMS focus on facilitating the consumer for the selection of trustworthy home CSP. Moreover, these TMS deal with individual CSPs to form a single level and direct relationship with the consumer. In any case, selection of one or more than one home CSP requires the same underlying trust management techniques. Hence, it can be safely stated that the TMS employed in conventional cloud computing are applicable in multi-cloud architecture with little or no modification and vice versa [58]. However, the case for trust management in cross-cloud federation is unique in its own due to the properties of such federation as discussed in the previous subsections.

Cross-cloud federation offers the perspective of transitive trust, i.e., a consumer's trust on its home CSP, and the home CSP's trust on foreign CSP(s) [5], as depicted in Figure 7. This transitivity issue must be considered while addressing the problem of trust management in cross-cloud federation. We propose to reduce this transitivity by splitting the problem of trust in cross-cloud federation into two distinct trust dimensions, i.e., consumer-to-cloud trust and cloud-to-cloud trust paradigm. The cloud-to-cloud trust paradigm dictates the need for establishing trust between CSPs participating in the federation. It is a fact that behavior of a federated service from a CSP is reflective of the behavior of its sub-providers. A violation of contract by a foreign CSP can have a cascading effect on the performance of home CSP [59], eventually causing distrust with the consumer. This is why we argue that addressing the concerns of cloud-to-cloud trust paradigm is sufficient to address the problem of transitive trust in cross-cloud federation. A home CSP, when confident with foreign CSPs for entrusting its consumers’ data can then safely provide guarantees of trustworthy service delivery to the customer.

Fig. 7.
Fig. 7. Transitivity of trust in cross-cloud federation.

Fig. 8.
Fig. 8. Abstract illustration of composite trust.

Despite of extensive work on TMS in cloud computing, a void however has been observed in addressing the challenges of cloud-to-cloud trust. Based on the unique formulation and properties of CCF, it is of utmost importance to establish the uniqueness of cloud-to-cloud trust paradigm over its consumer-to-cloud counterpart. Once recognized as unique paradigm, this will lead our exploration to observe the already available research for being able to address these concerns. Otherwise, an alternative would be to devise newer methods or align the already available ones to the underlying concepts of CCF.

We have identified four founding principles that make up the cloud-to-cloud trust paradigm, namely (i) trust bi-directionality, (ii) composite trust, (iii) delegation control, and (iv) resource awareness. The basic concepts of these principles and their necessity in the cross-cloud federation is described as follows:

  • Trust Bi-Directionality. Conventional TMS facilitate the consumer to identify the trustworthy CSP but a CSP is never interested in knowing the trustworthiness of a consumer. Cross-cloud federation, similarly, implies that a home CSP identifying trustworthy foreign CSPs to place its consumers’ data and application. However, in such a case, foreign CSPs are also faced with an increased threat. They might never know or control the ownership and manipulation of any data and applications that is residing in their premises. Thus, we argue that, in cross-cloud federation, there is a need for the bi-directional trust relationship, i.e., the home CSP's trust of foreign CSP and vice-versa.
  • Composite Trust. Federated clouds combine resources from multiple providers to form a composite service. To better understand the concept of composite service, and in turn the concept of composite trust, consider the following example. The end user service is delivered as SaaS application from its home CSP. This application has been compiled by combining services from foreign CSP A and B. CSP B have its PaaS delivered by CSP C and IaaS delivered by CSP D. An abstraction of this relationship is depicted in Figure 8. In such a scenario, the home cloud is entirely responsible for up-to-the-mark service delivery to the customer. Therefore, only the knowledge of individual trust levels of every CSP may not suffice. An evaluation of trustworthiness for this composite service in its entirety is necessary to predict its performance in the course of time.
  • Delegation Control. In scenarios of collaborative computing such as cross-cloud federation, trust should not be unilaterally delegated [103]. To understand the concept of trust delegation, consider the MMOG scenario from Figure 4. The home CSP relies on resources from the foreign CSPs A and B for delivering a composite service transparent to user. After a brief period, CSP B leases additional resources from its trusted peer C such that C would be actively involved in service composition. In such a scenario, this trust relationship of B with C does not and should not imply that the users’ data entrusted to CSP B via home CSP can be delegated to C without the knowledge of home CSP and user.
  • Resource Awareness. The concept of composite trust is complemented by resource awareness within trust assessment. A cloud provider may lease different types of resources with different settings, e.g., storage, compute, and so on. Trust as a value of global assessment of a CSP is not recommended for fine-grained evaluations. Each resource must be individually assessed for its trust value in addition to its provider's trust level.

Existing TMS do address the concerns of consumer-to-cloud trust, but their applicability to CCF is still a question that needs elaboration. We argue that a suitable TMS for cross-cloud federation is the one that addresses the above-mentioned challenges of cloud-to-cloud trust paradigm. Trust management systems in conventional and multi-cloud computing environment lack methods that align with the respective properties of cross-cloud architecture. A further deliberation on the trust management techniques may be helpful to provide insights on developing an appropriate trust management solution for cross-cloud federation.

4 OVERVIEW OF TRUST MANAGEMENT SYSTEMS

This section aims to deliver an overview of the TMS and their general attributes. It discusses three prevailing methods of trust realization, i.e., hard, soft, and explicit trust. Beginning with the basic concepts of trust from different perspectives of life, this section highlights the prominence of TMS. This discussion is followed by an overview of various components of a TMS and its basic properties are discussed from the perspective of cross-cloud federation. The basic aim of this discussion is to highlight the functionalities of these underlying methods and discuss why they need to align to the four foundation principles of the cloud-to-cloud trust paradigm.

4.1 Basics of Trust Realization

Trust is a complex social phenomenon and is a critical factor of everyday life. The detailed explanation and semantics of trust have always been investigated in conjunction with the context in which the trust phenomenon is being applied [104, 105]. There has been some significant definitions of trust, mostly in context of Sociology [106109] and a few in terms of Philosophy [110], Economics [111], Psychology [112, 113] and organizational management [114]. From a consolidate view point, trust can be a factor of

  • Expectation. A specific behavior is expected from the trustee.
  • Belief. The expected behavior will occur, as evident from the trustee's performances.
  • Risk . The belief is worth taking a risk.

Trust in an entity has always been considered a measure of assessment to act as a base of decision-making as to what extent the entity will behave as expected. Trust realization approaches can be categorized into three schools of thought as follows: (i) Trusted Computing or “hard trust”, (ii) Application oriented or “explicit trust”, and (iii) Trust Management Systems (TMS) or “soft trust” approaches.

Hard Trust. In this approach, service platforms are considered as “trusted” if they have a provable existence of certain security primitives. Trusted computing allows the customer to verify that CSPs do not tamper with VMs. These approaches suggest relying on a Trusted Third Party (TTP) for implementing a hardware-based Trusted Platform Module (TPM) within the computing infrastructure of service providers [115]. However, as the original TPMs are developed for the physical hardware, their applicability to virtual environment is challenging. This shortcoming is overcome by developing virtualized TPM specifications (VTPMs) [116]. These can be implemented as software based TPMs for each VM running with the CSP. Recent works by Santos et.al [117], Krautheim [118], Schiffman et al. [119], and Sadeghi et al. [120] are representative of hard trust approaches. However, in general, hard trust approaches focus on the evaluation of individual platform, and therefore are not applicable on composition of multiple providers [45]. Moreover, many obscurities arise due to the nature of these approaches that can only be addressed by using dynamic trust models [121].

Explicit Trust. This approach implements the protection mechanisms on the end user platform. This ensures that user information is submitted to the service provider in such a manner that creates obscurity. These approaches utilize cryptographic techniques as their underlying mechanisms and are as follows:

  1. Secure multi-party computation is one of the frequently used mechanisms in cryptographic protocols. The Sharemind system is a good practical example of using this technique [122].
  2. Fully homomorphic encryption [123, 124] is a recent technique which enables arithmetic operations on the data that is encrypted using any cryptographic method. The outcome from any such operation is obtained only when the result is decrypted. Mowbray et al. [125] provides a scheme for ensuring privacy in the cloud by obfuscating sensitive data.
  3. Data splitting is another “explicit trust” approach; however. it is not based on cryptographic mechanisms. The basic idea is to split data before submitting to different CSPs. Recent works for explicit trust includes RAIN by Jaatun et al. [126, 127], HAIL [128], and RACS [129], and the like.

Soft Trust. The soft trust approach involves aspects such as basic social sentiments, perceptions, and interaction experiences of human beings. This approach is based on the assumption that hard trust or explicit trust mechanisms are never perfect [60]. Recent surveys [5, 60] show that all schools of thought may have their own strong points for establishing trust on cloud providers. However, the feasibility of employing a trust mechanism other than soft trust in a large-scale cloud computing infrastructure is still a question due to its computational intensiveness [5]. Moreover, both the hard and explicit trust mechanisms enable the establishment of trust on a single platform, but not on the composition of entities [45] such as a federation. The next section discusses the TMS and their underlying soft trust mechanisms in detail.

4.2 Trust Management Systems

In the context of distributed and multi-agent systems, the concept of trust is mostly bound to “performance”, “security”, and “privacy”. These factors are represented in the form of trust models focusing on the formal definitions, semantics and modeling of trust. Trust modeling in distributed systems has its roots in the seminal works by Zadeh [131, 132], Shafer [133], Marsh [134, 135], and Josang [136, 137].

The most significant of these works for trust modeling has been done by Marsh [134]. He proposed a formal treatment of trust evaluation by integrating different trust concepts from sociology, social psychology, and philosophy. Recently, with the advent of decision support systems, context-dependent implementation of these models is observed in different types of distributed systems leading its way to the emergence of TMS. These systems have been observed in many environments including ad-hoc networks [138], multi-agent systems [139, 140], intrusion detection systems [141, 142] and wireless communication [143, 144]. Moreover, TMS usage has been reported in social networking [145], e-Market places [146148] and semantic web [149151]. Similarly, this phenomenon has been necessitated in earlier works for conventional cloud computing [6163, 130], multi-cloud [53], and federated cloud architectures [5].

In general, a TMS seeks to deliver a trust assessment as a representative view of the overall confidence in the ability of a system. Figure 9 shows a block representation of a TMS functionality involving entities like cloud consumer, cloud service provider, and trust management authority responsible for governing the overall system environment. A TMS is basically built on two fundamental components namely trust sources and trust methods. Trust sources include but may not be limited to certified assessments, policy matters, SLAs, recommendations, audit reports or third party monitoring, and the like. Trust indicators from these sources are passed to the second component hereby referred in the further sections as trust methods. Trust indicators are collected, aggregated and evaluated based on formal models of trust assessment within the trust method component. Afterwards, the evaluated trust result indicative of the overall assessment of the entity is disseminated for use, comparison, and update within the infrastructure [44, 66]. The overall functionality of the TMS and its underlying components is governed by a set of properties discussed in the next subsection.

Fig. 9.
Fig. 9. Generalized trust management systems architecture.

Fig. 10.
Fig. 10. Representation of TMS supporting (a) Trust bi-directionality and (b) Delegation control.

Fig. 11.
Fig. 11. Resource awareness support with (a) conventional requirements and (b) CCF requirements.

4.3 Trust Sources

Sources of soft trust are the origins of trust values based on human behavior, perception, and interaction experiences with the system. In this section, we classify trust sources into three categories based on their type of trust indications. From the following deliberation, we see that trust decision based on individual source may address one aspect of the trust but not the others. We argue that a viable solution is to implement all kinds of trust sources into the TMS to facilitate better trust decisions.

Recommendation as a Source. Recommendation is the most widely used source of trust in the grid [152], in service-oriented environment [153, 154], and also in cloud environment [44, 118]. Recommendations are of two types, namely, (i) explicit recommendation and (ii) transitive recommendation. Explicit recommendation is the one that is provided to a cloud consumer by a close and trusted relation (e.g., friends). It is also known as first-hand recommendation. On the other hand, transitive recommendation is the one that is received by cloud consumer from its trusted relationship, which in turn has received the same from another trusted source.

In the cloud federation model utilizing composite services, users are least concerned with providing feedback regarding participants of such a service. Contrary to this, the cloud providers that are leasing/borrowing resources from others must be the primary source of recommendation-based trust within the federation. This is one of the key differences that makes the problem of trust awareness in federation unique as compared to conventional or multi-cloud models.

Policy as a Source of Trust. Policy as a trust indicator is another way for trust establishment among various parties. Mostly, it has been used in grid computing [155], P2P systems [156], web-based applications [157], Service-Oriented Architectures (SOA) [158, 159] and also in cloud environments [18, 32, 117]. This approach utilizes the contract signed between the user and the CSP for security assurance and trust establishment. This contract, the SLA, may include maximum latency, maximum connected users, and the like related to QoS [51, 160, 161]. A major issue with the SLA is that it ignores essential elements such as security and privacy. However, a new trend to include security provisions or Quality of Protection (QoP) attributes [162] of encryption algorithm, key length etc. as a part of this contract is prevalent and is known as Security Level Agreement (SecLA). However, the uncertainty regarding the conduct of a CSP for keeping up with its contract is always prevalent [163].

In case of cloud federation, where an SLA-bound transaction between a consumer and its Home CSP may result in multiple sub-transactions, a hierarchy of SLAs may be signed between the participants of the federation. There are two challenges associated with this hierarchy of SLAs that affect how the same can be used for trust evaluation within federation. The first challenge is to represent and deliver the SLAs of sub-transactions as a subset of the SLAs of parent transactions. The superset of these sub-SLAs must be the SLA signed between the consumer and the CSP. The second challenge is related to heterogeneity in contracting languages of CSPs. Thus, evaluating these multi-level SLAs requires some mechanisms of homogenous SLA formalization [59]. This is one of the most aspiring challenges of cross-cloud federation.

Evidence as a Source of Trust. The terms and conditions as mentioned in the service contract serve the basis to measure the performance and security strength of a CSP and estimate the level of variation from the defined thresholds. These performance evidences may be used as a source of trust within the TMS [164, 165]. However, a major issue with utilizing evidence as a trust source is the lack of cloud users’ capability to monitor QoS parameters and verify SLA in a fine-grained manner [165]. Therefore, a trusted third party offering these services is mandatory for the cloud users to collect evidence. In case of private cloud, its own trust authority may perform this task. In public clouds, users and small organizations may utilize a commercially available entity to serve as a trust broker [166, 167]. Such a monitoring from third-party agents, brokers, auditors, and the like serve as an elevated level of confidence in the users.

4.4 Trust Methods

Trust methods are a collection of different operations and functions that are performed within a TMS to generate a comprehensive representation of the system's trust. As shown in Figure 9, the basic function of any TMS is to collect raw input in the form of trust indications from different sources and converts them into a representable form. Afterwards, information from all sources is aggregated before making them available to the trust evaluation function. This trust evaluation function is responsible to evaluate the resultant trustworthiness of the system based on formal trust models. This evaluation operation can be from one of two categories, i.e., static or dynamic. The static approach is a simple mathematical operation that does not cater to the evolving nature of the underlying system. However, the dynamic or adaptive operation involves a trust update function that allows the trust decisions to evolve with the nature of system. In case of highly dynamic nature of cross-cloud federation, adaptive approaches are highly recommended as federation participants can join or leave at any time.

The output of the trust evaluation function is often a numerical representation showing confidence in the provider. This result or trust assessment is then distributed or disseminated to the trust requester or the entire system. This assessment of a provider serves as a utility to the consumer and mode of governance to the authority within the system. A consumer can utilize this assessment for making a decision regarding service selection. After service contracts, a consumer acts as a source of trust of the indicator by providing a recommendation for the contracted service. This recommendation is again an input to the trust evaluation function, which may further be utilized to update the trust decisions regarding the same provider.

This trust assessment may serve as an input to the governance domain of any authority regulating the entire system. This authority may be a consumer itself or any Trusted Third Party (TTP) like brokers, accreditors, auditors, or certification authorities. The objective of such authority is to monitor and audit the providers for compliance to the policy requirements established with the consumer. This monitoring or audit reports serve as a source of evidence to report the overall performance of the cloud provider to the TMS.

4.5 Properties of Trust Management Systems

The overall functionality of a generic TMS is governed by a set of properties. These properties define the behavior of underlying components of any TMS. These properties are described as follows:

  • Objective. The basic objective of the TMS is to provide the consumer with a unique value reflective of the behavior of the service provider. This unique value may represent the trust, reputation, or both regarding a service provider. Trust and reputation are different but related terminologies. Trust is always context based and is held as a relationship goal between two entities. However, reputation is the accumulated public belief towards an entity. Trust and reputation go hand in hand with each other; however, few systems only account for one of these. The more dynamic the nature of the cloud services, the more important is the requirement for encompassing both in the system.
  • Context. Currently, TMS mainly focuses on the cloud customer's perspective, i.e., the user-to-cloud trust paradigm. However, federation architecture implies a cloud-to-cloud trust paradigm. It is therefore essential to differentiate a TMS, based on the supported perspective.
  • Visibility. In a multi-stakeholder collaboration environment, such as the cross-cloud federation, trust plays a somewhat different role. It is considered to facilitate cooperation, to render more robust collaboration, to boost performance, and to make innovations possible. This is only possible when trust decisions are openly visible within the environment in the local and in global perspective. Such an openness is necessary so that a trusted party must not unilaterally delegate the assigned task to other peers without apprising others concerned.
  • Security. A TMS must resist against malicious attacks and mischievous behaviors of both insiders and outsiders [168]. Potential attacks against the TMS include the whitewashing attack [169], self-promoting [170], and slandering attack [171]. An attacker can manipulate a TMS that lacks security and is easily penetrable. In case of federation, the attackers are most likely among the competing peers and are more resourceful than an outside attacker.
  • Accuracy. A TMS, by virtue of its trust evaluation function, must be accurate in computing the trust values. Accuracy can be determined by the ability of the function to disqualify malicious or illegitimate sources of trust indicators such as identification of legitimate feedback sources, and the like.
  • Privacy. A TMS must be sure to limit the degree of private and sensitive information of cloud consumer that might be disclosed intentionally or unintentionally during interactions. For example, a privacy breach of a higher degree exposing the cloud service consumers' user names, passwords, and dates of birth, and so on is as harmful as behavioral information, i.e., consumer and service interaction patterns, interests,. and so on. In case of cross-cloud federation, this risk is even higher when the trust management system is supporting clouds that are competing peers.
  • Control. Trust dissemination and control requires mechanisms of monitoring, audit, and enforcement of policies for compliance. The attributes that constitute the foundation of trust plays an important role in cloud service monitoring. These attributes can be used to observe that a provider behaved as expected. The TMS uses the conclusion drawn from this observation to revise the trust of the provider in question. The third-party-based TMS systems are far better than their peer-to-peer counterparts [95, 99] in terms of reliability, performance, and enforcement.
  • Scope. A comprehensive system must provide a fine-grained level of applicability. In this work, we anticipate three different levels for TMS aimed at cross-cloud federation. The highest view is that of cloud level, that means a cloud is considered as a single entity and its trust and reputation is evaluated. The second level is that of service level, i.e., IaaS, PaaS, and SaaS offered by the provider. The third level is the resource level, with each resource having its separate trust level. The more detailed a TMS is, the better and more fine-grained the decisions are.

5 STATE OF THE ART IN TRUST MANAGEMENT

This section highlights contributions to TMS for conventional and inter-cloud computing models. Each contribution has been categorized primarily based on the sources that are used in trust evaluation. Moreover, all work has been reviewed from the perspective of its applicability to cross-cloud federation, where relationships are cascaded, dynamic, and heterogeneous.

5.1 Single Sourced Trust Models

Models using Policy as a Source of Trust. Trustworthiness of a CSP can be evaluated using different QoS parameters as identified in [22]. These parameters are given a quantitative value that depends on the policies of the consumer, i.e., the signed SLA, but are then normalized to fall within range of (0, 1). The overall trust score of a CSP is then a weighted average of all these parameters, which is subjectively assigned by the respective consumer, hence lacking adaptability. Their trust evaluation framework facilitates the consumer to use the services of a third-party agent or evaluator for assessment of SLA parameters. The proposed model depends on a single source of trust estimation, and that too being the QoS parameters instead of QoP.

Audit assessment and accountability may also be used as a source of trust establishment as in TrustCloud framework [26]. The authors outline the risks arising due to the absence of accountability in cloud systems. Detective mechanisms are recommended instead of their preventive counterparts to increase accountability. The authors introduce the concept of file-centric activity logging above the system-centric activity logging. They have based their theory on the fact that nowadays end-users are less concerned about the clouds’ performance but focus more on integrity and accountability of their data. Using concepts from Cloud Accountability Life Cycle (CALC) and the abstraction layers of logs, both real-time and post-mortem approaches are equally important at different levels of granularity. A consolidated view is offered to the cloud users regarding accountability of the CSP, thus reducing the complexity of the task. However, the authors have not mentioned any method to evaluate trust on the basis of logs and auditability. Moreover, no methods have been outlined to propagate this audit and accountability information to other users or providers.

In another work, Habib et al. [24] suggested a framework for trust-awareness centered on the notion of verifying security controls, keeping in view the user requirements. The authors utilize the concept of trust properties as defined by the CSA self-assessment framework. The framework resolves the issues arising due to heterogeneity of cloud providers, thus providing the same trust metrics. The proposed work uses the mechanism of hybrid trust in which two types of trust mechanisms are used, i.e., hard and soft trust mechanisms. Both mechanisms are combined for verifying the trust attributes of the given CSP. Hard trust is a factor of security mechanisms within the CSP, whereas soft trust is an outcome of previous experience and performance related to any entity. Moreover, a decision model is suggested to facilitate users to establish trustworthiness of CSP. The authors have elaborated their notion on using soft trust mechanisms by extending their work [45] using the Consensus Assessment Initiative Questionnaire (CAIQ). This work establishes a Trust Management (TM) system for a cloud marketplace that provides flexibility in assigning a trust value to a CSP based on parameters selected by the users. The overall trust degree is uniquely represented as graphical output instead of a numerical score for easy comprehension of the cloud user. However, there is no detailed deliberation on how to actually combine different soft and hard trust mechanisms in the form of a unified assessment. Moreover, their trust model lacks the mechanisms to verify or enforce trusted relationship among participants.

Another framework [16] uses the concept of a trusted third-party-supported security auditing for establishing the users’ trust on CSP. The framework allows the CSUs to give their security preferences regarding their required services. The presence of security controls and internal security policies of CSPs are validated by a trusted Third Party Auditor (TPA). This TPA refers to the Security Trust and Assurance Registry (STAR) database of the Cloud Security Alliance (CSA) for this validation. This validation is performed by analyzing the CAIQ responses from the CSP, and afterwards the Security Control Validation (SCV) mechanism facilitates the validation of CAIQ controls. No detail on working of such mechanisms is provided by the authors and they anticipate developing various algorithms for their proposed framework.

Policy-Based Models with Multi-Cloud Support. The concept of the overlay network is employed in trust evaluation by establishing a trust-overlay network [14] built on top of multiple data centers. The objective of this trust overlay is to constitute a reputation evaluation system for trust establishment among CSPs and users by means of Distributed-Hash-Table (DHT)-based overlay networks. These networks belong to multiple data centers collaborating to manage trust and enforce security objectives. Data coloring along with software watermarking is proposed to safeguard data items and software components. These techniques support authentication for multiple participants, single sign-on, and access control provisions regarding data in private as well as public clouds.

Compliance management is another method to achieve trust in multiple clouds. Using the same strategy, Brandic et al. [21] has introduced an architecture called Compliant Cloud Computing (C3), which serves as a middleware to certify and audit applications before deployment. This middleware is able to select providers that comply with the user requirements. Moreover, it also acts as an enforcement engine for compliance-level agreements. The authors have also proposed a novel language in which compliance-related requirements could be specified regarding security, privacy, and trust. This language uses the domain-specific knowledge and compliance-level agreements to construct requirements. The C3 architecture utilizes the concept of composite services in which more than one cloud provider is participating. However, details regarding evaluation of such composite trust for these services is lacking in their architecture.

Models using Recommendation as a Source of Trust. Recommendation as source of trust has been used in a resource-aware trust model [12]. This model helps CSPs to allocate resources to customers based on a dynamic per transaction-based trust value. An entropy-based trust evaluation is used initially to evaluate trust of each resource before the resource is assigned to the user. After a transaction is complete, trust of the given resource is evaluated on the basis of user feedback regarding the subject resource. An adaptable trust evaluation method is used which updates the trust values for a cloud provider after every transaction. However, other methods of trust management like aggregation and dissemination, and the like, are not discussed.

Recommendations based trust has been the most common method of evaluation as it provides the social standing of any CSP. However, false feedbacks can seriously jeopardize the overall results of any trust management system. Distinguishing sources of feedbacks as reliable or malicious and categorizing them on the basis of their credibility is one way to deal with this problem. A “Trust as a Service” (TaaS) framework [30] by Noor and Sheng is an adaptive model for the purpose of credibility assessment, which is able to differentiate between feedback from reliable and malicious sources. This is performed by considering the consumers’ capabilities and reaching a consensus over its feedback.

Artificial-intelligence-based techniques for trust establishment is another less-visited perspective. A Genetically Modified Ant Colony Optimization (GM-ACO) [11] is proposed to build a list of Trust Metric Parameters (TMPs) with respect to CSPs. The proposed algorithm is based on the principles of Ant Colony Optimization (ACO) hybridized with Genetic Algorithm (GA). The proposed model distinguishes the trusted cloud providers based on the rules similar to those generated by ants in ACO. Moreover, the trust accuracy rate is also adjusted by optimizing the control parameters in GA.

In [13], the authors suggest the use of virtualization techniques to enforce security in cloud provider infrastructure. They propose to construct an overlay network based on a hierarchy of DHT. Access to data centers is controlled by their proposed reputation systems developed using this overlay network. Access to data at the file-access level is also limited using the same overlay network. Moreover, an architecture for cloud-based applications is proposed that utilizes several security mechanisms to strengthen the security and privacy in them. Their reputation system keeps a record of security lapses at all levels of access. Both cloud users and cloud providers can equally benefit from the proposed architecture.

A trust management system based on the fuzzy set theory has been proposed in [41]. The authors propose utilizing user recommendations from their interaction with a cloud provider as the source of trust. User recommendations are distinctly evaluated as direct and indirect feedback. The idea of trust chaining is introduced along with a method to prevent the behavior of cheating middle nodes.

Recommendation-Based Models with Multi-Cloud Support. Evaluating recommendations in a multiple cloud scenario introduces the concept of domain-based trust evaluation. The same has been employed in a model [50], in which both the customer and CSP are can select services and resources from heterogeneous domains. When a customer initially avails resources from a CSP, it utilizes recommendation-based trust from its familiar CSPs to evaluate the trust value. When a transaction is finished, it updates the trust value and revises the recommendation score of respective CSP. CSPs depend on their trust agents of their respective domains to manage trust values for them. These agents store and maintain the domain-specific trust scores in a table. This trust score is utilized whenever a CSP cooperates with other CSPs, provides service to customers, recommends trust, and so on. However, the research does not explain the mechanism for evaluating trust and its components; rather it just focuses on the establishment of the method to propagate trust in case of multiple collaborative clouds.

Another scheme facilitating cloud providers to cooperate and share resources with each other based on reputation score is presented in [49]. Recommendations from peer cloud providers are used as a source of reputation. Two functions are proposed based on beta reputation system for selecting the highly reputed collaborator. The first one is the node ranking schema and the other one is the node selection strategy. In node ranking, every action of the node is evaluated and ranked as either being satisfactory, unsatisfactory, or nothing. Afterwards, any random node is selected or, otherwise, the highest reputed or probabilistically reputed node is selected. This scheme does not take into account the multi-level nature of services that form as a result of cooperation. Although this scheme takes into account the reputation collection from peer clouds, mutual trust and delegation are not considered. Also, it does not take into account the security threats arising from fake reputation scores as the participants are peer clouds.

Evidence as a Source of Trust. QoS parameters are also used to predict the behavior of various resources before they are provisioned to a user on its request [35]. This prediction model is based on historical information regarding stability and availability of the cloud provider's resources that are required by the user. Performance indicators from the prediction model are used as the foundation for the trust evaluation model, which gathers the best available resources in advance to better serve the user's request. Their model, although being a multiple-attribute method, utilizes a manual method to allocate weights to trust parameters. These parameters were set as the same value, i.e., 0.25, thus lacking adaptability in evaluation of trust attributes.

5.2 Multi-Sourced Trust Models

Trust Models with Supportive Evidence. The concept of the D-S evidence theory along with the sliding window is extended for a trust and reputation evaluation model in cloud computing [42]. The dynamic interaction of both the Cloud Subscriber (CS) and the CSP is evaluated as evidence-based direct trust by the D-S evidence theory. Evidence as a result of interaction is considered to decay over time. Hence, the sliding window is used to reflect the timeliness value of the interaction evidence. The value of the recommendation trust collected from various entities is considered as second-hand evidence. Conflicting recommendations are combined using the subjective weight assignment method and are treated as the reputation score. However, this approach insufficiently describes the relation of interaction evidence to the reputation trust value.

The various trust parameters of the security, availability, and reliability paradigm has been utilized as a source of trust, thus creating an adaptive trust model called Cloud-Trust [36]. The proposed model uses an objective mechanism for evaluating the performance of cloud services in complying with SLA guarantees. Users record their interactions with CSP rather than providing their rating through feedback. The proposed Cloud-Trust model is used to define, collect, and analyze various trust parameters of CSPs and performs knowledge discovery over numerous trust parameters. The proposed solution is proven efficient in case of dynamic service behavior; however, it does not cater to multi-level agreements for composite services. The proposed model is not suitable for federated clouds, as it does not resolve the issues related to heterogeneity of cloud providers within the federation. Moreover, their entire model revolves around the compliance and monitoring of SLA signed with the end user or with the customer, which is not possible in federation.

A Trustworthy Service-Oriented Architecture (TSOA) can be achieved in cloud environment by enforcing mechanisms of robust accountability [18]. The design for such a TSOA separates the service space of cloud into two distinct domains, namely (i) Accountability Service Domain (ASD) and (ii) Business Service Domain (BSD). Accountability is incorporated in all business-related services and their respective processes. They log irrefutable evidence in ASD that is analyzed by the Accountability Service (AS). This evidence is validated against the business logic and respective SLA registered by the same business service. Any business descriptive language can be used to incorporate this accountability into the business process and can be automated with little or no impact on the implementations of the business process.

Neural networks have been employed to forecast the trust of cloud-based services in [28]. The authors extend the Particle Swarm Optimization (PSO) technique as PSO-NN to optimize initial settings of the neural network. This is done by finding suitable parameters for the neural network in order to forecast trust of services with much accuracy. The accuracy of their algorithm is evaluated in case of different numbers of training data sets and training times.

Another method of utilizing evidence collects dynamic performance parameters of the providers’ services and correlates with the fuzzy QoS requirements of the user as presented in [48]. The system architecture involves two basic steps to be performed. The first step is to capture the users’ subjective opinions regarding a service and its different QoS attributes. This can be achieved through methods of fine-tuning fuzzy membership functions. The second step covers the entire process of application deployment. This may include submission of requirement, discovery of service, trust evaluation, selection of service and finally the deployment. User requirements are fed to the system using a web interface. The Discovery Service fetches the services in accordance with the users’ functional and QoS requirements. The trust evaluation service calculates the trust levels of the matching services. Afterwards, it takes the user requirements and the historical performance of all services to deliver candidate services along with their respective trust values. A Cloud Benchmark Service (CBS) is used to observe the performance of cloud providers and the results are published publicly.

Operational architecture of a trust label system anticipated to act as a TMS for cloud services is presented in [31]. The proposed system is developed using Delphi methodology [172] and specifies a range of important metrics for communicating cloud trustworthiness to CSU. However, this article demonstrates the use of Service Execution and Data Management metric groups only. For a data management group, the authors present a location control model which helps consumers to specify locations where they want to store their data. The execution metric group provides service-level monitoring using a service monitor framework. This framework is composed of various tools to monitor different metrics and to communicate the monitored data to the trust label interface. Integration of all these modules to support trustworthiness computation is anticipated by the authors in [31].

Monitoring the QoS parameter is the most significant method of trust evaluation. The authors in [43] suggest exploiting the correlation between QoS attributes to significantly resolve issues like predicting missing assessments, detecting malicious feedbacks, and improving the accuracy of trust values. They propose to use the Naive Bayes model and the n-gram Markov model to design a more efficient trust model for cloud environments. The trust model initially takes into account the user's requirements as a base to evaluate trust. Afterwards, the qualitative and quantitative assessments of the cloud provider by the user is aggregated.

Trust Models with Supportive Evidence for Multi-Cloud. Li et al. [56] have presented a service-brokering scheme, called T-broker, for selecting trusted service from multiple CSPs in a collaborative cloud environment. Their scheme has a trusted third-party-based broker, the T-broker, that facilitates trust management and service recommendations for users. The T-broker uses an adaptive model for evaluating the trustworthiness of resources from CSPs. Their adaptive model combines the result from the real-time monitoring with the feedback given by the user regarding the performance of a given resource. However, T-broker does not elaborate mechanisms for dealing with heterogeneity in contracts of different CSPs. Moreover, this scheme employs user feedback, which is not the case with the cross-cloud federation.

Contrary to the centralized trust management system as mentioned above, utilizing distributed Trust Service Providers (TSPs) for multi-cloud architecture has been proven beneficial [54]. These TSPs are distributed among CSPs and gather trust values from different sources regarding the compliance of a CSP to its offered SLA and feedback from CSUs. The proposed model is a two-layer architecture consisting of both subjective and objective trust models having local and global trust values for each resource. The trust evaluation model then relies on the trust propagation network for distributing the trust evaluation results among all TSPs. However, this model uses the traditional subjective probability method for direct trust evaluation, rather than direct service behavior. Moreover, this model utilizes the user feedback for cloud-to-cloud trust evaluation, which does not suffice in the case of dynamic and multilevel relationship formation. The mechanism of combining both direct trust and indirect trust has not been discussed in detail. Therefore, nothing can be concluded regarding the adaptability of this model to dynamic service behaviors.

A middleware framework for Service Operator-aware Trust Scheme (SOTS) [55] is used for discovery of matching resources in multiple clouds. Trust evaluation is modeled as a Multi-Attribute Decision-Making (MADM) problem. Their proposed trust evaluation approach is adaptive and is based on information entropy theory. A centralized broker is responsible for making trust decisions and offering resources based on users’ trust and functional requirements.

A TMS for Opportunistic Cloud Services (OCS) involving evidence from SLA-based monitoring is proposed [46]. This TMS involves five operations, namely expectation, data monitoring, data management, analysis, and decision making. The expectation operation is same as signing an SLA with the user having all the service-related attributes. This SLA is then used as a baseline by the data-monitoring function to monitor the performance of service. The data-management function is responsible for collecting evidence data and then forwarding the data to the analysis and the decision-making functions. The proposed TMS also takes into account the recommendations for the cloud provider to define a context-dependent trustworthiness computation. However, their trust evaluation approach is not identified as being adaptable in highly dynamic nature of cloud computing. Moreover, the functionality of OCS is defined as being similar to that of the cross-cloud federation; however, they still consider the non-hierarchical methods of trust aggregation, evaluation, and dissemination trivial.

A trust establishment framework resilient to collusion attacks is proposed in [57]. Initial trust values are assigned using a bootstrapping mechanism. Also a trust-based hedonic coalitional game is proposed that enables different providers and their services to form distributive trustworthy multi-cloud communities. Trust establishment is based on a polynomial-time services discovery algorithm that enables services to inquire about each other's behavior based on their tagging in online social networks. A trust bootstrapping mechanism is then used that combines both this endorsement mechanism in social network with the decision-tree classification technique. This results in initial trust values to be assigned to the newly deployed services. A trust aggregation technique is then proposed that uses the Dempster-Shafer theory [133] of evidence. A credibility update mechanism is used to ensure that trust results are accurate even in case of collusion attacks. Afterwards, the multi-cloud community formation is modeled as a trust-based hedonic coalition formation game. The article identifies their trust management solution viable for federation and service formation involving multiple clouds. However, their approach is more inclined toward multi-cloud architecture as it does not involve hierarchical service formation, which is a unique characteristic of federation.

Trust Models with Policy and Recommendation as Sources. An SLA-based trust model utilizes third-party intermediary agents to facilitate trust establishment between consumers and cloud providers [32]. Their agent, called an SLA-agent, performs activity monitoring, trust decisions, and best-fit service selection based on SLA parameters. Trust decisions are based on service delivery feedback about cloud providers from both the consumer and SLA-agents. However, the research is only subjective, and the authors have not shared any detail of the trust model in terms of SLA parameters, evaluation, and aggregation of feedbacks, and overall trust calculation. The theoretical foundation of their proposed model dictates that the fusion of trust evaluation parameter is performed manually and thus is not feasible for use in dynamic service compositions.

“Select Cloud Service Provider” (SelCSP) [23] is another model for selecting a trustworthy CSP from a set of CSPs. Trustworthiness and the competence of a CSP is combined for an overall risk estimation of interaction. Trustworthiness is computed as a result of experience achieved through interactions or from feedback regarding each provider's reputation. Competence of a CSP is measured based on transparency in the provider's SLA guarantees. Both entities are merged to compute the overall interaction risk that provides an overall approximation of the risk involved in any given interaction. However, their approach of trust evaluation uses subjective methods to evaluate QoS parameters rather than the service behavior from real-time sources against QoP attributes.

The notion of verifying CAIQ assessment and complementing it with user feedback is presented in [38]. A third-party audit framework acts as a baseline for the user to evaluate the services or the provider for whom they are working first time. Afterwards, the feedback from the user is incorporated to the audit score to build a trust score of the service provider. A time decay function is also used to give more weight to the recent feedbacks. The results of the cumulative feedback combined with the audit score is used as a representation of the service-provider trustworthiness score. However, the function used to combine both trust indicators is a static addition operator and lacks any kind of adaptability in the case of dynamic cloud environments.

Manuel et al. [47] introduced a mechanism to evaluate trust of cloud resources using a resource broker. Their broker selects suitable resources from heterogonous clouds depending on the user requirements. The proposed system provides improved trust through the broker by implementing Kerberos and PrivilEge and Role Management Infrastructure Standard (PERMIS) mechanisms for authentication and authorization, respectively. Their trusted broker makes the assessment for the trust value of resources based on their security level, feedback evaluation and resource capability. The overall trust score, however, is a simple aggregation with equal weights of these three trust scores, which does not consider dynamic service behaviors in multiple service compositions. In addition, the proposed model does not elaborate the mechanism to cater to the heterogeneity of cloud providers.

Credibility of feedbacks can be verified by using correlation of various QoS attributes and feedback result [15]. This approach utilizes technical requirements of users and considers the heterogeneity of providers, services, and users when evaluating trust parameters. Correlation between different QoS attributes (i.e., Availability, Reliability, Time Efficiency, and Data Integrity) is used for an overall trust assessment. A trust manager is responsible for selecting matching services based on the QoS requirements of the user and a trust value. The trust level of services is computed based on feedback from the previous interactions of various users.

Heterogeneity of service providers and services along with user feedback may be overcome by using standard approaches for cloud assessment. CAIQ may be used as a method for a trust and reputation evaluation mechanism, as proposed in [20]. Trust information is modeled in terms of opinions formalized in subjective logic. Cloud providers submit their assessment reports in the form of CAIQ before service delivery to the user. These assessment reports can be requested by the user via the Cloud Trust Protocol (CTP). After the service delivery, a user provides feedback opinion for the cloud provider. Only the latest service delivery feedback is kept in record without any aging factor. However, the credibility of service feedback from the client is not discussed in this approach.

A Security Measurement as a Trust (SMaaT) framework for cloud selection has been presented in [19]. The authors extend an Analytical Hierarchical Process (AHP) for service selection from the customers’ perspective. Monitoring of different Service Level Objectives (SLO) present in the Security SLA (SecLA) is performed to rank the security aspects and assign trust values based on these security parameters. The AHP allows calculation of attribute weights depending on user preference and the estimation of interdependencies between the attributes. The article only contains theoretical contents related to their proposed and hence the credibility of work cannot be established.

Trust Models with Federation Support. Trust management in cloud federation is a least-visited research area, having only few trust evaluation models. One such model [58] is based on the notion that previous models of TMS are unfit for cloud federation architecture due to the novel requirements of cloud-to-cloud trust. However, the proposed model still involves the user for its feedback and is a simple average of SLA-based and feedback-based trust scores. Moreover, the evaluation model of the authors of [58] lacks adaptability, which is the prime concern of federation due to its evolving nature. In addition, their work is only supported by a specific-use case of federation with two participating clouds and a central entity and lacks any word for problems of heterogeneity. To the best of our knowledge, this piece of work is the only trust evaluation system designed for federation. However, it still lacks mechanisms to cope with the specific case of cross-cloud federation.

6 EVALUATION OF TRUST MANAGEMENT SYSTEMS

This section presents a quantitative analysis of the mentioned thirty-six representative TMSs to complement their subjective assessment presented in the previous section. This analysis is carried out not only to build a consolidated view of the ability of these TMSs but also to verify their applicability to the CCF.

6.1 Quantification of Existing TMS

All parameters necessary to establish the evaluation of TMS have been identified in previous sections. These parameters range from architectural classification (Section 2.2) and cloud-to-cloud trust principles (Section 3.3) to attributes (Section 4) of TMS. A TMS may either explicitly address the trust principles of CCF or implicitly with the presence of certain attributes. As a first step, it is identified if a TMS explicitly fulfills the requirements of trust in CCF or not. In case of a negative evaluation, the second step is to verify whether it offers the necessary attributes of trust in general. If that is the case, the presence of requisite attributes is verified for each cloud-to-cloud trust principle as defined by their influence in Table 2. As illustrated in Table 2, Trust bi-directionality only influences methods of trust representation and few properties. Composite trust has its influence on all methods and properties except the objective of TMS. Moreover, Delegation control does not influence any method but the architectural classification and a few of the properties. Similarly, Resource awareness has its effects on representation and evaluation of trust along with some properties.

Table 2. Influence of Cloud-to-Cloud Trust Principles on Trust Management Systems

Concluding the efforts for explicitly addressing the concerns of cloud-to-cloud trust from Table 3, resource awareness is somewhat incorporated in recent works, making up to 60% of the literature. All other principles, including trust bi-directionality, composite trust, and delegation control can be seen as neglected areas. Moreover, from Table 3, it can be observed that many of the existing works exhibit the necessary properties and functions that can be fine-tuned to deal with the requirements of cloud-to-cloud trust.

Table 3. Objective Analysis of TMS in Cloud Computing
Trust Specifications
CCF Specifications Methods Properties
[22] SD P SSt T U AA CL
[24, 45] SC P H SSt T U V CL
[26] SC P Sa T U AA RL
[16] SC P H T U AA CL
[14] MP P SSt Re U CL
[21] MD P H Sa SAd T U AA RL
[12] - R SAd T U RL
[30] SC R SAd T U Pe CL
[11] SP R SAd T U
[13] SP R H Sa SSt Re U/C RL
[41] SC R H Sa SAd T U V SL
[50] MD R H Sa SSt T U/C M RL
[49] MC R H Sa SAd R C CL
[35] - E SSt T U M RL
[42] - R/E Sa SAd T/Re U CL
[36] SC R/E H Sa SAd T U M RL
[18] SD P/E Sa SSt T U AA SL
[28] - P/E SAd T U M SL
[48] SC P/E H Sa SAd T U M SL
[31] SC P/E H Sa - - T U M SL
[43] SC P/R/E Sa SAd T U M CL
[56] MC R/E Sa SAd T U M RL
[54] MD P/R/E Sa T U M RL
[55] MC R/E Sa SAd T U AA RL
[46] MC P/R/E H Sa SSt T/Re U M SL
[57] MD R/E Sa SAd T C M SL
[32] SC P/R SSt T U M CL
[23] SC P/R H Sa SSt T/Re U Tr SL
[38] SC P/R H Sst T U AA CL
[47] SC P/R Sa SSt T U RL
[15] SC P/R H Sa SAd T U V CL
[20] SC P/R H SSt T U RL
[19] - P/E T U M CL
[58] FC P/R Sa SSt T C CL

Legends

\hrule

= Present, = Not Present, -/NA = Not Applicable,

SC = Single cloud with Centralized management, SD = Single cloud with Decentralized management, SP = Single cloud with Peer-to-peer, MC = Multiple clouds with Centralized management, MD = Multiple clouds with Decentralized management, MP = Multiple clouds with Peer-to-peer, FC = Federated cloud with Centralized management

H = Homogenous representation, Sa = Simple aggregation Ha = Hierarchical aggregation,

SAd = Simple Adaptive, SSt = Simple Static, HAd = Hierarchical Adaptive, HSt = Hierarchical Static,

P = Policy, R = Recommendation, E = Evidence, T = Trust, Re = Reputation,

U = User centric, C = Cloud centric,

M = Monitoring, AA = Audit and Accounting, V = Verification, Pe = Penalty, Tr = Transparency,

CL = Cloud Level, SL = Service Level, RL = Resource Level.

\hrule

This objective analysis from Table 3 is then quantified so as to visualize and comprehend the trends in research and development of TMS. The resultant view is complimentary to the opinion that cloud-to-cloud trust paradigm is one of the least focused area of research. Moreover, this comprehension is the key to understand the shortcomings of existing solutions and to identify where much focus is required. A quantifiable analysis of the capability of these TMS in implicitly fulfilling the requirements of trust in CCF is presented as follows:

  • Trust Bi-Directionality. Referring to Table 2, bi-directionality requires homogeneous representation methods and must exhibit a few of the properties of TMS that may further be aligned to CCF context. It is observed that only nine TMS appear as candidate systems that exhibit homogeneous aggregation methods. Out of these nine candidates, only one TMS exhibits all five properties for introducing bi-directionality. The other eight lack one or more attributes, however, making them closely acceptable for the purpose. This is depicted in Figure 10(a).
  • Composite Trust. Referring to Table 2, composite trust not only requires homogeneous trust representation but also methods for multi-level aggregation, evaluation, and dissemination. All properties of TMS must be aligned to this multi-level nature of composite trust methods with the exception of the TMS objective that should always refer to trust and/or reputation. Out of all representative systems, not a single candidate TMS offers such a capability to implicitly provide any method that deals with composite trust.
  • Delegation Control. Referring to Table 2, unilateral delegation of trust can best be avoided with centralized architectures along with a few of the properties of TMS that may further be aligned to CCF context. It is observed that 14 TMS appear as candidate systems that have centralized architecture. However, none of these TMS exhibit all four properties necessary to introduce controlled delegation within CCF. This is depicted in Figure 10(b).
  • Resource Awareness. As observed, there are 16 TMS explicitly offering resource awareness mechanisms. However, keeping in view the conventional requirements of trust, only two of these are effective, as they exhibit the necessary properties of trust as derived in Table 2. This is depicted in Figure 11(a). Keeping in view the CCF requirements, unfortunately adaptive trust evaluation methods with homogenous representation to support a multi-level relationship in CCF is not available in literature as yet. However, there are six TMS that are partially candidate systems with a homogenous representation supporting adaptive evaluation of trust. Out of these six partially candidate TMS, only one exhibits the necessary properties influenced by resource awareness in CCF. This is depicted in Figure 11(b).

6.2 Requirement Matrix for Trust Evaluation in CCF

To this point, we have identified the general components of trust along with their properties and have outlined a basic cloud-to-cloud trust paradigm. Moreover, a review of the current research has been presented to summarize their shortcomings in achieving trust within a CCF. An overview of the evaluation of TMS helps us to draw the following significant assessments:

  1. Almost all of the discussed schemes lack the establishment of a complete TMS having both trust and reputation assessment.
  2. No significant work has been reported in the literature for trust and reputation evaluation from a cloud-centric, i.e., cloud-to-cloud, trust perspective.
  3. The present research on TMS lacks focus on mechanisms of multilevel aggregated trust evaluation for composite services.
  4. Existing trust models have never been instantiated in TMS to evaluate bi-directional trust of entities.

Keeping in view these assessments, it can be concluded that a novel TMS is required for CCF that contains newer methods aligned to the specific nature of CCF. This section outlines the probable areas that require necessary changes in their underlying structure along with our recommendations for these changes. Table 4 shows a detailed matrix containing the influence of identified parameters of trust evaluation and CCF on each other.

Table 4. Matrix for Requirements of Trust in Cross-Cloud Federation

In this matrix, we have identified two categories of trust parameters. One category consists of parameters that have a set of choices from which to select, i.e., architecture and trust method types. Both of these parameters have two choices and the most influential choice is the recommended one. For example, out of all identified parameters, a large number is compatible with centralized architecture, rendering it a recommended choice. The other category consists of trust parameters that have no set of choices. However, these parameters influence certain other parameters and hence are necessary to be incorporated. These parameters mostly require a change or alteration in their underlying methods to be fit for CCF. For example, from the intersection of privacy and trust sources as highlighted in Table 4, it is recommended that the information collected from trust sources must incorporate mechanisms for privacy. Moreover, the intersection of trust sources with multilevel nature of federation, it is suggested that the methods for assessment of policy, recommendations, and evidence must align to the multi-level nature of CCF. Following the same patterns, a few guidelines can be provided as recommendations for a comprehensive and most suitable trust management solution for CCF.

Centralized Trust Management. In cross-cloud federation, the necessity of a central entity such as a broker for resource discovery and matching is already an established fact. Similarly, in case of trust dissemination, enforcement, control, and compliance, a centralized model is a trustworthy choice. A trust-aware broker encourages the CSPs to have higher confidence in federation as trust decisions are authentic and reliable. Moreover, the benefits of a centralized trust management system, as evident from Table 4, surpasses its drawback of being a single point of failure.

Multi-Sourced Trust Indicators. In a cross-cloud paradigm, the objective of a trusted federation is to convince the CSPs to entrust their customers’ data to each other for enhanced mutual interest. It is crucial to select key indicators of trust to maximize decision performance. The key indicators of trust must be collected from a combination of policy, recommendation and evidence base to indicate a CSP's social standing and assurance of its future outcomes.

Adaptive Trust Fusion. The dynamic nature of federation establishes the need for adaptive fusion of trust values collected from multi-source trust indicators. This ensures that the overall trust evaluation follows the evolving and ever-changing structure of the federation.

Homogenous Policy Formalization across Entire Federation. Converting heterogeneous policies of all CSPs to homogenous metric space is necessary for uniform evaluation and comparison of the trust values of their respective resources from all trust resources.

Novel Methods within Federation. As mentioned earlier, a CCF can achieve the requisite properties of trust by aligning its underlying methods with the nature of federation. However, certain parameters in the cloud-to-cloud trust paradigm require newer methods as these parameters have never been addressed in literature in the perspective of trust. These include novel methods for (i) evaluating cumulative trust of a composite service, (ii) controlling unilateral delegation of trust, and (iii) dealing with the multilevel and hierarchical nature of federation.

7 CONCLUSION

The issues of trust establishment in cross-cloud federation are highlighted as unique cases due to the transitive nature of federation, i.e., the customers’ trust of its home CSP and the home CSP's trust of its sub-providers. This survey has presented insightful analysis of the recent literature on trust in conventional and inter-cloud computing models, revealing the void that exists in addressing the concerns of trust management in the cloud-to-cloud relationship setting. Moreover, this survey has identified (i) trust bi-directionality, (ii) composite trust, (iii) delegation control, and (iv) resource awareness as theoretical principles that make up the cloud-to-cloud trust paradigm. To address the challenges related to these principles, it has been established that the underlying methods and properties of TMS need to align with the specific characteristics of CCF. Novel mechanisms are required for composite and mutual trust evaluation within the federation. Moreover, avoiding unilateral trust delegation and resource awareness are the other major concerns in such a competitive environment, which is inherently heterogeneous, dynamic, and hierarchical. A consolidated requirement matrix is presented, highlighting the potential areas of influence that federation's nature has on the properties and characteristics of TMS.

REFERENCES

Footnote

Authors’ addresses: U. Ahmed (corresponding author), Communication Networks Research Center (CNRC), Department of Computer Science, COMSATS University Islamabad, Lahore Campus, Pakistan and Department of Software Engineering, Government College University, Faisalabad, Pakistan; email: usamaahmed@hotmail.com; I. Raza and S. A. Hussain, P.O. Box 54000, Communication Networks Research Center (CNRC), Department of Computer Science, COMSATS University Islamabad, Lahore Campus, Pakistan; emails: iraza@cuilahore.edu.pk, asadhussain@cuilahore.edu.pk.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.

©2019 Association for Computing Machinery.
0360-0300/2019/01-ART19 $15.00
DOI: https://doi.org/10.1145/3292499

Publication History: Received August 2017; revised February 2018; accepted November 2018