Self-reliant mobile code: a new direction of agent security

Self-reliant mobile code: a new direction of agent security

Shashank Srivastava

, G.C. Nandi

Indian Institute Of Information Technology, Allahabad, India

a r t i c l e

i n f o

Article history: Received 3 April 2012 Received in revised form 16 December 2012 Accepted 11 January 2013

Keywords:

Mobile agent security Self-protection JADE Formal proof

Integrity based confidentiality

a b s t r a c t

The motivation for using mobile agent technology in the context of distributed application stems from its various advantages like intelligence, mobility, communication ability and fault tolerance capability. As every technological movement is aligned with its repercussions, the mobile agent technology also has its inherent security loop holes. Researchers have proposed various approaches to mitigate security bottlenecks but the threat of malicious execution environment in permissible and effectual conduct is still vague and unresolved.

In this paper, we introduced a security protocol to protect mobile agent from different kinds of security attacks. The basic building blocks of our protocol are built on the foundation of integrity based confidentiality and self-protection approach based on agent driven security. The general idea behind self-protection is to make mobile agent less interactive during its execution. In order to achieve agent driven security, we bring forth a novel concept of symmetric key’s component distribution, wherein a key component is distributed in secure manner and other key component is derived from ensuring integrity of data collected at run time. In order to verify the validity of our approach in overcoming different kind of security attacks, we present Petri net based formal representation of our protocol to strengthen the belief of distributed applications. In addition, we implement our approach on JADE (Java agent development framework) platform and compare it with well-known self-protection approach on the basis of computational complexity and services offered.

&_{2013 Elsevier Ltd. All rights reserved.}

1. Introduction

The recent advancement in distributed application and perva-siveness of mobile agent technology offers new opportunities for various digital platforms like e-commerce, e-auctions, e-marketplace etc. to enhance the efficiency and effectiveness of the application rollout. ‘Mobile agent is a self-contained software entity bundled with executable code, data and execution state which has ability to move from one host to another’.

Mobile agent has enough intelligence to take the decision according to its environmental changes which saves its execution state at each host during its itinerary so that on occurrence of fault, it resumes its last execution state and starts from the saved state. A variety of advantages have been pioneered due to certain characteristics of mobile agent like intelligence, auton-omy, adaptability, flexibility etc. (Lange and Oshima, 1999;Jansen and Karygiannis, 2000).

In agent based infrastructure, computational code moves to data location that resides on remote platform where it performs computation on resource data and sends computational result

back to the agent owner. The migration of computation to the remote data location makes mobile agent superior than other kinds of communication system, but this feature makes the mobile agent system vulnerable and paves way for many attacks to take place.

Various researchers have been looking ahead with this agent technology acknowledging the multiple advantages but due to challenges probing the security concerns revokes the global accep-tance on a common platform. Last decade has shown numerous efforts from researchers providing techniques to overcome security but malicious execution environment still exists as a hindrance in the way to deploy this technology in a wide domain.

In agent based infrastructure, two entities participate in whole communication and computation. One is home platform, where the agent owner is responsible for agent creation; other is host platform which executes the agent. Malicious entity can perform various attacks on agent’s component when agent traverses in the communication channel. So security over com-municational channel needs to be established. Secondly when agent migrates from one execution environment to other, it provides its control to execution environment which makes it vulnerable to different types of security attacks that could be performed through execution (Borselius, 2002; Sander and Tschudin, 1998;Macrides, 2002).

Contents lists available atSciVerse ScienceDirect

journal homepage:www.elsevier.com/locate/jnca

Journal of Network and Computer Applications

1084-8045/$ - see front matter&2013 Elsevier Ltd. All rights reserved. http://dx.doi.org/10.1016/j.jnca.2013.01.004

n

Corresponding author. Tel.:þ91 9984905199.

Our research provides a new direction to agent driven security primarily targeting confidentiality and integrity concerns of mobile agent security during communication channel or on execution platform vulnerable to the following security threats:

Insecure communication channel Malicious execution environment

Generally encryption is provided to maintain the confidenti-ality factor of the information. Encryption using single shared key known as symmetric encryption is used for sending large amount of data. It is computationally efficient but fails to provide authentication and integrity. To overcome the said challenges and enhance security, asymmetric encryption concept was built in but it lags in providing efficient computational factor.

In this paper, we have proposed a security protocol which is influenced by the novel concept of self-protection and it provides privacy based on integrity assurance (Lee et al., 2005). This approach provides real time verifiable type of protection, which ensures privacy with integrity through a single process of integ-rity based encryption. To provide secuinteg-rity to the agent based paradigm, the symmetric key’s component is responsible for encryption.

Our protocol generates the symmetric key composed of two key components. One component is delivered to the destination in encrypted form through asymmetric encryption mechanism while the other component travels with mobile agent in encap-sulated manner. After reaching to the intended destination, agent itself generates the symmetric decryption key through these two key components and provides agent driven security.

The overall paper is organized as follows: In Section 2, we performed critical analysis of last 12 years of researches con-ducted in the prominent area of agent’s security. After doing critical analysis, we identified the current state of art which tells, malicious execution environment is still a challenging issue for researchers.Section 3presents the attacks’ classification in terms of attackers, agent’s component and security factors and then discussed about our security protocol.

In Section 4, we verify our protocol using Petri net based

formal framework. InSection 5, we perform comparative analysis of our protocol with existing self-protection approach in terms of their computational complexities.Section 6gives the implemen-tation details of our protocol and performs comparative analysis of our protocol with existing self-protection approach. At last, we conclude the paper inSection 7.

2. Analysis of previous researches

Although numerous distributed applications have been pro-vided by mobile agent technology got a radical changes over traditional communicational approaches like RPC, RMI etc. that persuades network infrastructure to adapt it in wider scale but unfortunately new security implication introduced with this technology hampers the vision of mobile code’s widespread acceptance.

2.1. Protection of execution platform

Mobile agent is the executable code that moves from platform to platform and processes the data which resides on remote execution platform. Mobile agent either directly interacts with execution platform or with the static agent which resides on execution platform. Agent can perform unwanted malicious acts on remote execution platform to exploit the resources for which it

is not entitled. The issue of malicious agent is not a challenging problem and can be easily tackled practically by sandboxing, code signing technique and proof carrying code (Jansen and Karygiannis, 2000;Borselius, 2002;Sander and Tschudin, 1998).

Sandboxing limits the privileges of the executable code of mobile agent i.e. apply access control mechanism on agent’s right. Java implements the sandbox which limits the access of resources at memory, file, and system and disk level (Jansen and Karygiannis, 2000;Sander and Tschudin, 1998;Hohl, 1998).

Code singing ensures the authenticity as well as the integrity of code (Sander and Tschudin, 1998). Code signing mechanism applies in digital signature and one way hash function to ensure integrity and authenticity. In this technique, execution platform maintains a list of trusted hosts and checks the originator’s identity of mobile code with the help of this list. If the code originator’s name is mentioned in trusted list, its means it is trustworthy and code is safe.

This approach has one major drawback i.e. this technique accepts the truthfulness of entities if it is in the trusted list and gives full privileges to that mobile agent, which is originated by trusted entity, but in a condition when agent itself is malicious, means during its itinerary, it is infected by malicious host and its originator is in the trusted list, agent platform gives full privilege to the trusted entity to execute malicious code and may cause harm to agent’s platform. So, ideally malicious agent problem is derived from malicious host problem.

Farmer et al. (1996)proposed the state appraisal mechanism

