Towards Trusted Mobile Ad-Hoc Clouds

Ahmed Hammam, Samah Senbel College of Computing and Information Technology

Arab Academy for Science and Technology and Maritime Transport Cairo, Egypt

ahmed@hammam.me, senbel@aast.edu

Abstract—Most current cloud provisioning involves a data center model, in which clusters of machines are dedicated to running cloud infrastructure software. Ad-hoc mobile clouds, in which infrastructure software is distributed over resources harvested from machines already existing and used for other purposes, are gaining popularity. In this paper, we propose a trust management system (TMC) for mobile ad-hoc clouds. This system considers availability, neighbors’ evaluation and response quality and task completeness in calculating the trust value for a node. The trust management system is built over PlanetCloud which introduced the term of ubiquitous computing. EigenTrust algorithm is used to calculate the reputation trust value for nodes. Finally, a performance test was executed to prove the efficiency of the proposed TMC in term of execution time, and detecting node behavior.

Keywords: Ad-Hoc Clouds, Reputation, Trust management.

I. INTRODUCTION Cloud computing introduced a high scalable computing

architecture, that provides everything as a service "XAAS". This architecture opened the door to new applications and solutions. Generally, cloud computing is based on the existence of huge datacenters, which need internet connection to reach its services. But, there are some applications which require scalable computing in absence of internet connection, such as in natural crises, to reach computing resources. That drives to ad-hoc cloud, where resources are harvested from machines already in existence within a network. And the increase in computing power of mobile devices led to the use of mobile ad-hoc clouds. In this type of architecture, resources are owned by users who cannot be trusted and may be malicious. To solve this problem, trust management systems were developed.

A new architecture was introduced that forms ad-hoc mobile clouds [8, 9]. This architecture is based on a “spatio-temporal” calendering mechanism that automatically adjusts resources to each cloud. Client agents' calendars is stored in resource servers “RS” which allows them to pick suitable members to form clouds. However, cloud agents need to verify that participants are reliable, available, and not malicious. To solve this, a reputation trust management system is proposed. This system will allow cloud agents to select client agents based on a calculated trust value that reflects its honesty.

To simulate the proposed reputation Trust management system, the “P2P Trust Simulator” [13] was used to simulate the transactions between cloud agent and client agents and to calculate trust values. The next section provides an overview of

the related work in this field of research. In section III, a brief description of the “PlanetCloud” [8] system is given. In section IV, the proposed trust system for ad-hoc mobile clouds TMC is described. Section V describes the system performance test and displays the results that were obtained, and section VI concludes this work and provides at a glance a view of the future work.

II. RELATED WORK

A. Mobile Cloud Computing “Mobile Cloud” is an ad-hoc cloud that utilizes the

increase of mobile devices power. A model was introduced for cloud [7], in which infrastructure software is distributed over resources harvested from machines already in existence within an enterprise. In contrast to the data center cloud model that in which resources dedicated exclusively to the cloud. Ad hoc cloud allows partial virtualization of non-dedicated hardware based in distributed voluntary resources.

“Mobile Cloud Computing (MCC)” was defined in surveys [2, 3] as a composition of mobile technology and cloud computing infrastructure where data and the related processing takes place in the cloud and then can be accessed through a mobile device. Or in which mobile device is being part of the cloud by voluntarily provides its resource to the cloud provisioning system.

As a development of SETI@HOME concept a new Cloud infrastructure Architecture is introduce [4]. In this architecture Commercial/business and the volunteer/scientific viewpoints coexist. This infrastructure is able to provide adequate resources to satisfy user requests also taking into account QoS requirements. This Architecture was built on resources voluntarily by their owners or administrators, following a volunteer computing approach and provided to users through a cloud-service interface.

PlanetCloud, a new architecture was introduced for forming ad-hoc mobile clouds. It is designed especially for emergency and critical situations [8, 9]. We chose this architecture to build our trust management system on because it has resource servers (RS) which are distributed servers that are used to store spatio-temporal calendar and other information. RS can be used to store trust values for client agents’ to be used by cloud agents in the cloud formation request. PlanetCloud is described in more details in the next section.

