O. M. Paracha Thesis - Signed

A SECURITY FRAMEWORK FOR MOBILE AGENT
SYSTEMS
A Thesis Presented to
Mohammad Ali Jinnah University
In Partial Fulfillment
of the Requirement for the Degree
Master of Science
(Computer Science)
by
Omer Mansoor Paracha

May, 2006
Abstract
Agent technology is a novel approach for the development of distributed systems. In
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
by an agent. A number of different approaches have been suggested in the literature to
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
systems. Based on the techniques surveyed, a state-of-the-art is evaluated and the
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
and platform. The idea is to provide a solution to the requirement of a security
framework that provides security as a combination of components based on techniques
for mobile agent system security and protection. The proposed framework is comprised
of various components that are studied in the light of operation scenarios. An
implementation of the system is discussed and the evaluation of the proposed framework
as well as a comparison with the state-of-the-art mobile agent systems is provided to
highlight the strengths and weaknesses.

iv
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
me to the topic and advising me immensely in drawing out my proposed framework.
Thanks to Mr. Uzair Khan, Mr. Shaukat Ali, Mrs. Zille Huma and Mr. Zouhaib Zafar for
sharing their thesis-writing experiences.
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
research process flourish.
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
discussions on the whiteboard in the CSD.
I thank my family especially my parents who believed in me and gave me strength to
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
life. My family has been an astounding inspiration to my research work.
I thank Allah (SWT) for bestowing me with His uncountable blessings that are far too
many to mention here.

vi
Table of Contents
TABLE OF CONTENTS ................................................................................................................................ VI

LIST OF FIGURES ....................................................................................................................................... IX
LIST OF TABLES ......................................................................................................................................... X
CHAPTER 1 INTRODUCTION ............................................................................................................... 1
CHAPTER 2 MOBILE AGENT SYSTEMS SECURITY: A BACKGROUND ................................... 4
2.1 REMOTE CODE EXECUTION .................................................................................................................. 4
2.2 SOFTWARE AGENTS .............................................................................................................................. 5
2.3 MOBILE AGENTS .................................................................................................................................. 6
2.4 MOBILE AGENT BENEFITS .................................................................................................................... 7
2.4.1 Mobile Agent Applications ............................................................................................................ 9
2.5 MOBILE AGENTS LIMITATIONS........................................................................................................... 10
2.5.1 Mobile agent security .................................................................................................................. 12
CHAPTER 3 MOBILE AGENT SYSTEMS SECURITY - THREAT MODEL................................ 13
3.1 OVERVIEW OF MAS SECURITY THREATS ........................................................................................... 13
3.1.1 Malicious Platform ..................................................................................................................... 14
3.1.2 Malicious Agent .......................................................................................................................... 15
3.1.3 Malicious Network ...................................................................................................................... 15
3.2 THE MAS THREAT MODEL ................................................................................................................ 15
3.2.1. Masquerading ............................................................................................................................ 16
3.2.2. Denial- of-Service ...................................................................................................................... 17
3.2.3. Unauthorized Access .................................................................................................................. 18
3.2.4. Repudiation ................................................................................................................................ 19
3.2.5. Eavesdropping ........................................................................................................................... 20
3.2.6. Alteration ................................................................................................................................... 20
3.2.7. Copy and Replay ........................................................................................................................ 21
CHAPTER 4 SURVEY OF COUNTERMEASURES FOR PROTECTION OF MOBILE AGENT
SYSTEMS .................................................................................................................................................. 23
4.1 COUNTERMEASURES OVERVIEW ........................................................................................................ 23
4.2 AGENT PROTECTION ........................................................................................................................... 24
4.2.1 Partial Result Encapsulation ...................................................................................................... 25
4.2.2 Environmental Key Generation .................................................................................................. 26
4.2.3 Code Obfuscation........................................................................................................................ 27
4.2.4 Cryptographic Functions ............................................................................................................ 28
4.2.5 Execution Traces......................................................................................................................... 31
4.2.6 Itinerary Protection .................................................................................................................... 33
4.2.7 Time Techniques ......................................................................................................................... 35
4.3 PLATFORM PROTECTION ..................................................................................................................... 36
4.3.1 Agent Authentication ................................................................................................................... 36
4.3.2 Path Histories ............................................................................................................................. 39
4.3.3 State Appraisal ............................................................................................................................ 41
4.3.4 Resource Protection .................................................................................................................... 42
4.3.5 Fault Isolation or Sandboxing .................................................................................................... 43
4.3.6 Safe Interpretation and Padded Cells ......................................................................................... 45
4.3.7 Proof Carrying Codes ................................................................................................................. 46
4.3.8 Payment-based Techniques ......................................................................................................... 47
4.4 NETWORK PROTECTION ...................................................................................................................... 48
4.4.1 Secure Sockets............................................................................................................................. 48
4.4.2 Firewalling.................................................................................................................................. 49
4.4.3 Tamper-Resistant Hardware ....................................................................................................... 50
4.5 EVALUATION ...................................................................................................................................... 50
vii
CHAPTER 5 MOBILE AGENTS SYSTEMS AND THEIR SECURITY: STATE-OF-THE-ART . 53

5.1 MOBILE AGENT SYSTEMS OVERVIEW ................................................................................................ 53
5.2 TELESCRIPT ........................................................................................................................................ 54
5.2.1 General Architecture .................................................................................................................. 55
5.2.2 Security in Telescript .................................................................................................................. 57
5.2.3 Comments on the Telescript Security Model ............................................................................... 62
5.3 AGENTTCL AND D’AGENTS ............................................................................................................... 63
5.3.2 Security in Agent Tcl and D’Agents ............................................................................................ 65
5.3.3 Comments on the Security of Agent Tcl and D’Agents ............................................................... 69
5.4 ARA .................................................................................................................................................... 71
5.4.2 Security in Ara ............................................................................................................................ 73
5.4.3 Comments on the Security of Ara ................................................................................................ 75
5.5 TACOMA ............................................................................................................................................. 76
5.5.2 Security in Tacoma ..................................................................................................................... 78
5.5.3 Comments on the Security of Tacoma ......................................................................................... 79
5.6. AJANTA ............................................................................................................................................. 81
5.6.2 Security in Ajanta ........................................................................................................................ 84
5.6.3 Comments on the Security of Ajanta ........................................................................................... 88
5.7 AGLETS .............................................................................................................................................. 89
5.7.2 Security in Aglets ........................................................................................................................ 91
5.7.3 Comments on the Security of Aglets ............................................................................................ 93
5.8 CONCORDIA ........................................................................................................................................ 93
5.8.2 Security in Concordia ................................................................................................................. 96
5.8.3 Comments on the security of Concordia ..................................................................................... 97
5.9 GRASSHOPPER .................................................................................................................................... 98
5.9.2 Security in Grasshopper............................................................................................................ 100
5.9.3 Comments on the Security of Grasshopper ............................................................................... 101
5.10 MOLE ............................................................................................................................................. 101
5.10.1 General Architecture .............................................................................................................. 102
5.10.2 Security in Mole ...................................................................................................................... 103
5.10.3 Comments on the Security of Mole.......................................................................................... 104
5.11 MAS SECURITY EVALUATION ........................................................................................................ 105
CHAPTER 6 MOBILE AGENT SECURITY FRAMEWORK.......................................................... 107
6.1 FRAMEWORK OVERVIEW .................................................................................................................. 107
6.2 FRAMEWORK ASSUMPTIONS............................................................................................................. 109
6.3 THE HOST ......................................................................................................................................... 110
6.3.1 Agent Creator ........................................................................................................................... 111
6.3.2 Agent Dock ................................................................................................................................ 112
6.4 MOBILE AGENT ................................................................................................................................ 112
6.4.1 Code and Data .......................................................................................................................... 113
6.4.2 Itinerary .................................................................................................................................... 114
6.4.3 Credentials ................................................................................................................................ 115
6.4.4 Certificate Vector ...................................................................................................................... 115
6.4.5 Hash List ................................................................................................................................... 115
6.4.6 Encryption Function ................................................................................................................. 116
6.5 CERTIFICATION AUTHORITY ............................................................................................................. 117
6.5.1 Certificate Authorizer ............................................................................................................... 117
6.5.2 Certificate Verifier .................................................................................................................... 118
viii
6.5.3 Key Distribution Centre ............................................................................................................ 118

6.6 AGENT PLATFORM............................................................................................................................ 118
6.6.1 Authenticator ............................................................................................................................ 120
6.6.2 Cryptographic Component ........................................................................................................ 121
6.6.3 Padded Cell............................................................................................................................... 122
6.6.4 Policy Engine ............................................................................................................................ 123
6.6.5 Resource Registry ..................................................................................................................... 124
6.6.6 Domain Database ..................................................................................................................... 124
6.6.7 Resources, Their Access and Proxies........................................................................................ 125
6.6.8 Proxy Manager ......................................................................................................................... 126
6.6.9 Agent Transferer ....................................................................................................................... 126
CHAPTER 7 MOBILE AGENTS SECURITY FRAMEWORK – OPERATION SECURITY
SCENARIOS ........................................................................................................................................... 128
7.1 SCENARIO 1: SPAWNING AGENTS AT THE HOST ................................................................................ 128
7.2 SCENARIO 2: AUTHENTICATING THE AGENT ..................................................................................... 129
7.3 SCENARIO 3: ACCESSING THE MOBILE AGENT BY THE PLATFORM .................................................... 131
7.4 SCENARIO 4: AUTHORIZATING THE MOBILE AGENT .......................................................................... 132
7.5 SCENARIO 5: CHECKING THE MOBILE AGENT’S FUNCTIONALITY BY THE PLATFORM ........................ 134
7.6 SCENARIO 6: ACCESSING AND ALLOCATING RESOURCES ................................................................. 135
7.7 SCENARIO 7: ACCESSING ONLY THROUGH THE ENVIRONMENT ......................................................... 136
7.8 SCENARIO 8: TRANSFERRING AGENTS .............................................................................................. 136
7.9 SCENARIO 9: ASSIGNING AND USING AGENT ID............................................................................... 137
7.10 SCENARIO 10: PROTECTING AGENT COMMUNICATION .................................................................... 138
7.11 SCENARIO 11: TRACING EXECUTION .............................................................................................. 138
7.12 SCENARIO 12: SIGNING COMPUTED CODE HASHES ........................................................................ 139
7.13 SCENARIO 13: PROTECTING THE ITINERARY ................................................................................... 139
7.14 SCENARIO 14: RECEIVING AGENTS AT THE HOST ........................................................................... 140
CHAPTER 8 IMPLEMENTATION ..................................................................................................... 142
8.1 IMPLEMENTATION OVERVIEW .......................................................................................................... 142
8.2 MOBILE AGENTS .............................................................................................................................. 143
8.3 HOST ................................................................................................................................................ 147
8.4 AGENT PLATFORM............................................................................................................................ 148
CHAPTER 9 EVALUATION OF THE PROPOSED FRAMEWORK ............................................. 153
9.1 FRAMEWORK EVALUATION .............................................................................................................. 153
9.2 SECURITY COMPARISON WITH STATE-OF-THE-ART MAS ................................................................ 156
9.3 STRENGTHS AND WEAKNESSES OF THE PROPOSED SECURITY FRAMEWORK .................................... 158
9.3.1 Strengths ................................................................................................................................... 158
9.3.2 Limitations ................................................................................................................................ 159
CHAPTER 10 CONCLUSIONS & FUTURE WORK ........................................................................ 161
REFERENCES ........................................................................................................................................ 164
ix
List of Figures
FIGURE 3.1: A SIMPLE MOBILE AGENT SYSTEM .......................................................................................... 16

