# BROSMAP: A Novel Broadcast Based Secure Mobile Agent Protocol for Distributed Service Applications

Authors: Dina Shehada; Chan Yeob Yeun; M. Jamal Zemerly; Mahmoud Al Qutayri; Yousof Al Hammadi; Ernesto Damiani; Jiankun Hu
Journal: Security and Communication Networks
 (2017)

---

## Abstract

Mobile agents are smart programs that migrate from one platform to another to perform the user task. Mobile agents offer flexibility and performance enhancements to systems and service real-time applications. However, security in mobile agent systems is a great concern. In this paper, we propose a novel Broadcast based Secure Mobile Agent Protocol (BROSMAP) for distributed service applications that provides mutual authentication, authorization, accountability, nonrepudiation, integrity, and confidentiality. The proposed system also provides protection from man in the middle, replay, repudiation, and modification attacks. We proved the efficiency of the proposed protocol through formal verification with Scyther verification tool.


---

## Body

## 1. Introduction

A mobile agent (MA) is intelligent software that has the ability to migrate from one node to another, performing tasks on behalf of its owner [1, 2]. In agent-based systems, the nodes where agents migrate, execute, and collect data are called platforms. MAs reduce the load on the network and require low bandwidth. MAs also add scalability to the network; that is, it is easy to add new participating agents to the system. They have the ability to perform asynchronous tasks. Moreover, MAs are small and operate based on the idea of moving computations to data rather than moving data to computations [3–6], reducing the number of computations to be performed on owners. Owners dispatch their agents carrying the request, and agents execute on other service platforms, doing most of the work by taking the advantage of their computational power and eventually coming back with useful information. All these features make them suitable for real-time information retrieval applications with distributed databases that are otherwise time-consuming and operationally costly to search [7, 8]. An example of real-time distributed applications is Location-Based Service (LBS) ones. LBS applications provide users with geospecific services and information based on their location and preferences. LBSs are used in different contexts, such as health, entertainment, travel, and many others [9, 10]. The use of LBS applications provides users with the needed information and saves their time, effort, and money. In LBSs, a large amount of information is stored in different places and the challenge lies in ensuring fast and efficient information retrieval process upon the user request [11]. MAs are small, fast, autonomous, have a distributed architecture, and have the ability to migrate in the network to search for information. Therefore, incorporating mobile agent system (MAS) with LBS will enhance the system performance and efficiency.Although agents offer many practical features to distributed systems, MAs face classic security breaches as any other software that is distributed in an open network, hence ensuring their security raises challenges [12]. The flexibility and mobility of agents in the open network increase their vulnerability to different security attacks such as masquerade, modification, man in the middle (MITM), replay, repudiation, eavesdropping, and denial of service (DOS) attacks [3, 13–15]. If these vulnerabilities are not properly addressed, they will not only reduce the performance and integrity of the system and services provided,but will also put user privacy at risk. In addition to their locations, users of LBS applications might need to reveal some sensitive information. Therefore, it is important for application users to trust that their data are not going to be exposed to any untrusted entity.To overcome such security problems, a novel BROadcast based Secure Mobile Agent Protocol (BROSMAP) for distributed service applications such as LBS is proposed. BROSMAP provides significant improvements over existing protocols found in the literature. While previous research efforts could address only small subsets of the security properties identified as important for MASs, BROSMAP’s innovative design provides security requirements coverage while staying lean enough to guarantee performance. It provides a generic solution for different security threats. It also provides the fundamental security requirements for distributed service applications. The proposed broadcast dispatch mechanism in addition to the use of hybrid approach of symmetric and asymmetric cryptography methods helps the system in maintaining a good performance compared to other protocols in the literature. In addition, BROSMAP has the flexibility of staying operational, even if one of its agents is maliciously killed or lost.The remaining part of the paper is structured as follows. In the next section, requirements of secure MAS are discussed. Section3 introduces the related works. In Section 4, details of the novel BROSMAP are discussed. Section 5 provides detailed security analysis in addition to analysis of results of formal verification proof carried with Scyther tool. Section 6 discusses the performance evaluation of BROSMAP compared to other similar protocols. Section 7 shows details of the implementation the BROSMAP based LBS application carried out with Java Agent Development Environment (JADE) [16, 17]. Finally, Section 8 summarizes the contributions and highlights future work.


## 2. Security Requirements for MASs

As noted in the previous section, MASs are vulnerable to different types of attacks. Such vulnerabilities do not only affect users’ security and privacy but also the system productivity. The security research community has identified some key security requirements for MASs; the following security requirements should be satisfied [13, 18–21]:(i)
Anonymity: privacy of the user (owner platform) is maintained through hiding its identity from being exposed.(ii)
Authorization: agents attributes should be verified and accordingly are either granted or denied the access to platform resources.(iii)
Confidentiality: user information, data, or any other sensitive information should remain secret and not be exposed to unauthorized platforms or agents.(iv)
Integrity: user information, data, and other sensitive information should be protected from unauthorized changes by a malicious party and any unauthorized change should be detected.(v)
Mutual authentication: communicating platforms should verify each other’s identity. This is usually done by using Public Key Infrastructure (PKI) where each platform identifies itself by its certificate or signatures.(vi)
Availability: platforms should be always available and ready to provide services. In addition, communication should not be disrupted at any time.(vii)
Nonrepudiation: actions should be traceable to their actors. Any platform cannot deny its results or actions.(viii)
Accountability: attackers or malicious platforms are held responsible for their malicious actions. In the next section, a review on some of the related work proposed to secure MAS is presented.


## 3. Related Works