B. Trust Management System Mobile ad-hoc networks MANET is a group of mobile

devices that are connected through wireless link. These nodes are Self-organization which means they are autonomous, with no fixed infrastructure or centralized administrative node. And each node can move in any direction independently from other devices. This network has main three constraints Bandwidth, Computer power and Battery power. Ad-hoc cloud is built on resources that are collected from a network. Network in this case is MANET like in which the physical layer is mapped to mobile devices “client agents”. The neighborhood relationships are among these client agents that are in the radio range. Two Trust management systems for MANET were proposed in [14, 15]. A comparison between TMC and these two systems is provided in section IV.

To build an effective Trust management there is a need to outline various issues involved in the design of reputation-based P2P system [10]. To answer the question of how trust can be applied in distributed computing [1, 12], an investigation has been conducted in trust management systems proposed for cloud computing. The proposed models/systems have been compared with each other based on a selected set of cloud computing parameters.

Another Trust Management System architecture was introduced for cloud computing marketplace [5]. This architecture reflects the multi-faceted nature of trust assessment by considering multiple attributes, sources and roots of trust. It aims at supporting customers to identify trustworthy services providers as well as trustworthy service providers to stand out.

To build a reputation trust management system a reputation algorithm is required to calculate reputation values. EigenTrust algorithm had been introduced [6] to be used in P2P networks to decrease the number of downloads of inauthentic files. It computes agent trust scores in P2P networks through repeated and iterative multiplication and aggregation of trust scores along transitive chains until the trust scores for all agent members of the P2P community converge to stable values. By these global reputation values to choose the peers from whom they download, the network effectively identifies malicious peers and isolates them from the network.

A decentralized trust management middleware for ad-hoc, peer-to-peer networks had been introduced [11]. In this middle ware, reputation information of each peer is stored in its neighbors and piggy-backed on its replies to requests for data or services. This middleware relies on the lack of network structure to manage reputation information in a secure way.

C. Simulator To conduct the performance test a general-purpose

evaluation framework is used [13]. This framework introduced to evaluate reputation management for distributed systems, peer-to-peer (P2P) networks, and ad-hoc mobile computing. We chose this framework because it was built specially to evaluate reputation algorithms in P2P and ad-hoc networks. And it provides a mechanism to plug new algorithms.

III. PLANETCLOUD IN BRIEF PlanetCloud [7, 8] is an architecture that was developed to

enable resource provisioning and dynamic “spatio-temporal” resource calendaring to form ad-hoc cloud. It aims to utilize the increased number of mobile devices available to provide "on-demand" scalable distributed computing capability, especially in critical situations. This architecture has three main components “Client Agent”, “Cloud Agent” and “Resource Server” (RS). Each of these components will be discussed in brief:

A. Client Agent Client agent is the application used by the user who has a

resource which he is willing to share. This application manages the client spatio-temporal resource calendar: which resource can be shared and when. It handles incoming requests for cloud formation, notifies a user of the next incoming clouds, connects with all other agents involved in the cloud formations, and synchronizes the calendar’s content with the Resource Server's data.

B. Cloud Agent Cloud agent is the application used by the user who wants

to form a cloud. This application is deployed on a high capability client to manage and store the data related to spatio-temporal calendars for all clients within a cloud. The cloud agent uses local data repository to store the user profiles, and spatio-temporal calendars of clients within a cloud. This application can query data repositories in “RS” for extra information.

Figure 1: PlanetCloud Architecture. [9]

C. Resource Server Distributed RSs operate on the updated data from clients’

calendars and clouds data, which are stored in a data repository. The RS provides resource forecasting using an implemented prediction unit. It has a data store that is used to

Figure 2: Proposed Trust System for mobile ad-hoc cloud