FIGURE 5.1: TELESCRIPT PARTIAL ARCHITECTURE (ADAPTED FROM (BAUMER, BREUGST, CHOY &
MAGEDANZ, 1999)) .............................................................................................................................. 57
FIGURE 5.2: D’AGENTS ARCHITECTURE (GRAY, CYBENKO, KOTZ & RUS, 2001) ....................................... 64
FIGURE 5.3: AGENT TCL (MAGNIFIED) (ADAPTED FROM (GRAY, 1996)) ..................................................... 65
FIGURE 5.4: D’AGENTS SECURITY MODEL .................................................................................................. 69
FIGURE 5.5: ARA PLATFORM ARCHITECTURE .............................................................................................. 73
FIGURE 5.6: TACOMA ARCHITECTURE (JOHANSEN ET AL., 2001)................................................................. 78
FIGURE 5.7: AJANTA ARCHITECTURE (TRIPATHI, KARNIK, VORA, AHMED & SINGH, 1999) ....................... 82
FIGURE 5.8: AGLETS ARCHITECTURE (KARJOTH, LANGE & OSHIMA, 1997)................................................ 90
FIGURE 5.9: CONCORDIA SYSTEM ARCHITECTURE (WONG ET AL., 1997) .................................................... 95
FIGURE 5.10: THE GRASSHOPPER DISTRIBUTED AGENT ENVIRONMENT (BAUMER, BREUGST, CHOY &
MAGEDANZ, 1999) ............................................................................................................................... 99
FIGURE 5.11: MOLE ARCHITECTURE (BAUMANN, HOHL, ROTHERMEL & STRABER, 1998) ....................... 102
FIGURE 6.1: MAS FRAMEWORK OVERVIEW ............................................................................................... 109
FIGURE 6.2: HOST ...................................................................................................................................... 111
FIGURE 6.3: MOBILE AGENT AND ITS COMPONENTS .................................................................................. 113
FIGURE 6.4: ITINERARY ............................................................................................................................. 114
FIGURE 6.5: CERTIFICATE VECTOR ............................................................................................................ 115
FIGURE 6.6: HASH LIST.............................................................................................................................. 116
FIGURE 6.7: CERTIFICATION AUTHORITY .................................................................................................. 117
FIGURE 6.8: AGENT PLATFORM AND ITS COMPONENTS .............................................................................. 119
FIGURE 6.9: AUTHENTICATOR ................................................................................................................... 121
FIGURE 6.10: AGENT RIGHTS ALLOCATION PROCESS (POLICY APPLICATION) ............................................ 123
FIGURE 6.11: RESOURCE BINDING VIA PROXIES ......................................................................................... 125
FIGURE 6.12: AGENT COMMUNICATION .................................................................................................... 126
FIGURE 7.1: AGENT CREATION PROCESS ................................................................................................... 129
FIGURE 7.2: AUTHENTICATION PROCESS .................................................................................................... 130
FIGURE 7.3: AGENT DECRYPTION – CRYPTOGRAPHIC COMPONENT PROCESS ........................................... 132
FIGURE 7.4: AUTHORIZATION PROCESS – RIGHTS ALLOCATION ................................................................ 133
FIGURE 7.5: PROXY USAGE ........................................................................................................................ 136
FIGURE 7.6: AGENT TRANSMISSION PROCESS ............................................................................................ 137
FIGURE 7.7: AGENT INTERACTION ............................................................................................................. 138
FIGURE 7.8: RECEIVE PROCESS AT HOST ................................................................................................... 141
FIGURE 8.1: MOBILE AGENT INTERFACE ................................................................................................... 144
FIGURE 8.2: MOBILE AGENT ACCESSOR INTERFACE.................................................................................. 145
FIGURE 8.3: MOBILE AGENT CLASS ........................................................................................................... 145
FIGURE 8.4: CREDENTIALS ......................................................................................................................... 145
FIGURE 8.5: HASH LIST.............................................................................................................................. 146
FIGURE 8.6: CERTIFICATE VECTOR ............................................................................................................ 146
FIGURE 8.7: AGENT CREATOR ................................................................................................................... 147
FIGURE 8.8: AUTHENTICATION .................................................................................................................. 149
FIGURE 8.9: TESTING THE AGENT IN THE PADDED CELL............................................................................ 149
FIGURE 8.10: POLICY ENGINE POLICY RETRIEVAL ..................................................................................... 150
FIGURE 8.11: POLICY ................................................................................................................................. 150
FIGURE 8.12: ACCESS CONTROL LIST (ACL)............................................................................................. 150
FIGURE 8.13: RESOURCE INTERFACE ......................................................................................................... 151
FIGURE 8.14 RESOURCE IMPLEMENTATION ................................................................................................ 151
FIGURE 8.15 RESOURCE PROXY DELEGATION ............................................................................................ 151
FIGURE 8.16: AGENT TRANSFERER SEQUENCE .......................................................................................... 152
x
List of Tables
TABLE 4.1: PROTECTION OF THE MOBILE AGENTS ...................................................................................... 51

