O. M. Paracha Thesis_signed

A SECURITY FRAMEWORK FOR MOBILE AGENT SYSTEMS

A Thesis Presented to

Mohammad Ali Jinnah University

In Partial Fulfillment of the Requirement for the Degree

Master of Science (Computer Science)

by

Omer Mansoor Paracha May, 2006

Abstract Agent technology is a novel approach for the development of distributed systems. In particular, mobile agents can provide much greater flexibility and robustness than the traditional distributed system methodologies since they provide mobility from platform to platform. Thus, they form a vast area of research. One key problem faced by the mobile agent systems is security. A migrating agent can face many threats while migrating to a host/ agent platform. Similarly the platform can be maliciously affected by an agent. A number of different approaches have been suggested in the literature to deal with security of mobile agents. In this thesis, we present an overview of such threats and present an "agent threat model" for mobile agent systems. Based on this model we survey and evaluate the techniques that provide countermeasures to the mobile agent systems. Based on the techniques surveyed, a state-of-the-art is evaluated and the security of certain mobile agent systems is discussed. The thesis presents a proposed framework to provide mobile agent system security from both malicious mobile agents and platform. The idea is to provide a solution to the requirement of a security framework that provides security as a combination of components based on techniques for mobile agent system security and protection. The proposed framework is comprised of various components that are studied in the light of operation scenarios. An implementation of the system is discussed and the evaluation of the proposed framework as well as a comparison with the state-of-the-art mobile agent systems is provided to highlight the strengths and weaknesses.

iv

Acknowledgements The completion of a long and tough journey in the form of my Master’s thesis would not have been possible without the remarkable support and supervision of Dr. M. Jaffar-urRehman whose memory and guidance lives long with me. Hoping that my thesis and my research work has met his expectations; this thesis is dedicated to him. I also thank Mr. Aamer Nadeem for his great advice during the course of my thesis, especially during the end of it. I thank him for his time, his comments and those helpful sessions discussing my work, without which this thesis would never have been completed. I thank the members of the Centre for Software Dependability (CSD), their help and their massive inputs that constructed and gave life to the work in this thesis and being like a family to me. I would specially like to thank Mr. Masud Khokhar for introducing me to the topic and advising me immensely in drawing out my proposed framework. Thanks to Mr. Uzair Khan, Mr. Shaukat Ali, Mrs. Zille Huma and Mr. Zouhaib Zafar for sharing their thesis-writing experiences. I thank the faculty, the students and the staff of Mohammad Ali Jinnah University for helping me achieves my goals. The faculty has always been available for a lot of help and guidance. I especially thank Prof. Zafar I. Malik for his immense support throughout the course of my thesis. His advice and his heart-lifting comments are duly appreciated. The staff is cordially appreciated, especially for the CSD lab and its facilities that let the research process flourish. I would also like to thank all my friends for their moral support, especially my old batch mates from my undergrad (the BS-6). I specifically thank Mr. Shahid Ishtiaq, Mr. Waqas

v

Mahmood, Mr. Ifraseab Afzal, Mr. Waqas Javed, Mr. Ibraheem Zaman, Mr. Raja Asad and Mr. Waqas Raza for removing all the writer’s blocks I faced. I also appreciate, Mr. Abeer-ur-Rehman for sending a very handy gift during my write-up. Also, I thank Mr. Wajahat Nosherwan for his comments on the proposed framework and the numerous discussions on the whiteboard in the CSD. I thank my family especially my parents who believed in me and gave me strength to progress in my education, my father for his counseling on living life and my mother for her prayers. My brother and sister for staying up with me on my long nights and not letting me fall asleep. I am extremely grateful for their patience and their high-spirits that helped me focus through many difficult times during the course of my educational life. My family has been an astounding inspiration to my research work. I thank Allah (SWT) for bestowing me with His uncountable blessings that are far too many to mention here.

vi

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

vii

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

viii

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

ix

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

x

List of Tables TABLE 4.1: PROTECTION OF THE MOBILE AGENTS ...................................................................................... 51 TABLE 4.2: PROTECTION OF THE AGENT PLATFORM .................................................................................... 52 TABLE 4.3: PROTECTION OF THE MAS NETWORK ....................................................................................... 52 TABLE 5.1: MOBILE AGENT SYSTEM SECURITY EVALUATION – MOBILE AGENT PROTECTION ................. 105 TABLE 5.2: MOBILE AGENT SYSTEM SECURITY – PROTECTION OF THE AGENT PLATFORM ....................... 106 TABLE 9.1: EVALUATION OF THE PROPOSED FRAMEWORK ........................................................................ 154

Chapter 1 Introduction

Software systems have advanced immensely with the technology march with special regard to expansion of systems over a distributed concept. Various approaches for development of software systems especially distributed systems have come into existence. This advent of distributed system application and performance has lead to many research dimensions and topics. Since distributed systems require immense communication between its components or subsystems and the information that they share is considerably large in amount, approaches to access, search and access of this is vital. So, for this, various theories for communication and information retrieval exist. Distributed systems came into existence so that a wider network could be used for information sharing and also for service access. A large number of applications were derived from this ability to scale a large area and distribute information and service. Distributed systems become vitally important due to their function. However, the function and capabilities are vast and the requirement from such systems becomes larger. Features of such systems make the system different in construction and operation. Performance issues include the issues of extensive reliability, like fault tolerance, safety and security. Of these, one important issue is the security of software. When software

1

goes distributed, it becomes potentially more prone to network insecurity and threats. Thus, it is very important to assess the threats and insecurities that the system might undergo during its lifetime and, that the system can somehow prevent the occurrence of attack. Mobile agents are an innovative idea in the field of distributed system research (Kotz, Gray & Rus, 2002). They are basically autonomous units of code and state data that can migrate from host to host for remote processing. Their capabilities are immense in comparison to normal remote procedure calls and remote processing as they themselves carry the process and data but use the remote host’s capability to carry out the execution. The uses of agents are many as their prime propose is in their name. They are actually representatives for cyber-users. Mobile agents may be characterized as “good” agents that carry out tasks for us on our behalf remotely, for example an agent to purchase a book online. The agent looks for the book on different hosts and purchases the one that fits the criteria like its cost or its required stock. Also, there may be “bad” agents, like viruses and worms that can go online and travel to hosts to damage them or spy on them. As agents are composed of code and data it can use this for virus like activity. Mobile agents and their activity may be malicious or it may be attacked by the host it is supposed to execute on, meaning that the host is malicious. Also, both agent and host may be “good” but the network may be comprised of hackers. This means that the network is insecure and liable to attacks in its route. Our aim is to create a framework to insure secure agents and hosts (Jansen & Karygiannis, 1998). The framework that has been suggested deals with primarily the security. The prime aim in abstract is to allow “good” mobile agents and disallow “bad” 2

mobile agents on the host and to protect the mobile agent from the host’s activity. The agent has to send its processed information back to the host from where it came from along with its execution log containing the entire trace of its execution on the host. Also, the use and access of resources has to be taken into consideration. The framework accommodates the protected resource use by the visiting mobile agent. The thesis is arranged as follows: Chapter 2 covers the background to Mobile agents, their theories and to their applications as well as giving the concepts of security that is required in mobile agent systems. Chapter 3 presents the Threat Model that accommodates the various threats that occur in a mobile agent system i.e. to the agent and the agent platform. Chapter 4 surveys the countermeasures and techniques in the literature on mobile agent security and is evaluated to see what threats are protected by these measures using the threat model. Chapter 5 covers the various state-of-the-art mobile agent systems and describes their security architectures and evaluates these on the basis of the techniques that are used for security from Chapter 4. Chapter 6 details our proposed framework and describes its components and subcomponents. Chapter 7 describes the various operation scenarios to check their security of our proposed framework. Chapter 8 describes the implementation issues of our proposed system. Chapter 9 evaluates our system and lists down the benefits and limitations of the proposed system using the threat model and also a comparison with other state-of-the-art mobile agent systems. Chapter 10 concludes the thesis and provides some research directions.

3

Chapter 2 Mobile Agent Systems Security: A Background

This chapter gives the background that is required for mobile agent system security. It covers the different theories that are available in the literature on mobile agents and mobile agent systems in general.

2.1 Remote Code Execution Taking the generic client server model, a set of traditional approaches to remote processing can be discussed. The client server model generically contains a client that issues a request to be processed by the server on its behalf. The server then processes the request and responds as required. For this kind of communication model, approaches for remote code execution were developed (Aneiba & Rees, 2004; Picco, 2001). The approaches for remote code execution are Remote Procedure Calls and Remote Evaluation (Lange, 1998; Rothermel & Schwehm, 1998).

4

Code can be accessed simply by calling the procedures like through RPC (Remote Procedure Calls) and through REV (Remote Evaluation). In RPC, the methods are invoked by the agent through method calls. Client is the caller whereas the server is the callee. The server responds by sending the results of the procedure execution back to the client. In REV, the method is downloaded to the client by the server and it executes there. Here, there are two further approaches; one is that the client may call the code for download and execution. The other is that the code may be sent by the server to be executed on the client according to the server. The first approach is remote execution where as the second is code-on-demand. In contrast we have software agents that can be mobile, i.e. mobile agents that can carry out remote code execution and overcome the limitations that traditional approaches have (Rothermel and Schwehm, 1998).

2.2 Software Agents To understand what software agents are, we have to understand what agents are. As defined in various papers, agents are best defined by Franklin and Graesser (Franklin & Graesser, 1996) that highlights the notion of what agents are according to various definitions that people defined. However, the best understanding was found in the definition that was derived in (Lange, 1998) that the definition of an agent is based on which perspective we are elucidating its nature. Generally, an agent is a representative for a user that has been delegated some work. As stated before the debate becomes rather immense (Franklin & Graesser, 1996) and the requirements of an agent and its actual meaning becomes too narrow. Thus, the definition needs to be broadened and the definition from (Lange, 1998) is rather complete by which we adapt our definition of an 5

agent; an agent is a delegate or a representative that can operate in an environment, is reactive, autonomous, goal-driven, continuous, communicative, mobile, learning and believable. Agents may possess all of these or some of these characteristics (Sundsted, 1998). From this definition of an agent, we can define what a software agent is. A software agent is basically an object possesses all of the aforementioned characteristics. Rothermel and Schwehm in (Rothermel & Schwehm, 1998) classify software agents. From this classification and the classification done in (Franklin & Graesser, 1996) we understand that due to the features of a software agent, the agent can assume a number of forms. In this thesis, we take the mobile agent class of software agents.

2.3 Mobile Agents After explaining software agents, the class of mobile agents does not require much of a formal definition. However, we do explain mobile agents and their context in the rest of this thesis. A mobile agent is an agent that can simply carry out our tasks for us as users remotely. By remotely, we can mean many other remote locations. A mobile agent is thus simply one that is created at one place, carries its code and state over to another place and resumes its execution.

It does not require the remote code execution

approaches for this; instead it propagates itself over the communication network to carry out its tasks (Lange, 1998). To explain what a mobile agent is, we have to understand certain basic concepts. As explained by (White, 1998) and (Milojicic, LaForge & Chauhan, 1998) a mobile agent system has agents and places. A place is where the agent visits in its journey. At each of these places, there exists an agent environment to allow its execution. The environment 6

allows processing on the basis of a policy. Of course, the underlying features that define the agent and the place implementation differ in its state-of-the-art as various mobile agent systems implement the features differently. (Marrow & Ghanea-Hercock, 2000) define the mobile agent computing approach and give the features of the actual setup and features that are required. Traced from what has been discussed and by (Marrow & Ghanea-Hercock, 2000) mobile agents have certain fundamental features. Taking a general idea that a mobile agent moves from place to place, a mobile agent requires the elements of mobility, communication and task association. A mobile agent is fundamentally mobile and can migrate from place to place as specified. Similarly, a mobile agent needs to communicate and co-ordinate with agents and the execution environment to execute. Lastly, an agent needs to be associated with a specialized task to perform on the behalf of the creator of the agent that it is representing.

2.4 Mobile Agent Benefits Mobile agents along with their features can thus provide a number of benefits to distributed and component based systems and technology (Kotz & Gray, 1999). Their applications due to these benefits are thus numerous. As explained in a lot of papers, mobile agents have large potential. To assess this we highlight the benefits from mobile agents that are mentioned in the literature. As expressed by (Lange & Oshima, 1999), there are several good reasons for mobile agents. These are listed as follows:

1) Network load is reduced because multiple interactions are not required between the server and the client like in traditional approaches. Instead, a mobile agent carries the

7

complete set of interactions to the server. The agent executes the commands locally and thus reduces the set of instructions that had to be sent. Also, for a large amount of data, transmission over channels is rather expensive; hence the mobile agent using the data locally reduces the network load.

2) No delays are witnessed as the mobile agent executes at the point of execution. For example, in the traditional approaches, a large amount of wait had to be done for a command to be processed and responded to. In the case of mobile agents, an agent is actually sent there and the wait time is reduced.

3) Protocols do not need to be enhanced for mobile agents that are migrating and they can utilize the protocols at hand as for other mechanisms the protocols need to be upgrade according to the specification of the communication required.

4) Autonomous execution makes the mobile agent independent of the creator. This is favorable for the example of limited devices like mobile devices. The agent moves to the server, executes and the device collects the agent later.

5) Dynamism is enhanced as the mobile agents can be adapted according to the environment that is given to them.

6) Heterogeneity is provided because the underlying specification is independent to the mobile agent allowing better integration of heterogeneous systems and environments.

8

7) Robustness is achieved because dynamism allows agents to be configurable as the environment suggests, this also makes them fault-tolerant if required.

2.4.1 Mobile Agent Applications

Now we discuss the applications that are possible because of mobile agents.

2.4.1.1 Telecommunication

In the field of telecommunication, mobile agents can use their advantage in reduction of network bandwidth and can enhance these for several network services that future or next-generation telecommunication networks (Pham & Karamouch, 1998).

2.4.1.2 Network Management

Mobile agents can be used to evolve current client/ server based network management approaches to a more distributed approach (Pham & Karamouch, 1998).

2.4.1.3 Information Retrieval

Mobile agents can be used for retrieval of information over a network and the Internet. The mobile agents can carry queries and can retrieve particular information (Pham, 2001). This can be extended for cache management and searching as well.

2.4.1.4 Others

There is other work in progress in many dimensions as seen in the literature on them. Mobile agents can be used in Global Information Systems for tracking, in Grid Systems,

9

in Intrusion detection systems, for distribution of multimedia and so on. Also, agents have a broad research potential (Kotz, Gray & Rus, 2002).

2.5 Mobile Agents Limitations Mobile agents have their immense applications and there are several benefits because of them but they still have their limitations. Their possibilities are hindered by several challenges (Schoder & Eymann, 2000). Some of these are limitations to the technology and some are because there are missing solutions to numerous issues that arise in mobile agent systems concepts and design (Rothermel, Hohl & Radounikilis, 1997; Kotz & Gray, 1997). Various authors have written about the mobile agent dimension limiting and the reasons that cause the limitations to their adoption (Gray, 2004). Also, the reason has been highlighted as because of applying it in the wrong regard despite having a clear concept to their use (Johansen, 2004). For this the reasons listed in (Vigna, 2004) define the limitations and their reasons quite well. The listed reasons are:

1) Performance issues can be limiting. A generalization states that agents may reduce network bandwidth consumption and so on, but this is not true in every scenario.

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

10

3) Implementing agents is also hard work as so many unpredictable interactions are present in its journey to so many places consisting of adverse environments.

4) The testing and debugging of such systems are extremely complex. This is due to the fact that the approaches become so unpredictable.

5) Authentication can be based on so many things the agent is associated with. For this the authentication mechanism may be weak.

6) Corruption of the agents is possible as the agent transfers over the various places it visits. This means an agent can lose its information or actually deviate from its goal.

7) Since information might be lost, the agent cannot be trusted with secret information either. The information can be leaked on its way.

8) A mobile agent requires a setup or an infrastructure to actually perform. A system that bases itself on mobile agents would require that all the places can execute the mobile agent.

9) Mobile agents in order to interact require a sort of mechanism, a means to interact and to collaborate; there is a lack of such an approach, such a language that supports this mechanism.

11

10) Mobile agents remotely execute at one place and go to the next; this is very much like a worm that actually can cause so much damage to the system if they are allowed to process.

2.5.1 Mobile agent security

Of all the above, security is one of the greatest weaknesses to a mobile agent. Security alone is a large reason for the lack of use of agents for providing the solutions they promise (Li, Zhang, Sun & Yin, 2004). A huge amount of research material is available that has either raised the notion of security of mobile agents or has tried to solve it in one way or another. The notion of mobile agent security is because the mobile agents that are roaming a network can be used as malicious objects for accessing private or confidential information and resource, for causing corruption like viruses and worms and so on. Similarly, in this regard if an agent is supposed to be correct and non-malicious, we are never sure that the place it is visiting may be malicious to it or not and may also leech information from the agent, corrupt it or even use it for its malicious purpose. The lack of security has been highlighted mainly because of a lack in approach to so many things that have to be secured about a mobile agent system. A mobile agent system thus lacks approaches because of a lack of a security providing framework that will fulfill the end to end security requirements of the agents and the places.

12

Chapter 3 Mobile Agent Systems Security - Threat Model

This chapter looks into various security threats and the aspects that may be malicious in a MAS. Also, a MAS threat model is presented that denotes the threats that an MAS may comprise.

3.1 Overview of MAS Security Threats Threats to a mobile agent are an area of fond interest as they stand out to the acceptance of mobile agent systems for various applications. The vulnerabilities alone have cause immense interest in the field of security of distributed systems. Various goals have been highlighted to protect a system out of which some have a substantial solution and some do not (Abdalla, Cirne, Franklin & Tabbara, 1997). This chapter identifies the threats that occur in a mobile agent system so that a MAS can be evaluated according to the threat that they countermeasure.

13

The threat model has been derived from the various papers discussing the countermeasures to the threats. However, (McDonald, Yasinsac & Thompson, 2005) derived threats to the MAS. In this model, we generalize the threats to the MAS and create our own threat model. Also, the threat model includes threats from a malicious network not present in (McDonald, Yasinsac & Thompson, 2005). The security of mobile agent systems encompasses protection of the mobile agent, the platform and the network (Greenberg, Byington & Harper, 1998). Thus, the work on security in mobile agents can be classified in to three broad categories (Gray, 1997; Brooks, 2004): •

Malicious Agent Platform and environment

•

Malicious Agent

•

Malicious Networks

3.1.1 Malicious Platform

Malicious platform security is necessary so as to defend the agent and the spawning host from any platform to which the agent is transferred to. This includes various security threats like spying on the agent and its data, masquerading or posing as a correct platform and also the corruption or misuse of the agent (Farmer, Guttman & Swarup, 1996b; Kun, Xin & Dayou, 1999). Similar to this, other agents may harm the incoming agent(s) and so may the environment (Kun, Xin & Dayou, 1999).

14

3.1.2 Malicious Agent

The protection of the platform on which the agent is executing has to be protected as well (Farmer, Guttman & Swarup, 1996b). This is because the agent may act like a virus and may corrupt the platform or can act as a Trojan and can spy on the platform and its resources (Kun, Xin & Dayou, 1999).

3.1.3 Malicious Network

This security deals with the network on which the mobile agent is transferred to other platforms (Farmer, Guttman & Swarup, 1996b). The networks can be tampered and insecure channels may be created luring agents and corrupting them and may also allow the spying on the agents themselves (Kun, Xin & Dayou, 1999). The framework supposes that the network being considered is secure.

3.2 The MAS Threat Model The different types of threats that the MAS would encounter according to 1) malicious platforms, 2) malicious agents and 3) malicious networks are as follows. Like (Jansen & Karygiannis, 1998; Jansen, 2001; Jansen & Karygiannis, 1998), we use simple mobile agent architecture to identify the threat model shown in Figure 3.1. The arrows indicate an underlying network that carries the mobile agent. The host O spawns a mobile agent A to an agent platform X for execution. The mobile agent A continues its execution to agent platform Y and so on. The three major security considerations can be expressed here, the malicious platform, malicious agent and the malicious network. This threat

15

model is used to evaluate the techniques involved (Orso, Harrold & Vigna, 2000; Saeb, Hamza & Solimon, 2000).

Figure 3.1: A Simple Mobile Agent System

3.2.1. Masquerading

Masquerading involves: 1) an agent pretending to be another, 2) an agent platform to be another, 3) the platform’s services to be pretending to be an agent.

Agent to Platform

An agent may be bluffing an agent platform to be another agent maybe to gain unauthorized access or to prove another agent wrong in case of access so that the agent it is posing to be is blocked (Jansen & Karygiannis, 1998).

16

Agent to Agent

An agent may pose to be another agent to another agent to gain trust and thus acquire private information.

Platform to Agent

Another case is when the agent platform poses to be another platform to the agent. The aim is to lure the agent into its domain and to extract information or to alter it and so on.

Other services to platform

Other services on the platform may masquerade as an agent to gain access to certain services authorized for agents. This can happen with third party services deployed on a platform.

3.2.2. Denial- of-Service

DOS attacks are prevalent in network systems that are providing different services and information. In MAS, DOS attacks may prevail through mobile agents, the platform or other services on the platform.

Agents to Platform

Mobile agents start consuming resources during execution, so the other agents trying to acquire those resources are blocked.

17

Agent to Agent

Also an agent may block another agent by overloading it with messages or into an infinite conversation loop.

Platform to Agent

A platform may deny service to agents. This means not allowing them to execute, delaying agent requests and responding late or ignoring them entirely or even disposing the agent (Jansen & Karygiannis, 1998).

Other Services to Platform

Other services on the platform may also deny the platform its service like the underlying operating system or even communication services for the agent.

3.2.3. Unauthorized Access

Mobile agents, agent platforms and other services may try to access each other illegally. They may try to access certain services or information for which they are not authorized.

Agent to Platform

Agents may try to access the platform and its resources (meaning the platform’s data or services) illegally. The agent thus violates a certain security policy or right that it has on the platform.

18

Agent to Agent

The agent may be accessed maliciously by another agent as well and may thus hinder its execution by access of its public methods.

Platform to Agent

The agent platform may access the agent and hinder the say it executes.

Other services to platform

Other services, like remote users or processes may also try to access the platform or agent through unauthorized means. They may thus hinder the operating system etc on the platform corrupting its environment.

3.2.4. Repudiation

This type of threat appears when an agent completes an execution and denies that it ever occurred (Jansen & Karygiannis, 1998).

Agent to Platform and Agent to Agent

An agent may deny that it ever executed on a platform to regain resource or regain information or to replay its execution but n a similar but different unauthorized resource and so on. The agent may also repudiate another agent similarly.

Platform to Agent

Also, the platform may also deny that the agent ever executed for its own malicious purpose. For instance, it may bluff the origin host that the agent ever came and executed. 19

This may be because the platform may have just spied on how the agent executed and did not allow return of information to the host or may have tampered with the agent claiming to others that the altered agent is its own and to the host that the particular agent never came.

3.2.5. Eavesdropping

During any communication, it can be overheard and misused by others.

Agents to Platform

Agents may eavesdrop on the platform to gain information of other transactions as well as on agents to spy out what information is being exchanged and so on. This information can be thus misused further to lure the agent or to gain access to what kind of activity the agent was sent by the spawning host.

Platform to Agent and Agent to Agent

In the case of mobile agents, the platform and the agents may be eavesdropping on agents executing on the system for their data.

3.2.6. Alteration

Alteration is when something in the entire system is changed maliciously (Beirman & Cloete, 2002). This threat is again twofold.

20

Platform to Agent and Agent to Agent

An agent may be altered by the platform and may thus be corrupted. This can make the agent malicious by a malicious platform. The agent may for example start sending data back to the platform that altered it instead of the host. Also, an agent’s itinerary or its travel path may be altered so that the agent route is beneficial to the altering platform.

Agent to Platform

Also, in extreme cases, the agent or agents may together corrupt the platform or its environment, like viruses, worms and Trojans. This is thus the case when both the host and its spawned agents are malicious. Similarly, the agent can start altering the code of the other agents running on the agent platform.

3.2.7. Copy and Replay

As the name suggests, the information can be copied and reused or replayed later for malicious purpose (Beirman & Cloete, 2002). This can be used by agents, platforms and the other services on the platforms as well.

Platform to Agent