store calendars and other information and it has other three sub components, "Information Bases" where it stores information about cloud formation requests and users’ information, "Account manager" which contains billing information and "Synchronizer" that synchronize data between RSs and users.

Figure 1 explains the high level architecture of “PlanetCloud”. RSs are distributed not centralized, data are replicated through RSs. Client agents and cloud agents can directly communicate to RSs. Cloud agent can communicate directly to client agents.

IV. PROPOSED TRUST MANAGEMENT SYSTEM FOR AD-HOC MOBILE CLOUD TMC

A. TMC System Design The goal of the proposed system is to avoid the

participation of malicious client agents which would affect the performance of the formed cloud. This is due to the fact that this system is used in critical situations which require zero tolerance with malicious behavior.

We propose a trust system for ad-hoc mobile cloud that evaluates members of a cloud and computes trust value during its interaction in a cloud. This trust value is stored in the cloud agent’s local repository then it synchronizes these values with

the data repository of RSs. Table I contains sample information. Cloud agent can use these trust values in the next cloud formation to select the most high trusted client agents. Other cloud agents can query updated trust values of client agents from RSs data repository.

Because these ad-hoc clouds are made up mainly from mobile devices, the availability of the client agents is considered. Also, the neighbors’ evaluation is considered, because data are transferred from client agents to cloud agents and vice versa, though a path formed of other client agents. Malicious client agents cannot evaluate other client agents to avoid affecting trust values. Moreover, response speed and completeness of tasks are considered. Finally, the number of clouds that the client agent participated in is taken in consideration. After calculating the new trust value of a client agent, it is stored in the RSs repository to be used in the next selection process.

The EigenTrust algorithm was used to calculate the trust value of each client agent during its participation in a cloud. Figure 2 explains the proposed trust management system. In the next paragraphs, the system workflow will be described.

If a cloud agent is forming his first cloud it sends requests to RSs to form new cloud and set its preferences and settings. RSs query its data store to find the most suitable client agents.

Then RSs send approval request to client agents. If a client agent sends his approval to RSs, it checks if client agent is complying with cloud formation settings and preference.

Next, the cloud agent can form his cloud and after a cloud is formed, cloud agents start to evaluate cloud members and receive each client’s neighbors’ evaluation to include it in the final evaluation stored in the local data store, which is then synchronized with RSs. This evaluation is used to calculate the average trust value of each client agent to be used in next cloud formation.

Table I: client agents’ information in RS / Cloud agent store

In the subsequent cloud formations, a cloud agent checks if it can establish a connection to RSs then it will check trust values for its trusted client agents only in RSs data store. Then RSs will query the data store to query if the number of clients to form the cloud is not covered by trusted client from cloud agents. Then it request approval from client agents before complete cloud formation request.

If the connection between cloud agent and RSs is not established, Cloud agent queries its local data store for client agents. Then it selects the client agents using the same criteria used by RSs. Then it send approval request to client agents, if a cloud agent accepts the cloud formation request it sends confirmation to cloud agent. Then cloud agent forms its cloud and then the client agent starts to evaluate its neighbor client agents during its participation in the cloud as previously described. And then cloud agent synchronizes trust values with RSs once it can establish a connection with it. In Table II system messages are listed with brief descriptions.

Table II: System Messages Message From To Description Place Cloud formation Order

Cloud Agent RS set cloud settings by cloud agents

Approval Request Cloud Agent / RS

Client Agent

Asks client agent to join a cloud

Client Agent Accept Cloud Agent RS Client Agent Accepts to join the cloud

RS Confirm RS Cloud Agent

Confirms that Client agent is compliant with SLA and other cloud roles that was set by cloud agent

Send evaluation Client Agent Cloud Agent

Cloud Agent sends its evaluation of its Neighbors

Synchronize Cloud Agent RS Cloud Agent sends its new evaluation of client agents and request to update its local store with new computed client agents trust values.