TABLE 4.2: PROTECTION OF THE AGENT PLATFORM .................................................................................... 52
TABLE 4.3: PROTECTION OF THE MAS NETWORK ....................................................................................... 52
TABLE 5.1: MOBILE AGENT SYSTEM SECURITY EVALUATION – MOBILE AGENT PROTECTION ................. 105
TABLE 5.2: MOBILE AGENT SYSTEM SECURITY – PROTECTION OF THE AGENT PLATFORM ....................... 106
TABLE 9.1: EVALUATION OF THE PROPOSED FRAMEWORK ........................................................................ 154
Chapter 1
Introduction
Software systems have advanced immensely with the technology march with special
regard to expansion of systems over a distributed concept. Various approaches for
development of software systems especially distributed systems have come into
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
representatives for cyber-users.
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
network is insecure and liable to attacks in its route.
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
accommodates the protected resource use by the visiting mobile agent.
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
framework. Chapter 8 describes the implementation issues of our proposed system.
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
Mobile Agent Systems
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
mobile agent systems in general.
2.1 Remote Code Execution
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
Evaluation (Lange, 1998; Rothermel & Schwehm, 1998).
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
where as the second is code-on-demand.
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
(Rothermel and Schwehm, 1998).
2.2 Software Agents
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
which perspective we are elucidating its nature. Generally, an agent is a representative
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
reactive, autonomous, goal-driven, continuous, communicative, mobile, learning and
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
agent is basically an object possesses all of the aforementioned characteristics.
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.
2.3 Mobile 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
out its tasks (Lange, 1998).
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
agent systems implement the features differently.
(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.
2.4 Mobile Agent Benefits
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
locally reduces the network load.
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
actually sent there and the wait time is reduced.
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
upgrade according to the specification of the communication required.
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
server, executes and the device collects the agent later.
5) Dynamism is enhanced as the mobile agents can be adapted according to the
environment that is given to them.
6) Heterogeneity is provided because the underlying specification is independent to the
mobile agent allowing better integration of heterogeneous systems and environments.
8
7) Robustness is achieved because dynamism allows agents to be configurable as the
environment suggests, this also makes them fault-tolerant if required.
2.4.1 Mobile Agent Applications
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
next-generation telecommunication networks (Pham & Karamouch, 1998).
2.4.1.2 Network Management
Mobile agents can be used to evolve current client/ server based network management
approaches to a more distributed approach (Pham & Karamouch, 1998).
2.4.1.3 Information Retrieval
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
have a broad research potential (Kotz, Gray & Rus, 2002).
2.5 Mobile Agents Limitations
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.
2) There is a lack of a systematic approach to design a mobile agent, making it difficult
to develop.
10
3) Implementing agents is also hard work as so many unpredictable interactions are
present in its journey to so many places consisting of adverse environments.
4) The testing and debugging of such systems are extremely complex. This is due to the
fact that the approaches become so unpredictable.
5) Authentication can be based on so many things the agent is associated with. For this
the authentication mechanism may be weak.
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
either. The information can be leaked on its way.
8) A mobile agent requires a setup or an infrastructure to actually perform. A system that
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.
2.5.1 Mobile agent security
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
promise (Li, Zhang, Sun & Yin, 2004).
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,
corrupt it or even use it for its malicious purpose.
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
Mobile Agent Systems Security
- 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.
3.1 Overview of MAS Security Threats
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
threat that they countermeasure.
13
The threat model has been derived from the various papers discussing the
countermeasures to the threats. However, (McDonald, Yasinsac & Thompson, 2005)
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
network not present in (McDonald, Yasinsac & Thompson, 2005).
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 Platform and environment
• Malicious Agent
• Malicious Networks
3.1.1 Malicious Platform
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,
1996b; Kun, Xin & Dayou, 1999).
Similar to this, other agents may harm the incoming agent(s) and so may the
environment (Kun, Xin & Dayou, 1999).
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
resources (Kun, Xin & Dayou, 1999).
3.1.3 Malicious Network
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
supposes that the network being considered is secure.
3.2 The MAS Threat Model
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,
Hamza & Solimon, 2000).
Figure 3.1: A Simple Mobile Agent System
3.2.1. Masquerading
Masquerading involves: 1) an agent pretending to be another, 2) an agent platform to be
another, 3) the platform’s services to be pretending to be an agent.
Agent to Platform
An agent may be bluffing an agent platform to be another agent maybe to gain
unauthorized access or to prove another agent wrong in case of access so that the agent it
is posing to be is blocked (Jansen & Karygiannis, 1998).
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 to platform
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.
3.2.2. Denial- of-Service
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
other services on the platform.
Agents to Platform
Mobile agents start consuming resources during execution, so the other agents trying to
acquire those resources are blocked.
17
Agent to Agent
Also an agent may block another agent by overloading it with messages or into an
infinite conversation loop.
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
the agent (Jansen & Karygiannis, 1998).
Other Services to Platform
Other services on the platform may also deny the platform its service like the underlying
operating system or even communication services for the agent.
3.2.3. Unauthorized Access
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
execution by access of its public methods.
Platform to Agent
The agent platform may access the agent and hinder the say it executes.
Other services to platform
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
the platform corrupting its environment.
3.2.4. Repudiation
This type of threat appears when an agent completes an execution and denies that it ever
occurred (Jansen & Karygiannis, 1998).
Agent to Platform and Agent to Agent
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
agent never came.
3.2.5. Eavesdropping
During any communication, it can be overheard and misused by others.
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
the agent was sent by the spawning host.
Platform to Agent and Agent to Agent
In the case of mobile agents, the platform and the agents may be eavesdropping on
agents executing on the system for their data.
3.2.6. Alteration
Alteration is when something in the entire system is changed maliciously (Beirman &
Cloete, 2002). This threat is again twofold.
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
the other agents running on the agent platform.
3.2.7. Copy and Replay
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
the other services on the platforms as well.
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
for Protection of Mobile Agent
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.
4.1 Countermeasures Overview
Mobile Agent Systems are prone to numerous threats from attackers over the network.
An agent is created, executed, allowed resource access, migrates, and communicates
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
not doable according to theory (Farmer, Guttman & Swarup, 1996b).
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,
Yasinac, Thompson, 2005). Also, an evaluation of the presented techniques is done at
the end which was not in the other surveys.
4.2 Agent Protection
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
a survey of the work on the agent protection.
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
are generated (Tschudin, 1999).
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.
For this data it uses a simple encryption scheme.
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
purposes; hence generally the data is not alterable.
However, if the key distribution mechanism is weak, a malicious platform may
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
results encapsulation. Similarly, since no history is maintained, repudiation cannot be
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
encapsulated data, so it partially protects the agent.
4.2.2 Environmental Key Generation
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
Environmental key generation involves a set of environmental conditions to be true to
allow the platform to access the mobile agent. Thus, a key is generated based on certain
environmental conditions. This technique safeguards against masquerading of a platform
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
maintained, repudiation attacks are prevalent.
4.2.3 Code Obfuscation
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
as obfuscated code techniques by Jansen in (Jansen, 1998b) (Jansen & Karygiannis,
1998) by Beirman et al in (Beirman & Cloete, 2002) and by Bellavista et al. in
(Bellavista, Corradi, Federici, Montanari & Tibaldi, 2003).
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
invalid and the access becomes possible.
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
provide a meaningful executable for of the scrambled code. It protects against an
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.
Unauthorized access is possible if the platform is intelligent enough to derive a meaning
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.
4.2.4 Cryptographic Functions
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
interpretable but not understandable to the platform.
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 &
Tschudin, 1997a; Sander & Tschudin, 1997b).
(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
a mechanism for the platform to interact with the agent.
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
used to execute the agent.
Another cryptographic technique is presented in (Dadon-Elichai, 2004) which use keys
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
behavior. If it is opened and tampered with, a replica is always present to commence
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
whether or not the platform can execute the agent or not.
(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
communication of information. The MANSION framework (Noordende, Brazier &
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-
only depending on the type of execution required from it on the platform.
30
Analysis
Cryptographic functions are a strong technique to protect an agent from masquerading
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
invalid after a particular transaction or a given period of time.
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
is maintained meaning that repudiation attacks may be prevalent on the system.
4.2.5 Execution Traces
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
locate security breaches.
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
from an agent’s journey.
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,
such a platform can be blocked by the host in future journey creation.
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
thus be used by to determine what sort of protection is necessary.
(Vogler, Kunkelmann & Moschgath, 1997) protects an agent by a primitive logging
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
the platforms actions towards the agent.
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
attacks can be detected from the log as well.
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
information for malicious purpose, it is not logged.
4.2.6 Itinerary Protection
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
protocol for itinerary protection.
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
communication between them.
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
platform) and where it is going (destination platform).
Analysis
An agent is protected from a masquerading platform because a platform that cannot be
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
threats may prevail.
4.2.7 Time Techniques
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
on to the next platform.
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
alter it or copy it.
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.
4.3 Platform Protection
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
section surveys the various countermeasures to protect the agent platform.
4.3.1 Agent Authentication
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.
The implementation specified in (Berkovits, Guttman & Swarup, 1998) is specialized by
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
other execution information for the agent to the platform.
In (Jansen, 2001), Jansen provides a mechanism to determine mobile agent privileges by
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
agent proves itself from the registered certificate.
(Tan & Moreau, 2002) presents a framework for authenticating mobile agents using a
mechanism based on certificates. An agent is granted a certificate that is in turn verified
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.
Authentication in an agent is also present in the MANSION framework (Noordende,
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
to identify the agent through its passport.
(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
implementation of the signature scheme using certificates.
(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
of the system for the agent.
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
require an authorization mechanism to access the resources. Otherwise, an authenticated
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.
In an effort to protect mobile agents and to provide performance as well as security
through authentication in an MAS, (Ng, 2000) provides a mechanism of assigning group
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
only the agent group needs to be authenticated.
4.3.2 Path Histories
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
provided service to the agent, the agent can be rejected.
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
be malicious, the agent can be restricted.
(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
platform for copy and reply attacks.
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
access would be restricted or completely refused, as defined by the policy of the
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
appraisal is closely associated with authorization of an agent. The work in (Farmer,
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
State appraisal protects a platform from an agent masquerading as the appraisal
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
maintained, hence providing history to some extent.
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
Resource protection is a very important security consideration of all distributed systems.
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
privileges or to use safe padded cells for access to resources.
Karnik in his dissertation (Karnik, 1998) uses the same technique for resource
protection, using proxies for each agent reference to a 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
resource as the agent platform permits.
(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 from unauthorized access by an agent. This is because the resource is
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
prevent repudiation depending on what proof of interaction is being logged. An agent
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.
4.3.5 Fault Isolation or Sandboxing
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
tailored to belong with the area allocated to the agent.
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
because it is constricted to a narrow area of memory for execution. Similarly, an agent
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
assigned a classloader instance to interact with the platform.
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
checking that creates a kind of sandbox security.
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
padded cell and hence lower the threat.
Masquerading cannot be prevented in a padded cell; there is no way of finding out
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
corrupt agents (Moore, 1998).
(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
because the agent is not tracked.
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
exchanged by the agent and the platform service.
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
privilege to malicious advantage.
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).
4.4.1 Secure Sockets
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
agents between the host socket and the platform socket.
(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
and replay attacks from the outside can be prevented.
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
will be permitted over and over again.
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
link has a leak in it that may be accessible by an attacker.
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
objects maintain surveillance over the link. Eavesdropping is prevented as there is no
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
within the system through faults in the components of the system.
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
whether the approach over comes the particular threat(s).
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
protect the network
Table 4.1: Protection of the Mobile Agents
Masquerading DOS Unauthorized Repudiation Eavesdropping Alteration Copy

Access and
Replay
Partial Result Partial No Partial No Yes Partial No

Encapsulation
Environmental Yes No Yes No Yes Yes Yes
Key
Generation
Code Yes No Partial No Yes Partial Yes

Obfuscation
Cryptographic Yes No Yes No Yes Yes Yes
Functions
Execution Partial Yes Yes Yes No Yes Yes
Traces
Itinerary Yes Yes Yes Yes Partial Partial Partial
Protection
Time-based No Yes Partial No Partial Partial Partial

Techniques
51
Table 4.2: Protection of the Agent Platform

Access and
Replay
Agent Yes No Partial Partial No No No

Authentication
Path Histories Yes Partial Yes Yes No No No
State Yes Yes Yes Partial No No No
Appraisal
Resource No Yes Yes Partial Yes Yes Yes
Protection
(Proxies and
Wrappers)
Fault Isolation Partial Partial Yes No Partial Partial Partial
or Sandboxing
Safe No Partial Yes No Yes Yes Partial
Interpretation
and Padded
Cells
Proof Yes No Partial No No No No
Carrying
Codes
Payment- Partial Yes Yes Partial Partial Partial Partial
based
Techniques
Table 4.3: Protection of the MAS Network

Access and
Replay
Secure Yes No Partial No Yes Yes Yes

Sockets
Firewalling Yes No Partial Partial Yes Yes No
Tamper- Yes No Yes No Yes Partial No
Resistant
Hardware
52
Chapter 5
Mobile Agents Systems and
their Security: State-of-the-Art
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
according to the countermeasures from Chapter 4.
5.1 Mobile Agent Systems Overview
The research of mobile agents is growing immensely in directions of its use for
evolutionary distributed systems. Their operation and functionality is based on a mobile
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
based upon the differences in feature and construction of the MAS.
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
substantial amount of security and their use in the research work.
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-
tolerant MAS of all-time.
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.
5.2.1 General Architecture
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
instruction, i.e. the agent’s migration.
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
is destroyed (Baumer, Breugst, Choy & Magedanz, 1999).
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
embeds itself onto that place and starts its execution.
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
be a seller if the visiting agent is a buyer.
56
Figure 5.1: Telescript Partial Architecture (Adapted from (Baumer, Breugst, Choy &
Magedanz, 1999))
5.2.2 Security in Telescript
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:
Object Runtime Safety
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
the classes and their bindings (Tardo & Valente, 1996).
Process Safety and Security
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
model protects this through (Tardo & Valente, 1996):
• 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
authority the agent is authenticated and assigned an authorization level accordingly.
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
inherited in all the instances of the class.
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
can spawn other processes or agents. In Telescript, permit violation results in an
exception and hence a termination of execution in some cases.
There are four types of permits in Telescript:
1. Native: By a process creator
2. Regional: By engine on agent entering process or a new created process
3. Local: By a place when an agent enters or a new process is created
4. Temporary: Placed in the code
• Entering and Meeting
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
move to other destinations. The purgatory has a non-executable environment meaning
that the agent cannot exercise its operations.
• Security Mix-ins
These are special classes that cannot be instantiated but can be inherited. If an agent tries
to move an object, copy an object or modify an object an exception is thrown. This
results in a copyrighted form of object instantiation through its policy control.
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
channels to avoid hacking (Tardo & Valente, 1996).
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.
A secure channel is maintained upon negotiation between regions. Here it is necessary
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):
Identification: Authority information is exchanged between the regions.
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
and from here on the information are retained.
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
is faster than public key operations for registration.
Re-Key: This is used when the key has been lost or a key expires in DES otherwise it is
completely like registration.
61
Authentication: This is similar to fast authentication but it shares an RC4 key using
Diffie-Hellman for complete secrecy while sending information.
5.2.3 Comments on the Telescript Security Model
Telescript though sound in terms of safety and security it still has its weaknesses and
limitations. These are mainly (Tardo & Valente, 1996):
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
Telescript model covers are numerous but are not complete.
3) The engine doesn’t completely enforce the access control policies, like for resources
and for access to places.
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
security according to the threats that may arise on the MAS.
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
reporting of all running agents.
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))
5.3.2 Security in Agent Tcl and D’Agents
D’Agents security is progressing with their versions and accommodations of different
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).
Protection of the machine
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
completely deny it.
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.
The access implementations vary by placing different resource manager
implementations, according to security policy. For this, D’Agents currently keeps a
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
simple read access to certain global or public information.
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
and if it is unsafe an exception is raised or an alternative course of action performed.
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
ever. Here there are two types of groups:
1) Single administration
2) No single administration
In a single administration domain, the agent is assigned a maximum resource allowance
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
vector size is not performed on transit.
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.
Protecting the agents
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
sends it on a route it was not destined to follow.
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.
Figure 5.4: D’Agents Security Model
D’Agents is looking into techniques to protect the agent including cryptography of
components and algorithms, path histories, execution traces and state appraisal (Gray,
Kotz, Cybenko & Rus, 1998).
5.3.3 Comments on the Security of Agent Tcl and D’Agents
D’Agents uses a discretionary approach to its security meaning that it uses an access list
instead of a mandatory mechanism where classification is maintained or a state based
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
execution and the agent is malicious if the executions do not match.
The weaknesses of the D’Agents security are:
1) No protection of agents as yet.
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
agent that travels one by one to other platforms.
4) Replay attacks are still apparent on the D’Agents.
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
as a project at the University of Kaiserslautern. The platform it supports interpreted
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
(Peine & Stolpmann, 1997).
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
the same, but obviously the interpreter has to be extended.
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
to resources and with other agents is not stored however.
Another Ara feature is its communication feature (Peine & Stolpmann, 1997). This
communication is the multi-agent processing on the platform meaning that agents
together execute to complete a designation by collaborating, coordinating and interacting
with one another. This requires the agents to communicate with each other. For this Ara
provides special communication meeting points where the agent commutes in a
client/server style with another agent.
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.
The architecture looks like that in Figure 5.5.
72
Figure 5.5: Ara Platform Architecture
5.4.2 Security in Ara
In Ara, the security levels defined are in terms of agent authentication and the right
association of an agent on the platform (Peine, 1998). Secondly, due to this
authentication, an agent is associated with access rights or the authorization of resource
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
spawned. This looks some what like:
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
execution. Here, an agent is thus a part of a region and it authenticated once by a
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
visits. The local allowance cannot exceed the global allowance.
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).
5.4.3 Comments on the Security of Ara
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.
Sadly, however, Ara has its weaknesses. These are:
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
doesn’t provide a means for this.
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
servers of heterogeneous nature is not mentioned.
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
hidden behind a wrapper or a proxy.
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
security in the Tacoma project for later versions.
76
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,
Marzullo & Lauvset, 1999).
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
briefcases for communication (Johansen, Renesse, Schneider & 1995).
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
Tacoma architecture (Johansen, Renesse, Schneider & 1995).
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
language agents. These commute through the firewall shown.
Figure 5.6: Tacoma Architecture (Johansen et al., 2001)
5.5.2 Security in Tacoma
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
added in by the programmer.
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
this is not prevalent in all its versions.
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
platform cannot be used maliciously (Sudmann, 1998).
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
the implementation are not yet complete (Sudmann, 1998).
5.5.3 Comments on the Security of Tacoma
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.
3) Agent briefcase exchange with a malicious agent is not protected.
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.
5) Protection of agent’s data is not provided, like its itinerary.
6) Agents can be cloned instead of copied, and Tacoma does not in anyway protect this.
7) Agent encapsulation is present but no particular scheme to encapsulate result data is
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
features of mobile agent security, fault-tolerance, communication, agent migration
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
agent transferer. This is all collaborated by the agent environment.
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,
Karnik, Vora, Ahmed & Singh, 1999).
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
then delegated according to the policy on the server.
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 namespaces of other services and agents can be tampered with.
Agent Server Protection
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
run in any other thread than the one allotted to it.
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
dynamically during the execution.
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
credentials and is passed on to the agent through the environment.
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
copied, stolen, and impersonated and so on.
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
this is not replaceable by a tampering server with readable data.
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
checks the checksum. If the checksum is valid, the agent is accepted.
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
decrypted by the server that has the key to the object.
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
mismatch, the agent has been tampered with.
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
by the server itself.
5.6.3 Comments on the Security of Ajanta
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
security considerations like authentication, policy implementation, mobility security and
resource access security (Karjoth, Lange & Oshima, 1997).
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
messages coming from other agents.
Figure 5.8: Aglets Architecture (Karjoth, Lange & Oshima, 1997)
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
handling mechanism that is customizable by programmers.
An agent is created and assigned an identifier to distinguish it (Karjoth, Lange &
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
(Karjoth, Lange & Oshima, 1997).
Authentication
Aglets has a concept of principals that contains the following information (Karjoth,
Lange & Oshima, 1997):
• aglet’s manufacturer
• context
• context’s manufacturer
• context’s master (administrator, owner or operator)
• domain (group of contexts)
• 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
as they are accessible.
3) Aglet agent can spoof the system to obtain values from the user and sent them back to
the host.
4) The Aglet language is very costly to use and interpret.
5) An aglet’s internal state is not protected and can be tampered with and even simply
accessed for spying or eavesdropping.
5.8 Concordia
Concordia infrastructure was developed by Mitsubishi Electric and is another Java-based
MAS. Thus, it supports mobile agents implemented in Java. The Concordia
infrastructure has support for highly mobile agent execution and also for their
development. It supports agent collaboration, persistence of agent state, reliable agent
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.
Figure 5.9 shows the architecture in terms of the interaction of components in
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.
Agent interactions are either asynchronous events or agent collaborations. The
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
to maintain its connections with the agents (Wong et al., 1997).
The Persistence store manager is implemented through Java serialization. This
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
servers for reliable transmission of the agents over the network.
5.8.2 Security in Concordia
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
agents (Wong et al., 1997).
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
used (Wong et al., 1997).
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
dynamically as required by the server. The Administration manager in Concordia starts
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).
5.8.3 Comments on the security of Concordia
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
weaknesses and limitations in Concordia’s security model are as follows:
1) Agent communications and collaborations can be spied on by simply registering itself
to the Event manager.
2) Platform may be threatened by masquerading agents as the authenticity of the agent is
not assured.
3) Queue manager may be corrupt and may make the agent suffer from DOS attack.
4) Agents may threaten the administration server as direct access is possible.
5) Itinerary is not protected.
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
by GMD FOKUS and IKV++ GmbH in Germany. Grasshopper was developed to be
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 &
Magedanz, 1999). Grasshopper is developed to allow the creation of simple agent-based
systems to a more complex multi-agent system. Grasshopper agents can thus
communicate and interact in both a transparent and interactive means with multiple
protocol support. Grasshopper is another Java-based MAS.
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
registered to a region. Regions make the distributed components, containing agents,
places and agencies more manageable. This makes up the Grasshopper Distributed
Agent Environment as shown in Figure 5.10.
98
Figure 5.10: The Grasshopper Distributed Agent Environment (Baumer, Breugst, Choy
& Magedanz, 1999)
The Grasshopper core provides communication services so that the distributed
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.
External security in Grasshopper protects remote interactions between the various
components distributed on a network. To protect the communication, symmetric key
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.
Authentication is used by Grasshopper that includes identities associated to the various
components. For this, digital signatures are used to sign the data (Baumer, Breugst,
Choy & Magedanz, 1999).
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
exception is thrown (Baumer, Breugst, Choy & Magedanz, 1999).
100
5.9.3 Comments on the Security of Grasshopper
Grasshopper security, though substantial, is limiting and weak in ways (Fischmeister,
Vigna & Kemmerer, 2001). These are as follows:
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
registry are accessible.
3) Policies can be generated that can alter the launch and the authentication in the
system.
4) Agent communication is still easily spied on by the platform.
5) There is no itinerary in Grasshopper. An agent’s sending information is up to the
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,
Rothermel & Straber, 1998).
Mole has a rather simple architecture and consists of basic components to provide
execution, communication and transfer of mobile agents. Also, it contains resource
management and consumption services to provide control over access and to manage the
platform components (Baumann, Hohl, Rothermel & Straber, 1998). It looks somewhat
like that of Figure 5.11.
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
reinstantiated and the agent is started.
102
Agents can interact with each other through the directory. Each agent is assigned an
Agent ID that allows it to be located on the platform.
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).
5.10.2 Security in Mole
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,
Rothermel & Straber, 1998).
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
different policy settings (Baumann, Hohl, Rothermel & Straber, 1998).
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
management service (Baumann, Hohl, Rothermel & Straber, 1998).
5.10.3 Comments on the Security of Mole
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
agent transport and migration.
4) Logging of resource access is done and not of the agent execution.
104
5) To control access to resources, service agents provide a trusted middleware for their
access.
5.11 MAS Security Evaluation
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
Partial Environme Code Cryptograp Execution Itinerary Time

