Security mechanisms for the MAP agent system - Semantic Scholar

Security mechanisms for the MAP agent system Antonio Puliafito Dipartimento di Matematica Universit`a di Messina Salita Sperone, 98166 Messina - Italy E-mail: [email protected]

Orazio Tomarchio Istituto di Informatica e Telecomunicazioni Universit`a di Catania Viale A. Doria 6, 95125 Catania - Italy E-mail: [email protected]

Abstract

agent [13, 7, 4]; we can consider an agent as an active object that can independently move in the network for completing its task, by interacting (if necessary) with other agents in the system. This programming model leads to an increased flexibility in the design and creation of several distributed applications. Network management [3, 5, 18], distributed information retrieval, distributed computing [1, 4], are typical fields for agent-based applications [9]. The use of this model implies the creation of an infrastructure for supporting the execution of agents. This is possible in a local organization with almost no problem, but in a global scenario we need to assure that a generic computer can accept the execution of an agent coming from outside. In order to make such operations acceptable, we need to avoid that the execution of an agent coming from outside damages the local machine, and to assure the possibility of identifying the person who triggered and/or produced the agent. We therefore need to develop an adequate security model adapted to the specific issues of the agents; this model will have to assure an high level of protection to the agents and the hosts, so that the hosts can be protected from the attacks of unsafe agents, and the agents can run on the hosts of the network without being damaged [12, 6, 20]. The wide interest that agent technology is receiving, has produced the development of some software environment which allow agent programming, execution and mobility [15, 2, 16, 22, 19]. Although security issues are considered as a crucial goal which, if not addressed, can strongly delay or even stop the adoption of the agent programming paradigm, very limited effort has been devoted to such issues. In this paper we present the security model for the MAP 1 agent platform [19], which has been developed at the University of Catania. This model is based on the encryption and authentication mechanisms present in Java 2 [10]. The rest of this paper is organized as follows. In Sec-

Mobile agents represent a new communication paradigm which has recently obtained a great attention from researcher and practitioners. Interesting applications exist in the fields of distributed systems management, mobility and information retrieval. But, although widely recognized as a crucial point to be addressed, security has not been pursued in a satisfactory way yet. Most of all the existing software environment for agent programming do not offer security features or provide only partial implementations. In this paper we propose a security schema for mobile agent and describe its implementation inside the MAP platform. Some experimental results are also provide to evaluate the overhead introduced from the adoption of the proposed security mechanism. Keywords: mobile agents, security, Java, distributed computing.

1 Introduction The possibility to access many resources from a computer connected to a communication network has lead to new users’ needs and to the development of new advanced services. On one hand, the large supply of information and, on the other hand, the rising number of users are continually causing problems of traffic congestion. The constant improvement in infrastructures should be followed by new techniques for programming distributed systems; such techniques should optimize the exploitation of the available bandwidth. The client-server approach, which has been usually used as the communication paradigm for distributed systems, has been recently extended by techniques based on the use of mobile code [8, 17, 11, 13]. In particular, we think that the mobile agent model can overcome some limits of the client-server one, since each agent can dynamically play the role of either client or server. There is some disagreement in literature about the way of defining a mobile

1 MAP is available at the following site: http://sun195.iit.unict.it/MAP

1

tion 2 we present the specific security issues for the agent systems. In Section 3 we briefly describe the architecture of the MAP platform, while in section 4 we present the architecture of the security model implemented and provide some experimental results. Finally, in Section 5 we conclude, making some remarks about our work, and about any future work.

