JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617

HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 102

Mobile Agent Security and Key Management Technique

V Sreekanth, Prof S. Ramchandram, and Prof A.Govardhan

Abstract— Mobile agent technology is a new paradigm of distributed computing that can replace the conventional client-server
model. However, it has not become popular due to some problems such as security. The fact that hosts have complete control
over all the programs makes it very hard to protect mobile agents from untrusted hosts. The cryptographic key generation and
distribution mechanism strongly holds the success of the mobile agent security systems. The agents and hosts are mutually
distrusting each other, but they trust the third parties. In this paper, this property is exploited for the secure way of generating
and distributing the keys using service oriented architecture.

Index Terms— Mobile Agents, Security, Key Exchange, JADE.

——————————  ——————————

1 INTRODUCTION

W ITH the advent of new computing paradigms like

mobile code and ubiquitous computing, the priva-
cy and integrity of software programs become a
major concern beyond classical data security considera-
tions. Running a program in a potentially hostile envi-
ronment may raise various security concerns. The securi-
ty concerns can be classified in two broad categories, ac-
cording to whether the agent’s or the platform’s security
is at stake.
On the one hand, host platforms receiving and executing
mobile agents must be protected against malicious code.
Common mechanisms addressing this issue include cryp-
tographic authentication and integrity checks, code sign-
ing and encryption, etc. On the other hand, mobile agents
must protect themselves against hosts trying to tamper
maliciously with either the code or the data carried by
incoming agents. This issue, known as the malicious host
problem, is usually addressed by the introduction of ap-
plication-level cryptographic protocols [6, 10, 9, 8] whose
aim is providing two basic guarantees: confidentiality
and integrity.
The use of design patterns is an approach to improve the
development process of applications and the quality of
the final products. Some mobile agent design patterns
have already been proposed. However, most of these pat-
terns have not been concretely implemented yet. In addi-
tion, there is not enough concrete information on how
they can be implemented and on whether they are techni-
cally feasible when considering a specific agent platform.
This paper discuss about the experimental setup built by
————————————————
 V Sreekanth is persuing his Ph.D from Jawaharlal Nehru Technological
University, Hyderabad, AP. Currently employed in Tata Consultancy Ser- malicious host.
vices, Plano, TX, 75024.
 Prof S Ramchandram, Dept. of Computer Science & Engg, University
College of Engineering (A), Osmania University Hyderabad – 500 007,
INDIA
 Prof. A Govardhan, Principal, JNTUH College of Engg, Nachupally, Ka-