Result ntal Key Obfuscati hic Traces Protection Technique
Encapsul Generation on Functions s
ation
Telescript Partial No No No Yes No No
AgentTcl/ No No No TBI Yes Partial No

D’Agent
s
Ara Partial No No Yes Partial Yes No
Tacoma Partial No No No Partial Partial No

Ajanta Yes No No No Yes Yes No
Aglets No No No No Yes No No
Concordia Yes No No Yes Yes Yes Yes
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
Agent Path State Resour Fault Safe Proof Money-

Authen Histori Apprai ce Isolation or Interpretatio Carryin based
tication es sal Protecti Sandboxing n and g Codes Techniq
on Padded Cells ues
Telescript Yes No No Yes Partial Partial No No
AgentTcl/ Yes Yes TBI Yes No Yes No TBI

D’Agent
s
Ara Yes No No Partial Yes Yes No Yes
Tacoma Yes No No Yes No No No Yes
Ajanta Yes No No Yes No No No No
Aglets Yes Yes No Yes No No No No
Concordia Yes No No Partial No No No No
Grasshopp Yes No No Yes No No No No

er
Mole Yes No No Partial Yes No No No
106
Chapter 6
Mobile Agent Security
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 essence of security.
6.1 Framework overview
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
system to add security measures.
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
changed by any other component other than the host.
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
returns to its host.
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
6.2 Framework Assumptions
The proposed framework operates based on certain assumptions. The assumptions are
listed and discussed prior to the framework. These are listed as follows:
1) Host and platform discovery is done prior to the security concerns.
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
feature (or set of features) to the system.
3) Tamper-proof hardware exists such that the transmission is not tamper-able by an
external attacker during agent transmission.
109
4) Itinerary is built a-priori. The host knows where the agent is going rather than an
agent discovering its course.
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
time and the actual transmission of the agent.
6.3 The Host
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
disposing the used mobile agents.
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
6.3.1 Agent Creator
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
data to be processed, state data, path data and agent credentials.
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
platforms in its itinerary.
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
mobile agents’ entry into the spawned log is then removed.
The host provides a mobile agent transfer mechanism that implements the protocol for
the deployment of the agent on the network.
6.4 Mobile Agent
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
components are discussed in this section.
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
some of our own necessary information.
Figure 6.3: Mobile Agent and its components
6.4.1 Code and Data
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
is required to perform on the platforms.
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
transfer from its current platform.
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
are considered as an either-or selection.
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.
Figure 6.4: Itinerary
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
agent certificates in (Tan & Moreau, 2002).
6.4.4 Certificate Vector
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
by an agent on that platform. The certificate is digitally signed by the host.
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,
the required resource is listed.
Figure 6.5: Certificate Vector
6.4.5 Hash List
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.
Figure 6.6: Hash List
6.4.6 Encryption Function
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
protected from view by other platforms.
6.5 Certification Authority
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
authorization and verification of the certificate. However, it differs in context and
construction in our case.
Figure 6.7: Certification Authority
6.5.1 Certificate Authorizer
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
Certificate database for later use.
6.5.2 Certificate Verifier
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
requesting server for its verification means.
As shown in Figure 6.7, the verifier checks the certificate in the certificate database.
6.5.3 Key Distribution Centre
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
carry in its itinerary for encryption.
6.6 Agent Platform
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.
Thus, it is provided with security components for this purpose.
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,
databases and so on as well as certain services or other agents on the platform.
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
authorization process of our proposed secure mobile agent platform.
Figure 6.8: Agent Platform and its components
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
public key of the creator of the agent.
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
platforms of the mobile agent’s journey.
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
agent for authentication as well.
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.
Figure 6.9: Authenticator
6.6.2 Cryptographic Component
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
gives a partial authentication for the agent.
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.
The cryptographic component is in league with various cryptographic approaches
covered in the survey of countermeasures. It has resemblance mainly with the approach
by (Algesheimer, Cachin, Camenisch & Karjoth, 2001) and its improved version in
(Tate & Xu, 2003).
6.6.3 Padded Cell
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
kind of commands it makes to the padded cell for resources.
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
access control list generated accordingly.
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.
Figure 6.10: Agent rights allocation process (Policy application)
6.6.4 Policy Engine
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
compared with the command trace from the padded cell.
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
policy will exist for the agent.
6.6.5 Resource Registry
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
request is re-issued by an agent that requires the resource for execution.
In Figure 6.10, the resource has to register itself in the resource registry to have a policy
generated for it by the policy engine.
6.6.6 Domain Database
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.
Each of these entries is against each 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
the domain database of the platform.
6.6.7 Resources, Their Access and Proxies
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
interface is an image of the resource. The proxy is such an interface specially
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
shown in Figure 6.11.
Figure 6.11: Resource binding via proxies
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
implementation. This is shown in Figure 6.12.
Figure 6.12: Agent Communication
6.6.8 Proxy Manager
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.
6.6.9 Agent Transferer
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
then goes to the next platform as shown in Figure 6.8.
Summing up the security framework, the complete view of all the components plugged
together looks like figure 6.13.
Figure 6.13: Secure Mobile Agent Framework
127
Chapter 7
Mobile Agents Security
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.
7.1 Scenario 1: Spawning Agents at the host
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,
the private and the primary key of the host.
An agent that is created is then placed into the agent transferer where the transferer sets
up a secure connection with the destination platform.
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
allotting an agent a timestamp.
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
mobile agent’s itinerary.
Figure 7.1: Agent Creation Process
7.2 Scenario 2: Authenticating the agent
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
the signature is valid and the code is authenticated.
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
platform and for checking for tampering with an agent.
Figure 7.2: Authentication process
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
framework. Here, the mobile agent’s code and data is decrypted.
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 maliciously.
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
will be of weak mobility as execution commencement has to be implicit in the agent
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.
Figure 7.3: Agent Decryption – Cryptographic Component Process
7.4 Scenario 4: Authorizating the mobile agent
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
the mobile agent.
This process is detailed in Figure 7.4.
Figure 7.4: Authorization Process – Rights allocation
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
bind with each resource.
7.5 Scenario 5: Checking the mobile agent’s functionality by the
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
execute the agent. It instead provides pseudo-resources (“dummy” resources) to check
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.
7.6 Scenario 6: Accessing and Allocating Resources
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-
only implementation thus protecting DOS attacks on the platform.
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
controlled by the environment. If there is a race condition and an agent is blocking a
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
actions in the padded cell listed in the resource registry.
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
7.5 shows this interaction.
135
Figure 7.5: Proxy Usage
7.7 Scenario 7: Accessing only through the environment
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.
7.8 Scenario 8: Transferring Agents
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
itinerary. The agent is placed on this channel and transmitted.
136
The process steps that occur during the transmission of the mobile agent in the agent
transferer are shown in Figure 7.6.
Figure 7.6: Agent Transmission Process
7.9 Scenario 9: Assigning and Using Agent ID
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
present on the host, i.e. has returned from its travels.
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
interpret the message exchanges between agents.
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.
Figure 7.7: Agent Interaction
7.11 Scenario 11: Tracing Execution
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
the time the agent arrives till it leaves the platform.
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
one causing the delay can be regarded as malicious.
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
the platform can be regarded as malicious.
7.12 Scenario 12: Signing Computed Code Hashes
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
with the signature of the platform.
Since the platform public key is known, this can be used to check the signed hash value
of the platform.
7.13 Scenario 13: Protecting the Itinerary
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
considered as one so that if one of the alternate platforms is visited
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
path denoted in the itinerary generally can be detected.
7.14 Scenario 14: Receiving Agents at the Host
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
host may consider the agent invalid. However it is processed.
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
checked for possible causes of malicious activity.
140
ID incorrect –
Send to Host’s
Platform
Authenticator Authenticate Decrypt Agent
Authenticated
Mobile Mobile
Agent Agent
Check ID + Agent code