2 Agents security The mobile agent systems have several features that make them suitable for the creation of applications in a distributed field. However, such systems cause new security issues that have to be adequately dealt with, in order to benefit from the features described, and to develop some applications that can be used on a large scale [20]. Even if strong security models have been studied and developed for the traditional distributed systems [21], agents cause new issues in this scenario. In traditional client-server systems, the active entities run under the control of the operating system of the machine in which they are running; the user who triggers an application is appropriately identified before accessing his/her account, and is consequently assigned some authorizations. At this point the operating system assures the protection of the critical resources of the system. The agent paradigm changes the terms of the security issue; a host may not ”recognize” the user on behalf of whom an agent is running, or may not rely on what the agent might do when running locally. The main issue is that the state of the agent, while crossing several more or less trusted hosts, may be modified in such a way that it changes its behaviour, and causes negative effects. Several security purposes are desirable for an agent system. Most of these issues concern the interaction between the agent and the host on which it runs. The user on behalf of whom the agent runs wishes to be protected from malicious interpreters and from the intermediate hosts involved in the migration of its agent. Conversely, an interpreter and the host in which it runs need to be protected from the agents whose behaviour is wrong. Since in several applications (where agents are used) different organizations provide services to many users, many of the parts involved do not trust on each other. A server might be interested in changing the state of an agent in order to benefit from this situation. Conversely, a malicious agent might have been created in order to search for some information that it is not allowed to obtain, thus taking illegal advantages from it. In a few words, the specific points for an agent system are the following [14, 20]:

 protection of a host from the agents that reach it and run on it;

 protection of an agent from other agents;  protection of an agent from the host where it runs;  protection of an agent from the outside environment (for example, against the network attacks during the migration); None of the existing agent systems can provide a security model that could deal with and solve any issue. Some of the requirements for developing a general security model are not practicable, according to what has been said in [6]. For example, the issues listed below do not seem to be completely practicable:

 verifying that an interpreter has not been changed;  verifying that an interpreter runs an agent correctly;  verifying that an interpreter runs an agent until its completion;  verifying that a host sends an agent as required;  keeping the data and the code of an agent private;  communicating with a wide group of agent servers privately;  distinguishing an agent from a clone. Conversely, what seems to be practicable is the protection of a host from the actions of an agent, thanks to the use of authentication techniques and access control mechanisms. In this area, the issue is finding a responsibility for the agent’s actions. We therefore need to make a distinction between the author of the agent’s code and the user who uses it by triggering its execution. Besides (in order to avoid causing other problems in the host accepting an agent), we need to make sure that during the agent’s migration there has been no attack on the communication channel, which in general has to be considered unsafe. Similar techniques need to be used for protecting an agent from other agents. In general, an agent has to obtain specific authorizations in order to interact with other agents of the system.

3 MAP architecture The MAP platform [19] allows the development of mobile agents applications by providing all the basic primitives needed for their creation, execution, communication, migration, etc. It has been entirely developed in Java, and this guarantees its portability on different hardware and software architectures. The migration implemented in MAP is a weak migration: the agents are able to carry the data-state

of data with them, but not the execution-state. Besides, it integrates the paradigms of remote execution and code on demand [8], thanks to the exploitation of dynamic loading of classes, a mechanism present in Java. A graphic interface manages the agents in execution. This interface (shown in Figure 1) allows to verify which agents are active in the local server, and which ones are present in remote servers. Besides, through this interface we can trigger the execution of any agent present in the system, independently of its code location.

Figure 1. MAP graphical interface The architecture of a generic MAP server is shown in Figure 2: it consists of an object called Server that contains all the entities needed for the operation of the platform itself. In a host there can be more than one Server, each identified by the host address and by the TCP port number on which the server is listening for accepting agents or messages coming from the network. The presence of a Server on a node characterizes it as belonging to the platform and enables it to accept and run agents coming from the network, as well as to activate other agents locally. Agents Server

Context

Network ClassLoader

Serialized Object

CodeServer

Agent

Instancer

Message

Instancer

Agent

stream arrives from the network, the Daemon creates a specific entity called Instancer, whose task is to instance the serialized object, both if it is an agent and a message. In both cases, the object, once it is instanced, is passed to the Context, whose task will be to make it run (if it is an agent), or to send it to the receiver agent (if it is a message). The Context is one of the basic objects in a MAP server. In fact, it knows all the agents present on the server and gives the user all the functionalities needed for their management. It puts some methods at disposal, which enable to create an agent, to make it run, even on a server in which its code is not present, to suspend it, to deactivate it, to resume its execution, and even to kill it, if necessary. Each object coming from the network in serialized form, is passed to the Context, after having been instanced by the Instancer. If such object is an agent, the Context initializes it, by giving it a reference to the Context, and later, starts its execution, and consequently updates the list of local agents. Conversely, if the object is a message, the Context makes sure to deliver it to the receiver agent, of course after checking the agent’s availability to receive such message, or of its actual presence on the server. The NetworkClassLoader and the CodeServer are used to retrieve remote classes, enabling the agents to run on a specific MAP server, even when their class is not present there. In order to permit this, each time a specific object reaches a new server, the corresponding Daemon loads a new Instancer object with a NetworkClassLoader that deals with the loading of such classes. If one of the classes to which the agent or the message refers is not actually present locally, the NetworkClassLoader will search for it in the network, in a list of MAP servers fixed within the Context. Once the class is found, it is loaded from the remote site and saved in a cache memory managed by the Context, so that it can be accessed and used, if necessary, also by of the other agents of the server.

