difﬁculties on server’s control over the agent’s execution ﬂow.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
allowother 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 (ser-
vice 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
knowany details about the data structures used by the AMP.
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 fromAMP,which will generate the agent package.
This operation requires additional information about the agent,information supplied by the pro-
grammer,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 informa-
tion,a header will be generated for the agent,which will be used for agent authentication (the
authentication ﬁeld fromheader).This header contains information needed for age nt 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 speciﬁed AMP.The newly created agent will begin its execution a t the speciﬁed 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 fromthe 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
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 communica-
tion between agents.
There are methods for local (agent running on the same AMP) and far (agents run-
ning 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 communica-
tion,are provided;the local communication structure and the remote communication structure.
The send and receive methods are deﬁned 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
communicationrequest 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 communi-
cating 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 (fromthe 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 identiﬁed somehow.This is done using a key.This key may be:the
receiving messages there are deﬁned 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 com-
mon language.This language is represented by a protocol known by both of the communicat-
ing agents.Since a single general purpose protocol cannot be deﬁne,our framework lets the
programmer use its own protocols.This means that the server must accept dinamically new
protocols,as newagents 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 name s,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 Reﬂection mechanismprovided by Java is
used.This mechanismprovides a way to load and execute classes without knowing their names
at the compile time.The communication methods are implemented using the same Reﬂection
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
Mobile agent systems are particularly sensitive to attacks,because their main com-
ponents,the agents,are - basicly - programs that can migrate from a location to another,trans-
porting 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 compro-
mised,because the agent’s actions cannot be easily traced,and the consequences cannot
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 ad-
equate 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 knowthat 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 be-
tween 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 systemstatus and security.This interaction
can be done so that it strengthens the systemsecurity and provides a global viewof the system’s
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 con-
cerned 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 trans-
mitted 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
Our ﬁrst 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 systemcreated 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 systemis 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 systemadministrator 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 modiﬁ ed nor read
by unauthorised persons or programs.
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 deﬁned between one agent and several groups,
brings ﬂexibility in describing the ”security policy” a user may want to deﬁne.F or example,
a group may contain agents with different friendly groups,as well as agents without friendly
groups at all.The mechanism allows to deﬁne 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.)
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 ProgramInterface (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’ be-
haviour 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.
 J.Baumann,F.Hohl,K.Rothermel,M.Strasser:“Mole - Concepts of a Mobile Agents
System”,Institute for Parallel and Distributed High-Performance Computing,Stuttgart,
 Mitsuru Oshima,Guenter Karjoth:“Aglets Speciﬁcation”,IBMJapan
 V.Patriciu:“Cryptography and Security of Computer Networks”,Editura Tehnica,
 ***:“Cryptix(tm) Provider Documentation”,The Cryptix Development Team