Timestamp Decrypted Form Hosts
Spawned Log
Itinerary Hash
incorrect – Call Check Itinerary Original
trace Hash
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
Figure 7.8: Receive Process at Host
141
Chapter 8
Implementation
This chapter covers the details of the implementation of the proposed security
framework from Chapter 6. The implementation is discussed component by component
and then their subcomponents. This chapter discusses the implementation to implement
the framework as a prototype.
8.1 Implementation Overview
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
that is responsible for certificates delegation, authentication and verification. The
implementation of the security features of this framework are discussed in detail to
describe how the secure mobile agent framework can be implemented.
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
independence of the underlying machine, provision of abstraction to remote
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
implementation language independent and portable.
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.
8.2 Mobile Agents
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
execution from platform to platform. A mobile agent implements a serializable interface
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
has a proxy delegation function.
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
mobile agent interface is shown in Figure 8.1.
interface MobileAgentInterface implements Serializable

{
public void encryptor(PublicKey pubkey, Message message) throws
Exception;
public Vector hashList();
public Vector credentialsVector();
public Vector nextPlatform() throws Exception;
public void go(String URI);
public void signHash();
public void getHostHash();
}
Figure 8.1: Mobile Agent Interface
The mobile agent accessor interface implements the Java serializable interface. This is
shown in Figure 8.2.
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 mobile agent class is shown in Figure 8.3.
class MobileAgent implements MobileAgentAccessor, MobileAgentInterface

{
/*
Agent data and methods as specified by agent programmer
*/
public void agentCreate(){}
public void agentRemove(){}
}
Figure 8.3: Mobile Agent Class
The credentials are placed with the mobile agent in XML. It is shown in Figure 8.4.
<AgentCredentials AgentName = "" AgentID = "">

<AgentVendor>
</AgentVendor>
<AgentRoles>
<Role> 
</Role>
</AgentRoles>
</AgentCredentials>
Figure 8.4: Credentials
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
like Figure 8.6.
<CertificateVector>
<Platform platformName = "" URI ="">
<Certificate>
<AgentRole RoleName = "" State = "">
<ResourceRequired Name = "">
<Access>
</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
subcomponents that support the functionality of the mobile agent host.
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();
MobileAgent agX_impl = factory.initializeAgent();