An agent on an agent platform can be copied or its message can be copied and can be replayed later on for malicious purposes. An agent can be then used by the platform for its own use and activity like gaining insight into other platforms. Also, the agent messages can be copied by the other services and can be used maliciously to gain access of resources that may be unauthorized to the service but authorized to the agent.

21

Agent to Platform and Other services to Platform

Copy and replay can be used to resend a message over and over again to regain resources that may only be issued one at a time for competing agents and services on a platform. This can be utilized by an agent, a platform or the other services maliciously.

22

Chapter 4 Survey of Countermeasures for Protection of Mobile Agent Systems

This chapter surveys the various countermeasures for the threats that a MAS may encounter from attacks presented in the threat model. The evaluation of each technique to protect the MAS is evaluated with respect to the threat model in chapter 2.

4.1 Countermeasures Overview Mobile Agent Systems are prone to numerous threats from attackers over the network. An agent is created, executed, allowed resource access, migrates, and communicates with other agents or the platform (Abdalla, Cirne, Franklin & Tabbara, 1997). These activities in a MAS are all prone to various threats. Security threats have limited the use of the mobile agent systems and have opened a door towards the suggestion of countermeasures or the potential solutions to the security threats. These solutions have 23

caused immense theoretical interest over the years, with various levels of effectiveness (Li, Zhang, Sun & Yin, 2004). Some of the threats have been tackled by these including some solutions that are difficult and some are still either not solved or not possible because of either current technology limitations, have too many assumptions or are just not doable according to theory (Farmer, Guttman & Swarup, 1996b). The MAS is comprises of the mobile agent, the mobile agent platform, where the agent executes and the underlying network that carries the agents from platform to platform. These thus form the three broad areas where harm may be done to the MAS. So, the techniques are divided into three groups. The grouping is done according to (Jansen, 1998a; Jansen & Karygiannis, 1998; Beirman & Cloete, 2002; McDonald, Yasinac, Thompson, 2005). This work is extended in this survey to include more techniques and to analyze these techniques according to the threat model. Another contribution is that the techniques to protect the network have been surveyed that were not present in (Jansen, 1998a; Jansen & Karygiannis, 1998; Beirman & Cloete, 2002; McDonald, Yasinac, Thompson, 2005). Also, an evaluation of the presented techniques is done at the end which was not in the other surveys.

4.2 Agent Protection Agents are threatened by their surroundings, like the agent platform, other agents (Vigna, 2004) and the execution environment of the platform they are running on (Chess, 1998; Jansen, 1998b). To cater for the threats caused by these entities of the MAS, various countermeasures have been suggested in the literature. This section gives a survey of the work on the agent protection.

24

4.2.1 Partial Result Encapsulation

Mobile agent execution result data needs to be secured as it may be very critical or important. Thus, the data needs to be encapsulated from possibly malicious outsiders. Various techniques exist for the result data’s protection as the results are hidden as they are generated (Tschudin, 1999). One of these approaches is highlighted in (Young & Yung, 1997) by using Sliding Encryption. The data computed at various agent platforms is encrypted by the agent and carried with it. This data is then decrypted at the origin (host) of the mobile agent using a private key. (Yee, 1997) describes the PRAC technique which uses checksums for the computed data. The checksums are formed using a secret key by the agent. This key is generated for the agent and the data at the host. The data is thus encrypted when the agent migrates and the key is destroyed. So, the only remaining copy of the key is with the host. (Karnik, 1998) gives a use of read-only states that allow only the access of agent’s integral data. This state locks the data within the agent from all others except its owner. The owner is authenticated by simple digital signatures and can thus modify it as needed. Also, it uses append-only logs within the agent to carry data that cannot be modified during the travel. It keeps appending the data that is collected at each platform. For this data it uses a simple encryption scheme.

Analysis

Result encapsulation involves the protection of agent data from the agent platform. Masquerading of the platform and the other agents is prevented as the agent data can only be decrypted by an entity that possesses the key to access the mobile agent’s data. 25

Since this data is encrypted, it cannot be eavesdropped on for any purpose as well. Access is authorized through the key. This data is accessible by platforms for viewing purposes; hence generally the data is not alterable. However, if the key distribution mechanism is weak, a malicious platform may masquerade as another. Thus, anyone with a key will be able to access the results and may even be allowed to alter them, if there is no way of making the agent data readonly. An agent cannot guard itself from denial of service on a platform through partial results encapsulation. Similarly, since no history is maintained, repudiation cannot be solved either. An agent cannot be protected from copy and replay. An agent message can still be copied. However, the message meaning may be locked inside the agent’s encapsulated data, so it partially protects the agent.

4.2.2 Environmental Key Generation

This technique involves the agent to generate a key for its own access to the platform if certain conditions are met. (Jansen, 1998a; Jansen & Karygiannis, 1998; Beirman & Cloete, 2002; Bellavista, Corradi, Federici, Montanari & Tibaldi, 2003) describe the encryption of the data that an agent carries and it only decipherable according to a key. When the agent reaches a platform, it searches for the required information on the agent platform. If this information is found, it is used to generate a key. This key in turn decrypts the agent information and thus the information is accessible. This has also been called the clueless agents approach by Tsuchudin in (Tschudin, 1999) as the agents have no clue until and unless a particular environmental condition becomes true (i.e. the key).

26

Analysis

Environmental key generation involves a set of environmental conditions to be true to allow the platform to access the mobile agent. Thus, a key is generated based on certain environmental conditions. This technique safeguards against masquerading of a platform to the agent. Only a platform that uniquely possesses these values can process the agent. Also, an agent cannot be accessed until the platform is identified. The environment values to access the agent are used by the agent to determine what level of access to grant the platform. Thus, an agent cannot be spied on and eavesdropped on in anyway and the agent cannot be tampered or altered or copied, since the access is restricted. However, there is no safeguard against denial of service from the platform as an agent may be blocked out after access by the platform. Also, since no logging or history is maintained, repudiation attacks are prevalent.

4.2.3 Code Obfuscation

To protect the agent, techniques like time-limited black box protection has that been proposed by Hohl (Hohl, 1998a; Hohl, 1998b). This technique involves the scrambling of code such that it is not interpretable in function and operation. This is also referred to as obfuscated code techniques by Jansen in (Jansen, 1998b) (Jansen & Karygiannis, 1998) by Beirman et al in (Beirman & Cloete, 2002) and by Bellavista et al. in (Bellavista, Corradi, Federici, Montanari & Tibaldi, 2003). In Hohl’s approach (Hohl, 1998a; Hohl, 1998b), a mobile agent is made a blackbox for a certain known period of time. This is achieved so that a mobile agent, its code and data are not readable. But, after the time has elapsed, the mobile agent data has become invalid and the access becomes possible. 27

Analysis

Code obfuscation protects the agent from a platform that is masquerading because a platform that is pretending cannot in anyway know how to read the agent code and provide a meaningful executable for of the scrambled code. It protects against an unauthorized access because the agent is accessible but is not meaningful to the attacker. Agents cannot be eavesdropped either because the code is not meaningful at all. So if the execution is spied on, the meaning would not give anything comprehendible. The agent message copying and replaying is also protected. The agent is a blackbox to the platform. So, its messages alone have no meaning even if they are copied and replayed. Unauthorized access is possible if the platform is intelligent enough to derive a meaning from the sequence of execution of code. Denial of service is not solved as they platform may block the agent. Also, repudiation is possible because no history of execution is maintained.

4.2.4 Cryptographic Functions

Cryptographic functions have been suggested by (Sander & Tschudin, 1997a; Sander & Tschudin, 1997b) to encrypt the code and data of the mobile agent. The platform would then use an encryption scheme to decrypt the mobile agent and to use the mobile agent. The approach uses a technique that encrypts both the mobile agent’s code and data. What the technique uses is that an agent function should not describe its actual purpose. It should be able to run on the agent platform but should not be able to understand its working. Agent functions are thus decomposed and sent to the platform. Each function is encrypted and sent to be executed. This is then decrypted at the platform. The result is interpretable but not understandable to the platform. 28

Similar to this (Ametller, Robles & Ortega-Ruiz, 2004) protects mobile agents through encrypting their functions through a key mechanism. The agent is encrypted publicly and then signed with its signature. However, the scheme is implemented for the JADE platform. Lee et al. (Karnik & Tripathi, 2000) use the same approach that (Sander & Tschudin, 1997a; Sander & Tschudin, 1997b) uses but extends their work to include a practical implementation. They in turn come up with a new scheme for the approach in (Sander & Tschudin, 1997a; Sander & Tschudin, 1997b). (Algesheimer, Cachin, Camenisch & Karjoth, 2001) includes the agents that can use its results during its journey. Thus, its data is not limited to just the originator host. This approach adds a special service, the secure computation service that does not leak the encrypted function information to the platform safeguarding the agent but still provides a mechanism for the platform to interact with the agent. In (Novak, Rollo, Hodik & Vlcek, 2003), session keys are used to protect the agents that are executed. The agent can only be accessed with it session key while it is in communication with the platform. The session key becomes invalid after a session. To gain access, another session has to be built with the agent and a session key needs to be used to execute the agent. Another cryptographic technique is presented in (Dadon-Elichai, 2004) which use keys to hide the mobile agent execution. The RDS scheme also relies on fault-tolerance as it sends agent replicas to execute at the platform. A platform requires the appropriate key to transact with the mobile agent hence protecting the agent from any malicious behavior. If it is opened and tampered with, a replica is always present to commence execution. 29

(Ferreira & Ricardo, 2002) uses a scheme to protect keys being carried inside an agent. The scheme is used to blind the key being carried by the agent. This means that the private key is factored to give a particular blinded key, the factor is only known to the host. Then, this blinded key is used to create a signature. To use the key, the factor has to be known. Thus, this scheme can be used to protect very critical and confidential data in the agent. Another technique is presented in (Tate & Xu, 2003) which overcome the limitations of approaches in (Lee, Alves-Foss, Harrison, 2004; Sander & Tschudin, 1997a; Sander & Tschudin, 1997b; Algesheimer, Cachin, Camenisch & Karjoth, 2001). The approach uses multi-agent cryptography. In this, instead of relying on a special service, the host itself deals with the encryption and decryption. Also, it incorporates the dealing with untrusted platforms since the approach defines a threshold value. This value determines whether or not the platform can execute the agent or not. (Marques, Santos, Silva & Silva, 2001) also incorporates the use of cryptography in its M&M framework. This allows an agent to create cryptographic protocols for secure communication of information. The MANSION framework (Noordende, Brazier & Tanenbaum, 2002) also uses cryptography to protect its data. (Vuong & Fu, 2001) incorporates the hiding of its data behind an encryption scheme as well. (Fu, 1999) extends the work in (Vuong & Fu, 2001) to give an implementation in Wave. It gives the details of the implementation of the cryptographic system. It also makes the agent readonly depending on the type of execution required from it on the platform.

30

Analysis

Cryptographic functions are a strong technique to protect an agent from masquerading platforms. This is because a platform with a key is authenticated before it can decrypt an agent. A masquerading platform cannot have a key. A platform cannot access an agent it cannot decrypt. To make this a stronger, an agent may carry a key that may be used to decrypt it, like in the blinded key approach. Thus the agent containing encrypted functions is not harmed by unauthorized access or by spying out of the code nor can the encrypted agent be altered since without the key, the functions are not readable. An agent message cannot be copied either if the key relies on session keys that become invalid after a particular transaction or a given period of time. Denial of service attacks cannot be prevented as an agent that may be decrypted may still be blocked out from the platform’s resources. An agent is not logged and no history is maintained meaning that repudiation attacks may be prevalent on the system.

4.2.5 Execution Traces

Execution tracing also called encrypted traces (Vigna, 1998; Moore, 1998; Vigna, 1997) for mobile agents have also been suggested which involves the encryption of the execution log of mobile agents executing on platforms. This log is a history of the execution on a platform. The log is then hashed by the platform and signed with its signature. The platform keeps the original trace of the agent. The agent execution trace may contain certain suspicious results that can be used to find a malicious host. Also, the host can ask for the traces from the various platforms for comparison. This can thus locate security breaches.

31

(Leung & Ng, 2004) extends the tracing approach by Vigna in (Vigna, 1998; Vigna, 1997) in to detect the malicious hosts from the traces that the mobile agents generate. For this, a protocol is suggested that uses the threats to locate a malicious agent platform from an agent’s journey. Another approach here is to use Cubaleska et al. approach (Dadon-Elichai, 2004) for determining whether an agent platform in the mobile agent’s journey was malicious. For this, the agent platforms are queried by the host upon arrival of the agent. Each platform is queried for their identity and for the identity of the next platform. A malicious platform will give a wrong response or will not be able to give any response at all. Thus, such a platform can be blocked by the host in future journey creation. Another approach is by Hohl in (Hohl, 1999) that protects the mobile agents using the concept of reference states. The agent’s execution is checked for certain reference states that are determined by the data that the agent holds after an execution. To authenticate the data produced by the platform, digital signatures are used. The resulting state can thus be used by to determine what sort of protection is necessary. (Vogler, Kunkelmann & Moschgath, 1997) protects an agent by a primitive logging mechanism. The malicious activity is traced back and execution is then recommenced from there. Thus, it protects the malicious activity on an agent by rollback recovery, a fault-tolerance mechanism. Logging capabilities are apparent in the M&M framework (Marques, Santos, Silva & Silva, 2001) to keep a trace of agent execution, of agent interaction and this is listed with the agent identity. This maintains accountability for agent actions on the platform and the platforms actions towards the agent.

32

In (Noordende, Brazier & Tanenbaum, 2002) the MANSION framework uses an audit/trail mechanism. This mechanism audits all changes made and where the change in the agent occurred. (Fu, 1999) also uses logging the execution trace of the agent on the platform.

Analysis

The approach uses a capture of an agent’s execution into a trace. This allows the detection of a threat and not entirely the prevention of it. However, a masquerading platform can be detected from the trace as a masquerading agent will not leave a trace that is expected from the actual platform. However, if this check is not enabled, masquerading is prevalent. The technique checks for unauthorized access, for any alterations to the agent and for any copy and replay actions against the agent during execution. It guards against repudiation because a log is maintained that keeps a track off all execution and all interactions of the agent, the platform and other agents. DOS attacks can be detected from the log as well. However, an agent cannot be checked for eavesdropping. Spy-outs of the code or data rely on other techniques as a trace cannot denote an outside spy of an agent execution, if it is not being interacted with. The log relies on interaction of an agent along its execution. If a spy is merely viewing the agents set of message calls and gathering this information for malicious purpose, it is not logged.

4.2.6 Itinerary Protection

Itinerary protection of mobile agents is another approach as presented by Mir and Borell in (Mir & Borrel, 2002; Mir & Borrel, 2003). The itinerary of the mobile agent is its 33

route that also has to be made private. The work on the protection of the itinerary is by encrypting the itinerary of the agent. There are different types of routes that an agent can take, they can be sequenced or in alternate order as well. (Mir & Borrel, 2002; Mir & Borrel, 2003) takes these types into consideration while applying their cryptographic protocol for itinerary protection. Another variation of (Mir & Borrel, 2002; Mir & Borrel, 2003) is that in (Wilhelm, Staaman & Buttyan, 1998) which uses a similar protocol for the protection of the mobile agent’s itinerary along with special tamper-proof hardware. The hardware is there to enforce a policy. Another technique is to use a cooperating agent to record the itinerary of the mobile agent. (Roth, 1999; Roth, 2003) uses a cooperating agent that sets up a authenticated channel with its cooperating mobile agent. This agent records the path information and in the case of malicious behavior, the cooperating agent takes the necessary action, like inconsistencies in the itinerary. The agents that are cooperating are the only ones that can see each other’s itinerary with the help of the authenticated channel of communication between them. The MANSION framework (Rothermel & Schwehm, 1998) uses this scheme to keep the agent itinerary private from the platforms it visits. This is maintained in the agent’s table of content that details what methods an agent contains and where is has been (source platform) and where it is going (destination platform).

Analysis

An agent is protected from a masquerading platform because a platform that cannot be identified is not allowed to view the encrypted itinerary. A key is required to access the 34

itinerary. Also, a cooperating agent keeps a check on the route an agent takes. DOS attacks are also recorded if a cooperating agent is used. Also, any kind of unauthorized access to the itinerary is not possible since the itinerary is protected by encryption. The agent is also protected from repudiation attacks as a cooperating agent logs the information of execution. However, an agent is partially open to an attacker for eavesdropping. Since the attacker cannot view the itinerary, other information may be accessible and alterable. The agent can thus not be completely spied on, altered and copied but partially it can. Thus, such threats may prevail.

4.2.7 Time Techniques

Another approach in (Beirman & Cloete, 2002; Greenberg, Byington & Harper, 1998) to protect the mobile agents is to use a time technique. The agent has a built in timer. If the time passes and the agent is not provided service, it can either self-destruct or it can pass on to the next platform.

Analysis

The approach can be used to protect from DOS, as an agent will expire in a period of time. Access time is limited and thus unauthorized access may be prevented by the agent expiring after a given time. Eavesdropping can also be limited because the agent is only existent for a limited time. The agent life may be so short that it might not be possible to alter it or copy it. The approach cannot protect an agent from any masquerade as there is no way to authenticate the platform. also, there is no mechanism for keeping track of the agent’s 35

time spent on a platform and repudiation may occur Access can be limited by time, but an agent may be spied on, may be altered or copied in that limited time.

4.3 Platform Protection To protect the platform other approaches have been mentioned in various papers. The agent or a group of multiple agents can maliciously hinder the activity of the platform or a group of platforms (Vigna, 2004) causing fatal consequences (Jansen, 1998b). This section surveys the various countermeasures to protect the agent platform.

4.3.1 Agent Authentication

First we deal with agent authentication as proposed in (Farmer, Guttman & Swarup, 1996a) by Farmer et al. The approach simply uses the digital signature scheme for the authentication of agents. An agent has to be signed by its vendor and this allows the running of the agent on the platform if the public key to see the signature is known. Otherwise the agent is not to be trusted and the agent is rejected. Similarly, Berkovits et al. (Berkovits, Guttman & Swarup, 1998) use an authentication mechanism for mobile agents. This paper gives a detailed implementation approach to (Farmer, Guttman & Swarup, 1996a). In this approach, the agent is assigned a certificate. The agent is authorized according to the certificate that includes agent information such as the agent creator, the agent sender and the actual program of the agent. The platform checks the agent and thus authenticates itself to the agent and the agent to the platform as it possesses a key. If it does not have this key, the agent is not authenticated and thus the agent and the platform are unknown to each other. Upon authentication, the agent state

36

appraisal functions are executed and the agent is authorized to access the platform. The state appraisal functions denote what privileges the agent has on the particular platform. The implementation specified in (Berkovits, Guttman & Swarup, 1998) is specialized by how the theory in (Farmer, Guttman & Swarup, 1996a) will be used in practice. Another approach (Schelderup & Olnes, 1999) (Varadharajan, 2000) suggests that an agent be given a passport. This is a kind of information file with the agent that describes it. It can be used to gain information for authenticating it and to authorize resources to it. The file thus contains necessary information like the agent name, the host address and other execution information for the agent to the platform. In (Jansen, 2001), Jansen provides a mechanism to determine mobile agent privileges by assigning mobile agent certificates. The certificates contain information about the agent that is in turn used by the platform to apply a policy for the agent. The application of policy is governed by a component on the platform called a policy engine. This policy according to the agent certificate allocates the privileges that the mobile agent has on the platform. In (Novak, Rollo, Hodik & Vlcek, 2003), certificates are defined to authenticate the agents based on mobile agent standards. The certificates are registered to a certification authority that allows the agent to implement security. Upon reaching a platform, the agent proves itself from the registered certificate. (Tan & Moreau, 2002) presents a framework for authenticating mobile agents using a mechanism based on certificates. An agent is granted a certificate that is in turn verified from a special verification server. The agent is then granted access or denied access according to its certificate and the response from the verification server.

37

(Marques, Santos, Silva & Silva, 2001) uses an authentication scheme as well that associates each agent to an identity containing the list of owners, the name of the agent, a hash signature of the code of the agent, the agent creation and the agent expiration time. Each agent is assigned a key so that copies cannot be made. The distribution of the keys is done through a server. This is used to authenticate the agent on the platform. Authentication in an agent is also present in the MANSION framework (Noordende, Brazier & Tanenbaum, 2002). Each agent has a passport that contains signatures of the agent code. The signature is checked to identify the agent according to its owner. Also, another authentication is done for within system transfer. This uses the same mechanism to identify the agent through its passport. (Vuong & Fu, 2001) uses a simple scheme to authenticate agents on the bases of digital signatures. The framework has a certification infrastructure to assign signatures and keys to the agents. (Fu, 1999) extends the work in (Vuong & Fu, 2001) to give an implementation of the signature scheme using certificates. (Karnik, 1998) uses a simlar authentication scheme based on the El Gamal Crypto system. This ensures the authentication of an agent onto a system and the authentication of the system for the agent.

Analysis

Agent authentication can prevent masquerading attacks as only permitted agents can access the agent platform’s services and resources with real credentials. Authentication does check the agents for their identities and allocates them to the system however they require an authorization mechanism to access the resources. Otherwise, an authenticated agent may still act maliciously and try to access services and resources it is not permitted 38

to. Similarly, an agent that has been authenticated can be kept track of and repudiation checked. However, only authenticating the agent does not mean that the agent will cause repudiation or not. An authenticated, yet malicious mobile agent may still cause a DOS attack on the platform by hogging its resources and not freeing them. Similarly, an authenticated agent may spy on or try to tamper with a platform. An authenticated agent may copy the platform messaging and replay them as well. Hence, authenticating an agent alone will not suffice. In an effort to protect mobile agents and to provide performance as well as security through authentication in an MAS, (Ng, 2000) provides a mechanism of assigning group signatures. The members of a group are thus anonymous and private to the authenticating body. The authenticating platform knows the identity of the group. This gives performance because the agents do not have to be authenticated individually and only the agent group needs to be authenticated.

4.3.2 Path Histories

Path histories (Jansen, 1998a; Jansen & Karygiannis, 1998) can be used by the platform to see where the agent has been. Based on the platforms it has been to the platform sees if it can trust the agent. Thus, if a platform the current platform does not trust has provided service to the agent, the agent can be rejected. Path histories are maintained (Beirman & Cloete, 2002; Bellavista, Corradi, Federici, Montanari & Tibaldi, 2003) by the agent containing the platforms that it has visited on its journey. Each host enters its name as well as the next platform’s name in the history. With this, the agent can be checked for possible malicious platforms in its path that may 39

have corrupted the agent. This can be done in a few different ways, the agent visits the platform and the platform checks the list for a platform it does not trust, or has referred to as malicious. Also, the host list and the signatures can be used to check each platform visited by the agent’s current platform. From this, if one of the platforms is detected to be malicious, the agent can be restricted. (Dias, Ribeiro & Ferreira, 2003) uses a history based scheme to enforce its security policy on an incoming mobile agent. The agent platforms implement a proxy that keeps track of the agent execution. The proxy forwards its information to other proxies and the platform can use this information to apply the policy for the particular agent.

Analysis

Agent platforms can be protected by using path histories mechanism that helps detect malicious mobile agents. A mobile agent’s history can be checked to detect any masquerading. Similarly, the agent can be checked for a history of DOS attacks on other platforms. However, DOS attack detection in the history is complex as a series of other information would be required as well, like the number of waiting agents for the same resource and the total amount of time the process required the resource and how long the agent kept it and so on. This scheme also prevents unauthorized access as the path history can be used to set a policy for what the agent is allowed to access and what it is not allowed to access. Since a history is maintained, the agent cannot cause repudiation attacks. This technique does not however prevent the agent from spying on the agent platform as it is not detected. The agent may still be corrupting the platform and may also use the platform for copy and reply attacks. 40

4.3.3 State Appraisal

(Farmer, Guttman & Swarup, 1996a) also gives the concept of state appraisal. The state is checked to see if the agent has been tampered with. The state is checked by the platform and access given to the agent based on the state. The states that the agent can hold are pre-defined by the platform. If the state is out of these defined states, the agent access would be restricted or completely refused, as defined by the policy of the platform. To accomplish this, each agent is assigned state appraisal methods. These are executed by the platform the agent has arrived on. According to the results of the state appraisal methods, the agent is allocated a set of privileges. This is detected by the states that an agent can be in and what privileges it may require. Thus, the use of state appraisal is closely associated with authorization of an agent. The work in (Farmer, Guttman & Swarup, 1996a) has been enhanced in (Berkovits, Guttman & Swarup, 1998) which uses state appraisal for migrating agents’ authentication and authorization on an agent platform.