rimnagar, AP.
the authors. This setup is useful for collecting bids (Of-
fers) from each of the hosts. This system also addresses
security issues for the system, evaluate possible attacks by
malicious hosts, and devise and implement solutions to
protect the system against these attacks.
2 DEFINATIONS AND NOTATIONS
The integrity of an agent means that neither code nor the
execution state should be changed by an unauthorized
host, and if the code or execution state has been tampered
with, such changes should be detectable (the owner, host
or an agent platform, that wants to interact with the
agent).
The authorized changes occur only when the agent has to
migrate from one host to another. The formal definitions
are given below:
Definition 1 (Integrity of an agent): An agent’s integrity is
not compromised if any unauthorized modification can
be detected by the agent’s owner.
Definition 2 (Weak forward integrity): If in is the first ma-
licious agent place on the itinerary, the integrity of each
partial result m0, …, mn-1 is provided.
Weak forward integrity is conceptually not resistant to
cooperating malicious hosts and agent places that are vi-
sited twice. To really protect the integrity of partial result
we need a definition without constraints.
As defined by Yee[11], if a mobile agent visits a sequence
of hosts S1,S2,…Sn, and the first malicious host is after
Sm, where 1≤m≤n-1, then none of the partial results gen-
erated at hosts Si (i ≤ m) can be undetectably modified by
Definition 3 (Strong forward integrity): None of the encap-
sulated messages mk, with k<n, can be modified.
If a mobile agent visits a sequence of hosts S1,S2,…,Sn,
and the first malicious host is after Sm, then none of the
encapsulated offers Ok where k>m can be modified.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
This paper refers to forward integrity as strong forward
integrity (when applicable). To make notion of forward
integrity more useful, publicly verifiable forward integri-
ty is also defined, that enables any host to detect com-
promised agents.
Definition 4 (Publicly verifiable forward integrity): Any
host Si can verify that the chain of partial results
m(i0),….m(in-1) has not been compromised.
Definition 5 (Insertion Resilience): Offers can only be add-
ed to the agent data by authorized hosts.
Definition 6 (Truncation Resilience): The chain can only be
truncated at i if the host Si colludes with the malicious
host(s).
TABLE 1: NOTATIONS USED
S0 Source System of the Agent (Origin of Mobile
Agent)
Si (i>=1) Set of hosts the Agent visits (intermediate Hosts)
oi Original Bid made by host Si
Oi Encapsulated offer from Si
H(x) Cryptographic hash function
ri Nonce generated by Si
MACki(x) Message Authentication Code generated using
secret key ki
As mentioned, each of these protocols has a common se-
quence of phases: Initial setup by originator, initial visit
on intermediate hosts, and update of data and verification
of data integrity. The agent visits a sequence of hosts s1,
s2, ...sn, and obtain an offer oi from each host, where an
offer includes not only a price but some indication of the
source of the offer, usually set of offers ω, a set of encap-
sulated offers Ω and key k, and we use subscript to de-
note these values over time. For example, ωi represents
the value of ω after the agent has visited the ith host.
3 SECURITY REQUIREMENTS
This paper is aimed to provide a technical basis for build-
ing trustworthy agents that perform their missions with
confidence even though they sometimes execute on un-
trusted hosts. Several key requirements must be satisfied
for agent systems to realize their potential:
High Mobility: Agents must be free to migrate to, and ex-
ecute on, a wide variety of hosts that are unknown to the
users who launched the agents. Without such mobility,
agents will be unable to perform the searching and com-
mercial operations often envisioned for agent technology.
Detached Operation: Agents must operate autonomously,
without the need for constant communication with users,
and, preferably, without constant communication with
103
trusted infrastructure elements which may or may not
exist.
Extended Deployment Periods: Agents must function for
extended periods of time, thus allowing users to launch
long-term “watcher” agents that take action only if speci-
fied criteria have been met and other long-term service
agents.
Safe Execution: Agents must be free from integrity attacks
conducted by malicious hosts or other agents, and must
be protected from faulty execution or non-execution by
malicious hosts. Agents will also be much more useful if
they can carry secrets (such as cryptographic keys or user
decision information, such as how much a user would be
willing to pay for merchandise).
Realistic Infrastructure Requirements: Agent properties
must not rely on unrealistic infrastructure assumptions,
such as the assumption that all hosts are trustworthy, that
implementation algorithms will remain secret, or that
every agent execution environment is implemented by a
tamper-resistant hardware peripheral.
4 CURRENT AGENT INTEGRITY
TECHNIQUE
This technique of agent integrity and key generation is
the extension of Yee’s Strong forward integrity, which
says none of the offers in the agent data can be modified
without detection by the originator, was extended by oth-
ers. Each offer in the data set is chained to the next one
using the identity of the next host to be visited by the
agent. Upon agent return, for each visited host, the origi-
nator decrypts the random nonce and generates the secret
keys. If the chaining relation fails at a particular point, all
subsequent offers are rejected.
The originator generates the initial key K1, ω0 & Ω0 are in-
itially set to NULL. Each host generates a random nonce ri
and encrypts it using the originator’s public key to in-
clude the offer from ith and the identity of the i+1 (next)
host. The term ri prevents a host si from being able to
modify the offers of hosts that follow it, since it cannot
identify the chaining value that must be inserted into the
encapsulated offer of the hosts that follow it.
4.1 Key Generation
The initial random key is set by the originator. The subse-
quent keys are generated by the agent after visiting the
host. The value ri is an input to the computation of the
next secret key ki+1.
Ki+1 = h(ki, ri, oi, Si+1)
As the key changes for a host on each visit, it would not
be possible for the malicious host to change the offer
submitted by the host. However, this also comes with the
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 104

limitation that a host cannot update the offers it has sub-
mitted as the offer itself is used in computing the key.
4.2 Encryption and Decryption of Data
Each host generates the offer oi, and the first offer is en-
crypted using the random key generated by the Origina-
tor. All the subsequent offers are encrypted by the key
generated by the previous host. As the Agent reaches the
originator, the originator decrypts the first offer using the
random key it generated. This would also give the key the
next offer is encapsulated with. All the subsequent keys
are generated by each of the offers submitted by the host.
Setup on Source System: (Originator)
S0 -> S1:
ω0 = Ø; Ω0 = Ø
K1 = random initial key
(ii) Since the offer itself is used in computing the
key for the next host, offers may not be
changed, and a new key must be generated
each time when the agent re-visits a host.
(iii) A limited degree of insertion resilience is en-
sured by this protocol. A malicious server
cannot insert spurious offers into the chain of
hosts visited prior to it. However, it is possi-
ble for a malicious server to insert data in the
chain from this point onward, since the tech-
nique explicitly allows a host to do so. In a
chain of encapsulated offers O1, … Om, it is
possible to detect any truncation at k < m,
assuming that m is not malicious. However,
a malicious host can truncate all the offers
following its own and can insert fake offers.