to ensure the authenticity of agent when the state of agent is modified by untrustworthy platform. In this mechanism, creator of mobile agent generates a state appraisal function which specifies some set of valid permission on the basis of current state of mobile agent that could request from remote host plat-form. In this technique, agent creator sends state appraisal function with mobile agent code to host platform. Host platform verifies the state function and gives the valid privileges to incoming mobile agent which should be granted on the basis of current state of agent.

In mobile agent paradigm, mobile agent visits many platforms; some of them are not trusted up to certain extent. When an agent visits a new platform, newly visited platforms have to determine whether to process agent or not on the basis of path history. Platform should take the help of authenticable records main-tained by mobile agent for taking decision. Using the path history, the platform decides whether to run the agent and what level of trust, resources, privileges and services should be granted to agents.

Lee and Necula (1997)put forward a technique wherein code’s

originator dispatches the code with formal safety proof to the intended receiver. Receiver obtains the code and verifies it with fast proof checker (Jansen and Karygiannis, 2000;Borselius, 2002;

Benachenhou and Pierre, 2006). PCC, a preventive technique

guarantees the authenticity of incoming code provided that there should be no flaw in proof checker. In this mechanism, there is no need of cryptography and trusted third party because it can be considered as self-certifying.

In current communication infrastructure, all above techniques are more or less sufficient to provide permissible security to the execution platform from agent. However, the issue of malicious host is an open problem and many challenging research issues need to be solved for adequate mobile agent security.

2.2. Protection of mobile agent (malicious host problem)

Execution of mobile agent is under the control of the system that is not responsible for its creation is the main problem of overall mobile agent system. Execution platform may be trusted

or not and to identify whether it is trusted or not is a challenging task for a mobile agent at run time. So agent owner should build a protection mechanism that can travel with mobile agent to protect it from malicious intent or the execution platform.

2.2.1. Conventional security mechanisms

Various conventional security techniques are proposed for malicious host problem. We will summarize the advantages and disadvantages of each and every technique in brief.Jansen and

Karygiannis (2000) and Nitschke et al. (2004)focused

general-purpose techniques for protecting a mobile agent from malicious host include the following:

Computing with Encrypted Functions (Sander and Tschudin, 1998).

Environmental Key Generation (Riordan, 1998).

Obfuscated Code (Time Limited Black box) (Hohl, 1998;

Armoogum and Caully, 2011; Szpryngier and Matuszek,

2010;Waqar Shah’ and Nixon, 2006). Execution Tracing (Vigna, 1997).

Co-operating Agents (Vigna, 1997;Esfandi and Rahimabadi, 2009;Benachenhou and Pierre, 2006).

Clone Agent Protocol (Bouchemal et al., 2009). Secure Image mechanism (Ahmed, 2009).

Sander and Tschudin (1998)proposed computing with

encry-pted function. The basic motive behind this is to conceal the function of mobile code from the execution environment for maintaining the integrity and privacy of mobile agents against malicious host platform. Although this technique has been claimed to be a powerful one, but it is not capable to prevent replay and denial of service attacks. Till date, there is no any sophisticated cryptosystem that implements additively, multi-plicatively and mixed multimulti-plicatively homomorphism that helps to implement mobile cryptography (i.e. evaluating encrypted function).

Schneier (1998)proposed environmental key generation method

in which agent’ executable code is produced in such a way that upon getting an environmental condition, a key is generated automati-cally to unlock executable code. In this technique, it is tedious job for an agent’s creator to set the environmental condition for an unknown and heterogeneous environment.

Hohl (1998)proposed a preventive technique, in which mobile

code is scrambled to change its layout, control flow in such a manner that no one host may be proficient enough to analyse and modify it easily. Moreover, java obfuscation only provides execu-tion privacy or confidentiality to the mobile code but it cannot be ensured that the particular obfuscated code is deobfuscatable or not (Armoogum and Caully, 2011; Szpryngier and Matuszek, 2010;Waqar Shah’ and Nixon, 2006). In this case, if execution platform has sufficient computational capacity, it can deobfuscate the code before executing the code. This technique is a preventive measure and its security is dependent upon the computational capacity of execution environment.

Execution tracing is a technique which provides the capability of detecting unauthorized misbehaviour or modification of an agent’s code and state during its lifetime. Traces are cryptographic log of actions that are not repudiated and are performed by an agent which can be used to detect unauthorized modification. Tracing enables the owner of an agent to check the trace or log (agents’ execution history) and try to detect the unauthorized modification done by malicious platform (Vigna, 1997). Execution tracing approach has a number of drawbacks such as large size and number of logs to be maintained.

Roth (1999)gave the concept of co-operating agents to build

the secured mobile agent system where functionality is distrib-uted among different mobile agents so that the attackers could not compromise the information by compromising a single mobile agent.

After Roth, Samuel Pierre et al. (El Rhazi et al., 2007;

Benachenhou and Pierre, 2006) proposed a solution based on

the perfect cooperation of a sedentary agent running inside a trusted host. However, this technique is only good enough to provide security by establishing communication between agent platforms and trusted servers. But the problem is each platform has to reveals the details of the agent’s execution to the trusted server through a large number of communication links estab-lished which creates extra burden (Ouardani et al., 2007).

Zaslavsky et al. (Page et al., 2004a,2004b) proposed a buddy model which behaved like the approach of co-operative agent. In this approach, every agent protects its neighbour agent by showing the responsibilities of security function in pervasive environment. This model also inherits the disadvantages of the approach of co-operative agents.

Narjes et al. (2009) proposed clone agent protocol which is

somehow related to sedentary agent approach, but here the clone agent executes on the same execution host before critical code execution. Thus, instead of exposing the mobile agent to the malicious host, it first sends a clone to investigate the behaviour of the execution environment. In CAP, once an attack is detected, the mobile agent puts the responsible host in its malicious host’s list and changes its destination accordingly. In this approach, original task of agent is performed after the execution of clone agent which verifies the authenticity of execution environment. The overall process creates unnecessary delay in the execution of original task.

Tarig (2009) brought the same concept like clone agent

protocol called Secure-Image Mechanism (SIM) to protect the mobile agent from malicious hosts. In this technique, secure image controller creates the image of mobile agent and sends this to unknown host for execution. Host executes this image and sends it back to the secure image controller where verification of agent’s integrity takes place by comparing it with original copy of the agent. If it finds any malicious modification SIM presumes the host to be malicious. This mechanism offers security to the detriment of unnecessary communication overhead with trusted host in network.

2.2.2. Cryptographic approaches

Besides above stated conventional security mechanisms, during last few years various cryptographic based mechanisms came forward to alleviate the problem of mobile agent security

(Huanmei and Huanguo, 2010; Srivastava and Nandi, 2011a;

Srivastava and Nandi, 2011b). Cryptographic protocol generally

runs in closed environment where at least information regarding nature of network is known. Unlike previous conventional approaches, cryptographic enabled techniques provide strong verifiable type of protection in case of mobile agent security.

2.2.2.1. Public key infrastructure based model. Most of the cryptographic based model is supported by PKI based model

(Ismail, 2007a, 2007b; Saxena and Soh, 2005). In public key

2.2.2.2. Self-reliant security approach. In the year 2003, Zaslavsky et al. (Page et al., 2003) had brought forward a detailed concept of self-reliant security features. In their approach, agents carry only an indication of the actual message that resides on the secure server instead of any sensitive data. On receiving the indicator digest, destination host (agent platform) sets up a secure communication channel for retrieving complete message from the secure server. In this technique, each destination host (during itinerary of mobile agent) needs to setup a secure communication channel to retrieve the original message which creates huge amount of security overhead.