Analysis

State appraisal protects a platform from an agent masquerading as the appraisal functions can be used to check an agent’s identity. DOS attacks can be prevented because the state check is used to allocate resources to the agent. Similarly, access levels can be set based on policy. Repudiation is avoided but not completely as an agent state is maintained, hence providing history to some extent. On the other hand, eavesdropping alteration and copy and reply cannot be tracked by the agent’s state values. The agent functionality has to be checked for that.

41

4.3.4 Resource Protection

Resource protection is a very important security consideration of all distributed systems. Similarly it is vital for MAS as well. Tripathi and Karnik in (Tripathi & Karnik, 1998) provide a scheme for the protection of the resource through proxies. The agent based on its authentication information or its credentials are given the authority and access level to the resource through the proxy. Similar to this approach is to use a wrapper which is a general implementation of the accessor object for categorized agents. The proxy is thus dynamically constructed and the wrapper is static constructed by the resource provider beforehand. Another approach that can be used is to use state appraisal to determine privileges or to use safe padded cells for access to resources. Karnik in his dissertation (Karnik, 1998) uses the same technique for resource protection, using proxies for each agent reference to a resource. Another approach by Jansen uses policy certificates in (Jansen, 2001). This contains information about the agent that a policy engine on the platform uses to determine what privileges to assign the agent. The privileges are determined by the information about the underlying algorithm that the agent uses for use of the platform and its resources. (Villazon & Binder, 2001) describes the resource access by a mobile agent through reification of the mobile agent itself. The mobile agent code is transformed into a metaagent. This meta-agent structure requires the access and modification of the mobile agent’s actual code. The agent is thus reified and the new meta-agent accesses the resource as the agent platform permits. (Nicola, Nicola & Pugliese, 1997) uses a rather dynamic approach to violation of access rights. The paper defines a type system for mobile agent’s access to resources. The agent access (read, write) is checked via a blackboard. The blackboard contains the agent 42

actual intention, its permission granted by the platform and the agent’s current type of access.

Analysis

The resource protection techniques are there to protect an agent platform from an agent that may cause DOS attacks. A resource that may be overloaded by an agent can terminate the agent calls and free the resource. Similarly, the platform resources are protected from unauthorized access by an agent. This is because the resource is protected by a policy in the form of a proxy or a wrapper. Also, certain mechanisms may use a resource logging facility to keep track of agent to resource interactions. This may prevent repudiation depending on what proof of interaction is being logged. An agent that may be spying is prevented as any agent spying is not possible since sensitive information is kept private to the agent, in other words, it is inaccessible. All the platform’s resources and services cannot be corrupted by the agent as they are protected and the platform calls and any attempts to reply messages are prevented. Agents are not checked for identity in all schemes for resource protection. Thus another technique for authentication has to be incorporated with the resource protection and authorization.

4.3.5 Fault Isolation or Sandboxing

Other schemes listed by Jansen in (Jansen, 1998a; Jansen & Karygiannis, 1998) to protect the platform from the agents are to use fault isolation or to sandbox the execution of the mobile agent. This means that the agent can only execute in a limited virtual area on the platform. It cannot access anything outside this sandbox unless it is permitted by 43

the platform. This protects the platform entirely from any malicious activity from the agent. Thus, the instructions are checked whether they are within the address allocated or not (Moore, 1998). If they are not an exception can be reported or the address can be tailored to belong with the area allocated to the agent. In (Noordende, Brazier & Tanenbaum, 2002) the MANSION framework uses a similar approach to allow secure execution. The agent is binded with a sandbox and a monitor checks all interactions that the agent carries out with the platform.

Analysis

Fault isolation prevents a masquerading mobile agent from harming the platform because it is constricted to a narrow area of memory for execution. Similarly, an agent cannot cause DOS attacks because it has restricted access to resources. An agent is prevented from unauthorized access because it is kept in a sandbox with only its accessible entities; the inaccessible entities are outside the sandbox. An agent cannot eavesdrop but it can spy on whatever is going on within the sandbox. An agent can alter what it has access to unless the sandbox limits the agent from such activities. Agents can copy message exchanges that occur and replay them but since this is in a limited area this does not cause much of a threat to the platform. Since there is no mechanism for keeping track of the interaction that goes on, the platform is threatened by agent repudiation attacks. For protected execution of mobile agents, (Karnik, 1998) uses protection domains. These domains are created for the agent when the agent arrives. This uses a classloader that protects the agent from maliciously interacting with the platform. Each agent is assigned a classloader instance to interact with the platform. 44

4.3.6 Safe Interpretation and Padded Cells

Also, stated in (Moore, 1998), safe interpreters like in Safe-Tcl (Ousterhout, Levy & Welch, 1996) can be used. Here the padded cell concept is given to execute instructions inside a safe interpreter and block out the unsafe instructions. The master interpreter either gives it pseudo-instructions to complete the process instead of the real instruction (that is not safe) or it gives the actual instruction as suggested by the requirement of the platform. Java has a similar means of safe code interpretation since it provides a type checking that creates a kind of sandbox security.

Analysis

An agent that attacks a platform through a DOS can be prevented by checking it with a padded cell. A platform can contain any sort of unauthorized access to resources since the padded cell would close such commands from the agent. Agents in a padded cell cannot eavesdrop or alter a system because such commands are prevented. Agents can copy message calls and replay them, but these are the few calls that are visible in the padded cell and hence lower the threat. Masquerading cannot be prevented in a padded cell; there is no way of finding out whether the agent is real or just pretending. DOS attacks may still prevail because the padded cell instructions can be exercised over and over again. The instructions accessible in the padded cell are safe but they may thus be made dangerous by redundant messaging. Mobile agents still cause repudiation because the padded cell has no track of the execution.

45

4.3.7 Proof Carrying Codes

Proof carrying code (Jansen, 1998a) (Jansen & Karygiannis, 1998; Bellavista, Corradi, Federici, Montanari & Tibaldi, 2003; Tschudin, 1999) techniques can also be used by various agent platforms. The agent code can be used to carry its signature, in the form of a proof. For example, the code can be algorithmically used to provide a number. This number would change if the code of the agent has been tampered with. Since this number is known to the platform beforehand, it can reject the agent and avoid any corrupt agents (Moore, 1998). (Esparza, Soriano, Munoz & Forne, 2004) suggests the use of a digital watermark that is added within the code. In the case of a change in the code, the watermark becomes faulty and scrambled. In this case, the attack can be detected by the platform that knows how to read the watermark. The watermark can be a value or a sequence and so on.

Analysis

Mobile agents protected by PCC can be checked for masquerading because an agent that contains a proof can be checked with its originator. An agent can also be checked for the proof and be allowed access on the platform accordingly. An agent that has been tampered with has a scrambled proof and is denied access or rejected completely. An agent cannot be stopped from causing DOS or by spying on the platform, altering it or causing copy and replay as the agent is still threatening. Repudiation still occurs because the agent is not tracked.

46

4.3.8 Payment-based Techniques

Also, for protection of the platform and its resources, various works propose money based techniques (Kun, Xin & Dayou, 1999; Gray, 1997) for mobile agent systems. An agent arriving and acquiring an agent platform’s service has to use a cryptographic sum of money. The agent use is based on how much it is willing to spend. The money is thus exchanged by the agent and the platform service. The MANSION framework (Noordende, Brazier & Tanenbaum, 2002) uses a form of this technique containing e-cash that is used to pay and acquire services.

Analysis

Payment-based techniques may help prevent masquerading because they only permit the agents that have money to pay for the platform’s services. However, a masquerading agent may have money and may be pretending to be another and thus the threat is limited but not completely eradicated. DOS is prevented because an agent cannot hog a resource. The money that an agent has is finite making the access of the resource limited by that amount. Unauthorized access is also prevented since an agent can only pay for the services that the platform allows. Otherwise, the platform does not put the service up for access. Agents can avoid repudiation to some extent by the transaction and the money exchange involved but this would require an account tracker to check when required. An agent access can be payment based too making the access limited and denying changes and copying. However, the agent may pay for full access and use this privilege to malicious advantage.

47

4.4 Network Protection Various techniques are available to protect the network that the entire MAS is built upon. This is necessary because an attacker may tamper with the network and may capture a mobile agent in transit. Also, a platform may be hampered with by an attacker from the outside through intrusion attacks. Solutions exist to protect the MAS through both hardware and software approaches (Li, Zhang, Sun & Yin, 2004).

4.4.1 Secure Sockets

Voung and Fu (Vuong & Fu, 2001) provide practical implementations of MAS using SSL (Secure Sockets Layer) to create a protected channel for the communication between the host and the platform. The SSL provides a secure layer for transmission of agents between the host socket and the platform socket. (Jihong, Jianping & Kai, 2000) uses SSL very strongly in its design of a secure MAS. Here, it is used similar to (Vuong & Fu, 2001) to set up a secure channel for transmitting agents. Similar to building a secure socket a continuous stream can be sent out so that only the intended receiver knows which bits are meaningful (Tschudin, 1999). The M&M framework (Marques, Santos, Silva & Silva, 2001) also incorporates SSL sockets for agent migration.

Analysis

Mobile agent systems can be protected through secure sockets preventing any masquerading of an agent and a platform since a secure channel can only be setup

48

between known servers that send known agents. Since a channel is secure from end to end, an outsider cannot eavesdrop on the conversation. Similarly, alteration and copy and replay attacks from the outside can be prevented. DOS attacks cannot be prevented because the secure sockets are to secure transmission not limit them. Repudiation is not prevented either as there is no logging. Alteration and copy and replay attacks can occur if the secure socket is between untrusted nodes.

4.4.2 Firewalling

(Rubin & Geer, 1998; Feng, Shan & Ying, 2003) describe the use of firewalls for the protection of a MAS. Incoming requests to the MAS are checked one by one. Any attempts to hurt the system are blocked. This approach is not possible in all scenarios. So, a proxy is built with a firewall. The requests are sent to the proxy. The proxy acquires the necessary information and responds with the safe version of the request.

Analysis

Firewalls check for masqueraded messages from the outside. They also prevent any kind of eavesdropping from the outside as well. Access that is not authorized can be detected but if not specified in the proxy, it may still be accessible. Repudiation can be checked as a request log is maintained. However, the incoming attacker may change identity and cause repudiation. Firewalls cannot prevent DOS or copy and replay as a request that has been permitted will be permitted over and over again.

49

4.4.3 Tamper-Resistant Hardware

(Beirman & Cloete, 2002) suggests the use of tamper-resistant hardware and detection objects to protect the MAS from outside network security threats. The hardware is made such that it cannot be physically tampered to allow access and also virtual tampering is blocked. For this, firstly the hardware is enclosed in protective encapsulation (switches in locked cabinets) and secondly, detection objects are placed to detect if the physical link has a leak in it that may be accessible by an attacker.

Analysis

Masquerading is prevented by the detection objects that check the source and sink of the incoming agent. Access is controlled by the detection objects and the tamper-resistant hardware because the resistant hardware prevents any illegal entry and the detection objects maintain surveillance over the link. Eavesdropping is prevented as there is no entry point for an attacker. Similarly, alteration attacks can be prevented from the outside. DOS and copy reply cannot be prevented as there is no way to detect these by the tamper-resistant hardware and the detection objects. Alteration may still occur from within the system through faults in the components of the system.

4.5 Evaluation The protection countermeasures are evaluated according to the threat model (Orso, Harrold & Vigna, 2000) (Saeb, Hamza & Solimon, 2000). We analyzed each approach

50

and find the potential weaknesses of each approach according to the threat model and whether the approach over comes the particular threat(s). For this we make two tables. The first table (Table 4.1) evaluates which threat to the mobile agent is counter measured. The second table (Table 4.2) is for the evaluation of the countermeasures to protect the platform, checked to describe which threat to the platform they countermeasure and the third (table 4.3) describes the countermeasures to protect the network

Table 4.1: Protection of the Mobile Agents Masquerading

DOS

Unauthorized Access

Repudiation

Eavesdropping

Alteration

Copy and Replay

Partial Result Encapsulation

Partial

No

Partial

No

Yes

Partial

No

Environmental Key Generation

Yes

No

Yes

No

Yes

Yes

Yes

Code Obfuscation

Yes

No

Partial

No

Yes

Partial

Yes

Cryptographic Functions

Yes

No

Yes

No

Yes

Yes

Yes

Execution Traces

Partial

Yes

Yes

Yes

No

Yes

Yes

Itinerary Protection

Yes

Yes

Yes

Yes

Partial

Partial

Partial

Time-based Techniques

No

Yes

Partial

No

Partial

Partial

Partial

51

Table 4.2: Protection of the Agent Platform Masquerading

DOS

Unauthorized Access

Repudiation

Eavesdropping

Alteration

Copy and Replay

Agent Authentication

Yes

No

Partial

Partial

No

No

No

Path Histories

Yes

Partial

Yes

Yes

No

No

No

State Appraisal

Yes

Yes

Yes

Partial

No

No

No

Resource Protection (Proxies and Wrappers)

No

Yes

Yes

Partial

Yes

Yes

Yes

Fault Isolation or Sandboxing

Partial

Partial

Yes

No

Partial

Partial

Partial

Safe Interpretation and Padded Cells

No

Partial

Yes

No

Yes

Yes

Partial

Proof Carrying Codes

Yes

No

Partial

No

No

No

No

Paymentbased Techniques

Partial

Yes

Yes

Partial

Partial

Partial

Partial

Table 4.3: Protection of the MAS Network Masquerading

DOS

Unauthorized Access

Repudiation

Eavesdropping

Alteration

Copy and Replay

Secure Sockets

Yes

No

Partial

No

Yes

Yes

Yes

Firewalling

Yes

No

Partial

Partial

Yes

Yes

No

TamperResistant Hardware

Yes

No

Yes

No

Yes

Partial

No

52

Chapter 5 Mobile Agents Systems and their Security: State-of-the-Art

This chapter gives a state of the art describing various Mobile Agent Systems that have been implemented and it details their security along with an evaluation of them according to the countermeasures from Chapter 4.

5.1 Mobile Agent Systems Overview The research of mobile agents is growing immensely in directions of its use for evolutionary distributed systems. Their operation and functionality is based on a mobile agent system (MAS). There are various MAS that encompass the use of mobile agents for both research, experimentation and for commercial use as well. Numerous mobile agent systems have arisen for these purposes. Their differences lay in their features and their support for mobile agent types depending on what kind of languages they support (Gray, Kotz, Cybenko & Rus, 2000), whether they support weak or strong mobility (Gray, Kotz, Cybenko & Rus, 2000) and also up to what extent their threading is (Gray,

53

Kotz, Cybenko & Rus, 2000). Since we are discussing each MAS in the light of security we shall take into account the security mechanisms that each MAS has for the mobile agents and the agent platforms that are a part of the MAS. Obviously, the security is based upon the differences in feature and construction of the MAS. Security is dealt with in different regards in MAS. The techniques can be preventing different kinds of attacks and threats to a MAS whether for the mobile agent or for the agent platform. The MAS deal with these directly or on the basis of the mobile agent code itself. This means that in some MAS, security is a built in feature while in some, it is a provision placed as a feature of the implementation of the system using the MAS. Different approaches are used to secure systems as well as to enhance application of the MAS. Thus, the security in each system differs and the extent of security provisions by the MAS varies. The MAS taken into consideration in this paper are based on their substantial amount of security and their use in the research work.

5.2 Telescript Telescript was developed by General Magic Inc. and it was the first ever MAS developed for industrial market use (Gray, Kotz, Cybenko & Rus, 2000). The Telescript MAS comprises of the Telescript object-oriented language for writing mobile agents, which is interpreted (Gray, Kotz, Cybenko & Rus, 2000). The Telescript language contains classes allowing multiple inheritance (Tardo & Valente, 1996). The language is like Java and C++. Telescript is considered one of the most efficient, secure and faulttolerant MAS of all-time.

54

Due to the success march of Java, Telescript was outdated and it is now obsolete but, its concept and architecture provide idea and foundation of many other MAS that came after it.

5.2.1 General Architecture

The Telescript architecture (Figure 5.1) runs agents in divisions called places. Places are dived based on the service they provide for the agent to fulfill its function. Like a place might represent database access, the meeting places for agents or even directory access. Each server may thus contain several places that allow communication of the mobile agents in one place and in different places. The agent completes its functionality on the platform by migrating from place to place (Gray, Kotz, Cybenko & Rus, 2000). The agent can meet within a place by passing a reference of the agent’s object and can invoke its methods accordingly. Also, the agent can communicate with an object of an agent in a different place through a process called connection. In this an agent creates a communication channel and sends each other’s objects on this. The agent migrates from place to place using the go method in each agent’s process. The agent’s code, data and thread state are captured. The execution commences immediately after the go instruction, i.e. the agent’s migration. The agent enters a place according to an authentication mechanism. The agent contains a permit which is the agent’s cryptographic credentials. These credentials are based on what kind of usage the agent does on the platform like the amount of disk space it will be using or the lifetime the agent might have. If the agent violates any of this, the agent is destroyed (Baumer, Breugst, Choy & Magedanz, 1999).

55

As shown in Figure 5.1, the mobile agent accesses a server from the WAN and accesses the Telescript engine. This Telescript engine allows the agent to run. The Telescript engine is embedded onto the server and its operating system through the Telescript API. Each server contains a virtual machine (like Java) (Gray, Kotz, Cybenko & Rus, 2000) that runs each agent which is a part of the Telescript engine. The agent is compiled into bytecode in order to be executed. The server contains a process. The process is actually a class of the agent that extends the Process class. This means that the agent class inherits this functions that it can run inside a place (Baumer, Breugst, Choy & Magedanz, 1999). The places are assigned different IP addresses. So the agent locates a place through its IP address hosted on the WAN. Then it uses the IP address to join a place. The agent then embeds itself onto that place and starts its execution. Another thing that is shown in Figure 5.1 is a local agent. The server may be running different stationary agents. These may represent real world concepts that the agent uses to acquire a request to use a service or a resource. Also, it can be present on the server to provide a collaborative functionality to the agent. For example, the stationary agent may be a seller if the visiting agent is a buyer.

56

Figure 5.1: Telescript Partial Architecture (Adapted from (Baumer, Breugst, Choy & Magedanz, 1999))

5.2.2 Security in Telescript

Telescript security deals with four distinct levels (Tardo & Valente, 1996). These together form the Telescript security model. The model looks at different levels to provide safety and security to the MAS and it depends on the programmer of the Telescript MAS on what degree of each level of security to be provided. The levels are:

Object Runtime Safety

Telescript accesses objects through interfaces and only references to those objects (Tardo & Valente, 1996). It does not provide pointers meaning that the Telescript MAS consists of both dynamic variables and exception handling along with garbage collection. Like Java, it enforces the implementation of operations and attributes in the form of a class. This means that it enforces encapsulation of our objects. The methods and attributes are either publicly or privately accessible to the class itself or its sub-classes 57

(Tardo & Valente, 1996). Similarly, once a class is loaded into the Telescript engine, it cannot be updated or reinstalled or replaced by another class of the same name. This is all made possible by the fact that the engine’s interpreter acts as a monitor for access to the classes and their bindings (Tardo & Valente, 1996).

Process Safety and Security

Telescript deals with the security and safety of interacting agents thus protecting the agents from other agents as well as from the places they are running in. The Telescript model protects this through (Tardo & Valente, 1996):

•

Authenticated Authorities

Each place and agent is assigned a unique identifier. The Telescript engine contains these different types of authorities for the places and the agent. Now according to this authority the agent is authenticated and assigned an authorization level accordingly. Thus, Telescript allows the control of trust levels while running the agent.

•

Protected References

Telescript provides the essence of ownership. This is to protect the referencing of the object making it read-only access. This is done by making the class protected which is inherited in all the instances of the class.

58

•

Permits

To limit the use of resources and controlling execution of the code is done through permits. The permits are special objects that denote the life of a process, its memory requirements and its priority or it can allow the mobility of an agent or whether or not it can spawn other processes or agents. In Telescript, permit violation results in an exception and hence a termination of execution in some cases. There are four types of permits in Telescript:

1. Native: By a process creator

2. Regional: By engine on agent entering process or a new created process

3. Local: By a place when an agent enters or a new process is created

4. Temporary: Placed in the code

•

Entering and Meeting

The agent destination place has full authority of whether or not it will let the agent enter. The Telescript engine is responsible for providing the agent’s credential information (authority, class and permit). Here the place according to the agent’s credentials, allows the agent and applies its own permit on the agent. If the agent is not allowed, an exception is given to the agent and the agent is not entertained on the place. For new agents, where the authority is newer than the regular agents running, a special safe and restricted environment is provided called a purgatory. This place may be used 59

as docking areas for the agents to check if they are allowed or not, if they are not, they move to other destinations. The purgatory has a non-executable environment meaning that the agent cannot exercise its operations.

•

Security Mix-ins

These are special classes that cannot be instantiated but can be inherited. If an agent tries to move an object, copy an object or modify an object an exception is thrown. This results in a copyrighted form of object instantiation through its policy control.

System Safety

The system is treated as a separate layer in Telescript. The engine provides system visibility but access to resources like files, databases and network ports are through system objects (Tardo & Valente, 1996). These objects are mix-in copyrighted for safety. An agent can thus not use any of the system management and control functions. For instance if an agent is to install a virus, it cannot. The configuration options are left to the system management functions in the engine (Tardo & Valente, 1996).

Network Security

Telescript networks comprise of interconnected engines that contain many places. These places together make regions. The agents travel from and to these regions over secure channels to avoid hacking (Tardo & Valente, 1996). Region policies can be configured for each region in Telescript. Similarly, when an agent enters a region, it enters the outermost region called the engine place. Here it is decided to let the agent continue or not and also to enforce the policy on it, via the 60

permit, if it is allowed to continue. Also, the places an agent can and cannot visit are highlighted. A secure channel is maintained upon negotiation between regions. Here it is necessary for the regions to be authenticated. Upon reception of an agent, the place is handed over the agent’s authority, the region’s (where the agent is coming from) authority and the security services of the channel. These security services are pre-determined and have to be negotiated when a channel is setup and are called security regimes (Tardo & Valente, 1996). There are five types of security regimes supported by Telescript (Tardo & Valente, 1996):

Identification: Authority information is exchanged between the regions.

Registration: RSA is used for authentication and Diffie-Hellman and the encryption scheme used is the RC4. Here registration agents enter and visit only a few places that are authorized to them. These agents register the region with the region they are visiting and from here on the information are retained.

Fast Authentication: this uses the DES to authenticate and to transfer information between the regions. The key exchange is through the RC4 computation. Obviously, this is faster than public key operations for registration. Re-Key: This is used when the key has been lost or a key expires in DES otherwise it is completely like registration.

61

Authentication: This is similar to fast authentication but it shares an RC4 key using Diffie-Hellman for complete secrecy while sending information.

5.2.3 Comments on the Telescript Security Model

Telescript though sound in terms of safety and security it still has its weaknesses and limitations. These are mainly (Tardo & Valente, 1996): 1) Safety is not provided by the Telescript model, it is provided by the Telescript way of programming. This means that the programmer has to make sure that the safety rules are being followed.

2) Trusted operations have to be used for object sharing. The scenarios that the Telescript model covers are numerous but are not complete.

3) The engine doesn’t completely enforce the access control policies, like for resources and for access to places.

4) The Crypto system used in Telescript is breakable since it uses a small number of bits.

5) Encapsulation of the agent is present but this is for the agent generally, no complete scheme for result encapsulation is present. Hence, a partial result encapsulation exists.

6) Contains a safe area for execution like a sandbox, but it is not a special area in isolation, there is a check on the commands of the agent, which makes it like a padded cell. 62