B. Simulator “P2P Trust Simulator” [13] is used to execute performance

tests. It was originally implemented to be fed with fixed

numbers of pre-Trusted users, good Behaving users and other values for other malicious behaviors. Then it generates random values for each node to match its assigned behavior. Then it calculates number of good and bad transactions.

This simulator works in two steps. In first step, it generates a trace file that contains nodes and its trust values also this file contains the transactions between nodes and files this file is generated based up on the parameters that are passed to trace generator. In second step the trace file is used as an input for trace simulator which will apply the reputation algorithm then it write its output and statistics in a file this steps are shown in figure 3.

Figure 3 : Overview of evaluation architecture [13]

In this simulator, new calculated trust values for nodes are

not used in the next rounds. To use this simulator in the performance test it is needed use the calculated trust values in next rounds. Also there is a need to dynamically detect nodes behavior according its “Honesty” and “Response Quality” as shown in Table III.

Numbers in Table III are guided by numbers in Table 1[13]. In this table Pre-trusted Client Agents referees to client agents which are trusted by TMC or by cloud agent. Good Client Agents are client agents which behave honestly during the test round. Malicious Client Agents are client agents which were not performing honestly during the test round. Client Agent’s behavior is not detected are the agents which TMC couldn’t categorize them into one of the previous behaviors.

A simulation of RSs behavior is done by storing and retrieving these values for client agents to be used by cloud agents. Client agent will be represented by a node and there is e only one Cloud agent.

Pre-trusted client agents are detected in the start of a round. The new client agent who didn’t participate in any cloud will be assigned an initial trust value between 0 and 1, that is less than a static value called new_trust_value_threshold. The behavior of the new client agent can be controlled by changing the new_trust_value_threshold value. Unlike the default “P2P Trust Simulator” behavior, TMC detects client agents’ behavior from retrieved trust value “Honesty” and response-quality. Refer to Table III.

In Figure 4 explains the changes that had been done in the simulator. Now it only has two arguments passed to it the required nodes number and the selection strategy. Node selection is done using passed selection strategy then selected nodes are used in the trace simulator step. Then new calculated trust values are updated. Finally statistics are written to a file.

Figure 4: Overview of evaluation architecture after

enhancements

Table III: Values used to detect user's type User Type Response-

quality% Honesty%

Pre-trusted Client Agents 90-100% 90-100%

Good Client Agents 90-100% 70-100%

Client Agent’s behavior is not detected

50-70% 50-70%

Malicious Client Agents 0-50% 0-50%

To calculate the trust value of a client, last trust (t) and

response-quality (r) values are loaded from database We also take into consideration neighbor-evaluation (n) and availability-evaluation (a) based on the user’s behavior. 100,000 transactions are generated to be used in the simulation to calculate trust value(t). However, these values cannot exceed the new_trust_value_threshold specified for a new member.

These values n, r and a are used in an Equation 1 to calculate the final trust (t) value which is stored in RSs.

( ) ( ) ( ) ( )arntt ×+×+×+×= 4.02.01.03.0 (1)

We chose these weights for each element to reflect its importance. The availability is the highest importance because it is what makes the deference in mobile environment. The second in its importance is the computed trust value that is based on behavior of the client agent. The third in its importance is response-quality based on response speed and assigned task completeness, then finally neighbor-evaluation.

RSs client agent selection process is simulated, by ordering client agents using their Honesty value, response-quality and number of participation in the clouds. Then select from lists top the number of client agents requested by cloud agent.

C. Comparison between TMC and Existing Trust Management Systems for MANET There exists number of trust management systems were

built for MANET. In the next table a comparison between TMC and two trust management systems were built for MANET. Table IV compares between TMC and trust management systems [14, 15] in term of trust values calculation, trust values store, trust values reusability, and trust values exchange.

Table IV: Comparison between TMC and MANET Trust Management systems

TMC Buchegger, S., et al. [14]

Velloso, Pedro B., et

al. [15]

