-
An Integrated Security Framework for Mobile Agent
Communities
by
John Premjeet Page BSc (Comp Sc), M Comp Applications
DISSERTATION
Submitted for fulfilment of the requirements for the degree
of
DOCTOR OF PHILOSOPHY
Caulfield School of Information Technology
Monash University
March 2006
-
1
Declaration I declare that the thesis contains no material that
has been accepted for the award
of any degree or diploma in any university and that, to the best
of my knowledge,
this thesis contains no material previously published or written
by any other
person except where due reference is made in the text.
John Premjeet Page Caulfield School of Information and
Technology
Monash University, Melbourne
March 2006
-
2
Abstract
The mobile agent technology has been applied in a number of
research and
commercial applications implemented on closed networks. In spite
of the
significant potential offered by the mobile agent paradigm, the
lack of a secure
computing infrastructure has blocked the development of open
network based
applications using mobile agents. While several security
proposals have addressed
the security issues confronting mobile agents, a number of
research challenges
were left unanswered. Further, these proposals have failed to
address their cost-
efficiency and usefulness as trust building mechanisms between
mobile agents
and the servers that host mobile agents.
This thesis investigates, analyses and addresses security issues
as well as
proposes, develops and validates solutions to some of these
issues in mobile agent
communities. Various vulnerablities in the existing security
mechanisms of
mobile agent systems have been uncovered in the experiments
carried out on a
number of available mobile agent toolkits. To evaluate the
implications of the
security attacks on mobile agents belonging to a community, two
application
scenarios are implemented. Based on our study and investigation,
we propose,
implement and validate an Integrated Security Framework (ISF)
for securing a
community of mobile agents. The Integrated Security Framework
consists of a
self-executing security examination and a mutual support
mechanism for
countering attacks against mobile agents.
The Self ExecutiNg Security Examination (SENSE) method
implements a code
tampering detection mechanism for mobile agents. Using the SENSE
method, an
MA can detect malicious modifications to its code. Using our
implemented
model, we prove the SENSE method to be a reliable and
cost-efficient
mechanism for detecting the actions of malicious mobile agents.
Further, the
application of the SENSE method makes it difficult for a
malicious host server to
-
3
bypass the security mechanism of an MA as it introduces an
element of
randomness into a mobile agents run-time program sequence.
Active mobile agents are subject to several new security threats
within a
community of mobile agents. To counter these security threats,
the community of
mobile agents implement a mutual support mechanism, called the
Buddy Model
Schema (BMS). The Buddy Model Schema lays down certain rules
that structure
the operation of the mobile agent community. Each mobile agent
of the
community is enabled with a mechanism that tracks and monitors
the migration
and operation of other mobile agents of that community.
Several experiments for analysing and evaluating the performance
of the
implemented security framework are carried out. The experimental
results
validate the cost-efficiency and the reliablity of the
Integrated Security
Framework.
-
4
To my parents and the loving memory of my grandmother, who left
us in 2003
-
5
Acknowledgements I will forever remain grateful for the constant
support and guidance extended by my two supervisors, Arkady
Zaslavsky and Maria Indrawan in making this thesis a success. From
the time that I shot off an email to Arkady requesting to be his
student, to the time that I put in the thesis for examination;
Arkady has always been there for me. His vast research and
supervisory experience, the invaluable discussions I had with him,
the penetrating questions he has put to me and the constant
motivation (read pushing), has all led to the development of the
ideas presented in this thesis. From Arkady, I have also learnt the
technique of applying the principles of multi-tasking to my life,
seamlessly switching between tasks while giving my best to
everything. Thank you, Arkady for your time, for all that you have
taught me and most importantly for believing in me when my own
confidence waned. A very big thank you to Maria for always being
available to me for discussions, for your help and guidance
especially in structuring the ideas presented in the thesis and for
the prompt feedback on the draft versions of the thesis. I would
like to express my heartfelt gratitude to Allison Mitchell for her
help and support with my candidature and scholarship. Allison is
undoubtedly one of the kindest people; I have come across in my
life. From the time that I put in my candidature application to the
time that I submitted my thesis, Allison always with a smile, has
helped me with my queries, paperwork and many times has gone beyond
the call of duty to get me the information required. Many thanks
Allison, for being so nice. A big Sawadee Krap to Akamon
Kunkongkapun for handling all my scholarship related matters and
for promptly processing all payments. Thank you also to Rosemary
Demirtas for helping me with finance matters and for the
interesting philosophical discussions we have had over cups of
coffee While on finance matters, I gratefully acknowledge the
financial support extended to me for the duration of the PhD
project, by Monash University. I would also like to thank the
Boeing Corporation and Mike Barley for conference travel grants. My
grateful thanks to the Monash university technical support staff
especially Duke Fonias and See Ngieng for their help with technical
resources. A very big thank you to Michelle Ketchen, for providing
me with a great workspace. Thank you, Aleisha Mathews for help,
always with a captivating smile in general admin matters. This
thesis would not have been a success without the support and
encouragement of some great mates. I would especially like to thank
Diganth Sheth for his friendship and for constantly encouraging me.
Thank you, Laurence Bull for all the tips about publishing papers
and thesis writing. Thank you, Nitin Arora for being a good friend
and a ready listener to all my ramblings. Thank you, Tarun Shah for
your friendship, support and constant encouragement. A very big
thank you to Prem Jayaraman, Karan Mitra and Saguna for being good
friends and helping me with thesis related admin matters. A very
big thank you to all my friends from my Christian fellowship (OCF)
and Bible study group whose prayers, phone calls and emails have
played a vital role in the
-
6
successful completion of the thesis. A special thank you to
Pastor Wayne Stanley and Martina Stanley for their kindness and
prayers for me. Thank you, Flora Salim for inviting me to undertake
the Bible study course, which made me, realise that just knowing is
not enough I have to apply1. I will always remain grateful and
indebted to Maha, my mentor and my ex-group manager from Perot
Systems Ltd for his support, advice and encouragement. His Thought
for the Day emails have always been a great source of inspiration
to me. Thank you Maha, for always being there for me. I would also
like to acknowledge the motivation I received from the motion
picture Rocky and the soundtrack, No Easy Way Out2. I was also
influenced and in some ways motivated by the unrelenting character
of Colonel Nicholson3, from the 1957 motion picture classic, The
Bridge on the River Kwai. Now, how does one thank someone who has
always loved you since the day you were born, someone whose daily
prayers for you have meant the difference between victory and
defeat? There are three people who come to mind when I ask myself
this question. They are my late grandmother and my parents. Thank
you, Granny for your daily prayers and for all you have done for
me. You are no longer with us in a physical sense, but you live on
each day in my heart. A huge hug to my lovely parents whose love
and belief in me has helped me achieve what I have. Thank you, Dad
and Mom for everything, for all the sacrifices you made in your
lives, so that I could reach for the stars today. Finally, I would
like to acknowledge my greatest motivator, The Holy Bible. In its
passages, I have found strength and direction, both for my thesis
and my life. In moments of despair, I have found hope; in pitch
darkness, I have seen light. The amazing wisdom that flows from its
passages never ceases to amaze me. Verily the Holy Bible is indeed
the Book of Life, which I have been blessed to experience. Thank
you, Jesus.
1 Willing is not enough; we must do. Knowing is not enough; we
must apply. - Bruce Lee 2 From the Rocky IV soundtrack. Performed
by Robert Tepper (1985). 3 Colonel Nicholson was played by Sir Alec
Guinness , who won the Academy Award for Best Actor in a Leading
Role.
-
7
Contents
LIST OF FIGURES
............................................................................................
11 LIST OF TABLES
..............................................................................................
13 CHAPTER
1........................................................................................................
16 MOBILE AGENTS IN DISTRIBUTED
SYSTEMS....................................... 16
1.1 RESEARCH MOTIVATION
.....................................................................
16 1.2 ADVANTAGES OF MA BASED APPLICATIONS
...................................... 19
1.2.1 Scalability of
Operations..................................................................
19 1.2.2 Application
Robustness....................................................................
19 1.2.3 Dynamic Application Discovery
...................................................... 20 1.2.4
Dynamic System Modelling
.............................................................
20
1.3 PROBLEM DEFINITION
.........................................................................
21 1.3.1 Primary Research Questions
........................................................... 26
1.3.2 Secondary Research Questions
....................................................... 27
1.4 THESIS OVERVIEW
...............................................................................
28 CHAPTER
2........................................................................................................
32 THE MOBILE AGENT
PARADIGM..............................................................
32
2.1 INTRODUCTION
.....................................................................................
32 2.2 THE EVOLUTION OF THE MOBILE AGENT
PARADIGM........................ 34
2.2.1 Mobile Code Systems
.......................................................................
34 2.2.2 Levels of Mobility in MAs
...............................................................
36
2.2.2.1 Strong Mobility
.......................................................................
37 2.2.2.2 Weak Mobility
.........................................................................
37
2.3 LANGUAGES FOR MOBASS
..................................................................
37 2.3.1 Telescript
..........................................................................................
38 2.3.2
Java...................................................................................................
39 2.3.3 TCL
/TK............................................................................................
41
2.4 MOBAS CONCEPTS
..............................................................................
42 2.4.1 Terminology
.....................................................................................
42
2.4.1.1 Agent States
.............................................................................
43 2.4.1.2 Place
.........................................................................................
43 2.4.1.3 Agency
......................................................................................
43 2.4.1.4
Region.......................................................................................
44
2.4.2 Differentiating between Mobile Agents and Objects
...................... 44 2.5 CHAPTER SUMMARY
............................................................................
45
CHAPTER
3........................................................................................................
47
-
8
SECURITY IN MOBILE AGENT SYSTEMS AND TOOLKITS ................
47 3.1 INTRODUCTION
.....................................................................................
47 3.2 DEFINING SECURITY
............................................................................
48
3.2.1 MA
Perspective.................................................................................
48 3.2.2 MoAS Perspective
............................................................................
50 3.2.3 MA User Perspective
........................................................................
51
3.3 MAE SECURITY REQUIREMENTS
........................................................ 51 3.4 THE
MAE SECURITY PROBLEM
.......................................................... 53
3.4.1 Target Areas of Malicious Attacks
.................................................. 55 3.4.2
Classifying Malicious Attacks
......................................................... 55
3.5 A SURVEY OF MA TOOLKITS
.............................................................. 58
3.5.1 Java based Toolkits
..........................................................................
60
3.5.1.1 Aglets
........................................................................................
60 3.5.1.2
Tryllian.....................................................................................
63 3.5.1.3 Grasshopper
............................................................................
64 3.5.1.4
Ajanta.......................................................................................
66 3.5.1.5
SOMA.......................................................................................
70 3.5.1.6 JADE
........................................................................................
72
3.5.2 Non-Java based
Toolkits..................................................................
74 3.5.2.1 Telescript
.................................................................................
74 3.5.2.2 Agent TCL / DAgents
........................................................... 75
3.5.2.3 ARA
..........................................................................................
77
3.5.3 Comparison of the MobAS security mechanisms
........................... 79 3.6 CHAPTER SUMMARY
............................................................................
81
CHAPTER
4........................................................................................................
83 SECURITY APPROACHES FOR MOBILE AGENT SYSTEMS...............
83
4.1 A SURVEY OF SECURITY APPROACHES
............................................... 83 4.1.1
Cryptographic
Approach..................................................................
85
4.1.1.1 The Agent Perspective
............................................................ 85
4.1.1.2 The Agent System Perspective
............................................... 89
4.1.2 Non-Cryptographic Approach
......................................................... 93
4.1.2.1 The Agent Perspective
............................................................ 93
4.1.2.2 The Agent System Perspective
............................................... 95
4.2 DISCUSSION ON THE SECURITY
APPROACHES..................................... 95 4.3 CHAPTER
SUMMARY
............................................................................
98
CHAPTER
5........................................................................................................
99 SECURING MOBILE AGENT
COMMUNITIES..................................... 99
5.1 INTRODUCTION
.....................................................................................
99 5.2 MAC SECURITY
REQUIREMENTS......................................................
102 5.3 SECURITY APPROACHES FOR MA COMMUNITIES
............................ 104 5.4 FUNCTIONS CHARACTERISING AN MA
COMMUNITY ....................... 106 5.5 MA COMMUNITY
SCENARIOS............................................................
109
5.5.1 Workflow Management System
..................................................... 110
-
9
5.5.1.1 Security Concerns in the WMS
........................................... 114 5.5.2 Airline
Ticketing System
................................................................
114
5.5.2.1 Security Concerns in the
ATS.............................................. 118 5.6 SECURITY
CONCERNS IN MACS
........................................................ 120 5.7
CHAPTER SUMMARY
..........................................................................
121
CHAPTER
6......................................................................................................
123 THE SENSE METHOD
..............................................................................
123
6.1 INTRODUCTION
...................................................................................
123 6.2 MOTIVATION FOR THE SENSE METHOD
.......................................... 124
6.2.1 Airline Ticketing System
Implementation..................................... 125 6.2.2
Security Attacks within the ATS scenario
..................................... 129
6.3 SCHEMA ARCHITECTURE AND
OPERATION....................................... 131 6.3.1 SENSE
Method: Schema
1............................................................
133
6.3.1.1 Assumptions
..........................................................................
133 6.3.1.2 Schema
Operation.................................................................
134
6.3.2 SENSE Method: Schema
2............................................................ 141
6.3.2.1 Assumptions
..........................................................................
141
6.3.2.2 Schema
Operation......................................................................
141 6.3.3 SENSE Method: Schema
3............................................................
144
6.3.3.1 Assumptions
..........................................................................
144 6.3.3.2 Schema
Operation.................................................................
144
6.3.4 SENSE Method: Schema
4............................................................ 147
6.3.4.1 Assumptions
..........................................................................
149 6.3.4.2 Schema
Operation.................................................................
149
6.4 SUMMARY OF THE SENSE
METHOD.................................................. 155 6.5
CHAPTER SUMMARY
..........................................................................
156
CHAPTER
7......................................................................................................
158 THE BUDDY MODEL SCHEMA
.............................................................
158
7.1 INTRODUCTION
...................................................................................
158 7.2 SCHEMA ARCHITECTURE AND
OPERATION....................................... 159
7.2.1 The entities of the BMS
.................................................................
161 7.2.1.1 The Mobile Agent
Servers.................................................... 161
7.2.1.2 The Agents
.............................................................................
162 7.2.1.3 Rules Governing the Buddy Model Schema
....................... 163 7.2.1.4 Various Configuration Models
............................................ 164
7.3 MAC BASED AIRLINE TICKETING
SYSTEM....................................... 171 7.3.1 The 7-14
Buddy
Model...................................................................
173
7.3.1.1. Assumptions
..........................................................................
173 7.3.1.2. The BMS
Operation..............................................................
173
7.4. CHAPTER SUMMARY
..........................................................................
180 CHAPTER
8......................................................................................................
182 AN INTEGRATED SECURITY FRAMEWORK FOR MOBILE AGENT
COMMUNITIES...............................................................................................
182
-
10
8.1 INTRODUCTION
...................................................................................
182 8.2 ISF SCHEMA
ARCHITECTURE............................................................
183
8.2.1 Sequence
Diagrams........................................................................
184 8.2.2 Collaboration Diagram
..................................................................
188
8.3 ISF SCHEMA OPERATION
...................................................................
190 8.4 CHAPTER SUMMARY
..........................................................................
191
CHAPTER
9......................................................................................................
193 EVALUATION OF THE INTEGRATED SECURITY FRAMEWORK ... 193
9.1 INTRODUCTION
...................................................................................
193 9.2 SENSE METHOD PERFORMANCE ANALYSIS
...................................... 194 9.3 SENSE METHOD:
ADVANTAGES AND LIMITATIONS ....................... 197 9.4 BMS
PERFORMANCE ANALYSIS
......................................................... 199 9.5
BMS: ADVANTAGES AND LIMITATIONS
............................................ 203 9.6 ISF
PERFORMANCE ANALYSIS
........................................................... 204 9.7
ISF: ADVANTAGES AND LIMITATIONS
.............................................. 209 9.8 EVALUATION
PARAMETERS
............................................................... 210
9.9 EVALUATION OF THE
ISF...................................................................
211 9.10 SUMMARY OF THE ISF EVALUATION
................................................. 214 9.11
RECOMMENDATIONS FOR APPLYING THE
ISF................................... 216 9.12 CHAPTER SUMMARY
..........................................................................
217
CHAPTER
10....................................................................................................
218 CONCLUSIONS AND FUTURE
WORK...................................................... 218
10.1 THESIS CONCLUSIONS
........................................................................
218 10.2 CONTRIBUTIONS OF THE
THESIS........................................................ 221
10.3 FUTURE WORK
...................................................................................
222
BIBLIOGRAPHY............................................................................................
224 LIST OF ACRONYMS
....................................................................................
238
-
List of Figures
Figure.1.1. Attacks on an MA operation
environment___________________ 23
Figure.1.2. Thesis Roadmap
_______________________________________ 29
Figure.2.1. Client-Server paradigm
_________________________________ 35
Figure.2.2 Overview of the Java security
model________________________ 40
Figure.3.1 A Mobile Agent Environment
(MAE)_______________________ 53
Figure.3.2. Overview of a MoAS Security Model
_______________________ 59
Figure.3.3. A rule in the Aglet security model
_________________________ 62
Figure.3.4. Overview of the Ajanta Security Model
_____________________ 67
Figure.4.1. Four levels of security in a MAE
__________________________ 96
Figure.5.1. Describing MA interaction spheres
_______________________ 100
Figure.5.2. Distinguishing between a MAS and an MAC
_______________ 101
Figure.5.3. An MAs functionality as a member of an
MAC_____________ 107
Figure.5.4. MAC Security Vulnerabilities
___________________________ 108
Figure.5.5. An MAC based Workflow Management System (WMS)_______
112
Figure.5.6. Transaction processing within an MAC based WMS
_________ 113
Figure.5.7. A MAS based Trip Planning System
(TPS)_________________ 116
Figure.5.8. Transaction processing within an MAC based ATS
__________ 117
Figure.6.1. Configuration File of SeeTheWorld Region
________________ 126
Figure.6.2. System Console of SeeTheWorld
Region___________________ 127
Figure.6.3. Partial Configuration File of Destiny_Travels Agency
_______ 128
Figure.6.4. MA code snippet illustrating private data
__________________ 130
Figure.6.5. Agency console displaying hacked data of Johns
Secret Agent 131
Figure.6.6. SENSE algorithm pseudo-code
__________________________ 132
Figure.6.7.Destiny_Travels Agency screenshot
_______________________ 135
Figure.6.8.SENSE schema confirmation dialog box
___________________ 136
Figure.6.9.Reporting the progress of the securityCheck
function_________ 138
-
12
Figure.6.10.SENSE reporting No Code Tampering Detected
____________ 139
Figure.6.11.SENSE reporting Code Tampering Detected
_______________ 140
Figure.6.12.SENSE method report of Johns Secret Agent ver2
_________ 143
Figure.6.13.Creating code maps within the MAs code
_________________ 146
Figure.6.14.SMC concept
overview_________________________________ 151
Figure.6.15.SMC SENSE schema__________________________________
153
Figure.7.1.Relationship between the SPG and
WAG___________________ 160
Figure.7.2.The 2 phases of the 1-2
model____________________________ 164
Figure.7.3. The 4-8 and 3-6 BMS configurations
_____________________ 165
Figure.7.4.The 5-10 Buddy configuration model
______________________ 167
Figure.7.5. BMS pseudo code algorithm
____________________________ 168
Figure.7.6. Intelligent countermeasures with a BA
____________________ 170
Figure.7.7.Configuration file of NorthWestTravel Agency
______________ 172
Figure.7.8. Logic of MA allocation in the
BMS_______________________ 175
Figure.7.9. Interface screenshot of NorthWestTravel
Agency____________ 178
Figure.8.1.SENSE method operation within the ISF
__________________ 184
Figure.8.2.BMS operation within the ISF
___________________________ 186
Figure.8.3 Interactions between the MAs and their host MoAS in
the ISF _ 189
Figure.8.4.Integrated Security Framework
algorithm__________________ 190
Figure.9.1.MA code size vs. code elements
___________________________ 194
Figure.9.2.MA code size vs. scan time
______________________________ 195
Figure.9.3. BMS Performance Analysis
_____________________________ 199
Figure.9.4. Buddy Execution Performance Runs
_____________________ 201
Figure.9.5.Analysing the effect of MA migration on the BMS
___________ 202
Figure.9.6.ISF SENSE method Performance Analysis
_________________ 205
Figure.9.7.SENSE_BMS Integrated Performance Runs (Agent Two)
_____ 207
Figure.9.8.SENSE_BMS Integrated Performance Runs (Agent Three)
___ 208
-
13
List of Tables
Table 2.1: A Summary of Mobile Code
Systems________________________ 36
Table 3.1 Comparison of the MobAS security
mechanisms_______________ 80
Table 6.1. A Summary of the SENSE Schemas
_______________________ 156
Table 7.1.Allocation of MAs in an SPG of 4 MAs
_____________________ 165
Table 7.2. Agent Role Allocation for the 5-10
Model___________________ 166
Table 7.3. MA Role Allocation in the 7-14
model______________________ 176
Table 9.1. A Summary of the Evaluation
____________________________ 214
-
14
Outcomes/Publications
Conference Publications
1. Page, J., Zaslavsky, A., & Indrawan, M., Evaluating
Security in Software Agent Systems using a Security Analysis Tool,
In Proceedings of the 1st Australian Information Security
Management Conference (InfoSec2003), ISBN 0-7298-0541-7, 2003,
Perth (Australia), 2003.
2. Page, J., Zaslavsky, A., & Indrawan, M., Security Aspects
of Software
Agents in Pervasive Information Systems, In Proceedings of the
14th Australasian Conference on Information Systems,(ACIS2003),
ISBN No 0-7298-0544-1,Perth (Australia), 2003.
3. Page, J., Zaslavsky, A., & Indrawan, M., A Buddy Model of
Security for
Mobile Agent Communities Operating in Pervasive Scenarios, In
Proceedings of 2nd Australasian Information Security Workshop
(AISW2004), ACS, Vol 32, pp. 17-25,Dunedin (New Zealand) ,2004.
4. Page, J., Zaslavsky, A., & Indrawan, M., Countering
Security
Vulnerabilities using a Shared Security Buddy Model Schema in
Mobile Agent Communities, In Proceedings of the 1st International
Workshop on Safety and Security in Multi-Agent Systems
(SASEMAS2004), pp. 85-101,New York (USA), July 2004.
5. Page, J., Zaslavsky, A., & Indrawan, M., Countering
Security
Vulnerabilities in Agent Execution using a Self Executing
Security Examination, In Proceedings of the 3rd International Joint
Conference on Autonomous Agents and Multi-Agent Systems
(AAMAS2004), Vol 3,pp. 1486-1487,New York (USA), July 2004.
6. Page, J., Zaslavsky, A., & Indrawan, M., Securing
m>Business Scenarios
using the Buddy Model of Security for Agent Communities, In
Proceedings of m>Business 2004, pp 1-12, New York (USA), July
2004.
7. Page, J., Zaslavsky, A., & Indrawan, M., Countering Agent
Security
Vulnerabilities using an Extended SENSE method, In Proceedings
of the 2004 International Conference on Intelligent Agent
Technology (IAT2004), pp 183-189, Beijing (China), September
2004.
8. Page, J., Zaslavsky, A., & Indrawan, M., Agent
Communities, Security
Vulnerabilities and the Buddy Model of Security: Applicability
and Effectiveness, In Proceedings of the 12th International
Conference on
-
15
Advanced Computing and Communication (ADCOM2004 ), pp 316-324,
Ahmedabad (India), December 2004.
9. Page, J., Padovitz, A., & Gaber, M. M., Mobility in
Agents, a Stumbling
or a Building Block?, In Proceedings of 2nd International
Conference on Intelligent Computing and Information Systems
(ICICIS2005), Cairo, (Egypt), March 2005.
10. Page, J & Wang, M., The Future of Intelligent
Information Management:
Mobile Agents, In Proceedings of the 1st International
Conference on Information Management and Business (IMB2005), pp
257-263, ISBN 957-9129-33-9, Taipei (Taiwan), March 2005.
11. Page, J., Zaslavsky, A., & Indrawan, M., Extending the
Buddy Model to
Secure Variable Sized Multi-Agent Communities, In Proceedings of
the 2nd International Workshop on Safety and Security in
Multi-Agent Systems (SASEMAS2005), pp 59-75, Utrecht (The
Netherlands), July 2005.
Public Presentations and Seminars Seminar title : 'Security
Considerations of Mobile Agents ' , Presented on
9.5.2003 , 11 am in Room B5.50A, Monash University,
Caulfield.
Seminar title : 'Security Aspects of Mobile Agents operating in
Pervasive Scenarios' , Presented on 08.10.2003, 1 pm at the
Gippsland School of Information Technology, Monash University,
Gippsland.
Debate on Mobile Agents. Debate Theme : 'Mobility of software
Agents is an important and useful Feature', held on Friday,
31.10.2003, 9.45-11.30am, in Room B5.50A, Caulfield.
Seminar title : 'Security and Protection of Mobile Agent
Communities ', Presented on 30.09.2004, 12 pm at University of
South Australia (UniSA), Adelaide.
Seminar title : 'Securing Mobile Agent Communities ' , Presented
on 30.9.2005 , 10 am in Room B5.50A, Monash University,
Caulfield.
-
16
CHAPTER 1
MOBILE AGENTS IN DISTRIBUTED SYSTEMS
This chapter gives an overview of the research motivation by
describing
drawbacks of distributed systems that have been addressed by the
advent of the
Mobile Agent (MA) paradigm. It describes the importance of
security in the
success of the MA based applications. Further, the limitations
in existing security
models are explained and the goals this research are stated. The
chapter concludes
with an overview of the thesis structure.
1.1 Research Motivation
Over the last few years, changing user preferences and a large
variety of
distributed applications have indicated the need for a paradigm
shift in distributed
computing. The advent of agent based computing appeared to match
the changing
requirements and supported the development of Multi-Agent
Systems (MASs).
Kotz and Gray [KG99] argued that the large number of client
systems in use, the
increasing base of mobile users and the demand for
personalization of services
called for the use of mobile code. This and other similar
studies, led to the
development of Mobile Agent Systems (MobASs).
Currently, while several forms of code exhibit mobility, Kotz
and Gray [KG99]
refer to Mobile Agents (MAs) as mobile code that can migrate
sequentially
through multiple nodes while carrying out their programmed
tasks. MAs enable
-
17
applications with the promise of providing distributed services
in a cost-efficient
manner. This section describes a few MA based applications that
demonstrate the
usefulness of an MA based architecture as compared to other
traditional forms of
distributed computing.
When dealing with distributed systems, network bandwidth is a
key factor in
defining the quality of service provided by an application.
Restrictions imposed
by slow and unreliable network connections are overcome by MAs.
Mobility
enables agents to migrate to several nodes, allowing it to pick
and choose the best
possible results. Further, MAs are able to overcome the physical
limitations of
mobile nodes, such as low battery life of Personal Digital
Assistants (PDAs).
EASTER [FKK+03] is one such initiative where in the current
executing
application is able to migrate to another node when the battery
life of the node
becomes critical.
Apart from data intensive applications, there are real-time
applications in which
communication between their nodes is a critical factor [BHR+97,
MP99]. Success
in these applications is dependant on a reliable communication
infrastructure
between its interlinked components. Space exploration is a good
example of such
a situation. NASA has used MAs in developing systems for
planetary Extra-
Vehicular Activity (EVA) [CSA+04]. This initiative will allow
the development
of a distributed coordination framework and support
human-robotic EVA teams.
The MA application will also support space exploration including
potential agent
manned research forays on the moon and on Mars.
Another example of a similar MA based approach is the initiative
of the US office
of Naval Research called The Multimedia Intelligent Network of
Unattended
Mobile Agents project a.k.a MinuteMan4. This project
investigates the
development of Unmanned Aerial Vehicles (UAV), which will
coordinate with
unmanned ground vehicles (UGV) in simulating battle conditions.
Continuing in
the same vein are the dozen or so, successful projects of the
Lockheed Martin
4 See Wireless Review. 2002, Mario Gerla, UCLA researcher and
director of the U.S. Navy's MinuteMan project, Available at
http://wirelessreview.com/ar/wireless_mario_gerla_ucla/ ,Date
accessed 04/09/2003
-
18
Advanced Technology Laboratories, which have been rolling out
successful MA
based projects since 1995, including Domain Adaptive Information
Systems
(DAIS) [MCW04], supported by the Defence Advanced Research
Projects
Agency (DARPA). This project has used MAs to query heterogeneous
databases
over unreliable and low-bandwidth networks. An analysis of the
results displayed
a significant improvement in operator decision-making. DARPA has
another
successful implementation of an MA based approach is called the
Cooperating
Agents for Specific Tasks project a.k.a CAST. CAST uses
intelligent, mobile
agents to discover and analyse the location of hidden TELS by
querying several
distributed military data systems.
Another area where the application of MAs has been recognised,
is connecting
geographical locations where maintaining a reliable network
connection might be
difficult. The STORMCAST5 project based on TACOMA6 agents
[JRS95a,
JRSb03] is an example of such a project. TACOMA agents are used
to meta-tag
satellite images on a periodic basis. This is used for
predicting weather. This
agent-oriented approach is particularly useful as the weather
monitoring stations
are located in remote locations such as the Artic circle.
Maintaining network
connectivity, bandwidth and caching capacity are all problem
areas with such
remote stations.
The RETSINA7 MoAS toolkit [SPV+01], developed at the Carnegie
Mellon
University, has been used to implement several intra-domain
applications such as
financial portfolio management, e-commerce auctions and F-15
aircraft
maintenance to name a few domain areas. Thus, from the
application scenarios
described above, it is clear that mobility in agents enables the
development of
distributed applications. These MA based applications are able
to overcome the
limitations of unreliable network connectivity and hazardous
geographical
locations while delivering cost-efficient applications. MAs are
developed to 5 See Stormcast Available at
http://www.cs.uit.no/forskning/DOS/StormCast/ Date accessed
17/03/2004. 6 See Overview of the TACOMA project, Available at
http://www.cs.uit.no/forskning/DOS/Tacoma/Overview.html Date
accessed 15/07/2004. 7 For a full list of projects based on the
RETSINA MAS, see Katia Sycaras homepage at
http://www.ri.cmu.edu/people/sycara_katia.html Date
accessed12/07/2005.
-
19
accomplish a particular set of objectives. To execute they need
to be hosted by
Mobile Agent Servers (MoASs). To accomplish their pre-defined
objectives MAs
depart on missions to remote MoASs. On their missions, they meet
and interact
with MAs from other MoASs.
Thus, based on their application functionality MAs can
communicate, collaborate
and build communities through their actions. Research also
indicates that MAs are
suitable candidates for the development of e-commerce
applications [VP99,
RSHR00, HEG+99], semantic routing, personalizing applications,
information
management [PW05], entertainment [Mae95] and being alternate
options for
Remote Procedure Calls (RPC) applications [CHK96].
1.2 Advantages of MA based Applications
1.2.1 Scalability of Operations
An MA-oriented approach allows an application to maintain a high
level of
scalability, as compared to other traditional architectures.
Agents act as glue
between different sub-systems. Intra-domain applications can
connect or detach
themselves from an agent based application model, dynamically.
The term
connectivity does not imply merely connectivity as physical
machines but the
existence of an application level channel through which
information flows. MAs
act as the conduit for this information transfer. They allow
systems to come
together, share information and become part of a pervasive
application.
1.2.2 Application Robustness
The mobility factor coupled with the agent paradigm allows
applications to
maintain a high level of robustness within their operations.
Fault discovery agents
continuously monitor the health of the system assigned to them.
Since these
agents are mobile, they can move across an application spread
over different
physical machines while performing health checks. Their action
enables the
detection of tied up resources, system deadlocks, queued
requests and heavily
-
20
loaded modules. When faults occur, MAs can redirect themselves
and ensure a
smooth transition of operations from the primary system onto the
backup systems.
Thus, MA based applications do not suffer from downtime periods,
if backup
procedures are in place.
1.2.3 Dynamic Application Discovery
The mobility feature allows agents to bridge the physical gap
within and across
applications. Their presence allows a high level of
inter-application as well as
intra-application interactions. Sub-components within an
application can talk to
each other, even if they are located on different physical
systems. Applications
can dynamically discover each other as and when they become
hosts and MAs
start arriving and docking at the system.
1.2.4 Dynamic System Modelling
An MA based architecture enables a high degree of separation
between the
physical infrastructure and the application system design. For
example, consider a
scenario wherein an airline travel agency makes a decision to
expand its business
operations from airline ticketing to the railway-ticketing
sector. If the application
design is MA based, porting it onto another system would be a
comparatively
easier operation due to the high degree of modularity present in
the architecture.
MAs allow the design of scalable, robust and dynamically
evolving application
systems. Acting individually and sometimes as cohesive units,
MAs collaborate
and coordinate their functionality to service the application.
Since MAs are
mobile, they can migrate across networks, in the search for the
closest matches to
their information requirements. While mobility increases the
chances of getting an
acceptable solution to a users requirements, it opens the door
to several
possibilities that if exploited, can compromise the operation of
MAs.
-
21
1.3 Problem Definition
While various definitions of the term agent have been proposed,
the American
Heritage dictionary defines an agent as one that acts or has the
power to act or
represent another. According to Franklin and Graesser [FG96], an
MA extends a
users authority into the computing world. It executes on the
users behalf and
attempts to accomplish pre-defined objective(s). An important
aspect that
distinguishes it from other forms of mobile code is that the MA
has intelligence.
On being presented with a number of options, it analyses and
chooses the best
course of action, without contacting its parent Mobile Agent
Server (MoAS).
Apart from intelligence, autonomy is another aspect which makes
it an ideal data
retrieval tool and a suitable candidate for developing
applications that require
accessing distributed sources of data. Since every MA has to be
hosted by a
Mobile Agent Server (MoAS). Thus, an MA, its host MoAS and the
sender of the
MA can be regarded as the three main components of every MA
operation
scenario.
While the utility of the agent paradigm has been discussed in
several studies
[KG99, Som97, Lan99, CHK96], the introduction of the mobility
factor into the
agent paradigm has been a debatable topic [PPG05]. Mobility has
given rise to
several issues that hinder the ready acceptance of the paradigm
[CHK96]. Among
these issues, the security issue ranks foremost. With respect to
security, there are
two main aspects of the MA operation. These aspects are
authentication and
authorisation of MAs [FGS96, KG99, LABW92].
Authentication of MAs refers to verifying the MA senders
identity. Since the
credentials of the MA could be forged or spoofed, authentication
of the senders
identity is of principal importance. The second factor in the
security sphere is
authorisation. This relates to validating the level of resources
that the host MoAS
should make available to the MA. Authentication checking is
based on the
senders identity. Thus if the authorisation checking procedure
was weak and did
not detect the presence of an MA with forged credentials, the
authentication step
will also be compromised. The impact of admitting an
unauthorized MA into the
-
22
MoAS can be compared to that of a virus action as a malicious MA
can damage
system files and effect Denial-Of-Service (DOS) attacks.
Thus, for any MA based application to be successful, there needs
to be a pre-
defined level of trust between the MAs and the host MoAS. Trust
between two
entities can be established, if there is a reliable mechanism in
place to ensure that
one entity cannot damage the other. While limiting the
functionality of an MA is
one possible option for restricting the damage scenario, it also
reduces the
effectiveness of the MA operation. Thus, MA based applications
require a trade-
off between restricting an MAs action and establishing security
mechanisms
within the application.
In most cases, while MAs are created in good faith by their
owners, malicious
entities in the guise of malicious MoASs and MAs, can intercept
and tamper with
the code of the MA. Since the behaviour of an MA arises from its
code,
maintaining code integrity during the MAs travels is a
pre-requisite in ensuring
an expected form of execution on a host MoAS.
From the security viewpoint, three components of an MA operation
environment
can be identified. These components are the MAs Code, The Mobile
Agent
(MA) and The Mobile Agent Server (MoAS). The MAs code represents
the
program statements and the internal variables used for its
execution. The other
aspect of the MA is the resources it requires for its execution
and migration.
Examples of such resources are migration protocols,
communication channels,
information databases etcetera. The third component of the
operation environment
is the MoAS. The MoAS is responsible for hosting the environment
and providing
system resources to the MA, when requested.
Malicious attacks on the MA operation environment can target any
of the three
components. These attacks can be launched directly or indirectly
by the malicious
entities. Direct attacks as the name suggest target the entity
directly. For example
a MoAS may attack an MA, to access the data carried by it. This
is can be termed
as a direct attack on the MA code and an indirect attack on the
data carried by it.
-
23
These attacks can be applied in different modes. These are an
Open mode and a
Concealed mode. Attacking in an open mode implies that the
attacker does not
conceal the attack. Symptoms of an open attack can range from
degradation of
service to corruption of system files. Examples of Open mode
attacks are Denial
of Service (DOS) and destruction of system files.
Attacks in a Concealed mode are difficult to detect because they
do not disturb the
equilibrium of the MA operation. In the case of Concealed mode
attacks, the MA
can continue to execute without noticing any changes in the
operating
environment. Examples of such attacks are eavesdropping and
tracking agent
migration. Malicious attacks on the MAE are described in detail
in chapter 2.
Figure 1.1 describes the different modes and various kinds of
attacks that can be
launched on an MA operation environment.
Figure.1.1. Attacks on an MA operation environment
Thus, the need for equipping the MA with a reliable code
tampering detection
scheme assumes major importance for the success of an MA based
application.
While in the past, several schemes have been proposed for
detecting tampering of
the MAs code, they have not been entirely successful in solving
the security
issues. An unfortunate consequence is that while some of these
proposed
Agent System
Agent
Direct Attack
Direct Attack
Indirect Attack
Mobile Operation Environment
Legend Mode of Attack Intensity of Attack Concealed Attack:
Strong : Open Attack: Weak:
Code
Malicious Entities
-
24
approaches continue to exist in theory; they have not been
implemented by
MobAS toolkit developers because of their operating
complexity.
A further drawback with the schemes being proposed is that they
are expensive in
terms of computing power required to execute them. It is
important to keep in
mind that an MA, in terms of size is a small piece of software.
It has specific
functionality and objectives. On its travels it carries a
limited amount of data,
which may or may not have any financial value to a malicious
entity. Applying a
cryptographic scheme to protect an agent, which carries data of
very little value,
is a non-viable option. These factors have led MobAS toolkit
developers to leave
the addition of security functionality, as future work or to
make the underlying
layer, such as the Java Security Manager [GJS96] in a Java based
application,
responsible for enforcing security.
This approach, far from being a solution has proved to be a
hindrance in the
development of trust relationships between the entities of the
MA operating
environment as it plays the one-sided role of restricting the
action of MAs against
the MoAS but does little to prevent the opposite happening. The
lack of a reliable,
cost effective and efficient security mechanism for MAs has left
them vulnerable
in defending themselves against the malicious action from
hostile entities.
Different researchers have proposed security schemes to address
the problem of
MA code tampering by malicious entities. Jansen surveyed their
efforts in his
paper [Jan00]. Another detailed study on mobile code security
has been attempted
by Thorn [Tho97]. Fischmeister et al [FVK01] analysed the
security of three Java
based MA toolkits.
All these studies indicate that while it is relatively easier to
protect the MoAS
from malicious entities, protecting MAs is a critical but
difficult task. The reason
for this is that a MoAS has several resources at its behest and
controls the
environment in which the MA operates, while MAs are not
similarly privileged.
Since the execution environment for the MA is provided by the
MoAS, an MA
cannot force the MoAS to influence the execution of statements
or functions that
the MoAS may not wish to. This is the reason why enforcing
security mechanisms
-
25
and policies that aim at protecting the MA from a malicious
attack initiated by the
MoAS are difficult to implement. The only option open to the MA
is to trick the
MoAS into allowing it to execute its security functions, if it
suspects the MoAS to
be malicious.
In the context of a Mobile Agent Community (MAC), the security
issues take on a
whole new dimension as the level of interactions between the MAs
is increased
and there are several factors that can lead to the introduction
of a malicious entity
into the community. Among these factors, the topology of a
community plays an
important role in setting the vulnerability level from the
security point of view.
MACs can be of three types. The structure can be Open, Semi-open
and Closed
[PZI03b].
Open communities imply that any MA can join or leave the
community at will.
The MA does not need any explicit invitation to become a part of
the community.
This structure gives rise to a very dynamic model of the MAC.
There are fewer
security checks in this model, as having a very high volume of
checks will give
rise to performance bottlenecks. Consequently, MAs within the
open community
model can be the target of malicious attacks from several
quarters as it is
comparatively easier for a malicious entity to enter the
community and affect the
operations of the MA. Further, due to the high volume of
transactions taking place
and migration of MAs, it can also be difficult to differentiate
between a malicious
attack and a performance issue.
Semi-open communities are based on the premise that if any MA
wishes to join
the MAC, it will have to be invited by existing MAs within the
community. While
this requirement restricts the ingress of new MAs into the
community to some
extent and limits the scope of the MAC operation, it has the
advantage of limiting
the level of vulnerability that the community might face. Thus,
compared to the
Open community model, the Semi-open model is less vulnerable to
malicious
attacks and greater control can be exercised over the members of
the community.
-
26
The Closed model of MACs can be regarded as the most secure
model among the
three models. The number of MAs within a Closed MAC is fixed8
and remains
the same through out the duration of the community operation
[SPV+01]. Thus,
the possibility of the introduction of a malicious entity is
considerably diminished
in a Closed community model. Even though, this model appears to
be a relatively
secure model for an MAC operation, malicious attacks can still
be launched
against the entities of the community as the entities might be
sharing resources
and server space with the MAs of other communities.
Thus, due to the changing dynamics of MACs, achieving an
acceptable level of
security in an MAC is a challenging task. Chapter 2 takes this
view forward with
an in-depth analysis of the intricacies of security in MA
operating scenarios. The
next section lists the research questions that this thesis has
answered.
1.3.1 Primary Research Questions
What does the term security in the context of an MAC imply? As
discussed in the previous section, an MA operation can have
several
dimensions attached to it. This can give rise to various
security issues, each of
which might have different consequences for the entities
involved. This
question analyses the concept of security for each of the
entities involved in
the MA operation.
Is it possible for an MA to detect tampering of its code at
runtime while it is executing away from its parent MoAS without
having to take recourse
to third-party support?
Owing to the lack of control on the execution environment, the
MAs are
limited in their options of executing security mechanisms
especially against
attacks from MoASs. However, using surreptitious methods, it may
be
possible for an MA to initiate a code scanning algorithm that
might not be
blocked or bypassed by the host MoAS.
8 In the RETSINA MAS, the fixed number of MAs are referred to as
a Priori
-
27
While the MA security aspect may encompass several aspects such
as data
confidentiality, code integrity and accountability [SO99], as
described in
detail in section 3.3, the schemas described in the thesis have
dealt with the
problem of detecting and verifying the code integrity of mobile
agents
operating in community based scenarios.
1.3.2 Secondary Research Questions
Is it possible to remove or reduce MA dependence on MoASs for
executing their tamper-check algorithms?
While it is understood that an MA cannot function without the
execution
environment of the host MoAS, the question arises that for a
security
mechanism to be successful, how much dependence on the host
server is
actually necessary and given a level of resources required, can
that level be
reduced. If yes, then what will be the resulting trade-off?
Is it possible to function in a neutral execution environment,
while visiting non-trusted servers?
While MoAS control the execution environment within which MAs
operate, is
it possible to create neutral spaces for MAs and MoAS alike and
if such a
scenario was indeed possible, then what will be the conditions
required for it
to exist?
Is it possible to create effective trust models within and
across MACs? This question will attempt to answer, what exactly the
term trust in an MAC
implies and what conditions are required for the establishment
and continued
presence of trust in an MAC.
This section listed some of the primary and secondary questions
that this thesis
attempts to answer. These questions represent a focused view of
the motivation
behind the study presented in this thesis. The next section
gives an overview of
the thesis structure. It describes the remaining chapters in the
thesis and
-
28
introduces the focus and contribution of each chapter towards
the ideas presented
in the thesis.
1.4 Thesis Overview
This section gives an overview of the thesis structure. Figure
1.2 describes a
road-map for the thesis. The thesis can be seen to consist of
two parts, Part A and
Part B. Part A describes the research motivation, defines the
problem area in
terms of research questions and examines the related work that
has been carried
out to answer the research questions. Part B describes the
proposed and
implemented schemas that form the major body of the work in this
thesis.
Part A consists of chapters 1, 2, 3, and 4. It focuses on
explaining the motivation
behind the MA paradigm, its advantages and the paradigms
applicability in
different applications. It describes the security issues that
arise within a single
MA operation. Part 1 also examines the various approaches that
have been
proposed to counter the security issues that arise in a single
MA operation. An
analysis of these approaches has been performed with respect to
their advantages
and limitations.
Part B consists of chapters 5, 6, 7, 8, 9 and 10. It describes
the evolution of a
Mobile Agent Community (MAC) and presents two application
scenarios which
demonstrate the advantages of implementing an MAC based
application as
compared to a traditional Client-Server approach. Further, it
analyses the security
issues that arise in the working of MACs.
Part B also presents the proposed and implemented Integrated
Security framework
(ISF) for MACs. The ISF is composed of two schemas. The first
schema of the
ISF is a Self ExecutiNg Security Examination (SENSE) method
which acts as a
security mechanism at an individual MA level and the second
schema of the ISF
is the Buddy Model Schema (BMS) which secure the operation of
the MAs at a
community level.
-
29
Figure.1.2. Thesis Roadmap
-
30
Part B describes the implementation and operation of these two
schemas in detail.
It lists the advantages of these two schemas and analyses their
operation as
independent components before presenting the operation of an
integrated
architecture of the two schemas. The integrated version of the
two schemas is
referred to as the Integrated Security Framework (ISF). Part B
evaluates and
validates the operation of the ISF using different parameters
and by analysing its
effectiveness against other existing security mechanisms.
Finally, Part B
concludes the thesis with a listing of the thesis contributions
and a road map for
future work.
Chapter 2 presents a detailed introduction of the MA paradigm.
It traces the MA
paradigms evolution and compares it with other forms of code
mobility that are
prevalent. Chapter 2 also discusses the various levels of
mobility exhibited by
code and presents a differentiation among them. The chapter also
presents a
compendium of different definitions and various viewpoints that
attempt to
capture the energy behind the MA paradigm. It also describes
some of the popular
languages that have been used to develop MA toolkits and
compares their features
in gauging their suitability for the paradigm.
Chapter 3 gives a brief historical perspective of the
development of the MA
paradigm by tracing the evolution of various toolkits. The
chapter also surveys the
security features available in these toolkits.
Chapter 4 introduces the security concepts in terms of an MA
operation. It
attempts to define and describe some of the essential elements
of a secure
operation in terms of an MA scenario. The chapter compares the
advantages and
lists the limitations of the different security approaches. The
chapter presents a
critical analysis of the various security approaches that have
proposed to resolve
the issues behind the security problems faced by the different
entities in an MA
operation scenario. This chapter examines the advantages and
limitations of some
of the security approaches.
-
31
Chapter 5 describes the operation of an MA community (MAC) in
terms of the
various operations that are carried out by the members in the
agent community. It
presents the advantages of a community operation in terms of
different business
application scenarios. The chapter presents two MAC based
application scenarios
and uses them to investigate some of the various sources of
vulnerabilities that
may be witnessed in an MAC operation.
Chapter 6 describes the implementation of the SENSE method of
security that
enables MAs to carry out code tampering checks on their code,
while operating
away from their parent MoAS. The chapter describes the
architecture of the
SENSE method, explains its operation and enumerates the various
conditions
under which the effectiveness of the method can be harnessed to
the maximum.
Chapter 7 describes the implementation of the Buddy Model Schema
(BMS). The
BMS is used for securing the operation of MACs. The chapter
presents various
configurations of an MAC which implement the BMS. Further, the
chapter
enumerates the rules imposed by the BMS on the members of the
MAC. It
describes various scenarios of MACs and explains how the
implementation of the
BMS serves as a security mechanism in countering various
security issues that
arise in an MAC.
Chapter 8 presents an Integrated Security Framework (ISF) that
incorporates the
SENSE method and the BMS. The chapter describes the ISF
architecture and the
functionality of the security mechanism using sequence and
collaboration
diagrams.
Chapter 9 evaluates the two components of the ISF which are the
SENSE method
and the BMS. Using different experiments carried out on the two
schemas of the
ISF, the chapter analyses the operation of the ISF in an MAC
scenario. Further,
the chapter illustrates the advantages and limitations of the
ISF by comparing its
functionality with other existing security schemas.
Chapter 10 concludes the thesis. It summarises the contributions
of the thesis and
presents a short discussion on future work.
-
32
CHAPTER 2
THE MOBILE AGENT PARADIGM
This chapter traces the evolution of the agent paradigm from its
early beginnings
to its current form as a Mobile Agent (MA). It compares the MA
paradigm with
other forms of mobile code. The chapter discusses various
terminology associated
with Mobile Agent System (MobAS) toolkits and concludes with a
discussion on
the differences between a MA and a Mobile Object.
Parts of this chapter have appeared in Page et al [PPG05 and
PZI04b].
2.1 Introduction
Over the last decade and a half, the agent paradigm has seen
continuous
evolution. Various definitions have been proposed to identify
and isolate the
characteristics behind the motivation of the term agents.
Russell and Norvig
[RN95] broached the concept of artificial intelligent agents9.
According to them,
an agent can be anything that perceives its environment through
sensors and acts
upon the environment through effectors. A human agents eyes,
nose and ears are
his / her sensors and his / her arms and legs are the
effectors.
A detailed taxonomy that took Russell and Norvigs definition
into consideration
was Franklin and Graessers [FG96] study. Franklin and Graessers
paper lists the
various forms of agent-like behaviour exhibited by computing
systems. Using this
analysis they come forth with an agent definition that states An
autonomous 9 See page 1,Chapter 2 of [RN95]
-
33
agent is a system situated within and a part of an environment
that senses that
environment and acts on it, over time, in pursuit of its own
agenda and so as to
effect what it senses in the future.
Their view defines an agent as a system situated within an
environment that
senses it and acts upon it and consequently affects the agents
perception of the
future and influences its behaviour accordingly. From this
definition, it can be
inferred that an agent possesses two main characteristics. These
are autonomy and
intelligence. Other characteristics that have been identified
within agents are the
ability to be goal oriented, communicative, learning, flexible
and mobile [FG96,
WJ95]. [FG96] also distinguishes between an agent and a program
using the
example of a school teacher and a computer program. A school
teacher can be
regarded to be an agent but is not a computer program. Other
similar examples
are real-estate agents who act on behalf of the owner of a
property and are the go-
between the owner and the tenant. Software agents perform a
similar function.
They act as a go-between the agent owner and the external world.
They can
negotiate and make decisions on behalf of the agent owner. Thus,
they can be
regarded as authorized representatives of their owners. At this
point, it is
necessary to separate the word human from owners, as software
agents can also
own other software agents.
Bradshaw studied the evolution of agents as an ascription and a
description
[Bra97]. As an ascription, an agent can be regarded a distinct
entity based on the
character that was assigned to it. A description approach gives
a comparatively
specific view of the agent paradigm and is more popular with
agent developers.
This approach focuses on describing the various characteristics
that an Agency
has. Bradshaw considered the viewpoint and studies of several
agent researchers
including those of Franklin and Graesser [FG96] and Russel and
Norvig [RN95]
in documenting the evolution of the agent paradigm. Further, he
analysed the
motivation surrounding software agents.
According to Bradshaw [Bra97], software agents simplify
distributed computing
and overcome the limitations that arise from a human-computer
interface. From
-
34
the various discussions, it would not be incorrect to regard
software agents as
assistants that manage the affairs of their owners, especially
in carrying out
routine tasks. In order to perform their duties, software agents
exhibit various
characteristics such as autonomy and intelligence. Apart from
these
characteristics, software agents can also possess mobility.
Mobility in an agent is
described as the ability of the agent to transport itself from
one machine to
another machine [FG96].
2.2 The Evolution of the Mobile Agent Paradigm
2.2.1 Mobile Code Systems
This section describes some of different mobile code paradigms.
Since many of
these paradigms evolved from one another, differences between
them may not be
striking, however their orientation and behaviour does present
some interesting
points of study and comparison.
According to past and recent trends, four types of mobile code
systems are
recognised [Fis00, CLZ00]. They are as follows:
Client-Server; Remote Evaluation; Code-on-Demand; Mobile
Agents.
To understand the differences between these mobile code systems,
consider a
system of two machines as shown in figure 2.1. In the figure,
machine B is
responsible for providing the processing power in the system,
while machine A is
responsible for displaying the results of the computation
performed by machine B.
This is a simple division of functionality and results in a
cost-efficient outcome of
the computation and visualisation process.
In the Client-Server approach, machine A is the client and
machine B is the
server. The client sends a request to the server in the form of
a query. The server
-
35
processes the query of the client and responds with a result.
The response of the
server is received by the client and is used for further
computation.
Figure.2.1. Client-Server paradigm
Various forms of the Client-Server paradigm have been evolved
over the years.
Remote Procedure Calls10 (RPC) is one of the early forms of
implementing
Client-Server architecture in an application. While in the RPC
architecture, it is
possible that the client and the server role could be played by
the same machine,
for the purpose of this discussion they are regarded as separate
machines. The
client makes the RPC call to the server and waits for the server
to respond. The
server considers the clients RPC request and processes it. The
results of the
processing are returned to the client11. In Java the RPC
mechanism is referred to
as Remote Method Invocation (RMI)12.
Remote Evaluation (REV) proposed by Stamos and Gifford [SG90] is
another
form of mobile code. The major difference between the
Client-Server
architecture and the REV technique is that in the REV paradigm,
the client
machine initiates executing the code. Mid-way in its execution,
the code is
transferred to another machine which could be regarded as the
server. The server
completes processing the part required from it and returns the
results to the client.
10 Introduced by Xerox in 1981 (from Fis00). See Also
Implementing RPC Calls (Birrell and Nelson, 1984). A review
available at
http://www.deas.harvard.edu/courses/cs261/reviews/birrell-1984.html.
Date accessed 28/06/2005. 11 See also How RPC Works. Available at
http://www.cs.cf.ac.uk/Dave/C/node33.html. Date accessed
29/06/2005. 12 See also Java Remote Method Invocation. Available at
http://my.execpc.com/~gopalan/java/java_rmi.html Date accessed
29/06/2005.
-
36
Another well-known type of mobile code is Code-on-Demand (COD).
In this
approach, the executable code is stored on the server and is
downloaded by the
client in response to a request sent by it. Sun Microsystemss
Java Applet13
technology is a well known example of the COD approach.
The fourth type of mobile code system is the Mobile Agent (MA)
paradigm. An
MA can be seen to consist of three elements that can be
independently mobile
from one another [CLZ00]. These elements are data, code and the
execution state
of the program. The MA data refer to the internal variables that
are used by the
MA for its own computations. The MA code is the set of commands
that define
the functionality and behaviour of the MA. The third element in
an MA is the
execution state. In Java MAs, this is expressed in terms of the
program stack. The
stack holds the current instruction that is being executed.
Table 2.1 summarizes
the mobility aspects of the different forms of mobile code with
examples of each
type. These examples and their relevance have been explained
further in [FIS00].
Table 2.1: A Summary of Mobile Code Systems Paradigm
Examples
Data
Code Execution
State Client-Server WWW,EJB,RPC,
CORBA Mobile Static Static
REV Postscript Language
Static Mobile Static
COD Java Applets Static Mobile Static
MA MobAS Toolkits Mobile Mobile Mobile
2.2.2 Levels of Mobility in MAs
Based on the three different elements that exhibit mobility in
an MA, two levels
of mobility can be defined in the context of an MA migration
operation. These
levels are strong mobility and weak mobility [CLZ00, FPV98].
13 See Applets. Available at http://java.sun.com/applets/ Date
accessed 02/03/2005.
-
37
2.2.2.1 Strong Mobility
Strong mobility is exhibited by MA systems that support the
migration of code,
data and execution state from one physical machine to another.
On successfully
transferring it self from one machine to another, the MA is able
to resume its
execution from the point that it paused. To achieve this
objective, the capture of
the MA state in terms of the execution environments registers
and pointers has to
be performed. An example of an MobAS supporting strong mobility
is the
Telescript MobAS [Whi96]. The Telescript MobAS is described in
detail in the
later sections.
2.2.2.2 Weak Mobility
In some cases, the underlying execution environment or the
operating system may
not allow the MA to access its execution state in terms of the
registers and
pointers. Weak mobility allows the migration of only the MA code
and the data.
The MA state is not transferred and as a consequence, the MA
initiates its
execution from its first statement every time it migrates. Most
of the Java based
MobAS exhibit weak mobility. An example of a system exhibiting
weak mobility
is the Grasshopper MobAS [ghp01].
Since mobility of agents is highly dependent upon the
development language
supported by the MobAS, the next section describes some of the
popular
languages that have been used to implement MobAS toolkits and
develop MA
based applications. It describes some of the main features in
the languages and
focuses on the security aspects of the language.
2.3 Languages for MobASs
Every MobAS provides a language to developers for creating and
deploying MAs.
Karnik [Kar98] discusses the need for portability and
type-safety in a potential
MobAS programming language. Based on this aspect, several
scripting as well as
object-oriented languages have been used to develop and program
the MobAS.
Thorn and Versteeg [Tho97, Ver97], in different studies, have
examined the
-
38
suitability of several languages for MA development. While the
native languages
offer some security mechanisms for limiting the effect of
malicious programs on
the underlying system, security loopholes can still threaten the
applications due to
bad programming practices. This section analyses the security
features available
in some of the popular languages that have been used to develop
MobAS toolkits
and to program MA applications.
2.3.1 Telescript
In the early 1990s General Magic introduced the Telescript MobAS
[Whi96] and
also patented the term mobile agents [Mah97]. Telescript was an
object-oriented,
type safe language that had a syntax and structure similar to
that of C++ [Ver97].
It used a built-in class library for constructing agents. An
interesting feature was
that it emphasized object runtime safety [TV96]. This
requirement meant that
Telescript agents could not theoretically damage the underlying
execution
environment. This control was possible because the language did
not allow direct
access to program memory via pointers. The execution environment
provided
facilities for run-time checking, automatic memory management
and exception
handling.
Telescript classes could also inherit from super-classes. Key
words such as sealed
and abstract controlled the inheritance features in the language
[Tho97]. The
attributes of these classes could be private or public. From the
view point of code
mobility, Telescript supported process migration. This implied
that executing
processes could interrupt their execution, physically move from
one machine to
another and resume execution from the point they had stopped.
This was a major
advantage over other object-oriented languages that followed
Telescript and
supported code mobility as support for process level migration
is not provided in
them. However, in spite of these features, Telescript, which was
marketed as a
part of the Tabriz web-server project [Kar98] and was used in
the PersonalLink
service of AT&T [Gra04], could not gain commercial
success.
-
39
One possible reason attributed to its non-acceptance was that
programmers were
required to learn a new language i.e. Telescript for programming
the MobAS
[Kar98]. Other possible reasons for the failure of the
Telescript MobAS could be
that it could prove itself as an efficient and reliable
platform. These drawbacks
were somewhat reduced with the advent of Java [GM96] as it
gained acceptance
as the de-facto language of the Web. This is the reason why many
MobAS
toolkits14 support Java as an implementation language for
developing MA
applications [Bra97].
2.3.2 Java
Java supports the development of portable programs. This allows
developers to
extend their application designs and design web-based interfaces
for legacy as
well as new applications. The MA paradigm too, benefited from
this emerging
language and in the mid and late 1990s several Java based MobAS
toolkits have
emerged. General Magic re-developed the Telescript MobAS and
came out with
Odyssey [ody97], a Java based MobAS. Other Java based MobASs
followed.
ObjectSpace came out with Voyager [voy03], IBM developed the
Aglet MobAS
[LO98], Mitsubishi unveiled Concordia [WPW+97, WPW98] and IKV
developed
the Grasshopper MobAS [ghp01].
When compared to C++, Java combines the advantages of
object-oriented
programming and reusability, and does away with the
disadvantages of pointer
arithmetic, unrestricted casts, unions and features such as
unstructured GOTOs,
operator overloading and multiple inheritance.
Security in Java is implemented using the Sandbox model [Gon98,
Ven97]. The
Sandbox model implements the notion of a restricted area in the
memory where
non-trusted code can be executed with reduced privileges.
Differentiation between
trusted and non-trusted code is performed on the basis of
digital signatures that
are used to sign the MA code. If the MA code is signed with a
digital signature,
14 For a list of different MA toolkits, see AgentBuilder
ToolKit. Available at
http://www.agentbuilder.com/Documentation/brochures/ABProBrochure.pdf
Date accessed 10/07/2003.
-
40
then it is allowed access to system resources based on its
authorisation level. If
the code is unsigned or the signature on the code is invalid,
then the code is
executed within the Sandbox. Figure 2.2 describes an overview of
the Java
security model.
Figure.2.2 Overview of the Java security model
The major Java classes that implement language safety and
security checks on a
Java application are the ClassVerifier, the ClassLoader and the
SecurityManager.
These classes form the base of the Java security architecture
and prevent
malicious or buggy code from gaining access to the execution
environment and
disturbing it. The execution environment is called the Java
Virtual Machine
-
41
(JVM). However, in spite of these security checks, it is
possible that malicious
code may pass through and crash the JVM. LaDue [Lau97] and Dean
et al
[DFW96] discuss several scenarios where in malicious code is
able to by pass the
Java security mechanisms. A well-known technique of by passing
the Java
Sandbox is embedding native code with in the Java code
[Ven97].When the Java
program executes a statement written in C++, the Sandbox
mechanism is by
passed as the C++ statement is not converted into Java
byte-codes and the JVM is
designed to check only Java byte-codes.
Since malicious mobile code, like Java Applets can damage the
host system
[Lau04, Mah00] they are subject to several security
restrictions15 such as not
being allowed to make native language calls. Since MAs do not
extend the Java
Applet class, they are not subject to the security restrictions
imposed on Applets
and can make calls in native languages such as C++.
2.3.3 TCL /TK
The previous two sections described Telescript and Java, two
object-oriented
languages and examined their in-built features with respect to
creating and
executing secure code. This section examines the Tool Command
Language /
Tool Kit (TCL/TK) [Ous94a], a scripting language that also
evolved in the early
1990s and is currently an open source project16. TCL statements
are generated
using TCL commands. While some of the TCL commands are built-in,
others can
be created using the API and the TK library. Further, since TCL
is an interpreted
language, it is comparatively safer though slower than native
languages such as C.
Safety and security features in the TCL language are controlled
by the Safe-TCL
mechanism [LOW97]. This mechanism is based on the Padded-cell
concept, very
similar to the Java Sandbox technique. By using the Safe-TCL
mechanism, it is
possible to differentiate between trusted and non-trusted
scripts. The Safe-TCL 15 See The Java Tutorial, Security
Restrictions, Available at :
http://java.sun.com/docs/books/tutorial/applet/practical/security.html,
Date accessed 07/03/2003. 16 See TCL Developer eXchange, TCL/Tk,
Available at : http://www.tcl.tk/software/tcltk/ Date accessed
04/05/2005
-
42
mechanism uses safe-interpreters and aliases for implementing
access and
resource control. Safe interpreters provide executing scripts
with controlled access
to resources. Aliases are used within the interpreters to
restrict access to system
resources. Thus, using aliases, it is possible to have different
resource control
mechanisms within the same interpreter. Another advantage that
TCL shares with
Java is that it does not have pointer arithmetic and program
access to memory is
restricted. Further, array references are bounds checked. These
features made
TCL an attractive language for programming and deploying MobAS.
Agent TCL
(now known as DAgents) [Gra95, Gra96] was a TCL based MobAS. The
next
section describes some of the terminology associated with MobAS
toolkits.
2.4 MobAS Concepts
This section describes the major standards committees that were
formed to
standardize MA concepts. It describes some of the MA related
terminology that
was proposed by these committees.
2.4.1 Terminology
The emergence of several MobASs led to the need of standardizing
the
terminology and the concepts associated with the paradigm. The
Object
Management Group (OMG) [MBB+98] came out with a draft that laid
down the
specifications for some of the common terminology associated
with MobASs.
In January 199917, another committee was formed to develop
standards for
MobASs. It was called the Foundation for Intelligent Physical
Agents (FIPA)18.
The objective of the first FIPA meeting was to standardize
architectural concepts
of agents. However, the standards approved by FIPA did not
gather much support
from the developers of MobASs. Grasshopper was one of the early
MobASs that
was made MASIF compliant19 and also implemented the FIPA
standard20. Even
17 See Page 34 of [FIS00] 18 See
http://www.fipa.org/resources/livesystems.html Date accessed
03/05/2005 19 See Page 13 and Page 22 of [ghp01]
-
43
though support for the FIPA standard was later withdrawn, the
Grasshopper
MobASs compliance to these standards makes its security features
interesting for
study and analysis. The terminology and concepts introduced in
this section have
been defined by MASIF and are implemented in the Grasshopper
MobAS.
2.4.1.1 Agent States
During its lifetime, an MA can be in any one of the possible
states at any time.
These states are active, suspended and flushed21.
An MA is in an active state if it is currently executing and
communicating with
other entities. It goes into a suspended state if its execution
is interrupted. In a
suspended state, the MA cannot be contacted by other entities
and cannot receive
or react to any communication sent to it. An MA in a flushed
state implies that the
MAs information is stored on the hard disk. The MA itself is in
a state of
suspended animation and can be reactivated in response to
incoming
communication [ghp01].
2.4.1.2 Place
A Place implements a logical grouping of services that may be
made available in
a MobAS. For example in the Grasshopper MobAS22, functionality
can be
bundled together and served to the MA through a Place. In other
words, MAs
interact with the Mobile Agent Server (MoAS) via Places. The
Information Desk
is the default Place that is created in a Grasshopper MobAS.
2.4.1.3 Agency
An Agency is responsible for managing a group of Places and thus
indirectly
hosts the MAs. The Agency is also responsible for hosting the
communication
service and the security mechanism of the MobAS.
20 Also see Grasshopper: A Platform for Mobile Software Agents.
A