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