Although, indicator digests does not contain whole message, but it should be secure in communication channel as well as on execution environment as it locates the original message and the address of secure server. In this scenario, malicious entity may perform denial of service (DOS) by capturing the indicator digest to analyse and modify its context so that destination host (execution agent platform) will not be able to extract original message.

In 2004, Zaslavsky et al. (Page et al., 2004c) proposed an approach of self-executing security examination (SENSE) for the protection of mobile agent from malicious execution environ-ment. In this approach, agent is self-reliant with respect to its security function and executes in an unknown environment without having dependency on an external support for security. Agent carries scan algorithm which scans the agent’s code and verifies the integrity of agent at random intervals. Continuous execution of scan algorithm degrades the performance of the approach. In addition, this approach did not give the focus on execution privacy issue of mobile agent.

2.2.2.3. Self-protection approach. In the year 2006,Ametller et al. (2004)proposed a key idea that lies in encapsulating agents with an independent protection mechanism carried by mobile agent itself. In this mechanism, executable code is wrapped as data and encrypted with the recipient’s public key. Executable code is transported and managed by an explicit controller agent code C that exploits platform cryptographic services to decrypt execut-able code.

This technique provides agent authentication, platform authen-tication, data integrity and it also prevents malicious data injec-tion inside the agent. This technique promotes agent driven approach i.e. security verification is performed by agent itself and it also uses a cryptographic interface between agent and execution platform so that platform cannot directly interact with the agent. The need for agent to gain access to the private key of execution platform is one aspect which makes this approach sometime inferior.

According to this scheme, agents are internally structured as follows:

All executable agents’ code wrapped up as data and encrypted with platform’s public key.

Explicit controller code C transports executable code. Thus mobile agent is structured as a combination of (C,D) whereC acts as a controller code andDwrapped as data.

Now, first agent owner generates public private key pair (Pa,Sa)

and digitally sign the executable code djand create signature

Sj¼ESaðHðdjÞÞ.

After that, agent owner encrypts explicit executable code dj and its signatureSjusing pubic key ofjth platform and creates encapsulated agent Dj¼EKjðdj,ESaðHðdjÞÞÞ,HðCÞ.

At the receiver end, using platform public decryption function, receiver extractsðdj,SjÞfromDj.

Before executing djfirst the receiver verifies the authenticity and integrity ofdjwith the help of signatureSjthen executes the code dj.

The major drawbacks of this technique are its high computa-tional complexity. Each receiver (agent platform) uses platform decryption function as cryptographic service acting as an inter-face between the interaction of agent and agent platform. Decryp-tion of mobile agent using platform’s private key is the main downside of this approach. So to overcome the problem of security and computational complexity, we develop a new self-protection protocol with novel features of integrity based encryp-tion as well as secure symmetric key’s component distribuencryp-tion.

2.2.2.4. Multi-agent multi-key approach. In 2009, Esfandi and

Rahimabadi (2009) proposed multi-agent based cryptographic

protocol wherein encryption key and data are broken into different parts carried by different mobile agent so that it is necessary for an intruder to compromise all agents to crack the security. This protocol seems to provide security but at the cost of communication and computational overhead which comes in terms of encryption, authentication as well as communication overhead. In case of ‘n’ different mobile agents, ‘n’ time security checks is applied at each host to provide verifiable security which is not feasible in case of light weighted network infrastructure.

Beside overhead problem, this protocol does not provide fault tolerance capability to the entire communication process due to the multi-agent based security. In any occurrence of fault, if any of the agents do not reach at the destination, the whole commu-nication process fails due to availability factor.

2.2.2.5. Root canal algorithm. According to Venkatesan and

Chellappan (2010) when mobile agent executes in a malicious

host environment then the behaviour of agent turns malicious which may be dangerous for next host platform and suppose this platform detects that this is malicious agent then it will think the originator of this agent is responsible for this while it is not true. For the protection of agent code, Venkatesan proposed root canal algorithm in which there are two modules. One is for agent owner and another one is for remote platforms contained in the itinerary of agent. This approach is like digital signature approach and following steps are taken to perform it:

First agent owner generates the hash value of agent byte code. Encrypt the hash value with its own private key (Digitally Signed).

Append digitally signed hash value of agent code with original agent code.

At the remote site, remote host get the agent’ code with encrypted hashed value.

Remote hosts decrypt hashed code with the help of public key of agent owner.

Remote host calculate hash value of agent of agent code and compare it with appended digitally signed hashed code and identify the alteration if it occurs.

According to this approach, if succeeding host finds any malicious change then it claims to the preceding host for altera-tion. In the case, when malicious host changes the code and claims that this change is performed by proceeding legitimate host then in this case, root canal algorithm is not suitable. So in order to prevent false claim by malicious host, Venkatesan proposed extended root canal algorithm in 2010. Moreover, root canal algorithm provides efficient integrity mechanism for mobile

agent as compared to self-protection; but it did not provide any space for execution privacy.

After doing exhaustive analysis of security solutions and current status of malicious host problem, we bring forth a solution which is motivated from self-protection approach and integrity based encryption technique. We made agent so proactive in nature that upon breaches the integrity it can detect it at run time and also protects them from execution environment. In spite of giving whole security verification authority directly to the execution environ-ment, we follow the agent driven security approach in different aspects.

3. Proposed security protocol

3.1. Security threat classification

Focusing on the security aspects, the following are iden-tified as the comprehensive security threats associated to the mobile agent technology. In a nutshell, there are two major aspects of protection mechanism. Before delving into the details of threat classification, first we classify the entities involved in attack:

But here, we classified attacks only related to agent security. In other words, agent security means protecting agent from execution platform or from MITM (channel attacker or man in the middle attack). In order to classify attacks, we need to classify the attackers, agent’s components which are vulnerable to attack and the security factors (confidentiality, integrity and availability) which can be compromised.

3.1.1. Formal representation of attacks

As discussed in previous section, researchers have provided various solutions for the protection of agent platform which is broadly acceptable but the protection of mobile agent still a concern area for research. We formalize the security threats and attacks related to agent security in following way.

3.1.1.1. Attack scenario. We formalize the attack in this respect. Attack¼fA,M, MC,Fg means ‘‘attacker A performs attacks on mobile agent M and affected component of mobile agent is ‘MC’ and factor ‘F’ of security is compromised.’’ (ReferTable 2for notations)-where Attacker A can be classified as¼ fCA,MHg ¼{Channel Attacker, Malicious host}

A set of attacks may be possible in agent scenario mentioned inTable 1.

It can be seen from the above formalism there are 24 classes of attacks. In our approach, we will focus on the data and code

confidentiality and integrity issues. Hence, according to the formalism following 8 classes of security threats will be focused.

fCA,M,MC,Cg,fCA,M,MC,Ig, fCA,M,MD,Cg,fCA,M,MD,Ig, fMH,M,

MC,Cg,fMH,M,MC,Ig,fMH,M,MD,Cg,fMH,M,MD,Ig.

So from a single approach we will solve 33.33% security threats. Shaded cell ofTable 1represents the security objectives solved by our protocol. In Section 3.2, we will show how our protocol fulfils the above mentioned security requirements.

3.2. Proposed protocol

We have developed a security protocol employing integrity based encryption technique (Lee and Hong, 2005) in which encryption key is generated by applying hash operation on digitally signed encrypted data to offer integrity and privacy simultaneously (referTable 4for notation meaning).

We create symmetric key componentK1 using hash operation and then to generate cumulative symmetric key KðK1K2Þ by combining K1 with symmetric key component K2. In place of distributing cumulative symmetric keyK, we sendK2to the next recipient host in secure fashion i.e. encryptK2with public key of next recipient host.