5.3 AgentTcl and D’Agents Agent Tcl was the first implementation of D’Agents MAS and supported a single agent scripting language, Tcl and used the Safe Tcl extension (Gray, 1996). The Agent Tcl MAS was developed by Dartmouth College with the intention to replace other MAS due to their weaknesses, especially in security and language support. Agent Tcl was under development while its architecture claimed to support the Tcl language only, but provided a mechanism to support agents of other languages as well. Its main intention in terms of security was to remove the overhead of the programmer to explicitly add in the security according to the threats that may arise on the MAS. D’Agents replaced the Agent Tcl as its evolved version because it incorporated multiple languages like Java, Tcl and Scheme. Also, the D’Agents MAS was the first commercial release for use in applications since the Agent Tcl was for experimental and internal use. The name change was due to the fact that D’Agents incorporated more languages than just Tcl.

5.3.1 General Architecture

The D’Agents architecture is an extension of the architecture that was initially for Agent Tcl (Gray, Cybenko, Kotz & Rus, 2001). In Figure 5.2, we see the D’Agents architecture. It shows agents that can be implemented in multiple languages. Agent Tcl was initially just for Tcl, but now the D’ Agents architecture includes Java and Scheme as well. Each of the languages provides four components for the agents, an interpreter for the agent, the state capture facility so that the state of the agent can be saved in motion, as shown in Figure 5.3. The security component is a part of the interpreter that

63

checks each action by the agent and stops any malicious actions taken. The server API allows interaction of the language interpreter with the server for its communication services, its check pointing facilities to store agent states in case of failure, for the migration facilities for the mobile agents and also for the status management and status reporting of all running agents.

Figure 5.2: D’Agents Architecture (Gray, Cybenko, Kotz & Rus, 2001)

In operation, each agent that arrives on the D’Agents server will be sent to its corresponding interpreter, for example, a Java agent will be sent to the Java interpreter for processing (Gray, Cybenko, Kotz & Rus, 2001). The interpreter forms an interface with the server/ engine. The agent security is maintained by the interpreters themselves and all access to them is made based upon the restriction and allowances by the resource managers.

64

Figure 5.3: Agent Tcl (Magnified) (Adapted from (Gray, 1996))

5.3.2 Security in Agent Tcl and D’Agents

D’Agents security is progressing with their versions and accommodations of different language based agents. In Agent Tcl, the security was limited to techniques for secure authentication of mobile agents and authorization of the agents to the resources on the agent platform (Gray, 1996). The current D’Agents security protects the agent and the agent platform by providing more security techniques as extensions to the Agent Tcl security approach. The D’Agents security is divided in four parts, the protection of the machine, the protection of the agent, the protection of other agents running on the machine and the protection of a group of network machines (Gray, Kotz, Cybenko & Rus, 1998).

Protection of the machine

When a mobile agent migrates from a hot machine to other machines, it undergoes authentication and authorization (Gray, Kotz, Cybenko & Rus, 1998). The agent can be of two types, an owned agent and an anonymous agent. An owned agent is one that has a digital signature that can be verified and adversely an anonymous agent is one that can 65

not be verified. An agent can be authenticated if its owner is known or its sending machine is known. Meaning that if its sending machine is known and that the sending machine also authenticated it then its owner must be known making security a transitive concern. The approach to authenticate the agent is simple (Gray, Kotz, Cybenko & Rus, 1998). It uses the PGP (Pretty Good Privacy) approach. The agent upon reaching a platform is checked for its digital signature. The digital signature is registered by its spawning host with its owner private key. The signature is then encrypted using the public key of the destination platform. Here the agent is then authenticated providing two scenarios. First that the agent is owned and the platform may or may not allow it and similarly the agent is anonymous and the agent may allow it with highly restricted access or may completely deny it. After the agent executes, its state is stored and it is encrypted using the owner private key and then encrypted using the public key of the next platform in the itinerary and then sent. Authorization is then performed for the authenticate agents. D’Agents allows access to its resources through resource managers. The agent requests are then sent to these resource managers. The request is then allowed or denied by the manager accordingly. The

access

implementations

vary

by

placing

different

resource

manager

implementations, according to security policy. For this, D’Agents currently keeps a configuration file with owner and right pairs (Gray, Kotz, Cybenko & Rus, 1998). This list is loaded upon request and the owner and its corresponding right is checked and allocated accordingly. Similarly, the anonymous agents are given very little access like simple read access to certain global or public information. 66

Similarly there are enforcement modules for each language according to the code implementation of the agent. The enforcement modules regulate and manage common requests to and the resource managers and the agent. One provision is to maintain a list or a cache to see what grant was provided to the owner in the current execution history of the agent. The cache is emptied of course when there is a policy change. Another provision is the request lists. Here predictability is used instead of checking each command at run time. An agent issues a request log to the resource manager. The enforcement module checks with the resource manager the denial or the allocation of the request and returns a list to what request is allowed and what is denied. Also, an agent can restrict itself, based on its requirements, the platform or its surrounding environment. There are then the specialized enforcement modules of the languages. Agent Tcl uses the Safe Tcl architecture that involves the use of two interpreters, the safe interpreter and the master interpreter. The agent executes in the safe interpreter. All requests are sent to the master interpreter and they are then performed. In the case of unsafe instructions, the safe interpreter denies the instruction from running and instead provides secure links in replacement. Java uses the security manager class that does all its access control in D’Agents (Gray, Cybenko, Kotz & Rus, 2001). The command is checked by the class and if it is unsafe an exception is raised or an alternative course of action performed. Then, Scheme uses modules that can be public or exported. The exported functions are available on loading of the module. For security, the denial to export harmful functions can be restricted. Thus the Scheme enforcement module basically exports a set of safe functions.

67

Protecting a group of machines

Protection of a group of machines involves the agent not causing a denial of service attack on the network of machines by spawning to many children for instance or using up resources that other agents might require or routing over the network forever and ever. Here there are two types of groups: 1) Single administration 2) No single administration In a single administration domain, the agent is assigned a maximum resource allowance by the owner. In D’Agents, this is the usage vector. This vector holds the maximum resource allowance and is reduced if it exceeds the permitted resource usage. This is digitally singed as it moves from machine to machine so that any tampering of the usage vector size is not performed on transit. In the other case, where there is no single administration, the list itself can be tampered with upon reaching a machine. Here the D’Agents model (Gray, Kotz, Cybenko & Rus, 1998) has not implemented but has suggested the use of currency. Each agent has a specific finite currency that is used to gain access. This currency is cryptographically maintained.

Protecting the agents

D’Agents research is looking into various possibilities of protecting the agent that do not require tamper resistant hardware. The two broad categories of possible malicious activities defined are, malicious machine spies on the agent, tampers with it but lets it take its normal course of motion. Or the second type of threat where the agent platform sends it on a route it was not destined to follow. 68

However, the D’Agents (Gray, Kotz, Cybenko & Rus, 1998) has not yet dealt with these because of two reasons. The first being that the protection is possible by using a combination of these approaches and the second is that all of the techniques for protection will hinder performance. Simply, the D’Agents Security system looks like Figure 5.4.

Figure 5.4: D’Agents Security Model

D’Agents is looking into techniques to protect the agent including cryptography of components and algorithms, path histories, execution traces and state appraisal (Gray, Kotz, Cybenko & Rus, 1998).

5.3.3 Comments on the Security of Agent Tcl and D’Agents

D’Agents uses a discretionary approach to its security meaning that it uses an access list instead of a mandatory mechanism where classification is maintained or a state based

69

approach where its execution is traced at run-time for malicious activity or also an immunology approach where an agent’s current execution is matched with its proposed execution and the agent is malicious if the executions do not match. The weaknesses of the D’Agents security are: 1) No protection of agents as yet.

2) Protection of groups is for single administration and not the general case.

3) Multi-hop problem, where the host has to send an agent to perform one thing and then another to perform a next to avoid becoming anonymous. It thus cannot send a single agent that travels one by one to other platforms.

4) Replay attacks are still apparent on the D’Agents.

5) The platforms have to know the keys publicly available. This restricts the amount of owners that can be available i.e. any signed agent that cannot be authenticated is anonymous.

6) No protection of the message passing between an agent and the platform or the agent to agent.

7) It maintains a track of the next and current platforms but it removes the rest of the itinerary.

70

5.4 Ara The Ara (Agents for Remote Action) MAS (Peine & Stolpmann, 1997), was developed as a project at the University of Kaiserslautern. The platform it supports interpreted language agents in Tcl, Java and C/C++ (interpreted bytecode called MACE). It is being updated to include more languages like Pascal and Lisp. It covers the concern of agent mobility such that its execution is not effected by the migration of the agent from platform to platform. Also, the platform has kept a fair amount of fault-tolerance and includes checkpoints to save the agent internal state any time during execution. It has kept its implementation based on performance rather than ease of programming of the agents.

5.4.1 General Architecture

In Are, the MAS is based upon the concepts of its system core and interpreters, their communication, mobility (Peine & Stolpmann, 1997). The provision of the system core and interpreters is to allow multiple language agents to run on the platform. Also, the communication and mobility is for the agents to be able to migrate (as well as stationary agents) and to form a multi-agent system that provides the ability for the agents to interact and communicate to perform a task on the platform they are sent to execute on (Peine & Stolpmann, 1997). The interpreters are present in the Ara MAS for each language that it provides (Peine & Stolpmann, 1997). Here, the interpreter provides the agents with their language specific functionality issues of the agent platform to the agent. The system core, handles the language independent functionality issues of the agent platform to the agent. This

71

separation is so that various language interpreters can be added. The Ara core remains the same, but obviously the interpreter has to be extended. Then, Ara provides the communication and mobility privileges that makes the general operation of Ara possible (Peine & Stolpmann, 1997). The agents move from platform to platform as well as remaining stationary on a platform. For these mobile agents, Ara provides mobility and state capture facilities. Mobility features that Ara provides include the migration of an agent from one platform to the other and resume its execution there from where it left off. The agent is created and sent to and agent platform. The agent executes and has certain intermediate results. The agent stores its state and commences its execution from there on the next platform. The other state that includes its association to resources and with other agents is not stored however. Another Ara feature is its communication feature (Peine & Stolpmann, 1997). This communication is the multi-agent processing on the platform meaning that agents together execute to complete a designation by collaborating, coordinating and interacting with one another. This requires the agents to communicate with each other. For this Ara provides special communication meeting points where the agent commutes in a client/server style with another agent. Ara also provides fault tolerance features to the agents as well. Here an agent can checkpoint its state before a specific task. If the task causes an accident, the agent can roll back to this checkpointed state. This checkpoint is stored in a persistent storage. This is especially used before an agent migrates from one platform to another since there are chances of fault and failure in transmission, like line breaks and server crashes. The architecture looks like that in Figure 5.5.

72

Figure 5.5: Ara Platform Architecture

5.4.2 Security in Ara

In Ara, the security levels defined are in terms of agent authentication and the right association of an agent on the platform (Peine, 1998). Secondly, due to this authentication, an agent is associated with access rights or the authorization of resource usage on the platform. Entry of the agent on the platform is of three levels, these are the platform itself, the region to which it is going to be accessing and then the place. The platform entry is server level, the region is group level and the place is service level entry.

Authentication

The agent is given a passport that contains the host information from where the agent is spawned. This looks some what like:

AgentPassport { GlobalUniqueID id; String name;

// optional symbolic

Tima dateOf Birth; Allowance maxGlobalAllow;

73

// . . . //ttl, maxSize // . . . Certificate userCert; Certificate manufCert; Signature codeSig;

//by manufacturer

Siganature argSig;

// by user

Signature passportSig;

// by user

}

Here it is important to note that these are the values associated with the agent at the time of creation and will not change during its life time. Then there is information that the agent keeps that is ever-changing. This includes the agent’s host trace, or the hosts that the agent has traversed before it came to the platform it is running on. In Ara, the division of this information is done and the unchanging parts are signed digitally (Peine, 1998). The agent is then checked for its owner and the agent can be authenticated and accepted or unauthenticated and rejected. The changing parts are thus not signed as the problem of how an untrusted host will sign is not yet solved.

Authorization

Once an agent is authorized it is then sent to a region or a group of platforms for its execution. Here, an agent is thus a part of a region and it authenticated once by a platform in this region and is not re-authenticated as long as it stays in this region. However, the agent upon entering a new region is authenticated again (Peine, 1998). The agent is then allocated a place that contains its execution environment and the services that it has to run. The agents are allocated a particular allowance amount that expresses the time it stays at a particular platform and uses its resources. The allowances are maintained in a vector, and acts as a list of various system access rights. The system

74

resources are the files, CPU time, and memory and so on. This is the local allowance that each agent has on the system. The agent also has a global allowance associated with it. This global allowance is the agent’s general access to the various platforms that it visits. The local allowance cannot exceed the global allowance. Each agent has an admission function to enter the place. The agent, based on this function is allowed or denied the access to the place. This function contains the agent allowance, the agent passport and other security attributes (Peine, 1998).

5.4.3 Comments on the Security of Ara

The Ara platform has its strengths and weaknesses in regard to its security framework. The platform covers security features like authenticating the agent on the platform before allowing it access and then preserves the access to the platform resources as well. Sadly, however, Ara has its weaknesses. These are: 1) Ara does not secure the agents from malicious platforms. The agents upon authentication are at the platform’s disposal and may be spied on, copied and corrupted.

2) The digital signature scheme has to distribute its keys. The Ara platform has to work in accordance to a central server for the key distribution. Currently the Ara platform doesn’t provide a means for this.

3) There is no knowledge whatsoever how the agent credentials (its passport and other security attributes) are actually cryptographically handled. The assumption is that it uses one of the many schemes available, but has not currently specified which one.

75

4) Checkpoints that are maintained on the platform as a backup for fault tolerance are not secured.

5) An agent running on the Ara specification is not standard, how the MAS will contain servers of heterogeneous nature is not mentioned.

6) Ara encapsulates agents. But result data itself is not encapsulated by any scheme.

7) The logging is for the agent resource access and is not for the execution traces.

8) The resources are protected and controlled through a resource manager. It is not hidden behind a wrapper or a proxy.

5.5 Tacoma Tacoma (Tromso And COrnell Moving Agents) was developed by the University of Tromso and Cornell University and now has been undertaken by the University of California. It supports languages like C/C++, Java, ML, Perl, Python, Scheme and Tcl/ Tk. Implementations of Tacoma have been existent for years but the literature available on it is far less. The Tacoma project uses operating system support for its security features (Johansen, Renesse, Schneider & 1995). Tacoma covers state storage, agent communication, agent wrappers to structure the agent and fault tolerance. Security is provided through means of the underlying operating system. There are provisions for security in the Tacoma project for later versions.

76

5.5.1 General Architecture

The Tacoma MAS supports mobility of agents and thus state capture facilities (Johansen, Renesse, Schneider & 1995). The agent’s state is placed in a briefcase. These briefcases contain folders that contain certain elements that denote state. Each agent accesses one briefcase. A set of agents may contribute to form a file cabinet that can be accessed by many agents. When an agent migrates, it stores its state in folders and places it in its briefcase. This state is thus carried with the agent to its new destination. Some state may have o remain behind and that is registered in the file cabinet (Johansen, Marzullo & Lauvset, 1999). The agents communicate with one another using their respective briefcases. Agents create meetings with one another. An agent that has to communicate with the initiating agent must use the agent that the initiator is using. The agents pass one another their briefcases for communication (Johansen, Renesse, Schneider & 1995). Each agent uses a service agent to access a service on the platform for executing (Johansen et al., 2001). These form a layer of trusted processes for the mobile agents to acquire the system’s underlying services. Firewalls are present as well that coordinate meetings if the agents and also message other platforms upon transfer of a mobile agent. Wrappers are present that mediates all the agent operations and redirects them towards its interpreter. This approach allows the integration of more agent languages into the Tacoma architecture (Johansen, Renesse, Schneider & 1995). Versions of Tacoma had implemented payment mechanisms where the agent can access a resource upon payment that it possesses (Johansen, Renesse, Schneider & 1995). This involves the use of a large random number so that the cash cannot be forged. An agent that tries to use another copied number or one that it has already used, is thus rejected 77

for service. Also, the exchange of cash in times of transaction requires an audit service that keeps track of all the exchange taken place and the payments made from one agent to the other (Johansen et al., 2001). Figure 5.6 shows the architecture that contains the agents with their respective briefcases and the libraries for the agents of various language agents. These commute through the firewall shown.

Figure 5.6: Tacoma Architecture (Johansen et al., 2001)

5.5.2 Security in Tacoma

Security in Tacoma versions has grown steadily. But more of it is reliant on the Operating system (Johansen, Renesse, Schneider & 1995; Johansen, Marzullo & Lauvset, 1999). The Tacoma security is thus implicit and the explicit extension to include security is still under construction. Tacoma supports the use of digital signatures. This can be added to an agent as a program hook in its implementation. So, it has to be added in by the programmer. Also, Tacoma (Sudmann, 1998) uses electronic cash that solves certain problems of denial of service and also for the protection of the platform from being illegally

78

accessed. Thus, some what of the protection of the services is handled by this. However this is not prevalent in all its versions. The transfer of briefcases does make meetings secure and conversations between interacting agents confidential. However they must go through the firewall. The firewall acts as the point of mediation for the conversation and hence the security. Also, the security comes with the use of a meeting type conversation. An agent talks to an agent for service or collaboration and it cannot collaborate with other agents and others cannot collaborate with it. This is only possible if the third agent forms a meeting with the same agent the first agent was collaborating with. Service agents also provide security enforcement on the platform by the incoming agents. They form a layer so that the platform cannot be used maliciously (Sudmann, 1998). Another security perspective that is provided is through the use of wrappers that encapsulate the agent (Sudmann, 1998). This wrapper forms a means for instruction forwarding and fault isolation within the agent. The agents use the wrappers and their implementations as policies. Also, the agents’ replication support is a part that covers some of the agent security as well. Here agents are replicated and provided a secret known only to the agent and its host. The agent is also allotted a number. The agent if is copied will have the same number and the secret. The copied agent can be rejected by the host. But the details of the implementation are not yet complete (Sudmann, 1998).

5.5.3 Comments on the Security of Tacoma

Tacoma security is extremely primitive. Work is not completely focused on this regard and thus security is only available implicitly. The general weaknesses are as follows: 79

1) Agent platforms can act maliciously with Tacoma agents.

2) Platform is protected somewhat, but the platform knows all that is going on.

3) Agent briefcase exchange with a malicious agent is not protected.

4) Cash method of service allotment can be broken as copying of cash in the virtual world is easy and thus other cash forging is easy. Cryptography can be used to verify this cash.

5) Protection of agent’s data is not provided, like its itinerary.

6) Agents can be cloned instead of copied, and Tacoma does not in anyway protect this.

7) Agent encapsulation is present but no particular scheme to encapsulate result data is available.

8) Logging is done for the resources accessed by the agent but no resource traces are maintained.

9) It implements certain parts of the agent to be implicit. That means these are immutable but, there is no scheme of hiding such information, hence partial itinerary protection is available.

80

5.6. Ajanta The Ajanta MAS has been developed at the University of Minnesota and supports a lot of mobile agent programming features (Tripathi, Karnik, Vora, Ahmed & Singh, 2000). Ajanta is strictly Java based and supports mobile agents implemented in Java only. The MAS has extensive features for development of a mobile agent application with strong features of mobile agent security, fault-tolerance, communication, agent migration patterns and resource protection (Tripathi, Karnik, Vora, Ahmed & Singh, 1999).

5.6.1 General Architecture

Ajanta based mobile agents are very well defined (Tripathi, Karnik, Vora, Ahmed & Singh, 2000). The Ajanta agent possesses four parts: Agent code, data, a path itinerary and the agent credentials. The agent platform is well defined as well containing the resources, the domain controls like the resource registry, the domain database and an agent transferer. This is all collaborated by the agent environment. The platform in Ajanta is referred to as the agent server (Tripathi, Karnik, Vora, Ahmed & Singh, 1999). The architecture of such a server is shown in Figure 5.7.

81

Figure 5.7: Ajanta Architecture (Tripathi, Karnik, Vora, Ahmed & Singh, 1999)

Ajanta defines a mobile agent containing code and state information (Tripathi, Karnik, Vora, Ahmed & Singh, 1999). Along with this, the agent also has a well defined itinerary that defines the agent’s complete path migration, meaning that it defines the entire route of where the agent is going to move in its journey from the host. This looks like a list with a pointer denoting at which platform the mobile agent currently resides. The mobile agent also has its credentials that tell the creator of the agent and the mobile agent’s intentions, in other words a description of why the agent was created in the first place. This acts as a signed certificate to authenticate the originality of the agent. The agent uses the agent environment that is an interface to the agent server. This provides the agent with the service to communicate with other agents, access the

82

resources available or to migrate from itself to another server. On the agent server, there are three underlying services. The resource registry keeps track and sets safe bindings with the agents. This means that it is basically a log for the sharing of resources to avoid conflict and also to avoid denial of service by blocking of resources. Then there is the domain database that keeps track of the agents currently executing on the platform and sends this information back to the sending platform or host of the agent. The agent transferer provides the means and the protocol to actually transfer the agent over the network to its next server or back home as indicated by the agent’s itinerary (Tripathi, Karnik, Vora, Ahmed & Singh, 1999). Resource access is through the proxies of the resources (Tripathi, Karnik, Vora, Ahmed & Singh, 2000). These are simple object representations of the actual resource. The agent is assigned a proxy object according to its access rights as indicated in its credentials. The proxy contains the accessor methods to the resource and its content. For the access, the environment provides a resource access protocol for the agents. The agent looks up the resource according to its URN (Universal Resource Name). The proxy is then delegated according to the policy on the server. Agents can talk to one another through the resource proxies or may install proxy RMI server for its self. The agent registers itself with the server as a service resource and allows access for communication with other agents. Similarly, the agent may request installation of a RMI proxy. The agent, if allowed, creates a proxy object with the local RMI registry. Another agent looks up the agent according to its name and queries the RMI registry through which it obtains a stub (Tripathi, Karnik, Vora, Ahmed & Singh, 2000).

83

5.6.2 Security in Ajanta

Security in the Ajanta MAS is for both the protection of the mobile agent and the server that the agent is executing on (Karnik & Tripathi, 2000). It sets its security objectives to protecting the server in terms of leakage of information, the protection of the agent’s data from being spied on, the code alteration prevention, the protection of the resources from attacks such as denial of service and protection of the names database that contains the namespaces of other services and agents can be tampered with.

Agent Server Protection

The Ajanta server uses authenticated communication (Karnik & Tripathi, 2000). This is based on a challenge response authentication protocol. The agent possesses a ticket that will identify it to the server. The ticket is obtained by issuing the authenticate service when it arrives at a server. The agent provides its name to the authenticate service and to challenge the server for its identity, the agent provides a nonce value. The agent and the server then exchange their authentication details within the ticket. The ticket thus contains the agent’s signed credentials, is name and the nonce. The server signature is then verified by the server’s nonce reply. The agent then sends its request and the communication is established. Here the ticket is continuously checked by the server. The server has already stored an identified agent. If the agent is not present in the table, or suddenly the ticket contains a different value, the agent is rejected and called untrusted. The security is provided by the agent transfer protocol. This works in three steps between a sender and a receiver server of the mobile agent. First the request is sent by the sender to the receiver. This request is the Agent Transfer Protocol that contains the agent’s name and its credentials only. Based on this the receiver authenticated the 84

agent’s signed credentials and then checks if the sender is where the agent is actually coming from all through the name service. Then, the agent may or may not allow the agent to migrate onto the server (Karnik & Tripathi, 2000). Upon acceptance the agent is entered into the domain database of the receiver server. The entry is marked so that its credentials can be re-verified when the agent is received on the receiver. Then, the sender gets an acknowledgement so that it sends the agent if the permission is granted. The agent arrives at the receiver server and is then re-verified for its credentials. These are then compared to the credentials that were previously obtained. This prevents stolen credentials and the entry is unmarked so that it is in a verified state. Lastly, the location of the agent is updated in the name service to point to the new server (the receiver) that it has arrived on. This in turn reduces the risk of replication of the agent (Karnik & Tripathi, 2000). The Ajanta Security Manager is an extension of the RMI Security Manager that protects the resources through agent access rights. It maintains an access list according to the agents name and provides access based upon the agent’s owner. The agent is thus given access to the resources or disallowed through the access list. An agent is not allowed to run in any other thread than the one allotted to it. Resources are accessed by proxies that define the resource’s security policies (Karnik & Tripathi, 2000). This makes the access to the actual resource a private access and based on the agent’s credentials the proxy disables methods not allowed to it. If an agent commits an allowed method, the call is made to the resource; otherwise a security exception is thrown. This is also made dynamic and the agent rights can be changed dynamically during the execution.