agX_impl = factory.implement(agent);
agX = agX_impl.assignHash();
Agent agX = factory.create(agentCredentials,

itinerary, certificates);
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
specification of the authentication mechanism, the agent is allowed otherwise
disallowed. This is shown in Figure 8.8.
class Authenticator
{
Vector credentials;
Object host;
Object vendor;
//and other information present about the agent in the Vector

Authentricator(){
Vector credentials = new Vector();
}
public Vector loadAgentCredentials (PlatformID pid, Vector

credentialList){
credentials = parseCredentials(credentialList, pid)
//gain credentials from the Vector for the platform and put
them into their designated places
return credentials;
}
public Object verifyAgent (PublicKey pubKey, PublicKey

pubKeyPrevPlat){
byte checkHash = decrypt(pubKey);
byte previousHash = decrypt(pubKeyPrevPlat);
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
and the decryption is shown in Figure 8.9.
class PaddedCell
{
public Object decryptAgentCode(PrivateKey priKey){
//any decryption algorithm
CryptogrphicComponent crypo = new CryptogrphicComponent();
crypo.decrypt(priKey);
}
public ACL testAgent (Policy policy){

checkPolicy(policy);
//execute agent
}
}
Figure 8.9: Testing the Agent in the Padded Cell
The policy engine is shown in Figure 8.10.
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
The policy looks like Figure 8.11.
<Policy>
<Role> 
<Resource>

</Resource>
</Role>
</Policy>
Figure 8.11: Policy
The ACL looks like Figure 8.12.
<ACL AgentName = “” AgentID = “” AgentRole = “”>

<Resource ResourceID = “”>
<!—Access controllers to define read, write, modify control Æ
</Resource>
</ACL>
Figure 8.12: Access Control List (ACL)
Resource Access is done by implementing a resource according to the Resource
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).
public interface Resource {

// generic methods common to all resources
}
Figure 8.13: Resource Interface
public class ResourceImpl implements Resource {

// implementations of the generic methods
}
Figure 8.14 Resource implementation
public interface ResourceAccessProtocol {

public Resource getProxy (ACL acl)
}
Figure 8.15 Resource Proxy delegation
The agent transferer is like Figure 8.16. The new platform is located in the agent’s
itinerary. If it is not found it throws an exception. To send an agent, it is encrypted; the
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;
}
public void transferSequence(Agent agent) throws

UnknownHostException
{
locateHost(itinerary.next());
Briefcase briefcase = createBriefcase(data);
try{
go(encrypt(agent), briefcase);
}catch (UnknownHostException){
//cater exception
}
}
}
Figure 8.16: Agent Transferer Sequence
152
Chapter 9
Evaluation of the Proposed
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.
9.1 Framework Evaluation
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
protected and by which mechanism.
153
Table 9.1: Evaluation of the Proposed Framework
Threats Malicious Agents Malicious Platforms