Upon receiving encrypted component K2, execution host decrypts it with private key to get it and gives it to decryption module of the agent.

Decryption module of the mobile agent generates cumulative symmetric keyK. To generateK, agent hashes the digitally signed result data part and findsK1 then performs bitwise ex-or opera-tion on K1 andK2. If the generated cumulative keyKis able to decrypt encrypted agent’s code then it verifies the authenticity of the execution platform (asK1can only be decrypted by intended recipient), integrity of agent’s data (as key component K2 is generated from hashing of data) and verification of sender’s host (K2 if generated from digitally signed data) at the same time whereas till now, integrity verification of data is generally performed at agents owner site at the last of agent’s itinerary or could be performed at each host of agent’s itinerary but for both the circumstances, integrity verification and privacy

Table 1

Formal classification of attacks.

Security attacks classification {A,M,MC,F}

fA,M,MC} fA,M,MSg fA,M,MDg

Attacks on Agent’scode Attacks on Agent’sState Attacks on Agent’sData

fCA,M,MCg fMH,M,MCg fCA,M,MSg fMH,M,MSg fCA,M,MDg fMH,M,MDg

fCA,M,MC,Cg fMH,M,MC,Cg fCA,M,MS,Cg fMH,M,MS,Cg fCA,M,MD,Cg fMH,M,MD,Cg

fCA,M,MC,Ig fMH,M,MC,Ig fCA,M,MS,Ig fMH,M,MS,Ig fCA,M,MD,Ig fMH,M,MD,Ig

fCA,M,MC,Ag fMH,M,MC,Ag fCA,M,MS,Ag fMH,M,MS,Ag fCA,M,MD,Ag fMH,M,MD,Ag

Table 2

Notation used in attack classification.

Symbols Definitions

CA Channel attacker

MH Malicious host

MC Compromised agent’s component

MC Agent’s code component

MD Agent’s data component

MS Agent’s state component

C Confidentiality

I integrity

assurance overhead occurs separately. The protocol is summar-ized inTable 3.

Protocol:According toTable 3we summarized the protocol in following 7 steps:

(1) Agent owner platform creates encapsulated mobile agent and sends it to the next agent platform.

(2) Agent platform receives this encapsulated mobile agent, now controller agent Ainteracts with execution platformAPand gives the details according to step 2.

(3) Agent platform decrypts above details and delivers key componentK2to the controller agent in step 3.

(4) And verify the authenticity of controller agent asfsig,pubðOÞðAÞ.

(5) Controller agent A calculates symmetric keyKas according to step 4.

(6) And after decryption, codeCis executed.

(7) After executing the code C, controller agent A updates the previous results with current generated result.

3.2.1. Detailed analysis of our protocol

Our protocol modularized in following phases:

Agent Creation Phase

Agent Execution Phase atith host Agent Updating Phase

Agent Migration Phase

Protocol Phase1: Agent Creation Phase(owner side)

1.1.Create Mobile AgentMðC,dTÞ 1.2.Choose data part dT

1.3.Encrypt dT(Encrypt data part with owner public key) 1.4. SetEðdTÞ’EPubðoÞðdTÞ

1.5. Applying Digital Signature 1.6. SetDT’EPriðoÞðEðdTÞÞ

1.7.Generate encryption key component 1.8. K1’HðDTÞ

1.9.Generate symmetric key componentK2

1.10. Generate Combined keyK¼K1 K2 1.11. Create Encapsulated Mobile Agent 1.12. EKðCÞJDTJHðCÞJEPubNextðK2ÞJAJsigðAÞ 1.13. Send encapsulated mobile agent to next

recipient (host)Si

Protocol Phase2: Agent Execution Phase atith host

2.1.Recipient host receives

2.2. EKðCÞJDTJHðCÞJEPubNextðK2ÞJAJsigðAÞ 2.3.Decrypt

2.4. EPubNextðK2Þ//Recipient host authentication

Table 3

Summary of protocol (interactions between protocol’s components).

Protocol:

(1) OP,AP-AP:fsencðCÞJfhashðfsig,priðAPÞðfaenc,pubðOPÞðdTÞÞÞJfaenc,pubðAPÞðK2ÞJAJfsig,pvtðOPÞðAÞ (2) A-AP:faenc,pubðAPÞðK2ÞJ9AJfsig,pvtðOPÞðAÞ

(3) AP-A:fadec,pvtðAPÞðK2Þ

(4) A:fsig,pubðOÞðAÞ//verify the signature (5) A:fkgenðK1,K2Þ//Symmetric key generation (6) A:fsdec,KðCÞ//Decryption of code C (7) C-AP:fupdðDTJfsig,pvtðAPÞðfaenc,pubðOPÞðdiÞÞ

Notation Meaning

OP Agent owner platform

AP Agent platform

C Mobile agent (executable code)

A Controller agent

fhashðXÞ Calculate hash of entityX.

fsencðCÞ Performs symmetric encryption by symmetric keyK.

fsig,priðYÞðXÞ Digitally signXwith private key of entityY.

faenc,pubðYÞðXÞ Performs asymmetric encryption on dataXwith public key of entityY.

fsdec,KðCÞ Performs symmetric decryption by symmetric keyK.

fadec,priðYÞðXÞ Performs asymmetric decryption on dataXwith private key of entityY.

fkgenðK1,K2Þ Key generation function

fupd Data updating function

Table 4

Notation used in our protocol.

Symbols Definitions

M Mobile agent

C Mobile agent’s code

dT Data part of mobile agent

DT Digitally signed data part

K1 Symmetric key component (derived from hash data)

K2 Symmetric key component

K Combined symmetric key

A Controller agent

sigðAÞ Signature of controller agent

PubNext Public key of next recipient host

PriNext Private key of next host

H(C) Hash of codeC

Di Collected data(Result) atith host

PriðiÞ Private key ofith host

PubðOÞ Public key of ownerO PriðOÞ Private key of ownerO

CA Channel attacker

MH Malicious host

MC Compromised agent’s component

MC Agent’s code component

MD Agent’s data component

MS Agent’s state component

Protocol Phase2: Agent Execution Phase atith host

2.5.And give it to the controller agent

2.6. K2’DPriNextðEPubNextðK2ÞÞ//K2is given to controller agent

2.7.VerifyDT// optional if sender authentication is required 2.8. EðdTÞ’DPubðOÞðEPriðOÞðEPubðOÞðdTÞÞÞ

2.9.Generate combine symmetric key

2.10. K¼K1K2// whereK1¼HðDTÞcontroller agent calculates

2.11. Decrypt encrypted agent’s code i.e.EKðCÞ 2.12. C1’C’DKðEKðCÞÞand KOLD’K1 2.13. Integrity checking of code 2.14. ifHðC1Þ ¼ ¼HðCÞ

2.15. thengoto line 2.17 of Agent execution phase 2.16. elseabort execution

2.17. Executes codeC 2.18. Generates resultsdi

2.19. Follow line 1.3–1.6 of agent creation phase 2.20. CalculateDi’EPriðiÞðEPubðiÞðdiÞÞ

2.21. Create cloneC

2.22. Call functionupdateðC,DiÞ// goto agent data updating phase

Protocol Phase 3: Agent Updating PhaseupdateðC,DiÞ//Under the control of agent itself

3.1.updateðC,DiÞ 3.2.{

3.3.Select DT// previous data

3.4. Check integrity ofDT// Applying hashing 3.5. IfðKOLD¼ ¼HðDTÞÞ

3.6. thenDT’DTJDi 3.7. CallmoveðC,DTÞ 3.8.}// end of update