85

Similarly, the resource is bound with the agent according to a resource access protocol (Karnik & Tripathi, 2000). The protocol has the duty to create a proxy object based on the agent credentials. This also makes an entry in the resource registry. The registry cannot be tampered as it contains the ownership information along with the resource name and its proxy objects name. The proxy that is made for the agent contains the enabled and disabled methods according to the policy set for the particular agent credentials and is passed on to the agent through the environment. The server makes sure that the proxies are made by the server and not the agent, because that may allow unauthorized access (Karnik & Tripathi, 2000). Also, the proxy is not inherited from any other class that may allow public access to the resource; the proxy is thus completely private. The proxy cannot be copied by agents because it is transient in nature and thus unserializable for the agent to copy and send to another cooperating agent for copy. The proxy object does not implement the cloneable interface in Java and thus cannot be cloned. If it were, the agent may keep using this clone for a denial of service attack on the resource as the server only has a reference to the original.

Agent Protection

In Ajanta, the protection of the agents is done during its transmission as well as on the agent server. The agent transfer protocol is thus made cryptographic in nature. This enables that the agent is not tampered with during execution. Also, a signature is added to check for tampering after the agent has covered an untrusted path (Karnik & Tripathi, 2000). An agent protection on the server is done by allowing the agent to have read-only parts, to have append-only logs, to have the ability to keep certain objects of the agent visible 86

and the rest invisible to the server and also a means to protect the agent from being copied, stolen, and impersonated and so on. Read only states in an agent are done by using a private key to sign the data (Karnik & Tripathi, 2000). Also, the credentials are signed along with these read-only data so that this is not replaceable by a tampering server with readable data. Append only logs allow only addition of certain information that is collected at the different servers during its course of motion in the network. This is done by keeping the log under signature of its adding server. Each server signs its addition and sends the agent this in turn builds up to a checksum of the agent. The owner decrypts the log and checks the checksum. If the checksum is valid, the agent is accepted. The protection of agents’ objects through visibility is also possible by encrypting the objects (Karnik & Tripathi, 2000). If the visibility is required, the objects can be decrypted by the server that has the key to the object. Lastly, the agent has to be protected from copy and from masquerade (Karnik & Tripathi, 2000). To avoid copy, only the owner can modify the agent information. The location is kept for the agent and this location is updated with the agent’s movement. Only the creator can update this information. Thus, if a copy is sent, two same agents would be sent and have to be recorded, this is impossible and there is only one copy of the agent. Then to protect masquerade or impersonation of the agent, the read-only state that is bound to an agent would have to be replaced. Since the replacement would cause totally different credentials with the data, the agent is invalid. Also, the change in the course of the agent journey can be checked since the owner of the agent has an original itinerary as well as the traveled itinerary from the agent’s entire journey. If there is a mismatch, the agent has been tampered with. 87

Name Service Protection

It is important to protect the critical components and services of the system (Karnik & Tripathi, 2000). This is threatened by illegal modification of the name service and the protection of the namespaces. The updates are controlled by using an access control list for the entries in the name registry. This access is only left to the owners of the names for updating. Also, the namespaces for the entities are given a key that is accessible by allowed agents. Agents are only allowed to use their own namespace. This is controlled by the server itself.

5.6.3 Comments on the Security of Ajanta

Security in Ajanta is reasonably strong in accordance to the protection of the agents and the platform itself. The agents are protected from malicious activity and from corruption by the server in Ajanta. Also, the Ajanta server, its resources and the services are protected from misuse and malicious activity from the agents. However, its security has a few weaknesses: 1) Ajanta provides a mechanism of spying on the agents and to replay the agent to create their own for piracy. All the execution is watched by the environment and the security manager. The requests made to these can be logged and used to create an agent based on its actions.

2) The proxy generator would have to be rather intelligent to create a dynamic policy that would also ensure that what ever it is bypassing is still secure.

3) Key distribution mechanism has not been covered in Ajanta’s architecture so far. 88

4) Sending information back to the agent owning server is necessary in cases and is not possible always.

5.7 Aglets The Aglets Workbench (AWB) is another Java based mobile agent system. It was developed by IBM and contains a development environment for agents (called aglets in AWB) and an environment for their execution (Karjoth, Lange & Oshima, 1997). The Aglets model allows Java objects, called aglets, to visit aglet-enabled platforms on a network. The aglets execute on one platform and then migrate to another and commence their execution there. The Aglets MAS allows only agents written in Java. It has various security considerations like authentication, policy implementation, mobility security and resource access security (Karjoth, Lange & Oshima, 1997).

5.7.1 General Architecture

Aglets allows the creation of Java objects called aglets (Karjoth, Lange & Oshima, 1997). These aglets contain their code as well as data. The aglet runs with its own environment which is called a context in Aglets. This context is a stationary object that runs on the server. The purpose of this is to maintain and manage the aglets that are executing on the platform and also to provide an interface for the aglets to the platform. The aglets are only accessible through their proxy, which is in actuality a representation of the aglet. The proxy gives the accessibility protection as well as transparency to the location of the agent. As shown in Figure 5.8, the agents communicate using message

89

objects and not method invocations. The messages are thus exchanged between the proxies of the agents. Each aglet has its own message handling method that handles the messages coming from other agents.

Figure 5.8: Aglets Architecture (Karjoth, Lange & Oshima, 1997)

Aglets works on an event-based scheme rather than a process migration scheme, this means that the agent fires an event based and based on this it causes a proper event handling mechanism that is customizable by programmers. An agent is created and assigned an identifier to distinguish it (Karjoth, Lange & Oshima, 1997). Then, the agent is inserted into the context where it immediately starts execution. To migrate, the agent removes itself from its current context and inserts itself into a destination context. This is a push and pull based scheme since the aglet is pushed into its destination context and pull from its current context into the calling context.

90

5.7.2 Security in Aglets

In Aglets security is for the protection of the hosts from the agents, from other agents, of the agents from the host and protection of the underlying network. Aglets ensures this protection by providing identities, policies, mobility and also the resource access (Karjoth, Lange & Oshima, 1997).

Authentication

Aglets has a concept of principals that contains the following information (Karjoth, Lange & Oshima, 1997): •

aglet’s manufacturer

•

context

•

context’s manufacturer

•

context’s master (administrator, owner or operator)

•

domain (group of contexts)

•

domain’s authority

The aglet is authenticated using its name. The name is basically the class name or in other word the product name. This is basically the identifier assigned to it by the context. This in turn is used by the context to authenticate it and apply its policy on it. Also, the aglet itself has to be made secure on the platform it is executing on. The preferences are set accordingly. For instance, an aglet may not want all the platforms to view its itinerary data. The capabilities of the aglet can also be set here, like the number of hops, the CPU consumption and other things of this sort. The context is also assigned an identity according to the CPU serial and the version of software and hardware. Since the

91

authorization on every context will be costly, domains can authenticate as a group. Thus an authenticated aglet can authorize itself on the domain and utilize all contexts under that domain. For authentication, Aglets defines an authentication language that allows the definition of principals and their access. Also, the language defines a means to define the privileges of the aglet as defined by the aglet programmer (Karjoth, Lange & Oshima, 1997).

Policies

The Aglets MAS contains a policy that overrides that specified by the aglet principal (Karjoth, Lange & Oshima, 1997). The policies set by the context are placed in a policy database. The policy describes the mapping of the principal to the policy of the context.

Mobility

Mobility is made secure by keeping track of the aglet’s context of origin, the context it is execution on and the destination context (Karjoth, Lange & Oshima, 1997).

Resource Access.

For the access of resources, the Aglets MAS enforces that all references being made to the context be monitored by a reference monitor. This gives allowance to the aglet only if it complies with the policy of the context (Karjoth, Lange & Oshima, 1997).

92

5.7.3 Comments on the Security of Aglets

Aglets has substantial security mechanisms and provides protection to the mobile agent system up to an extent (Fischmeister, Vigna & Kemmerer, 2001). However, the Aglets security model has its weaknesses and limitations. These are as follows: 1) Reflection can attack and reveal agent code and allow agent misuse by revealing methods.

2) Context Manager overlooks the modifications made to a policy in the policy database as they are accessible.

3) Aglet agent can spoof the system to obtain values from the user and sent them back to the host.

4) The Aglet language is very costly to use and interpret.

5) An aglet’s internal state is not protected and can be tampered with and even simply accessed for spying or eavesdropping.

5.8 Concordia Concordia infrastructure was developed by Mitsubishi Electric and is another Java-based MAS. Thus, it supports mobile agents implemented in Java. The Concordia infrastructure has support for highly mobile agent execution and also for their development. It supports agent collaboration, persistence of agent state, reliable agent

93

transmission and also the issue of security. Security is based on protection of agents from harm and the protection of the server resources from unauthorized access (Wong et al., 1997).

5.8.1 General Architecture

The Concordia architecture contains several components that are shown in Figure 5.9. These components are basically Java class libraries allowing execution, development and activation for agents. Basically, the entire system resides and executes on a Java Virtual Machine (JVM). Agents in Concordia can span local as well as wide area networks. Concordia agents have code and data as well as it state in mobility. Along with this, the agent has an itinerary of its path in the network. it uses a destination URL and a method value table in its itinerary to tell where the agent has to go to complete a particular task. Figure 5.9 shows the architecture in terms of the interaction of components in Concordia.

94

Figure 5.9: Concordia System Architecture (Wong et al., 1997)

The Concordia Conduit server acts as a server through which the agents are transferred. This means that this server calls the destination host for an agent to transfer (Wong et al., 1997). The server contacts the Conduit server of the destination platform and thus forms a receiver as well. All agents that arrive at a Concordia platform meet the Conduit server for propagation. The server implicitly has the service of locating the destination as well for agents to propagate. Conduit servers also allow queuing of the agents to facilitate the underlying network between a server and an agent destination server. Agent interactions are either asynchronous events or agent collaborations. The asynchronous events are scheduled by the Event manager. However, for collaboration, the agent code must contain the issuance of an agent group that allows group formation of agents belonging to the same group. For events, each agent registers with the Event

95

manager to receive events from a particular agent. The agent also gives its location and this is continually updated so that the agent can keep on receiving events. These registrations are kept in the Persistent Store manager. The Event manager uses a proxy to maintain its connections with the agents (Wong et al., 1997). The Persistence store manager is implemented through Java serialization. This component allows the storage of internal state of the agents for agent persistence and recovery. This can be used in case of failures as well (Wong et al., 1997). The Queue manager facilitates the queuing facility of the Conduit server. This is for both the inbound and outbound queues on the server (Wong et al., 1997). The queuing manager is responsible of contacting the remote Conduit servers and the remote Queuing servers for reliable transmission of the agents over the network.

5.8.2 Security in Concordia

For the security, Concordia has the Security manager and the Administration manager. The Concordia security model protects from agents harming the server resources through unauthorized access and agents to be tampered with by the server or other agents (Wong et al., 1997).

Agent Protection

The agents are protected while they are on systems as well as when they are in transmission and also in the persistence storage through encryption. For this the SSL is used (Wong et al., 1997). Also, a function of the Administration Manager is to check the agents on the network to see if they have reached their destination along with keeping a log of this with itself. 96

Resource Protection

To protect the resources, the Concordia Security manager operates. Each agent has its identity that is used for access to the resources. The access is adjusted by the manager dynamically as required by the server. The Administration manager in Concordia starts and shuts down the servers that are in the MAS and is also responsible for the changes in the security profile of the agents and the server that they are running on. It sends requests on the behalf of the agents and the servers to the Security manager (Wong et al., 1997).

5.8.3 Comments on the security of Concordia

Despite the efforts in the security of Concordia, the security has its weaknesses. The system supports a set of features yet, the question of security in MAS is limiting. The weaknesses and limitations in Concordia’s security model are as follows: 1) Agent communications and collaborations can be spied on by simply registering itself to the Event manager.

2) Platform may be threatened by masquerading agents as the authenticity of the agent is not assured.

3) Queue manager may be corrupt and may make the agent suffer from DOS attack.

4) Agents may threaten the administration server as direct access is possible.

5) Itinerary is not protected. 97

5.9 Grasshopper The Grasshopper platform is another Java-based MAS but it is based on both the OMG MASIF and the FIPA standards for mobile agent systems. Grasshopper was developed by GMD FOKUS and IKV++ GmbH in Germany. Grasshopper was developed to be compliant with mobile agent and intelligent agent development standards that are existent in the agent research community. It was thus developed to be MASIF compliant and was extended to include the FIPA compliance as well (Baumer, Breugst, Choy & Magedanz, 1999). Grasshopper is developed to allow the creation of simple agent-based systems to a more complex multi-agent system. Grasshopper agents can thus communicate and interact in both a transparent and interactive means with multiple protocol support. Grasshopper is another Java-based MAS.

5.9.1 General Architecture

Grasshopper classifies its agents based on their nature of action meaning that it has two types of agents, mobile and stationary. Each agent has its own set of functions and data. The agents run inside an agency. Thus, an agency is the agent runtime environment. The agencies also have 2 parts, the core agency that provides basic execution of agents and the set of places. Similar service provision is grouped into a place. Each agency is registered to a region. Regions make the distributed components, containing agents, places and agencies more manageable. This makes up the Grasshopper Distributed Agent Environment as shown in Figure 5.10.

98

Figure 5.10: The Grasshopper Distributed Agent Environment (Baumer, Breugst, Choy & Magedanz, 1999)

The Grasshopper core provides communication services so that the distributed components can interact with each other. For this, the region registry provides the communication mechanism. The registry contains the CORBA interface in the form of the MAF Agent System for remote interaction as well as other mechanisms using RMI, IIOP or plain sockets. The management of the communications is handled here as well. Transformation services are present on the system that actually provides the underlying mobility of the agent itself (Baumer, Breugst, Choy & Magedanz, 1999). Registration of the agent is necessary to know what agents and services are on the system. This in tern is used to provide information to the information seeking agents on the system. Also, management services are available to monitor and control the agents and services on the system (Baumer, Breugst, Choy & Magedanz, 1999). Another provision is the persistence service that allows the storage of the agents and the places so that they can be revived in the case of a fault (Baumer, Breugst, Choy & Magedanz, 1999). 99

5.9.2 Security in Grasshopper

Grasshopper provides two types of security, the external and the internal security. The security that Grasshopper provides protects the agent platform and the agent interactions. For these, the Grasshopper MAS uses SSL, certificates and also Java security mechanisms. External security in Grasshopper protects remote interactions between the various components distributed on a network. To protect the communication, symmetric key encryption protocols are used on secure sockets. For this, Grasshopper uses RSA. Also, to protect from message corruption, authentication codes are used to check if there are any errors in the agent during the transmission. For this Grasshopper uses MD5. Authentication is used by Grasshopper that includes identities associated to the various components. For this, digital signatures are used to sign the data (Baumer, Breugst, Choy & Magedanz, 1999). Internal security protects the resources from illegal access and the agents from each other. For this, it maintains a policy in the form of an access list that contains the permissions for the components. The permission has a type, a target and one or more actions to access the agency. The access controller is consulted upon request to access a resource. The access controller accesses the information of whether the accessor is an agent. If it is an agent, its owner information is extracted from the agent and then the policy is checked. According to this policy, access is granted if allowed, and if not, an exception is thrown (Baumer, Breugst, Choy & Magedanz, 1999).

100

5.9.3 Comments on the Security of Grasshopper

Grasshopper security, though substantial, is limiting and weak in ways (Fischmeister, Vigna & Kemmerer, 2001). These are as follows: 1) Access checks in trusted classes are bypassed making it possible to shut down the server.

2) Agent platform information like the name of the agency, the protocol and the region registry are accessible.

3) Policies can be generated that can alter the launch and the authentication in the system.

4) Agent communication is still easily spied on by the platform.

5) There is no itinerary in Grasshopper. An agent’s sending information is up to the platform according to the code and a malicious platform can deny transmission.

6) Resources are protected and controlled by a security manager not by proxy delegation or wrappers.

5.10 Mole The Mole MAS was developed at the University of Stuttgart and is another Java-based MAS. The Mole MAS has been developed for the development and use of mobile

101

agents. Mole uses a very strong concept of communication, interaction and mobility of agents. The security is thus based on the mobility provisions that Mole provides. Mole secures the agents and the platform the agents are executing on (Baumann, Hohl, Rothermel & Straber, 1998).

5.10.1 General Architecture

Mole has a rather simple architecture and consists of basic components to provide execution, communication and transfer of mobile agents. Also, it contains resource management and consumption services to provide control over access and to manage the platform components (Baumann, Hohl, Rothermel & Straber, 1998). It looks somewhat like that of Figure 5.11.

Figure 5.11: Mole Architecture (Baumann, Hohl, Rothermel & Straber, 1998)

Mole contains the concept of mobility in its provision for mobile agents. This utilized the Java RMI, the agent threads are suspended, no message calls are accepted, the agent is removed from the list of agents and the agent is serialized. The agent is then reinstantiated and the agent is started.

102

Agents can interact with each other through the directory. Each agent is assigned an Agent ID that allows it to be located on the platform. Each agent can be either active or passive, depending on its mode. If it is in a listening mode it is passive and if it is in a sending mode, it is active. So, an agent can register itself into the directory to detail its provided service. The agent is then contacted by the active agent for service (Baumann, Hohl, Rothermel & Straber, 1998). Mole consists of a communication service that allows the agent to interact in different ways. One of the methods of communicating is that the agent interacts with another agent for its service. Second is that the agent spawns or controls another agent. Third is that the agents know each other to form a group and interact with its group (Baumann, Hohl, Rothermel & Straber, 1998). These are handled by the communication service. Agents are allowed access to the resources according their allowed permission. This permission is based on their accounts and the resource control or the policy. Various components are managed by the resource manager that checks each request according to the policy that the agent has according to its Agent ID (Baumann, Hohl, Rothermel & Straber, 1998).

5.10.2 Security in Mole

Security in Mole uses a simple technique to protect the resources and the agents. It uses the simple Sandboxing model which does not allow an agent to use certain dangerous commands that the agent may issue. For this, service agents are present that actually provide the system access between the agent and the resource itself (Baumann, Hohl, Rothermel & Straber, 1998).

103

Mole also uses places for mobile agents. An agent place can set restrictions on which agents to allow and which not to allow. The agent access to resources can be controlled via the policy set by a place as well. Agents in the place and outside the place both have different policy settings (Baumann, Hohl, Rothermel & Straber, 1998). Resources are protected by the service agents as direct interaction is not possible. Secondly, the manager prevents DOS attacks from the agent in cases where the agent does not let go of the service as there are allocation times to the resources in the resource management service (Baumann, Hohl, Rothermel & Straber, 1998).

5.10.3 Comments on the Security of Mole

Mole Security is small and thus rather limiting. The limitations and weaknesses are as follows: 1) Sandboxes limit the agent activities and functionality as they are not allowed to do much.

2) There is no security for the mobile agent code being tampered or spied on by outside sources.

3) Agent migration paths can be tampered with as the platform is responsible for the agent transport and migration.

4) Logging of resource access is done and not of the agent execution.

104

5) To control access to resources, service agents provide a trusted middleware for their access.

5.11 MAS Security Evaluation Mobile agent systems security is evaluated by the kind of approach they use for the protection of the mobile agent and the agent platform. This is summarized in the form of two tables. The first table contains the techniques to protect mobile agents in the mobile agent systems surveyed. Table 2 summarizes the techniques used in the protection of the agent platform. The tables show if a particular technique is present, denoted by a Yes and if not present, it is denoted by a No. TBI means that the technique is To Be Implemented in the system as said by the authors of the system. Partial means that a technique exists but not completely.

Table 5.1: Mobile Agent System Security Evaluation – Mobile Agent Protection Partial Result Encapsul ation

Environme ntal Key Generation

Code Obfuscati on

Cryptograp hic Functions

Execution Traces

Itinerary Protection

Time Technique s

Telescript

Partial

No

No

No

Yes

No

No

AgentTcl/ D’Agent s

No

No

No

TBI

Yes

Partial

No

Ara

Partial

No

No

Yes

Partial

Yes

No

Tacoma

Partial

No

No

No

Partial

Partial

No

Ajanta

Yes

No

No

No

Yes

Yes

No

Aglets

No

No

No

No

Yes

No

No

Concordia

Yes

No

No

Yes

Yes

Yes

Yes

105

Grasshopp er

No

No

No

No

Yes

No

No

Mole

No

No

TBI

No

Partial

No

No

Table 5.2: Mobile Agent System Security – Protection of the Agent Platform Agent Authen tication

Path Histori es

State Apprai sal

Resour ce Protecti on

Fault Isolation or Sandboxing

Safe Interpretatio n and Padded Cells

Proof Carryin g Codes

Moneybased Techniq ues

Telescript

Yes

No

No

Yes

Partial

Partial

No

No

AgentTcl/ D’Agent s

Yes

Yes

TBI

Yes

No

Yes

No

TBI

Ara

Yes

No

No

Partial

Yes

Yes

No

Yes

Tacoma

Yes

No

No

Yes

No

No

No

Yes

Ajanta

Yes

No

No

Yes

No

No

No

No

Aglets

Yes

Yes

No

Yes

No

No

No

No

Concordia

Yes

No

No

Partial

No

No

No

No

Grasshopp er

Yes

No

No

Yes

No

No

No

No

Mole

Yes

No

No

Partial

Yes

No

No

No

106

Chapter 6 Mobile Agent Security Framework

This chapter presents the details of the proposed framework for mobile agent security. The proposed framework protects an agent as well as the platform that the agent executes on. It comprises of various components to enhance the MAS model to provide the essence of security.

6.1 Framework overview The proposed security framework comprises of certain components. These in turn have their own sub components that are added or enhanced from a general mobile agent system to add security measures. Generally, the host spawns an agent that travels from one platform to the next for its processing. The spawned agent keeps the list of the platforms to be visited in its itinerary. Another way may be that an agent be spawned for each platform. That means n agents for n platforms to go to the platform and come back instead of one agent to go to

107

each platform one by one. Thus, allowing parallel execution of mobile agents on platforms. The mobile agent is comprised of code and state data that is executed to perform certain necessary tasks required by the host that sends the mobile agent for its functionality. It requires the platforms execution environment to fulfill the tasks that are assigned to it. The mobile agent visits the various platforms in its itinerary to acquire the services and resources that are required by the host the mobile agent belongs to. The agent is sent as an encrypted set of methods that can only be decrypted by the platforms it is visiting. Also, sensitive information is made immutable such that it can be viewed but not changed by any other component other than the host. Upon completion of its journey, the agent returns home (to its spawning host) and provides the host with the service results it was sent to acquire in the first place. This entire process is shown in Figure 6.1. The host spawns an encrypted mobile agent that is sent onto the agent platform 1. On this platform, upon authentication of the mobile agent, the mobile agent is decrypted and its execution commences. The mobile agent then migrates to the next platform, agent platform 2. Here the mobile agent goes through the same process. Finally, after its itinerary is complete, the mobile agent returns to its host. The framework thus has a few distinct components that can be drawn from Figure 6.1. These are the mobile agent, the host that creates and collects the mobile agent and the agent platform(s) that the mobile agent executes on. Each of these components has their own subcomponents that allow the MAS to actually process. These components are enhanced and tailored to provide the required levels of security that a MAS requires.

108

Figure 6.1: MAS framework overview

6.2 Framework Assumptions The proposed framework operates based on certain assumptions. The assumptions are listed and discussed prior to the framework. These are listed as follows: 1) Host and platform discovery is done prior to the security concerns.

2) Failure of the platforms, loss of agents during transmission is outside security issues and is a part of fault-tolerance of a MAS that can be added along with or as an extra feature (or set of features) to the system.

3) Tamper-proof hardware exists such that the transmission is not tamper-able by an external attacker during agent transmission.

109

4) Itinerary is built a-priori. The host knows where the agent is going rather than an agent discovering its course.

5) The agent that has left the host will become malicious. Thus, every agent that returns has to be checked and tested before it is accepted by the host from where it left initially.

6) Cost to provide security is acceptable in terms of size of the agent, the processing time and the actual transmission of the agent.