Securing MASs has been addressed by many researchers. Some proposed works address the issue of user privacy and providing anonymity to system users [22–24]. This feature is important if the application involves dealing with sensitive information. Others focus on providing a scheme to protect the dynamic itinerary of the MA or propose authorization schemes to protect platforms from malicious agents [25–27]. Some authors propose a solution to repudiation and replay attacks, providing the possibility of legitimate reexecution of agents [28], while others propose a new MAS architecture to protect the system from losing all its data in case the MA is killed [29]. Other authors put forward a cryptographic and/or trusted platforms based approaches to provide secure MASs [30–34].In [22], user (owner platform) anonymity and secrecy of path traversed by the MA are addressed. Intermediate helper nodes called mixers are visited by the MAs on their itineraries. Visited mixers in the MA journey store their addresses in the agent state. The MA carries on, randomly migrating from one node to another. At the last itinerary, the addresses of the visited mixers that are stored in the MA state are used to direct the agent to the owner platform. The protocol provides anonymity to the MA owner and to the path of agent. Confidentiality and authorization of data access are ensured through encryption. Authentication of users is not provided and it is assumed that exchanged messages cannot be intercepted and that they all come from legitimate users. A drawback of the proposed protocol is the inability to recover from the malicious killing of an agent. If an agent is lost, the collected data are lost and a new MA has to be resent again. Furthermore, the proposed system introduces random delays, due to the random decisions of the mixers. Therefore, this approach is not suitable for many applications.An anonymous authentication protocol is proposed in [23]. MAs exchange messages that involve information required to authenticate the user. User information is kept confidential through symmetric encryption. A freshly generated nonce and a secret key that are known to the user agent only are needed for a successful decryption of the message. Mutual authentication between interacting agents and protection from replay, MITM, and masquerade attacks are claimed.The authors in [24] proposed another anonymity scheme based on the idea of a last input first output (LIFO) buffer of data that the agent carries with it throughout its journey. Each platform generates its own secret key, a hash of the previous, current, and next destination, and a fresh nonce. The platform encrypts the nonce and the hash along with the previous destination with its secret key and pushes the hash into the stack. When the agent finishes its journey, each platform uses its secret key to decrypt the information available on the stack and sends the agent to its previous destination. The stored hash is used to check the integrity of the path stored to detect if the stack was tampered. Therefore, only the first platform knows the actual address of the owner platform. At the starting point, the LIFO buffer is filled with random garbage data to prevent platforms from reconstructing the address of the owner platform. A weakness of this approach is the size of garbage that the buffer should be filled with. It should be randomly chosen in a way that is big enough to protect the owner platform identity and provide protection from analysis attacks. At the same time, it should also be small enough to fit the MA limited memory size, taking into consideration other itinerary information to be stored later. The protocol also assumes that all MAs in the network have the same code and state, which is an unrealistic assumption for MASs [22].The authors in [25] proposed a cryptographic and trusted platforms based protocol, which ensures the secrecy of the dynamic itinerary generated at run time. Trusted platforms are the main key here; they collect information of other platforms securely and decide the agent’s next itinerary. The itinerary information is encrypted and can only be accessed by the intended platform. In addition to providing secrecy of agent itinerary, the protocol also provides integrity to agent code through hash and asymmetric encryption. Mutual authentication between MAs and platforms is provided. The protocol best suits systems which require time-consuming tasks; otherwise, the system introduces a timing overhead that is not suitable for many applications [28, 35, 36].A protection protocol preventing illegitimate reexecutions and replay attacks of MAs is proposed in [28]. An authorization entity issues a unique identifier called trip marker for each MA. Agents hold counter values which indicate the number of times an agent has been executed. Sometimes an MA needs to execute more than once on the same platform. The counter makes that possible without the need to generate a new trip marker for the agent. Tracks of trip markers and counter values of executed agents are kept on each platform. When the agent requests to be executed, platform checks if the carried trip marker is already in its database. If there is no match then it saves the agent information and executes it. If a match is found, it checks the value of the counter carried by the agent and the value it has in its database; if the counter is incremented, then this is a legitimate reexecution; otherwise, it detects a replay attack and kills the agent. The protocol is verified through simulating replay attacks with Java Agent Development Environment (JADE) [16, 17]. The results verified the ability of the proposed protocol in detecting all simulated replay attacks; however, the protocol is still vulnerable to other attacks such as eavesdropping and repudiation attacks. Although the proposed protocol provides mutual authentication and authorization, it does not support agent cloning as each copy of the agent should carry a new trip marker. In addition, malicious killing of the MAS results in the loss of its collected data [35].To protect and manage information authorization, a Visa Based Authentication Scheme (VBAS) for MASs is proposed by [26]. The user generates an agent and grants it a passport containing the agent information, that is, name of its owner, identity, time stamp, certificate, and other data required for agent authentication. The passport is sent to an authentication server (AS) which verifies the passport and issues a Visa that includes all the resources the MA granted access for. The Visa is verified by a verification server and sent back to the authentication server for final verification, before sending it to the agent. With the Visa issued by the trusted Visa and authentication servers, platforms are able to detect if a malicious agent is unauthorized to access some resources. The protocol provides an integrity check for the passport and Visa. The protocol assumes the availability of a secure communication channel. However, if the channel is compromised, then the passport and Visa information sent in clear text are disclosed. Although the Visa and passport might not contain sensitive information, sending them in clear text makes the system vulnerable to the denial of service attack, where attackers might maliciously tamper with the passport and Visa of an agent and send the tampered version to overwhelm legitimate platforms [37].Another authorization protocol for MAS is proposed by [27]. The work provides an extension to [38] protocol where malicious identification police (MIP) scan MAs for malicious code. MIP use a database containing malicious codes previously detected; if MIP find that the agent is genuine, then the agent is executed; otherwise, the agent is killed. The extension proposed in [27] allows platforms to scan the agent’s code for platform specific policy file. The file includes privileges and permissions granted to agents. The agent’s code is scanned and compared to the policy file of each executing platform. The database contains malicious codes that are known to the system; however, agents with unknown codes are executed and kept under monitoring. If the agent starts to act maliciously, then its code is eventually added to the database. This delay might jeopardize system security. Moreover, any change made to the policy files needs to be reported to the Attack Identification Scanner (AIS) [39]. To support integrity of agent code against malicious platforms, another protocol is proposed in the paper. The protocol is an improvement to the classic Root Canal protocol [40], which was proven to be vulnerable to repudiation attacks. By signing the hash of the code, The eXtended Root Canal (XRC) protocol provides a proof for detecting malicious platforms and, therefore, protection from repudiation attacks as well [34].Authors in [41] proposed a security framework for mobile agent platforms. The proposed framework introduces the idea of multiple levels of access control of platforms resources for MAs. Agent level of access is dependent on their history of traversed itineraries. Each platform visited by the MA signs it and then decides its next destination. Platforms check the history of visited platforms and based on the list it decides how trusted is the MA and grant it access accordingly. The framework provides one-way authentication and authorization. However, the disadvantage of the proposed framework lies in the increase of the path history and signature chain as the MA migrates from platform to another. Another disadvantage is the assumption that platforms are able to identify malicious platforms in the system.A matrix hop architecture for MASs is proposed by [29]. The architecture protects the system from losing its functionality by a malicious killing or loss of MAs. Data generated at every platform are sent back to the owner platform before the migration of the MA to the next platform. Moreover, the architecture enables the system to recover if the agent is killed. The owner platform keeps track of data sent by platforms; therefore, if the agent is killed, then the owner will send the agent to the next destination platform, to carry on its journey.A secure MA information transfer system for e-health applications is proposed in [30]. Information needed for decryption is only provided upon the verification of platforms legitimacy. First, the owner sends its agent for verification along with a token and encrypted data. Upon verification of the agent and the integrity of the code, the receiver sends the token with some other information proving its legitimacy to the sender. Then the sender sends back a one-time secret key required to decrypt the data. Mutual authentication between sender and receiver and data confidentiality are provided. Moreover, data are only accessible to authorized and verified parties [42, 43].Confidentiality, integrity of MA data, secrecy of path of the MA, and nonrepudiation of data are all addressed in [31]. Trusted platforms verify the integrity of data, detect any alteration, insertion, and deletion to the collected data, and inform the owner platform of any changes. After the execution of the MA, the platform sends its output data to the trusted platform and then migrates to the next destination. When the agent returns to its owner carrying the collected data, a hash of the data collected at each platform is sent to the trusted platform. The trusted platform verifies the integrity of collected data and informs the owner of any malicious changes detected. The protocol is based on multihop architecture where an MA migrates from one platform to another to collect data. However, the loss of the MA results in the final loss of all the collected data.The protocol in [32] relies on a Knowledge-Based System (KBS) that collects information about hosts’ trustworthiness. The protocol is based on trusted hosts and chain relations. The MA starts at the owner host and with the help of the KBS, it chooses its next destination. The MA travel to hosts and collects data. The visited trust hosts check the integrity of all the data collected by the MA. If any modification is detected, the owner host is informed. Asymmetric encryptions and hash functions are used to provide data confidentiality, nonrepudiation, and integrity. Moreover, owner’s identity and path taken by the MA are encrypted and can only be accessed by the owner and trust hosts. However, the system’s complexity is high and introduces an operational overhead because of the expensive integrity check at trust hosts. Moreover, again the loss of the agent results in the loss of all the collected data and nonfunctionality of the system [44].The protocol proposed in [33] splits the agent code into two codes, critical and normal. The critical code is only executed at the trusted platform and the normal code is carried by the MA. The system has two trusted platforms: one is responsible for executing the critical code, while the other watches and provides the system with a recovery policy in case of a breakdown. The MA collects the data and sends it to the trusted platform to get the final result. The trusted platform starts a timer to detect replay attacks. The protocol provides confidentiality of data, integrity of data and code, and the possibility of recovering the agent code in case of modification or breakdown.A symmetric cryptography scheme is proposed in [34]. The generation and distribution of the symmetric keys are unique. Keys are derived from data generated at platforms at run time. Therefore, it becomes harder for attackers to guess or predict the keys. Agent owner authentication, confidentiality, and integrity of both code and data are provided. However, the protocol is vulnerable to replay attacks and the system functionality is affected by the loss of MA and its data.Despite the usefulness of the aforementioned protocols, they cannot satisfy all the security requirements. Moreover, as we have seen, they are impaired by some hidden assumptions and drawbacks. In order to overcome issues of the current state of the art, we propose BROSMAP which provides improvements over the previously reviewed protocols. It provides mutual authentication between users and service providers, integrity, confidentiality, accountability, authorization, and nonrepudiation. Another important feature that distinguishes BROSMAP from other protocols is its ability to continue its functionality even if one of the agents is killed. BROSMAP satisfies the security requirements and protection from MITM, replay, masquerade, unauthorized access, and modification attacks. A detailed comparison of BROSMAP with the reviewed protocols will be presented later in Section5. In the next section, a detailed description of BROSMAP is discussed, followed by security analysis and results of carried formal verification test, the performance evaluation, and implementation details with JADE.


## 4. Proposed BROSMAP

BROSMAP provides fundamental security requirements and protection from different attacks. The proposed broadcast architecture allows the system to stay functioning even if one of the MAs is maliciously killed or lost and maintain good performance at the same time.In BROSMAP, the hybrid approach of using both symmetrical and asymmetrical cryptography is used. Using the asymmetrical cryptography enables the system to provide many security requirements that are harder to cover with symmetrical cryptography such as mutual authentication, accountability, and nonrepudiation. On the other hand, using symmetrical cryptography enhances the system performance as it is lighter operational wise. Therefore, incorporating the hybrid approach provides the system with the needed security requirements maintaining the good performance at the same time.In order to explain how the interaction happens in further detail, notations and definitions are provided in (I) in “Notations” section.An illustrative scenario of the proposed BROSMAP for distributed applications is shown in Figure1. A scenario of a LBS application is used as a possible example of a distrusted application. Service providers are registered after being verified by the telecomm operator. Service providers provide their identity, address, and type of services they offer. Their reputation can also be an important factor in the registration process. We also assume that PKI has been set up. In our scenario, service providers provide users with names of possible hotels, restaurants, and flight agencies that are close to the specified location. Users are provided with different available options along with additional information about the option such as average price and distance from current location. The provided information helps users in the decision making process.Figure 1
System scenario of BROSMAP in a distributed application.Accessing the application, the user provides his/her request. Then, the request is broadcast to registered service providers. Each service provider receives the request and searches its database for matching results to be sent back. If one of the broadcast messages is lost, the user is still able to get results from the other service providers. An example of a user request would be “provide me with names of close by hotels” and a possible answer would be “Sheraton Hotel is 10 miles away and cost on average $100 per night.”BROSMAP system architecture is shown in Figure2. PLA1 is the owner platform that launches copies of the MA carrying the user request containing the location and service type to service providers. As shown, the system includes i-1 service providers platforms which are PLA2 to PLAi. The owner platform PLA1 generates MA1. MA1 carries the user request R to collect output of requests ORi from platforms, containing possible service options for users.Figure 2
BROSMAP system architecture.Next, steps of interaction between owner platform and service providers are explained in detail.