Masquerading Yes. Agent IDs and Yes. Authentication and
authentication on platforms. encryption of agents
DOS Partially. Policies, padded cells Partially. Certificates and
and proxies. certificate vectors.
Unauthorized Access Yes. Padded cells, policies and Yes. Encrypted agents and digital
proxies. signatures.
Repudiation Yes. Tracing. Partially. Tracing and Hash lists.
Eavesdropping Yes. Encryption of agents, Yes. Secure channel for
padded cells, policies and communication, encryption and
proxies. proxies.
Alteration Yes. Padded cells, policies and Yes. Code Hashes, Hash Lists
proxies. and Encryption.
Copy and Replay Partially. Proxies. Yes. Agent IDs and agent
encryption.
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
platform, the agent can only be accessed if it is authenticated. Supposing an agent is
permitted, the agent is encrypted and only the real platform with the proper private key
can decrypt the agent.
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
certificates they carry for the services/ resources they require.
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 authorization. Unauthorized access by the platform is protected by encrypting
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
own sharing proxy to protect from eavesdropping.
Alteration by a malicious agent is prevented by giving it no means to cause such a threat.
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
hash list. Any change to this will detect such an attack.
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
difficulty to copying of an agent.
9.2 Security Comparison with State-of-the-Art MAS
The proposed framework is comparable to the MAS in the state-of-the-art in many ways.
The framework implementation in Chapter 8 describes that it is in Java. However, the
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
framework and the MAS in the state-of-the-art.
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.
In comparison to other frameworks, the Telescript security framework (Baumer,
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.
Ara platform in comparison to our proposed framework uses an authentication based on
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
each type of agent that accesses a resource.
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
surveying the access of resources.
Agent protection in Concordia is centralized in an administration manager (Wong et al.,
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.
The access in Grasshopper is like in our framework, it is based on a policy (Baumer,
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
framework. The authentication is very similar as it is based on digital signatures.
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
defined time of accessing a resource.
9.3 Strengths and Weaknesses of the Proposed Security Framework
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
The strengths of the proposed framework in terms of security are:
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
components in language or technology restrictions.
3) The platform has a very strong mechanism to protect the MAS platform resources and
services.
4) The MAS security framework is in itself integratable with other state-of-the-art
systems as a security extension. It thus overcomes the shortcomings of the state-of-the-
art system.
5) The framework is also integratable with other mobile agent system requirements like
fault-tolerance and discovery mechanisms.
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
behaviors in the MAS.
7) Electronic cash based (money-based) techniques can be applied into the framework
for resource consumption control.
9.3.2 Limitations
The limitations of the proposed framework in terms of security are:
1) Copy and replay attacks are not fully prevented in certain cases, like if a malicious
agent copies a message and keeps repeating it.
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
and unaltered for its own gain.
5) There is no way of detecting or preventing during transmission attacks as yet. Thus
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
threats during transmission.
6) Large overheads to provide security are prevalent.
160
Chapter 10
Conclusions & Future Work
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
various security threats in a MAS. A survey and evaluation of various approaches to
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
surveyed and evaluated techniques, a state-of-the-art of some existing mobile agent
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
(Agent-oriented Software Engineering) can be extended to include security measures
through this framework. Certain methods to ensure MAS security can be developed
using this framework.
Research work can be on the construction of a heterogeneous system. The platform in
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
a future extension as well (Gray, 1997).
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
agent interaction protocols.
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
especially the interaction protocols between agents and resources.
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
the creation of security for such systems.
163
References
Abdalla, M., Cirne, W., Franklin, L. and Tabbara, A. (1997). Security Issues in Agent
Based Computing, In the Proceedings of the 15th Brazilian Symposium on
Computer Networks, Sao Carlos, Brazil.
Algesheimer, J., Cachin, C., Camenisch, J. and Karjoth, G. (2001). Cryptographic
Security for Mobile Code, In the Proceedings of the 2001 IEEE Symposium on
Security and Privacy, p. 2 , Oakland, California, USA.
Ametller, J., Robles, S. and Ortega-Ruiz, J. (2004). Self-Protected Mobile Agents, In the
Proceedings of the 3rd International Conference on Autonomous Agents and
Multiagent Systems (AAMAS), ACM Press, pp. 362-367, Madrid, Spain.
Aneiba, A. and Rees, S. (2004). Mobile Agents Technology and Mobility, In the
Proceedings of the 5th Annual Postgraduate Symposium on the Convergence of
Telecommunications, Networks and Broadcasting (PgNet), Liverpool, UK.
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
Netherlands, Stuttgart, Germany.
Baumer, C., Breugst, M., Choy, S. and Magedanz, T. (1999). Grasshopper – A
Universal Agent Platform Based on OMG MASIF and FIPA Standards, In the
Proceedings of the 1st International Workshop on Mobile Agents for
Telecommunication Applications, World Scientific Publications, Ottawa, Canada.
164
Beirman, E. and Cloete, E. (2002). Classification of Malicious Host Threats in Mobile
Agent Computing, In the Proceedings of the 2002 Annual Research Conference of
the South African Institute of Computer Scientists and Information Technologists
on Enablement through Technology, South African Institute for Computer
Scientists and Information Technologists (SAICSIT), pp. 141-148, Port Elizabeth,
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
0-84931-971-4, CRC Press.
Berkovits, S., Guttman, J. and Swarup, V. (1998) Authentication for Mobile Agents,
Mobile Agents and Security, Lecture Note in Computer Science, Volume 1419,
pp.114-136, Springer-Verlag, Berlin, Germany.
Brooks, R. (2004). Mobile Code Paradigms and Security Issues, IEEE Internet
Computing, Volume 8, pp. 54–59.
Chess, D. (1998). Security Issues in Mobile Code Systems, Mobile Agents and Security,
Lecture Notes in Computer Science, Volume 1419, pp. 1-14, Springer-Verlag,
Berlin, Germany.
Condict, M., Milojicic, D., Reynolds and F., Bolinger, D. (1996). Towards a World-
Wide Civilization of Objects, In the Proceedings of the 7th workshop on ACM
SIGOPS European workshop: Systems support for worldwide applications, pp. 25-
32, ACM Press, Connemara, Ireland.
Cubaleska, B. and Schneider, M. (2002). A Method for Protecting Mobile Agents against
Denial of Service Attacks, Cooperative Information Agents VI : 6th International
165
Workshop, CIA 2002, Lecture Notes in Computer Science, Volume 2446, p. 297,
Springer-Verlag, Madrid, Spain.
Dadon-Elichai, A. (2004). RDS: Remote Distributed Scheme for Protecting Mobile
Agents, In the Proceedings of the 3rd International Conference on Autonomous
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
in Mobile Agent Systems, In the Proceedings of the 4th International Workshop on
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
Manipulation Attacks in Mobile Agent Systems, In the Proceedings of the 5th
International Workshop on Mobile Agents for Telecommunication Applications,
Lecture Notes in Computer Science, Volume 3284, p. 224, Spring-Verlag, Berlin,
Germany.
Farmer, W., Guttman, J. and Swarup, V. (1996a). Security for Mobile Agents:
Authentication and State Appraisal, In the Proceedings of the 4th European
Symposium on Research in Computer Security (ESORICS), Lecture Notes in
Computer Science, Volume 1146, pp. 118-130, Springer-Verlag, Berlin, Germany.
Farmer, W., Guttman, J. and Swarup, V. (1996b). Security for Mobile Agents: Issues and
Requirements, In the Proceedings of the 19th National Information Systems
Security Conference, pp. 591-597, Baltimore, MD, USA.
Feng, L., Shan, F. and Ying, W. (2003). An Enhanced Security Model for Mobile Agent
System, In the Proceedings of Intelligent Data Engineering and Automated
166
Learning (IDEAL), Lecture Notes in Computer Science, Volume 2690, pp. 89-93,
Springer-Verlag, Berlin, Germany.
Ferreira, L. and Ricardo, D. (2002). Blinded Key Signatures: Securing Private Keys
Embedded in Mobile Agents, In the Proceedings of the 2002 ACM Symposium on
Applied Computing (SAC), ACM Press, pp. 82-86, Madrid, Spain.
FIPA (2003). The Agent Unified Modeling Language Web Site. Retrieved February 14,
2005, from http://www.auml.org/.
Fischmeister, S., Vigna, G. and Kemmerer, R. (2001). Evaluating the Security of Three
Java-Based Mobile Agent Systems, In the Proceedings of Mobile Agents: 5th
International Conference, Lecture Notes in Computer Science, Volume 2240, p. 31
Springer-Verlag, Atlanta, GA, USA.
Franklin, S. and Graesser, A. (1996). Is it an Agent, or just a Program?: A Taxonomy for
Autonomous Agents, In the Proceedings of the Workshop on Intelligent Agents III,
Agent Theories, Architectures, and Languages, Lecture Notes In Computer
Science, Volume 1193, pp. 21-35, Springer-Verlag, London, UK.
Fu, P. (1999). A Security Architecture for Mobile Agent Systems, Master of Science
Thesis, Tsinghua University, China.
Gray, R. (1996). Agent Tcl: A Flexible and Secure Mobile-Agent System, In the
Proceedings of the USENIX Tcl/Tk Workshop, Monterey, CA, USA.
Gray, R. (1997). Mobile-agent Security, Position Paper, In the Proceedings of the
ECOOP Workshop on Distributed Object Security and 4th Workshop on Mobile
Object Systems: Secure Internet Mobile Computations, pp. 79-80, Brussels,
Belgium.
167
Gray, R., Kotz, D., Cybenko, G. and Rus, D. (1998). D’Agents: Security in a Multiple-
Language Mobile-Agent System, Mobile Agents and Security, Lecture Notes in
Computer Science, Volume 1419, p. 154, Springer-Verlag, Berlin, Germany.
Gray, R., Kotz, D., Cybenko, G. and Rus, D. (2000). Mobile Agents: Motivations and
State-of-the-art Systems, University of Dartmouth, Technical Report, TR2000-365,
Dartmouth College, Hanover, NH, USA.
Gray, R., Cybenko, G., Kotz, D., Peterson, R. and Rus, D. (2001). D’Agents:
Applications and Performance of a Mobile-Agent System, Software—Practice &
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
Proceedings of IEEE International Conference on Mobile Data Management
(MDM), p. 302, Berkley, CA, USA.
Greenberg, M., Byington, J. and Harper, D. (1998). Mobile Agents and Security, IEEE
Communications Magazine, Volume 36, Issue 7, pp. 76-85.
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
Mobile Object Systems - Towards the Programmable Internet, pp.25-45, Linz,
Austria.
Hohl, F. (1998a). A Model of Attacks of Malicious Hosts Against Mobile Agents, In the
Proceedings of Object Oriented Technology - ECOOP'98 Workshop Reader:
ECOOP'98 Workshops, Demos, and Posters, Lecture Notes in Computer Science,
p. 299, Springer-Verlag, Brussels, Belgium.
168
Hohl, F. (1998b). Time Limited Blackbox Security: Protecting Mobile Agents from
Malicious Hosts, Mobile Agents and Security, Lecture Notes in Computer Science,
Volume 1419, p.92, Springer-Verlag, Berlin, Germany.
Hohl, F. (1999). A Framework to Protect Mobile Agents by Using Reference States, In
the Proceedings of the 20th International Conference on Distributed Computing
Systems ( ICDCS), p. 410, IEEE Computer Society, Washington, DC, USA.
Jansen, W. (1998a). Countermeasures for Mobile Agent Security, Computer
Communications, Special issue on advanced security techniques for network
protection, Volume 23, pp. 1667-1676, Elsevier Science.
Jansen, W. (1998b). Mobile Agents and Security, MD: National Institute of Standards
and Technology, Retrieved April 8, 2005, from
http://www.csrc.nist.gov/staff/jansen/pp-agentsecurityfin.pdf.
Jansen, W. and Karygiannis, T. (1998), Mobile Agent Security, NIST Special
Publication, National Institute of Standards and Technology, 800-19.
Jansen, W. (2001). Determining Privileges of Mobile Agents, In the Proceedings of the
17th Annual Computer Security Applications Conference (ACSAC), p. 149, New
Orleans, Louisiana, USA.
Jihong, W., Jianping, H. and Kai, H. (2003). Security Design of Mobile Agent System,
Proceedings of the 11th International Workshop on Database and Expert Systems
Applications, p. 426, IEEE Computer Society, Washington, DC, USA.
Johansen, D., Renesse, R. and Schneider, F. (1995). Operating System Support for
Mobile Agents, In the Proceedings of the Fifth Workshop on Hot Topics in
Operating Systems (HotOS-V), p. 42, IEEE Computer Society, Washington, DC,
USA.
169
Johansen, D., Marzullo, K. and Lauvset, K. (1999) An Approach towards an Agent
Computing Environment, Proceedings. 19th IEEE International Conference on
Distributed Computing Systems Workshops on Electronic Commerce and Web-
based Applications/Middleware, pp. 78-83, Austin, TX, USA.
Johansen, D., Lauvset, J., Renesse, R., Schneider, F., Sudmann, N. and Jacobsen, K.
(2001). A TACOMA Retrospective, Software—Practice & Experience [Special
issue: Mobile agent systems], Volume 32 , Issue 6, pp. 605-619, John Wiley &
Sons, Inc., New York, NY, USA.
Johansen, D. (2004). Mobile Agents: Right Concept, Wrong approach, in the
Proceedings of the 2004 IEEE International Conference on Mobile Data
Management, pp. 300-301, IEEE Computer Society, Washington, DC, USA.
Karjoth, G., Lange, D. and Oshima, M. (1997). A Security Model for Aglets, IEEE
Internet Computing, Volume 1, Issue 4, pp. 68-77.
Karnik, N. (1998). Security in Mobile Agent Systems, PhD Dissertation, University of
Minnesota, USA. Retrieved November 17, 2005, from
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.,
New York, NY, USA.
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,
New York, NY, USA.
170
Kotz, D., Gray, R. and Rus, D. (2002). Future Directions for Mobile-Agents Research,
University of Dartmouth, Dept. Computer Science, Technical Report, TR2002-
415, Dartmouth College, Hanover, NH, USA.
Kun, Y., Xin, G. and Dayou, L. (1999). Security in Mobile Agent System: Problems and
Approaches, ACM SIGOPS Operating Systems Review, Volume 34 , Issue 1, pp.
21-28, ACM Press, New York, NY, USA.
Lange, D. (1998). Mobile Objects and Mobile Agents: The Future of Distributed
Computing?, In the Proceedings of the 12th European Conference Object-Oriented
Programming (ECOOP), Lecture Notes in Computer Science, Volume 1445, p. 1,
Springer-Verlag, Brussels, Belgium.
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
York, NY, USA.
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
Conference on System Sciences, pp. 297-306, Hawaii, USA.
Leung, K. and Ng, K. (2004). Detection of Malicious Host Attacks by Tracing with
Randomly Selected Hosts, In the Proceedings of the International Conference
Embedded and Ubiquitous Computing (EUC), Lecture Notes in Computer
Science, Volume 3207, pp. 839-848, Springer-Verlag, Aizu-Wakamatsu City,
Japan.
Li, X., Zhang, A., Sun, J. and Yin, J. (2004). The Research of Mobile Agent Security,
Second International Workshop on Grid and Cooperative Computing (GCC),
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
M & M Mobile Agent Framework, In the Proceedings of the International ICSC
Symposium on Multi-Agents and Mobile Agents in Virtual Organizations and E-
Commerce (MAMA), ICSC Press, Wollongong, Australia.
Marrow, P. and Ghanea-Hercock, R. (2000). Mobile Software Agents – Insect-Inspired
Computing, BT Technology Journal, Volume 18, Number 4, pp. 129-139,
Springer-Verlag, Netherlands.
McDonald, J., Yasinyac, A. and Thompson III, W. (2005). A Survey of Mobile Agent
Security, Technical Report, Florida State University, TR-050329, Tallahassee,
Florida, USA.
Milojicic, D., LaForge, W. and Chauhan, D. (1998). Mobile Objects and Agents, In the
Proceedings of the Second USENIX Conference on Object Oriented Technologies
and Systems (COOTS), Toronto, Canada.
Mir, J. and Borell, J. (2002). Protecting General Flexible Itineraries of Mobile Agents,
In the Proceedings of the 4th International Conference on Information Security and
Cryptology (ICISC), Lecture Notes in Computer Science, Volume 2288, p.382,
Springer-Verlag, Seoul, Korea.
Mir, J. and Borell, J. (2003). Protecting Mobile Agent Itineraries, Mobile Agents for
Telecommunication Applications, Lecture Notes in Computer Science, pp. 275-
285, Volume 2881, Springer-Verlag, Berlin, Germany.
Moore, J. (1998). Mobile Code Security Techniques, Technical Report MS-CIS-98-28,
Department of Computer and Information Science, University of Pennsylvania,
Philadelphia, Pennsylvania, USA.
172
Ng, S. (2000). Protecting Mobile Agents against Malicious Hosts, Mater of Science
Thesis, The Chinese University, Hong Kong, China.
Nicola, R., Nicola, G. and Pugliese, R. (1997). Coordinating Mobile Agents Access
Rights via Blackboards and Access Rights, In the Proceedings of the Second
International Conference on Coordination Languages and Models, Lecture Notes
in Computer Science, Volume 1282, pp. 220-237, Springer-Verlag, London, UK.
Noordende, G., Brazier, F. and Tanenbaum, A. (2002). A Security Framework for a
Mobile Agent System, In the Proceedings of the 2nd International Workshop on
Security in Mobile Multiagent Systems (SEMAS), associated with AAMAS 2002,
DFKI Research Report RR-02-03, Deutsches Forschungszentrum fur Künstliche
Intelligenz, pp. 43-50, Bologna, Italy.
Novak, P., Rollo, M., Hodik, J. and Vlcek, T. (2003). Communication Security in Multi-
agent Systems, In the Proceedings of the Conference on 3rd International Central
and Eastern European Multi-Agent Systems and Applications III (CEEMAS),
Lecture Notes in Computer Science, Volume 2691, p. 454, Springer-Verlag,
Prague, Czech Republic.
Orso, A., Harrold, M. and Vigna, G. (2000). MASSA: Mobile Agents Security through
Static/Dynamic Analysis, In the Proceedings of the 1st ICSE Workshop on
Software Engineering and Mobility (WSEM), Toronto, Canada.
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,
Springer-Verlag, Berlin, Germany.
Peine, H. and Stolpmann, T. (1997). The Architecture of the Ara Platform for Mobile
Agents, In the Proceedings of the First International Workshop on Mobile Agents,
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
System, In the Proceedings of the Seventh IEEE International Workshops on
Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE),
pp. 236-242, IEEE Computer Society, Stanford, CA, USA.
Pham, V. and Karamouch, A. (1998). Mobile Software Agents: An Overview, IEEE
Communications Magazine, Volume 36, Issue 7, pp. 26-37.
Picco, G. (2001). Mobile Agents: An Introduction, Microprocessors and Microsystems,
25(2), pp. 65-74.
Refsnes Data (1999). W3Schools Online Web Tutorials. Retrieved June 5, 2005, from
http://www.w3schools.com/.
Roth, V. (1999). Mutual Protection of Co-operating Agents, Secure Internet
Programming: Security Issues for Mobile and Distributed Objects Archive,
Lecture Notes in Computer Science, pp. 275-285, Springer-Verlag, London, UK.
Roth, V. (2003). Secure Recording of Itineraries through Co-operating Agents,
Workshop ion on Object-Oriented Technology, Lecture Notes in Computer
Rothermel, K., Hohl, F. and Radouniklis, N. (1997). Mobile Agent Systems: What is
Missing?, In the Proceedings of the International Working Conference on
Distributed Applications and Interoperable Systems (DAIS), pp. 111-124, Cottbus,
Germany.
Rothermel, K. and Schwehm, M. (1998). Mobile Agents, Encyclopedia for Computer
Science and Technology, M. Dekker.
174
Rubin, A. and Geer, D. (1998). Mobile Code Security, IEEE Internet Computing,
Volume 2, Issue 6, pp. 30-34.
Saeb, M., Hamza, M. and Soliman, A. (2000). Protecting Mobile Agents against
Malicious Host Attacks Using Threat Diagnostic AND/OR Tree, In the
Proceedings of the Smart Objects Conference 2003 (SOC), Grenoble, France.
Sander, T. and Tschudin, C. (1997). Protecting Mobile Agents against Malicious Hosts,
Mobile Agents and Security, Lecture Notes in Computer Science, Volume 1419, p.
44, Springer-Verlag, Berlin, Germany.
Sander, T. and Tschudin, C. (1997). Towards Mobile Cryptography, Proceedings of the
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
the Proceedings of the 6th International Conference on Intelligence and Services in
Networks: Paving the Way for an Open Service Market, Lecture Notes in
Computer Science, Volume 1597, pp. 155-167, Springer-Verlag, London, UK.
Schoder, D. and Eymann, T. (2000). The Real Challenges of Mobile Agents,
Communications of the ACM, Volume 43 , Issue 6, pp. 111-112, ACM Press, New
York, NY, USA.
Sudmann, N. (1998). Security in TACOMA, Position Paper, In the Proceedings of the
Workshop on Object-Oriented Technology, Lecture Notes In Computer Science,
Vol. 1543, pp. 302-303, Springer-Verlag, London, UK.
Sun Microprocessors (1994). Sun’s Java Technology Page. Retrieved December 2,
2004, from http://java.sun.com/.
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
Proceedings of the 41st IEEE International Computer Conference (COMPCON), p.
58, IEEE Computer Society, Washington, DC, USA.
Tate, S. and Xu, K. (2003). Mobile Agent Security Through Multi-Agent Cryptographic
Protocols, In the Proceedings of the 4th International Conference on Internet
Computing (IC 2003), pp. 462-468, Las Vegas, Nevada, USA.
Tripathi, A. and Karnik, N. (1998). Protected Resource Access for Mobile Agent-based
Distributed Computing, In the Proceedings of the 1998 International Conference
on Parallel Processing Workshops (ICPPW), p. 144, IEEE Computer Society,
Washington, DC, USA.
Tripathi, A., Karnik, N., Vora, M., Ahmed, T. and Singh, R. (1999). Mobile Agent
Programming in Ajanta, In the Proceedings of the 19th IEEE International
Conference on Distributed Computing Systems, pp. 190-197, Austin, TX, USA.
Tripathi, A., Karnik, N., Vora, M., Ahmed, T. and Singh, R. (2000). Ajanta – A Mobile
Agent Programming System, Technical Report, University of Minnesota, TR98-
016, Department of Computer Science, Minneapolis, MN, USA.
Tschudin, C. (1999). Mobile Agent Security, Intelligent Information Agents: Agent-
Based Information Discovery and Management on the Internet, Chapter 18, pp.
431-445, Springer-Verlag, Berlin, Germany.
176
Varadharajan, V. (2000). Security Enhanced Mobile Agents, Proceedings of the 7th
ACM conference on Computer and Communications Security, pp. 200-209, ACM
Press, Athens, Greece.
Vigna, G. (1997). Protecting Mobile Agents through Tracing, Proceedings of the 3rd
ECOOP Workshop on Mobile Object Systems, Jyvälskylä, Finland.
Vigna, G. (1998). Cryptographic Traces for Mobile Agents, Mobile Agents and
Security, Lecture Notes in Computer Science, Volume 1419, p. 137, Springer-
Verlag, Berlin, Germany.
Vigna, G. (2004). Mobile Agents: Ten Reasons for Failure, In the Proceedings of the
2004 IEEE International Conference on Mobile Data Management, pp. 298-299,
IEEE Computer Society, Washington, DC, USA.
Villazon, A. and Binder, W. (2001). Portable Resource Reification on Java-Based
Mobile Agent Systems, In the Proceedings of the 5th International Conference,
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
Security and Fault Tolerance using Distributed Transactions, In the Proceedings
of the 1997 International Conference on Parallel and Distributed Systems
(ICPADS), p. 268-274, IEEE Computer Society, Washington, DC, USA.
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.
21-30, ACM Press, New York, NY, USA.
White, J. (1996). Mobile Agents White Paper, General Magic. Retrieved March 17,
2004, from http://www.genmagic.com/agents/Whitepaper/whitepaper.html.
177
Wilhelm, U., Staaman, S. and Buttyan, L. (1998). Protecting the Itinerary of Mobile
Agents, In the Proceedings of the Workshop on Object-Oriented Technology,
Lecture Notes in Computer Science, Volume 1543, pp. 301, Springer-Verlag,
London, UK.
Wong, D., Paciorek, N., Walsh, T., DiCelie, J., Young, M. and Peet, B. (1997).
Concordia: An Infrastructure for Collaborating Mobile Agents, In the Proceedings
of the First International Workshop on Mobile Agents, Lecture Notes in Computer
Yee, B. (1997). A Sanctuary for Mobile Agents, Secure Internet Programming: Security
Issues for Mobile and Distributed Objects, Lecture Notes in Computer Science, pp.
261-273, Springer-Verlag, London, UK.
Young, A. and Yung, M. (1997). Sliding Encryption: A Cryptographic Tool for Mobile
Agents, In the Proceedings of Fast Software Encryption: the 4th International
Workshop (FSE), Lecture Notes in Computer Science, Volume 1267, p. 230,
Haifa, Israel.
178