6.3 The Host The host platform is the origin of the mobile agent. This is the base system that requires a mobile agent to execute remotely for its own needs. The responsibility of the host is to allow the creation of reliable and secure agents that contain processing information. Also, it has the responsibility to provide a docking environment for agents to come back after their journey, gathering their results, manipulating these results and then finally disposing the used mobile agents. Each host has their subcomponents that are shown in Figure 6.2. These components are discussed in detail as follows. Figure 6.2 shows the host component which is the centre for mobile agent creation and then the collection of the returning agents.

110

Figure 6.2: Host

6.3.1 Agent Creator

The host spawns the mobile agent with a mission to process its information on a remote agent platform. For this mission, all necessary data is provided to the agent, this includes data to be processed, state data, path data and agent credentials. Along with the provision of the code and data the agent is assigned its credentials. These include the necessary details that distinguish the mobile agent to the host and the agent platforms in its itinerary. The credentials include an agent ID that is unique for every agent. This is entered into an agent spawned log on the server along with a validity time for the agent. Then there is a host name that tells a receiving platform to which host the agent belongs to. The credentials are then signed by the host using its private key.

111

6.3.2 Agent Dock

An agent that is to be sent is first docked into a transfer queue where its identity is entered into a list. Also, the agent is digitally signed and its methods are encrypted using the host’s private key. The agent is also allotted a list that contains the various platforms it has to visit on its journey. This list for agent platforms is the agent itinerary. After the agent has completed its journey, it returns to its home station. First of all the agent ID that was initially assigned by the host is checked. This ID is responsible for telling the host that the agent actually belongs to the host and is one of its own. The collected mobile agent is decrypted using the host’s private key and its results acquired. This mobile agent is then disposed by the host as it becomes useless. The mobile agents’ entry into the spawned log is then removed. The host provides a mobile agent transfer mechanism that implements the protocol for the deployment of the agent on the network.

6.4 Mobile Agent The mobile agent is the most integral part of the mobile agent system. Since it is prone to a lot of danger from the network and the platform that it is running on, the mobile agent needs to be protected. In the proposed framework the mobile agent is made secure by adding certain security measures to its construction. The agent has its own components that need to be secured and protected from the various threats that may prevail. Thus, for the agent we define security at its component level. The security components are discussed in this section.

112

The secure mobile agent is shown in Figure 6.3. The various subcomponents that are shown in this figure are described as follows. The mobile agent subcomponents are similar to many other MAS agents. Thus, we modify the mobile agent slightly to include some of our own necessary information.

Figure 6.3: Mobile Agent and its components

6.4.1 Code and Data

The mobile agent contains both code and data. The code is composed of its functionality in the form of methods. The data is the agent state in its migration from one platform to the next. The methods that exist in the mobile agent comprise the methods that the agent is required to perform on the platforms. The data part in the mobile agent is composed of the computation results on each platform that the mobile agent has visited in its entire journey. These data values are required for certain computations as intermediate results and some of these are the end

113

results that are required by the host from the mobile agent that it was sent for in the first place.

6.4.2 Itinerary

The agent also contains an itinerary that details the hosts it has to go to in its cycle of motion. This is the list of the agent platforms that the mobile agent has to visit as it is spawned from its host. The itinerary has a pointer that denotes the agent’s current platform. From this the next platform can be determined by the agent when it has to transfer from its current platform. Figure 6.4 shows the illustrated form of what an itinerary looks like. It contains a number of the platforms that the mobile agent visits on its way. The itinerary also has alternates that the agent may choose between. When the itinerary is read the alternates are considered as an either-or selection. Another thing to notice is that along with the platforms is their public key that have been added to the itinerary for the re-encryption of the code of the mobile agent at various platforms.

Figure 6.4: Itinerary

114

6.4.3 Credentials

One more thing that is added is the agent contains other information listed as the mobile agent’s credentials. The credentials contain the agent’s host, the agent’s creator, the agent’s identification (agent ID). From this, the agent’s digital signature is computed that is then used to authenticate it on various platforms. This is similar to the mobile agent certificates in (Tan & Moreau, 2002).

6.4.4 Certificate Vector

This contains the set of certificate for each particular platform individually. A certificate is for a particular platform in the agent itinerary denoting a set of rights that is required by an agent on that platform. The certificate is digitally signed by the host. A simplified illustration certificate vector is shown in Figure 6.5. The vector contains various certificates that are present for the designated host. The certificates are according to the role that the agent may assume on a specific platform. According to these roles, the required resource is listed.

Figure 6.5: Certificate Vector

6.4.5 Hash List

This is an append only list maintained for firstly carrying the immutable and read-only correct hash of the code of the agent signed by the host’s private key. The list keeps on 115

building as each platform the agent visits in its itinerary recomputes the agent code’s hash and digitally signs it with its private key to this list. A simplified illustrated hash list is shown in Figure 6.6. As shown, the list contains the original hash value of the code signed by the host. Each platform and the mobile agent code’s recomputed hash value that is signed when it has visited the platform are placed in the list. This means that initially the list is built up as the mobile agent progresses in its journey.

Figure 6.6: Hash List

6.4.6 Encryption Function

This is a method implementing an agent encryption function. This function uses the public key of the agent’s destination platform embedded within the agent itinerary to encrypt the agent in an asymmetric manner such that only the platform with its proper private key can decrypt the mobile agent code for executing it. The same encryption function is used to encrypt the data as well. There is data that the mobile agent requires on the destination platform. This is kept in a briefcase that is encrypted with the same public key (destination platform’s public key) as the code and sent along with the agent. The other data that is only required by the host is encrypted using the public key of the host to keep the data private. This is only decryptable by the

116

host platform as it requires the private key of the host for decryption. Thus, the data is protected from view by other platforms.

6.5 Certification Authority The Certification Authority (CA) is a trusted third party available in the network to maintain a form of trust among the domain of the hosts and platforms that are utilizing a MAS. The CA and its subcomponents look like Figure 6.7. This CA is similar in concept to the CA in (Fu, 1999) such that it distributes the keys and creates a point of authorization and verification of the certificate. However, it differs in context and construction in our case.

Figure 6.7: Certification Authority

6.5.1 Certificate Authorizer

The CA provides the host with a certificate carrying the digital signature of the host. Similarly it assigns all other platforms with their own digital signatures to be verified when required. The signatures will never overlap for any server in the MAS.

117

This is shown in Figure 6.7. All authorized certificates by the CA are stored in the Certificate database for later use.

6.5.2 Certificate Verifier

This component is present to verify the signature of a server in the MAS. The request to verify a signature responds with a correct or incorrect signature reply that is used by the requesting server for its verification means. As shown in Figure 6.7, the verifier checks the certificate in the certificate database.

6.5.3 Key Distribution Centre

The responsibility is to provide and distribute public keys of the servers in a MAS. The host requests the public keys of the agent platforms that the created mobile agent will carry in its itinerary for encryption.

6.6 Agent Platform The remote agent platform is a system on the network with an environment allowing the agent to execute its process and the resources it requires to access in performing its function. The platform needs to provide security measures to protect itself from malicious activity from the mobile agent. Also, it needs to safeguard the mobile agent. Thus, it is provided with security components for this purpose. As shown in Figure 6.8, the mobile agent enters the platform and is authenticated using its credentials. The mobile agent is then decrypted by the platform by the platform’s private key. Then the mobile agent is allowed to run in the padded cell to check its

118

commands for building up its access control list to access the resources that may be files, databases and so on as well as certain services or other agents on the platform. As soon as the mobile agent executes, it is migrated to the transferer and allowed to encrypt itself. The details of the architecture of the platform in our secure mobile agent framework are present in the following sections that discuss the various subcomponents of the framework. Figure 6.8 shows the platform component of our MAS and its subcomponents along with their respective interactions. Figure 6.10 shows the process of administering the rights on the mobile agent that is authenticated, in other words, the authorization process of our proposed secure mobile agent platform.

Figure 6.8: Agent Platform and its components

119

The resource registry, domain database and the agent transferer are similar to Ajanta but in retrospect the components have different functionality and relation to the other components that are not a part of the Ajanta MAS (Tripathi, Karnik, Vora, Ahmed & Singh, 2000). The proxy delegation is adapted from (Tripathi, Karnik, Vora, Ahmed & Singh, 2000) but it is extended to be generated from the Access Control List.

6.6.1 Authenticator

This component provides a simple functionality required in our domain, the function of trust. The agent is checked for the digital signature of the creator of the agent from with in its credentials. This allows the agent to enter the platform or not. The agent carries a set of credentials with its code and data. These hold the digital signature of the creator of the agent. The platform can verify the signature from the public key of the creator of the agent. Another purpose of this is to check the agent’s itinerary. The agent path is viewable for where the agent has been. The agent is also authenticated on the basis of the previous platforms of the mobile agent’s journey. Another security issue that is checked is the mobile agent code’s has value for corruption. An agent code that has been corrupted along its path will never be the same resulting in a different hash value. This value is checked with the original value of the agent for authentication as well. The agent certificate vector allotted to the particular vector is also checked. The level of access required by the agent is also a mechanism for its rejection or authentication to the platform.

120

In Figure 6.9, a mobile agent enters the agent dock on the platform. Here the mobile agent’s credentials are checked. The information provided in the mobile agent’s credentials is checked from the Certification Authority. This is done using the agent information gatherer. The mobile agent that is being checked is entered into the domain database to keep track of all mobile agents that undergo the authentication process. The rejected agents are directly sent to the agent transferer. Otherwise the agent enters the platform.

Figure 6.9: Authenticator

6.6.2 Cryptographic Component

The mobile agent’s functions are encrypted and can only be decrypted using a proper key on the agent platform. The agent is decrypted and the functions opened to run on the platform. This is done by encrypting the agent using the agent’s own encryption function. The agent is encrypted with the destination platform’s public key. The agent upon migrating to its destination is decrypted by the platform using the platform’s private key. Thus,

121

only a platform that possesses the correct key can view the platform. This mechanism gives a partial authentication for the agent. This component thus implements a decryption mechanism based on the key given to the agent. The mobile agent code is decrypted and readable by the platform using its own private key. The cryptographic component is in league with various cryptographic approaches covered in the survey of countermeasures. It has resemblance mainly with the approach by (Algesheimer, Cachin, Camenisch & Karjoth, 2001) and its improved version in (Tate & Xu, 2003).

6.6.3 Padded Cell

To protect the platform, we use a padded cell to contain the agent and check its execution before it actually executes. The padded cell disables direct interaction of the agent with the platform resources and checks for malicious activity by analyzing the kind of commands it makes to the padded cell for resources. On the basis of these commands the agent issues, a set of rights are described for the agent according to the policy that is set for the resource based on the mobile agent’s credentials. Some commands are blocked out and some are allowed. As shown in Figure 6.10, a decrypted agent enters the padded cell where it is checked according to the policy that was created for the agent according to its certificate(s) for the platform and its resource. Each command is checked along with the policy and the access control list generated accordingly. The padded cell in the framework is unlike the one in the Safe-Tcl (Ousterhout, Levy & Welch, 1996) security model because the Safe-Tcl model has a feature of only mapping 122

the commands to the master interpreter for safety. Here, we use the padded cell to test an agent and to extract the ACL for applying a policy on the agent execution.

Figure 6.10: Agent rights allocation process (Policy application)

6.6.4 Policy Engine

The policy engine is basically configured by the administrator of the agent platform. The platform sets policies on its resources and services through the policy engine. The policy engine checks the credentials and sets the policy according to the resource to be compared with the command trace from the padded cell. Each agent’s certificate vector is used to apply the policy. That is used to check the kinds of access the agent allows and whether the platform can provide it or not in the platform. This is used to build the policy for the specific agent.

123

Upon comparison, the policy engine provides its second function. The agent access control list issuance. The access control list is like a passport for the agent. it contains the requests it can issue to the resource on the platform. This is according to both the policy set on the agent initially and the performance of the agent in the padded cell. As shown in Figure 6.10, the policy engine provides a policy for the agent. The policy is for the agent interaction with the resource. For another resource it requires, another policy will exist for the agent.

6.6.5 Resource Registry

This keeps track of all the resources/ services on the agent platform. For resources being used it also lists which agent or agents are using what resource and what is the maximum permissible time for an agent to wait for the resource before a resource request is re-issued by an agent that requires the resource for execution. In Figure 6.10, the resource has to register itself in the resource registry to have a policy generated for it by the policy engine.

6.6.6 Domain Database

This is merely a logging station for the mobile agent execution. This component records the actual execution and resource consumption on the platform according to every agent. Each of these entries is against each agent. The domain data base enters an agent and its credentials once it acquires the service of authentication. This means even the rejected agents are logged. The agents that are authenticated and allowed execution are traced until rejected or transferred upon completion of execution. 124

As shown in Figure 6.9, the agent entered has to add itself to the domain database. The domain database is used for keeping track of all occurrences that occur on the platform. The resource keeps on sending this information to the domain database as shown in Figure 6.10. The log of the agent is kept as a trace of execution. This can later be referred by the host if required, so it is digitally signed by the platform that is creating it. This log is kept in the domain database of the platform.

6.6.7 Resources, Their Access and Proxies

Resources are the platform’s data and services that can be accessed. This is through an interface that allows the access of the resources on the agent platform. Thus, the interface is an image of the resource. The proxy is such an interface specially implemented according to the agent access list. According to the agent credentials and nature that is checked in the authentication and the padded cell interactions, it provides accessor methods in its interface. Other methods are turned off accordingly. This is shown in Figure 6.11.

Figure 6.11: Resource binding via proxies

The proxy is also used for the interaction of agents. The mobile agent that requires the interaction with another mobile agent sends a request. The agent then generates a proxy

125

object for the interacting agent according to the agent request and its own implementation. This is shown in Figure 6.12.

Figure 6.12: Agent Communication

6.6.8 Proxy Manager

The proxy manager is responsible for creating a proxy for the resource. This is generated as an interface that provides the access methods for the resource/ service. Here, according to the agent access control list (passport) the agent is provided with a proxy of the resource, by simply enabling and disabling the methods that the resource implements. The proxy manager is responsible for the generation of the proxy. The access control policy is used by the proxy manager to implement a proxy object for the resource that needs to be accessed by the mobile agent. Figure 6.10 shows this. The proxy manager creates a proxy and the proxy is used by the mobile agent to access the resource of the platform.

6.6.9 Agent Transferer

This component is responsible for providing the agent a safe route to the next platform from its current platform. Also, here the agent code hash is recomputed and digitally signed using the current platform’s private key and stored in the agents hash list.

126

This is not a responsibility of the transferer, but it is at this point the agent runs its encryption mechanism and uses the next platforms public key to sign itself. The agent then goes to the next platform as shown in Figure 6.8. Summing up the security framework, the complete view of all the components plugged together looks like figure 6.13.

Figure 6.13: Secure Mobile Agent Framework

127

Chapter 7 Mobile Agents Security Framework – Operation Security Scenarios

Using the proposed security framework we go over the threats in the threat model checking how the framework 1) protects the agent and 2) protects the platform. We present various scenarios one by one handling each threat that the MAS may encounter.

7.1 Scenario 1: Spawning Agents at the host When an agent is created it is assigned an ID for its own reference. The agent is allotted certificates. The certificates are digitally signed by the host with its primary key. This can be verified using the Certification Authority which delegates the digital signature, the private and the primary key of the host. An agent that is created is then placed into the agent transferer where the transferer sets up a secure connection with the destination platform. 128

The agent is created and its information entered into the spawned log. According to each agent, there can be a timer associated after which the agent becomes invalid. This is by allotting an agent a timestamp. Also, during the creation process, the agent is encrypted using its encryption function with the public key of the destination platform in the mobile agent’s itinerary. The public keys are obtained from the CA which maintains a Key Distribution Centre that coordinates public keys to requesting servers. These keys are maintained inside the mobile agent’s itinerary.

Figure 7.1: Agent Creation Process

7.2 Scenario 2: Authenticating the agent The agent arrives on platform A, which is a part of its itinerary. Platform A authenticates the agent according to its security credentials. The public key is globally known. If the mobile agent cannot be identified by its digital signature then it is simply rejected. The

129

signature is verified by issuing a request to the CA. If the CA responds positively, then the signature is valid and the code is authenticated. Secondly, the certificate that is carried by the agent is checked. This tells the resource the mobile agent requires and the privilege that it requires on it. The platform can reject the agent on the basis of its required resource access as well. For example, an agent requires a resource R and the platform does not allow access to it, the platform can reject the agent Thirdly, a mobile agent can be checked for its code integrity. The hash value that the mobile agent is checked with the hash value that the previous platform signed. If these are equal the code is real, if not, the code is corrupt and the agent is rejected. The integrity of the certificate can be checked. The signature of the host that created the agent is checked through the CA. The authentication process is shown in Figure 7.2. This kind of protection guards against the mobile agent masquerading against the platform and for checking for tampering with an agent.

Figure 7.2: Authentication process

130

7.3 Scenario 3: Accessing the mobile agent by the platform Once the mobile agent has been authenticated by the platform, the agent needs to verify that the platform can be trusted as well. The agent can only be accessed by the platform if its code is viewable by the platform and its services. For this, the mobile agent is encrypted using the public key of the destination platform by its own encryption function. The mobile agent can thus only be decrypted by the destination platform’s private key. The mobile agent goes through the cryptographic component of the framework. Here, the mobile agent’s code and data is decrypted. Only the destined platform would know of the agent’s decryption key as it is based on a private key decryption system. If the mobile agent cannot be decrypted, it terminates after a wait time. If an agent life exceeds a particular time to decrypt, it terminates itself. Thus, the mobile agent is protected from the platform’s unauthorized access to decrypt the mobile agent maliciously. The mobile agent re-encrypts itself before it goes to the next platform so this whole process is followed again. The data that is computed at one platform is encrypted by the public key of the host, hence different from that used to encrypt the code. The system will be of weak mobility as execution commencement has to be implicit in the agent code. If this data is required at other places the data is placed as a briefcase, i.e. the state data is saved and execution can use this data to resume. This briefcase is sent virtually with the agent. There are two sets of data, the agent’s private data and the agent’s public data. The private data is encrypted by the agent and can only be decrypted when it returns to the

131

host, by the host. The second is the data that the agent requires to complete its execution at the commencing platforms. This data is kept in the briefcase of the agent. This process is shown in Figure 7.3. The agent that is not decryptable is sent to the transferer to be sent to either the next platform in its itinerary or back to its host.

Figure 7.3: Agent Decryption – Cryptographic Component Process

7.4 Scenario 4: Authorizating the mobile agent The agents are issued an access control list once they are checked by the padded cell. These are kept on the platform’s domain database according to the agent’s identity in its credentials. The mobile agent’s certificate vector is used by the policy engine to obtain a policy along with the actual policy of using the resource on the platform. According to the policy that is obtained from the certificate vector which specifies the resources that the mobile agent requires from the particular platform the mobile agent visits, an agent is authorized for using the agent. Each agent may occupy multiple roles on the platform

132

while it is executing. The certificate for each role may be differently dealing with the mobile agent; hence multiple vectors may exist for an agent at a platform. Each authorized mobile agent’s execution is traced on the platform and kept in the domain database. An authorized agent can use all the resources that it is allotted to it by the access control list. However, direct interaction is prevented through a proxy that stands for each interacting authorized agent to avoid possible manipulation attacks on the mobile agent. This process is detailed in Figure 7.4.

Figure 7.4: Authorization Process – Rights allocation

Another thing worth mentioning is the use of the proxy manager. The agent’s generated access control list is used by the proxy manager to generate a proxy for the agent that is

133

binded with a resource. The proxy manager checks which methods are allowed and which are not allowed in the access control list, accordingly the code interface to access the resource is generated by the proxy manager in the form of a proxy for each agent bind with each resource.

7.5 Scenario 5: Checking the mobile agent’s functionality by the platform An agent that is authenticated is trustworthy but not yet safe. Its functionality may still be malicious. The agent is sent to a padded cell. The padded cell is like a pseudo agent environment. It allows the agent to run and call its commands but it does not fully execute the agent. It instead provides pseudo-resources (“dummy” resources) to check what kind of activity it performs. The pseudo-resources are provided to the mobile agent according to the certificate vector designated for the particular platform and its particular resource. For the policies that are present for the particular resources the agent requires on the platform are used. The policy is used to check what kind of access is permissible. The agent command are checked and if the adhere to the policy they are granted in an access control list that is generated here. The other commands are blocked in the access control list. Also, repetitive and non-terminating commands are checked. For these, the mobile agent is given partial access. This means that the agent can issue the set of commands for a while after which the resource is freed. This is shown in Figure 7.4. The padded cell

134

checks the agent along with the policy associated with it and the resource. Thus there will be multiple policies against each agent in the padded cell for each resource.

7.6 Scenario 6: Accessing and Allocating Resources The agent can only access the resource through a proxy. The proxy is generated using the mobile agent passport in the domain database. The proxy, being an interface, generates the implementation of only those methods for which the agent has access. The agent is the binded to the resource through this proxy. The access is controlled implicitly by the proxy. If the right is supposed to be read-only, the agent will only get the readonly implementation thus protecting DOS attacks on the platform. Also, to protect DOS attacks that may be caused by other agents on the platform, the proxy will register the resource being used in a resource registry. This registry will be controlled by the environment. If there is a race condition and an agent is blocking a resource, it is made to wait for a particular wait time. The resource is freed and given to the next in line. The competing agents have to wait in line according to the policy set in the passport. The higher priority goes to the ID assigned with a priority according to its actions in the padded cell listed in the resource registry. Every agent has a particular time. If the agent does not gain service within that time, it transfers to the next platform or stops executing, as specified by the agent creator. Figure 7.5 shows this interaction.

135

Figure 7.5: Proxy Usage

7.7 Scenario 7: Accessing only through the environment The framework does not allow direct use of the resource and services by the agent. The agent only settles itself and executes in accordance to the environment, i.e. the system. So, the agent relies on the platform’s environment for its deployment and execution on the platform. The domain database keeps track of all the transactions with the platform to avoid repudiation. This protects the platform from being hindered and places the MAS at a separate level.

7.8 Scenario 8: Transferring Agents For transferring an agent, the agent goes through a simple process. The agent is sent to the agent transferer where it is allowed to re-encrypt itself using the public key of the next platform. Also, another thing that happens here is that the agent code has value is re-computed. The hash is signed using the private key of the platform and entered into the hash list. The value of the hash of the code is not changeable if the code has not been corrupted. After this, a channel is opened from the current platform to the next in the agent itinerary. The agent is placed on this channel and transmitted.

136

The process steps that occur during the transmission of the mobile agent in the agent transferer are shown in Figure 7.6.

Figure 7.6: Agent Transmission Process

7.9 Scenario 9: Assigning and Using Agent ID Each agent has a respective ID assigned to it in its credentials assigned by its spawning host. The ID is unique to each agent according to the host’s properties conjoined with its creation timestamp and vendor. Thus an agent that is cloned would have the same ID as its original. It would be rejected by the host if the agent with the same ID is already present on the host, i.e. has returned from its travels.

137

7.10 Scenario 10: Protecting agent communication The domain database records the type of communication going on between the agents and the platforms resources. The environment does not allow multiple resend messages. If a message is to be repeated it is sent after a wait time. The host of course cannot interpret the message exchanges between agents. Figure 7.7 shows this process. For an agent to communicate with another agent it requests the second agent to issue it a proxy. This proxy allows the communication methods that the programmer allows to any requesting agent, unless the agents are from the same host or vendor. In this case the privileges might be greater between them similarly, if another agent wants to communicate, the agent issues another proxy. Also, if the agent that is requesting communication has to be used by the other agent that it is using, the second agent has to request a proxy and the initially requesting agent delegates its proxy in the same way. Thus the proxy is one-way.

Figure 7.7: Agent Interaction

7.11 Scenario 11: Tracing Execution Tracing the execution is done for protection of the platform as well as the agent. The domain database is responsible for logging all the occurrences of execution flow from the time the agent arrives till it leaves the platform.

138

For the case of the platform, the trace can be rechecked in the case the host denies to ever send an agent to the platform. Or, in the case where an agent states that it did arrive on the platform, but it did not process or commit a particular command that it was authorized to perform. In such a case the domain database retrieves the agent’s trace along with its timestamp and presents it to the host of the agent. For the case of agents, when the agent arrives that has exhausted its time limit, it possibly suffered a denial of service attack. The trace is checked from the platform. The one causing the delay can be regarded as malicious. Also, in the case that the agent has been corrupted its hash values can be checked as where the actual change occurred. The trace is called from that particular platform and the platform can be regarded as malicious.