Protocol Phase 4: Agent Migration PhasemoveðC,DTÞ

4.1.moveðC,DiÞ 4.2.{

4.3.Follow line 1.7–1.8 4.4.Calculate keyK1’HðDTÞ 4.5.Follow line 1.7–1.10 4.6.Encrypt CodeC 4.7.Follow line 1.11–1.12 4.8.EKðCÞJDTJHðCÞ_JEPubNextðK2Þ 4.9. Move to next recipient host 4.10. }

3.3. Agent creation phase

Agent owner creates mobile agent which consists of codeC and data part dT(lines1.1–1.2). Code security and data security is the basic challenge for agent owner to handle. So for security of the data part, it should be necessary to encrypt data with the public key of agent’s owner (lines1.3–1.4). So that, only agent’s owner can access the data collected after agent’s itinerary. This step ensures the confidentiality of the mobile agent’s data and prevents mobile agent from following classes of security attacks

i.e. fCA,M,MD,Cg,fMH,M,MD,Cg. After encrypting the data, apply

signature on encrypted data so that host in the network can authenticates the data origin (lines1.5–1.6).

After securing data, it is required to focus on the security issue of mobile code. So in order to secure mobile code, encryption

key is required which is to be generated with ensuring data confidentiality and authentication (reliability). Here one encryption key’s component K1 is formed by applying hashing on encrypted data part (lines 1.7–1.8). And the key component K2 is encrypted with the public key of next host (lines1.10–1.12), so that it can only be accessed by the authenticated host which has the corresponding private key. Generation of key component K1ensures data integrity as it is formed by hash operation. According to the attack classifica-tion (Table 1), this step (lines1.7–1.8) prevents the mobile agent from following classes of attacks that are related to data integrity i.e.

fCA,M,MD,Ig,fMH,M,MD,Ig.

At the end of agent creation phase, an encapsulated mobile agent is created according to theline1.12 at each host of agent’s itinerary including agent’s owner. Encapsulated mobile agent contains encrypted codeðEKðCÞÞ, digitally signed encrypted data DT, hash of code HðCÞ, encrypted key K2, controller agent A and its signature. This encapsulated mobile agent is safe from the following attacks that are related to code confidentiality and code integrity i.e.

fCA,M,MC,Cg,fCA,M,MC,Ig,fMH,M,MC,Cg,fMH,M,MC,Ig. Now sends

the encapsulated agent to the next recipient host.

3.4. Agent execution phase at ith host

Now recipient host (Agent’s execution platform) gets the encapsulated mobile agent in the form of line 2.2. Agent’s execution platform decrypts EpubNextðK2Þ with its private key in order to get key K2and ensures its entitlement over key K2(lines 2.3–2.4) and then gives this key to the controller agentAafter checking the authenticity of controller agent (lines 2.5–2.6). Controller agent has its signature as proof of its authenticity.

Agent’s execution platform first verifiesDTwith public key of agent owner and ensures the authenticity of data origin (agent owner) (lines 2.7–2.8). After verification of DT, agent generates key component K1 by applying hashing on EðdTÞ. After getting key K1, controller agent computes key K by applying some function like K¼ ðK1K2Þ (line 2.10). After generating key K, controller agent decryptsEKðCÞ(lines 2.11–2.12).After decrypting code C, checks the integrity of code and if the integrity is preserved then execution of mobile code starts otherwise execu-tion of mobile code is aborted (lines 2.13–2.17). After execution of agent’s codeCon host hi, a resultdi is produced which is to be signed by private key of host hi (lines 2.17–2.20).

3.5. Agent updating phase

After producing result, agent updating phase is invoked (lines 2.19–2.22). In which, before updating the data, first agent itself checks the integrity of previous data (Data which are received up to previous execution host) and verifies whether it is tempered or not. If the integrity is verified(line 3.5),data updating takes placed (line 3.6).

3.6. Agent migration phase

4. Formal analysis with Petri net based model

4.1. Petri net with EEOS

Now Petri net methodology is mature enough to model systems in wide area of software engineering as it is widely used formalism for modelling distributed and concurrent system. Due to lack of compositionality features in Petri nets, object oriented technology has been combing with Petri nets during recent years as compositionality is the main forte of object oriented technol-ogy (Lu and Jeffrey, 2006;Ma and Tsai, 2008).

Valk proposed the elementary object system (EOS) which is the elementary class of object Petri net that also provides space for security aspects of mobile agent technology. Moreover EOS provides Petri net characteristics with some object oriented aspects but is not able to afford high level facets of object oriented technology like inheritance, polymorphism, dynamic binding etc.

Ma and Tsai (2008) further extends proposed EEOS (extended

elementary object system) formal graphical approach like object

Petri net (OPN). EEOS can be used for the formal modelling of secure mobile agent based system. To verify our security protocol, we take the assistance of EEOS model. Before representing our protocol with formal representation, we go through a brief introduction of Petri net model and EEOS model to make it easier to understand.

Petri net is graphical formal modelling language for embody-ing distributed and concurrent system. It signifies stepwise events or processes that comprise concurrent execution, conditional execution or iteration. Petri net has three components Place, transition and arcs. Arc connects place to transition or vice versa but never connects between places or transitions.

Petri nets contain number of tokens called marks which is necessary for firing of transition (event). In the reference of mobile agent, tokens of Petri net represent information regarding keys, certificate, agent’s code and data at particular state.

Transition is the event or process that happened by consuming sufficient or necessary tokens from the input places of it. Each transition of Petri nets is having some input places that are responsible for the firing of the transition (occurrence of parti-cular event). After consuming tokens, transition fired and places all tokens (result of transition) to the end of arc i.e. output place of the transition.Figure 1represents basic notion of place transition diagram. We only formalize the security protocol by taking the reference of only one execution platform. To support mobility trait we may deem token as mobile agent or mobile event that may transport from one location to another. Various researchers previously proposed different formal approaches based on Petri net technology to support mobility features of mobile agent.

4.2. Petri net based model description

We formalize our security protocol with extended elemen-tary object system (EEOS) which is derived from Petri net with

Fig. 1.Basic Petri net mode.

Fig. 2.Formal Petri net based representation of our protocol.

additional features of object oriented programming. Our protocol’s working is represented by P1–P14 places and T1–T13 transitions. To represent the functionality of mobile agent based system and proposed security protocol we choose the graphical approach of Petri net which can represent mobility, concurrency as well as security in the form of places and transitions. Formal Petri net based representation of our protocol is shown inFig. 2and nota-tions of places and transinota-tions are represented inTables 5 and 6.

Our formal depiction has two external places to form the communication links between agent platform and external entities. External places are used for transporting mobile agent to another platform as well as receiving mobile agent from previous platform. We simplified the functionality of mobile agent and platform in a single EEOS model as state transition type of diagram.

As we previously stated in our protocol, we divide the func-tionality of mobile agent into different interdependent modules of platform interaction module, key generation module and code execution module. We assume mobile agent is coming from Pei which is denoted for externally incoming communication channel. Incoming Mobile agent and data is stored in place P1 represented in diagram. Initially as per our protocol, platform interaction module interacts with execution platform by giving encrypted symmetric key componentK1 to the execution plat-form. Execution platform decrypts this encrypted key component with its private key. Transition T2 describes the decryption process of encrypted key component. T2 has two input places P1 and P12 that provides required tokens for its firing. P12 represent security base which acts as repository place of all needed information regarding keys, certificates etc. After the transi-tion T2 is accomplished T2 places all tokens (means outcome of event) and the end of arc i.e. on place P2.