### 4.1. Stages of Interaction between Owner and Service Provider Platforms

For the sake of simplicity, here, we do not discuss certificates distribution as we assume that platforms have been verified and granted certificates by the certificate authority (CA) [45–48]. The owner platform has a prior knowledge of the available trusted service providers to be contacted for results. Service providers are service-specific servers providing information to the user. For example, some servers hold information about restaurants, some others about hotels, and so on; therefore, service providers are chosen according to the requested service. Moreover, BROSMAP sheds light on securing the MA during migration and interaction with platforms; however, the exchange and verification of certificates are out of the scope of this paper.Next, stages of interaction between owner platformPLA1 and PLAn are described. PLAn is any service provider in the system where i and n are positive integers and 2≤n≤i:(1)
Starting stage at the owner platform. The system interaction starts when the user provides the application with a request. The owner platform is the starting point. The first stage of the interaction is the preparation and broadcast of user request message to service providers platforms steps are summarized as follows:
(i)
the owner platformPLA1 does the following:
(a)
it gets requestR from user;(b)
it generates time stampT1;(c)
it generates session keyKn;(d)
it generatesh(R∥T1);(e)
it encryptsh(R∥T1) with Kn to generate Kn(h(R∥T1));(f)
it signsKn(h(R∥T1)) and addn with S1 to generate S1(Kn(h(R∥T1))∥addn);(g)
it encryptsR, addn, K1 and T1 with Pn to generate Pn(R∥addn∥Kn∥T1).(2)
Sending request to service provider platform.
(i)
PLA1→PLAn;Pn(R∥addn∥Kn∥T1)∥S1(Kn(h(R∥T1))∥addn).(3)
Processing of user request at the service provider platform. The second stage involves processing the received user requests messages at the service provider platforms:
(i)
the service provider platformPLAn does the following:
(a)
it decryptsPn(R∥addn∥Kn∥T1) with Sn to get the session key Kn;(b)
it checks freshness ofT1;(c)
it decryptsS1(Kn(h(R∥T1))∥addn) with P1 to get (Kn(h(R∥T1))∥addn);(d)
it decrypts withKn to get h(R∥T1);(e)
it checks ifh(T1∥R) in Kn(h(R∥T1)) matches hash of sent T1 and R in Pn(R∥addn∥Kn∥T1);(f)
if all checks are correct, then it executes agent and generates resultORn;(g)
it generates time stampTn;(h)
it generates hash of the resulth(ORn);(i)
it generates hash of the time stamph(Tn);(j)
it encrypts resultORn, R, add1, T1, and Tn with the session key Kn to get Kn(ORn∥R∥add1∥T1∥Tn);(k)
it signs(h(R∥T1)∥h(ORn)∥h(Tn)) with Sn to get Sn(h(R∥T1)∥h(ORn)∥h(Tn)).(4)
Sending results to owner platform.
(i)
PLAn→PLA1;Kn(ORn∥R∥add1∥T1∥Tn)∥Sn(h(R∥T1)∥h(ORn)∥h(Tn)).(5)
Processing results at owner platform. Finally, in the last stage, the owner platform receives and processes the reply messages carrying results:
(i)
platformPLA1 does the following:
(a)
it decryptsKn(ORn∥R∥add1∥T1∥Tn) with Kn;(b)
it checks freshness ofT1 and Tn;(c)
it decryptsSn(h(R∥T1)∥h(ORn)∥h(Tn)) with Pn;(d)
it checks ifh(R∥T1) in Sn(h(R∥T1)∥h(Tn)∥(h(ORn))) matches h(R∥T1) in Kn(ORn∥R∥add1∥T1∥Tn);(e)
it checks ifh(Tn) in Sn(h(R∥T1)∥h(Tn)∥(h(ORn))) matches h(Tn) in Kn(ORn∥R∥add1∥T1∥Tn);(f)
it checks ifh(ORn) in Sn(h(R∥T1)∥h(Tn)∥(h(ORn))) matches h(ORn) in Kn(ORn∥R∥add1∥T1∥Tn);(g)
if all checks are correct, it displays results to the user.Figure3 shows the messages exchanged between owner platform PLA1 and each service provider PLAn in the system.Figure 3
Summary of messages exchanged betweenPLA1 and PLAn through MA.


## 4.1. Stages of Interaction between Owner and Service Provider Platforms

For the sake of simplicity, here, we do not discuss certificates distribution as we assume that platforms have been verified and granted certificates by the certificate authority (CA) [45–48]. The owner platform has a prior knowledge of the available trusted service providers to be contacted for results. Service providers are service-specific servers providing information to the user. For example, some servers hold information about restaurants, some others about hotels, and so on; therefore, service providers are chosen according to the requested service. Moreover, BROSMAP sheds light on securing the MA during migration and interaction with platforms; however, the exchange and verification of certificates are out of the scope of this paper.Next, stages of interaction between owner platformPLA1 and PLAn are described. PLAn is any service provider in the system where i and n are positive integers and 2≤n≤i:(1)
Starting stage at the owner platform. The system interaction starts when the user provides the application with a request. The owner platform is the starting point. The first stage of the interaction is the preparation and broadcast of user request message to service providers platforms steps are summarized as follows:
(i)
the owner platformPLA1 does the following:
(a)
it gets requestR from user;(b)
it generates time stampT1;(c)
it generates session keyKn;(d)
it generatesh(R∥T1);(e)
it encryptsh(R∥T1) with Kn to generate Kn(h(R∥T1));(f)
it signsKn(h(R∥T1)) and addn with S1 to generate S1(Kn(h(R∥T1))∥addn);(g)
it encryptsR, addn, K1 and T1 with Pn to generate Pn(R∥addn∥Kn∥T1).(2)
Sending request to service provider platform.
(i)
PLA1→PLAn;Pn(R∥addn∥Kn∥T1)∥S1(Kn(h(R∥T1))∥addn).(3)
Processing of user request at the service provider platform. The second stage involves processing the received user requests messages at the service provider platforms:
(i)
the service provider platformPLAn does the following:
(a)
it decryptsPn(R∥addn∥Kn∥T1) with Sn to get the session key Kn;(b)
it checks freshness ofT1;(c)
it decryptsS1(Kn(h(R∥T1))∥addn) with P1 to get (Kn(h(R∥T1))∥addn);(d)
it decrypts withKn to get h(R∥T1);(e)
it checks ifh(T1∥R) in Kn(h(R∥T1)) matches hash of sent T1 and R in Pn(R∥addn∥Kn∥T1);(f)
if all checks are correct, then it executes agent and generates resultORn;(g)
it generates time stampTn;(h)
it generates hash of the resulth(ORn);(i)
it generates hash of the time stamph(Tn);(j)
it encrypts resultORn, R, add1, T1, and Tn with the session key Kn to get Kn(ORn∥R∥add1∥T1∥Tn);(k)
it signs(h(R∥T1)∥h(ORn)∥h(Tn)) with Sn to get Sn(h(R∥T1)∥h(ORn)∥h(Tn)).(4)
Sending results to owner platform.
(i)
PLAn→PLA1;Kn(ORn∥R∥add1∥T1∥Tn)∥Sn(h(R∥T1)∥h(ORn)∥h(Tn)).(5)
Processing results at owner platform. Finally, in the last stage, the owner platform receives and processes the reply messages carrying results:
(i)
platformPLA1 does the following:
(a)
it decryptsKn(ORn∥R∥add1∥T1∥Tn) with Kn;(b)
it checks freshness ofT1 and Tn;(c)
it decryptsSn(h(R∥T1)∥h(ORn)∥h(Tn)) with Pn;(d)
it checks ifh(R∥T1) in Sn(h(R∥T1)∥h(Tn)∥(h(ORn))) matches h(R∥T1) in Kn(ORn∥R∥add1∥T1∥Tn);(e)
it checks ifh(Tn) in Sn(h(R∥T1)∥h(Tn)∥(h(ORn))) matches h(Tn) in Kn(ORn∥R∥add1∥T1∥Tn);(f)
it checks ifh(ORn) in Sn(h(R∥T1)∥h(Tn)∥(h(ORn))) matches h(ORn) in Kn(ORn∥R∥add1∥T1∥Tn);(g)
if all checks are correct, it displays results to the user.Figure3 shows the messages exchanged between owner platform PLA1 and each service provider PLAn in the system.Figure 3
Summary of messages exchanged betweenPLA1 and PLAn through MA.