7.12 Scenario 12: Signing Computed Code Hashes Each platform re-computes the mobile agent code that it decrypted and signs it. This is then added to the mobile agents hash list. For an agent that is rejected by the platform or an agent that cannot be decrypted, the same hash that the agent carries is added to the list with the signature of the platform. Since the platform public key is known, this can be used to check the signed hash value of the platform.

7.13 Scenario 13: Protecting the Itinerary Protecting the itinerary is vital because the agent pathway altering means corruption to the core functionality of the mobile agent. So, the itinerary in our approach is created

139

prior to the migration. The itinerary will not change its pathway. Alternate paths are considered as one so that if one of the alternate platforms is visited To protect the itinerary, the hash is computed for the itinerary and digitally signed as shown in Figure 7.1. Any one changing it is not at all possible because then the private key to sign it would be required. Also, the hash is computed to that any tamper in the path denoted in the itinerary generally can be detected.

7.14 Scenario 14: Receiving Agents at the Host When the mobile agent has completed its execution a number of processes are followed. The agent arrives into the agent dock. This part of the dock is for received agents. The mobile agent is first checked for its agent ID and its timestamp. If the ID is of an agent that belongs to the platform, the timestamp and ID must be in the spawned log of the host. If the timer has exceeded the dedicated time value (t = time stamp + time elapsed) the host may consider the agent invalid. However it is processed. To see the processing scenario, we have Figure 7.8. The mobile agent is decrypted using the host’s private key as the agent encrypts itself using the host’s public key before arriving. The code hash is recomputed and compared with the original value. Also, the itinerary is checked by re-computing its hash value. If any of these differ from the original, the hash list is extracted. The host checks where the hash value changed. Since the values are digitally signed, the host requests the platform where the hash changed. The trace is digitally signed by the platform for each agent. The trace is checked for possible causes of malicious activity.

140

ID incorrect – Send to Host’s Platform Authenticator

Decrypt Agent

Authenticate Authenticated Mobile Agent

Mobile Agent

Check ID + Timestamp

Agent code Decrypted

Itinerary Hash incorrect – Call trace

Form Hosts Spawned Log

Check Itinerary

Original Hash

Itinerary Recomputed Hash

Itinerary Correct Code incorrect – Call trace

Check Hash List

Check Code

Hash List

Code and Data

Form Hosts Spawned Log Original Hash

Recomputed Hash

Hash List

Code Correct – Decrypt data

Acquire Agent Data Data

Manipulate Data

Figure 7.8: Receive Process at Host

141

Chapter 8 Implementation

This chapter covers the details of the implementation of the proposed security framework from Chapter 6. The implementation is discussed component by component and then their subcomponents. This chapter discusses the implementation to implement the framework as a prototype.

8.1 Implementation Overview The security framework generically has its main components being the mobile agents, the host that creates the mobile agent, the agent platform that executes and provides an environment to facilitate the execution of the mobile agent and the certification authority that is responsible for certificates delegation, authentication and verification. The implementation of the security features of this framework are discussed in detail to describe how the secure mobile agent framework can be implemented. The language we choose is Java (Sun, 1994) because it provides various security and encapsulation features that we require (Gray, Kotz, Cybenko, & Rus, 2000). Also, in comparison with other languages, it has certain benefits like, portability because of independence of the underlying machine, provision of abstraction to remote

142

communication through the RMI technology and also because Java is very suitable in providing ease to implementing the mobile agents. Another feature that we use is XML (Refsnes Data, 1999) for the specification of certificates that are used in the system. We use XML because of its size and it being a standard that can easily be used to specify the requirements of our system. Also, XML is portable and easy baggage for the agents to carry. We use the specifying of the logs that are present, the certificates, the credentials of the mobile agent, the access control list, the itinerary and the hash list. Similarly XML can be used in accordance to SOAP for communicating mobile agents. Also, it is easy to apply digital signatures to XML documents. Lastly, XML makes the entire implementation language independent and portable. For storage, to make it manageable we use the strength of any Relational Database Management System. The data stored is of the mobile agents created at the host, the certificates at the CA, the domain database at the agent platform. Hence, there is a large amount of data to be tracked. Also, this data needs to be accessed and retrieved quickly. Thus, an RDBMS is sufficient. Also, RDBMS can store and retrieve the XML certificates of the system. For the logging, XML is not used and simple traces are placed in the RDBMS.

8.2 Mobile Agents For the implementation of mobile agents, we use Java. The mobile agent is implemented as a stateful object. By being stateful, the mobile agent maintains its state to resume execution from platform to platform. A mobile agent implements a serializable interface in Java (Gray, Kotz, Cybenko & Rus, 2000). The mobile agent interface contains the

143

methods that are present to implement the mobile agent. These methods include its mobility, its itinerary acquirement, certificate list traversal, encryption, credential access. Thus the structure of an agent has a serializable interface that contains the mobile agent’s general functions. Also, the mobile agent has an accessor interface that is implemented by an accessor class to allow access to the agent. The agent also creates a proxy for communicating with other agents. For this the mobile agent accessor method has a proxy delegation function. The mobile agent specific functions are implemented in the mobile agent class or classes that refer to the agent functionality designated to it by the agent programmer. The mobile agent interface is shown in Figure 8.1.

interface MobileAgentInterface implements Serializable { public void encryptor(PublicKey pubkey, Message message) throws Exception; public Vector hashList(); public Vector credentialsVector(); public Vector nextPlatform() throws Exception; public void go(String URI); public void signHash(); public void getHostHash(); }

Figure 8.1: Mobile Agent Interface

The mobile agent accessor interface implements the Java serializable interface. This is shown in Figure 8.2.

144

interface MobileAgentAccessor implements Serializable { public Vector acquireCredentials(HostID host); public AgentHash acquireHostHash(); public Object decryptAgent(PrivateKey prikey); public void signHash(Signature signature, PlatformHash platformhash); public agentProxy delegateProxy(String request, int requestNo, String agentID); }

Figure 8.2: Mobile Agent Accessor Interface

The mobile agent class is shown in Figure 8.3.

class MobileAgent implements MobileAgentAccessor, MobileAgentInterface { /* Agent data and methods as specified by agent

programmer

*/ public void agentCreate(){} public void agentRemove(){} }

Figure 8.3: Mobile Agent Class

The credentials are placed with the mobile agent in XML. It is shown in Figure 8.4.



Figure 8.4: Credentials

145

Similar to the credentials, the hash list is an XML document which looks like Figure 8.5.

<Signature> <Signature>

Figure 8.5: Hash List

The credentials list holds a number of the agents’ credentials like a vector. This looks like Figure 8.6.



Figure 8.6: Certificate Vector

146

8.3 Host The host implementation is done in Java. The host has a container responsible for the creation and the collection of the mobile agent. The host has several smaller subcomponents that support the functionality of the mobile agent host. The host has a creator component that is basically a factory for agents. For this, we have a simple Java factory for the agents created by a programmer. The creator class is like Figure 8.7.

class AgentCreator { public void createAgent(Vector agentCredentials, Itinerary itinerary, Vector certificates, Agent agent){ AgentFactory factory = new AgentFactory(); MobileAgent agX_impl = factory.initializeAgent(); agX_impl = factory.implement(agent); agX = agX_impl.assignHash(); Agent agX = factory.create(agentCredentials, itinerary, certificates); log(agX); } /* . . . . */ }

Figure 8.7: Agent Creator

To digitally sign the agent any Java signature scheme can be used.

147

8.4 Agent Platform The agent platform possesses a container as well. The responsibility of the container is to allow the agent to execute. The architectural model is of a simple Java container. The agent authenticator uses a simple mechanism of retrieving the mobile agent’s credentials and checking the digital signature of the agent. If the agent corresponds to the specification of the authentication mechanism, the agent is allowed otherwise disallowed. This is shown in Figure 8.8.

class Authenticator { Vector credentials; Object host; Object vendor; //and other information present about the agent in the Vector Authentricator(){ Vector credentials = new Vector(); } public Vector loadAgentCredentials (PlatformID pid, Vector credentialList){ credentials = parseCredentials(credentialList, pid) //gain credentials from the Vector for the platform and put them into their designated places return credentials; } public Object verifyAgent (PublicKey pubKey, PublicKey pubKeyPrevPlat){ byte checkHash = decrypt(pubKey); byte previousHash = decrypt(pubKeyPrevPlat); if (checkHash = previousHash) {

148

//do whatever with correct agent } else //do whatever with corrupt agent //Verify signature checkAgentVendor(vendor); checkAgentHost(host); } }

Figure 8.8: Authentication

The agent decryption mechanism is within the padded cell. It uses the private key of the agent platform the mobile agent is running on to decrypt the code. The padded cell tests the agent according to the policy that is allowed to it. The testing of the agent in the cell and the decryption is shown in Figure 8.9.

class PaddedCell { public Object decryptAgentCode(PrivateKey priKey){ //any decryption algorithm CryptogrphicComponent crypo = new CryptogrphicComponent(); crypo.decrypt(priKey); } public ACL testAgent (Policy policy){ checkPolicy(policy); //execute agent } }

Figure 8.9: Testing the Agent in the Padded Cell

The policy engine is shown in Figure 8.10.

class PolicyEngine { String resourceURI;

149

public Policy grantPolicy(Vector credentialsVector, Resource resource) { //look for resource and acquire the resource's URI Policy policy = accessResourceRegistry(lookup.forName(resourceURI), resource); } }

Figure 8.10: Policy Engine Policy retrieval

The policy looks like Figure 8.11.



Figure 8.11: Policy

The ACL looks like Figure 8.12.



Figure 8.12: Access Control List (ACL)

Resource Access is done by implementing a resource according to the Resource interface. The accessor methods of the resource interface implements the generic

150

methods that are common to all resources. The access of resources is through proxies that are delegated through the getProxy method that issues the proxy through the access control list issued to the agent for the resource. The resource implements the resource interface and to access the resource, the access protocol is used to gain access to a proxy as specified by the agent’s ACL. Figure 8.13 shows the interface that every resource must implement and Figure 8.14 shows the actual implementation of the resource specific functions. Figure 8.15 shows the delegation of a proxy to the resource that needs to be accessed by the mobile agent. Figure 8.13 and Figure 8.14 have been adapted from (Tate & Xu, 2003). The Resource access protocol class is an extension to (Tate & Xu, 2003).

public interface Resource { // generic methods

common to all resources

}

Figure 8.13: Resource Interface

public class ResourceImpl implements Resource { // implementations of the generic methods }

Figure 8.14 Resource implementation

public interface ResourceAccessProtocol { public Resource getProxy (ACL acl)

} Figure 8.15 Resource Proxy delegation

The agent transferer is like Figure 8.16. The new platform is located in the agent’s itinerary. If it is not found it throws an exception. To send an agent, it is encrypted; the agent’s necessary data kept in a briefcase and transferred to the located platform. 151

class AgentTransferer { Itinerary itinerary; Data data;

AgentTransferer(){ itinerary = new Itinerary(); data = null; } public void transferSequence(Agent agent) throws UnknownHostException { locateHost(itinerary.next()); Briefcase briefcase = createBriefcase(data); try{ go(encrypt(agent), briefcase); }catch (UnknownHostException){ //cater exception } } }

Figure 8.16: Agent Transferer Sequence

152

Chapter 9 Evaluation of the Proposed Framework

This chapter evaluates the proposed framework in Chapter 6 according to the threat model presented in Chapter 3. The threat model is applied according to the operation scenarios of the proposed framework from Chapter 7. The chapter then compares the framework with other frameworks and draws out the benefits and limitations of the framework.

9.1 Framework Evaluation Summarizing the results of applying the threat model on the operation scenarios, we come to know the security applications of the proposed framework and how. For the evaluation results we present 3 tables. Table 9.1 contains the threats from malicious mobile agents and threats from malicious platforms and it details whether these are protected and by which mechanism.

153

Table 9.1: Evaluation of the Proposed Framework Threats

Malicious Agents

Malicious Platforms

Masquerading

Yes. Agent IDs and authentication on platforms.

Yes. Authentication encryption of agents

and

DOS

Partially. Policies, padded cells and proxies.

Partially. Certificates certificate vectors.

and

Unauthorized Access

Yes. Padded cells, policies and proxies.

Yes. Encrypted agents and digital signatures.

Repudiation

Yes. Tracing.

Partially. Tracing and Hash lists.

Eavesdropping

Yes. Encryption of agents, padded cells, policies and proxies.

Yes. Secure channel for communication, encryption and proxies.

Alteration

Yes. Padded cells, policies and proxies.

Yes. Code Hashes, Hash Lists and Encryption.

Copy and Replay

Partially. Proxies.

Yes. Agent encryption.

IDs

and

agent

A malicious mobile agent can masquerade against a platform or even a launching host. For this, Agent IDs are present to distinguish agents uniquely. Also, the authentication process ensures that a masquerading agent does not enter the platform. Similarly, a platform may be masquerading as well. To protect from such a threat from the malicious platform, the agent can only be accessed if it is authenticated. Supposing an agent is permitted, the agent is encrypted and only the real platform with the proper private key can decrypt the agent. Denial-of-service attacks from a malicious agent are prevented partially. Policies are applied that can be helpful in aiding against pre-determined DOS attacks. Similarly, the padded cell can detect some forms of DOS attacks. Proxies can also prevent DOS attack by disabling certain methods based on the policy and the padded cell test results in the ACL. As for DOS attacks by the platform, the agents are protected partially through the certificates they carry for the services/ resources they require.

154

Unauthorized access by malicious agents is protected using padded cells as agents are tested for such access. Policies and proxies restrict the unauthorized access according to the agent authorization. Unauthorized access by the platform is protected by encrypting the agent code. Also, digital signatures prevent illegally copying data as well. Repudiation by an agent is detected by the domain database that tracks the agent and the platform’s entire interaction. Similarly, to protect such an attack by a platform, the trace can be recalled by the host from a repudiating platform. But this is only partial because if the platform is malicious, the extremity to change the trace for its own gain may cause further repudiation. Eavesdropping is protected by encrypting agents so that they cannot be spied out. The use of proxies provides independence to the interactions from malicious agents. Also to prevent an eavesdropper a padded cell and proxy closes out any means of spying. On the other hand to protect from a malicious platform, the agent is encrypted causing a secure channel for its transmission. Similarly for interacting with other agents, the agent uses its own sharing proxy to protect from eavesdropping. Alteration by a malicious agent is prevented by giving it no means to cause such a threat. This is by placing it in a padded cell then by applying a proxy that restricts such actions. To protect from a malicious platform causing alteration attacks, we encrypt our agents. Similarly to trace the alteration, we take code hashes that are transferred in the agents hash list. Any change to this will detect such an attack. Copy and reply by an agent is protected partially through proxies, meaning that we simply control the access of the agent. However, an agent may still gain enough information if read access is provided. Such gain can still be a surmountable threat by a malicious agent. To protect from a malicious platform, the agent is given an ID. A copy 155

of the agent is simply rejected and corrupt. Also, encryption provides a level of difficulty to copying of an agent.

9.2 Security Comparison with State-of-the-Art MAS The proposed framework is comparable to the MAS in the state-of-the-art in many ways. The framework implementation in Chapter 8 describes that it is in Java. However, the aim is to allow its implementation with out the restrictions of programming language used to build it. Thus, the comparison is solely based on the security aspect of the framework and the MAS in the state-of-the-art. Comparing with other MAS security frameworks in general, certain concepts are very similar to Ajanta (Karnik & Tripathi, 2000; Tripathi, Karnik, Vora, Ahmed & Singh, 1999; Tripathi, Karnik, Vora, Ahmed & Singh, 2000). The Ajanta framework comprises of a very strong mechanism for protecting against unauthorized access through proxy application. One difference here is that the proxy is applied on a previously built policy and there is no testing of commands like in our proposed framework in the padded cell component. Also, the Ajanta framework uses a checksum to prevent tampering of the agents. In comparison to other frameworks, the Telescript security framework (Baumer, Breugst, Choy & Magedanz, 1999; Gray, Kotz, Cybenko & Rus, 2000; Tardo & Valente, 1996) divides the entire MAS into regions and places. Between these, the agents exchange and migrate for processing. The authentication and authorization mechanism is strong and the agents are restricted according to restrictions set through the implementation. Our proposed framework does not base its protection on features of

156

underlying system support; it protects the MAS from threats based on techniques in its implemented components. The D’Agents security architecture (Gray, Cybenko, Kotz & Rus, 2001) uses resource managers for control of resource access by agents. This technique is more centralized than out policy engine and padded cell combination for access control. Also, the agent itself has control over its execution and can restrict its execution based on its surroundings. However, there is not much in D’Agents to protect agents in the MAS. Ara platform in comparison to our proposed framework uses an authentication based on agent credentials. The Ara (Peine & Stolpmann, 1997) platform uses allowances which act as policies on the platform. There is not much on protection of agents except that the agent is encapsulated. Tacoma security is very different from the security in our proposed framework (Johansen, Renesse, Schneider & 1995; Johansen, Marzullo & Lauvset, 1999; Johansen et al., 2001). Firstly, it uses electronic cash for control of resource access and for protection against threats that may be caused by access of an agent. Tacoma uses wrapper objects for agent and resource interaction. Wrappers are thus maintained for each type of agent that accesses a resource. Aglets (Karjoth, Lange & Oshima, 1997) uses a very different authentication mechanism from our proposed framework. The authentication issues policies from a policy database against the shared resources and services. This is like our policy engine but is not dynamic as the ACL does not exist for Aglets. For dynamism, there is a context manager surveying the access of resources. Agent protection in Concordia is centralized in an administration manager (Wong et al., 1997). The policies are set by a security manager dynamically according to a profile 157

against the agents. The access adjustment is similar to our approach but there is no means of detection, instead the access is redrawn for agents at run-time according to predetermined rules. The access in Grasshopper is like in our framework, it is based on a policy (Baumer, Breugst, Choy & Magedanz, 1999). The agent is given permission according to its owner information. Thus, the setting of access is all predetermined unlike in our framework. The authentication is very similar as it is based on digital signatures. Mole uses a sandbox to protect the platform from malicious agent access (Baumann, Hohl, Rothermel & Straber, 1998). Also it enforces policies based on services within a set place. These are predetermined. Agent access is time based so that it lets go after a defined time of accessing a resource.

9.3 Strengths and Weaknesses of the Proposed Security Framework As drawn from the discussion, we come to the strengths that the proposed security framework provides and the weaknesses that the framework has according to its security.

9.3.1 Strengths

The strengths of the proposed framework in terms of security are: 1) Prevents threats to mobile agents from a malicious platform and also prevents threats to the platform from mobile agents using simple components. The combination to form a framework to security is still a large area of mobile agent security research discussion.

158

2) The framework is technology friendly and does not restrict the implementation of components in language or technology restrictions.

3) The platform has a very strong mechanism to protect the MAS platform resources and services.

4) The MAS security framework is in itself integratable with other state-of-the-art systems as a security extension. It thus overcomes the shortcomings of the state-of-theart system.

5) The framework is also integratable with other mobile agent system requirements like fault-tolerance and discovery mechanisms.

6) The MAS framework potentially provides safety to the agents and the platform as well as security. Safety is provided in terms of preventing and detecting the malicious behaviors in the MAS.

7) Electronic cash based (money-based) techniques can be applied into the framework for resource consumption control.

9.3.2 Limitations

The limitations of the proposed framework in terms of security are: 1) Copy and replay attacks are not fully prevented in certain cases, like if a malicious agent copies a message and keeps repeating it. 159

2) DOS attacks are not prevented. This can be enhanced by adding a tracing subcomponent with the mobile agent, but this would also have redundant security limitations.

3) Dynamism of path in the form of the itinerary of the agent is not catered.

4) The MAS has to be trusted in the case of repudiation attacks response to be complete and unaltered for its own gain.

5) There is no way of detecting or preventing during transmission attacks as yet. Thus threats from a malicious network are explicit and not of the domain of this framework as yet. However, the encryption of agents forms a means of protection of mobile agent threats during transmission.

6) Large overheads to provide security are prevalent.

160

Chapter 10 Conclusions & Future Work

Mobile agent systems are hindered by the security that threatens their application. A MAS is threatened by the agents, the platform running the agent and the network that the system is communicating on. In this thesis a threat model is presented that highlights the various security threats in a MAS. A survey and evaluation of various approaches to protect a mobile agent system from malicious attack from agents themselves, the platform they execute on and the underlying transmission network. On the basis of the surveyed and evaluated techniques, a state-of-the-art of some existing mobile agent systems is evaluated. The state-of-the art discusses the security frameworks present in these mobile agent systems. Also, a framework that provides security a MAS is proposed. The framework addresses the issues of security of the platform against the malicious agents and also of the agent against malicious host platform. This is accomplished by the use of various approaches that are the components of the framework. For the framework various operation scenarios are listed that are in turn used to analyze the security provided by the framework according to the threat model. To cover the implementation issues of the framework, the implementation of the security components is discussed.

161

Possible research directions and future work in regard to the domain (Li, Zhang, Sun & Yin, 2004) of this thesis are immense. Starting from the requirements level, we can utilize the Gaia Methodology for building a multi-agent system. Then we can use the framework to design an MAS using AUML (FIPA, 2003). Similarly, the entire AOSE (Agent-oriented Software Engineering) can be extended to include security measures through this framework. Certain methods to ensure MAS security can be developed using this framework. Research work can be on the construction of a heterogeneous system. The platform in the framework can be extended to incorporate multiple kinds of platforms. In this aspect, an operating system for mobile agents can be devised such that security measures can be accommodated (Kotz, Gray & Rus, 2002). One area that has not been addressed and has been assumed to be secure is the network (Gray, 1997). This area can be explored for securing the network from threats while the agent is traveling and can be incorporated into this framework. Also, the work on the fault-tolerance of MAS can be incorporated as a part of this framework as well (Vogler, Kunkelmann & Moschgath, 1997). The framework does provide the ability for extension to accommodate other features. The implementation has been discussed for Java-based mobile agents. To incorporate mobile agents in other languages, the framework will suffice, but significant changes have to be made in the implementation discussed (Gray, Kotz, Cybenko & Rus, 2000). Work in this direction can be extended. Also, to enhance the subject of possible security threats, more mobile agent based applications and technologies need to be developed. Itinerary is a-priori, meaning that it is decided beforehand (Mir & Borrel, 2002; Mir & Borrel, 2003; Wilhelm, Staaman & Buttyan, 1998). For flexible or dynamic itineraries,

162

the security perspective will change because the mobile agent corruption will be hard to detect. Platform discovery mechanisms can be extended and incorporated into the framework proposed in this thesis (Marrow & Ghanea-Hercock, 2000). Similarly, work can be done in how to reduce costs associated with the security provision techniques. Money based (electronic cash based) techniques can be integrated for resource consumption control as a future extension as well (Gray, 1997). Also, for agent communication, various languages like KQML or ACL (Rothermel & Schwehm, 1998) can be incorporated and extended for security. They need to be made more secure for agents to communicate secret data during collaboration. These can be extended by the use of XML (Refsnes Data, 1999) as well for specifying secure mobile agent interaction protocols. A relevant domain can be to develop security features by specifying these using formal notations and semantics. Using these the security features in a MAS can be verified especially the interaction protocols between agents and resources. The uses of mobile agents are immense and their incorporation into the development of future systems is only hindered by security. This thesis serves as a basis for exploring the creation of security for such systems.

163

References

Abdalla, M., Cirne, W., Franklin, L. and Tabbara, A. (1997). Security Issues in Agent Based Computing, In the Proceedings of the 15th Brazilian Symposium on

Computer Networks, Sao Carlos, Brazil. Algesheimer, J., Cachin, C., Camenisch, J. and Karjoth, G. (2001). Cryptographic Security for Mobile Code, In the Proceedings of the 2001 IEEE Symposium on

