DSDAGENTS – A JAVA FRAMEWORK FOR DEVELOPING MOBILE AGENT SYSTEMS Diana Szentivanyi, Sorin Serau, Dan Cosma, Ioan Jurca fsd748, shally, danc,
[email protected] Department of Computer Science Faculty of Automation and Computer Science Politehnica University of Timisoara Romania
Abstract This paper describes a Java framework, which can be used to create and use mobile agent based systems, developed at Politehnica University of Timisoara. It consists, mainly, in servers that execute agents, and a set of Java classes providing the functionality for developing the agents’ code. All basic tasks are done by the framework, so that the programmer doesn’t have to be concerned about details regarding the communication, agent migration or security. 1. Introduction The idea of dispatching a program for execution from a local computer on a remote one is quite old. This led to the development of agents and of systems for their execution. Agents are, in fact, sequences of executable code, which do something. At the beginning, this code was used only to compensate certain lacks (i.e. lack of memory, lack of disk space, etc.) and not to do anything else. Once the Internet began growing, it was desirable to create agents capable of searching information and of making decisions based on this information. Also, a way of communication between agents was desired allowing agents to exchange knowledge. Agents of this type are called Itinerant Agents. Itinerant agents are programs which are dispatched from a source computer and which roam among a set of networked servers until they are able to accomplish their task. An important issue regarding itinerant agents is the Agent Meeting Point (AMP) an abstraction that supports the interaction of agents with each other and server based resources. This is an extension to the client-server model in which the client sends a portion of itself to the server for execution. An important feature of itinerant agents is their ability to migrate from server to server. We have developed an framework that can be used to create agent based systems that provide the following :
Itinerant agents.
Agent Meeting Places. Security services. User Interface Agents. 1.1. Related work There already exist some Java based agent systems. Such a system is Mole [1], made by a group of researchers from Stuttgart University. Another Java based agent system is Aglets [2], designed by IBM Japan. 2. The Agent Server This section will describe the way a server for Itinerant Agents was implemented. The agent server implements the whole AMP. It is responsible for receiving, management, execution and dispatch of agents. The agent server uses the client-server protocol for intercommunication. It is a concurrent server, which means it can accept multiple requests of connection at one time; once a connection is established with a client, the server will create a thread, which will handle the rest of communication. The protocol used for communication between server and client is TCP (direct connection). After receiving an agent, from client, the communication thread will create another thread, which will authenticate the agent, and it will continue the communication with the client. The authentication thread will verify and authenticate the agent and, if valid, the agent will begin its execution. A few important issues of an agent system are:
Agent dispatch. The agent is dispatched from server either after its creation (initial dispatch of agent) or upon an agent migration request. The agents components (its code, data and additional info) are stored in a transportable form and added to a package. This package requires encryption for security purposes. The agent is dispatched through a Communication Portal by the client-end of the communication between the two agent servers. Agent arrival. The agent arrives through a Communication Portal. At this point, the agent’s package needs to be decrypted and the necessary data for its authentication and execution retrieved. The agent arrives at the server-end of the communication. Agent execution. An execution environment provides the agent’s execution. Server and agent services. These services provide agent execution, inter-agent communication, server security etc. There are server services and agent services. The security service, the execution service, the communication service, the migration service are some of the server services. The agent services are provided by agents and can be requested by other agents during their execution. Agent services can be dynamic services (available through agent communication only during their execution) or static services (available as long as the providing agents reside at the local server). The agents’ code (the code that is interpreted by the execution environment) is Java virtual code. The execution environment is provided by the Java virtual machine, which raises
difficulties on server’s control over the agent’s execution flow. An agent code programmer has access to all the facilities of Java when programming an agent. The AMP uses threads for the execution of agents. Agents have a unique name, which can be used to identify them, and they are grouped. Each agent belongs to a group. Agents can specify the groups that they want to communicate to and to which they want to provide services to. These groups are called friendly groups. It is possible for an agent code programmer to implement certain services and then allow other agents to use these services. During their execution, agents can communicate with each other using dynamic communication (both agents have to be running for this type of communication to take place). Also, a static communication can take place between a running agent and an agent service (service provided by another agent which resides at the AMP). Agents can also request migration to another AMP during execution. An important issue followed during the implementation of this agent server was transparency. An API (Application Programmable Interface) is provided for the agent code programmer. This API contains public classes and methods. Any of this classes and methods can be used without knowledge about their implementation. Also, the programmer does not know any details about the data structures used by the AMP. 2.1. Managing Agents In order to create and dispatch an agent, a programmer must follow certain steps. First, he must write and compile the classes that compose the agent to obtain the Java byte code. Then, he must use the creation service from AMP, which will generate the agent package. This operation requires additional information about the agent, information supplied by the programmer, such as the communication protocols known by the agent, services provided etc. Also some security information must be supplied (i.e. friendly groups). Once acquired the information, a header will be generated for the agent, which will be used for agent authentication (the authentication field from header). This header contains information needed for agent validation, authentication and management (name, group, friendly groups, AMP of creation, visited AMPs, known services and protocols, provided services, AMP authentication, CRCs, etc.). The header and the byte code will form the agent package. For security reasons, a part of the header will be encrypted and a CRC will be applied over the rest of the header and another CRC over the byte code. The security service from AMP is responsible for encrypting, generating of CRCs and AMP authentication. Next, the programmer has to use the migration service to request dispatch for his agent to a specified AMP. The newly created agent will begin its execution at the specified AMP. A running agent can also request migration to another AMP (it will be dispatched to another AMP). This situation is similar to the one described above. In this case the additional information, which was supplied by the programmer, is obtained from the Agent Table, available at any AMP. The Agent Table contains information about all agents currently residing at the AMP. Each agent has a corresponding entry in this Agent Table; each entry contains all the information regarding an agent (its name, group, friendly groups, available services, etc.). At any AMP, agents have a local name obtained from the agent’s original name by adding some information (to assure it’s unique). The global name of that agent will not be changed. The inverse of the agent dispatch is the agent arrival (the receiving service). After
receiving the agent through a Communication Portal, the agent will be validated. The header will be decrypted, the CRCs will be verified and the agent’s sender will be authenticated. Each AMP, on agent dispatch, adds the authentication information to the agent’s header. If no error occurs during validation, the agent will be setup. From header will be retrieved the agent’s name, group, friendly groups etc. A new entry in the Agent Table will be created for the current agent using the obtained information. At this point, the byte code, which forms the agent’s classes, is written on disk in a specific folder. Each agent will have its own folder; this way collisions are avoided (agents consisting of classes named alike will overwrite one another). To ensure proper agent execution, the agent’s classes are loaded using a Class Loader for each agent. This is due to Java’s way of loading classes; Java searches the class is supposed to load using the CLASSPATH environment variable (CLASSPATH specifies a set of folders that contain Java classes). So, in order to load an agent class the agent’s folder has to be added to CLASSPATH. But this CLASSPATH is unique so there is only one set of folders where Java looks for classes to load. Now, if two agents have classes named alike for both of them the same class will be loaded during their execution, so for one of them the wrong class will be loaded. By using a Class Loader, for each agent can be specified a folder from which to be loaded its classes (agent’s folder). Now the agent can be executed. During execution the agents can communicate with each other, they can request services (server services or agent services) and/or they can request migration to another AMP. Communications between running agents and agent service requests can be possible only if requested agents allow this thing (if the agent that requested belongs to the requested agent’s friendly groups and vice versa). 2.1.1. Migration Agent migration can be realized in several ways:
The agent can specify the destination AMP. In this case, the requested AMP will be verified if it exists and is ‘alive’. If so, the agent will be dispatched to that AMP. This type of migration does not involve the agent server (in finding a destination AMP). The agent can specify several AMPs. These AMPs can be interpreted as: – The agent wants to migrate to one of the AMPs. – The agent does not want to migrate to any of the AMPs, – It is specified where it wants to migrate to and where not. The agent server will decide where the agent will migrate based on the specified AMPs and the list of already visited AMPs.
The agent can request migration without specifying any AMP. The agent server will determine where the agent will migrate. The agent’s execution will be terminated after a migration request. Once an agent terminates its execution, either normal or due to an error, all information regarding that agent will be erased (agent’s entry from the Agent Table will be erased).
3. Communication between Agents 3.1. Necessity of communication In any distributed system, the communication between its components is a very important issue. An agent-based system makes no exception from the rule. Moreover, agent systems cannot be imagined without communication. Dynamic communication between agents is useful for agent cooperation in completing a task; either all agents solve the same task (each agent doing the same thing, any of them being able to succeed) or each agent solves a sub-task of the initial one (cooperating one with the other). 3.2. The Dynamic Communication Module The provided API contains data structures and methods for dynamic communication between agents. There are methods for local (agent running on the same AMP) and far (agents running on different AMPs) communication requests. At the programmer’s level this is done by means of message transfer (send and receive). Two structures, one for each type of communication, are provided; the local communication structure and the remote communication structure. The send and receive methods are defined inside these structures. When a communication request is made, the partner’s communication structure is returned. Further on, the communication structure (local or remote) of the requester is bound to the partner’s one (the destination is established). Thus, the place where the messages are to be sent being known, the communication may start. 3.2.1. Features of the Dynamic Communication Module An important issue in creating the communication module is the temporal side of the communication (in fact, of the communication request). The most natural way of making a communication request is the one in which the agent can receive a request at any time. This is the asynchronous way of requesting communications. In other words, the communication request, which may or may not be accepted, arrives asynchronously during the agent’s execution. But, the most convenient way of communication is the synchronous one, where sending or receiving a message is made with blocking (the send method blocks as long as the message queue is full, and the receive method blocks when there is no message in the queue). As far as the spatial side of the communication, this can be local (the two communicating agents are on the same AMP) or remote (agents are on different AMPs). In both cases the communication request arrives asynchronously. The remote communication is an extension of the local communication system, meaning that both types of communications take place in the same way (from the agent’s perspective). The communication (and the communication request) is achieved through shared memory (at the module implementation level). 3.2.2. The way the communication takes place 1. At the requester’s side: A communication will be initiated. For this to take place, the partner has to be identified somehow. This is done using a key. This key may be: the
dynamic service executed by the agent, the agent’s source machine, the agent’s group, the agent’s identifier (unique), the protocol known by the agent (mandatory). To obtain multiple keys, one may use combinations of the above mentioned elements. First, the system searches for the requested agent (locally or remotely). If the agent is found, the system tries to suspend it’s execution. If it succeeds,then the communication structure is returned. After binding the communication structures (establishing destination) communication by means of sending and receiving messages can be done. 2. The requested agent’s side: For each agent’s there are two threads: one for running the agent’s code, and another for communication. The communication thread checks for communication requests. Upon receiving a communication request, the requested agent’s execution is suspended (if possible). After this, communication can begin. A communication method is invoked, with the following parameters: the communication protocol used, the requester agent object and its communication structures. The dialogue between the two agents ends, usually, when the initiating agent sends a termination message. Other possibilities could be: an exception which occurs at the server, or an announcement that a communication timeout is reached (this ”alarm” is simulated by starting a timeout thread at the beginning of the communication, by the server, of course). 3.2.3. The Extension for Remote Communication One of the design principles followed was that the remote communication takes place in the same manner as the local one. The main problem was how to access a memory location on a remote machine. We decided that the most efficient way was to use the Java RMI features for this purpose. The remote objects’ methods have some interesting properties:
Their parameters, if they are remote objects, are transmitted as references. This means that when method M is executed on machine B (while its call was made on machine A) its remote object parameters are, in fact, objects from machine A’s memory; The same situation arises in the case of return values if these are remote objects: they also come as references. The extension in the communication module, which permits remote communication, consists of the following: on each AMP that allows remote communication, a remote object is defined. This object is registered with Java’s rmiregistry (by convention, its name will be unique on all AMPs). This special object contains a field that points to the memory region where all agents are registered. It also contains a method for requesting communication with an agent on the local AMP. Under these terms, the remote communication takes place in a similar way as the local communication. One difference consists in the manner by which the partner agent’s object is obtained: the name service of the remote AMP is used. Another difference is that all operations take place on the remote AMP. The communication structures are remote too. 3.2.4. The implementation of the Communication Structures Both the local and the remote communication structures are implemented using circular queues. The remote communication structure is a remote object. For sending and
receiving messages there are defined methods called send() and receive(). Before doing any kind of communication, the destination has to be established. By calling the send() method a call to the put() method of the destination communication structure is made. Methods send() and receive() are synchronized (if a call to receive is made while a call to send is already running, the receive call blocks until the send method exits). 3.2.5. Adding New Protocols For agents to communicate properly with each other, they have to speak a common language. This language is represented by a protocol known by both of the communicating agents. Since a single general purpose protocol cannot be define, our framework lets the programmer use its own protocols. This means that the server must accept dinamically new protocols, as new agents arrive at the corresponding AMP. We have implemented a server service that provides for dynamic registering of protocol names. This resembles to a “name server”. Along with the protocol names, the service registers the classes and methods that implement the corresponding protocol. These classes are written by the agent code programmer. In order to load the protocol classes, the Reflection mechanism provided by Java is used. This mechanism provides a way to load and execute classes without knowing their names at the compile time. The communication methods are implemented using the same Reflection mechanism. 4. Security issues 4.1. Security in mobile agent systems Security is an essential issue in any distributed system. The information moving between different components of the system is vulnerable to external attacks, as well as to unauthorized intrusion from inside the system. While accessing the system from the inside can be easily limited through internal rules and monitoring, intruders from the outside world may generate serious problems if they succeed to break in the system or to manipulate the information flow. Mobile agent systems are particularly sensitive to attacks, because their main components, the agents, are - basicly - programs that can migrate from a location to another, transporting data and executing tasks on the host. Therefore, if an agent is corrupted through external intrusion, it represents a potential danger for the respective host and for the entire system. An intruder has, in theory, two ways to attack the system: 1. Direct attacks. The intruder may create an agent of his/her own, then trying to make it run in the system. If the system accepts such an agent, its security is obviously compromised, because the agent’s actions cannot be easily traced, and the consequences cannot be foreseen. 2. The Man-in-the-middle attack. The communication lines are a very important element when considering security for distributed systems. An unathorised person, posessing adequate hardware, may interfere with the communication between two hosts (components of the system), by receiving the transmitted data and/or by altering it and sending it for-
ward, to the destination. The attacker may, for example, modify the information an agent carries from one host to another, or modify the agent’s code itself, inserting actions to be done at the destination, serving his/her purpose. This is obviously the most dangerous method, as the destination host may never know that an intrusion arised, therefore treating the agent as a fair one, executing blindly its unauthorised tasks. Another issue in securing mobile agents systems is the direct communication between agents when they arrive to a certain host. First of all, the agents has to be executed in an environment that provides for a complete separation between their codes and data, making sure that their actions will not interfere in any kind. Then, the communication between them must be supervised. Particular applications using agents may require that not every agent to be capable of talking to other agents, or that agents must be discriminated through access rights or privileges. Therefore, a framework for developing mobile agent-based applications has to provide tools for solving these problems. Finally, there is the interaction between the hosts as components of the system. An environment that runs agents on a host may communicate directly to another, from a different host, exchanging information about, for instance, the system status and security. This interaction can be done so that it strengthens the system security and provides a global view of the system’s behaviour. 4.2. The security model in DSDAgents The DSDAgents framework is designed to provide tools for creation, execution and migration of mobile agents. The programmer who uses the framework doesn’t have to be concerned about the details of implementing the agent basic functions, having to specify only their behaviour in the system. That is, he or her will never have to think about how agents are transmitted or received, about how the host environment works, and about how the communication between agents or between agents and hosts is done. One of the goals stated when we designed this system was that the user (i. e. the programmer) must also not be bothered with details regarding security. Our first approach of security for DSDAgents has focused on the two most important things (in our opinion) that provides for a secure behaviour of the system: the authenthication of agents and the control of communication between agents, using privillege-based mechanisms. As seen in the previous sections, a mobile agent system created with DSDAgents has two types of components: servers, situated on hosts, providing the virtual machines for running agents, and agents themselves. To provide security, we have introduced a few conventions regarding the agent-based system’s architecture. First of all, the system consists of a number of hosts in a local or wide area network. Every host in the system is considered trustworthy by all the other hosts. Every host has a list with all hosts in the system, with their IP addresses. Any agent that proves that it comes from a trusted host and that its code and data was not altered in between, is considered reliable and is accepted as belonging to the system. All other agents, coming from unlisted hosts, are not allowed in the system, that is they will never be accepted and executed by any host. A host may send an agent to itself. The security database containing the addresses of trusted hosts is maintained on every host by an agent system administrator who may be other person than the local network sysadmin. Moreover, this database has to be secured through local operating system’s mechanisms, ensuring that it can be neither modified nor read by unauthorised persons or programs.
4.2.1. Authentication The security is based on mutual trust between the hosts in the system. So, an agent coming to a host, asking to be executed, has to prove both its provenience and code/data integrity. DSDAgents system has solved this problem using cryptographic tools as message digests, encryption and digital signatures. The agent’s header (present when the agent is transmitted on the communication line) contains a special zone storing security information. This is called ”crypted message” and it’s encrypted through a symmetrical algorithm (DES). The key is called ”system key” and it is unique in the system, being known by every host belonging to the system. This key is stored in a protected directory in the host’s filesystem, being kept unreachable by unauthorised persons. The information in the crypted message is:
The agent identifier The group identifier - tells what is the group the agent belongs to (see below for details) A list of friendly groups (see below) The header message digest, storing the digest of the rest of the header, for authentication purposes The agent message digest - a message digest authentifying the agent code and data The last two items are generated using the MD5 algorithm and are signed by the host that has sent the agent, using an asymmetric encryption algorithm (RSA). (In fact, both items are digital signatures based on MD5-RSA suite) There are two more kinds of keys stored on every host, used with the RSA algorithm: a secret key for the host, kept in a secured location, and a set of public keys identifying all hosts in the system, including the local one. Having this information, a host receiving an agent can easily authenticate both its provenience (using the public key of the sender to decrypt the message digests) and the integrity of the agent itself (verifying the message digests). The cryptography procedures were written using the International Java Cryptography Extension (the Cryptix library) [4]. 4.2.2. Communication. Groups of agents In order to provide flexibility in writing agent-based applications, the DSDAgents framework introduces a method to discriminate the agents using a sort of access rights based mechanism for the communication between two agents. Thus, every agent belongs to a group, and every agent declares a list of friendly groups. The communication between agents follows these rules: 1. An agent can provide services to any agent belonging to the same group; 2. An agent can provide services to all agents belonging to friendly groups; 3. An agent can neither require nor provide services from/to agents that does not belong to it’s group or to friendly groups.
Consequently, two agents will be able to exchange services only if they belong to the same group, or every one belongs to a group friend to the other. The fact that the ”friendship” is defined between one agent and several groups, brings flexibility in describing the ”security policy” a user may want to define. For example, a group may contain agents with different friendly groups, as well as agents without friendly groups at all. The mechanism allows to define both ”highly privilleged” groups or agents and ”public” agents having as friends all existing groups (note that although an agent A from a group G declares friendly a group H, if no agent in the group H declares friendly the group G, the agent A will never be able to communicate with an agent belonging to H.) 5. Conclusions In this paper is described the way we implemented an agent framework that can be used to create mobile agent-based systems. The framework consists of an agent server program (the AMP) and an Application Program Interface (API) in Java.All tasks concerning the creation of agents, their migration and execution, the communication between then and the security issues are solved within the framework. Therefore, the agent code programmers do not have to be concerned about these details, being able to concentrate on building their own agent-based application software. The main issues taken under consideration were: the agents’ ability to communicate with each other, both locally and remotely, their ability to migrate from host to host, the security of the agent-based system (protection against unauthorised entities). There are many possible improvements to this scheme: keeping logs of agents’ behaviour while at the local AMP, allowing agents to receive communication request at any time, developing a direct communication system between AMPs to exchange security information and so on. Currently, these improvements are not yet fully implemented, but there are several issues already under consideration. References [1] J. Baumann, F. Hohl, K. Rothermel, M. Strasser: “Mole - Concepts of a Mobile Agents System”, Institute for Parallel and Distributed High-Performance Computing, Stuttgart, 1997 [2] Mitsuru Oshima, Guenter Karjoth: “Aglets Specification”, IBM Japan [3] V. Patriciu: “Cryptography and Security of Computer Networks”, Editura Tehnica, Bucharest 1994 [4] *** : “Cryptix(tm) Provider Documentation”, The Cryptix Development Team http://www.systemics.com/docs/cryptix