## 5. Security Analysis of BROSMAP

In this section, a security analysis of BROSMAP is provided. We show that BROSMAP provides the following security requirements:(i)
Mutual authentication: mutual authentication is the assurance that communicating entities can verify each other’s identity. Take, for example, the interaction betweenPLA1 and PLAn. Both platforms are able to identify each other through the PKI using the signatures and certificates. Also they are sure of who sent the message because of the digital signature. The messages sent are fresh due to the use of time stamps and both platforms can verify that the messages exchanged are actually intended for them because of the concatenation of the address of the destination in the message. Moreover, messages are received in order, and PLAn replies to PLA1 after it receives the request. The interaction provides all the requirements for mutual authentication; therefore, BROSMAP provides mutual authentication.(ii)
Confidentiality: the exchanged information between platforms remains secret throughout the communication due to the use of public and symmetric key encryptions. At any time, only the owner platform can access the output of the request because of the encryption with the secret session key. In addition, the user request and time stamps are also encrypted and remain confidential. The required information for decryption requires the knowledge of either the private key or the session key.(iii)
Integrity: in BROSMAP, the use of one-way hash function and signature supports a standard integrity test. The integrity of request, the output of the request, and all the time stamps are guaranteed at all times. Any change or manipulation is detected.(iv)
Accountability: BROSMAP provides accountability in the sense that if platformPLA2 decides to act maliciously and change the request, then PLA1 detects the change comparing the hashes, and PLA2 signature provides proof of its malicious action. Our protocol is proposed for distributed services applications; therefore, the architecture is made up of both users (senders) and service providers (servers). The request is broadcast from the user to the service providers. Accountability is provided to hold service providers accountable if they acted maliciously and decided, for example, to send false data or change the user request. At this stage, the user needs to know who did the malicious action and might decide to stop dealing with that server in future requests.(v)
Authorization: when the user accesses the application and provides his/her credentials, this information is verified to decide whether to grant the user access to the application services or not. In addition, the certificate authority checks the validity of the certificate and the identity of the platforms; therefore, only authorized platforms (service providers) provide the user with the service. Moreover, by providing mutual authentication, platforms are able to verify each other and any communication request or message sent by a nontrusted platform is ignored. The request, time stamps, and the output of the request are all confidential and can only be decrypted by authorized platforms.(vi)
Nonrepudiation: the signature of platforms provides proof of the originator of the message sent. In BROSMAP, platforms sign messages with their private keys providing the possibility for action traceability.The protocol also provides protection from different attacks: (i)
Replay attacks: the time stamp indicates the freshness of the message and any expired message is discarded. Both the freshness of the data and delivery are checked. Two timestamps are used. The first one is generated to stamp the time of the request generation and the second one is generated to stamp the time of the data (results) generation. The user will only consider the delivered results if and only if both timestamps are fresh; that is, the request and generated data are fresh and new.(ii)
MITM attacks: in BROSMAP, even if a malicious platform gets hold of exchanged messages, it cannot decrypt and read their content. Moreover, all data is encrypted and remains confidential. Integrity checks are provided to detect any modification. Therefore, MITM attacks are detected and fake messages or requests are dropped.(iii)
Modification attacks: a malicious platform or agent cannot modify the time stamps, the request, and the results without being detected, due to the digital signature and the integrity checks comparing hash values at each platform.(iv)
Masquerade attacks: a malicious platform cannot impersonate another platform because of the use of the digital signatures.To verify the correctness of BROSMAP, formal methods verification proof is carried using Scyther. Next, a detailed explanation of the verification tests and results are presented along with a comparison of BROSMAP and other existing protocols.


### 5.1. Formal Verification of BROSMAP

To verify BROSMAP, we selected Scyther formal methods verification tool. Scyther is a free formal analysis tool used to verify security protocols. Scyther provides a set of claims to test secrecy of information, synchronization, and authentication between communication parties. Synchronization means that messages sent are received by the intended communication party and that received messages are actually sent by the communication party. It also means that the messages sent and received are in order and their content has not been modified. Scyther also tests for aliveness of a communication party, which basically means that the party is alive and has executed some events [49–52].


#### 5.1.1. Verification Code

