Professional Documents
Culture Documents
SYSTEMS
A Thesis Presented to
In Partial Fulfillment
Master of Science
(Computer Science)
by
particular, mobile agents can provide much greater flexibility and robustness than the
traditional distributed system methodologies since they provide mobility from platform
to platform. Thus, they form a vast area of research. One key problem faced by the
mobile agent systems is security. A migrating agent can face many threats while
migrating to a host/ agent platform. Similarly the platform can be maliciously affected
deal with security of mobile agents. In this thesis, we present an overview of such threats
and present an "agent threat model" for mobile agent systems. Based on this model we
survey and evaluate the techniques that provide countermeasures to the mobile agent
security of certain mobile agent systems is discussed. The thesis presents a proposed
framework to provide mobile agent system security from both malicious mobile agents
for mobile agent system security and protection. The proposed framework is comprised
implementation of the system is discussed and the evaluation of the proposed framework
Acknowledgements
The completion of a long and tough journey in the form of my Master’s thesis would not
have been possible without the remarkable support and supervision of Dr. M. Jaffar-ur-
Rehman whose memory and guidance lives long with me. Hoping that my thesis and my
research work has met his expectations; this thesis is dedicated to him.
I also thank Mr. Aamer Nadeem for his great advice during the course of my thesis,
especially during the end of it. I thank him for his time, his comments and those helpful
sessions discussing my work, without which this thesis would never have been
completed.
I thank the members of the Centre for Software Dependability (CSD), their help and
their massive inputs that constructed and gave life to the work in this thesis and being
like a family to me. I would specially like to thank Mr. Masud Khokhar for introducing
Thanks to Mr. Uzair Khan, Mr. Shaukat Ali, Mrs. Zille Huma and Mr. Zouhaib Zafar for
I thank the faculty, the students and the staff of Mohammad Ali Jinnah University for
helping me achieves my goals. The faculty has always been available for a lot of help
and guidance. I especially thank Prof. Zafar I. Malik for his immense support throughout
the course of my thesis. His advice and his heart-lifting comments are duly appreciated.
The staff is cordially appreciated, especially for the CSD lab and its facilities that let the
I would also like to thank all my friends for their moral support, especially my old batch
mates from my undergrad (the BS-6). I specifically thank Mr. Shahid Ishtiaq, Mr. Waqas
v
Mahmood, Mr. Ifraseab Afzal, Mr. Waqas Javed, Mr. Ibraheem Zaman, Mr. Raja Asad
and Mr. Waqas Raza for removing all the writer’s blocks I faced. I also appreciate, Mr.
Abeer-ur-Rehman for sending a very handy gift during my write-up. Also, I thank Mr.
Wajahat Nosherwan for his comments on the proposed framework and the numerous
progress in my education, my father for his counseling on living life and my mother for
her prayers. My brother and sister for staying up with me on my long nights and not
letting me fall asleep. I am extremely grateful for their patience and their high-spirits
that helped me focus through many difficult times during the course of my educational
I thank Allah (SWT) for bestowing me with His uncountable blessings that are far too
Table of Contents
List of Figures
List of Tables
Introduction
Software systems have advanced immensely with the technology march with special
existence. This advent of distributed system application and performance has lead to
many research dimensions and topics. Since distributed systems require immense
communication between its components or subsystems and the information that they
share is considerably large in amount, approaches to access, search and access of this is
vital. So, for this, various theories for communication and information retrieval exist.
Distributed systems came into existence so that a wider network could be used for
information sharing and also for service access. A large number of applications were
derived from this ability to scale a large area and distribute information and service.
Distributed systems become vitally important due to their function. However, the
function and capabilities are vast and the requirement from such systems becomes
larger. Features of such systems make the system different in construction and operation.
Performance issues include the issues of extensive reliability, like fault tolerance, safety
and security. Of these, one important issue is the security of software. When software
1
goes distributed, it becomes potentially more prone to network insecurity and threats.
Thus, it is very important to assess the threats and insecurities that the system might
undergo during its lifetime and, that the system can somehow prevent the occurrence of
attack.
Mobile agents are an innovative idea in the field of distributed system research (Kotz,
Gray & Rus, 2002). They are basically autonomous units of code and state data that can
migrate from host to host for remote processing. Their capabilities are immense in
comparison to normal remote procedure calls and remote processing as they themselves
carry the process and data but use the remote host’s capability to carry out the execution.
The uses of agents are many as their prime propose is in their name. They are actually
Mobile agents may be characterized as “good” agents that carry out tasks for us on our
behalf remotely, for example an agent to purchase a book online. The agent looks for the
book on different hosts and purchases the one that fits the criteria like its cost or its
required stock. Also, there may be “bad” agents, like viruses and worms that can go
online and travel to hosts to damage them or spy on them. As agents are composed of
code and data it can use this for virus like activity.
Mobile agents and their activity may be malicious or it may be attacked by the host it is
supposed to execute on, meaning that the host is malicious. Also, both agent and host
may be “good” but the network may be comprised of hackers. This means that the
Our aim is to create a framework to insure secure agents and hosts (Jansen &
Karygiannis, 1998). The framework that has been suggested deals with primarily the
security. The prime aim in abstract is to allow “good” mobile agents and disallow “bad”
2
mobile agents on the host and to protect the mobile agent from the host’s activity. The
agent has to send its processed information back to the host from where it came from
along with its execution log containing the entire trace of its execution on the host. Also,
the use and access of resources has to be taken into consideration. The framework
The thesis is arranged as follows: Chapter 2 covers the background to Mobile agents,
their theories and to their applications as well as giving the concepts of security that is
required in mobile agent systems. Chapter 3 presents the Threat Model that
accommodates the various threats that occur in a mobile agent system i.e. to the agent
and the agent platform. Chapter 4 surveys the countermeasures and techniques in the
literature on mobile agent security and is evaluated to see what threats are protected by
these measures using the threat model. Chapter 5 covers the various state-of-the-art
mobile agent systems and describes their security architectures and evaluates these on
the basis of the techniques that are used for security from Chapter 4. Chapter 6 details
our proposed framework and describes its components and subcomponents. Chapter 7
describes the various operation scenarios to check their security of our proposed
Chapter 9 evaluates our system and lists down the benefits and limitations of the
proposed system using the threat model and also a comparison with other state-of-the-art
mobile agent systems. Chapter 10 concludes the thesis and provides some research
directions.
3
Chapter 2
Security: A Background
This chapter gives the background that is required for mobile agent system security. It
covers the different theories that are available in the literature on mobile agents and
Taking the generic client server model, a set of traditional approaches to remote
processing can be discussed. The client server model generically contains a client that
issues a request to be processed by the server on its behalf. The server then processes the
request and responds as required. For this kind of communication model, approaches for
remote code execution were developed (Aneiba & Rees, 2004; Picco, 2001). The
approaches for remote code execution are Remote Procedure Calls and Remote
4
Code can be accessed simply by calling the procedures like through RPC (Remote
Procedure Calls) and through REV (Remote Evaluation). In RPC, the methods are
invoked by the agent through method calls. Client is the caller whereas the server is the
callee. The server responds by sending the results of the procedure execution back to the
client. In REV, the method is downloaded to the client by the server and it executes
there. Here, there are two further approaches; one is that the client may call the code for
download and execution. The other is that the code may be sent by the server to be
executed on the client according to the server. The first approach is remote execution
In contrast we have software agents that can be mobile, i.e. mobile agents that can carry
out remote code execution and overcome the limitations that traditional approaches have
To understand what software agents are, we have to understand what agents are. As
defined in various papers, agents are best defined by Franklin and Graesser (Franklin &
Graesser, 1996) that highlights the notion of what agents are according to various
definitions that people defined. However, the best understanding was found in the
definition that was derived in (Lange, 1998) that the definition of an agent is based on
for a user that has been delegated some work. As stated before the debate becomes
rather immense (Franklin & Graesser, 1996) and the requirements of an agent and its
actual meaning becomes too narrow. Thus, the definition needs to be broadened and the
definition from (Lange, 1998) is rather complete by which we adapt our definition of an
5
agent; an agent is a delegate or a representative that can operate in an environment, is
believable. Agents may possess all of these or some of these characteristics (Sundsted,
1998).
From this definition of an agent, we can define what a software agent is. A software
Rothermel and Schwehm in (Rothermel & Schwehm, 1998) classify software agents.
From this classification and the classification done in (Franklin & Graesser, 1996) we
understand that due to the features of a software agent, the agent can assume a number
of forms. In this thesis, we take the mobile agent class of software agents.
After explaining software agents, the class of mobile agents does not require much of a
formal definition. However, we do explain mobile agents and their context in the rest of
this thesis. A mobile agent is an agent that can simply carry out our tasks for us as users
remotely. By remotely, we can mean many other remote locations. A mobile agent is
thus simply one that is created at one place, carries its code and state over to another
place and resumes its execution. It does not require the remote code execution
approaches for this; instead it propagates itself over the communication network to carry
To explain what a mobile agent is, we have to understand certain basic concepts. As
explained by (White, 1998) and (Milojicic, LaForge & Chauhan, 1998) a mobile agent
system has agents and places. A place is where the agent visits in its journey. At each of
these places, there exists an agent environment to allow its execution. The environment
6
allows processing on the basis of a policy. Of course, the underlying features that define
the agent and the place implementation differ in its state-of-the-art as various mobile
(Marrow & Ghanea-Hercock, 2000) define the mobile agent computing approach and
give the features of the actual setup and features that are required. Traced from what has
been discussed and by (Marrow & Ghanea-Hercock, 2000) mobile agents have certain
fundamental features. Taking a general idea that a mobile agent moves from place to
place, a mobile agent requires the elements of mobility, communication and task
association. A mobile agent is fundamentally mobile and can migrate from place to
place as specified. Similarly, a mobile agent needs to communicate and co-ordinate with
agents and the execution environment to execute. Lastly, an agent needs to be associated
with a specialized task to perform on the behalf of the creator of the agent that it is
representing.
Mobile agents along with their features can thus provide a number of benefits to
distributed and component based systems and technology (Kotz & Gray, 1999). Their
applications due to these benefits are thus numerous. As explained in a lot of papers,
mobile agents have large potential. To assess this we highlight the benefits from mobile
agents that are mentioned in the literature. As expressed by (Lange & Oshima, 1999),
there are several good reasons for mobile agents. These are listed as follows:
1) Network load is reduced because multiple interactions are not required between the
server and the client like in traditional approaches. Instead, a mobile agent carries the
7
complete set of interactions to the server. The agent executes the commands locally and
thus reduces the set of instructions that had to be sent. Also, for a large amount of data,
transmission over channels is rather expensive; hence the mobile agent using the data
2) No delays are witnessed as the mobile agent executes at the point of execution. For
example, in the traditional approaches, a large amount of wait had to be done for a
command to be processed and responded to. In the case of mobile agents, an agent is
3) Protocols do not need to be enhanced for mobile agents that are migrating and they
can utilize the protocols at hand as for other mechanisms the protocols need to be
4) Autonomous execution makes the mobile agent independent of the creator. This is
favorable for the example of limited devices like mobile devices. The agent moves to the
8
7) Robustness is achieved because dynamism allows agents to be configurable as the
Now we discuss the applications that are possible because of mobile agents.
2.4.1.1 Telecommunication
In the field of telecommunication, mobile agents can use their advantage in reduction of
network bandwidth and can enhance these for several network services that future or
Mobile agents can be used to evolve current client/ server based network management
Mobile agents can be used for retrieval of information over a network and the Internet.
The mobile agents can carry queries and can retrieve particular information (Pham,
2001). This can be extended for cache management and searching as well.
2.4.1.4 Others
There is other work in progress in many dimensions as seen in the literature on them.
Mobile agents can be used in Global Information Systems for tracking, in Grid Systems,
9
in Intrusion detection systems, for distribution of multimedia and so on. Also, agents
Mobile agents have their immense applications and there are several benefits because of
them but they still have their limitations. Their possibilities are hindered by several
challenges (Schoder & Eymann, 2000). Some of these are limitations to the technology
and some are because there are missing solutions to numerous issues that arise in mobile
agent systems concepts and design (Rothermel, Hohl & Radounikilis, 1997; Kotz &
Gray, 1997).
Various authors have written about the mobile agent dimension limiting and the reasons
that cause the limitations to their adoption (Gray, 2004). Also, the reason has been
highlighted as because of applying it in the wrong regard despite having a clear concept
to their use (Johansen, 2004). For this the reasons listed in (Vigna, 2004) define the
limitations and their reasons quite well. The listed reasons are:
1) Performance issues can be limiting. A generalization states that agents may reduce
network bandwidth consumption and so on, but this is not true in every scenario.
to develop.
10
3) Implementing agents is also hard work as so many unpredictable interactions are
4) The testing and debugging of such systems are extremely complex. This is due to the
5) Authentication can be based on so many things the agent is associated with. For this
6) Corruption of the agents is possible as the agent transfers over the various places it
visits. This means an agent can lose its information or actually deviate from its goal.
7) Since information might be lost, the agent cannot be trusted with secret information
bases itself on mobile agents would require that all the places can execute the mobile
agent.
9) Mobile agents in order to interact require a sort of mechanism, a means to interact and
to collaborate; there is a lack of such an approach, such a language that supports this
mechanism.
11
10) Mobile agents remotely execute at one place and go to the next; this is very much
like a worm that actually can cause so much damage to the system if they are allowed to
process.
Of all the above, security is one of the greatest weaknesses to a mobile agent. Security
alone is a large reason for the lack of use of agents for providing the solutions they
A huge amount of research material is available that has either raised the notion of
security of mobile agents or has tried to solve it in one way or another. The notion of
mobile agent security is because the mobile agents that are roaming a network can be
used as malicious objects for accessing private or confidential information and resource,
for causing corruption like viruses and worms and so on. Similarly, in this regard if an
agent is supposed to be correct and non-malicious, we are never sure that the place it is
visiting may be malicious to it or not and may also leech information from the agent,
The lack of security has been highlighted mainly because of a lack in approach to so
many things that have to be secured about a mobile agent system. A mobile agent
system thus lacks approaches because of a lack of a security providing framework that
will fulfill the end to end security requirements of the agents and the places.
12
Chapter 3
- Threat Model
This chapter looks into various security threats and the aspects that may be malicious in
a MAS. Also, a MAS threat model is presented that denotes the threats that an MAS
may comprise.
Threats to a mobile agent are an area of fond interest as they stand out to the acceptance
of mobile agent systems for various applications. The vulnerabilities alone have cause
immense interest in the field of security of distributed systems. Various goals have been
highlighted to protect a system out of which some have a substantial solution and some
do not (Abdalla, Cirne, Franklin & Tabbara, 1997). This chapter identifies the threats
that occur in a mobile agent system so that a MAS can be evaluated according to the
13
The threat model has been derived from the various papers discussing the
derived threats to the MAS. In this model, we generalize the threats to the MAS and
create our own threat model. Also, the threat model includes threats from a malicious
The security of mobile agent systems encompasses protection of the mobile agent, the
platform and the network (Greenberg, Byington & Harper, 1998). Thus, the work on
security in mobile agents can be classified in to three broad categories (Gray, 1997;
Brooks, 2004):
• Malicious Agent
• Malicious Networks
Malicious platform security is necessary so as to defend the agent and the spawning host
from any platform to which the agent is transferred to. This includes various security
threats like spying on the agent and its data, masquerading or posing as a correct
platform and also the corruption or misuse of the agent (Farmer, Guttman & Swarup,
Similar to this, other agents may harm the incoming agent(s) and so may the
14
3.1.2 Malicious Agent
The protection of the platform on which the agent is executing has to be protected as
well (Farmer, Guttman & Swarup, 1996b). This is because the agent may act like a virus
and may corrupt the platform or can act as a Trojan and can spy on the platform and its
This security deals with the network on which the mobile agent is transferred to other
platforms (Farmer, Guttman & Swarup, 1996b). The networks can be tampered and
insecure channels may be created luring agents and corrupting them and may also allow
the spying on the agents themselves (Kun, Xin & Dayou, 1999). The framework
The different types of threats that the MAS would encounter according to 1) malicious
platforms, 2) malicious agents and 3) malicious networks are as follows. Like (Jansen &
Karygiannis, 1998; Jansen, 2001; Jansen & Karygiannis, 1998), we use simple mobile
agent architecture to identify the threat model shown in Figure 3.1. The arrows indicate
an underlying network that carries the mobile agent. The host O spawns a mobile agent
A to an agent platform X for execution. The mobile agent A continues its execution to
agent platform Y and so on. The three major security considerations can be expressed
here, the malicious platform, malicious agent and the malicious network. This threat
15
model is used to evaluate the techniques involved (Orso, Harrold & Vigna, 2000; Saeb,
3.2.1. Masquerading
Agent to Platform
unauthorized access or to prove another agent wrong in case of access so that the agent it
16
Agent to Agent
An agent may pose to be another agent to another agent to gain trust and thus acquire
private information.
Platform to Agent
Another case is when the agent platform poses to be another platform to the agent. The
aim is to lure the agent into its domain and to extract information or to alter it and so on.
Other services on the platform may masquerade as an agent to gain access to certain
services authorized for agents. This can happen with third party services deployed on a
platform.
DOS attacks are prevalent in network systems that are providing different services and
information. In MAS, DOS attacks may prevail through mobile agents, the platform or
Agents to Platform
Mobile agents start consuming resources during execution, so the other agents trying to
17
Agent to Agent
Also an agent may block another agent by overloading it with messages or into an
Platform to Agent
A platform may deny service to agents. This means not allowing them to execute,
delaying agent requests and responding late or ignoring them entirely or even disposing
Other services on the platform may also deny the platform its service like the underlying
Mobile agents, agent platforms and other services may try to access each other illegally.
They may try to access certain services or information for which they are not authorized.
Agent to Platform
Agents may try to access the platform and its resources (meaning the platform’s data or
services) illegally. The agent thus violates a certain security policy or right that it has on
the platform.
18
Agent to Agent
The agent may be accessed maliciously by another agent as well and may thus hinder its
Platform to Agent
The agent platform may access the agent and hinder the say it executes.
Other services, like remote users or processes may also try to access the platform or
agent through unauthorized means. They may thus hinder the operating system etc on
3.2.4. Repudiation
This type of threat appears when an agent completes an execution and denies that it ever
An agent may deny that it ever executed on a platform to regain resource or regain
information or to replay its execution but n a similar but different unauthorized resource
and so on. The agent may also repudiate another agent similarly.
Platform to Agent
Also, the platform may also deny that the agent ever executed for its own malicious
purpose. For instance, it may bluff the origin host that the agent ever came and executed.
19
This may be because the platform may have just spied on how the agent executed and
did not allow return of information to the host or may have tampered with the agent
claiming to others that the altered agent is its own and to the host that the particular
3.2.5. Eavesdropping
Agents to Platform
Agents may eavesdrop on the platform to gain information of other transactions as well
as on agents to spy out what information is being exchanged and so on. This information
can be thus misused further to lure the agent or to gain access to what kind of activity
In the case of mobile agents, the platform and the agents may be eavesdropping on
3.2.6. Alteration
Alteration is when something in the entire system is changed maliciously (Beirman &
20
Platform to Agent and Agent to Agent
An agent may be altered by the platform and may thus be corrupted. This can make the
agent malicious by a malicious platform. The agent may for example start sending data
back to the platform that altered it instead of the host. Also, an agent’s itinerary or its
travel path may be altered so that the agent route is beneficial to the altering platform.
Agent to Platform
Also, in extreme cases, the agent or agents may together corrupt the platform or its
environment, like viruses, worms and Trojans. This is thus the case when both the host
and its spawned agents are malicious. Similarly, the agent can start altering the code of
As the name suggests, the information can be copied and reused or replayed later for
malicious purpose (Beirman & Cloete, 2002). This can be used by agents, platforms and
Platform to Agent
An agent on an agent platform can be copied or its message can be copied and can be
replayed later on for malicious purposes. An agent can be then used by the platform for
its own use and activity like gaining insight into other platforms. Also, the agent
messages can be copied by the other services and can be used maliciously to gain access
of resources that may be unauthorized to the service but authorized to the agent.
21
Agent to Platform and Other services to Platform
Copy and replay can be used to resend a message over and over again to regain
resources that may only be issued one at a time for competing agents and services on a
platform. This can be utilized by an agent, a platform or the other services maliciously.
22
Chapter 4
Survey of Countermeasures
Systems
This chapter surveys the various countermeasures for the threats that a MAS may
encounter from attacks presented in the threat model. The evaluation of each technique
to protect the MAS is evaluated with respect to the threat model in chapter 2.
Mobile Agent Systems are prone to numerous threats from attackers over the network.
with other agents or the platform (Abdalla, Cirne, Franklin & Tabbara, 1997). These
activities in a MAS are all prone to various threats. Security threats have limited the use
of the mobile agent systems and have opened a door towards the suggestion of
countermeasures or the potential solutions to the security threats. These solutions have
23
caused immense theoretical interest over the years, with various levels of effectiveness
(Li, Zhang, Sun & Yin, 2004). Some of the threats have been tackled by these including
some solutions that are difficult and some are still either not solved or not possible
because of either current technology limitations, have too many assumptions or are just
The MAS is comprises of the mobile agent, the mobile agent platform, where the agent
executes and the underlying network that carries the agents from platform to platform.
These thus form the three broad areas where harm may be done to the MAS. So, the
techniques are divided into three groups. The grouping is done according to (Jansen,
1998a; Jansen & Karygiannis, 1998; Beirman & Cloete, 2002; McDonald, Yasinac,
Thompson, 2005). This work is extended in this survey to include more techniques and
to analyze these techniques according to the threat model. Another contribution is that
the techniques to protect the network have been surveyed that were not present in
(Jansen, 1998a; Jansen & Karygiannis, 1998; Beirman & Cloete, 2002; McDonald,
Agents are threatened by their surroundings, like the agent platform, other agents
(Vigna, 2004) and the execution environment of the platform they are running on
(Chess, 1998; Jansen, 1998b). To cater for the threats caused by these entities of the
MAS, various countermeasures have been suggested in the literature. This section gives
24
4.2.1 Partial Result Encapsulation
Mobile agent execution result data needs to be secured as it may be very critical or
important. Thus, the data needs to be encapsulated from possibly malicious outsiders.
Various techniques exist for the result data’s protection as the results are hidden as they
One of these approaches is highlighted in (Young & Yung, 1997) by using Sliding
Encryption. The data computed at various agent platforms is encrypted by the agent and
carried with it. This data is then decrypted at the origin (host) of the mobile agent using
a private key.
(Yee, 1997) describes the PRAC technique which uses checksums for the computed
data. The checksums are formed using a secret key by the agent. This key is generated
for the agent and the data at the host. The data is thus encrypted when the agent migrates
and the key is destroyed. So, the only remaining copy of the key is with the host.
(Karnik, 1998) gives a use of read-only states that allow only the access of agent’s
integral data. This state locks the data within the agent from all others except its owner.
The owner is authenticated by simple digital signatures and can thus modify it as
needed. Also, it uses append-only logs within the agent to carry data that cannot be
modified during the travel. It keeps appending the data that is collected at each platform.
Analysis
Result encapsulation involves the protection of agent data from the agent platform.
Masquerading of the platform and the other agents is prevented as the agent data can
only be decrypted by an entity that possesses the key to access the mobile agent’s data.
25
Since this data is encrypted, it cannot be eavesdropped on for any purpose as well.
Access is authorized through the key. This data is accessible by platforms for viewing
masquerade as another. Thus, anyone with a key will be able to access the results and
may even be allowed to alter them, if there is no way of making the agent data read-
only. An agent cannot guard itself from denial of service on a platform through partial
solved either. An agent cannot be protected from copy and replay. An agent message can
still be copied. However, the message meaning may be locked inside the agent’s
This technique involves the agent to generate a key for its own access to the platform if
certain conditions are met. (Jansen, 1998a; Jansen & Karygiannis, 1998; Beirman &
Cloete, 2002; Bellavista, Corradi, Federici, Montanari & Tibaldi, 2003) describe the
encryption of the data that an agent carries and it only decipherable according to a key.
When the agent reaches a platform, it searches for the required information on the agent
platform. If this information is found, it is used to generate a key. This key in turn
decrypts the agent information and thus the information is accessible. This has also been
called the clueless agents approach by Tsuchudin in (Tschudin, 1999) as the agents have
no clue until and unless a particular environmental condition becomes true (i.e. the key).
26
Analysis
allow the platform to access the mobile agent. Thus, a key is generated based on certain
to the agent. Only a platform that uniquely possesses these values can process the agent.
Also, an agent cannot be accessed until the platform is identified. The environment
values to access the agent are used by the agent to determine what level of access to
grant the platform. Thus, an agent cannot be spied on and eavesdropped on in anyway
and the agent cannot be tampered or altered or copied, since the access is restricted.
However, there is no safeguard against denial of service from the platform as an agent
may be blocked out after access by the platform. Also, since no logging or history is
To protect the agent, techniques like time-limited black box protection has that been
proposed by Hohl (Hohl, 1998a; Hohl, 1998b). This technique involves the scrambling
of code such that it is not interpretable in function and operation. This is also referred to
In Hohl’s approach (Hohl, 1998a; Hohl, 1998b), a mobile agent is made a blackbox for a
certain known period of time. This is achieved so that a mobile agent, its code and data
are not readable. But, after the time has elapsed, the mobile agent data has become
27
Analysis
Code obfuscation protects the agent from a platform that is masquerading because a
platform that is pretending cannot in anyway know how to read the agent code and
unauthorized access because the agent is accessible but is not meaningful to the attacker.
Agents cannot be eavesdropped either because the code is not meaningful at all. So if the
execution is spied on, the meaning would not give anything comprehendible. The agent
message copying and replaying is also protected. The agent is a blackbox to the
platform. So, its messages alone have no meaning even if they are copied and replayed.
from the sequence of execution of code. Denial of service is not solved as they platform
may block the agent. Also, repudiation is possible because no history of execution is
maintained.
Cryptographic functions have been suggested by (Sander & Tschudin, 1997a; Sander &
Tschudin, 1997b) to encrypt the code and data of the mobile agent. The platform would
then use an encryption scheme to decrypt the mobile agent and to use the mobile agent.
The approach uses a technique that encrypts both the mobile agent’s code and data.
What the technique uses is that an agent function should not describe its actual purpose.
It should be able to run on the agent platform but should not be able to understand its
working. Agent functions are thus decomposed and sent to the platform. Each function is
encrypted and sent to be executed. This is then decrypted at the platform. The result is
28
Similar to this (Ametller, Robles & Ortega-Ruiz, 2004) protects mobile agents through
encrypting their functions through a key mechanism. The agent is encrypted publicly
and then signed with its signature. However, the scheme is implemented for the JADE
platform.
Lee et al. (Karnik & Tripathi, 2000) use the same approach that (Sander & Tschudin,
1997a; Sander & Tschudin, 1997b) uses but extends their work to include a practical
implementation. They in turn come up with a new scheme for the approach in (Sander &
(Algesheimer, Cachin, Camenisch & Karjoth, 2001) includes the agents that can use its
results during its journey. Thus, its data is not limited to just the originator host. This
approach adds a special service, the secure computation service that does not leak the
encrypted function information to the platform safeguarding the agent but still provides
In (Novak, Rollo, Hodik & Vlcek, 2003), session keys are used to protect the agents that
are executed. The agent can only be accessed with it session key while it is in
communication with the platform. The session key becomes invalid after a session. To
gain access, another session has to be built with the agent and a session key needs to be
to hide the mobile agent execution. The RDS scheme also relies on fault-tolerance as it
sends agent replicas to execute at the platform. A platform requires the appropriate key
to transact with the mobile agent hence protecting the agent from any malicious
execution.
29
(Ferreira & Ricardo, 2002) uses a scheme to protect keys being carried inside an agent.
The scheme is used to blind the key being carried by the agent. This means that the
private key is factored to give a particular blinded key, the factor is only known to the
host. Then, this blinded key is used to create a signature. To use the key, the factor has
to be known. Thus, this scheme can be used to protect very critical and confidential data
in the agent.
Another technique is presented in (Tate & Xu, 2003) which overcome the limitations of
approaches in (Lee, Alves-Foss, Harrison, 2004; Sander & Tschudin, 1997a; Sander &
Tschudin, 1997b; Algesheimer, Cachin, Camenisch & Karjoth, 2001). The approach
uses multi-agent cryptography. In this, instead of relying on a special service, the host
itself deals with the encryption and decryption. Also, it incorporates the dealing with
untrusted platforms since the approach defines a threshold value. This value determines
(Marques, Santos, Silva & Silva, 2001) also incorporates the use of cryptography in its
M&M framework. This allows an agent to create cryptographic protocols for secure
Tanenbaum, 2002) also uses cryptography to protect its data. (Vuong & Fu, 2001)
incorporates the hiding of its data behind an encryption scheme as well. (Fu, 1999)
extends the work in (Vuong & Fu, 2001) to give an implementation in Wave. It gives the
details of the implementation of the cryptographic system. It also makes the agent read-
30
Analysis
platforms. This is because a platform with a key is authenticated before it can decrypt an
agent. A masquerading platform cannot have a key. A platform cannot access an agent it
cannot decrypt. To make this a stronger, an agent may carry a key that may be used to
decrypt it, like in the blinded key approach. Thus the agent containing encrypted
functions is not harmed by unauthorized access or by spying out of the code nor can the
encrypted agent be altered since without the key, the functions are not readable. An
agent message cannot be copied either if the key relies on session keys that become
Denial of service attacks cannot be prevented as an agent that may be decrypted may
still be blocked out from the platform’s resources. An agent is not logged and no history
Execution tracing also called encrypted traces (Vigna, 1998; Moore, 1998; Vigna, 1997)
for mobile agents have also been suggested which involves the encryption of the
execution log of mobile agents executing on platforms. This log is a history of the
execution on a platform. The log is then hashed by the platform and signed with its
signature. The platform keeps the original trace of the agent. The agent execution trace
may contain certain suspicious results that can be used to find a malicious host. Also, the
host can ask for the traces from the various platforms for comparison. This can thus
31
(Leung & Ng, 2004) extends the tracing approach by Vigna in (Vigna, 1998; Vigna,
1997) in to detect the malicious hosts from the traces that the mobile agents generate.
For this, a protocol is suggested that uses the threats to locate a malicious agent platform
Another approach here is to use Cubaleska et al. approach (Dadon-Elichai, 2004) for
determining whether an agent platform in the mobile agent’s journey was malicious. For
this, the agent platforms are queried by the host upon arrival of the agent. Each platform
is queried for their identity and for the identity of the next platform. A malicious
platform will give a wrong response or will not be able to give any response at all. Thus,
Another approach is by Hohl in (Hohl, 1999) that protects the mobile agents using the
concept of reference states. The agent’s execution is checked for certain reference states
that are determined by the data that the agent holds after an execution. To authenticate
the data produced by the platform, digital signatures are used. The resulting state can
mechanism. The malicious activity is traced back and execution is then recommenced
from there. Thus, it protects the malicious activity on an agent by rollback recovery, a
fault-tolerance mechanism.
Logging capabilities are apparent in the M&M framework (Marques, Santos, Silva &
Silva, 2001) to keep a trace of agent execution, of agent interaction and this is listed with
the agent identity. This maintains accountability for agent actions on the platform and
32
In (Noordende, Brazier & Tanenbaum, 2002) the MANSION framework uses an
audit/trail mechanism. This mechanism audits all changes made and where the change in
the agent occurred. (Fu, 1999) also uses logging the execution trace of the agent on the
platform.
Analysis
The approach uses a capture of an agent’s execution into a trace. This allows the
detection of a threat and not entirely the prevention of it. However, a masquerading
platform can be detected from the trace as a masquerading agent will not leave a trace
that is expected from the actual platform. However, if this check is not enabled,
masquerading is prevalent. The technique checks for unauthorized access, for any
alterations to the agent and for any copy and replay actions against the agent during
execution. It guards against repudiation because a log is maintained that keeps a track
off all execution and all interactions of the agent, the platform and other agents. DOS
However, an agent cannot be checked for eavesdropping. Spy-outs of the code or data
rely on other techniques as a trace cannot denote an outside spy of an agent execution, if
it is not being interacted with. The log relies on interaction of an agent along its
execution. If a spy is merely viewing the agents set of message calls and gathering this
Itinerary protection of mobile agents is another approach as presented by Mir and Borell
in (Mir & Borrel, 2002; Mir & Borrel, 2003). The itinerary of the mobile agent is its
33
route that also has to be made private. The work on the protection of the itinerary is by
encrypting the itinerary of the agent. There are different types of routes that an agent can
take, they can be sequenced or in alternate order as well. (Mir & Borrel, 2002; Mir &
Borrel, 2003) takes these types into consideration while applying their cryptographic
Another variation of (Mir & Borrel, 2002; Mir & Borrel, 2003) is that in (Wilhelm,
Staaman & Buttyan, 1998) which uses a similar protocol for the protection of the mobile
agent’s itinerary along with special tamper-proof hardware. The hardware is there to
enforce a policy.
Another technique is to use a cooperating agent to record the itinerary of the mobile
agent. (Roth, 1999; Roth, 2003) uses a cooperating agent that sets up a authenticated
channel with its cooperating mobile agent. This agent records the path information and
in the case of malicious behavior, the cooperating agent takes the necessary action, like
inconsistencies in the itinerary. The agents that are cooperating are the only ones that
can see each other’s itinerary with the help of the authenticated channel of
The MANSION framework (Rothermel & Schwehm, 1998) uses this scheme to keep the
agent itinerary private from the platforms it visits. This is maintained in the agent’s table
of content that details what methods an agent contains and where is has been (source
Analysis
identified is not allowed to view the encrypted itinerary. A key is required to access the
34
itinerary. Also, a cooperating agent keeps a check on the route an agent takes. DOS
attacks are also recorded if a cooperating agent is used. Also, any kind of unauthorized
access to the itinerary is not possible since the itinerary is protected by encryption. The
agent is also protected from repudiation attacks as a cooperating agent logs the
information of execution.
However, an agent is partially open to an attacker for eavesdropping. Since the attacker
cannot view the itinerary, other information may be accessible and alterable. The agent
can thus not be completely spied on, altered and copied but partially it can. Thus, such
Another approach in (Beirman & Cloete, 2002; Greenberg, Byington & Harper, 1998) to
protect the mobile agents is to use a time technique. The agent has a built in timer. If the
time passes and the agent is not provided service, it can either self-destruct or it can pass
Analysis
The approach can be used to protect from DOS, as an agent will expire in a period of
time. Access time is limited and thus unauthorized access may be prevented by the agent
expiring after a given time. Eavesdropping can also be limited because the agent is only
existent for a limited time. The agent life may be so short that it might not be possible to
The approach cannot protect an agent from any masquerade as there is no way to
authenticate the platform. also, there is no mechanism for keeping track of the agent’s
35
time spent on a platform and repudiation may occur Access can be limited by time, but
an agent may be spied on, may be altered or copied in that limited time.
To protect the platform other approaches have been mentioned in various papers. The
agent or a group of multiple agents can maliciously hinder the activity of the platform or
a group of platforms (Vigna, 2004) causing fatal consequences (Jansen, 1998b). This
First we deal with agent authentication as proposed in (Farmer, Guttman & Swarup,
1996a) by Farmer et al. The approach simply uses the digital signature scheme for the
authentication of agents. An agent has to be signed by its vendor and this allows the
running of the agent on the platform if the public key to see the signature is known.
Otherwise the agent is not to be trusted and the agent is rejected. Similarly, Berkovits et
al. (Berkovits, Guttman & Swarup, 1998) use an authentication mechanism for mobile
agents. This paper gives a detailed implementation approach to (Farmer, Guttman &
Swarup, 1996a). In this approach, the agent is assigned a certificate. The agent is
authorized according to the certificate that includes agent information such as the agent
creator, the agent sender and the actual program of the agent. The platform checks the
agent and thus authenticates itself to the agent and the agent to the platform as it
possesses a key. If it does not have this key, the agent is not authenticated and thus the
agent and the platform are unknown to each other. Upon authentication, the agent state
36
appraisal functions are executed and the agent is authorized to access the platform. The
state appraisal functions denote what privileges the agent has on the particular platform.
how the theory in (Farmer, Guttman & Swarup, 1996a) will be used in practice.
Another approach (Schelderup & Olnes, 1999) (Varadharajan, 2000) suggests that an
agent be given a passport. This is a kind of information file with the agent that describes
it. It can be used to gain information for authenticating it and to authorize resources to it.
The file thus contains necessary information like the agent name, the host address and
assigning mobile agent certificates. The certificates contain information about the agent
that is in turn used by the platform to apply a policy for the agent. The application of
policy is governed by a component on the platform called a policy engine. This policy
according to the agent certificate allocates the privileges that the mobile agent has on the
platform.
In (Novak, Rollo, Hodik & Vlcek, 2003), certificates are defined to authenticate the
agents based on mobile agent standards. The certificates are registered to a certification
authority that allows the agent to implement security. Upon reaching a platform, the
(Tan & Moreau, 2002) presents a framework for authenticating mobile agents using a
from a special verification server. The agent is then granted access or denied access
according to its certificate and the response from the verification server.
37
(Marques, Santos, Silva & Silva, 2001) uses an authentication scheme as well that
associates each agent to an identity containing the list of owners, the name of the agent,
a hash signature of the code of the agent, the agent creation and the agent expiration
time. Each agent is assigned a key so that copies cannot be made. The distribution of the
keys is done through a server. This is used to authenticate the agent on the platform.
Brazier & Tanenbaum, 2002). Each agent has a passport that contains signatures of the
agent code. The signature is checked to identify the agent according to its owner. Also,
another authentication is done for within system transfer. This uses the same mechanism
(Vuong & Fu, 2001) uses a simple scheme to authenticate agents on the bases of digital
signatures. The framework has a certification infrastructure to assign signatures and keys
to the agents. (Fu, 1999) extends the work in (Vuong & Fu, 2001) to give an
(Karnik, 1998) uses a simlar authentication scheme based on the El Gamal Crypto
system. This ensures the authentication of an agent onto a system and the authentication
Analysis
Agent authentication can prevent masquerading attacks as only permitted agents can
access the agent platform’s services and resources with real credentials. Authentication
does check the agents for their identities and allocates them to the system however they
agent may still act maliciously and try to access services and resources it is not permitted
38
to. Similarly, an agent that has been authenticated can be kept track of and repudiation
checked. However, only authenticating the agent does not mean that the agent will cause
repudiation or not.
An authenticated, yet malicious mobile agent may still cause a DOS attack on the
platform by hogging its resources and not freeing them. Similarly, an authenticated
agent may spy on or try to tamper with a platform. An authenticated agent may copy the
platform messaging and replay them as well. Hence, authenticating an agent alone will
not suffice.
signatures. The members of a group are thus anonymous and private to the
authenticating body. The authenticating platform knows the identity of the group. This
gives performance because the agents do not have to be authenticated individually and
Path histories (Jansen, 1998a; Jansen & Karygiannis, 1998) can be used by the platform
to see where the agent has been. Based on the platforms it has been to the platform sees
if it can trust the agent. Thus, if a platform the current platform does not trust has
Path histories are maintained (Beirman & Cloete, 2002; Bellavista, Corradi, Federici,
Montanari & Tibaldi, 2003) by the agent containing the platforms that it has visited on
its journey. Each host enters its name as well as the next platform’s name in the history.
With this, the agent can be checked for possible malicious platforms in its path that may
39
have corrupted the agent. This can be done in a few different ways, the agent visits the
platform and the platform checks the list for a platform it does not trust, or has referred
to as malicious. Also, the host list and the signatures can be used to check each platform
visited by the agent’s current platform. From this, if one of the platforms is detected to
(Dias, Ribeiro & Ferreira, 2003) uses a history based scheme to enforce its security
policy on an incoming mobile agent. The agent platforms implement a proxy that keeps
track of the agent execution. The proxy forwards its information to other proxies and the
platform can use this information to apply the policy for the particular agent.
Analysis
Agent platforms can be protected by using path histories mechanism that helps detect
malicious mobile agents. A mobile agent’s history can be checked to detect any
masquerading. Similarly, the agent can be checked for a history of DOS attacks on other
platforms. However, DOS attack detection in the history is complex as a series of other
information would be required as well, like the number of waiting agents for the same
resource and the total amount of time the process required the resource and how long the
agent kept it and so on. This scheme also prevents unauthorized access as the path
history can be used to set a policy for what the agent is allowed to access and what it is
not allowed to access. Since a history is maintained, the agent cannot cause repudiation
attacks.
This technique does not however prevent the agent from spying on the agent platform as
it is not detected. The agent may still be corrupting the platform and may also use the
40
4.3.3 State Appraisal
(Farmer, Guttman & Swarup, 1996a) also gives the concept of state appraisal. The state
is checked to see if the agent has been tampered with. The state is checked by the
platform and access given to the agent based on the state. The states that the agent can
hold are pre-defined by the platform. If the state is out of these defined states, the agent
platform. To accomplish this, each agent is assigned state appraisal methods. These are
executed by the platform the agent has arrived on. According to the results of the state
appraisal methods, the agent is allocated a set of privileges. This is detected by the states
that an agent can be in and what privileges it may require. Thus, the use of state
Guttman & Swarup, 1996a) has been enhanced in (Berkovits, Guttman & Swarup, 1998)
which uses state appraisal for migrating agents’ authentication and authorization on an
agent platform.
Analysis
functions can be used to check an agent’s identity. DOS attacks can be prevented
because the state check is used to allocate resources to the agent. Similarly, access levels
can be set based on policy. Repudiation is avoided but not completely as an agent state is
On the other hand, eavesdropping alteration and copy and reply cannot be tracked by the
agent’s state values. The agent functionality has to be checked for that.
41
4.3.4 Resource Protection
Similarly it is vital for MAS as well. Tripathi and Karnik in (Tripathi & Karnik, 1998)
provide a scheme for the protection of the resource through proxies. The agent based on
its authentication information or its credentials are given the authority and access level
to the resource through the proxy. Similar to this approach is to use a wrapper which is a
general implementation of the accessor object for categorized agents. The proxy is thus
dynamically constructed and the wrapper is static constructed by the resource provider
beforehand. Another approach that can be used is to use state appraisal to determine
Karnik in his dissertation (Karnik, 1998) uses the same technique for resource
Another approach by Jansen uses policy certificates in (Jansen, 2001). This contains
information about the agent that a policy engine on the platform uses to determine what
privileges to assign the agent. The privileges are determined by the information about
the underlying algorithm that the agent uses for use of the platform and its resources.
(Villazon & Binder, 2001) describes the resource access by a mobile agent through
reification of the mobile agent itself. The mobile agent code is transformed into a meta-
agent. This meta-agent structure requires the access and modification of the mobile
agent’s actual code. The agent is thus reified and the new meta-agent accesses the
(Nicola, Nicola & Pugliese, 1997) uses a rather dynamic approach to violation of access
rights. The paper defines a type system for mobile agent’s access to resources. The agent
access (read, write) is checked via a blackboard. The blackboard contains the agent
42
actual intention, its permission granted by the platform and the agent’s current type of
access.
Analysis
The resource protection techniques are there to protect an agent platform from an agent
that may cause DOS attacks. A resource that may be overloaded by an agent can
terminate the agent calls and free the resource. Similarly, the platform resources are
protected by a policy in the form of a proxy or a wrapper. Also, certain mechanisms may
use a resource logging facility to keep track of agent to resource interactions. This may
that may be spying is prevented as any agent spying is not possible since sensitive
information is kept private to the agent, in other words, it is inaccessible. All the
platform’s resources and services cannot be corrupted by the agent as they are protected
and the platform calls and any attempts to reply messages are prevented.
Agents are not checked for identity in all schemes for resource protection. Thus another
technique for authentication has to be incorporated with the resource protection and
authorization.
Other schemes listed by Jansen in (Jansen, 1998a; Jansen & Karygiannis, 1998) to
protect the platform from the agents are to use fault isolation or to sandbox the execution
of the mobile agent. This means that the agent can only execute in a limited virtual area
on the platform. It cannot access anything outside this sandbox unless it is permitted by
43
the platform. This protects the platform entirely from any malicious activity from the
agent. Thus, the instructions are checked whether they are within the address allocated
or not (Moore, 1998). If they are not an exception can be reported or the address can be
In (Noordende, Brazier & Tanenbaum, 2002) the MANSION framework uses a similar
approach to allow secure execution. The agent is binded with a sandbox and a monitor
checks all interactions that the agent carries out with the platform.
Analysis
Fault isolation prevents a masquerading mobile agent from harming the platform
cannot cause DOS attacks because it has restricted access to resources. An agent is
prevented from unauthorized access because it is kept in a sandbox with only its
accessible entities; the inaccessible entities are outside the sandbox. An agent cannot
eavesdrop but it can spy on whatever is going on within the sandbox. An agent can alter
what it has access to unless the sandbox limits the agent from such activities. Agents can
copy message exchanges that occur and replay them but since this is in a limited area
this does not cause much of a threat to the platform. Since there is no mechanism for
keeping track of the interaction that goes on, the platform is threatened by agent
repudiation attacks.
For protected execution of mobile agents, (Karnik, 1998) uses protection domains.
These domains are created for the agent when the agent arrives. This uses a classloader
that protects the agent from maliciously interacting with the platform. Each agent is
44
4.3.6 Safe Interpretation and Padded Cells
Also, stated in (Moore, 1998), safe interpreters like in Safe-Tcl (Ousterhout, Levy &
Welch, 1996) can be used. Here the padded cell concept is given to execute instructions
inside a safe interpreter and block out the unsafe instructions. The master interpreter
either gives it pseudo-instructions to complete the process instead of the real instruction
(that is not safe) or it gives the actual instruction as suggested by the requirement of the
platform. Java has a similar means of safe code interpretation since it provides a type
Analysis
An agent that attacks a platform through a DOS can be prevented by checking it with a
padded cell. A platform can contain any sort of unauthorized access to resources since
the padded cell would close such commands from the agent. Agents in a padded cell
cannot eavesdrop or alter a system because such commands are prevented. Agents can
copy message calls and replay them, but these are the few calls that are visible in the
whether the agent is real or just pretending. DOS attacks may still prevail because the
padded cell instructions can be exercised over and over again. The instructions
accessible in the padded cell are safe but they may thus be made dangerous by redundant
messaging. Mobile agents still cause repudiation because the padded cell has no track of
the execution.
45
4.3.7 Proof Carrying Codes
Proof carrying code (Jansen, 1998a) (Jansen & Karygiannis, 1998; Bellavista, Corradi,
Federici, Montanari & Tibaldi, 2003; Tschudin, 1999) techniques can also be used by
various agent platforms. The agent code can be used to carry its signature, in the form of
a proof. For example, the code can be algorithmically used to provide a number. This
number would change if the code of the agent has been tampered with. Since this
number is known to the platform beforehand, it can reject the agent and avoid any
(Esparza, Soriano, Munoz & Forne, 2004) suggests the use of a digital watermark that is
added within the code. In the case of a change in the code, the watermark becomes
faulty and scrambled. In this case, the attack can be detected by the platform that knows
how to read the watermark. The watermark can be a value or a sequence and so on.
Analysis
Mobile agents protected by PCC can be checked for masquerading because an agent that
contains a proof can be checked with its originator. An agent can also be checked for the
proof and be allowed access on the platform accordingly. An agent that has been
tampered with has a scrambled proof and is denied access or rejected completely.
An agent cannot be stopped from causing DOS or by spying on the platform, altering it
or causing copy and replay as the agent is still threatening. Repudiation still occurs
46
4.3.8 Payment-based Techniques
Also, for protection of the platform and its resources, various works propose money
based techniques (Kun, Xin & Dayou, 1999; Gray, 1997) for mobile agent systems. An
agent arriving and acquiring an agent platform’s service has to use a cryptographic sum
of money. The agent use is based on how much it is willing to spend. The money is thus
The MANSION framework (Noordende, Brazier & Tanenbaum, 2002) uses a form of
this technique containing e-cash that is used to pay and acquire services.
Analysis
Payment-based techniques may help prevent masquerading because they only permit the
agents that have money to pay for the platform’s services. However, a masquerading
agent may have money and may be pretending to be another and thus the threat is
limited but not completely eradicated. DOS is prevented because an agent cannot hog a
resource. The money that an agent has is finite making the access of the resource limited
by that amount. Unauthorized access is also prevented since an agent can only pay for
the services that the platform allows. Otherwise, the platform does not put the service up
for access. Agents can avoid repudiation to some extent by the transaction and the
money exchange involved but this would require an account tracker to check when
required. An agent access can be payment based too making the access limited and
denying changes and copying. However, the agent may pay for full access and use this
47
4.4 Network Protection
Various techniques are available to protect the network that the entire MAS is built
upon. This is necessary because an attacker may tamper with the network and may
capture a mobile agent in transit. Also, a platform may be hampered with by an attacker
from the outside through intrusion attacks. Solutions exist to protect the MAS through
both hardware and software approaches (Li, Zhang, Sun & Yin, 2004).
Voung and Fu (Vuong & Fu, 2001) provide practical implementations of MAS using
SSL (Secure Sockets Layer) to create a protected channel for the communication
between the host and the platform. The SSL provides a secure layer for transmission of
(Jihong, Jianping & Kai, 2000) uses SSL very strongly in its design of a secure MAS.
Here, it is used similar to (Vuong & Fu, 2001) to set up a secure channel for transmitting
agents.
Similar to building a secure socket a continuous stream can be sent out so that only the
intended receiver knows which bits are meaningful (Tschudin, 1999). The M&M
framework (Marques, Santos, Silva & Silva, 2001) also incorporates SSL sockets for
agent migration.
Analysis
Mobile agent systems can be protected through secure sockets preventing any
masquerading of an agent and a platform since a secure channel can only be setup
48
between known servers that send known agents. Since a channel is secure from end to
end, an outsider cannot eavesdrop on the conversation. Similarly, alteration and copy
DOS attacks cannot be prevented because the secure sockets are to secure transmission
not limit them. Repudiation is not prevented either as there is no logging. Alteration and
copy and replay attacks can occur if the secure socket is between untrusted nodes.
4.4.2 Firewalling
(Rubin & Geer, 1998; Feng, Shan & Ying, 2003) describe the use of firewalls for the
protection of a MAS. Incoming requests to the MAS are checked one by one. Any
attempts to hurt the system are blocked. This approach is not possible in all scenarios.
So, a proxy is built with a firewall. The requests are sent to the proxy. The proxy
acquires the necessary information and responds with the safe version of the request.
Analysis
Firewalls check for masqueraded messages from the outside. They also prevent any kind
of eavesdropping from the outside as well. Access that is not authorized can be detected
but if not specified in the proxy, it may still be accessible. Repudiation can be checked
as a request log is maintained. However, the incoming attacker may change identity and
cause repudiation.
Firewalls cannot prevent DOS or copy and replay as a request that has been permitted
49
4.4.3 Tamper-Resistant Hardware
(Beirman & Cloete, 2002) suggests the use of tamper-resistant hardware and detection
objects to protect the MAS from outside network security threats. The hardware is made
such that it cannot be physically tampered to allow access and also virtual tampering is
blocked. For this, firstly the hardware is enclosed in protective encapsulation (switches
in locked cabinets) and secondly, detection objects are placed to detect if the physical
Analysis
Masquerading is prevented by the detection objects that check the source and sink of the
incoming agent. Access is controlled by the detection objects and the tamper-resistant
hardware because the resistant hardware prevents any illegal entry and the detection
entry point for an attacker. Similarly, alteration attacks can be prevented from the
outside.
DOS and copy reply cannot be prevented as there is no way to detect these by the
tamper-resistant hardware and the detection objects. Alteration may still occur from
4.5 Evaluation
The protection countermeasures are evaluated according to the threat model (Orso,
Harrold & Vigna, 2000) (Saeb, Hamza & Solimon, 2000). We analyzed each approach
50
and find the potential weaknesses of each approach according to the threat model and
For this we make two tables. The first table (Table 4.1) evaluates which threat to the
mobile agent is counter measured. The second table (Table 4.2) is for the evaluation of
the countermeasures to protect the platform, checked to describe which threat to the
platform they countermeasure and the third (table 4.3) describes the countermeasures to
51
Table 4.2: Protection of the Agent Platform
52
Chapter 5
This chapter gives a state of the art describing various Mobile Agent Systems that have
been implemented and it details their security along with an evaluation of them
The research of mobile agents is growing immensely in directions of its use for
agent system (MAS). There are various MAS that encompass the use of mobile agents
for both research, experimentation and for commercial use as well. Numerous mobile
agent systems have arisen for these purposes. Their differences lay in their features and
their support for mobile agent types depending on what kind of languages they support
(Gray, Kotz, Cybenko & Rus, 2000), whether they support weak or strong mobility
(Gray, Kotz, Cybenko & Rus, 2000) and also up to what extent their threading is (Gray,
53
Kotz, Cybenko & Rus, 2000). Since we are discussing each MAS in the light of security
we shall take into account the security mechanisms that each MAS has for the mobile
agents and the agent platforms that are a part of the MAS. Obviously, the security is
Security is dealt with in different regards in MAS. The techniques can be preventing
different kinds of attacks and threats to a MAS whether for the mobile agent or for the
agent platform. The MAS deal with these directly or on the basis of the mobile agent
code itself. This means that in some MAS, security is a built in feature while in some, it
is a provision placed as a feature of the implementation of the system using the MAS.
Different approaches are used to secure systems as well as to enhance application of the
MAS. Thus, the security in each system differs and the extent of security provisions by
the MAS varies. The MAS taken into consideration in this paper are based on their
5.2 Telescript
Telescript was developed by General Magic Inc. and it was the first ever MAS
developed for industrial market use (Gray, Kotz, Cybenko & Rus, 2000). The Telescript
MAS comprises of the Telescript object-oriented language for writing mobile agents,
which is interpreted (Gray, Kotz, Cybenko & Rus, 2000). The Telescript language
contains classes allowing multiple inheritance (Tardo & Valente, 1996). The language is
like Java and C++. Telescript is considered one of the most efficient, secure and fault-
54
Due to the success march of Java, Telescript was outdated and it is now obsolete but, its
concept and architecture provide idea and foundation of many other MAS that came
after it.
The Telescript architecture (Figure 5.1) runs agents in divisions called places. Places are
dived based on the service they provide for the agent to fulfill its function. Like a place
might represent database access, the meeting places for agents or even directory access.
Each server may thus contain several places that allow communication of the mobile
agents in one place and in different places. The agent completes its functionality on the
platform by migrating from place to place (Gray, Kotz, Cybenko & Rus, 2000). The
agent can meet within a place by passing a reference of the agent’s object and can
invoke its methods accordingly. Also, the agent can communicate with an object of an
agent in a different place through a process called connection. In this an agent creates a
communication channel and sends each other’s objects on this. The agent migrates from
place to place using the go method in each agent’s process. The agent’s code, data and
thread state are captured. The execution commences immediately after the go
The agent enters a place according to an authentication mechanism. The agent contains a
permit which is the agent’s cryptographic credentials. These credentials are based on
what kind of usage the agent does on the platform like the amount of disk space it will
be using or the lifetime the agent might have. If the agent violates any of this, the agent
55
As shown in Figure 5.1, the mobile agent accesses a server from the WAN and accesses
the Telescript engine. This Telescript engine allows the agent to run. The Telescript
engine is embedded onto the server and its operating system through the Telescript API.
Each server contains a virtual machine (like Java) (Gray, Kotz, Cybenko & Rus, 2000)
that runs each agent which is a part of the Telescript engine. The agent is compiled into
bytecode in order to be executed. The server contains a process. The process is actually a
class of the agent that extends the Process class. This means that the agent class inherits
this functions that it can run inside a place (Baumer, Breugst, Choy & Magedanz, 1999).
The places are assigned different IP addresses. So the agent locates a place through its IP
address hosted on the WAN. Then it uses the IP address to join a place. The agent then
Another thing that is shown in Figure 5.1 is a local agent. The server may be running
different stationary agents. These may represent real world concepts that the agent uses
to acquire a request to use a service or a resource. Also, it can be present on the server to
provide a collaborative functionality to the agent. For example, the stationary agent may
56
Figure 5.1: Telescript Partial Architecture (Adapted from (Baumer, Breugst, Choy &
Magedanz, 1999))
Telescript security deals with four distinct levels (Tardo & Valente, 1996). These
together form the Telescript security model. The model looks at different levels to
provide safety and security to the MAS and it depends on the programmer of the
Telescript MAS on what degree of each level of security to be provided. The levels are:
Telescript accesses objects through interfaces and only references to those objects
(Tardo & Valente, 1996). It does not provide pointers meaning that the Telescript MAS
consists of both dynamic variables and exception handling along with garbage
collection.
Like Java, it enforces the implementation of operations and attributes in the form of a
class. This means that it enforces encapsulation of our objects. The methods and
attributes are either publicly or privately accessible to the class itself or its sub-classes
57
(Tardo & Valente, 1996). Similarly, once a class is loaded into the Telescript engine, it
cannot be updated or reinstalled or replaced by another class of the same name. This is
all made possible by the fact that the engine’s interpreter acts as a monitor for access to
Telescript deals with the security and safety of interacting agents thus protecting the
agents from other agents as well as from the places they are running in. The Telescript
• Authenticated Authorities
Each place and agent is assigned a unique identifier. The Telescript engine contains
these different types of authorities for the places and the agent. Now according to this
Thus, Telescript allows the control of trust levels while running the agent.
• Protected References
Telescript provides the essence of ownership. This is to protect the referencing of the
object making it read-only access. This is done by making the class protected which is
58
• Permits
To limit the use of resources and controlling execution of the code is done through
permits. The permits are special objects that denote the life of a process, its memory
requirements and its priority or it can allow the mobility of an agent or whether or not it
The agent destination place has full authority of whether or not it will let the agent enter.
The Telescript engine is responsible for providing the agent’s credential information
(authority, class and permit). Here the place according to the agent’s credentials, allows
the agent and applies its own permit on the agent. If the agent is not allowed, an
exception is given to the agent and the agent is not entertained on the place.
For new agents, where the authority is newer than the regular agents running, a special
safe and restricted environment is provided called a purgatory. This place may be used
59
as docking areas for the agents to check if they are allowed or not, if they are not, they
• Security Mix-ins
These are special classes that cannot be instantiated but can be inherited. If an agent tries
System Safety
The system is treated as a separate layer in Telescript. The engine provides system
visibility but access to resources like files, databases and network ports are through
system objects (Tardo & Valente, 1996). These objects are mix-in copyrighted for
safety. An agent can thus not use any of the system management and control functions.
For instance if an agent is to install a virus, it cannot. The configuration options are left
to the system management functions in the engine (Tardo & Valente, 1996).
Network Security
Telescript networks comprise of interconnected engines that contain many places. These
places together make regions. The agents travel from and to these regions over secure
Region policies can be configured for each region in Telescript. Similarly, when an
agent enters a region, it enters the outermost region called the engine place. Here it is
decided to let the agent continue or not and also to enforce the policy on it, via the
60
permit, if it is allowed to continue. Also, the places an agent can and cannot visit are
highlighted.
for the regions to be authenticated. Upon reception of an agent, the place is handed over
the agent’s authority, the region’s (where the agent is coming from) authority and the
security services of the channel. These security services are pre-determined and have to
be negotiated when a channel is setup and are called security regimes (Tardo & Valente,
1996). There are five types of security regimes supported by Telescript (Tardo &
Valente, 1996):
Registration: RSA is used for authentication and Diffie-Hellman and the encryption
scheme used is the RC4. Here registration agents enter and visit only a few places that
are authorized to them. These agents register the region with the region they are visiting
Fast Authentication: this uses the DES to authenticate and to transfer information
between the regions. The key exchange is through the RC4 computation. Obviously, this
Re-Key: This is used when the key has been lost or a key expires in DES otherwise it is
61
Authentication: This is similar to fast authentication but it shares an RC4 key using
Telescript though sound in terms of safety and security it still has its weaknesses and
1) Safety is not provided by the Telescript model, it is provided by the Telescript way of
programming. This means that the programmer has to make sure that the safety rules are
being followed.
2) Trusted operations have to be used for object sharing. The scenarios that the
3) The engine doesn’t completely enforce the access control policies, like for resources
4) The Crypto system used in Telescript is breakable since it uses a small number of bits.
5) Encapsulation of the agent is present but this is for the agent generally, no complete
scheme for result encapsulation is present. Hence, a partial result encapsulation exists.
6) Contains a safe area for execution like a sandbox, but it is not a special area in
isolation, there is a check on the commands of the agent, which makes it like a padded
cell.
62
5.3 AgentTcl and D’Agents
Agent Tcl was the first implementation of D’Agents MAS and supported a single agent
scripting language, Tcl and used the Safe Tcl extension (Gray, 1996). The Agent Tcl
MAS was developed by Dartmouth College with the intention to replace other MAS due
to their weaknesses, especially in security and language support. Agent Tcl was under
development while its architecture claimed to support the Tcl language only, but
provided a mechanism to support agents of other languages as well. Its main intention in
terms of security was to remove the overhead of the programmer to explicitly add in the
D’Agents replaced the Agent Tcl as its evolved version because it incorporated multiple
languages like Java, Tcl and Scheme. Also, the D’Agents MAS was the first commercial
release for use in applications since the Agent Tcl was for experimental and internal use.
The name change was due to the fact that D’Agents incorporated more languages than
just Tcl.
The D’Agents architecture is an extension of the architecture that was initially for Agent
Tcl (Gray, Cybenko, Kotz & Rus, 2001). In Figure 5.2, we see the D’Agents
architecture. It shows agents that can be implemented in multiple languages. Agent Tcl
was initially just for Tcl, but now the D’ Agents architecture includes Java and Scheme
as well. Each of the languages provides four components for the agents, an interpreter
for the agent, the state capture facility so that the state of the agent can be saved in
motion, as shown in Figure 5.3. The security component is a part of the interpreter that
63
checks each action by the agent and stops any malicious actions taken. The server API
allows interaction of the language interpreter with the server for its communication
services, its check pointing facilities to store agent states in case of failure, for the
migration facilities for the mobile agents and also for the status management and status
Figure 5.2: D’Agents Architecture (Gray, Cybenko, Kotz & Rus, 2001)
In operation, each agent that arrives on the D’Agents server will be sent to its
corresponding interpreter, for example, a Java agent will be sent to the Java interpreter
for processing (Gray, Cybenko, Kotz & Rus, 2001). The interpreter forms an interface
with the server/ engine. The agent security is maintained by the interpreters themselves
and all access to them is made based upon the restriction and allowances by the resource
managers.
64
Figure 5.3: Agent Tcl (Magnified) (Adapted from (Gray, 1996))
language based agents. In Agent Tcl, the security was limited to techniques for secure
authentication of mobile agents and authorization of the agents to the resources on the
agent platform (Gray, 1996). The current D’Agents security protects the agent and the
agent platform by providing more security techniques as extensions to the Agent Tcl
security approach.
The D’Agents security is divided in four parts, the protection of the machine, the
protection of the agent, the protection of other agents running on the machine and the
protection of a group of network machines (Gray, Kotz, Cybenko & Rus, 1998).
When a mobile agent migrates from a hot machine to other machines, it undergoes
authentication and authorization (Gray, Kotz, Cybenko & Rus, 1998). The agent can be
of two types, an owned agent and an anonymous agent. An owned agent is one that has a
digital signature that can be verified and adversely an anonymous agent is one that can
65
not be verified. An agent can be authenticated if its owner is known or its sending
machine is known. Meaning that if its sending machine is known and that the sending
machine also authenticated it then its owner must be known making security a transitive
concern.
The approach to authenticate the agent is simple (Gray, Kotz, Cybenko & Rus, 1998). It
uses the PGP (Pretty Good Privacy) approach. The agent upon reaching a platform is
checked for its digital signature. The digital signature is registered by its spawning host
with its owner private key. The signature is then encrypted using the public key of the
destination platform. Here the agent is then authenticated providing two scenarios. First
that the agent is owned and the platform may or may not allow it and similarly the agent
is anonymous and the agent may allow it with highly restricted access or may
After the agent executes, its state is stored and it is encrypted using the owner private
key and then encrypted using the public key of the next platform in the itinerary and
then sent.
Authorization is then performed for the authenticate agents. D’Agents allows access to
its resources through resource managers. The agent requests are then sent to these
resource managers. The request is then allowed or denied by the manager accordingly.
configuration file with owner and right pairs (Gray, Kotz, Cybenko & Rus, 1998). This
list is loaded upon request and the owner and its corresponding right is checked and
allocated accordingly. Similarly, the anonymous agents are given very little access like
66
Similarly there are enforcement modules for each language according to the code
implementation of the agent. The enforcement modules regulate and manage common
requests to and the resource managers and the agent. One provision is to maintain a list
or a cache to see what grant was provided to the owner in the current execution history
of the agent. The cache is emptied of course when there is a policy change. Another
provision is the request lists. Here predictability is used instead of checking each
command at run time. An agent issues a request log to the resource manager. The
enforcement module checks with the resource manager the denial or the allocation of the
request and returns a list to what request is allowed and what is denied. Also, an agent
can restrict itself, based on its requirements, the platform or its surrounding
environment.
There are then the specialized enforcement modules of the languages. Agent Tcl uses the
Safe Tcl architecture that involves the use of two interpreters, the safe interpreter and the
master interpreter. The agent executes in the safe interpreter. All requests are sent to the
master interpreter and they are then performed. In the case of unsafe instructions, the
safe interpreter denies the instruction from running and instead provides secure links in
replacement. Java uses the security manager class that does all its access control in
D’Agents (Gray, Cybenko, Kotz & Rus, 2001). The command is checked by the class
Then, Scheme uses modules that can be public or exported. The exported functions are
available on loading of the module. For security, the denial to export harmful functions
can be restricted. Thus the Scheme enforcement module basically exports a set of safe
functions.
67
Protecting a group of machines
Protection of a group of machines involves the agent not causing a denial of service
attack on the network of machines by spawning to many children for instance or using
up resources that other agents might require or routing over the network forever and
1) Single administration
2) No single administration
by the owner. In D’Agents, this is the usage vector. This vector holds the maximum
resource allowance and is reduced if it exceeds the permitted resource usage. This is
digitally singed as it moves from machine to machine so that any tampering of the usage
In the other case, where there is no single administration, the list itself can be tampered
with upon reaching a machine. Here the D’Agents model (Gray, Kotz, Cybenko & Rus,
1998) has not implemented but has suggested the use of currency. Each agent has a
specific finite currency that is used to gain access. This currency is cryptographically
maintained.
D’Agents research is looking into various possibilities of protecting the agent that do not
require tamper resistant hardware. The two broad categories of possible malicious
activities defined are, malicious machine spies on the agent, tampers with it but lets it
take its normal course of motion. Or the second type of threat where the agent platform
68
However, the D’Agents (Gray, Kotz, Cybenko & Rus, 1998) has not yet dealt with these
because of two reasons. The first being that the protection is possible by using a
combination of these approaches and the second is that all of the techniques for
protection will hinder performance. Simply, the D’Agents Security system looks like
Figure 5.4.
components and algorithms, path histories, execution traces and state appraisal (Gray,
D’Agents uses a discretionary approach to its security meaning that it uses an access list
69
approach where its execution is traced at run-time for malicious activity or also an
immunology approach where an agent’s current execution is matched with its proposed
2) Protection of groups is for single administration and not the general case.
3) Multi-hop problem, where the host has to send an agent to perform one thing and then
another to perform a next to avoid becoming anonymous. It thus cannot send a single
5) The platforms have to know the keys publicly available. This restricts the amount of
owners that can be available i.e. any signed agent that cannot be authenticated is
anonymous.
6) No protection of the message passing between an agent and the platform or the agent
to agent.
7) It maintains a track of the next and current platforms but it removes the rest of the
itinerary.
70
5.4 Ara
The Ara (Agents for Remote Action) MAS (Peine & Stolpmann, 1997), was developed
language agents in Tcl, Java and C/C++ (interpreted bytecode called MACE). It is being
updated to include more languages like Pascal and Lisp. It covers the concern of agent
mobility such that its execution is not effected by the migration of the agent from
platform to platform. Also, the platform has kept a fair amount of fault-tolerance and
includes checkpoints to save the agent internal state any time during execution. It has
kept its implementation based on performance rather than ease of programming of the
agents.
In Are, the MAS is based upon the concepts of its system core and interpreters, their
communication, mobility (Peine & Stolpmann, 1997). The provision of the system core
and interpreters is to allow multiple language agents to run on the platform. Also, the
communication and mobility is for the agents to be able to migrate (as well as stationary
agents) and to form a multi-agent system that provides the ability for the agents to
interact and communicate to perform a task on the platform they are sent to execute on
The interpreters are present in the Ara MAS for each language that it provides (Peine &
Stolpmann, 1997). Here, the interpreter provides the agents with their language specific
functionality issues of the agent platform to the agent. The system core, handles the
language independent functionality issues of the agent platform to the agent. This
71
separation is so that various language interpreters can be added. The Ara core remains
Then, Ara provides the communication and mobility privileges that makes the general
operation of Ara possible (Peine & Stolpmann, 1997). The agents move from platform to
platform as well as remaining stationary on a platform. For these mobile agents, Ara
provides mobility and state capture facilities. Mobility features that Ara provides include
the migration of an agent from one platform to the other and resume its execution there
from where it left off. The agent is created and sent to and agent platform. The agent
executes and has certain intermediate results. The agent stores its state and commences
its execution from there on the next platform. The other state that includes its association
Another Ara feature is its communication feature (Peine & Stolpmann, 1997). This
with one another. This requires the agents to communicate with each other. For this Ara
Ara also provides fault tolerance features to the agents as well. Here an agent can
checkpoint its state before a specific task. If the task causes an accident, the agent can
roll back to this checkpointed state. This checkpoint is stored in a persistent storage.
This is especially used before an agent migrates from one platform to another since there
are chances of fault and failure in transmission, like line breaks and server crashes.
72
Figure 5.5: Ara Platform Architecture
In Ara, the security levels defined are in terms of agent authentication and the right
usage on the platform. Entry of the agent on the platform is of three levels, these are the
platform itself, the region to which it is going to be accessing and then the place. The
platform entry is server level, the region is group level and the place is service level
entry.
Authentication
The agent is given a passport that contains the host information from where the agent is
AgentPassport
{
GlobalUniqueID id;
String name; // optional symbolic
Tima dateOf Birth;
Allowance maxGlobalAllow;
73
// . . .
//ttl, maxSize
// . . .
Certificate userCert;
Certificate manufCert;
Signature codeSig; //by manufacturer
Siganature argSig; // by user
Signature passportSig; // by user
}
Here it is important to note that these are the values associated with the agent at the time
of creation and will not change during its life time. Then there is information that the
agent keeps that is ever-changing. This includes the agent’s host trace, or the hosts that
the agent has traversed before it came to the platform it is running on.
In Ara, the division of this information is done and the unchanging parts are signed
digitally (Peine, 1998). The agent is then checked for its owner and the agent can be
authenticated and accepted or unauthenticated and rejected. The changing parts are thus
not signed as the problem of how an untrusted host will sign is not yet solved.
Authorization
Once an agent is authorized it is then sent to a region or a group of platforms for its
platform in this region and is not re-authenticated as long as it stays in this region.
However, the agent upon entering a new region is authenticated again (Peine, 1998).
The agent is then allocated a place that contains its execution environment and the
services that it has to run. The agents are allocated a particular allowance amount that
expresses the time it stays at a particular platform and uses its resources. The allowances
are maintained in a vector, and acts as a list of various system access rights. The system
74
resources are the files, CPU time, and memory and so on. This is the local allowance
that each agent has on the system. The agent also has a global allowance associated with
it. This global allowance is the agent’s general access to the various platforms that it
Each agent has an admission function to enter the place. The agent, based on this
function is allowed or denied the access to the place. This function contains the agent
allowance, the agent passport and other security attributes (Peine, 1998).
The Ara platform has its strengths and weaknesses in regard to its security framework.
The platform covers security features like authenticating the agent on the platform
before allowing it access and then preserves the access to the platform resources as well.
1) Ara does not secure the agents from malicious platforms. The agents upon
authentication are at the platform’s disposal and may be spied on, copied and corrupted.
2) The digital signature scheme has to distribute its keys. The Ara platform has to work
in accordance to a central server for the key distribution. Currently the Ara platform
3) There is no knowledge whatsoever how the agent credentials (its passport and other
security attributes) are actually cryptographically handled. The assumption is that it uses
one of the many schemes available, but has not currently specified which one.
75
4) Checkpoints that are maintained on the platform as a backup for fault tolerance are
not secured.
5) An agent running on the Ara specification is not standard, how the MAS will contain
6) Ara encapsulates agents. But result data itself is not encapsulated by any scheme.
7) The logging is for the agent resource access and is not for the execution traces.
8) The resources are protected and controlled through a resource manager. It is not
5.5 Tacoma
Tacoma (Tromso And COrnell Moving Agents) was developed by the University of
Tromso and Cornell University and now has been undertaken by the University of
California. It supports languages like C/C++, Java, ML, Perl, Python, Scheme and Tcl/
Tk. Implementations of Tacoma have been existent for years but the literature available
on it is far less. The Tacoma project uses operating system support for its security
features (Johansen, Renesse, Schneider & 1995). Tacoma covers state storage, agent
communication, agent wrappers to structure the agent and fault tolerance. Security is
provided through means of the underlying operating system. There are provisions for
76
5.5.1 General Architecture
The Tacoma MAS supports mobility of agents and thus state capture facilities
(Johansen, Renesse, Schneider & 1995). The agent’s state is placed in a briefcase. These
briefcases contain folders that contain certain elements that denote state. Each agent
accesses one briefcase. A set of agents may contribute to form a file cabinet that can be
accessed by many agents. When an agent migrates, it stores its state in folders and places
it in its briefcase. This state is thus carried with the agent to its new destination. Some
state may have o remain behind and that is registered in the file cabinet (Johansen,
The agents communicate with one another using their respective briefcases. Agents
create meetings with one another. An agent that has to communicate with the initiating
agent must use the agent that the initiator is using. The agents pass one another their
Each agent uses a service agent to access a service on the platform for executing
(Johansen et al., 2001). These form a layer of trusted processes for the mobile agents to
acquire the system’s underlying services. Firewalls are present as well that coordinate
meetings if the agents and also message other platforms upon transfer of a mobile agent.
Wrappers are present that mediates all the agent operations and redirects them towards
its interpreter. This approach allows the integration of more agent languages into the
Versions of Tacoma had implemented payment mechanisms where the agent can access
a resource upon payment that it possesses (Johansen, Renesse, Schneider & 1995). This
involves the use of a large random number so that the cash cannot be forged. An agent
that tries to use another copied number or one that it has already used, is thus rejected
77
for service. Also, the exchange of cash in times of transaction requires an audit service
that keeps track of all the exchange taken place and the payments made from one agent
to the other (Johansen et al., 2001). Figure 5.6 shows the architecture that contains the
agents with their respective briefcases and the libraries for the agents of various
Security in Tacoma versions has grown steadily. But more of it is reliant on the
Operating system (Johansen, Renesse, Schneider & 1995; Johansen, Marzullo &
Lauvset, 1999). The Tacoma security is thus implicit and the explicit extension to
include security is still under construction. Tacoma supports the use of digital signatures.
This can be added to an agent as a program hook in its implementation. So, it has to be
Also, Tacoma (Sudmann, 1998) uses electronic cash that solves certain problems of
denial of service and also for the protection of the platform from being illegally
78
accessed. Thus, some what of the protection of the services is handled by this. However
The transfer of briefcases does make meetings secure and conversations between
interacting agents confidential. However they must go through the firewall. The firewall
acts as the point of mediation for the conversation and hence the security. Also, the
security comes with the use of a meeting type conversation. An agent talks to an agent
for service or collaboration and it cannot collaborate with other agents and others cannot
collaborate with it. This is only possible if the third agent forms a meeting with the same
agent the first agent was collaborating with. Service agents also provide security
enforcement on the platform by the incoming agents. They form a layer so that the
Another security perspective that is provided is through the use of wrappers that
encapsulate the agent (Sudmann, 1998). This wrapper forms a means for instruction
forwarding and fault isolation within the agent. The agents use the wrappers and their
implementations as policies.
Also, the agents’ replication support is a part that covers some of the agent security as
well. Here agents are replicated and provided a secret known only to the agent and its
host. The agent is also allotted a number. The agent if is copied will have the same
number and the secret. The copied agent can be rejected by the host. But the details of
Tacoma security is extremely primitive. Work is not completely focused on this regard
and thus security is only available implicitly. The general weaknesses are as follows:
79
1) Agent platforms can act maliciously with Tacoma agents.
2) Platform is protected somewhat, but the platform knows all that is going on.
4) Cash method of service allotment can be broken as copying of cash in the virtual
world is easy and thus other cash forging is easy. Cryptography can be used to verify
this cash.
6) Agents can be cloned instead of copied, and Tacoma does not in anyway protect this.
available.
8) Logging is done for the resources accessed by the agent but no resource traces are
maintained.
9) It implements certain parts of the agent to be implicit. That means these are
immutable but, there is no scheme of hiding such information, hence partial itinerary
protection is available.
80
5.6. Ajanta
The Ajanta MAS has been developed at the University of Minnesota and supports a lot
of mobile agent programming features (Tripathi, Karnik, Vora, Ahmed & Singh, 2000).
Ajanta is strictly Java based and supports mobile agents implemented in Java only. The
MAS has extensive features for development of a mobile agent application with strong
patterns and resource protection (Tripathi, Karnik, Vora, Ahmed & Singh, 1999).
Ajanta based mobile agents are very well defined (Tripathi, Karnik, Vora, Ahmed &
Singh, 2000). The Ajanta agent possesses four parts: Agent code, data, a path itinerary
and the agent credentials. The agent platform is well defined as well containing the
resources, the domain controls like the resource registry, the domain database and an
The platform in Ajanta is referred to as the agent server (Tripathi, Karnik, Vora, Ahmed
& Singh, 1999). The architecture of such a server is shown in Figure 5.7.
81
Figure 5.7: Ajanta Architecture (Tripathi, Karnik, Vora, Ahmed & Singh, 1999)
Ajanta defines a mobile agent containing code and state information (Tripathi, Karnik,
Vora, Ahmed & Singh, 1999). Along with this, the agent also has a well defined
itinerary that defines the agent’s complete path migration, meaning that it defines the
entire route of where the agent is going to move in its journey from the host. This looks
like a list with a pointer denoting at which platform the mobile agent currently resides.
The mobile agent also has its credentials that tell the creator of the agent and the mobile
agent’s intentions, in other words a description of why the agent was created in the first
place. This acts as a signed certificate to authenticate the originality of the agent.
The agent uses the agent environment that is an interface to the agent server. This
provides the agent with the service to communicate with other agents, access the
82
resources available or to migrate from itself to another server. On the agent server, there
are three underlying services. The resource registry keeps track and sets safe bindings
with the agents. This means that it is basically a log for the sharing of resources to avoid
conflict and also to avoid denial of service by blocking of resources. Then there is the
domain database that keeps track of the agents currently executing on the platform and
sends this information back to the sending platform or host of the agent. The agent
transferer provides the means and the protocol to actually transfer the agent over the
network to its next server or back home as indicated by the agent’s itinerary (Tripathi,
Resource access is through the proxies of the resources (Tripathi, Karnik, Vora, Ahmed
& Singh, 2000). These are simple object representations of the actual resource. The
agent is assigned a proxy object according to its access rights as indicated in its
credentials. The proxy contains the accessor methods to the resource and its content. For
the access, the environment provides a resource access protocol for the agents. The agent
looks up the resource according to its URN (Universal Resource Name). The proxy is
Agents can talk to one another through the resource proxies or may install proxy RMI
server for its self. The agent registers itself with the server as a service resource and
allows access for communication with other agents. Similarly, the agent may request
installation of a RMI proxy. The agent, if allowed, creates a proxy object with the local
RMI registry. Another agent looks up the agent according to its name and queries the
RMI registry through which it obtains a stub (Tripathi, Karnik, Vora, Ahmed & Singh,
2000).
83
5.6.2 Security in Ajanta
Security in the Ajanta MAS is for both the protection of the mobile agent and the server
that the agent is executing on (Karnik & Tripathi, 2000). It sets its security objectives to
protecting the server in terms of leakage of information, the protection of the agent’s
data from being spied on, the code alteration prevention, the protection of the resources
from attacks such as denial of service and protection of the names database that contains
The Ajanta server uses authenticated communication (Karnik & Tripathi, 2000). This is
based on a challenge response authentication protocol. The agent possesses a ticket that
will identify it to the server. The ticket is obtained by issuing the authenticate service
when it arrives at a server. The agent provides its name to the authenticate service and to
challenge the server for its identity, the agent provides a nonce value. The agent and the
server then exchange their authentication details within the ticket. The ticket thus
contains the agent’s signed credentials, is name and the nonce. The server signature is
then verified by the server’s nonce reply. The agent then sends its request and the
communication is established. Here the ticket is continuously checked by the server. The
server has already stored an identified agent. If the agent is not present in the table, or
suddenly the ticket contains a different value, the agent is rejected and called untrusted.
The security is provided by the agent transfer protocol. This works in three steps
between a sender and a receiver server of the mobile agent. First the request is sent by
the sender to the receiver. This request is the Agent Transfer Protocol that contains the
agent’s name and its credentials only. Based on this the receiver authenticated the
84
agent’s signed credentials and then checks if the sender is where the agent is actually
coming from all through the name service. Then, the agent may or may not allow the
agent to migrate onto the server (Karnik & Tripathi, 2000). Upon acceptance the agent is
entered into the domain database of the receiver server. The entry is marked so that its
credentials can be re-verified when the agent is received on the receiver. Then, the
sender gets an acknowledgement so that it sends the agent if the permission is granted.
The agent arrives at the receiver server and is then re-verified for its credentials. These
are then compared to the credentials that were previously obtained. This prevents stolen
credentials and the entry is unmarked so that it is in a verified state. Lastly, the location
of the agent is updated in the name service to point to the new server (the receiver) that
it has arrived on. This in turn reduces the risk of replication of the agent (Karnik &
Tripathi, 2000).
The Ajanta Security Manager is an extension of the RMI Security Manager that protects
the resources through agent access rights. It maintains an access list according to the
agents name and provides access based upon the agent’s owner. The agent is thus given
access to the resources or disallowed through the access list. An agent is not allowed to
Resources are accessed by proxies that define the resource’s security policies (Karnik &
Tripathi, 2000). This makes the access to the actual resource a private access and based
on the agent’s credentials the proxy disables methods not allowed to it. If an agent
commits an allowed method, the call is made to the resource; otherwise a security
exception is thrown. This is also made dynamic and the agent rights can be changed
85
Similarly, the resource is bound with the agent according to a resource access protocol
(Karnik & Tripathi, 2000). The protocol has the duty to create a proxy object based on
the agent credentials. This also makes an entry in the resource registry. The registry
cannot be tampered as it contains the ownership information along with the resource
name and its proxy objects name. The proxy that is made for the agent contains the
enabled and disabled methods according to the policy set for the particular agent
The server makes sure that the proxies are made by the server and not the agent, because
that may allow unauthorized access (Karnik & Tripathi, 2000). Also, the proxy is not
inherited from any other class that may allow public access to the resource; the proxy is
thus completely private. The proxy cannot be copied by agents because it is transient in
nature and thus unserializable for the agent to copy and send to another cooperating
agent for copy. The proxy object does not implement the cloneable interface in Java and
thus cannot be cloned. If it were, the agent may keep using this clone for a denial of
service attack on the resource as the server only has a reference to the original.
Agent Protection
In Ajanta, the protection of the agents is done during its transmission as well as on the
agent server. The agent transfer protocol is thus made cryptographic in nature. This
enables that the agent is not tampered with during execution. Also, a signature is added
to check for tampering after the agent has covered an untrusted path (Karnik & Tripathi,
2000).
An agent protection on the server is done by allowing the agent to have read-only parts,
to have append-only logs, to have the ability to keep certain objects of the agent visible
86
and the rest invisible to the server and also a means to protect the agent from being
Read only states in an agent are done by using a private key to sign the data (Karnik &
Tripathi, 2000). Also, the credentials are signed along with these read-only data so that
Append only logs allow only addition of certain information that is collected at the
different servers during its course of motion in the network. This is done by keeping the
log under signature of its adding server. Each server signs its addition and sends the
agent this in turn builds up to a checksum of the agent. The owner decrypts the log and
The protection of agents’ objects through visibility is also possible by encrypting the
objects (Karnik & Tripathi, 2000). If the visibility is required, the objects can be
Lastly, the agent has to be protected from copy and from masquerade (Karnik &
Tripathi, 2000). To avoid copy, only the owner can modify the agent information. The
location is kept for the agent and this location is updated with the agent’s movement.
Only the creator can update this information. Thus, if a copy is sent, two same agents
would be sent and have to be recorded, this is impossible and there is only one copy of
the agent. Then to protect masquerade or impersonation of the agent, the read-only state
that is bound to an agent would have to be replaced. Since the replacement would cause
totally different credentials with the data, the agent is invalid. Also, the change in the
course of the agent journey can be checked since the owner of the agent has an original
itinerary as well as the traveled itinerary from the agent’s entire journey. If there is a
87
Name Service Protection
It is important to protect the critical components and services of the system (Karnik &
Tripathi, 2000). This is threatened by illegal modification of the name service and the
protection of the namespaces. The updates are controlled by using an access control list
for the entries in the name registry. This access is only left to the owners of the names
for updating. Also, the namespaces for the entities are given a key that is accessible by
allowed agents. Agents are only allowed to use their own namespace. This is controlled
Security in Ajanta is reasonably strong in accordance to the protection of the agents and
the platform itself. The agents are protected from malicious activity and from corruption
by the server in Ajanta. Also, the Ajanta server, its resources and the services are
protected from misuse and malicious activity from the agents. However, its security has
a few weaknesses:
1) Ajanta provides a mechanism of spying on the agents and to replay the agent to create
their own for piracy. All the execution is watched by the environment and the security
manager. The requests made to these can be logged and used to create an agent based on
its actions.
2) The proxy generator would have to be rather intelligent to create a dynamic policy
that would also ensure that what ever it is bypassing is still secure.
3) Key distribution mechanism has not been covered in Ajanta’s architecture so far.
88
4) Sending information back to the agent owning server is necessary in cases and is not
possible always.
5.7 Aglets
The Aglets Workbench (AWB) is another Java based mobile agent system. It was
developed by IBM and contains a development environment for agents (called aglets in
AWB) and an environment for their execution (Karjoth, Lange & Oshima, 1997). The
Aglets model allows Java objects, called aglets, to visit aglet-enabled platforms on a
network. The aglets execute on one platform and then migrate to another and commence
their execution there. The Aglets MAS allows only agents written in Java. It has various
Aglets allows the creation of Java objects called aglets (Karjoth, Lange & Oshima,
1997). These aglets contain their code as well as data. The aglet runs with its own
environment which is called a context in Aglets. This context is a stationary object that
runs on the server. The purpose of this is to maintain and manage the aglets that are
executing on the platform and also to provide an interface for the aglets to the platform.
The aglets are only accessible through their proxy, which is in actuality a representation
of the aglet. The proxy gives the accessibility protection as well as transparency to the
location of the agent. As shown in Figure 5.8, the agents communicate using message
89
objects and not method invocations. The messages are thus exchanged between the
proxies of the agents. Each aglet has its own message handling method that handles the
Aglets works on an event-based scheme rather than a process migration scheme, this
means that the agent fires an event based and based on this it causes a proper event
Oshima, 1997). Then, the agent is inserted into the context where it immediately starts
execution. To migrate, the agent removes itself from its current context and inserts itself
into a destination context. This is a push and pull based scheme since the aglet is pushed
into its destination context and pull from its current context into the calling context.
90
5.7.2 Security in Aglets
In Aglets security is for the protection of the hosts from the agents, from other agents, of
the agents from the host and protection of the underlying network. Aglets ensures this
protection by providing identities, policies, mobility and also the resource access
Authentication
Aglets has a concept of principals that contains the following information (Karjoth,
• aglet’s manufacturer
• context
• context’s manufacturer
• domain’s authority
The aglet is authenticated using its name. The name is basically the class name or in
other word the product name. This is basically the identifier assigned to it by the context.
This in turn is used by the context to authenticate it and apply its policy on it. Also, the
aglet itself has to be made secure on the platform it is executing on. The preferences are
set accordingly. For instance, an aglet may not want all the platforms to view its
itinerary data. The capabilities of the aglet can also be set here, like the number of hops,
the CPU consumption and other things of this sort. The context is also assigned an
identity according to the CPU serial and the version of software and hardware. Since the
91
authorization on every context will be costly, domains can authenticate as a group. Thus
an authenticated aglet can authorize itself on the domain and utilize all contexts under
that domain.
For authentication, Aglets defines an authentication language that allows the definition
of principals and their access. Also, the language defines a means to define the
privileges of the aglet as defined by the aglet programmer (Karjoth, Lange & Oshima,
1997).
Policies
The Aglets MAS contains a policy that overrides that specified by the aglet principal
(Karjoth, Lange & Oshima, 1997). The policies set by the context are placed in a policy
database. The policy describes the mapping of the principal to the policy of the context.
Mobility
Mobility is made secure by keeping track of the aglet’s context of origin, the context it is
execution on and the destination context (Karjoth, Lange & Oshima, 1997).
Resource Access.
For the access of resources, the Aglets MAS enforces that all references being made to
the context be monitored by a reference monitor. This gives allowance to the aglet only
if it complies with the policy of the context (Karjoth, Lange & Oshima, 1997).
92
5.7.3 Comments on the Security of Aglets
Aglets has substantial security mechanisms and provides protection to the mobile agent
system up to an extent (Fischmeister, Vigna & Kemmerer, 2001). However, the Aglets
security model has its weaknesses and limitations. These are as follows:
1) Reflection can attack and reveal agent code and allow agent misuse by revealing
methods.
2) Context Manager overlooks the modifications made to a policy in the policy database
3) Aglet agent can spoof the system to obtain values from the user and sent them back to
the host.
5) An aglet’s internal state is not protected and can be tampered with and even simply
5.8 Concordia
infrastructure has support for highly mobile agent execution and also for their
93
transmission and also the issue of security. Security is based on protection of agents
from harm and the protection of the server resources from unauthorized access (Wong et
al., 1997).
The Concordia architecture contains several components that are shown in Figure 5.9.
These components are basically Java class libraries allowing execution, development
and activation for agents. Basically, the entire system resides and executes on a Java
Virtual Machine (JVM). Agents in Concordia can span local as well as wide area
networks.
Concordia agents have code and data as well as it state in mobility. Along with this, the
agent has an itinerary of its path in the network. it uses a destination URL and a method
value table in its itinerary to tell where the agent has to go to complete a particular task.
Concordia.
94
Figure 5.9: Concordia System Architecture (Wong et al., 1997)
The Concordia Conduit server acts as a server through which the agents are transferred.
This means that this server calls the destination host for an agent to transfer (Wong et
al., 1997). The server contacts the Conduit server of the destination platform and thus
forms a receiver as well. All agents that arrive at a Concordia platform meet the Conduit
server for propagation. The server implicitly has the service of locating the destination
as well for agents to propagate. Conduit servers also allow queuing of the agents to
facilitate the underlying network between a server and an agent destination server.
asynchronous events are scheduled by the Event manager. However, for collaboration,
the agent code must contain the issuance of an agent group that allows group formation
of agents belonging to the same group. For events, each agent registers with the Event
95
manager to receive events from a particular agent. The agent also gives its location and
this is continually updated so that the agent can keep on receiving events. These
registrations are kept in the Persistent Store manager. The Event manager uses a proxy
component allows the storage of internal state of the agents for agent persistence and
recovery. This can be used in case of failures as well (Wong et al., 1997).
The Queue manager facilitates the queuing facility of the Conduit server. This is for both
the inbound and outbound queues on the server (Wong et al., 1997). The queuing
manager is responsible of contacting the remote Conduit servers and the remote Queuing
For the security, Concordia has the Security manager and the Administration manager.
The Concordia security model protects from agents harming the server resources
through unauthorized access and agents to be tampered with by the server or other
Agent Protection
The agents are protected while they are on systems as well as when they are in
transmission and also in the persistence storage through encryption. For this the SSL is
Also, a function of the Administration Manager is to check the agents on the network to
see if they have reached their destination along with keeping a log of this with itself.
96
Resource Protection
To protect the resources, the Concordia Security manager operates. Each agent has its
identity that is used for access to the resources. The access is adjusted by the manager
and shuts down the servers that are in the MAS and is also responsible for the changes in
the security profile of the agents and the server that they are running on. It sends
requests on the behalf of the agents and the servers to the Security manager (Wong et al.,
1997).
Despite the efforts in the security of Concordia, the security has its weaknesses. The
system supports a set of features yet, the question of security in MAS is limiting. The
not assured.
3) Queue manager may be corrupt and may make the agent suffer from DOS attack.
97
5.9 Grasshopper
The Grasshopper platform is another Java-based MAS but it is based on both the OMG
MASIF and the FIPA standards for mobile agent systems. Grasshopper was developed
compliant with mobile agent and intelligent agent development standards that are
existent in the agent research community. It was thus developed to be MASIF compliant
and was extended to include the FIPA compliance as well (Baumer, Breugst, Choy &
communicate and interact in both a transparent and interactive means with multiple
Grasshopper classifies its agents based on their nature of action meaning that it has two
types of agents, mobile and stationary. Each agent has its own set of functions and data.
The agents run inside an agency. Thus, an agency is the agent runtime environment. The
agencies also have 2 parts, the core agency that provides basic execution of agents and
the set of places. Similar service provision is grouped into a place. Each agency is
places and agencies more manageable. This makes up the Grasshopper Distributed
98
Figure 5.10: The Grasshopper Distributed Agent Environment (Baumer, Breugst, Choy
& Magedanz, 1999)
components can interact with each other. For this, the region registry provides the
communication mechanism. The registry contains the CORBA interface in the form of
the MAF Agent System for remote interaction as well as other mechanisms using RMI,
IIOP or plain sockets. The management of the communications is handled here as well.
Transformation services are present on the system that actually provides the underlying
mobility of the agent itself (Baumer, Breugst, Choy & Magedanz, 1999).
Registration of the agent is necessary to know what agents and services are on the
system. This in tern is used to provide information to the information seeking agents on
the system. Also, management services are available to monitor and control the agents
and services on the system (Baumer, Breugst, Choy & Magedanz, 1999).
Another provision is the persistence service that allows the storage of the agents and the
places so that they can be revived in the case of a fault (Baumer, Breugst, Choy &
Magedanz, 1999).
99
5.9.2 Security in Grasshopper
Grasshopper provides two types of security, the external and the internal security. The
security that Grasshopper provides protects the agent platform and the agent
interactions. For these, the Grasshopper MAS uses SSL, certificates and also Java
security mechanisms.
encryption protocols are used on secure sockets. For this, Grasshopper uses RSA. Also,
to protect from message corruption, authentication codes are used to check if there are
any errors in the agent during the transmission. For this Grasshopper uses MD5.
components. For this, digital signatures are used to sign the data (Baumer, Breugst,
Internal security protects the resources from illegal access and the agents from each
other. For this, it maintains a policy in the form of an access list that contains the
permissions for the components. The permission has a type, a target and one or more
actions to access the agency. The access controller is consulted upon request to access a
resource. The access controller accesses the information of whether the accessor is an
agent. If it is an agent, its owner information is extracted from the agent and then the
policy is checked. According to this policy, access is granted if allowed, and if not, an
100
5.9.3 Comments on the Security of Grasshopper
1) Access checks in trusted classes are bypassed making it possible to shut down the
server.
2) Agent platform information like the name of the agency, the protocol and the region
3) Policies can be generated that can alter the launch and the authentication in the
system.
platform according to the code and a malicious platform can deny transmission.
6) Resources are protected and controlled by a security manager not by proxy delegation
or wrappers.
5.10 Mole
The Mole MAS was developed at the University of Stuttgart and is another Java-based
MAS. The Mole MAS has been developed for the development and use of mobile
101
agents. Mole uses a very strong concept of communication, interaction and mobility of
agents. The security is thus based on the mobility provisions that Mole provides. Mole
secures the agents and the platform the agents are executing on (Baumann, Hohl,
Mole has a rather simple architecture and consists of basic components to provide
management and consumption services to provide control over access and to manage the
platform components (Baumann, Hohl, Rothermel & Straber, 1998). It looks somewhat
Figure 5.11: Mole Architecture (Baumann, Hohl, Rothermel & Straber, 1998)
Mole contains the concept of mobility in its provision for mobile agents. This utilized
the Java RMI, the agent threads are suspended, no message calls are accepted, the agent
is removed from the list of agents and the agent is serialized. The agent is then
102
Agents can interact with each other through the directory. Each agent is assigned an
Each agent can be either active or passive, depending on its mode. If it is in a listening
mode it is passive and if it is in a sending mode, it is active. So, an agent can register
itself into the directory to detail its provided service. The agent is then contacted by the
active agent for service (Baumann, Hohl, Rothermel & Straber, 1998).
Mole consists of a communication service that allows the agent to interact in different
ways. One of the methods of communicating is that the agent interacts with another
agent for its service. Second is that the agent spawns or controls another agent. Third is
that the agents know each other to form a group and interact with its group (Baumann,
Hohl, Rothermel & Straber, 1998). These are handled by the communication service.
Agents are allowed access to the resources according their allowed permission. This
permission is based on their accounts and the resource control or the policy. Various
components are managed by the resource manager that checks each request according to
the policy that the agent has according to its Agent ID (Baumann, Hohl, Rothermel &
Straber, 1998).
Security in Mole uses a simple technique to protect the resources and the agents. It uses
the simple Sandboxing model which does not allow an agent to use certain dangerous
commands that the agent may issue. For this, service agents are present that actually
provide the system access between the agent and the resource itself (Baumann, Hohl,
103
Mole also uses places for mobile agents. An agent place can set restrictions on which
agents to allow and which not to allow. The agent access to resources can be controlled
via the policy set by a place as well. Agents in the place and outside the place both have
Resources are protected by the service agents as direct interaction is not possible.
Secondly, the manager prevents DOS attacks from the agent in cases where the agent
does not let go of the service as there are allocation times to the resources in the resource
Mole Security is small and thus rather limiting. The limitations and weaknesses are as
follows:
1) Sandboxes limit the agent activities and functionality as they are not allowed to do
much.
2) There is no security for the mobile agent code being tampered or spied on by outside
sources.
3) Agent migration paths can be tampered with as the platform is responsible for the
104
5) To control access to resources, service agents provide a trusted middleware for their
access.
Mobile agent systems security is evaluated by the kind of approach they use for the
protection of the mobile agent and the agent platform. This is summarized in the form of
two tables. The first table contains the techniques to protect mobile agents in the mobile
agent systems surveyed. Table 2 summarizes the techniques used in the protection of the
agent platform.
The tables show if a particular technique is present, denoted by a Yes and if not present,
it is denoted by a No. TBI means that the technique is To Be Implemented in the system
as said by the authors of the system. Partial means that a technique exists but not
completely.
Table 5.1: Mobile Agent System Security Evaluation – Mobile Agent Protection
105
Grasshopp No No No No Yes No No
er
Mole No No TBI No Partial No No
Table 5.2: Mobile Agent System Security – Protection of the Agent Platform
106
Chapter 6
Framework
This chapter presents the details of the proposed framework for mobile agent security.
The proposed framework protects an agent as well as the platform that the agent
executes on. It comprises of various components to enhance the MAS model to provide
The proposed security framework comprises of certain components. These in turn have
their own sub components that are added or enhanced from a general mobile agent
Generally, the host spawns an agent that travels from one platform to the next for its
processing. The spawned agent keeps the list of the platforms to be visited in its
itinerary. Another way may be that an agent be spawned for each platform. That means n
agents for n platforms to go to the platform and come back instead of one agent to go to
107
each platform one by one. Thus, allowing parallel execution of mobile agents on
platforms.
The mobile agent is comprised of code and state data that is executed to perform certain
necessary tasks required by the host that sends the mobile agent for its functionality. It
requires the platforms execution environment to fulfill the tasks that are assigned to it.
The mobile agent visits the various platforms in its itinerary to acquire the services and
resources that are required by the host the mobile agent belongs to. The agent is sent as
an encrypted set of methods that can only be decrypted by the platforms it is visiting.
Also, sensitive information is made immutable such that it can be viewed but not
Upon completion of its journey, the agent returns home (to its spawning host) and
provides the host with the service results it was sent to acquire in the first place.
This entire process is shown in Figure 6.1. The host spawns an encrypted mobile agent
that is sent onto the agent platform 1. On this platform, upon authentication of the
mobile agent, the mobile agent is decrypted and its execution commences. The mobile
agent then migrates to the next platform, agent platform 2. Here the mobile agent goes
through the same process. Finally, after its itinerary is complete, the mobile agent
The framework thus has a few distinct components that can be drawn from Figure 6.1.
These are the mobile agent, the host that creates and collects the mobile agent and the
agent platform(s) that the mobile agent executes on. Each of these components has their
own subcomponents that allow the MAS to actually process. These components are
enhanced and tailored to provide the required levels of security that a MAS requires.
108
Figure 6.1: MAS framework overview
The proposed framework operates based on certain assumptions. The assumptions are
listed and discussed prior to the framework. These are listed as follows:
2) Failure of the platforms, loss of agents during transmission is outside security issues
and is a part of fault-tolerance of a MAS that can be added along with or as an extra
109
4) Itinerary is built a-priori. The host knows where the agent is going rather than an
5) The agent that has left the host will become malicious. Thus, every agent that returns
has to be checked and tested before it is accepted by the host from where it left initially.
6) Cost to provide security is acceptable in terms of size of the agent, the processing
The host platform is the origin of the mobile agent. This is the base system that requires
a mobile agent to execute remotely for its own needs. The responsibility of the host is to
allow the creation of reliable and secure agents that contain processing information.
Also, it has the responsibility to provide a docking environment for agents to come back
after their journey, gathering their results, manipulating these results and then finally
Each host has their subcomponents that are shown in Figure 6.2. These components are
discussed in detail as follows. Figure 6.2 shows the host component which is the centre
for mobile agent creation and then the collection of the returning agents.
110
Figure 6.2: Host
The host spawns the mobile agent with a mission to process its information on a remote
agent platform. For this mission, all necessary data is provided to the agent, this includes
Along with the provision of the code and data the agent is assigned its credentials. These
include the necessary details that distinguish the mobile agent to the host and the agent
The credentials include an agent ID that is unique for every agent. This is entered into an
agent spawned log on the server along with a validity time for the agent. Then there is a
host name that tells a receiving platform to which host the agent belongs to.
The credentials are then signed by the host using its private key.
111
6.3.2 Agent Dock
An agent that is to be sent is first docked into a transfer queue where its identity is
entered into a list. Also, the agent is digitally signed and its methods are encrypted using
the host’s private key. The agent is also allotted a list that contains the various platforms
it has to visit on its journey. This list for agent platforms is the agent itinerary.
After the agent has completed its journey, it returns to its home station. First of all the
agent ID that was initially assigned by the host is checked. This ID is responsible for
telling the host that the agent actually belongs to the host and is one of its own.
The collected mobile agent is decrypted using the host’s private key and its results
acquired. This mobile agent is then disposed by the host as it becomes useless. The
The host provides a mobile agent transfer mechanism that implements the protocol for
The mobile agent is the most integral part of the mobile agent system. Since it is prone
to a lot of danger from the network and the platform that it is running on, the mobile
agent needs to be protected. In the proposed framework the mobile agent is made secure
by adding certain security measures to its construction. The agent has its own
components that need to be secured and protected from the various threats that may
prevail. Thus, for the agent we define security at its component level. The security
112
The secure mobile agent is shown in Figure 6.3. The various subcomponents that are
shown in this figure are described as follows. The mobile agent subcomponents are
similar to many other MAS agents. Thus, we modify the mobile agent slightly to include
The mobile agent contains both code and data. The code is composed of its functionality
in the form of methods. The data is the agent state in its migration from one platform to
the next. The methods that exist in the mobile agent comprise the methods that the agent
The data part in the mobile agent is composed of the computation results on each
platform that the mobile agent has visited in its entire journey. These data values are
required for certain computations as intermediate results and some of these are the end
113
results that are required by the host from the mobile agent that it was sent for in the first
place.
6.4.2 Itinerary
The agent also contains an itinerary that details the hosts it has to go to in its cycle of
motion. This is the list of the agent platforms that the mobile agent has to visit as it is
spawned from its host. The itinerary has a pointer that denotes the agent’s current
platform. From this the next platform can be determined by the agent when it has to
Figure 6.4 shows the illustrated form of what an itinerary looks like. It contains a
number of the platforms that the mobile agent visits on its way. The itinerary also has
alternates that the agent may choose between. When the itinerary is read the alternates
Another thing to notice is that along with the platforms is their public key that have been
added to the itinerary for the re-encryption of the code of the mobile agent at various
platforms.
114
6.4.3 Credentials
One more thing that is added is the agent contains other information listed as the mobile
agent’s credentials. The credentials contain the agent’s host, the agent’s creator, the
agent’s identification (agent ID). From this, the agent’s digital signature is computed
that is then used to authenticate it on various platforms. This is similar to the mobile
This contains the set of certificate for each particular platform individually. A certificate
is for a particular platform in the agent itinerary denoting a set of rights that is required
A simplified illustration certificate vector is shown in Figure 6.5. The vector contains
various certificates that are present for the designated host. The certificates are according
to the role that the agent may assume on a specific platform. According to these roles,
This is an append only list maintained for firstly carrying the immutable and read-only
correct hash of the code of the agent signed by the host’s private key. The list keeps on
115
building as each platform the agent visits in its itinerary recomputes the agent code’s
hash and digitally signs it with its private key to this list.
A simplified illustrated hash list is shown in Figure 6.6. As shown, the list contains the
original hash value of the code signed by the host. Each platform and the mobile agent
code’s recomputed hash value that is signed when it has visited the platform are placed
in the list. This means that initially the list is built up as the mobile agent progresses in
its journey.
This is a method implementing an agent encryption function. This function uses the
public key of the agent’s destination platform embedded within the agent itinerary to
encrypt the agent in an asymmetric manner such that only the platform with its proper
private key can decrypt the mobile agent code for executing it.
The same encryption function is used to encrypt the data as well. There is data that the
mobile agent requires on the destination platform. This is kept in a briefcase that is
encrypted with the same public key (destination platform’s public key) as the code and
sent along with the agent. The other data that is only required by the host is encrypted
using the public key of the host to keep the data private. This is only decryptable by the
116
host platform as it requires the private key of the host for decryption. Thus, the data is
The Certification Authority (CA) is a trusted third party available in the network to
maintain a form of trust among the domain of the hosts and platforms that are utilizing a
MAS. The CA and its subcomponents look like Figure 6.7. This CA is similar in concept
to the CA in (Fu, 1999) such that it distributes the keys and creates a point of
The CA provides the host with a certificate carrying the digital signature of the host.
Similarly it assigns all other platforms with their own digital signatures to be verified
when required. The signatures will never overlap for any server in the MAS.
117
This is shown in Figure 6.7. All authorized certificates by the CA are stored in the
This component is present to verify the signature of a server in the MAS. The request to
verify a signature responds with a correct or incorrect signature reply that is used by the
As shown in Figure 6.7, the verifier checks the certificate in the certificate database.
The responsibility is to provide and distribute public keys of the servers in a MAS. The
host requests the public keys of the agent platforms that the created mobile agent will
The remote agent platform is a system on the network with an environment allowing the
agent to execute its process and the resources it requires to access in performing its
function. The platform needs to provide security measures to protect itself from
malicious activity from the mobile agent. Also, it needs to safeguard the mobile agent.
As shown in Figure 6.8, the mobile agent enters the platform and is authenticated using
its credentials. The mobile agent is then decrypted by the platform by the platform’s
private key. Then the mobile agent is allowed to run in the padded cell to check its
118
commands for building up its access control list to access the resources that may be files,
As soon as the mobile agent executes, it is migrated to the transferer and allowed to
encrypt itself. The details of the architecture of the platform in our secure mobile agent
framework are present in the following sections that discuss the various subcomponents
of the framework. Figure 6.8 shows the platform component of our MAS and its
subcomponents along with their respective interactions. Figure 6.10 shows the process
of administering the rights on the mobile agent that is authenticated, in other words, the
119
The resource registry, domain database and the agent transferer are similar to Ajanta but
in retrospect the components have different functionality and relation to the other
components that are not a part of the Ajanta MAS (Tripathi, Karnik, Vora, Ahmed &
Singh, 2000). The proxy delegation is adapted from (Tripathi, Karnik, Vora, Ahmed &
Singh, 2000) but it is extended to be generated from the Access Control List.
6.6.1 Authenticator
This component provides a simple functionality required in our domain, the function of
trust. The agent is checked for the digital signature of the creator of the agent from with
in its credentials. This allows the agent to enter the platform or not.
The agent carries a set of credentials with its code and data. These hold the digital
signature of the creator of the agent. The platform can verify the signature from the
Another purpose of this is to check the agent’s itinerary. The agent path is viewable for
where the agent has been. The agent is also authenticated on the basis of the previous
Another security issue that is checked is the mobile agent code’s has value for
corruption. An agent code that has been corrupted along its path will never be the same
resulting in a different hash value. This value is checked with the original value of the
The agent certificate vector allotted to the particular vector is also checked. The level of
access required by the agent is also a mechanism for its rejection or authentication to the
platform.
120
In Figure 6.9, a mobile agent enters the agent dock on the platform. Here the mobile
agent’s credentials are checked. The information provided in the mobile agent’s
credentials is checked from the Certification Authority. This is done using the agent
information gatherer. The mobile agent that is being checked is entered into the domain
database to keep track of all mobile agents that undergo the authentication process. The
rejected agents are directly sent to the agent transferer. Otherwise the agent enters the
platform.
The mobile agent’s functions are encrypted and can only be decrypted using a proper
key on the agent platform. The agent is decrypted and the functions opened to run on the
platform.
This is done by encrypting the agent using the agent’s own encryption function. The
agent is encrypted with the destination platform’s public key. The agent upon migrating
to its destination is decrypted by the platform using the platform’s private key. Thus,
121
only a platform that possesses the correct key can view the platform. This mechanism
This component thus implements a decryption mechanism based on the key given to the
agent. The mobile agent code is decrypted and readable by the platform using its own
private key.
covered in the survey of countermeasures. It has resemblance mainly with the approach
by (Algesheimer, Cachin, Camenisch & Karjoth, 2001) and its improved version in
To protect the platform, we use a padded cell to contain the agent and check its
execution before it actually executes. The padded cell disables direct interaction of the
agent with the platform resources and checks for malicious activity by analyzing the
On the basis of these commands the agent issues, a set of rights are described for the
agent according to the policy that is set for the resource based on the mobile agent’s
credentials. Some commands are blocked out and some are allowed.
As shown in Figure 6.10, a decrypted agent enters the padded cell where it is checked
according to the policy that was created for the agent according to its certificate(s) for
the platform and its resource. Each command is checked along with the policy and the
The padded cell in the framework is unlike the one in the Safe-Tcl (Ousterhout, Levy &
Welch, 1996) security model because the Safe-Tcl model has a feature of only mapping
122
the commands to the master interpreter for safety. Here, we use the padded cell to test an
agent and to extract the ACL for applying a policy on the agent execution.
The policy engine is basically configured by the administrator of the agent platform. The
platform sets policies on its resources and services through the policy engine. The policy
engine checks the credentials and sets the policy according to the resource to be
Each agent’s certificate vector is used to apply the policy. That is used to check the
kinds of access the agent allows and whether the platform can provide it or not in the
platform. This is used to build the policy for the specific agent.
123
Upon comparison, the policy engine provides its second function. The agent access
control list issuance. The access control list is like a passport for the agent. it contains
the requests it can issue to the resource on the platform. This is according to both the
policy set on the agent initially and the performance of the agent in the padded cell.
As shown in Figure 6.10, the policy engine provides a policy for the agent. The policy is
for the agent interaction with the resource. For another resource it requires, another
This keeps track of all the resources/ services on the agent platform. For resources being
used it also lists which agent or agents are using what resource and what is the
maximum permissible time for an agent to wait for the resource before a resource
In Figure 6.10, the resource has to register itself in the resource registry to have a policy
This is merely a logging station for the mobile agent execution. This component records
the actual execution and resource consumption on the platform according to every agent.
The domain data base enters an agent and its credentials once it acquires the service of
authentication. This means even the rejected agents are logged. The agents that are
authenticated and allowed execution are traced until rejected or transferred upon
completion of execution.
124
As shown in Figure 6.9, the agent entered has to add itself to the domain database. The
domain database is used for keeping track of all occurrences that occur on the platform.
The resource keeps on sending this information to the domain database as shown in
Figure 6.10.
The log of the agent is kept as a trace of execution. This can later be referred by the host
if required, so it is digitally signed by the platform that is creating it. This log is kept in
Resources are the platform’s data and services that can be accessed. This is through an
interface that allows the access of the resources on the agent platform. Thus, the
implemented according to the agent access list. According to the agent credentials and
nature that is checked in the authentication and the padded cell interactions, it provides
accessor methods in its interface. Other methods are turned off accordingly. This is
The proxy is also used for the interaction of agents. The mobile agent that requires the
interaction with another mobile agent sends a request. The agent then generates a proxy
125
object for the interacting agent according to the agent request and its own
The proxy manager is responsible for creating a proxy for the resource. This is generated
as an interface that provides the access methods for the resource/ service. Here,
according to the agent access control list (passport) the agent is provided with a proxy of
the resource, by simply enabling and disabling the methods that the resource
implements.
The proxy manager is responsible for the generation of the proxy. The access control
policy is used by the proxy manager to implement a proxy object for the resource that
needs to be accessed by the mobile agent. Figure 6.10 shows this. The proxy manager
creates a proxy and the proxy is used by the mobile agent to access the resource of the
platform.
This component is responsible for providing the agent a safe route to the next platform
from its current platform. Also, here the agent code hash is recomputed and digitally
signed using the current platform’s private key and stored in the agents hash list.
126
This is not a responsibility of the transferer, but it is at this point the agent runs its
encryption mechanism and uses the next platforms public key to sign itself. The agent
Summing up the security framework, the complete view of all the components plugged
127
Chapter 7
Framework – Operation
Security Scenarios
Using the proposed security framework we go over the threats in the threat model
checking how the framework 1) protects the agent and 2) protects the platform. We
present various scenarios one by one handling each threat that the MAS may encounter.
When an agent is created it is assigned an ID for its own reference. The agent is allotted
certificates. The certificates are digitally signed by the host with its primary key. This
can be verified using the Certification Authority which delegates the digital signature,
An agent that is created is then placed into the agent transferer where the transferer sets
128
The agent is created and its information entered into the spawned log. According to each
agent, there can be a timer associated after which the agent becomes invalid. This is by
Also, during the creation process, the agent is encrypted using its encryption function
with the public key of the destination platform in the mobile agent’s itinerary. The
public keys are obtained from the CA which maintains a Key Distribution Centre that
coordinates public keys to requesting servers. These keys are maintained inside the
The agent arrives on platform A, which is a part of its itinerary. Platform A authenticates
the agent according to its security credentials. The public key is globally known. If the
mobile agent cannot be identified by its digital signature then it is simply rejected. The
129
signature is verified by issuing a request to the CA. If the CA responds positively, then
Secondly, the certificate that is carried by the agent is checked. This tells the resource
the mobile agent requires and the privilege that it requires on it. The platform can reject
the agent on the basis of its required resource access as well. For example, an agent
requires a resource R and the platform does not allow access to it, the platform can reject
the agent
Thirdly, a mobile agent can be checked for its code integrity. The hash value that the
mobile agent is checked with the hash value that the previous platform signed. If these
are equal the code is real, if not, the code is corrupt and the agent is rejected. The
integrity of the certificate can be checked. The signature of the host that created the
agent is checked through the CA. The authentication process is shown in Figure 7.2.
This kind of protection guards against the mobile agent masquerading against the
130
7.3 Scenario 3: Accessing the mobile agent by the platform
Once the mobile agent has been authenticated by the platform, the agent needs to verify
that the platform can be trusted as well. The agent can only be accessed by the platform
if its code is viewable by the platform and its services. For this, the mobile agent is
encrypted using the public key of the destination platform by its own encryption
function. The mobile agent can thus only be decrypted by the destination platform’s
private key. The mobile agent goes through the cryptographic component of the
Only the destined platform would know of the agent’s decryption key as it is based on a
private key decryption system. If the mobile agent cannot be decrypted, it terminates
after a wait time. If an agent life exceeds a particular time to decrypt, it terminates itself.
Thus, the mobile agent is protected from the platform’s unauthorized access to decrypt
The mobile agent re-encrypts itself before it goes to the next platform so this whole
process is followed again. The data that is computed at one platform is encrypted by the
public key of the host, hence different from that used to encrypt the code. The system
code.
If this data is required at other places the data is placed as a briefcase, i.e. the state data
is saved and execution can use this data to resume. This briefcase is sent virtually with
the agent.
There are two sets of data, the agent’s private data and the agent’s public data. The
private data is encrypted by the agent and can only be decrypted when it returns to the
131
host, by the host. The second is the data that the agent requires to complete its execution
at the commencing platforms. This data is kept in the briefcase of the agent.
This process is shown in Figure 7.3. The agent that is not decryptable is sent to the
transferer to be sent to either the next platform in its itinerary or back to its host.
The agents are issued an access control list once they are checked by the padded cell.
These are kept on the platform’s domain database according to the agent’s identity in its
credentials. The mobile agent’s certificate vector is used by the policy engine to obtain a
policy along with the actual policy of using the resource on the platform. According to
the policy that is obtained from the certificate vector which specifies the resources that
the mobile agent requires from the particular platform the mobile agent visits, an agent is
authorized for using the agent. Each agent may occupy multiple roles on the platform
132
while it is executing. The certificate for each role may be differently dealing with the
mobile agent; hence multiple vectors may exist for an agent at a platform.
Each authorized mobile agent’s execution is traced on the platform and kept in the
domain database. An authorized agent can use all the resources that it is allotted to it by
the access control list. However, direct interaction is prevented through a proxy that
stands for each interacting authorized agent to avoid possible manipulation attacks on
Another thing worth mentioning is the use of the proxy manager. The agent’s generated
access control list is used by the proxy manager to generate a proxy for the agent that is
133
binded with a resource. The proxy manager checks which methods are allowed and
which are not allowed in the access control list, accordingly the code interface to access
the resource is generated by the proxy manager in the form of a proxy for each agent
platform
An agent that is authenticated is trustworthy but not yet safe. Its functionality may still
be malicious. The agent is sent to a padded cell. The padded cell is like a pseudo agent
environment. It allows the agent to run and call its commands but it does not fully
what kind of activity it performs. The pseudo-resources are provided to the mobile agent
according to the certificate vector designated for the particular platform and its particular
resource.
For the policies that are present for the particular resources the agent requires on the
platform are used. The policy is used to check what kind of access is permissible. The
agent command are checked and if the adhere to the policy they are granted in an access
control list that is generated here. The other commands are blocked in the access control
list.
Also, repetitive and non-terminating commands are checked. For these, the mobile agent
is given partial access. This means that the agent can issue the set of commands for a
while after which the resource is freed. This is shown in Figure 7.4. The padded cell
134
checks the agent along with the policy associated with it and the resource. Thus there
will be multiple policies against each agent in the padded cell for each resource.
The agent can only access the resource through a proxy. The proxy is generated using
the mobile agent passport in the domain database. The proxy, being an interface,
generates the implementation of only those methods for which the agent has access. The
agent is the binded to the resource through this proxy. The access is controlled implicitly
by the proxy. If the right is supposed to be read-only, the agent will only get the read-
Also, to protect DOS attacks that may be caused by other agents on the platform, the
proxy will register the resource being used in a resource registry. This registry will be
resource, it is made to wait for a particular wait time. The resource is freed and given to
the next in line. The competing agents have to wait in line according to the policy set in
the passport. The higher priority goes to the ID assigned with a priority according to its
Every agent has a particular time. If the agent does not gain service within that time, it
transfers to the next platform or stops executing, as specified by the agent creator. Figure
135
Figure 7.5: Proxy Usage
The framework does not allow direct use of the resource and services by the agent. The
agent only settles itself and executes in accordance to the environment, i.e. the system.
So, the agent relies on the platform’s environment for its deployment and execution on
the platform.
The domain database keeps track of all the transactions with the platform to avoid
repudiation. This protects the platform from being hindered and places the MAS at a
separate level.
For transferring an agent, the agent goes through a simple process. The agent is sent to
the agent transferer where it is allowed to re-encrypt itself using the public key of the
next platform. Also, another thing that happens here is that the agent code has value is
re-computed. The hash is signed using the private key of the platform and entered into
the hash list. The value of the hash of the code is not changeable if the code has not been
corrupted.
After this, a channel is opened from the current platform to the next in the agent
136
The process steps that occur during the transmission of the mobile agent in the agent
Each agent has a respective ID assigned to it in its credentials assigned by its spawning
host. The ID is unique to each agent according to the host’s properties conjoined with its
creation timestamp and vendor. Thus an agent that is cloned would have the same ID as
its original. It would be rejected by the host if the agent with the same ID is already
137
7.10 Scenario 10: Protecting agent communication
The domain database records the type of communication going on between the agents
and the platforms resources. The environment does not allow multiple resend messages.
If a message is to be repeated it is sent after a wait time. The host of course cannot
Figure 7.7 shows this process. For an agent to communicate with another agent it
requests the second agent to issue it a proxy. This proxy allows the communication
methods that the programmer allows to any requesting agent, unless the agents are from
the same host or vendor. In this case the privileges might be greater between them
similarly, if another agent wants to communicate, the agent issues another proxy. Also,
if the agent that is requesting communication has to be used by the other agent that it is
using, the second agent has to request a proxy and the initially requesting agent
delegates its proxy in the same way. Thus the proxy is one-way.
Tracing the execution is done for protection of the platform as well as the agent. The
domain database is responsible for logging all the occurrences of execution flow from
138
For the case of the platform, the trace can be rechecked in the case the host denies to
ever send an agent to the platform. Or, in the case where an agent states that it did arrive
on the platform, but it did not process or commit a particular command that it was
authorized to perform. In such a case the domain database retrieves the agent’s trace
along with its timestamp and presents it to the host of the agent.
For the case of agents, when the agent arrives that has exhausted its time limit, it
possibly suffered a denial of service attack. The trace is checked from the platform. The
Also, in the case that the agent has been corrupted its hash values can be checked as
where the actual change occurred. The trace is called from that particular platform and
Each platform re-computes the mobile agent code that it decrypted and signs it. This is
then added to the mobile agents hash list. For an agent that is rejected by the platform or
an agent that cannot be decrypted, the same hash that the agent carries is added to the list
Since the platform public key is known, this can be used to check the signed hash value
of the platform.
Protecting the itinerary is vital because the agent pathway altering means corruption to
the core functionality of the mobile agent. So, the itinerary in our approach is created
139
prior to the migration. The itinerary will not change its pathway. Alternate paths are
To protect the itinerary, the hash is computed for the itinerary and digitally signed as
shown in Figure 7.1. Any one changing it is not at all possible because then the private
key to sign it would be required. Also, the hash is computed to that any tamper in the
When the mobile agent has completed its execution a number of processes are followed.
The agent arrives into the agent dock. This part of the dock is for received agents. The
mobile agent is first checked for its agent ID and its timestamp. If the ID is of an agent
that belongs to the platform, the timestamp and ID must be in the spawned log of the
host.
If the timer has exceeded the dedicated time value (t = time stamp + time elapsed) the
To see the processing scenario, we have Figure 7.8. The mobile agent is decrypted using
the host’s private key as the agent encrypts itself using the host’s public key before
arriving. The code hash is recomputed and compared with the original value. Also, the
itinerary is checked by re-computing its hash value. If any of these differ from the
original, the hash list is extracted. The host checks where the hash value changed.
Since the values are digitally signed, the host requests the platform where the hash
changed. The trace is digitally signed by the platform for each agent. The trace is
140
ID incorrect –
Send to Host’s
Platform
Authenticator Authenticate Decrypt Agent
Authenticated
Mobile Mobile
Agent Agent
Itinerary
Recomputed
Hash
Itinerary
Correct Form Hosts
Spawned Log
Code incorrect
– Call trace Check Hash List Check Code Original
Hash
Hash List Code and Data
Recomputed
Hash List
Hash
Code Correct –
Decrypt data
Acquire Agent Data
Data
Manipulate Data
141
Chapter 8
Implementation
This chapter covers the details of the implementation of the proposed security
and then their subcomponents. This chapter discusses the implementation to implement
The security framework generically has its main components being the mobile agents,
the host that creates the mobile agent, the agent platform that executes and provides an
environment to facilitate the execution of the mobile agent and the certification authority
The language we choose is Java (Sun, 1994) because it provides various security and
encapsulation features that we require (Gray, Kotz, Cybenko, & Rus, 2000). Also, in
comparison with other languages, it has certain benefits like, portability because of
142
communication through the RMI technology and also because Java is very suitable in
providing ease to implementing the mobile agents. Another feature that we use is XML
(Refsnes Data, 1999) for the specification of certificates that are used in the system. We
use XML because of its size and it being a standard that can easily be used to specify the
requirements of our system. Also, XML is portable and easy baggage for the agents to
carry. We use the specifying of the logs that are present, the certificates, the credentials
of the mobile agent, the access control list, the itinerary and the hash list. Similarly XML
can be used in accordance to SOAP for communicating mobile agents. Also, it is easy to
apply digital signatures to XML documents. Lastly, XML makes the entire
For storage, to make it manageable we use the strength of any Relational Database
Management System. The data stored is of the mobile agents created at the host, the
certificates at the CA, the domain database at the agent platform. Hence, there is a large
amount of data to be tracked. Also, this data needs to be accessed and retrieved quickly.
Thus, an RDBMS is sufficient. Also, RDBMS can store and retrieve the XML
certificates of the system. For the logging, XML is not used and simple traces are placed
in the RDBMS.
For the implementation of mobile agents, we use Java. The mobile agent is implemented
as a stateful object. By being stateful, the mobile agent maintains its state to resume
in Java (Gray, Kotz, Cybenko & Rus, 2000). The mobile agent interface contains the
143
methods that are present to implement the mobile agent. These methods include its
mobility, its itinerary acquirement, certificate list traversal, encryption, credential access.
Thus the structure of an agent has a serializable interface that contains the mobile
agent’s general functions. Also, the mobile agent has an accessor interface that is
implemented by an accessor class to allow access to the agent. The agent also creates a
proxy for communicating with other agents. For this the mobile agent accessor method
The mobile agent specific functions are implemented in the mobile agent class or classes
that refer to the agent functionality designated to it by the agent programmer. The
}
Figure 8.1: Mobile Agent Interface
The mobile agent accessor interface implements the Java serializable interface. This is
144
interface MobileAgentAccessor implements Serializable
{
public Vector acquireCredentials(HostID host);
public AgentHash acquireHostHash();
public Object decryptAgent(PrivateKey prikey);
public void signHash(Signature signature, PlatformHash
platformhash);
public agentProxy delegateProxy(String request, int requestNo,
String agentID);
}
Figure 8.2: Mobile Agent Accessor Interface
The credentials are placed with the mobile agent in XML. It is shown in Figure 8.4.
145
Similar to the credentials, the hash list is an XML document which looks like Figure 8.5.
<HashList>
<Host>
<HashValue> </HashValue>
<Signature>
</Host>
<Platform platformName = "" URI ="">
<HashValue> </HashValue>
<Signature>
</Platform>
</HashList>
Figure 8.5: Hash List
The credentials list holds a number of the agents’ credentials like a vector. This looks
<CertificateVector>
<Platform platformName = "" URI ="">
<Certificate>
<AgentRole RoleName = "" State = "">
<ResourceRequired Name = "">
<Access><!--
Read, Write, Modify etc. Methods-->
</Access>
</ResourceRequired>
<ResourceRequired Name = "">
</ResourceRequired>
</AgentRole>
</Certificate>
</Platform>
</CertificateVector>
Figure 8.6: Certificate Vector
146
8.3 Host
The host implementation is done in Java. The host has a container responsible for the
creation and the collection of the mobile agent. The host has several smaller
The host has a creator component that is basically a factory for agents. For this, we have
a simple Java factory for the agents created by a programmer. The creator class is like
Figure 8.7.
class AgentCreator
{
public void createAgent(Vector agentCredentials, Itinerary
itinerary, Vector certificates, Agent agent){
AgentFactory factory = new AgentFactory();
log(agX);
}
/*
.
.
.
.
*/
}
Figure 8.7: Agent Creator
To digitally sign the agent any Java signature scheme can be used.
147
8.4 Agent Platform
The agent platform possesses a container as well. The responsibility of the container is
to allow the agent to execute. The architectural model is of a simple Java container. The
agent authenticator uses a simple mechanism of retrieving the mobile agent’s credentials
and checking the digital signature of the agent. If the agent corresponds to the
class Authenticator
{
Vector credentials;
Object host;
Object vendor;
//gain credentials from the Vector for the platform and put
them into their designated places
return credentials;
}
if (checkHash = previousHash)
{
148
//do whatever with correct agent
}
else //do whatever with corrupt agent
//Verify signature
checkAgentVendor(vendor);
checkAgentHost(host);
}
}
Figure 8.8: Authentication
The agent decryption mechanism is within the padded cell. It uses the private key of the
agent platform the mobile agent is running on to decrypt the code. The padded cell tests
the agent according to the policy that is allowed to it. The testing of the agent in the cell
class PaddedCell
{
public Object decryptAgentCode(PrivateKey priKey){
//any decryption algorithm
CryptogrphicComponent crypo = new CryptogrphicComponent();
crypo.decrypt(priKey);
}
class PolicyEngine
{
String resourceURI;
149
public Policy grantPolicy(Vector credentialsVector, Resource
resource)
{
//look for resource and acquire the resource's URI
Policy policy =
accessResourceRegistry(lookup.forName(resourceURI), resource);
}
}
Figure 8.10: Policy Engine Policy retrieval
<Policy>
<Role> <!--
the roles an agent may occupy-->
<Resource>
<!-- Access Type -->
</Resource>
</Role>
</Policy>
Figure 8.11: Policy
interface. The accessor methods of the resource interface implements the generic
150
methods that are common to all resources. The access of resources is through proxies
that are delegated through the getProxy method that issues the proxy through the access
control list issued to the agent for the resource. The resource implements the resource
interface and to access the resource, the access protocol is used to gain access to a proxy
as specified by the agent’s ACL. Figure 8.13 shows the interface that every resource
must implement and Figure 8.14 shows the actual implementation of the resource
specific functions. Figure 8.15 shows the delegation of a proxy to the resource that needs
to be accessed by the mobile agent. Figure 8.13 and Figure 8.14 have been adapted from
(Tate & Xu, 2003). The Resource access protocol class is an extension to (Tate & Xu,
2003).
The agent transferer is like Figure 8.16. The new platform is located in the agent’s
agent’s necessary data kept in a briefcase and transferred to the located platform.
151
class AgentTransferer
{
Itinerary itinerary;
Data data;
AgentTransferer(){
itinerary = new Itinerary();
data = null;
}
try{
go(encrypt(agent), briefcase);
}catch (UnknownHostException){
//cater exception
}
}
}
Figure 8.16: Agent Transferer Sequence
152
Chapter 9
Framework
This chapter evaluates the proposed framework in Chapter 6 according to the threat
model presented in Chapter 3. The threat model is applied according to the operation
scenarios of the proposed framework from Chapter 7. The chapter then compares the
framework with other frameworks and draws out the benefits and limitations of the
framework.
Summarizing the results of applying the threat model on the operation scenarios, we
come to know the security applications of the proposed framework and how. For the
evaluation results we present 3 tables. Table 9.1 contains the threats from malicious
mobile agents and threats from malicious platforms and it details whether these are
153
Table 9.1: Evaluation of the Proposed Framework
A malicious mobile agent can masquerade against a platform or even a launching host.
For this, Agent IDs are present to distinguish agents uniquely. Also, the authentication
process ensures that a masquerading agent does not enter the platform. Similarly, a
platform may be masquerading as well. To protect from such a threat from the malicious
permitted, the agent is encrypted and only the real platform with the proper private key
Denial-of-service attacks from a malicious agent are prevented partially. Policies are
applied that can be helpful in aiding against pre-determined DOS attacks. Similarly, the
padded cell can detect some forms of DOS attacks. Proxies can also prevent DOS attack
by disabling certain methods based on the policy and the padded cell test results in the
ACL. As for DOS attacks by the platform, the agents are protected partially through the
154
Unauthorized access by malicious agents is protected using padded cells as agents are
tested for such access. Policies and proxies restrict the unauthorized access according to
the agent code. Also, digital signatures prevent illegally copying data as well.
Repudiation by an agent is detected by the domain database that tracks the agent and the
platform’s entire interaction. Similarly, to protect such an attack by a platform, the trace
can be recalled by the host from a repudiating platform. But this is only partial because
if the platform is malicious, the extremity to change the trace for its own gain may cause
further repudiation.
Eavesdropping is protected by encrypting agents so that they cannot be spied out. The
use of proxies provides independence to the interactions from malicious agents. Also to
prevent an eavesdropper a padded cell and proxy closes out any means of spying. On the
other hand to protect from a malicious platform, the agent is encrypted causing a secure
channel for its transmission. Similarly for interacting with other agents, the agent uses its
This is by placing it in a padded cell then by applying a proxy that restricts such actions.
To protect from a malicious platform causing alteration attacks, we encrypt our agents.
Similarly to trace the alteration, we take code hashes that are transferred in the agents
Copy and reply by an agent is protected partially through proxies, meaning that we
simply control the access of the agent. However, an agent may still gain enough
information if read access is provided. Such gain can still be a surmountable threat by a
malicious agent. To protect from a malicious platform, the agent is given an ID. A copy
155
of the agent is simply rejected and corrupt. Also, encryption provides a level of
The proposed framework is comparable to the MAS in the state-of-the-art in many ways.
aim is to allow its implementation with out the restrictions of programming language
used to build it. Thus, the comparison is solely based on the security aspect of the
Comparing with other MAS security frameworks in general, certain concepts are very
similar to Ajanta (Karnik & Tripathi, 2000; Tripathi, Karnik, Vora, Ahmed & Singh,
1999; Tripathi, Karnik, Vora, Ahmed & Singh, 2000). The Ajanta framework comprises
of a very strong mechanism for protecting against unauthorized access through proxy
application. One difference here is that the proxy is applied on a previously built policy
and there is no testing of commands like in our proposed framework in the padded cell
component. Also, the Ajanta framework uses a checksum to prevent tampering of the
agents.
Breugst, Choy & Magedanz, 1999; Gray, Kotz, Cybenko & Rus, 2000; Tardo &
Valente, 1996) divides the entire MAS into regions and places. Between these, the
agents exchange and migrate for processing. The authentication and authorization
mechanism is strong and the agents are restricted according to restrictions set through
the implementation. Our proposed framework does not base its protection on features of
156
underlying system support; it protects the MAS from threats based on techniques in its
implemented components.
The D’Agents security architecture (Gray, Cybenko, Kotz & Rus, 2001) uses resource
managers for control of resource access by agents. This technique is more centralized
than out policy engine and padded cell combination for access control. Also, the agent
itself has control over its execution and can restrict its execution based on its
surroundings. However, there is not much in D’Agents to protect agents in the MAS.
agent credentials. The Ara (Peine & Stolpmann, 1997) platform uses allowances which
act as policies on the platform. There is not much on protection of agents except that the
agent is encapsulated.
Tacoma security is very different from the security in our proposed framework
(Johansen, Renesse, Schneider & 1995; Johansen, Marzullo & Lauvset, 1999; Johansen
et al., 2001). Firstly, it uses electronic cash for control of resource access and for
protection against threats that may be caused by access of an agent. Tacoma uses
wrapper objects for agent and resource interaction. Wrappers are thus maintained for
Aglets (Karjoth, Lange & Oshima, 1997) uses a very different authentication mechanism
from our proposed framework. The authentication issues policies from a policy database
against the shared resources and services. This is like our policy engine but is not
dynamic as the ACL does not exist for Aglets. For dynamism, there is a context manager
1997). The policies are set by a security manager dynamically according to a profile
157
against the agents. The access adjustment is similar to our approach but there is no
means of detection, instead the access is redrawn for agents at run-time according to
predetermined rules.
Breugst, Choy & Magedanz, 1999). The agent is given permission according to its
owner information. Thus, the setting of access is all predetermined unlike in our
Mole uses a sandbox to protect the platform from malicious agent access (Baumann,
Hohl, Rothermel & Straber, 1998). Also it enforces policies based on services within a
set place. These are predetermined. Agent access is time based so that it lets go after a
As drawn from the discussion, we come to the strengths that the proposed security
framework provides and the weaknesses that the framework has according to its
security.
9.3.1 Strengths
1) Prevents threats to mobile agents from a malicious platform and also prevents threats
to the platform from mobile agents using simple components. The combination to form a
framework to security is still a large area of mobile agent security research discussion.
158
2) The framework is technology friendly and does not restrict the implementation of
3) The platform has a very strong mechanism to protect the MAS platform resources and
services.
art system.
5) The framework is also integratable with other mobile agent system requirements like
6) The MAS framework potentially provides safety to the agents and the platform as
well as security. Safety is provided in terms of preventing and detecting the malicious
7) Electronic cash based (money-based) techniques can be applied into the framework
9.3.2 Limitations
1) Copy and replay attacks are not fully prevented in certain cases, like if a malicious
159
2) DOS attacks are not prevented. This can be enhanced by adding a tracing
subcomponent with the mobile agent, but this would also have redundant security
limitations.
3) Dynamism of path in the form of the itinerary of the agent is not catered.
4) The MAS has to be trusted in the case of repudiation attacks response to be complete
threats from a malicious network are explicit and not of the domain of this framework as
yet. However, the encryption of agents forms a means of protection of mobile agent
160
Chapter 10
Mobile agent systems are hindered by the security that threatens their application. A
MAS is threatened by the agents, the platform running the agent and the network that the
system is communicating on. In this thesis a threat model is presented that highlights the
protect a mobile agent system from malicious attack from agents themselves, the
platform they execute on and the underlying transmission network. On the basis of the
systems is evaluated. The state-of-the art discusses the security frameworks present in
these mobile agent systems. Also, a framework that provides security a MAS is
proposed. The framework addresses the issues of security of the platform against the
malicious agents and also of the agent against malicious host platform. This is
accomplished by the use of various approaches that are the components of the
framework. For the framework various operation scenarios are listed that are in turn
used to analyze the security provided by the framework according to the threat model.
To cover the implementation issues of the framework, the implementation of the security
components is discussed.
161
Possible research directions and future work in regard to the domain (Li, Zhang, Sun &
Yin, 2004) of this thesis are immense. Starting from the requirements level, we can
utilize the Gaia Methodology for building a multi-agent system. Then we can use the
framework to design an MAS using AUML (FIPA, 2003). Similarly, the entire AOSE
through this framework. Certain methods to ensure MAS security can be developed
the framework can be extended to incorporate multiple kinds of platforms. In this aspect,
an operating system for mobile agents can be devised such that security measures can be
accommodated (Kotz, Gray & Rus, 2002). One area that has not been addressed and has
been assumed to be secure is the network (Gray, 1997). This area can be explored for
securing the network from threats while the agent is traveling and can be incorporated
into this framework. Also, the work on the fault-tolerance of MAS can be incorporated
as a part of this framework as well (Vogler, Kunkelmann & Moschgath, 1997). The
framework does provide the ability for extension to accommodate other features.
The implementation has been discussed for Java-based mobile agents. To incorporate
mobile agents in other languages, the framework will suffice, but significant changes
have to be made in the implementation discussed (Gray, Kotz, Cybenko & Rus, 2000).
Work in this direction can be extended. Also, to enhance the subject of possible security
threats, more mobile agent based applications and technologies need to be developed.
Itinerary is a-priori, meaning that it is decided beforehand (Mir & Borrel, 2002; Mir &
Borrel, 2003; Wilhelm, Staaman & Buttyan, 1998). For flexible or dynamic itineraries,
162
the security perspective will change because the mobile agent corruption will be hard to
detect.
Platform discovery mechanisms can be extended and incorporated into the framework
proposed in this thesis (Marrow & Ghanea-Hercock, 2000). Similarly, work can be done
in how to reduce costs associated with the security provision techniques. Money based
(electronic cash based) techniques can be integrated for resource consumption control as
Also, for agent communication, various languages like KQML or ACL (Rothermel &
Schwehm, 1998) can be incorporated and extended for security. They need to be made
more secure for agents to communicate secret data during collaboration. These can be
extended by the use of XML (Refsnes Data, 1999) as well for specifying secure mobile
A relevant domain can be to develop security features by specifying these using formal
notations and semantics. Using these the security features in a MAS can be verified
The uses of mobile agents are immense and their incorporation into the development of
future systems is only hindered by security. This thesis serves as a basis for exploring
163
References
Abdalla, M., Cirne, W., Franklin, L. and Tabbara, A. (1997). Security Issues in Agent
Security for Mobile Code, In the Proceedings of the 2001 IEEE Symposium on
Ametller, J., Robles, S. and Ortega-Ruiz, J. (2004). Self-Protected Mobile Agents, In the
Aneiba, A. and Rees, S. (2004). Mobile Agents Technology and Mobility, In the
Baumann, J., Hohl, F., Rothermel, K. and Straber, M. (1998). Mole – Concepts of a
Mobile Agent System, World Wide Web, Volume 1, Issue 3, pp. 123-137, Springer
Universal Agent Platform Based on OMG MASIF and FIPA Standards, In the
164
Beirman, E. and Cloete, E. (2002). Classification of Malicious Host Threats in Mobile
South Africa.
Bellavista, P., Corradi, A., Federici, C., Montanari, R. and Tibaldi, D. (2003). Security
for Mobile Agents: Issues and Challenges, Handbook of Mobile Computing, ISBN
Berkovits, S., Guttman, J. and Swarup, V. (1998) Authentication for Mobile Agents,
Mobile Agents and Security, Lecture Note in Computer Science, Volume 1419,
Brooks, R. (2004). Mobile Code Paradigms and Security Issues, IEEE Internet
Chess, D. (1998). Security Issues in Mobile Code Systems, Mobile Agents and Security,
Berlin, Germany.
Condict, M., Milojicic, D., Reynolds and F., Bolinger, D. (1996). Towards a World-
SIGOPS European workshop: Systems support for worldwide applications, pp. 25-
Cubaleska, B. and Schneider, M. (2002). A Method for Protecting Mobile Agents against
165
Workshop, CIA 2002, Lecture Notes in Computer Science, Volume 2446, p. 297,
Agents and Multiagent Systems (AAMAS), pp. 354-361, ACM Press, New York,
NY, USA.
Dias, P., Ribeiro, C. and Ferreira, P. (2003). Enforcing History-Based Security Policies
Policies for Distributed Systems and Networks (POLICY), pp. 231-234, Lisboa,
Portugal.
Esparza, O., Soriano, M., Munoz, J. and Forne, J. (2004). Detecting and Providing
Germany.
Farmer, W., Guttman, J. and Swarup, V. (1996a). Security for Mobile Agents:
Farmer, W., Guttman, J. and Swarup, V. (1996b). Security for Mobile Agents: Issues and
Feng, L., Shan, F. and Ying, W. (2003). An Enhanced Security Model for Mobile Agent
166
Learning (IDEAL), Lecture Notes in Computer Science, Volume 2690, pp. 89-93,
Ferreira, L. and Ricardo, D. (2002). Blinded Key Signatures: Securing Private Keys
FIPA (2003). The Agent Unified Modeling Language Web Site. Retrieved February 14,
Fischmeister, S., Vigna, G. and Kemmerer, R. (2001). Evaluating the Security of Three
Fu, P. (1999). A Security Architecture for Mobile Agent Systems, Master of Science
Gray, R. (1996). Agent Tcl: A Flexible and Secure Mobile-Agent System, In the
Belgium.
167
Gray, R., Kotz, D., Cybenko, G. and Rus, D. (1998). D’Agents: Security in a Multiple-
Gray, R., Kotz, D., Cybenko, G. and Rus, D. (2000). Mobile Agents: Motivations and
Gray, R., Cybenko, G., Kotz, D., Peterson, R. and Rus, D. (2001). D’Agents:
Experience archive [Special issue: Mobile agent systems], Volume 32, Issue 6, pp.
543-573, John Wiley & Sons, Inc., New York, NY, USA.
Gray, R. (2004). Mobile Agents: Overcoming the Early Hype and a Bad Name, In the
Greenberg, M., Byington, J. and Harper, D. (1998). Mobile Agents and Security, IEEE
Harrison, C., Chess, D. and Kershenbaum, A. (2001). Research Report - Mobile Agents:
Are they a good idea?, In the Proceedings of the 2nd International Workshop on
Austria.
Hohl, F. (1998a). A Model of Attacks of Malicious Hosts Against Mobile Agents, In the
168
Hohl, F. (1998b). Time Limited Blackbox Security: Protecting Mobile Agents from
Malicious Hosts, Mobile Agents and Security, Lecture Notes in Computer Science,
Jansen, W. (1998b). Mobile Agents and Security, MD: National Institute of Standards
http://www.csrc.nist.gov/staff/jansen/pp-agentsecurityfin.pdf.
Jihong, W., Jianping, H. and Kai, H. (2003). Security Design of Mobile Agent System,
Johansen, D., Renesse, R. and Schneider, F. (1995). Operating System Support for
USA.
169
Johansen, D., Marzullo, K. and Lauvset, K. (1999) An Approach towards an Agent
Johansen, D., Lauvset, J., Renesse, R., Schneider, F., Sudmann, N. and Jacobsen, K.
issue: Mobile agent systems], Volume 32 , Issue 6, pp. 605-619, John Wiley &
Karjoth, G., Lange, D. and Oshima, M. (1997). A Security Model for Aglets, IEEE
http://www.cs.umn.edu/Ajanta/.
Karnik, N., Tripathi, A. (2000). Security in the Ajanta Mobile Agent System, Software-
Practice & Experience, Volume 31, Issue 4, pp. 301-329, John Wiley & Sons, Inc.,
Kotz, D. and Gray, R. (1999). Mobile Agents and the Future of the Internet, ACM
SIGOPS Operating Systems Review, Volume 33 , Issue 3, pp. 7-13, ACM Press,
170
Kotz, D., Gray, R. and Rus, D. (2002). Future Directions for Mobile-Agents Research,
Kun, Y., Xin, G. and Dayou, L. (1999). Security in Mobile Agent System: Problems and
Lange, D. (1998). Mobile Objects and Mobile Agents: The Future of Distributed
Lange, D. and Oshima, M. (1999). Seven Good Reasons for Mobile Agents,
Communications of the ACM, Volume 42, Issue 3, pp. 88-89, ACM Press, New
Lee, H., Alves-Foss, J. and Harrison, S. (2004). The Use of Encrypted Functions for
Mobile Agent Security, In the Proceedings of the 37th Annual Hawaii International
Leung, K. and Ng, K. (2004). Detection of Malicious Host Attacks by Tracing with
Japan.
Li, X., Zhang, A., Sun, J. and Yin, J. (2004). The Research of Mobile Agent Security,
Lecture Notes in Computer Science, Volume 3033, pp. 187-190, Shanghai, China.
171
Marques, P., Santos, N., Silva, L. and Silva, J. (2001). The Security Architecture of the
Springer-Verlag, Netherlands.
McDonald, J., Yasinyac, A. and Thompson III, W. (2005). A Survey of Mobile Agent
Florida, USA.
Milojicic, D., LaForge, W. and Chauhan, D. (1998). Mobile Objects and Agents, In the
Mir, J. and Borell, J. (2002). Protecting General Flexible Itineraries of Mobile Agents,
Mir, J. and Borell, J. (2003). Protecting Mobile Agent Itineraries, Mobile Agents for
172
Ng, S. (2000). Protecting Mobile Agents against Malicious Hosts, Mater of Science
Nicola, R., Nicola, G. and Pugliese, R. (1997). Coordinating Mobile Agents Access
Rights via Blackboards and Access Rights, In the Proceedings of the Second
Novak, P., Rollo, M., Hodik, J. and Vlcek, T. (2003). Communication Security in Multi-
Orso, A., Harrold, M. and Vigna, G. (2000). MASSA: Mobile Agents Security through
Ousterhout, J., Levy, J. and Welch, B. (1996). The Safe-Tcl Security Model, Mobile
Agents and Security, Lecture Notes in Computer Science, Volume 1419, p. 217,
Peine, H. and Stolpmann, T. (1997). The Architecture of the Ara Platform for Mobile
173
Lecture Notes In Computer Science, Vol. 1219, pp. 50-61, Springer-Verlag,
London, UK.
Peine, H. (1998). Security Concepts and Implementation in the Ara Mobile Agent
Refsnes Data (1999). W3Schools Online Web Tutorials. Retrieved June 5, 2005, from
http://www.w3schools.com/.
Rothermel, K., Hohl, F. and Radouniklis, N. (1997). Mobile Agent Systems: What is
Germany.
174
Rubin, A. and Geer, D. (1998). Mobile Code Security, IEEE Internet Computing,
Saeb, M., Hamza, M. and Soliman, A. (2000). Protecting Mobile Agents against
Sander, T. and Tschudin, C. (1997). Protecting Mobile Agents against Malicious Hosts,
Mobile Agents and Security, Lecture Notes in Computer Science, Volume 1419, p.
IEEE Symposium on Security and Privacy, pp. 215-224, Oakland, CA, USA.
Schelderup, K. and Olnes, J. (1999). Mobile Agent Security – Issues and Directions, In
Networks: Paving the Way for an Open Service Market, Lecture Notes in
Communications of the ACM, Volume 43 , Issue 6, pp. 111-112, ACM Press, New
Sundsted, T. (1998). An Introduction to Agents, Java World. Retrieved January 31, 2006,
from http://www.javaworld.com/javaworld/jw-06-1998/jw-06-howto.html.
175
Tan, H. and Moreau, L. (2002). Certificates for Mobile Code Security, Proceedings of
the 2002 ACM Symposium on Applied Computing (SAC), pp. 76-81, ACM Press,
Madrid, Spain.
Tardo, J. and Valente, L. (1996). Mobile Agents Security and Telescript, In the
Tate, S. and Xu, K. (2003). Mobile Agent Security Through Multi-Agent Cryptographic
Tripathi, A. and Karnik, N. (1998). Protected Resource Access for Mobile Agent-based
Tripathi, A., Karnik, N., Vora, M., Ahmed, T. and Singh, R. (1999). Mobile Agent
Tripathi, A., Karnik, N., Vora, M., Ahmed, T. and Singh, R. (2000). Ajanta – A Mobile
Based Information Discovery and Management on the Internet, Chapter 18, pp.
176
Varadharajan, V. (2000). Security Enhanced Mobile Agents, Proceedings of the 7th
Vigna, G. (1997). Protecting Mobile Agents through Tracing, Proceedings of the 3rd
Vigna, G. (1998). Cryptographic Traces for Mobile Agents, Mobile Agents and
Vigna, G. (2004). Mobile Agents: Ten Reasons for Failure, In the Proceedings of the
Lecture Notes in Computer Science, Volume 2240, p. 213, Atlanta, GA, USA.
Vogler, H., Kunkelmann, T. and Moschgath, M. (1997). An Approach for Mobile Agent
Vuong, S. and Fu, P. (2001). A Security Architecture and Design for Mobile Intelligent
Agent Systems, ACM SIGAPP Applied Computing Review, Volume 9, Issue 3, pp.
White, J. (1996). Mobile Agents White Paper, General Magic. Retrieved March 17,
177
Wilhelm, U., Staaman, S. and Buttyan, L. (1998). Protecting the Itinerary of Mobile
London, UK.
Wong, D., Paciorek, N., Walsh, T., DiCelie, J., Young, M. and Peet, B. (1997).
Yee, B. (1997). A Sanctuary for Mobile Agents, Secure Internet Programming: Security
Issues for Mobile and Distributed Objects, Lecture Notes in Computer Science, pp.
Young, A. and Yung, M. (1997). Sliding Encryption: A Cryptographic Tool for Mobile
Haifa, Israel.
178