Security and Privacy, p. 2 , Oakland, California, USA. Ametller, J., Robles, S. and Ortega-Ruiz, J. (2004). Self-Protected Mobile Agents, In the Proceedings of the 3rd International Conference on Autonomous Agents and Multiagent Systems (AAMAS), ACM Press, pp. 362-367, Madrid, Spain. Aneiba, A. and Rees, S. (2004). Mobile Agents Technology and Mobility, In the Proceedings of the 5th Annual Postgraduate Symposium on the Convergence of Telecommunications, Networks and Broadcasting (PgNet), Liverpool, UK. Baumann, J., Hohl, F., Rothermel, K. and Straber, M. (1998). Mole – Concepts of a Mobile Agent System, World Wide Web, Volume 1, Issue 3, pp. 123-137, Springer Netherlands, Stuttgart, Germany. Baumer, C., Breugst, M., Choy, S. and Magedanz, T. (1999). Grasshopper – A Universal Agent Platform Based on OMG MASIF and FIPA Standards, In the

Proceedings of the 1st International Workshop on Mobile Agents for Telecommunication Applications, World Scientific Publications, Ottawa, Canada.

164

Beirman, E. and Cloete, E. (2002). Classification of Malicious Host Threats in Mobile Agent Computing, In the Proceedings of the 2002 Annual Research Conference of

the South African Institute of Computer Scientists and Information Technologists on Enablement through Technology, South African Institute for Computer Scientists and Information Technologists (SAICSIT), pp. 141-148, Port Elizabeth, South Africa. Bellavista, P., Corradi, A., Federici, C., Montanari, R. and Tibaldi, D. (2003). Security for Mobile Agents: Issues and Challenges, Handbook of Mobile Computing, ISBN 0-84931-971-4, CRC Press. Berkovits, S., Guttman, J. and Swarup, V. (1998) Authentication for Mobile Agents, Mobile Agents and Security, Lecture Note in Computer Science, Volume 1419,

pp.114-136, Springer-Verlag, Berlin, Germany. Brooks, R. (2004). Mobile Code Paradigms and Security Issues, IEEE Internet Computing, Volume 8, pp. 54–59.

Chess, D. (1998). Security Issues in Mobile Code Systems, Mobile Agents and Security, Lecture Notes in Computer Science, Volume 1419, pp. 1-14, Springer-Verlag, Berlin, Germany. Condict, M., Milojicic, D., Reynolds and F., Bolinger, D. (1996). Towards a WorldWide Civilization of Objects, In the Proceedings of the 7th workshop on ACM

SIGOPS European workshop: Systems support for worldwide applications, pp. 2532, ACM Press, Connemara, Ireland. Cubaleska, B. and Schneider, M. (2002). A Method for Protecting Mobile Agents against Denial of Service Attacks, Cooperative Information Agents VI : 6th International

165

Workshop, CIA 2002, Lecture Notes in Computer Science, Volume 2446, p. 297, Springer-Verlag, Madrid, Spain. Dadon-Elichai, A. (2004). RDS: Remote Distributed Scheme for Protecting Mobile Agents, In the Proceedings of the 3rd International Conference on Autonomous

Agents and Multiagent Systems (AAMAS), pp. 354-361, ACM Press, New York, NY, USA. Dias, P., Ribeiro, C. and Ferreira, P. (2003). Enforcing History-Based Security Policies in Mobile Agent Systems, In the Proceedings of the 4th International Workshop on

Policies for Distributed Systems and Networks (POLICY), pp. 231-234, Lisboa, Portugal. Esparza, O., Soriano, M., Munoz, J. and Forne, J. (2004). Detecting and Providing Manipulation Attacks in Mobile Agent Systems, In the Proceedings of the 5th

International Workshop on Mobile Agents for Telecommunication Applications, Lecture Notes in Computer Science, Volume 3284, p. 224, Spring-Verlag, Berlin, Germany. Farmer, W., Guttman, J. and Swarup, V. (1996a). Security for Mobile Agents: Authentication and State Appraisal, In the Proceedings of the 4th European

Symposium on Research in Computer Security (ESORICS), Lecture Notes in Computer Science, Volume 1146, pp. 118-130, Springer-Verlag, Berlin, Germany. Farmer, W., Guttman, J. and Swarup, V. (1996b). Security for Mobile Agents: Issues and Requirements, In the Proceedings of the 19th National Information Systems

Security Conference, pp. 591-597, Baltimore, MD, USA. Feng, L., Shan, F. and Ying, W. (2003). An Enhanced Security Model for Mobile Agent System, In the Proceedings of Intelligent Data Engineering and Automated

166

Learning (IDEAL), Lecture Notes in Computer Science, Volume 2690, pp. 89-93, Springer-Verlag, Berlin, Germany. Ferreira, L. and Ricardo, D. (2002). Blinded Key Signatures: Securing Private Keys Embedded in Mobile Agents, In the Proceedings of the 2002 ACM Symposium on

Applied Computing (SAC), ACM Press, pp. 82-86, Madrid, Spain. FIPA (2003). The Agent Unified Modeling Language Web Site. Retrieved February 14, 2005, from http://www.auml.org/. Fischmeister, S., Vigna, G. and Kemmerer, R. (2001). Evaluating the Security of Three Java-Based Mobile Agent Systems, In the Proceedings of Mobile Agents: 5th

International Conference, Lecture Notes in Computer Science, Volume 2240, p. 31 Springer-Verlag, Atlanta, GA, USA. Franklin, S. and Graesser, A. (1996). Is it an Agent, or just a Program?: A Taxonomy for Autonomous Agents, In the Proceedings of the Workshop on Intelligent Agents III,

Agent Theories, Architectures, and Languages, Lecture Notes In Computer Science, Volume 1193, pp. 21-35, Springer-Verlag, London, UK. Fu, P. (1999). A Security Architecture for Mobile Agent Systems, Master of Science Thesis, Tsinghua University, China. Gray, R. (1996). Agent Tcl: A Flexible and Secure Mobile-Agent System, In the Proceedings of the USENIX Tcl/Tk Workshop, Monterey, CA, USA. Gray, R. (1997). Mobile-agent Security, Position Paper, In the Proceedings of the ECOOP Workshop on Distributed Object Security and 4th Workshop on Mobile Object Systems: Secure Internet Mobile Computations, pp. 79-80, Brussels, Belgium.

167

Gray, R., Kotz, D., Cybenko, G. and Rus, D. (1998). D’Agents: Security in a MultipleLanguage Mobile-Agent System, Mobile Agents and Security, Lecture Notes in Computer Science, Volume 1419, p. 154, Springer-Verlag, Berlin, Germany. Gray, R., Kotz, D., Cybenko, G. and Rus, D. (2000). Mobile Agents: Motivations and State-of-the-art Systems, University of Dartmouth, Technical Report, TR2000-365,

Dartmouth College, Hanover, NH, USA. Gray, R., Cybenko, G., Kotz, D., Peterson, R. and Rus, D. (2001). D’Agents: Applications and Performance of a Mobile-Agent System, Software—Practice & Experience archive [Special issue: Mobile agent systems], Volume 32, Issue 6, pp.

543-573, John Wiley & Sons, Inc., New York, NY, USA. Gray, R. (2004). Mobile Agents: Overcoming the Early Hype and a Bad Name, In the Proceedings of IEEE International Conference on Mobile Data Management (MDM), p. 302, Berkley, CA, USA. Greenberg, M., Byington, J. and Harper, D. (1998). Mobile Agents and Security, IEEE Communications Magazine, Volume 36, Issue 7, pp. 76-85.

Harrison, C., Chess, D. and Kershenbaum, A. (2001). Research Report - Mobile Agents: Are they a good idea?, In the Proceedings of the 2nd International Workshop on

Mobile Object Systems - Towards the Programmable Internet, pp.25-45, Linz, Austria. Hohl, F. (1998a). A Model of Attacks of Malicious Hosts Against Mobile Agents, In the Proceedings of Object Oriented Technology - ECOOP'98 Workshop Reader: ECOOP'98 Workshops, Demos, and Posters, Lecture Notes in Computer Science, p. 299, Springer-Verlag, Brussels, Belgium.

168

Hohl, F. (1998b). Time Limited Blackbox Security: Protecting Mobile Agents from Malicious Hosts, Mobile Agents and Security, Lecture Notes in Computer Science, Volume 1419, p.92, Springer-Verlag, Berlin, Germany. Hohl, F. (1999). A Framework to Protect Mobile Agents by Using Reference States, In the Proceedings of the 20th International Conference on Distributed Computing Systems ( ICDCS), p. 410, IEEE Computer Society, Washington, DC, USA. Jansen, W. (1998a). Countermeasures for Mobile Agent Security, Computer Communications, Special issue on advanced security techniques for network

protection, Volume 23, pp. 1667-1676, Elsevier Science. Jansen, W. (1998b). Mobile Agents and Security, MD: National Institute of Standards and Technology, Retrieved

April

8,

2005,

from

http://www.csrc.nist.gov/staff/jansen/pp-agentsecurityfin.pdf. Jansen, W. and Karygiannis, T. (1998), Mobile Agent Security, NIST Special Publication, National Institute of Standards and Technology, 800-19. Jansen, W. (2001). Determining Privileges of Mobile Agents, In the Proceedings of the 17th Annual Computer Security Applications Conference (ACSAC), p. 149, New Orleans, Louisiana, USA. Jihong, W., Jianping, H. and Kai, H. (2003). Security Design of Mobile Agent System, Proceedings of the 11th International Workshop on Database and Expert Systems Applications, p. 426, IEEE Computer Society, Washington, DC, USA. Johansen, D., Renesse, R. and Schneider, F. (1995). Operating System Support for Mobile Agents, In the Proceedings of the Fifth Workshop on Hot Topics in

Operating Systems (HotOS-V), p. 42, IEEE Computer Society, Washington, DC, USA. 169

Johansen, D., Marzullo, K. and Lauvset, K. (1999) An Approach towards an Agent Computing Environment, Proceedings. 19th IEEE International Conference on

Distributed Computing Systems Workshops on Electronic Commerce and Webbased Applications/Middleware, pp. 78-83, Austin, TX, USA. Johansen, D., Lauvset, J., Renesse, R., Schneider, F., Sudmann, N. and Jacobsen, K. (2001). A TACOMA Retrospective, Software—Practice & Experience [Special issue: Mobile agent systems], Volume 32 , Issue 6, pp. 605-619, John Wiley & Sons, Inc., New York, NY, USA. Johansen, D. (2004). Mobile Agents: Right Concept, Wrong approach, in the Proceedings of the 2004 IEEE International Conference on Mobile Data Management, pp. 300-301, IEEE Computer Society, Washington, DC, USA. Karjoth, G., Lange, D. and Oshima, M. (1997). A Security Model for Aglets, IEEE Internet Computing, Volume 1, Issue 4, pp. 68-77.

Karnik, N. (1998). Security in Mobile Agent Systems, PhD Dissertation, University of Minnesota,

USA.

Retrieved

November

17,

2005,

from

http://www.cs.umn.edu/Ajanta/. Karnik, N., Tripathi, A. (2000). Security in the Ajanta Mobile Agent System, SoftwarePractice & Experience, Volume 31, Issue 4, pp. 301-329, John Wiley & Sons, Inc.,

New York, NY, USA. Kotz, D. and Gray, R. (1999). Mobile Agents and the Future of the Internet, ACM SIGOPS Operating Systems Review, Volume 33 , Issue 3, pp. 7-13, ACM Press,

New York, NY, USA.

170

Kotz, D., Gray, R. and Rus, D. (2002). Future Directions for Mobile-Agents Research, University of Dartmouth, Dept. Computer Science, Technical Report, TR2002415, Dartmouth College, Hanover, NH, USA. Kun, Y., Xin, G. and Dayou, L. (1999). Security in Mobile Agent System: Problems and Approaches, ACM SIGOPS Operating Systems Review, Volume 34 , Issue 1, pp. 21-28, ACM Press, New York, NY, USA. Lange, D. (1998). Mobile Objects and Mobile Agents: The Future of Distributed Computing?, In the Proceedings of the 12th European Conference Object-Oriented

Programming (ECOOP), Lecture Notes in Computer Science, Volume 1445, p. 1, Springer-Verlag, Brussels, Belgium. Lange, D. and Oshima, M. (1999). Seven Good Reasons for Mobile Agents, Communications of the ACM, Volume 42, Issue 3, pp. 88-89, ACM Press, New

York, NY, USA. Lee, H., Alves-Foss, J. and Harrison, S. (2004). The Use of Encrypted Functions for Mobile Agent Security, In the Proceedings of the 37th Annual Hawaii International

Conference on System Sciences, pp. 297-306, Hawaii, USA. Leung, K. and Ng, K. (2004). Detection of Malicious Host Attacks by Tracing with Randomly Selected Hosts, In the Proceedings of the International Conference

Embedded and Ubiquitous Computing (EUC),

Lecture Notes in Computer

Science, Volume 3207, pp. 839-848, Springer-Verlag, Aizu-Wakamatsu City, Japan. Li, X., Zhang, A., Sun, J. and Yin, J. (2004). The Research of Mobile Agent Security, Second International Workshop on Grid and Cooperative Computing (GCC), Lecture Notes in Computer Science, Volume 3033, pp. 187-190, Shanghai, China. 171

Marques, P., Santos, N., Silva, L. and Silva, J. (2001). The Security Architecture of the M & M Mobile Agent Framework, In the Proceedings of the International ICSC

Symposium on Multi-Agents and Mobile Agents in Virtual Organizations and ECommerce (MAMA), ICSC Press, Wollongong, Australia. Marrow, P. and Ghanea-Hercock, R. (2000). Mobile Software Agents – Insect-Inspired Computing, BT Technology Journal, Volume 18, Number 4, pp. 129-139, Springer-Verlag, Netherlands. McDonald, J., Yasinyac, A. and Thompson III, W. (2005). A Survey of Mobile Agent Security, Technical Report, Florida State University, TR-050329, Tallahassee,

Florida, USA. Milojicic, D., LaForge, W. and Chauhan, D. (1998). Mobile Objects and Agents, In the Proceedings of the Second USENIX Conference on Object Oriented Technologies and Systems (COOTS), Toronto, Canada. Mir, J. and Borell, J. (2002). Protecting General Flexible Itineraries of Mobile Agents, In the Proceedings of the 4th International Conference on Information Security and Cryptology (ICISC), Lecture Notes in Computer Science, Volume 2288, p.382, Springer-Verlag, Seoul, Korea. Mir, J. and Borell, J. (2003). Protecting Mobile Agent Itineraries, Mobile Agents for Telecommunication Applications, Lecture Notes in Computer Science, pp. 275285, Volume 2881, Springer-Verlag, Berlin, Germany. Moore, J. (1998). Mobile Code Security Techniques, Technical Report MS-CIS-98-28, Department of Computer and Information Science, University of Pennsylvania, Philadelphia, Pennsylvania, USA.

172

Ng, S. (2000). Protecting Mobile Agents against Malicious Hosts, Mater of Science Thesis, The Chinese University, Hong Kong, China. Nicola, R., Nicola, G. and Pugliese, R. (1997). Coordinating Mobile Agents Access Rights via Blackboards and Access Rights, In the Proceedings of the Second

International Conference on Coordination Languages and Models, Lecture Notes in Computer Science, Volume 1282, pp. 220-237, Springer-Verlag, London, UK. Noordende, G., Brazier, F. and Tanenbaum, A. (2002). A Security Framework for a Mobile Agent System, In the Proceedings of the 2nd International Workshop on

Security in Mobile Multiagent Systems (SEMAS), associated with AAMAS 2002, DFKI Research Report RR-02-03, Deutsches Forschungszentrum fur Künstliche Intelligenz, pp. 43-50, Bologna, Italy. Novak, P., Rollo, M., Hodik, J. and Vlcek, T. (2003). Communication Security in Multiagent Systems, In the Proceedings of the Conference on 3rd International Central

and Eastern European Multi-Agent Systems and Applications III (CEEMAS), Lecture Notes in Computer Science, Volume 2691, p. 454, Springer-Verlag, Prague, Czech Republic. Orso, A., Harrold, M. and Vigna, G. (2000). MASSA: Mobile Agents Security through Static/Dynamic Analysis, In the Proceedings of the 1st ICSE Workshop on

Software Engineering and Mobility (WSEM), Toronto, Canada. Ousterhout, J., Levy, J. and Welch, B. (1996). The Safe-Tcl Security Model, Mobile Agents and Security, Lecture Notes in Computer Science, Volume 1419, p. 217,

Springer-Verlag, Berlin, Germany. Peine, H. and Stolpmann, T. (1997). The Architecture of the Ara Platform for Mobile Agents, In the Proceedings of the First International Workshop on Mobile Agents,

173

Lecture Notes In Computer Science, Vol. 1219, pp. 50-61, Springer-Verlag, London, UK. Peine, H. (1998). Security Concepts and Implementation in the Ara Mobile Agent System, In the Proceedings of the Seventh IEEE International Workshops on

Enabling Technologies: Infrastructure for Collaborative Enterprises (WET ICE), pp. 236-242, IEEE Computer Society, Stanford, CA, USA. Pham, V. and Karamouch, A. (1998). Mobile Software Agents: An Overview, IEEE Communications Magazine, Volume 36, Issue 7, pp. 26-37.

Picco, G. (2001). Mobile Agents: An Introduction, Microprocessors and Microsystems, 25(2), pp. 65-74. Refsnes Data (1999). W3Schools Online Web Tutorials. Retrieved June 5, 2005, from http://www.w3schools.com/. Roth, V. (1999). Mutual Protection of Co-operating Agents, Secure Internet Programming: Security Issues for Mobile and Distributed Objects Archive,

Lecture Notes in Computer Science, pp. 275-285, Springer-Verlag, London, UK. Roth, V. (2003). Secure Recording of Itineraries through Co-operating Agents, Workshop ion on Object-Oriented Technology, Lecture Notes in Computer Science, Volume 1543, pp. 297-298, Springer-Verlag, London, UK. Rothermel, K., Hohl, F. and Radouniklis, N. (1997). Mobile Agent Systems: What is Missing?, In the Proceedings of the International Working Conference on

Distributed Applications and Interoperable Systems (DAIS), pp. 111-124, Cottbus, Germany. Rothermel, K. and Schwehm, M. (1998). Mobile Agents, Encyclopedia for Computer Science and Technology, M. Dekker.

174

Rubin, A. and Geer, D. (1998). Mobile Code Security, IEEE Internet Computing, Volume 2, Issue 6, pp. 30-34. Saeb, M., Hamza, M. and Soliman, A. (2000). Protecting Mobile Agents against Malicious Host Attacks Using Threat Diagnostic AND/OR Tree, In the

Proceedings of the Smart Objects Conference 2003 (SOC), Grenoble, France. Sander, T. and Tschudin, C. (1997). Protecting Mobile Agents against Malicious Hosts, Mobile Agents and Security, Lecture Notes in Computer Science, Volume 1419, p.

44, Springer-Verlag, Berlin, Germany. Sander, T. and Tschudin, C. (1997). Towards Mobile Cryptography, Proceedings of the IEEE Symposium on Security and Privacy, pp. 215-224, Oakland, CA, USA. Schelderup, K. and Olnes, J. (1999). Mobile Agent Security – Issues and Directions, In the Proceedings of the 6th International Conference on Intelligence and Services in Networks: Paving the Way for an Open Service Market, Lecture Notes in Computer Science, Volume 1597, pp. 155-167, Springer-Verlag, London, UK. Schoder, D. and Eymann, T. (2000). The Real Challenges of Mobile Agents, Communications of the ACM, Volume 43 , Issue 6, pp. 111-112, ACM Press, New

York, NY, USA. Sudmann, N. (1998). Security in TACOMA, Position Paper, In the Proceedings of the Workshop on Object-Oriented Technology, Lecture Notes In Computer Science, Vol. 1543, pp. 302-303, Springer-Verlag, London, UK. Sun Microprocessors (1994). Sun’s Java Technology Page. Retrieved December 2, 2004, from http://java.sun.com/. Sundsted, T. (1998). An Introduction to Agents, Java World. Retrieved January 31, 2006, from http://www.javaworld.com/javaworld/jw-06-1998/jw-06-howto.html. 175

Tan, H. and Moreau, L. (2002). Certificates for Mobile Code Security, Proceedings of the 2002 ACM Symposium on Applied Computing (SAC), pp. 76-81, ACM Press, Madrid, Spain. Tardo, J. and Valente, L. (1996). Mobile Agents Security and Telescript, In the Proceedings of the 41st IEEE International Computer Conference (COMPCON), p. 58, IEEE Computer Society, Washington, DC, USA. Tate, S. and Xu, K. (2003). Mobile Agent Security Through Multi-Agent Cryptographic Protocols, In the Proceedings of the 4th International Conference on Internet

Computing (IC 2003), pp. 462-468, Las Vegas, Nevada, USA. Tripathi, A. and Karnik, N. (1998). Protected Resource Access for Mobile Agent-based Distributed Computing, In the Proceedings of the 1998 International Conference

on Parallel Processing Workshops (ICPPW), p. 144, IEEE Computer Society, Washington, DC, USA. Tripathi, A., Karnik, N., Vora, M., Ahmed, T. and Singh, R. (1999). Mobile Agent Programming in Ajanta, In the Proceedings of the 19th IEEE International

Conference on Distributed Computing Systems, pp. 190-197, Austin, TX, USA. Tripathi, A., Karnik, N., Vora, M., Ahmed, T. and Singh, R. (2000). Ajanta – A Mobile Agent Programming System, Technical Report, University of Minnesota, TR98-

016, Department of Computer Science, Minneapolis, MN, USA. Tschudin, C. (1999). Mobile Agent Security, Intelligent Information Agents: AgentBased Information Discovery and Management on the Internet, Chapter 18, pp.

431-445, Springer-Verlag, Berlin, Germany.

176

Varadharajan, V. (2000). Security Enhanced Mobile Agents, Proceedings of the 7th ACM conference on Computer and Communications Security, pp. 200-209, ACM Press, Athens, Greece. Vigna, G. (1997). Protecting Mobile Agents through Tracing, Proceedings of the 3rd ECOOP Workshop on Mobile Object Systems, Jyvälskylä, Finland. Vigna, G. (1998). Cryptographic Traces for Mobile Agents, Mobile Agents and Security, Lecture Notes in Computer Science, Volume 1419, p. 137, SpringerVerlag, Berlin, Germany. Vigna, G. (2004). Mobile Agents: Ten Reasons for Failure, In the Proceedings of the 2004 IEEE International Conference on Mobile Data Management, pp. 298-299, IEEE Computer Society, Washington, DC, USA. Villazon, A. and Binder, W. (2001). Portable Resource Reification on Java-Based Mobile Agent Systems, In the Proceedings of the 5th International Conference,

Lecture Notes in Computer Science, Volume 2240, p. 213, Atlanta, GA, USA. Vogler, H., Kunkelmann, T. and Moschgath, M. (1997). An Approach for Mobile Agent Security and Fault Tolerance using Distributed Transactions, In the Proceedings

of the 1997 International Conference on Parallel and Distributed Systems (ICPADS), p. 268-274, IEEE Computer Society, Washington, DC, USA. Vuong, S. and Fu, P. (2001). A Security Architecture and Design for Mobile Intelligent Agent Systems, ACM SIGAPP Applied Computing Review, Volume 9, Issue 3, pp. 21-30, ACM Press, New York, NY, USA. White, J. (1996). Mobile Agents White Paper, General Magic. Retrieved March 17, 2004, from http://www.genmagic.com/agents/Whitepaper/whitepaper.html.

177

Wilhelm, U., Staaman, S. and Buttyan, L. (1998). Protecting the Itinerary of Mobile Agents, In the Proceedings of the Workshop on Object-Oriented Technology,

Lecture Notes in Computer Science, Volume 1543, pp. 301, Springer-Verlag, London, UK. Wong, D., Paciorek, N., Walsh, T., DiCelie, J., Young, M. and Peet, B. (1997). Concordia: An Infrastructure for Collaborating Mobile Agents, In the Proceedings

of the First International Workshop on Mobile Agents, Lecture Notes in Computer Science, Volume 1219, pp. 86-97, Springer-Verlag, London, UK. Yee, B. (1997). A Sanctuary for Mobile Agents, Secure Internet Programming: Security Issues for Mobile and Distributed Objects, Lecture Notes in Computer Science, pp.

261-273, Springer-Verlag, London, UK. Young, A. and Yung, M. (1997). Sliding Encryption: A Cryptographic Tool for Mobile Agents, In the Proceedings of Fast Software Encryption: the 4th International

Workshop (FSE), Lecture Notes in Computer Science, Volume 1267, p. 230, Haifa, Israel.

178