Before giving decrypted key component to the requested module, execution platform first checks the authenticity of it. Verification of the identity of platform interaction module is processed by transition T2.There are two input places for con-suming required tokens (required information to authenticate platform interaction module) to make firing of transition T2 possible. Place P2 provides signature or hash of requested plat-form interaction module which is to be used for verifying the authenticity whereas place P12 provides security base in form of security verifying key i.e. public key of agent creator.

After ensuring authenticity of platform interaction module, agent platform delivers symmetric key component K1 to the respective module. For representation of this process transition T3 places symmetric key componentK1on P3 which is delivered to platform interaction module through T4. Place P5 is the holder place for key componentK1after dispatching.

After getting key componentK1, mobile agent itself calculates symmetric keyKwhich is the combined function of K1 andK2. In model, Transition T6 is responsible for symmetric key generation. Transition T6 has two input places P5 and P4. P4 is the output place of transition T5. Transition T5 calculates symmetric key component K2and place it to its output place P4. Transition T6 consumes tokens from input places P4 and P5and calculates symmetric keyKwhich is responsible for providing privacy to the executable code of mobile agent and places this key to the holder place P6.

After getting symmetric key K, agent is decrypted and this process is represented by transition T7. Transition T7 takes input from its two input places P6 and P12 places the decrypted code to its place P7. Execution of mobile agent started after decryption and it is denoted in graphical model as transition T8. Transition T8 has two input places P7 and P14. P14 provides knowledge base information which is used for the communication between agent and platform as well as execution of agent. Execution results are placed on the output place P8 of the transition T8.

After generating result, execution platform signs and encrypts its results with public key of agent owner so that only intended agent’s owner can access it. Transition T9 has two input places P8 and P12 which provides tokens in form of agent’s owner public key and private key of agent’s platform as well as result generated to the transition T9. Upon receiving these tokens, transition T9 fires and encrypts and digitally signs the result for ensuring confidentiality of result generated.

After firing of transition T9, T9 places encrypted results and agent to its output place P9. Now the execution of mobile agent on execution platform is completed. Subsequently agent should be prepared for next host migration. Before migration of agent to the next host, integrity verification of data as well as code should be achieved as stated in our protocol. After this, Transition T9 is fired for ensuring integrity verification of data and code. To achieve this transition T10 consumes the tokens from the input places P12 and P9 and processes these tokens and places all the tokens after integrity verification on output place P10.

Till now, mobile agent has performed its intended task and ready for its next destination. Encryption of mobile agent for next host is represented by T11. T11 places encrypted results with encrypted agent at place P11. T12 consumes token from its input places P11 and P14 and dispatches mobile agent with generated result. Place P13 and transition T13 is used for outgoing communication.

5. Comparative analysis of self-protection technique with our protocol

In order to compare the efficiency of traditional self-protection approach with our approach, we assume the notations represen-tations which are shown inTables 7 and 8.

Table 5

Places representation.

Transitions Meaning

Pei Externally incoming communication channels Peo Externally outgoing communication channels P1 Incoming information/mobile agents with data

P2 Holder for symmetric key component 1and decrypted data P3 Holder for symmetric key component 1after authentication P4 Holder for symmetric key component 2

P5 Holder for key component1 after dispatching

P6 Holder for symmetric key

P7 Holder for decrypted mobile code

P8 Holder of agent’s result and agent after execution P9 Holder of mobile agent with encrypted results P10 Holder of mobile agent after integrity verification

P14 Knowledge base

Table 6

Transition representation.

Transitions Meaning

T1 Process externally incoming info and forward to internal static agent

T2 Decrypts encrypted symmetric key component 1 using its private key

T3 Authenticate mobile agent’s module

T4 Deliver key component1 to the mobile agent’s module T5 Calculate symmetric key component 2 from hash of signed data T6 Generates symmetric keyK

T7 Decrypts agent code T8 Executes mobile agent T9 Encrypt and sign agent’s result

T10 Checks the integrity of code and previous data before migration T11 Creates encrypted agent for next host

5.1. Self-protection model:

InSection 2.2.2.3, we described the self-protection algorithm, in self-protection scheme, agent’s executable code wrapped up as a data in a variable and explicit controller code is used as code carrying agent. (refer notations meaning fromTables 6 and 7).

Dj¼EKjðdj,ESaðHðdjÞÞÞ,HðCÞ ð1Þ

Controller codeCcarries encapsulated code in the form ofDj (see Eq.(1)).Time to create encapsulated agent’s code is the sum of following time components:

Time to create hash of controller codeC¼THC . Time to create hash of agent’s executable code¼THA. Time to create signature on hashed executable code¼TS. Time to encrypt (Asymmetric) encapsulated one¼TAE.

Total time taken at agent’s creation phase is illustrated in Eq.(2).

T¼THCþTHAþTSþTAE ð2Þ

At the execution environment, platform decryption function performs decryption operation and provides decrypteddjto con-troller code. Platform decryption function takesT2time to decrypt requested data from agent’s controller codeC. Time to decryptDj and verify the authentication and integrity of controller code C and agent’s executable code dj is the sum of following time components:

Time to decryptDj¼T0AD.

Time to create hash of controller codeC¼THC’ . Hash checking time for controller code¼THcom’ .

Signature verification time¼TV.

Time to create hash of agent’s executable codedj¼THA’ . Hash checking time for agent’s executable code¼THcom2’ . Hash checking time for agent’s executable code¼THcom2’ .

So, total time taken by platform decryption function is shown by

T0

¼T0

ADþT

0

HCþT

0

HcomþTVþT0HAþT 0

Hcom2 ð3Þ

5.2. Our self-protection technique

Our protocol gains confidentiality factor by verifying the integ-rity and authenticity of collected data simultaneously and migra-tion of agent here is dependent on code integrity. Time complexity of our protocol is illustrated below in different time components.

Agent’screation phase:

Time to perform asymmetric encryption of datadT¼ETAED. Signature time on datadT¼ETS.

Time to create Hash of dataDTi.e. creation of key component

K1¼ETHD.

Time to create Hash of codeC¼ETHC.

Time to perform asymmetric encryption of symmetric key

K2¼ETAEK.

Time to perform symmetric encryption on codeC¼ETSEC.

Total time taken at agent’s creation phase is represented by

ET¼ETAEDþETSþETHDþETHCþETAEKþETSEC ð4Þ

Agent’sexecution phase:

Time to asymmetric decryptK2¼ETADK’ . Time to decrypt codeC¼ETSDC’ . Time to create hash of codeC¼ETHC’ .

Time to perform Hash checking of code¼ETHcomp1’ .

Time to create hash of dataDTi.e. create time of keyK1¼ETHD’ .

Total time taken at agent’s execution phase is represented by

ET0

¼ ET0

ADKþET

0

SDCþET

0

HCþET

0

Hcomp1þET

0

HD ð5Þ

Table 7

Notation used in self-protection protocol.

Symbols Definitions

Dj Encapsulated mobile agent

dj Mobile agent’s executable code

C Controller code

Sa Private key

Table 8

Notation used in performance analysis.

Symbols Definitions

THC,T0HC Time to create hash of controller codeC.

THA,T0HA Time to create hash of agent0s executable code.

TS Time to create signature on hashed executable code.

TAE Time to encrypt (Asymmetric) encapsulated one.

T0

AD Time to decrypt Dj:

T0

Hcom Hash checking time for controller code.

TV Signature verification time.

T0

Hcom2,ET0Hcom1 Hash checking time for agent0s executable code.

ETAED Time to perform asymmetric encryption of data dT.

ETS Signature time on data dT.