3.1 Agents' Structure As we have already said before, agents represent the entities of the platform MAP that can move in the network for carrying out a task assigned by the user who created them. Within our platform, an agent is able to:

Daemon Agent

Figure 2. MAP server architecture The Daemon is the entity of the MAP that listens on a certain port, waiting for agents coming from other nodes and for messages to be delivered to local agents. Both messages and agents travel in a serialized form. Each time a

 suspend itself and another agent: to suspend an agent means to stop its execution temporarily, by keeping all the references to the agent active;  resume a suspended agent: to wake up an agent means to resume its execution from the point where it had been suspended before;  deactivate itself and deactivate another agent: to deactivate an agent means to stop its execution, by down-

loading the agent to a disk in a serialized form, and by deleting all the references to it;

Domain

 reactivate an agent: it means to deserialize an agent that had been deactivated before, by giving all references back to it and restarting its execution from the beginning;

MAP Domain Server Generic host (with MAP server)

 create a new agent: to create an agent means to instance a new Agent object and to make it run;  kill an agent: it means to stop the execution of an agent, by deleting all its references and cancelling its entry from the list of the agents in the server;  migrate to a new server: to migrate an agent means to move it to another node, where it will start its execution from the beginning;  communicate with other agent, through messages, both in a synchronous and in an asynchronous way. From an implementation point of view, an agent is an object obtained by instancing a class deriving from the Agent class supplied by the platform. This enables the agent to take advantage from the methods put at our disposal by such class.

4 Security model in MAP

4.1 General architecture The security model developed for MAP considers the issues of authentication and authorization, in order to protecton one hand- the hosts from the agents, and- on the other hand- the agents from the other agents and from the attacks coming from the network. Some rules, which are called security policies, are defined. With these rules we specify the conditions according to which the agents can access host resources; we also specify the authentication needed for the entities for performing some operations, and the level of security in the communication among the agents on different hosts. The techniques used are based on public key encryption, in which each user has a pair of public and private keys, with which he/she can prove his/her identity. For the purposes of the security model developed, the whole set of hosts in which a MAP server runs is divided into domains (see Figure 3). As we will see below, several policies are adopted for agents belonging to the same domain or to different domains. Several hosts in a domain may therefore be grouped either physically (the hosts belonging to a specific subnet) or logically (hosts of the same organization, hosts belonging to a specific working group, etc). In each domain a trusted

Figure 3. Domains and hosts in the MAP environment

host (MapDS - Map Domain Server) is located where a domain administrator operates. Its task is the definition of a security policy for the domain, concerning the accesses and the migrations of agents to and from other domains. The same way, a host administrator can be identified for each host, which takes care of defining a security policy for the host. The system developed forces the agents to follow the security policy of the host and of the domain where they run. In fact, when the agent reaches a host, it is confined in a so-called protection domain where it can operate within fixed limits. For doing so, we need to find the origin of the agent, so to determine the set of authorizations to be given for the local execution of the agent. In fact, an agent is allowed to access the critical resources of a host only if the Access Control List (ACL) contains the appropriate authorizations. Two entities are involved in the authentication of an agent: the author of the agent (the person who has written the code, and/or the company that has put it on the market) and the user who has started the execution of the agent. In fact, in our opinion, both entities have to be involved for assigning specific authorizations to the agent. For example, if a reliable user uses an agent whose code has been created by an unknown person or even by an unreliable one, the set of authorizations to be assigned to the agent should be restricted. The information concerning the author of the agent is kept in the so-called credentials of the author. They contain:

 the ID of the author of the code  the public key certificate of the author  the digital signature of the code Conversely, the information concerning each user of the system is kept in the so-called credentials of the agent,