To verify BROSMAP, we set up a set of claims testing the secrecy of information and synchronization in the code. A set of claims tests the secrecy of the session key, private keys, request, output of request, and time stamps at the owner and the service provider platforms. Moreover, other claims test synchronization between the owner and the service provider platforms.The verification code, attached in Algorithm1, represents the protocol description in Security Protocol Description Language (SPDL) [50]. The code has two roles, the owner platform role and the service provider role. The code shows the exchanged messages in addition to the set of claims that need to be verified.Algorithm 1
(1)     usertype TimeStamp,Data,Request,Key;
(2)     hashfunction H;
(3)     macro hash1=H(Req,T1);                % hash the request and time stamp 1
(4)     macro hashofdata=H(OR);             % hash the result
(5)     macro hashoftime=H(T2);               % hash the request and time stamp 2
(6)     protocol MyProtocol(Owner, ServiceProvider)
(7)     role Owner fresh kir:Key;             % generate session key
(8)     fresh T1:TimeStamp;            % generate time stamp 1
(9)     var T2:TimeStamp;               % prepare variable to receive time stamp 2
(10)  const Req:Request;              % generate request
(11)  var OR:Data; % prepare variable to receive result
(12)send1(Owner,ServiceProvider,
(13){{hash1}kir,ServiceProvider}sk(Owner),{Req,ServiceProvider,kir,T1}pk(ServiceProvider));
(14)recv10(ServiceProvider,Owner,{hash1,hashofdata,hashoftime}sk(ServiceProvider),
(15){OR,Req,Owner,T1,T2}kir);
(16)macrohashofdata2=H(OR);           % generate hash of received result
(17)macrohashoftime2=H(T2);               % generate hash of received timestamp
(18)match(hash1,hash2);                 % compare hashes
(19)match(hashofdata,hashofdata2);
(20)match(hashoftime,hashoftime2);
(21)claimi1(Owner,Nisynch); % test Claims
(22)claimi2(Owner,Alive);
(23)claimi3(Owner,Secret,OR);
(24)claimi4(Owner,Secret,T1);
(25)claimi5(Owner,Secret,T2);
(26)claimi6(Owner,Secret,Req);
(27)claimi7(Owner,Secret,Key);
(28)claimi8(Owner,Secret,sk);
(29)
(30)  role ServiceProvider
(31)fresh OR:Data;               % generate result
(32)  var kir:Key;               % prepare variable to receive session key
(33)fresh T2:TimeStamp;               % generate time stamp 2
(34)var T1:TimeStamp;                 % prepare variable to receive time stamp 1
(35)  var Req:Request;             % prepare variable to receive request
(36)recv1(Owner,ServiceProvider,
(37)hash1kir,ServiceProviderskOwner, Req,ServiceProvider,kir,T1pkServiceProvider;
(38)  macro h2=H(Req,T1);                % generate hash of received request and time stamp 1
(39)  match (hash1,h2);              % compare hashes
(40)send10(ServiceProvider,Owner,
(41)hash1,hashofdata,hashoftimeskServiceProvider, OR,Req,Owner,T1,T2kir);
(42)claimi9(ServiceProvider,Nisynch);        % test claims
(43)claimi10(ServiceProvider,Alive);
(44)claimi11(ServiceProvider,Secret,OR);
(45)claimi12(ServiceProvider,Secret,T1);
(46)claimi13(ServiceProvider,Secret,T2);
(47)claimi14(ServiceProvider,Secret,Req);
(48)claimi15(ServiceProvider,Secret,Key);
(49)claimi16(ServiceProvider,Secret,sk);
(50)Figure4 shows the output of the verification test for the defined claims. The test verifies the secrecy of the exchanged time stamps, request, output of request, private keys, and session key. Moreover, aliveness of parties and synchronization between them are also verified.Figure 4
Output of Scyther claims test.Scyther generates trace figures (Figures5–7) showing the interaction and exchanged messages between communication parties. BROSMAP interaction can be summarized into three stages. Each stage is shown through a trace figure. Because Scyther uses its own notations that are different than the ones presented earlier, (II) in “Notations and Definitions” section reports the new notations used in Scyther traces.Figure 5
Stage 1: Owner platform: Owner#1 sends request to ServiceProvider#1.Figure 6
Stage 2: ServiceProvider#1 processes the user request and sends result back to Owner#1.Figure 7
Stage 3: Owner#1 processes the output of the result coming from ServiceProvider#1.Figure5 explains the first stage, which is the broadcast of the user request to the service provider platform. As shown in the figure, owner platform (Owner#1) sends the message to the service provider platform (ServiceProvider#1).The second stage is shown in Figure6. In this stage, ServiceProvider#1 processes the request message sent by Owner#1. ServiceProvider#1 authenticates Owner#1 and checks the integrity of sent information through the match functions. Match functions operate as a logical comparison that compares two values to check if they are equal. Match functions are used to check the integrity of the data and time stamps through comparing the hash sent in the message with the hash of the newly received data, generated on the current platform. After passing the integrity test, ServiceProvider#1 generates and sends the results back to Owner#1.The final stage is shown in Figure7, where Owner#1 receives the message sent by ServiceProvider#1 and checks the integrity of its content through the match functions. The three generated traces show that message synchronization exists between the interacting parties. Moreover, it also proves the aliveness and reachability of parties.


#### 5.1.2. Analysis of Results

In this section we discuss the mapping between the Scyther test results and the fundamental security requirements:(i)
Mutual authentication: synchronization between the owner and the service provider platforms is verified throughclaimi1, claimi2, claimi9, and claimi10 shown in Algorithm 1 in lines 21, 22, 42, and 43, respectively. Synchronization ensures that messages sent and received by intended parties are unmodified and in order. Also, the use of PKI and ensuring the secrecy of private keys provides the requirements to identify platforms and, therefore, mutual authentication exists between the two parties.(ii)
Confidentiality: time stamps, request, output of request, private key, and session key exchanged are verified for secrecy throughclaimi3 to claimi8 and claimi11 to claimi16 shown in lines 23–28 and 44–49, respectively. The data remains confidential throughout the communication.(iii)
Integrity: hash function and match operations are used to verify the integrity of the request, time stamps, and output of request. The match functions shown in lines 18–20 and 39 detect any change in the data.(iv)
Authorization: the exchanged information remains secret throughout the interaction and only authorized parties with proper decryption information can access it. This is proven through ensuring the secrecy of the exchanged session key throughclaimi7 in line 27 and claimi15 in line 48. Moreover, mutual authentication guarantees that the interaction happens between trusted parties, hence providing protection from unauthorized accesses.(v)
Accountability and nonrepudiation: using signature and verifying the secrecy of parties’ private keys inclaimi8 in line 28 and claimi16 in line 49, a party can be accounted for its malicious actions such as making changes to time stamp or request. Moreover, nonrepudiation is also provided in the sense that no party can deny data sent by it.Figure4 shows that according to Scyther, BROSMAP satisfies all the desired requirements. Also, we can state that BROSMAP provides protection from different types of attacks. Using time stamps and ensuring their secrecy and integrity provide protection from replay attacks. Synchronization and verification of secrecy of information ensure that communication between parties is secure and that there is no possibility for MITM attacks to pass without being detected. Moreover, the use of signature provides protection from masquerade attacks. A malicious party cannot masquerade as another legitimate party unless it gets hold of its private key; however, it is verified through claimi8 and claimi16 that private keys remain confidential throughout the communication. In addition, any malicious unauthorized modification of time stamps, results, and requests is detected and the message is discarded; therefore, modification attacks are also eliminated.A comparison between protocols in related work and BROSMAP is carried out. The criteria scheme used for comparison is whether the protocol provides the following security requirements: anonymity, authentication, authorization, accountability, confidentiality, integrity, and nonrepudiation. None of the proposed works provides availability; therefore it is not included in Table1.Table 1
Comparison of related works and BROSMAP.
Related works
Anonymity
Authentication
Authorization
Accountability
Confidentiality
Integrity
Nonrepudiation
Raji and Tork Ladani, 2010 [22]
Yes
No
Yes
No
Yes
No
No
Kuo et al., 2014 [23]
Yes
Yes (mutual)
Yes
No
No
No
No
Leszczyna, 2007 [24]
Yes
No
No
No
No
No
No
Garrigues et al., 2008 [25]
No
Yes (mutual)
Yes
No
No
No
No
Garrigues et al., 2009 [28]
No
Yes (mutual)
Yes
No
No
No
No
Fong et al., 2011 [26]
No
(one-way)
Yes
No
Yes
No
No
Venkatesan et al., 2010 (MIP) [27]
No
(one-way)
Yes
No
No
No
No
Venkatesan et al., 2010 (XRC) [27]
No
(one-way)
No
No
No
No
Yes
Kapnoullas et al., 2003 [41]
No
(one-way)
Yes
No
No
No
Yes
Dhanalakshmi and Nawaz, 2012 [29]
No
No
No
No
No
No
No
Sulaiman et al., 2009 [43]
No
Yes (mutual)
Yes
No
Yes
No
No
Guan et al., 2007 [31]
No
Yes (mutual)
Yes
No
Yes
Yes
Yes
Geetha and Jayakumar, 2011 [32]
Yes
No
No
No
Yes
Yes
Yes
Ouardani et al., 2007 [33]
No
Yes (mutual)
No
No
Yes
Yes
No
Srivastava and Nandi, 2014 [34]
No
(one-way)
No
No
Yes
Yes
No
BROSMAP
No
Yes (mutual)
Yes
Yes
Yes
Yes
YesTable1 shows the detailed comparison. As shown, most of the compared works passed two or three of the seven security requirements, while [31] is found to provide five. BROSMAP, however, is the only protocol that provides six of the seven requirements. BROSMAP provides mutual authentication, authorization, accountability, confidentiality, integrity, and nonrepudiation.Another two important comparison factors are whether the protocol takes into consideration the effect of potential loss or killing of an agent and if the proposed protocol is verified by any security verification tool. These two factors are important because the first affects the system functionality and the other verifies the correctness of the proposed protocol. In the related works, only [31, 33] consider agent loss by proposing the matrix hop and recovery method, respectively. Moreover, the only work that verified its proposed protocol is [28] and was proven to withstand all simulated replay attacks in JADE; however, none of the other works used formal verification methods. In BROSMAP, the two criteria are also covered. BROSMAP considers agent loss in the system by broadcasting simultaneously. Moreover, its correctness is proven through formal verification proof with Scyther as was previously explained in this section. Therefore, among the compared works BROSMAP is the only protocol that provides a proof of correctness through formal verification method.In the next section, the performance of BROSMAP is evaluated and compared to the other protocols.


## 5.1. Formal Verification of BROSMAP

To verify BROSMAP, we selected Scyther formal methods verification tool. Scyther is a free formal analysis tool used to verify security protocols. Scyther provides a set of claims to test secrecy of information, synchronization, and authentication between communication parties. Synchronization means that messages sent are received by the intended communication party and that received messages are actually sent by the communication party. It also means that the messages sent and received are in order and their content has not been modified. Scyther also tests for aliveness of a communication party, which basically means that the party is alive and has executed some events [49–52].


### 5.1.1. Verification Code

To verify BROSMAP, we set up a set of claims testing the secrecy of information and synchronization in the code. A set of claims tests the secrecy of the session key, private keys, request, output of request, and time stamps at the owner and the service provider platforms. Moreover, other claims test synchronization between the owner and the service provider platforms.The verification code, attached in Algorithm1, represents the protocol description in Security Protocol Description Language (SPDL) [50]. The code has two roles, the owner platform role and the service provider role. The code shows the exchanged messages in addition to the set of claims that need to be verified.Algorithm 1
(1)     usertype TimeStamp,Data,Request,Key;
(2)     hashfunction H;
(3)     macro hash1=H(Req,T1);                % hash the request and time stamp 1
(4)     macro hashofdata=H(OR);             % hash the result
(5)     macro hashoftime=H(T2);               % hash the request and time stamp 2
(6)     protocol MyProtocol(Owner, ServiceProvider)
(7)     role Owner fresh kir:Key;             % generate session key
(8)     fresh T1:TimeStamp;            % generate time stamp 1
(9)     var T2:TimeStamp;               % prepare variable to receive time stamp 2
(10)  const Req:Request;              % generate request
(11)  var OR:Data; % prepare variable to receive result
(12)send1(Owner,ServiceProvider,
(13){{hash1}kir,ServiceProvider}sk(Owner),{Req,ServiceProvider,kir,T1}pk(ServiceProvider));
(14)recv10(ServiceProvider,Owner,{hash1,hashofdata,hashoftime}sk(ServiceProvider),
(15){OR,Req,Owner,T1,T2}kir);
(16)macrohashofdata2=H(OR);           % generate hash of received result
(17)macrohashoftime2=H(T2);               % generate hash of received timestamp
(18)match(hash1,hash2);                 % compare hashes
(19)match(hashofdata,hashofdata2);
(20)match(hashoftime,hashoftime2);
(21)claimi1(Owner,Nisynch); % test Claims
(22)claimi2(Owner,Alive);
(23)claimi3(Owner,Secret,OR);
(24)claimi4(Owner,Secret,T1);
(25)claimi5(Owner,Secret,T2);
(26)claimi6(Owner,Secret,Req);
(27)claimi7(Owner,Secret,Key);
(28)claimi8(Owner,Secret,sk);
(29)
(30)  role ServiceProvider
(31)fresh OR:Data;               % generate result
(32)  var kir:Key;               % prepare variable to receive session key
(33)fresh T2:TimeStamp;               % generate time stamp 2
(34)var T1:TimeStamp;                 % prepare variable to receive time stamp 1
(35)  var Req:Request;             % prepare variable to receive request
(36)recv1(Owner,ServiceProvider,
(37)hash1kir,ServiceProviderskOwner, Req,ServiceProvider,kir,T1pkServiceProvider;
(38)  macro h2=H(Req,T1);                % generate hash of received request and time stamp 1
(39)  match (hash1,h2);              % compare hashes
(40)send10(ServiceProvider,Owner,
(41)hash1,hashofdata,hashoftimeskServiceProvider, OR,Req,Owner,T1,T2kir);
(42)claimi9(ServiceProvider,Nisynch);        % test claims
(43)claimi10(ServiceProvider,Alive);
(44)claimi11(ServiceProvider,Secret,OR);
(45)claimi12(ServiceProvider,Secret,T1);
(46)claimi13(ServiceProvider,Secret,T2);
(47)claimi14(ServiceProvider,Secret,Req);
(48)claimi15(ServiceProvider,Secret,Key);
(49)claimi16(ServiceProvider,Secret,sk);
(50)Figure4 shows the output of the verification test for the defined claims. The test verifies the secrecy of the exchanged time stamps, request, output of request, private keys, and session key. Moreover, aliveness of parties and synchronization between them are also verified.Figure 4
Output of Scyther claims test.Scyther generates trace figures (Figures5–7) showing the interaction and exchanged messages between communication parties. BROSMAP interaction can be summarized into three stages. Each stage is shown through a trace figure. Because Scyther uses its own notations that are different than the ones presented earlier, (II) in “Notations and Definitions” section reports the new notations used in Scyther traces.Figure 5
Stage 1: Owner platform: Owner#1 sends request to ServiceProvider#1.Figure 6
Stage 2: ServiceProvider#1 processes the user request and sends result back to Owner#1.Figure 7
Stage 3: Owner#1 processes the output of the result coming from ServiceProvider#1.Figure5 explains the first stage, which is the broadcast of the user request to the service provider platform. As shown in the figure, owner platform (Owner#1) sends the message to the service provider platform (ServiceProvider#1).The second stage is shown in Figure6. In this stage, ServiceProvider#1 processes the request message sent by Owner#1. ServiceProvider#1 authenticates Owner#1 and checks the integrity of sent information through the match functions. Match functions operate as a logical comparison that compares two values to check if they are equal. Match functions are used to check the integrity of the data and time stamps through comparing the hash sent in the message with the hash of the newly received data, generated on the current platform. After passing the integrity test, ServiceProvider#1 generates and sends the results back to Owner#1.The final stage is shown in Figure7, where Owner#1 receives the message sent by ServiceProvider#1 and checks the integrity of its content through the match functions. The three generated traces show that message synchronization exists between the interacting parties. Moreover, it also proves the aliveness and reachability of parties.


### 5.1.2. Analysis of Results

In this section we discuss the mapping between the Scyther test results and the fundamental security requirements:(i)
Mutual authentication: synchronization between the owner and the service provider platforms is verified throughclaimi1, claimi2, claimi9, and claimi10 shown in Algorithm 1 in lines 21, 22, 42, and 43, respectively. Synchronization ensures that messages sent and received by intended parties are unmodified and in order. Also, the use of PKI and ensuring the secrecy of private keys provides the requirements to identify platforms and, therefore, mutual authentication exists between the two parties.(ii)
Confidentiality: time stamps, request, output of request, private key, and session key exchanged are verified for secrecy throughclaimi3 to claimi8 and claimi11 to claimi16 shown in lines 23–28 and 44–49, respectively. The data remains confidential throughout the communication.(iii)
Integrity: hash function and match operations are used to verify the integrity of the request, time stamps, and output of request. The match functions shown in lines 18–20 and 39 detect any change in the data.(iv)
Authorization: the exchanged information remains secret throughout the interaction and only authorized parties with proper decryption information can access it. This is proven through ensuring the secrecy of the exchanged session key throughclaimi7 in line 27 and claimi15 in line 48. Moreover, mutual authentication guarantees that the interaction happens between trusted parties, hence providing protection from unauthorized accesses.(v)
Accountability and nonrepudiation: using signature and verifying the secrecy of parties’ private keys inclaimi8 in line 28 and claimi16 in line 49, a party can be accounted for its malicious actions such as making changes to time stamp or request. Moreover, nonrepudiation is also provided in the sense that no party can deny data sent by it.Figure4 shows that according to Scyther, BROSMAP satisfies all the desired requirements. Also, we can state that BROSMAP provides protection from different types of attacks. Using time stamps and ensuring their secrecy and integrity provide protection from replay attacks. Synchronization and verification of secrecy of information ensure that communication between parties is secure and that there is no possibility for MITM attacks to pass without being detected. Moreover, the use of signature provides protection from masquerade attacks. A malicious party cannot masquerade as another legitimate party unless it gets hold of its private key; however, it is verified through claimi8 and claimi16 that private keys remain confidential throughout the communication. In addition, any malicious unauthorized modification of time stamps, results, and requests is detected and the message is discarded; therefore, modification attacks are also eliminated.A comparison between protocols in related work and BROSMAP is carried out. The criteria scheme used for comparison is whether the protocol provides the following security requirements: anonymity, authentication, authorization, accountability, confidentiality, integrity, and nonrepudiation. None of the proposed works provides availability; therefore it is not included in Table1.Table 1
Comparison of related works and BROSMAP.
Related works
Anonymity
Authentication
Authorization
Accountability
Confidentiality
Integrity
Nonrepudiation
Raji and Tork Ladani, 2010 [22]
Yes
No
Yes
No
Yes
No
No
Kuo et al., 2014 [23]
Yes
Yes (mutual)
Yes
No
No
No
No
Leszczyna, 2007 [24]
Yes
No
No
No
No
No
No
Garrigues et al., 2008 [25]
No
Yes (mutual)
Yes
No
No
No
No
Garrigues et al., 2009 [28]
No
Yes (mutual)
Yes
No
No
No
No
Fong et al., 2011 [26]
No
(one-way)
Yes
No
Yes
No
No
Venkatesan et al., 2010 (MIP) [27]
No
(one-way)
Yes
No
No
No
No
Venkatesan et al., 2010 (XRC) [27]
No
(one-way)
No
No
No
No
Yes
Kapnoullas et al., 2003 [41]
No
(one-way)
Yes
No
No
No
Yes
Dhanalakshmi and Nawaz, 2012 [29]
No
No
No
No
No
No
No
Sulaiman et al., 2009 [43]
No
Yes (mutual)
Yes
No
Yes
No
No
Guan et al., 2007 [31]
No
Yes (mutual)
Yes
No
Yes
Yes
Yes
Geetha and Jayakumar, 2011 [32]
Yes
No
No
No
Yes
Yes
Yes
Ouardani et al., 2007 [33]
No
Yes (mutual)
No
No
Yes
Yes
No
Srivastava and Nandi, 2014 [34]
No
(one-way)
No
No
Yes
Yes
No
BROSMAP
No
Yes (mutual)
Yes
Yes
Yes
Yes
YesTable1 shows the detailed comparison. As shown, most of the compared works passed two or three of the seven security requirements, while [31] is found to provide five. BROSMAP, however, is the only protocol that provides six of the seven requirements. BROSMAP provides mutual authentication, authorization, accountability, confidentiality, integrity, and nonrepudiation.Another two important comparison factors are whether the protocol takes into consideration the effect of potential loss or killing of an agent and if the proposed protocol is verified by any security verification tool. These two factors are important because the first affects the system functionality and the other verifies the correctness of the proposed protocol. In the related works, only [31, 33] consider agent loss by proposing the matrix hop and recovery method, respectively. Moreover, the only work that verified its proposed protocol is [28] and was proven to withstand all simulated replay attacks in JADE; however, none of the other works used formal verification methods. In BROSMAP, the two criteria are also covered. BROSMAP considers agent loss in the system by broadcasting simultaneously. Moreover, its correctness is proven through formal verification proof with Scyther as was previously explained in this section. Therefore, among the compared works BROSMAP is the only protocol that provides a proof of correctness through formal verification method.In the next section, the performance of BROSMAP is evaluated and compared to the other protocols.


## 5.1.1. Verification Code

To verify BROSMAP, we set up a set of claims testing the secrecy of information and synchronization in the code. A set of claims tests the secrecy of the session key, private keys, request, output of request, and time stamps at the owner and the service provider platforms. Moreover, other claims test synchronization between the owner and the service provider platforms.The verification code, attached in Algorithm1, represents the protocol description in Security Protocol Description Language (SPDL) [50]. The code has two roles, the owner platform role and the service provider role. The code shows the exchanged messages in addition to the set of claims that need to be verified.Algorithm 1
(1)     usertype TimeStamp,Data,Request,Key;
(2)     hashfunction H;
(3)     macro hash1=H(Req,T1);                % hash the request and time stamp 1
(4)     macro hashofdata=H(OR);             % hash the result
(5)     macro hashoftime=H(T2);               % hash the request and time stamp 2
(6)     protocol MyProtocol(Owner, ServiceProvider)
(7)     role Owner fresh kir:Key;             % generate session key
(8)     fresh T1:TimeStamp;            % generate time stamp 1
(9)     var T2:TimeStamp;               % prepare variable to receive time stamp 2
(10)  const Req:Request;              % generate request
(11)  var OR:Data; % prepare variable to receive result
(12)send1(Owner,ServiceProvider,
(13){{hash1}kir,ServiceProvider}sk(Owner),{Req,ServiceProvider,kir,T1}pk(ServiceProvider));
(14)recv10(ServiceProvider,Owner,{hash1,hashofdata,hashoftime}sk(ServiceProvider),
(15){OR,Req,Owner,T1,T2}kir);
(16)macrohashofdata2=H(OR);           % generate hash of received result
(17)macrohashoftime2=H(T2);               % generate hash of received timestamp
(18)match(hash1,hash2);                 % compare hashes
(19)match(hashofdata,hashofdata2);
(20)match(hashoftime,hashoftime2);
(21)claimi1(Owner,Nisynch); % test Claims
(22)claimi2(Owner,Alive);
(23)claimi3(Owner,Secret,OR);
(24)claimi4(Owner,Secret,T1);
(25)claimi5(Owner,Secret,T2);
(26)claimi6(Owner,Secret,Req);
(27)claimi7(Owner,Secret,Key);
(28)claimi8(Owner,Secret,sk);
(29)
(30)  role ServiceProvider
(31)fresh OR:Data;               % generate result
(32)  var kir:Key;               % prepare variable to receive session key
(33)fresh T2:TimeStamp;               % generate time stamp 2
(34)var T1:TimeStamp;                 % prepare variable to receive time stamp 1
(35)  var Req:Request;             % prepare variable to receive request
(36)recv1(Owner,ServiceProvider,
(37)hash1kir,ServiceProviderskOwner, Req,ServiceProvider,kir,T1pkServiceProvider;
(38)  macro h2=H(Req,T1);                % generate hash of received request and time stamp 1
(39)  match (hash1,h2);              % compare hashes
(40)send10(ServiceProvider,Owner,
(41)hash1,hashofdata,hashoftimeskServiceProvider, OR,Req,Owner,T1,T2kir);
(42)claimi9(ServiceProvider,Nisynch);        % test claims
(43)claimi10(ServiceProvider,Alive);
(44)claimi11(ServiceProvider,Secret,OR);
(45)claimi12(ServiceProvider,Secret,T1);
(46)claimi13(ServiceProvider,Secret,T2);
(47)claimi14(ServiceProvider,Secret,Req);
(48)claimi15(ServiceProvider,Secret,Key);
(49)claimi16(ServiceProvider,Secret,sk);
(50)Figure4 shows the output of the verification test for the defined claims. The test verifies the secrecy of the exchanged time stamps, request, output of request, private keys, and session key. Moreover, aliveness of parties and synchronization between them are also verified.Figure 4
Output of Scyther claims test.Scyther generates trace figures (Figures5–7) showing the interaction and exchanged messages between communication parties. BROSMAP interaction can be summarized into three stages. Each stage is shown through a trace figure. Because Scyther uses its own notations that are different than the ones presented earlier, (II) in “Notations and Definitions” section reports the new notations used in Scyther traces.Figure 5
Stage 1: Owner platform: Owner#1 sends request to ServiceProvider#1.Figure 6
Stage 2: ServiceProvider#1 processes the user request and sends result back to Owner#1.Figure 7
Stage 3: Owner#1 processes the output of the result coming from ServiceProvider#1.Figure5 explains the first stage, which is the broadcast of the user request to the service provider platform. As shown in the figure, owner platform (Owner#1) sends the message to the service provider platform (ServiceProvider#1).The second stage is shown in Figure6. In this stage, ServiceProvider#1 processes the request message sent by Owner#1. ServiceProvider#1 authenticates Owner#1 and checks the integrity of sent information through the match functions. Match functions operate as a logical comparison that compares two values to check if they are equal. Match functions are used to check the integrity of the data and time stamps through comparing the hash sent in the message with the hash of the newly received data, generated on the current platform. After passing the integrity test, ServiceProvider#1 generates and sends the results back to Owner#1.The final stage is shown in Figure7, where Owner#1 receives the message sent by ServiceProvider#1 and checks the integrity of its content through the match functions. The three generated traces show that message synchronization exists between the interacting parties. Moreover, it also proves the aliveness and reachability of parties.


## 5.1.2. Analysis of Results

In this section we discuss the mapping between the Scyther test results and the fundamental security requirements:(i)
Mutual authentication: synchronization between the owner and the service provider platforms is verified throughclaimi1, claimi2, claimi9, and claimi10 shown in Algorithm 1 in lines 21, 22, 42, and 43, respectively. Synchronization ensures that messages sent and received by intended parties are unmodified and in order. Also, the use of PKI and ensuring the secrecy of private keys provides the requirements to identify platforms and, therefore, mutual authentication exists between the two parties.(ii)
Confidentiality: time stamps, request, output of request, private key, and session key exchanged are verified for secrecy throughclaimi3 to claimi8 and claimi11 to claimi16 shown in lines 23–28 and 44–49, respectively. The data remains confidential throughout the communication.(iii)
Integrity: hash function and match operations are used to verify the integrity of the request, time stamps, and output of request. The match functions shown in lines 18–20 and 39 detect any change in the data.(iv)
Authorization: the exchanged information remains secret throughout the interaction and only authorized parties with proper decryption information can access it. This is proven through ensuring the secrecy of the exchanged session key throughclaimi7 in line 27 and claimi15 in line 48. Moreover, mutual authentication guarantees that the interaction happens between trusted parties, hence providing protection from unauthorized accesses.(v)
Accountability and nonrepudiation: using signature and verifying the secrecy of parties’ private keys inclaimi8 in line 28 and claimi16 in line 49, a party can be accounted for its malicious actions such as making changes to time stamp or request. Moreover, nonrepudiation is also provided in the sense that no party can deny data sent by it.Figure4 shows that according to Scyther, BROSMAP satisfies all the desired requirements. Also, we can state that BROSMAP provides protection from different types of attacks. Using time stamps and ensuring their secrecy and integrity provide protection from replay attacks. Synchronization and verification of secrecy of information ensure that communication between parties is secure and that there is no possibility for MITM attacks to pass without being detected. Moreover, the use of signature provides protection from masquerade attacks. A malicious party cannot masquerade as another legitimate party unless it gets hold of its private key; however, it is verified through claimi8 and claimi16 that private keys remain confidential throughout the communication. In addition, any malicious unauthorized modification of time stamps, results, and requests is detected and the message is discarded; therefore, modification attacks are also eliminated.A comparison between protocols in related work and BROSMAP is carried out. The criteria scheme used for comparison is whether the protocol provides the following security requirements: anonymity, authentication, authorization, accountability, confidentiality, integrity, and nonrepudiation. None of the proposed works provides availability; therefore it is not included in Table1.Table 1
Comparison of related works and BROSMAP.
Related works
Anonymity
Authentication
Authorization
Accountability
Confidentiality
Integrity
Nonrepudiation
Raji and Tork Ladani, 2010 [22]
Yes
No
Yes
No
Yes
No
No
Kuo et al., 2014 [23]
Yes
Yes (mutual)
Yes
No
No
No
No
Leszczyna, 2007 [24]
Yes
No
No
No
No
No
No
Garrigues et al., 2008 [25]
No
Yes (mutual)
Yes
No
No
No
No
Garrigues et al., 2009 [28]
No
Yes (mutual)
Yes
No
No
No
No
Fong et al., 2011 [26]
No
(one-way)
Yes
No
Yes
No
No
Venkatesan et al., 2010 (MIP) [27]
No
(one-way)
Yes
No
No
No
No
Venkatesan et al., 2010 (XRC) [27]
No
(one-way)
No
No
No
No
Yes
Kapnoullas et al., 2003 [41]
No
(one-way)
Yes
No
No
No
Yes
Dhanalakshmi and Nawaz, 2012 [29]
No
No
No
No
No
No
No
Sulaiman et al., 2009 [43]
No
Yes (mutual)
Yes
No
Yes
No
No
Guan et al., 2007 [31]
No
Yes (mutual)
Yes
No
Yes
Yes
Yes
Geetha and Jayakumar, 2011 [32]
Yes
No
No
No
Yes
Yes
Yes
Ouardani et al., 2007 [33]
No
Yes (mutual)
No
No
Yes
Yes
No
Srivastava and Nandi, 2014 [34]
No
(one-way)
No
No
Yes
Yes
No
BROSMAP
No
Yes (mutual)
Yes
Yes
Yes
Yes
YesTable1 shows the detailed comparison. As shown, most of the compared works passed two or three of the seven security requirements, while [31] is found to provide five. BROSMAP, however, is the only protocol that provides six of the seven requirements. BROSMAP provides mutual authentication, authorization, accountability, confidentiality, integrity, and nonrepudiation.Another two important comparison factors are whether the protocol takes into consideration the effect of potential loss or killing of an agent and if the proposed protocol is verified by any security verification tool. These two factors are important because the first affects the system functionality and the other verifies the correctness of the proposed protocol. In the related works, only [31, 33] consider agent loss by proposing the matrix hop and recovery method, respectively. Moreover, the only work that verified its proposed protocol is [28] and was proven to withstand all simulated replay attacks in JADE; however, none of the other works used formal verification methods. In BROSMAP, the two criteria are also covered. BROSMAP considers agent loss in the system by broadcasting simultaneously. Moreover, its correctness is proven through formal verification proof with Scyther as was previously explained in this section. Therefore, among the compared works BROSMAP is the only protocol that provides a proof of correctness through formal verification method.In the next section, the performance of BROSMAP is evaluated and compared to the other protocols.


## 6. Performance Evaluation of BROSMAP

To evaluate the performance of BROSMAP, the total number of operations is approximated and compared to the other protocols. To give a fair comparison between BROSMAP and the other protocols, the widely accepted evaluation method used in [23] is applied. According to [23, 53], the computational cost of an asymmetric operation (A) is equivalent to one point operation which is equivalent to 1000 symmetrical operations (S) and 10000 hash operations (H). Therefore, every asymmetrical, symmetrical, and hash operation is evaluated as 1, 0.001, and 0.0001 point operations, respectively.Besides BROSMAP, the total number of operations is approximated for the following schemes [27, 31–34]. These schemes are chosen because they are similar to BROSMAP in the sense that they are also based on cryptographic techniques. The total number of operations depends on N, which is the number of platforms the MA visits to collect results in a MAS. In Table 2, the total number of operations for each scheme is calculated.Table 2
Comparison of related protocols according to number of operations.
Scheme
Total operations for system withN platforms
Guan et al., 2007 [31]
(
11
A
+
4
H
)
×
N
+
6
A
+
2
H
=
11.0004
×
N
+
6.002
Srivastava and Nandi, 2014 [34]
(
6
A
+
2
S
+
6
H
)
×
N
+
4
A
+
S
+
2
H
=
6.0205
×
N
+
4.0012
Ouardani et al., 2007 [33]
12
A
×
N
=
12
×
N
Venkatesan et al., 2010 (XRC) [27]
(
3
A
+
H
)
×
N
+
(
1
A
+
H
)
=
3.0001
×
N
+
1.0001
Geetha and Jayakumar, 2011 [32]
(
8
A
+
3
H
)
×
N
+
(
2
A
+
H
)
=
8.0003
×
N
+
2.0001
BROSMAP
(
6
A
+
4
S
+
6
H
)
×
N
=
6.0046
×
NTo evaluate the performance of protocols, the increase in the number of operations as the number of service providersN increases is studied. Figure 8 shows the change in the total number of approximated operations as N increases.Figure 8
Performance of BROSMAP compared to other proposed protocols.The key point that affects performance is the number of asymmetrical operations as they have the highest computational cost. The protocol in [33] is based on asymmetrical operations only and protocol in [31] is based on asymmetrical and hash operations. For this reason, they show the greatest increase in the number of operations as N increases. The protocol in [27] is also an asymmetrical based scheme; however protocol in [27] uses digital signature to provide integrity to agent code and protection from nonrepudiation attacks only. The approach in [32] uses asymmetrical and hash operations to provide anonymity, confidentiality, integrity, and nonrepudiation. Moreover, the protocol performance not only is dependent on N but also depends on a number of trusted hosts that the MA visits during its journey. To approximate the number of operations for this scheme, we assume that only one trust host is visited; therefore, the approximation represents the minimum number of operations the system can have. The other schemes rely on the hybrid approach which, as Figure 8 shows, is more efficient; it has a lower overall computational cost compared to the other schemes. Despite the fact that the approach in [34] is multihop and BROSMAP is based on broadcast architecture, BROSMAP performs better than [34] as the number of platforms increases. Moreover, as previously mentioned, the protocol provides one-way authentication, confidentiality, and integrity only. It is also vulnerable to replay attacks and does not consider the case of loss or malicious killing of MA causing the system to lose all the data collected by the MA. BROSMAP provides mutual authentication, authorization, integrity, confidentiality, accountability, and nonrepudiation. In addition, it also provides protection from different attacks such as replay, MITM, masquerade, and repudiation attacks. In BROSMAP, malicious killing of an MA in the system does not mean the loss of the whole data, but rather part of the data is lost; however, there are other copies of MAs that can compensate and carry on the system functionality. Taking all that into consideration, the number of operations of BROSMAP is acceptable. While BROSMAP is not the most efficient protocol, the performance of the system seems reasonable compared to other schemes that satisfy fewer security requirements.


## 7. Implementation of Possible Distributed Service Application: LBS

To verify the viability of BROSMAP, implementation of an example of a LBS application that uses BROSMAP for securing its communication on the well-known JADE [16, 17] platform is provided. In this paper, LBS applications were chosen because of their popularity among users; however, it is important to note that the proposed BROSMAP can be used with any other distributed application. According to the scenario of Section 4, the application provides users with names of possible hotels, restaurants, and flight agencies that are close to the specified location. Users are provided with different options and some information about each option, such as the average price and distance from current location. To simulate the application, four containers were created the MainContainer, Container-1, Container-2, and Container-3; see Figure 9.Figure 9
Basic architecture of JADE setup.MainContainer represents the owner platform, while the other containers are the service providers platforms. Both mobile and stationary agents are used. MAs called owner agents carry the owner request to the service providers to collect results. Other agents reside in the service provider platform that communicates with owner MAs to process the request and exchange results. At the MainContainer, three MAs of the type owner are created, Owner1, Owner2, and Owner3.The user request is broadcast where each copy of owner agent carries the user request to a different service provider. Three stationary agents (ServiceProvider1, ServiceProvider2, and ServiceProvider3) are created at each service provider. Figure10 shows the containers and agents in JADE prior to the interaction process.Figure 10
Simulated container and agents in JADE.JADE provides the user with the option of sniffing messages exchanged between two parties. A sniffer agent, mySniffer, is created at each container to trace interactions between the owner agents and service providers’ agents. Figure11 shows sniffed messages that are exchanged between the owner and service providers during the process of the user request and sending of results.Figure 11
Traced exchanged messages in JADE.The content of one of the sniffed messages from Owner1 to ServiceProvider1 is shown in Figure12. Message content is encrypted and can only be read after proper decryption at the intended destination.Figure 12
Message sniffed from ServiceProvider1 to Owner1.Figure13 shows the result of a successful interaction between the owner and service providers. The final results collected by MAs are printed to the user containing the name of the hotel, distance from location, and approximate average price for one night stay.Figure 13
Final results displayed to user.


## 8. Conclusions

We presented a novel BROadcast based Secure Mobile Agent Protocol (BROSMAP) for real-time distributed applications. The proposed broadcast architecture of MA and hybrid approach of using symmetric and asymmetric cryptography provides distributed applications with efficiency, good performance, and security. The proposed protocol introduces the broadcast architecture for mobile agent systems, where copies of the agent are sent to different service providers simultaneously. It also provides the fundamental security requirements of mutual authentication, authorization, integrity, confidentiality, accountability, and nonrepudiation. BROSMAP was also proven to withstand many attacks such as replay, man in the middle, masquerade, unauthorized access, and modification attacks. Moreover, the broadcast architecture enables the system to continue its functionality in a flawless manner even if one of the agents is maliciously killed or lost. Formal verification test was carried out with the Scyther verification tool, which proved the protocol correctness in providing the different security requirements and protection from the different malicious attacks. Performance analysis was also carried out to study the efficiency of the proposed protocol compared to other related protocols. The conducted performance analysis showed that BROSMAP number of operations is reasonable in relation to the security features it provides. Finally, a scenario of a LBS application that incorporates BROSMAP to secure its communication is implemented with JADE. Implementation with JADE proves the viability of the proposed protocol and ability to provide protection for users.For the future work, we are planning to enhance the system by incorporating a trust model to help users evaluate the honesty and behavior of service providers. Moreover, BROSMAP will be extended to provide availability and anonymity to cover the seven security requirements. Moreover, another interesting area for research is investigating the possibility of enhancing BROSMAP to cover rational attacks in applications such as service provisioning.



---

*Source: 3606424-2017-03-29.xml*