ETHD Time to create Hash of data dT.

ETHC Time to create Hash of codeC.

ETAEK Time to perform asymmetric encryption of symmetric key K2.

ETSEC Time to perform symmetric encryption on code C.

ET0

ADK Time to asymmetric decrypt K2.

ET0

SDC Time to decrypt codeC.

ET0

HC Time to create hash of codeC.

ET0

HD Time to create hash of data DTi.e. create time of keyK1.

5.3. Performance comparisons

We analyse the performance of both the approaches with following factors:

Time to provide integrity due to hash operation.

Time to provide confidentiality due to asymmetric and symmetric encryption.

Time to provide authenticity due to signature mechanism.

Time to provide integrity due to hash operation:

According to Eq. (2) and (3), total time to provide integrity in self-protection approach is represented by

THCþTHAþT0HC þT

0

HcomþT

0

HAþT

0

Hcom2 ð6Þ

Since THC¼T0HC And THA¼T0HA

So, total time is taken to provide integrity in self-protection scheme is denoted by

TH¼2nT_HCþ2nT_HAþT0

HcomþT0Hcom2 ð7Þ

Our protocol provides integrity assurance in the time limit represented by

ETH¼ETHDþETHCþETHC0 þETHcomp1’ þETHD’ ð8Þ

SinceETHD¼ET0HD

THcom2’ ¼ETHcomp1’ ¼ET0Hcomp1

and

ETHC¼ET0HC¼ THA

So,

ETH¼2nETHDþ2nTHAþT0Hcom2 ð9Þ

Since controller code (C)’s size is more than the collected data size (Result DT) which is collected through the agent. So the time taken to create hash of dataDTi.e. creation of key componentK1 is less than the time taken to create hash of controller codeC. This inequalities is shown ininequð1Þ.