Visit on a hostSi :
5 PROPOSED KEY EXCHANGE AND AGENT
Encapsulated Offer INTEGRITY TECHNIQUE
Oi = (oi, MACKi(ri, oi, Si+1))
The proposed key exchange and agent integrity technique
Protocol
will overcome the limitations discussed in the previous
Si -> Si+1:
technique. The three important areas of focus of the cur-
Ri = ENC0(ri) ; ωi = ωi-1 U {oi, Ri }
rent technique are
Ωi = Ωi-1 U {Oi};
(i) Authentication & Key Exchange
(ii) Integrity of code and mobile agent
(iii) Protection of bid collected from each host
and partial encapsulation of data
5.1 Authentication & Key Exchange

A new trusted Third Party Key Exchange (TPKE) server is

introduced that serves the purpose of a Certifying Agent
(CA). Public Key Infrastructure is setup by this trusted
third party key exchange server. This third party server
shares the public key of the originator with the hosts so
that the offers are encrypted with the Originator public
key. This architecture resembles a closed set of hosts reg-
istered to a trusted CA.
Figure 1 demonstrates the Agent life cycle and key gener-
ation. This technique allows an agent to take predefined
action when certain condition is met. The approach cen-
ters on constructing agents in such a way that upon re-
ceiving an offer from the host, the offer is encrypted and
the subsequent key is generated. After all the offers are
collected, the agent returns to the originator. The path of
the mobile agent is predefined and the agent counts the
number of hops it made to validate with the initial count
to check no malicious hosts have submitted their offers.

4.3 Limitations

(i) The important limitation of this technique is

the verification by the originator must be
performed sequentially i.e., the decryption
can be performed only in the order the agent
has visited. The originator must have the
prior knowledge of the order of the hosts to
5.2 Integrity of Code & Mobile Agent
be visited.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
The code and the data of the Mobile Agent is Digitally
Signed and encrypted with the Originator’s Private Key.
As the Mobile Agent reaches the host, the Host verifies
the Digital Signature to validate the Mobile Agent so that
the host is not attacked with a malicious agent. The host
decrypts the data and updates its offer oi in the Agent.
Each host generates a random nonce ri and the encrypted
offer is generated by encrypting with the shared key. The
encryption technique is similar the one discussed earlier.
Setup on Source System: (Originator)
S0 -> S1:
ω0 = Ø; Ω0 = Ø
K1 = key received from TPKE server
Visit on a hostSi :
Encapsulated Offer
Oi = (oi, MACKi(ri, oi, Si+1))
Protocol
Si -> Si+1:
Ri = ENC0(ri) ; ωi = ωi-1 U {oi, Ri }
Ωi = Ωi-1 U {Oi};
Since the number of host visited by an Agent is prede-
fined by the number of hosts exchanging the keys with
the TPKE server, hop count can be used to restrict the
number of hosts an Agent visits. An additional function
selfDestruct() is used to automatically destruct an Agent
when a tamper is detected. This validation is run by the
agent each time it visits a host and before collecting the
bid from the host.
5.3 Data Encapsulation
Each of the partially encrypted offer is collected from the
host is placed at the end of the Agent. A different key Ki is
used by each host so that the offer encrypted by one host
is not readable by the subsequent hosts. This technique
allows a host to update the bid it offered earlier. Since the
key a host shares is different from the keys other hosts
share, the host can decrypt the encrypted offer, update it
and encrypt it back using the same key.
Update: (Changing a previous offer oj)
Encapsulated Offer
Oi = (oi, MAXCkj (ri, oi, Si+1))
Protocol
Si - > Si+1:
Ri = ENC0(ri) ; ωi= ωi-1 U {(oi, Ri) }
Ωi = Ωi – 1 U {Oi};
Since the code and data are read by only authorized
Agents and each offer given by the host is digitally
signed, a host can never deny the fact that is has given a
bid.
The mobile agent reaches the originator and the origina-
tor decrypts each bid to read the offers. This technique
105
overcomes all the limitations discussed in the previous
section. Since we are using TPKE server, malicious hosts
will never be able to put in their bids nor read the data or
code. Another problem that a malicious host puts in thou-
sands of offers to flood the Agent can be avoided since
the number of bids an Agent expect is always equal to the
hop count.
6. IMPLEMENTATION
The proposed system is implemented using Java Agent
Development Framework (JADE). JADE simplifies the
implementation of multi-agent systems through a middle-
ware that complies with the FIPA specifications and
through a set of graphical tools that supports the debug-
ging and deployment phases. The agent platform can be
distributed across machines (which not even need to
share the same OS) and the configuration can be con-
trolled via a remote GUI. The configuration can be even
changed at run-time by moving agents from one machine
to another one, as and when required.
The hardware used is 2 Intel Centrino Laptops having 2
GB RAM and Windows XP as the operating system. One
system is set as an originator and the second system is
setup to 5 different Host Frames. The bidding system is
designed in such a way that each host is visited at least
once. The Key exchange server is setup on the originator
system and designed to generate a 1024 bit key for each
host.
The implementation of this platform has been simplified
since the platform already provides a Directory Facilitator
(DF). The originator is setup to register for DF, the agent
must include in its initialization (setup) the following
piece of code (Figure 3). The Host system sending bids is
implemented using a Facilitator Agent (FA). When the
agent receives a message, it adds the SearchBehaviour,
that will do the search according to the type defined in
the message and then it returns the results to the request-
er agent.
The application system is designed to retrieve the cost of
an Air Ticket phone from each host. The originator signs
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 106