which are associated to each agent triggered by the user. Such credentials are created each time the user triggers a new agent, and contain:

 the user’s ID  the digital signature of the agent  the credentials of the author of the code The credentials of the agent are inserted in it, and follow it during its migrations. In section 4.2 we will show how the information contained in the credentials is used for confining an agent in a specific protection domain. As we said before, two security policies are defined concerning the single host and the domain. For the agents coming from nodes within the domain, the system authenticates the user that has triggered the agent: the authorizations to be associated to each agent are therefore associated to the single users. Conversely, when an agent comes from a different domain, the authorizations are associated to the domain: there is no longer the visibility of the single user. This choice has been made considering that, if the agent model is extended to a large number of users, the ACL present in each host might excessively grow, thus making the performances of the system slower. Therefore, when an agent has to be sent out of its domain, it will transit on the MapDS, where the domain administrator will take care of sending it.

4.2 Implementation details The model described has been implemented by using the security features present in Java 2 [10]. In the latest version, considerable changes and improvements have been made to the Java security model, which was incomplete in some of its functionalities. In fact, in version 1.1 digital signature mechanisms had been introduced, but their only task was that of considering whether a class was trusted or not: a signed remote class could be considered equivalent to a local code, or confined in the sandbox (where it cannot access the local resources). Conversely, the model of Java 2 allows to provide some mechanisms of fine grain access control, which allow specifying the actions that a remote class can do within the local environment. This mechanism of access control can be extended, thus enabling the protection of new resources that have been dynamically added to the system. In this context, the term resource takes the widest meaning, since it can represent a file, a network connection, the access to the graphical system, or a logical resource. Another improvement is the possibility of an easy definition of the customized security policies. The model of protection adopted in our agent system makes use of ”capability list”: each protection domain (where the agents are confined when they reach each host)

is associated with a list containing all the access rights (authorizations) that will be acquired by the agents. Each authorization consists of two parts: the resource for which the authorization specifies the access (for example a file), and the type of access that is allowed on that resource (for example, writing). Below we will describe the actions performed by the system for sending and receiving an agent. When a server is activated, the host gets to know the domain to which it belongs, the other hosts belonging to the same domain, and the MapDS of its domain. Activating and sending an agent The system follows these steps for sending an agent:

 Loading the class The class of the agent is first searched in the local ”cache”, and then (if not found) in the local file system. The class may be present in the cache, if the agent has already been executed, or received from another node. Both the bytecode of the class and the credentials of the author associated to it are stored in the local cache.  Verification of the class integrity Once the class has been loaded, its integrity has to be verified. If it is loaded from the cache, the credentials of the author present in it will be used for the verification. The integrity of the class may not be verified if someone (through an attack) managed to change either the credentials or the bytecode of the class within the cache: in this case we try to reload the class and the credential of the author from the file system, and will repeat the verification process. If the integrity is verified the subsequent step is started, otherwise a security warning will be notified to the user.  Determination and confining in the protection domain In this phase, we determine the protection domain associated to the user who is preparing to trigger the agent. The class is therefore confined in this domain, since the user might decide to run the agent locally.  Generation of the agent’s credentials The user signs the agent with his/her own private key, thus generating the agent’s credentials. If the agent has to be sent to a host belonging to the same domain, then the system serializes the state of the agent, signs it (by using the user’s key), and then sends it through the network. Receiving an agent When receiving an agent that has to be executed, the system makes the following steps:

 Verification of the agent’s state Once an agent has been received, a verification must be done of the integrity of the state. The key of the latest user who has put his/her signature on the state of the agent is loaded and used for this verification. If no problem is found, we can go to the subsequent step; otherwise, the agent is not executed, and the user who sent the agent is notified about this situation.  Verification of the integrity of the agent’s class In order to verify the integrity of the class that implements the agent, the credentials of the user who triggered it are used. If this verification is not successful, we need to determine if this is due to a change in the agent’s attributes or of the bytecode of the class (wherever it has been found). At this point, several cases are possible, according to where the credentials of the author are, and where the class is (in the cache, in the local file system, or in other remote hosts). If after such verifications we cannot verify the agent’s integrity, the user who sent the agent is notified about this situation.  Confinement in the protection domain Once we have verified the integrity of the class and, at the same time, the identity of the user who sent the agent, it is confined in a protection domain, and obtains the corresponding authorizations. Sending and receiving an agent out of its domain If an agent has to be sent to a host outside its domain, it first reaches its MapDS. The administrator verifies that the user is enabled to send agents to other domains, and then verifies the integrity of the agent’s class. If such verifications are successful, the domain administrator redefines the credentials by putting his/her signature. In fact, the host that will receive the agent will autenthicate only the domain, and the agent will then be confined to the appropriate protection domain accordingly.