O. M. Paracha Thesis - Signed

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

O. M. Paracha Thesis - Signed

Uploaded by

Copyright:

Available Formats

A SECURITY FRAMEWORK FOR MOBILE AGENT

Mohammad Ali Jinnah University

of the Requirement for the Degree

Omer Mansoor Paracha

Agent technology is a novel approach for the development of distributed systems. In

by an agent. A number of different approaches have been suggested in the literature to

systems. Based on the techniques surveyed, a state-of-the-art is evaluated and the

and platform. The idea is to provide a solution to the requirement of a security

framework that provides security as a combination of components based on techniques

of various components that are studied in the light of operation scenarios. An

as well as a comparison with the state-of-the-art mobile agent systems is provided to

highlight the strengths and weaknesses.

me to the topic and advising me immensely in drawing out my proposed framework.

sharing their thesis-writing experiences.

research process flourish.

discussions on the whiteboard in the CSD.

I thank my family especially my parents who believed in me and gave me strength to

life. My family has been an astounding inspiration to my research work.

many to mention here.

TABLE OF CONTENTS ................................................................................................................................ VI

CHAPTER 5 MOBILE AGENTS SYSTEMS AND THEIR SECURITY: STATE-OF-THE-ART . 53

6.5.3 Key Distribution Centre ............................................................................................................ 118

FIGURE 3.1: A SIMPLE MOBILE AGENT SYSTEM .......................................................................................... 16

TABLE 4.1: PROTECTION OF THE MOBILE AGENTS ...................................................................................... 51

regard to expansion of systems over a distributed concept. Various approaches for

development of software systems especially distributed systems have come into

representatives for cyber-users.

network is insecure and liable to attacks in its route.

accommodates the protected resource use by the visiting mobile agent.

framework. Chapter 8 describes the implementation issues of our proposed system.

Mobile Agent Systems

mobile agent systems in general.

2.1 Remote Code Execution

Evaluation (Lange, 1998; Rothermel & Schwehm, 1998).

where as the second is code-on-demand.

(Rothermel and Schwehm, 1998).

2.2 Software Agents

which perspective we are elucidating its nature. Generally, an agent is a representative

reactive, autonomous, goal-driven, continuous, communicative, mobile, learning and

agent is basically an object possesses all of the aforementioned characteristics.

2.3 Mobile Agents

out its tasks (Lange, 1998).

agent systems implement the features differently.

2.4 Mobile Agent Benefits

locally reduces the network load.

actually sent there and the wait time is reduced.

upgrade according to the specification of the communication required.

server, executes and the device collects the agent later.

5) Dynamism is enhanced as the mobile agents can be adapted according to the

environment that is given to them.

6) Heterogeneity is provided because the underlying specification is independent to the

mobile agent allowing better integration of heterogeneous systems and environments.

environment suggests, this also makes them fault-tolerant if required.

2.4.1 Mobile Agent Applications

next-generation telecommunication networks (Pham & Karamouch, 1998).

2.4.1.2 Network Management

approaches to a more distributed approach (Pham & Karamouch, 1998).

2.4.1.3 Information Retrieval

have a broad research potential (Kotz, Gray & Rus, 2002).

2.5 Mobile Agents Limitations

2) There is a lack of a systematic approach to design a mobile agent, making it difficult

present in its journey to so many places consisting of adverse environments.

fact that the approaches become so unpredictable.