ETHD{THC inequð1Þ

If we compare Eq.(7)with (9) it can be seen that, our protocol provides integrity verification in less time as compare to previous self-protection approach. This inequalities is shown ininequð2Þ.

ETH{TH inequð2Þ

One more important add-on of our approach is that with providing integrity to the data collected, simultaneously a key is generated to ensure confidentiality at receiver end during decryp-tion of the execudecryp-tion code.

Time to provide confidentiality due to asymmetric and sym-metric encryption:

According to Eqs.(2) and (3), self-protection technique takes time TE to provide execution privacy to the mobile code is represented by

TE¼TAEþT0AD ð10Þ

In self-protection approach, data which is to be encrypted according to Eq.(1)are ðdj,ESaðHðdjÞÞÞ,HðCÞ, wheredj is execu-table code andCis controller code. Our protocol provides same execution privacy with low computational overhead. To achieve better performance in real time we encrypt the executable code with symmetric key encryption rather than asymmetric encryp-tion. As we earlier stated that execution data (result) size is very less as compared to the whole executable code as well as controller code hence here asymmetric encryption can be

performed for providing privacy to the data (results) collected during itinerary. Previous self-protection did not talk about data (results privacy).

So, our protocol provides execution privacy to the code as well as data (Results) in time constraint ETEis represented by

ETE¼ETAEDþETAEKþETSECþET0ADKþET

0

SDC ð11Þ

If we compare time TE with ETE, it can be inferred that our approach takes less amount of time to provide execution privacy as compare to previous self-protection approach which is repre-sented by inequalities (3). This is because in self-protection scheme, asymmetric encryption is applied on the whole code and its digitally signed hash value along with hash value of controller code whereas in our scheme, asymmetric encryption is used only for secure key distribution as well as to provide privacy to the execution results (data) generated at each host. Result’s size is normally just few chunks of bytes and key size is 128 bit in our protocol as we use AES for encrypting execution code.

TEcET_E inequð3Þ

Time to provide authenticity and integrity due to signature mechanism:

In self-protection technique, digital signature and hashing is required on executing code because it is needed to authenticate execution code and controller code before giving results of plat-form decryption function to the controller code where as in our approach, we divide the encryption key K into two halves in which one component is used to authenticate the receiver and second component comes with agent itself. We apply digital signature on the result generated to provide authenticity and integrity to the results. In this respect, as authenticity overhead is concerned our approach behaves better again.

6. Implementation details with comparative analysis of results

The whole scheme has been implemented and tested as an add-on to the well-known JADE platform, providing a down-to-earth realization of the proposed mechanisms. This implementa-tion fosters our confidence in the viability of the protecimplementa-tion scheme.

Java Agent Development Framework (JADE) (Vila et al., 2007;

JADE Board, 2005; Bellifemine et al., 2010; Caire, 2009) is a software development framework aimed at developing multi-agent systems and applications conforming to FIPA standards for intelligent agents. JADE is written in Java language and is made of various Java packages, giving application programmers both ready-made pieces of functionality and abstract interfaces for custom application dependent tasks.

We tested our application on a LAN with a server which acts as an agent owner and three clients exist as an execution environ-ment for the agent. In our proposed model a main container has to be formed at the server’s side which would be containing the entire containers present in the client’s sides of network. We suppose each container as a host and main container as an agent owner for the simulation of our protocol (seeFig. 3).

6.1. Implementation details

in an encrypted form and if the code’s and data’s integrity is maintained, code is executed to retrieve the data and then moved to next host only if its integrity is maintained after execution. Integrity’s verification is performed at the two points of imple-mentation, first of all, when the code arrives at execution plat-form (host) to ensure that no changes are made to it during transmission and after that, when the code is ready to migrate on the next execution environment after execution of the current execution platform.

Following agents and code are created for implementing our protocol.

Executable code (Executable. class): The executable code

(Executable. Class) migrates to each host in encrypted form and executed there to retrieve data from each execution platform. It goes as an encrypted variable to each host, decrypted and executed within the programme (MobileAgent.class) itself to retrieve data (seeFig. 4).

Mobile Agent (Code carrying Agent) (MobileAgent3.class): MobileAgent3.class is the main agent which encapsulates the execution code (Executable. class) and data in the form of variable. It is also responsible for implementing security protocol using java and jade security features.

Controller Agent (ControllerAgent3.class): Controller agent triggers the movement of the mobile agent from the origin.

6.2. Results analysis

InSection 5, we analysed the performances of self-protection approach and our protocol on the basis of time needed to provide confidentiality, integrity and authentication. In this section, we verify our protocol’s performance by implementations results. We execute the protocol and self-protection approach 30 times and analyse the average time’s components devoted for each sub-operations including encryption, decryption, hash comparisons, digital signature etc. of both the protocols.

Time to provide integrity of code and data:

According to Eqs.(7) and (9), the average total time taken by self-protection approach to provide integrity isTH¼276747:3 ms

whereas in our case (our protocol) it is onlyETH¼40131:71 ms which is approx 7 times less and save approx 85% computational efficiency as compared to self-protection approach.Table 9shows each time’s component devoted for integrity verification. In the

Table 9, it can be seen that, the hash checking time of controller codeðTHcom’ Þcreates extra overhead in the case of self-protection approach. Fig. 5 depicts the comparison between existing self-protection approach with our approach. The existing self-protec-tion scheme and our proposed protocol are implemented and tested in the systems with the configuration of 1 GB RAM and 2.2 GHz Dual core processor. The Message digest (MD-5) algorithm is used to generate the hash value for integrity verification which produces 128 bits of hash value.

Time to provide confidentiality due to asymmetric and symmetric encryption:

In Section 5, we analysed the time needed to provide

con-fidentiality due to asymmetric and symmetric encryption. Accord-ing to Eqs.(10) and (11), the total time taken by self-protection approach to provide confidentiality isTE¼4,272,300 ms, whereas our protocol takes onlyETE¼49,263:64 ms. Table 10 shows the encryption and decryption time’s comparison between our approach and self-protection approach. Through implementation, we verify our analysis and inequalities discussed inSection 5.3. In terms of time complexity, we find our approach 86 times better than previous self-protection approach after performing imple-mentation. We used Rivest Shamir Adleman (RSA) algorithm for asymmetric encryption as well as for digital signature whereas AES-128 bits is used for symmetric encryption.

Unlike self-protection protocol, our protocol also provides the confidentiality to the data part of mobile agent which creates less overhead in terms of the cost of asymmetric encryption of data

ðETAEDÞ. As data size is in few bytes (here 50 bytes) so using asymmetric encryption is not a bad idea for providing confidenti-ality. But, the main prominent feature of our protocol is that, we encrypt the mobile agent’s code by symmetric key encryption rather than asymmetric key encryption. In order to strengthen the security we distribute the symmetric key’s component through asymmetric encryption. FromTable 10, it can be observe that, the key size (128 bits) is less than the code size (1024 bytes). So we apply symmetric key encryption for the encryption of code as its size is large whereas previous self-protection approach applied asymmetric encryption for the same and creates large amount of overhead.

7. Conclusions and future work

In this paper, we proposed a protocol to make mobile agent self-protected in such a manner that it can assure its confidenti-ality in channel as well as at execution environment parallel with integrity maintenance at execution time. To protect mobile agent from malicious execution environment, it should be necessary to give less authority of security verification to the execution environment end.

Main Container (Agent owner)

Controller Agent MobileAgent

Platform2 Platform3 Platform4

Container-1 Container-2 Container-3

MobileAgent MobileAgent MobileAgent

Fig. 3.Basic architecture of our setup.

MobileAgent (MobileAgent.class) Output

Executable code (Executable. class)

Data (Results)

Run time class Container

Fig. 4.Interaction of agent with execution platform.

Table 9

Integrity verification average time comparison.

Time parameter

Self-protection (ms)TH

Our protocol (ms)ETH

% Saving ðTHETHÞ=TH

Times better

TH¼NnETH

2nTHC 198.33 –

2nTHA 45.42 44.8

T0

Hcom 236,451.3 –

T0

Hcom2 40,052.83 40,052.83

2nETHD – 34.08

Sum 276,747.9 40,131.71 85% N¼7

We performed the agent driven approach wherein agent hides its sensitive execution part of code from the environment. In order to make it happen, we propose a novel concept of key component distribution. In our protocol, for providing confidenti-ality, a symmetric key is generated which is composed of two key components, one key component is generated by the hash value of data collected during agent’s itinerary and another component is created randomly chosen (AES generated).

Here in spite of distributing whole key, sender host distributes only AES generated key component to the recipient host so that by getting this component, recipient cannot be able to decipher the encrypted information. To decrypt the encrypted information, another key component generated by the hash value of data collected is also needed. In this way, we ensure confidentiality based on integrity verification.

Our protocol is motivated from self-protection technique of mobile agent, but integrating the issue of confidentiality, integrity and authentication together, we gave a new direction to this prominent approach. Additionally to verify our protocol, we used Petri net based model and compared the time and space complexity with existing self-protection approach. It can be inferred from our protocol that applying agent driven approach and assuring confidentiality based on integrity may give the new birth to the agent based technology.

References

Ametller J, Robles S, Ortega-Ruiz JA. Self-protected mobile agents.New York: ACM; 2004 p. 362–7.

Armoogum Sandhya, Caully Asvin. Obfuscation techniques for mobile agent code confidentiality. Journal of Information & Systems Management 2011:25–36. Bellifemine Fabio, Caire Giovanni, Trucco Tiziana, Rimassa Giovanni. JADE

PRO-GRAMMER’s GUIDE, 08 April 2010. JADE 4.0.

Benachenhou Lotfi, Pierre Samuel. Protection of a mobile agent with a reference clone. Computer Communications 2006;29:268–78.

Borselius N. Mobile agent security. Electronics & Communication Engineering Journal 2002:211–8.

Caire Giovanni. JADE PROGRAMMING FOR BEGINNERS, 30 June 2009. JADE 3.7. El Rhazi Abdelmorhit, Pierre Samuel, Boucheneb Hanifa. A secure protocol based

on a sedentary agent for mobile agent environments. Journal of Computer Science 2007;3(1):35–42.

Esfandi A, Rahimabadi AM. Mobile agent security in multi agent environments using a multi agent-multi key approach. In: Proceedings of the 2nd IEEE international conference on computer science and information technology, ICCSIT 2009; 8–11 August 2009. p. 438–42.

Farmer William, Guttman Joshua, Swarup Vipin. Security for mobile agents: authentication and state appraisal. In: Proceedings of the 4th European symposium on research in computer security (ESORICS ‘96); September 1996. p. 118–30.

Guan Huanmei, Zhang Huanguo. A communication security protocol of mobile agent system. vol. 15(2). Berlin Heidelberg: Wuhan University and Springer-Verlag; 2010. p. 117–20.

Hohl Fritz. Time limited black box security: protecting mobile agents from malicious hosts. In: Vigna G, editor. Mobile agents and security in LNCS, vol. 1419. Berlin: Springer-Verlag; 1998. p. 92–113.

Ismail Leila. Evaluation of authentication mechanisms for mobile agents on top of Java. In: Proceedings of the 6th IEEE/ACIS international conference on computer and information science, ICIS 2007; 2007a. p. 663–8.

Ismail Leila. Authentication mechanisms for mobile agents. In: Proceedings of the second international conference on availability, reliability and security (ARES’07). IEEE; 2007b.

JADE Board. JADE SECURITY GUIDE; 28 February 2005. JADE 3.3.

JansenWA, Karygiannis T. Mobile agent security. NIST: National Institute of Standards and Technology, Special Publications 800-819, 2000.

Lange DB, Oshima M. Seven good reasons for mobile agents. Communications of the ACM 1999;42(3):88–9.

Lee Jaewon, Hong Seong-Min. Securing mobile agents by integrity-based encryp-tion. In: Proceedings of the 7th international conference on advanced com-munication technology—ICACT; 2005. p. 513–8.

Lee Jaewon, Hong Seong-Min, Yoon Hyunsoo. Securing mobile agents by integrity-based encryption. In: Proceedings of the 7th international conference on advanced communication technology, ICACT 2005, vol. 1; 2005. p. 508–13. Lee, Necula. Research on proof-carrying code on mobile-code security.

In: Proceedings of the workshop on foundations of mobile code security; 1997.

Lu Ma, Jeffrey JPTsai. Security modeling and analysis of mobile agent system, 57. Shelton Street Covent Garden, London: Imperial College Press; 2006. Ma Lu, Tsai Jeffrey JP. Formal modeling and analysis of a secure mobile-agent

system. IEEE Transactions on Systems, Man, and Cybernetics—Part A: Systems and Humans 2008;38(1).

Fig. 5.Comparison of integrity verification time.

Table 10

Average encryption time comparison.

Time parameter Execution time (our protocol) (in ms)ETE Size Execution time (self-protection) (in ms)TE Times betterTE¼NnETE

ETAED 21,650.17 50 Byte –

ETAEK 67.45 128 bit –

ETSEC 2822.83 1003 Byte –

TAE – 1024 Byte Approx min (423,000) (apply scaling)

ET0

ADK 21958.79 128 bits –

ET0

SDC 2764.40 1003 Byte –

T0

AD – 1024 Byte Approx min (4,230,000)