Calculation Cloud agent for client agents which participated in a cloud and every client agent for its neighbors

node for neighbors only

each node for every in radio range

Store Stored centralized in RSs and locally in cloud agents

Locally Locally

Reusability Reused by the TMC system to recommend client agents to cloud agents

Used during current network session

Used during current network session

Exchange between TMC and cloud agents

between neighbors nodes only

between all nodes in the radio range

V. SYSTEM PERFORMANCE TEST In this section, we simulate the behavior of TMC and

compare its results with plain PlanetCloud. We conduct a performance tests. We used two versions of EigenTrust first one EigenTrust-1 is as it was described in [6] while the second version EigenTrust-2 uses snapshot comparisons to avoid costly recalculation on every cycle.

In the performance test, the simulator was run using the proposed system TMC 10 test rounds with each EigenTrust version. Then the simulator was run another 10 test rounds with plain PlanetCloud, under the same conditions. Then, the three results are compared. The comparison is done between the numbers of pre-trusted client agents, good behaving client agents, malicious client agents and unknown behavior client agents and between the execution times.

Pre-trusted client agents are trusted by the system before it entered a round. Good behaving client agents are the agents that have good behavior during a round. Malicious client agents are the agents that have malicious behavior during the round. Unknown behaving client agents are the agents that system couldn’t categorize them into one of the previous behaviors.

In each experiment there is a set of 1000 client agents to select 100 clients out of them to form a cloud. Number of performed transactions in each experiment is 100,000. In the Performance Tests a machine that has Intel core I5 processor and 8 GB RAM was used.

A. Performance Test In this performance test, the new_trust_value_threshold

was set to be 0.7 which is near to the good type range Table III. There is a set of 1000 client agents to choose 100 client agents out of them. Number of transaction used was 100,000.

Figure 5 shows that the execution times of the ten rounds with and without using TMC are very close, with the TMC EigenTrust-1 system giving an enhancement of about 25% while TMC EigenTrust-2 it gives around 40%. Figure 6 shows that the number of pre-trusted client agents that entered the ten rounds using TMC with the two EigenTrust versions are

increased from round to round more that those entered the rounds without TMC. Also the total number of them using TMC is more than it without using TMC. Figure 7 shows that, the number of the good behaving client agents in each round with using TMC is more than that number without using TMC.

Figures 8 and 9 show that TMC using the two versions of EigenTrust detects and eliminates malicious and unknown-behavior client agents and that improves round after round. We can conclude from these experiments that adding the trust system to the existing PlanetCloud system will not only improve the performance of the system, but will also provide a reliable repository of client trust values which is useful in assigning future cloud groups.

Figure 5: execution Time comparison.

Figure 6: Pre-Trusted client agents.

Figure 7: good behaving client agents.

Figure 8: malicious client agents.

Figure 9: Unknown Behaving client agents.

Finally based on this performance test state that TMC enhance the performance of the PlanetCloud in term of numbers of Pre-trusted Client Agents, good behaving client agents, Malicious Client Agents and Client Agents with unknown behavior. This will reflect positively on the cloud performance, and was experimentally proven to be at least 20%.

VI. CONCLUSION AND FURTURE WORK The proposed system monitors the client agents’ behaviors

that join the ad-hoc clouds in the “PlanetCloud” to provide better results for cloud agents by providing them by trusted Client agents. Centralized store for this information may set some limitation on forming new ad-hoc cloud, but already cloud agents and client agents need to access RSs frequently to read or update spatio-temporal calendar. And also cloud agents have a local repository which can be used in cases that RSs are not reachable. Scalability of PlanetCloud will not be affected because Cloud agents just need to connect to RS in the selection phase of client agents. RS are not interfered during cloud sessions and cloud agents need only to synchronize its new calculated values when it is possible. And it is possible for cloud agents to depend on their local data store if they cannot connect to RS.