4.3 Performance In order to evaluate the overhead caused by the security mechanisms introduced in MAP, we have carried out some tests. The purpose was to evaluate the behaviour in the different operating situations in which the system can be. Three different cases have been considered: 1. migration from a host to another one located in the same domain 2. migration among three hosts in the same domain 3. migration from a host to another one located in a different domain

These tests have been carried out in machines with AMD K6 at 300 MHz processors and equipped with Windows 98, connected to a 10-Mbit Ethernet. Below we show the migration times obtained in each of the tests, both activating and deactivating the security mechanisms. The signature algorithm used is the DSA/SHA-1 present in the standard distribution of Java 2. The length of the key is 1024 bit and the size of the agent used for tests is 1 Kbyte. The results for the first set of experiments are shown in Table 1. An agent is triggered by a host and migrates to another one, belonging to the same domain. These are the operations made by the host A: verifying the integrity of the class, generating the credentials, signing the state of the agent, and then sending it. Conversely, the host B verifies the integrity of the state, verifies the credentials, and then the agent is instanced. Each row of the tables represents a different situation in which the hosts can be. The agent’s class could be already in the cache or should be loaded from the local file system or retrieved from the network. The first test is the worst of the cases: the host A has to load the class from the local file system, while B has to retrieve it through the network. The second test is an intermediate situation, since in both hosts the code of the agent is already present in the local file system. The third test is the best of the cases, and occurs when both hosts have the class of the agent in their cache, since they have previously executed a different instance of the agent. As can be observed the overhead introduced from the adoption of security mechanisms is in the range 1-1.5 seconds. In percentage, this will be less evident when the size of the agent will be higher than the hypotized value of 1KB. In the second set of experiments we have tested the migration in the same domain between three hosts. In this case, the hosts make the following operations: host A generates the credentials of the agent, then signs the state and sends it to B. The host B verifies the integrity of the state and of the credentials, and executes the agent, whose only task is migrating to the host C. Before being sent to C, its state is signed by B. Finally, C verifies the integrity of the state and of credentials, and executes the agent. The tests carried out in this case (see Table 2) show the results according to the variation of the presence (in the cache or in the file system) of the class that implements the agent. As can be observed, the total migration times are slightly shorter than the double of the previous case, since the host B does not have to generate the credentials, but only needs to sign the state of the agent again (of course, after doing all the verifications). In the third set of tests (see Table 3) we have tested the communication between two hosts (A and C) belonging to different domains. This implies (for what is provided by the security model) the transit through the host manager for the domain (B). We therefore have the additional cost of a migration and of a generation of credentials on the host B. The

Agent class location Host A Host B File system Network File system File system Cache Cache

Time (ms) With security Without security 1980 660 1380 330 1040 160

Table 1. Migration overhead between two host belonging to the same domain Agent class location Host A Host B Host C File system Network Network File system File system File system Cache Cache Cache

Time (ms) With security Without security 3880 1100 2140 500 1740 300

Table 2. Migration overhead between three host belonging to the same domain resulting times are therefore slightly higher than the ones corresponding to the previous case. Conversely, in case the security mechanisms are not enabled, the times result shorter, since the agent is not executed in the host B, but is sent to C as soon as it is received.

5 Conclusions Mobile agents represent a very promising paradigm with challenging applications in system management, user mobility, services provisioning. As a consequence of code mobility, security is an essential requisite. In this paper we have discussed about security and agents, and we have proposed a security infrastructure for mobile agent systems. Implementation issues have been presented and experimental results obtained from the MAP agent platform have been provided. Acknowledgments: this work has been carried out under the financial support of the Italian Ministero dell’Universit´a e della Ricerca Scientifica e Tecnologica (MURST) in the framework of the MOSAICO (Design Methodologies and Tools of High Performance Systems for Distributed Applications) Project.