his request and floated across the hosts. The hosts are
giving their offer in an encrypted form and this encrypted
offer is digitally signed. Finally the host receives the data
in a secure way. The agent gets the key through the Third
Party Key Exchange server and decrypts each bid sent by
the host and presented to the user. Each of the bid is en-
crypted by a 1024 bit key and is completely protected.
Verlag, 2002.
[11] B.Yee A Sanctuary for mobile agents. In J.Vitek
and C.Jensen, editors, Secure Internet Programming,
volume 1603 if lecture notes in Computer Science, p.
261-273. Springer-Verlag,1999.

7 CONCLUSION
This paper has attempted to improve the security aspects
of mobile agents by proposing an approach based on Cer-
tifying Authority (CA). The major issue of distributing
cryptographic keys is solved using a trusted Third Party
Key Exchange server. This application may be extended
in future to develop new system architecture to ensure
the security at the system level itself.

8 REFERENCES

[1] Jade, java agent development framework.

http://jade.cselt.it, 2004.
[2] William M. Farmer, Joshua D. Guttman, and Vipin
Swarup. Security for mobile agents: Authentication and
state appraisal. In Proceedings of the Fourth European
Symposium on Research in Computer Security, pages
118–130, Rome, Italy, 1996.
[3] Erich Gamma, Richard Helm, Ralph Johnson, and John
Vlissides. Design Patterns: Elements od Reusable Object-
Oriented Software. Addison-Wesley Professional Compu-
ting Series. Addison-Wesley Publishing Company, New
York, NY, 1995.
[4] F. Hohl. A Model of Attacks of Malicious Hosts
Against Mobile Agents. In Proceedings of the ECOOP
Workshop on Distributed Object Security and 4th Work-
shop on Mobile Object Systems: Secure Internet Mobile
Computations, pages 105–120, INRIA, France, 1998.
[5] V Sreekanth, Prof S.Ramchandram, Prof A.Govardhan
A Novel Approach for Security and Integrity of Mobile
Agents. ICCBN 2008, IISc, Bangalore
[6] Neeran M. Karnik and Anand R. Tripathi. Security in
the Ajanta mobile agent system. Software Practice and
Experience, 31(4):301–329, 2001.
[7] Chess David M. Security issues in mobile code sys-
tems. In Mobile Agents and Security, volume 1419, pages
1–14.
Springer Verlag, 1998.
[8] J. Mir and J. Borrell. Protecting mobile agent itinera-
ries. In Mobile Agents for Telecommunication Applica-
tions (MATA), volume 2881 of Lecture Notes in Comput-
er Science, pages 275–285. Springer Verlag, October 2003.
[9] S. Robles, J. Mir, and J. Borrell. Marism-a: An architec-
ture for mobile agents with recursive itinerary and secure
migration. In 2nd. IW on Security of Mobile Multiagent
Systems, Bologna, July 2002.
[10] V. Roth. Empowering mobile software agents. In
Proc. 6th IEEE Mobile Agents Conference, volume 2535 of
Lecture Notes in Computer Science, pages 47–63. Spinger