We have shown that the number of good behaving client agents and pre-trusted client agents is enhanced from one round to the next. And on the long run large numbers of good behaving, pre-trusted and bad behaving agents will be identified and recorded in the RSs what will help cloud agents to safely form clouds in low time cost especially in crises and emergency situations.

Although EigenTrust algorithm is being used for many years but it was chosen because its behavior is guaranteed and well tested. But other algorithms like PowerTrust [16] and PeerTrust [17] algorithms will be used in future work to compare their results with EigenTrust results. Neighbors evaluation is not covered in this paper and will be another point to be covered in the future work.

REFERENCES [1] Firdhous, Mohamed, Osman Ghazali, and Suhaidi Hassan. "Trust

Management in Cloud Computing: A Critical Review." arXiv preprint arXiv:1211.3979 (2012).

[2] Fernando, Niroshinie, Seng W. Loke, and Wenny Rahayu. "Mobile cloud computing: A survey." Future Generation Computer Systems (2012).

[3] Dinh, Hoang T., et al. "A survey of mobile cloud computing: architecture, applications, and approaches." Wireless Communications and Mobile Computing (2011).

[4] Distefano, Salvatore, and Antonio Puliafito. "Cloud@ Home: Toward a Volunteer Cloud." IT Professional 14.1 (2012): 27-31.

[5] Habib, Sheikh Mahbub, Sebastian Ries, and Max Muhlhauser. "Towards a trust management system for cloud computing." Trust, Security and Privacy in Computing and Communications (TrustCom), 2011 IEEE 10th International Conference on. IEEE, 2011.

[6] Kamvar, Sepandar D., Mario T. Schlosser, and Hector Garcia-Molina. "The eigentrust algorithm for reputation management in p2p networks." Proceedings of the 12th international conference on World Wide Web. ACM, 2003.

[7] Kirby, Graham, et al. "An approach to ad hoc cloud computing." arXiv preprint arXiv:1002.4738 (2010).

[8] Khalifa, Ahmed, and M. Eltoweissy. "A global resource positioning system for ubiquitous clouds." Innovations in Information Technology (IIT), 2012 International Conference on. IEEE, 2012.

[9] Khalifa, Ahmed, Riham Hassan, and Mohamed Eltoweissy. "Towards Ubiquitous Computing Clouds." FUTURE COMPUTING 2011, The Third International Conference on Future Computational Technologies and Applications. 2011.

[10] Maini, Siddharth. "A Survey Study on Reputation-Based Trust Management in P2P Networks." Reputation-based P2P Survey (2006): 1.

[11] Repantis, Thomas, and Vana Kalogeraki. "Decentralized trust management for ad-hoc peer-to-peer networks." Proceedings of the 4th international workshop on Middleware for Pervasive and Ad-Hoc Computing (MPAC 2006). ACM, 2006.

[12] Ruohomaa, Sini, Lea Kutvonen, and Eleni Koutrouli. "Reputation management survey." Availability, Reliability and Security, 2007. ARES 2007. The Second International Conference on. IEEE, 2007.

[13] West, Andrew G., et al. "An evaluation framework for reputation management systems." (2009).

[14] Buchegger, S., Le Boudec, J.-Y. “A Robust Reputation System for Mobile ad hoc Networks. Technical Report.” IC/2003/50, EPFL-DI-ICA, (2003).

[15] Velloso, Pedro B., et al. "Trust management in mobile ad hoc networks using a scalable maturity-based model." Network and Service Management, IEEE Transactions on 7.3 (2010): 172-185.

[16] Rahbar, A. G. P., and O. Yang. "Powertrust: A robust and scalable reputation system for trusted peer-to-peer computing." Parallel and Distributed Systems, IEEE Transactions on 18.4 (2007): 460-473.

[17] Xiong, Li, and Ling Liu. "Peertrust: Supporting reputation-based trust for peer-to-peer electronic communities." Knowledge and Data Engineering, IEEE Transactions on 16.7 (2004): 843-857.