References [1] L. Bic, M. Fukuda, and M. Dillencourt. Distributed Computing Using Autonomous Objects. IEEE Computer, 29(8):55– 61, Aug. 1996. [2] M. Breugst, I. Busse, S. Covaci, and T. Magedanz. Grasshopper - A Mobile Agent Platform for IN Based Service Environments. In IEEE IN Workshop 1998, Bordeaux, France, May 1998.

[3] M. Breugst and T. Magedanz. Mobile Agents - Enabling Technology for Active Intelligent Network Implementation. IEEE Network, 12(3):53–60, May/June 1998. [4] D. Chess, C. Harrison, and A. Kershenbaum. Mobile Agents: Are they a Good Idea? Technical Report RC19887, IBM T.J. Watson Research Center, Mar. 1995. [5] H. de Meer, A. Puliafito, J. Richter, and O. Tomarchio. Tunnel Agents for Enhanced Internet QoS. IEEE Concurrency, 6(2):30–39, April-June 1998. [6] W. Farmer, J. Guttman, and V. Swarup. Security for Mobile Agents: Issues and Requirements. In Proc. of the 19th National Information Systems Security Conf. (NISSC96), 1996. [7] S. Franklin and A. Graesser. Is it an Agent or Just a program? A Taxonomy for Autonomous agents. Intelligent Agents III: Agent Theories, Architectures and Languages, 1997. [8] A. Fuggetta, G. Picco, and G. Vigna. Understanding Code Mobility. IEEE Transaction on Software Engineering, 24, 1998. [9] M. Genesereth and S. Ketchpel. Software Agents. Communications of the ACM, 37(7):48–53, July 1994. [10] L. Gong. Java Security: Present and Near Future. IEEE Micro, 17(3):14–19, May 1997. [11] R. Gray, D. Kotz, S. Nog, D. Rus, and G. Cybenko. Mobile agents: the next generation in distributed computing. In Proc. of the Second Aizu Int. Symp. on Parallel Algorithms/Architecture Synthesis (pAs97), Fukushima, Japan, Mar. 1997. [12] M. Greenberg, J. Byington, and T. Holding. Mobile Agents and Security. IEEE Communications Magazine, pages 76– 85, July 1998. [13] K. Rothermel and R.Popescu-Zeletin Eds.,. Mobile Agents. Lecture Notes in Comp. Science, LNCS1219, 1997. [14] G. Karjoth, D. Lange, and M. Oshima. A Security Model for Aglets. IEEE Internet Computing, 4(1):68–77, July-August 1997. [15] J. Kiniry and D. Simmermann. A hands-on look at Java Mobile Agents. IEEE Internet Computing, 1(4):49–52, July 1997.

Agent class location Host A Host B Host C File system Network Network File system File system File system Cache Cache Cache

Time (ms) With security Without security 5440 880 3936 490 2530 270

Table 3. Migration overhead between two host belonging to different domains [16] D. Lange and M. Oshima. Programming Mobile Agents in Java with the Java Aglet API. Technical report, IBM Tokyo Research Division, 1997. [17] V. A. Phan and A. Karmouch. Mobile Software Agents: An Overview. IEEE Communication Magazine, 31(7):26–37, July 1998. [18] A. Puliafito and O. Tomarchio. Using Mobile Agents to implement flexible Management strategies. Computer Communication Journal. to be published. [19] A. Puliafito, O. Tomarchio, and L. Vita. MAP: Design and Implementation of a Mobile Agent Platform. Journal of System Architecture, 46(2):145–162, 2000. [20] K. Schelderup and J. Olnes. Mobile Agent Security: Issues and Directions. In IS&N’99, volume LNCS1597, Mar. 1999. [21] W. Stalling. Network and Internetwork Security Principles and Practice. Prentice Hall, 1995. [22] M. Strasser, J. Baumann, and F. Hohl. MOLE - A Java Based Mobile Agent System. In Proceedings of the 2nd ECOOP Workshop on Mobile Object Systems, July 1996.