protection and interoperability for mobile agents: a secure and open programming environment

IEICE TRANS. COMMUN., VOL.E83–B, NO.5 MAY 2000961

PAPER IEICE/IEEE Joint Special Issue on Autonomous Decentralized Systems

Protection and Interoperability for Mobile Agents:

A Secure and Open Programming Environment∗

Paolo BELLAVISTA†, Antonio CORRADI†, and Cesare STEFANELLI††, Nonmembers

SUMMARY The Mobile Agent technology helps in the de-velopment of applications in open, distributed and heterogeneousenvironments such as the Internet and the Web, but it has toanswer to the requirements of security and interoperability toachieve wide acceptance. The paper focuses on security and in-teroperability, and describes a Secure and Open Mobile Agent(SOMA) programming environment where both requirements aremain design objectives. On the one hand, SOMA is based on athorough security model and provides a wide range of mecha-nisms and tools to build and enforce flexible security policies.On the other hand, the SOMA framework permits to interop-erate with different application components designed with differ-ent programming styles. SOMA grants interoperability by closelyconsidering compliance with the OMG CORBA and MASIF stan-dards. SOMA has already shown the feasibility and effectivenessof the approach for the development of flexible and adaptive ap-plications in several areas, particularly in network and systemsmanagement.key words: mobile agents, security, interoperability, CORBA,

network and systems management

1. Introduction

Global distributed systems such as the Internet andthe Web have proposed a new framework for applica-tion development and have motivated the interest innew programming paradigms based on mobile and dy-namic entities. Remote Evaluation, Code On Demandand Mobile Agents (MA) [1]–[3] propose the migrationnot only of data but also of code over the network, toimprove the flexibility of the traditional client/server(C/S) model. The MA model differs from the aboveones because it allows executing entities to decide au-tonomously about their migration (code and runtimestate).

The MA paradigm is still in its infancy, but hasalready demonstrated its wide potential of applicabil-ity [3]. It could be suitable for several application ar-eas, such as network and systems management, mobile

Manuscript received October 4, 1999.Manuscript revised January 4, 2000.

†The authors are with the Dipartimento di Elettron-ica, Informatica e Sistemistica, Universita di Bologna, VialeRisorgimento 2, 40136 Bologna, Italy.

††The author is with the Dipartimento di Ingegneria,Universita di Ferrara, Via Saragat 1, 44100 Ferrara, Italy.

∗Work carried out under the financial support of theItalian Ministero dell’Universita e della Ricerca Scientificae Tecnologica (MURST) in the framework of the Project“MOSAICO: Design Methodologies and Tools of High Per-formance Systems for Distributed Applications.”

computing, distributed information retrieval, and e-commerce. Numerous benefits are expected, includingdynamic customization of both servers and clients, au-tonomy and adaptability in realizing user asynchronousoperations, traffic reduction by exploiting resource lo-cality and filtering opportunities, and robust remoteinteraction over unreliable networks and intermittentconnections.

In addition to the issues specific to code mobility,MA systems for Internet-based applications should ad-dress all the intrinsically complex aspects of the dis-tributed systems area [4]. In particular, the paperclaims that there are two issues deserving more atten-tion by researchers and practitioners and that couldgreatly widen the application opportunities: the capac-ity of providing the proper level of security needed byapplications and the possibility of granting the neces-sary degree of interoperability.

The issue of security, overlooked in some of thefirst MA proposals, should be reconsidered in order tofind solutions to the problems raised by the deploy-ment of the MA technology in untrusted environmentssuch as the Internet. Code mobility, intrinsic to theMA programming paradigm, adds another dimensionof complexity to the problem of security.

Interoperability is another critical requirement inthe Internet scenario: MA applications should be capa-ble of interacting with any other application and ser-vice, independent of the adopted programming style.The globality of the scenario forces to consider opensolutions and standards for the interoperability issue.

The paper describes an MA framework calledSecure and Open Mobile Agents (SOMA, availableat http://lia.deis.unibo.it/Research/SOMA/) that an-swers the key issues raised by the adoption of an MAprogramming environment for the Internet. SOMAprovides a hierarchy of locality abstractions that helpsin modeling a large variety of different schemes of in-terconnected networks. SOMA has been designed ac-cording to a layered architecture with several modulesin each layer. The basic layer provides a rich set offacilities to simplify the deployment of MA-based ser-vices. On top of the basic layer, the security modulemakes available a large number of security mechanismsand tools, to permit different tradeoffs between per-formance and security, while the interoperability mod-ule exploits the CORBA technology [5] to achieve the

962IEICE TRANS. COMMUN., VOL.E83–B, NO.5 MAY 2000

full integration with other CORBA-compliant environ-ments, based on distributed OO frameworks and on MAplatforms via the Mobile Agent System InteroperabilityFacility (MASIF) [6]. MASIF is a standard proposal tosupport agent mobility and management and is builton top of CORBA.

We have used SOMA as a platform for the design,implementation and deployment of distributed appli-cations in several application areas. In particular, wehave realized an environment for network and systemsmanagement, which exploits the SOMA technology tofurnish secure management services and interoperabil-ity with CORBA-compliant legacy systems.

2. Security and Interoperability in MA Sys-tems

The deployment of MA applications in the Internet en-vironment can be accelerated as soon as MA systemscan provide solutions that respect the opening and clos-ing properties. The opening property permits to over-come the system boundaries in order to interoperatewith any necessary external component and to allowany external recognized usage, while the closing prop-erty is the possibility of constraining the system in sucha way to identify and exclude any malicious intrusion.The opening property is granted by interoperability con-siderations and the closing property by security mech-anisms and policies.

The first MA prototypes fail to satisfy completelythe opening and closing properties. For this reason, asignificant portion of the recent MA research has fo-cused on the areas of security and interoperability (seeSect. 6 about related work). Here, we try to identifythe main aspects of security and interoperability pecu-liar of MA frameworks and to detail possible guidelinesfor solution.

Security is a fundamental issue when dealing withmobile agents in the untrusted Internet environment,where the communication network is assumed insecureand any node could host the execution of possibly mali-cious agents. The most common solutions adapt to theMA technology the accepted and standard mechanismsalready emerged in the distributed computing area [7].

A secure MA framework should protect bothagents and their execution environments from each oth-ers. At the moment, the MA research about securityhas mainly concentrated on the issue of protecting sitesfrom potentially malicious agents [8]. This means to en-sure that incoming agents cannot access to informationthey are not authorized to act upon, they cannot causea denial of service to other authorized entities, andthey cannot deliberately interfere with agents of otherusers. To this purpose, it is possible to exploit standardsolutions for cryptographic authentication and autho-rization controls. Agent execution can be confined byadopting sand-boxing techniques and more flexible evo-

lutions with a finer degree of granularity controls [7].Also the issue of agent protection from malicious sitesis fundamental for MA applications in untrusted envi-ronments. The secrecy of message and agent transfercan benefit from accepted mechanisms and tools for se-curing the communication layer [7], while preservingagent integrity is still an active research area [9].

A crucial goal of MA security is to identify theapplication-specific proper balance between differentand sometimes contrasting requirements: security, flex-ibility, usability, and efficiency. For this reason, it isimportant that the programming framework provides alarge variety of security mechanisms, tools and infras-tructures, to flexibly answer the different requirementsof application designers.

The second important property for MA systems toachieve is full interoperability. In general, MA propos-als tend to consider it the provision of an easy access tousers of the Internet and the Web. We claim that fullinteroperability means not only the possibility of useraccess via friendly GUI interfaces, but also the capacityof interacting with other applications, either designedaccording to the same MA style or with very differentstyles, and even with legacy systems.

The goal of interoperability requires to identifythe aspects of the MA technology candidate to becomestandard. The main recognized effort in the standard-ization toward interoperability of Object-Oriented com-ponents is Common Object Request Broker Architec-ture (CORBA), promoted by the Object ManagementGroup (OMG) [5]. The OMG works in different spe-cialized areas, and one of its subgroups has definedthe MASIF standard [6]. MASIF integrates the tra-ditional C/S model and the MA paradigm, thus pro-viding CORBA-based interfaces for agent registering,management and transfer. There are also other inter-esting approaches toward the standardization of manyaspects of the MA technology, such as the FIPA pro-posal that focuses on the definition of general standardlanguages and protocols for communication and man-agement of heterogeneous agents [10].

3. The SOMA Programming Environment

This section gives a general overview of the architec-ture of the SOMA programming environment and thenpresents the design solutions adopted to provide theopening and closing properties.

3.1 The SOMA Architecture

SOMA is based on a hierarchy of locality abstractionsto model and describe any kind of open and global dis-tributed system, ranging from simple LANs to the In-ternet, as depicted in Fig. 1. Any node owns at leastone place that constitutes the agent execution environ-ment. Several places can be grouped into a domain

BELLAVISTA et al.: PROTECTION AND INTEROPERABILITY FOR MOBILE AGENTS963

Fig. 1 Locality abstractions and CORBA connection.

Fig. 2 The SOMA layered architecture.

abstraction that corresponds to a network locality. Ineach domain, a default place hosts a gateway to performinter-domain functionality, to maintain domain-specificruntime information and to permit full integration withother components via the interoperability facility (seeSect. 3.3).

Places and domains abstract a logical representa-tion of system physical resources, and permit users andadministrators to express their needs in terms of mo-bile agents, and to develop new applications and ser-vices based on mobile code. Mobility is an intrinsicfeature not only of agents but also of most entities inthe SOMA system, e.g. a mobile place is suitable formodeling the behavior of a nomadic terminal.

The SOMA programming framework is designedaccording to a layered architecture, built on top ofthe Java Virtual Machine (JVM), as depicted in Fig. 2.SOMA main features are provided by the facility layer,that contains the principal functionality to fully sup-port MA-based applications. This layer is composed bya set of basic facilities and by two distinguished com-ponents in charge of granting the opening and closingproperties.

The SOMA basic facilities include:

• the naming facility to associate entities with glob-ally unique identifiers (GUID) and to organizethese identifiers in name systems to make possiblethe tracing of entities even if they move. This facil-ity allows to put together a set of different namingsystems (DNS-, CORBA-, and LDAP-compliant),possibly characterized by different resolution poli-cies, and is currently implemented by a coordi-nated set of dedicated agents;

• the migration facility to permit the migration ofone entity that should change its allocation. Thereallocated entity should be traced also in the newlocation by any entity in need of its services, and,if it is active, should transparently restart its exe-cution at the new location;

• the communication facility to provide tools for co-ordination and communication between possiblymobile entities. Within the same place, agentsinteract by means of shared objects, such asblackboards and tuple spaces for tight coopera-tion. Outside the scope of the place, agents canperform coordinated tasks by exchanging asyn-chronous messages that are delivered to agents alsoin case of migration;

• the monitoring facility to observe the state of localresources and services and to provide this informa-tion to the application level for permitting dynamicadaptive reactions. SOMA can monitor both sys-tem indicators (e.g. CPU load, file system occupa-tion, printer status, available network bandwidthand collision rate) and application indicators (e.g.available services, program versioning, local agentsstate);

• the persistency facility to give the possibility tosuspend temporarily executing agents and to storethem on a persistent medium. The facility allowsagents not to waste system resources while theyare waiting for external events such as the recon-nection of one user or terminal to yield back theresults of autonomously performed operations. Inaddition, it can be also exploited in providing fault-tolerant solutions by organizing and disseminatingstored copies of agents [13].

As shown in Fig. 2, on top of the basic facilities we haverealized two advanced SOMA facilities to provide a richset of mechanisms for interoperability and security.

• The security facility provides tools for protectingboth mobile agents and places. Authenticationis based on standard certificates and on a publickey infrastructure; authorization extends the Javastandard mechanisms for access control; secrecy isachieved by integrating the cryptographic librariesfurnished by external providers; integrity has re-quired the development of MA-specific protocolsfor the protection of mobile agents from the exe-cution environment.


• The interoperability facility allows SOMA agentsto interwork with existing software and hardwarecomponents via compliance with CORBA IIOPspecification [5]. SOMA agents can play the roleof CORBA clients and can register themselves asCORBA servers to offer access points to an ap-plication outside the SOMA system. In addi-tion, SOMA is compliant with the OMG work onMASIF [9] that standardizes the basic functions anMA framework should offer for agent managementand transfer to other systems, whether MA-basedor not.

Further details about the SOMA programming frame-work and its implementation are presented elsewhere[11], [12] and are out of the scope of this paper, wherewe specifically focus on the SOMA facilities for securityand interoperability.

3.2 The SOMA Security Facility

SOMA has been designed and implemented by con-sidering security as a key property integrated at anysystem layer [13]. Only this pervasive approach canachieve a level of security higher than the minimalone reached by MA systems that add a security strat-egy a posteriori. Whenever possible, SOMA securitymodel has been implemented by taking into accountonly the standard security solutions usually employedin distributed systems. In fact, the design and the ex-ploitation of ad hoc security mechanisms could requiretoo great an effort, and, more important, nonstandardtools are close and unlikely to be accepted if comparedwith widespread solutions.

SOMA addresses all the security issues that emergein the context of real MA applications running on theInternet [15]: it provides protection for both hosts andagents, and ensures secrecy and integrity for agent com-munication and migration.

SOMA recognizes a set of principals, i.e., the usersresponsible for agent and resource operations, and sup-ports the definition of any model of trust for principalsand mobile agents, to define who or what in the sys-tem is trusted, in what way, and to what extent. TheSOMA security facility implements the model of trustand enforces the security policies.

Principals are identified by standard certificatesand are associated with a limited number of rolesthroughout the SOMA system. Roles permit to expressthe required model of trust, by determining the permit-ted operations on system resources. The association ofprincipals with roles simplifies user administration andenhances the dynamicity in system configuration: onlythe information about roles needs to be propagated inthe system, while principals are locally and dynamicallyassociated with possibly different roles [16]. A graphicaltool for run-time role management allows administra-

Fig. 3 Different security paths for agents from un/trusteddomains.

tors to define new roles and to update existing ones,to associate principals with roles, and to automaticallygenerate corresponding place policies.

Mobile agents are signed by their principals, andthe authentication phase ascertains the role of the agentprincipal [16]. When one agent is signed by more princi-pals, it aggregates the permissions associated with theircorresponding roles. Once authenticated, agents areauthorized to interact with resources at the place ac-cording to the dynamically enforced security policy; anyresource has its specific role-based access control list.Places can also maintain some accounting informationon resource consumption by exploiting the functionalityprovided by the SOMA monitoring facility.

Secrecy for agent/message transfer in SOMA ex-ploits standard solutions for securing the communica-tion layer. The issue of agent protection from hostingplaces is still an active area of research [15]. For in-stance, SOMA provides mobile agent integrity protec-tion by using a number of integrity protocols that cansuit different application scenarios; the main idea is todetect any possible modification of the data collectedby agents moving in an untrusted domain [17].

Our security infrastructure is based on layered se-curity policies: the definition of different locality ab-stractions enforces security policies where actions arecontrolled at both the place and the domain level. Thedomain defines a global security policy that imposesgeneral authorizations and prohibitions; each place canonly apply restrictions to the domain-level set of per-missions (see Fig. 3).

The wide variety of security mechanisms availablein SOMA, and the clear distinction between mecha-nisms and policies give the possibility to decide a suit-able trade-off between security needs and required per-formances, tailored on specific circumstances. As de-picted in Fig. 3, agents from internally trusted domainscan directly access to authorization check, while agentsfrom untrusted ones have to overtake all the secrecy, in-


Fig. 4 SOMA full compliance with CORBA.

tegrity, authentication and authorization steps. As anadditional example, two endpoints can negotiate SSLconnection parameters in order to have none/short/long key protection according to the nature of the ap-plication and to the level of trust they grant to eachother.

3.3 The SOMA Interoperability Facility

The large number of recently implemented MA plat-forms shows the interest of the distributed systems areain the MA programming paradigm. This variety, how-ever, risks to endanger interoperability and to limit thegrowth of an MA applications industry. The only wayto promote both interoperability and system diversityis to standardize some aspects of the MA technology.

In the area of the traditional C/S approach toOO distributed computing, CORBA is the universallyadopted standard for object management, apart fromthe notable exception of Microsoft which has its ownDistributed Component Object Model (DCOM) [18].CORBA puts together objects that can communicateto each other across boundaries such as network, differ-ent operating systems, and different programming lan-guages. CORBA provides network transparency, open-ness and interoperability. In addition to that core func-tionality, it specifies an extensive set of object services,common facilities and application interfaces.

The MA model embodies a new programmingparadigm, distinguished from the C/S one, and, con-sequently, different from the CORBA programmingmodel under many points of view (e.g. location aware-ness vs. network transparency). However, we claim thatCORBA can play a fundamental role in achieving in-teroperability also for the MA technology, working as astandard bridge among proprietary implementations.

CORBA compliance imposes some additionalcosts, especially in terms of run-time performance, butit is worth the trouble because it ensures openness andstability to applications, saving the investments in MA-based programming. Our scenario puts together twomodels: we use proprietary and efficient solutions forinternal operations among SOMA entities, but provide

standard CORBA interfaces, both for exploiting theavailable CORBA services and for making SOMA itselfa CORBA application object.

There are three different aspects in providingSOMA compliance with CORBA (see Fig. 4):

1. an agent may call external CORBA objects (SOMAagents as CORBA clients);

2. an agent may publish its interface on a CORBAORB (SOMA applications as CORBA servers);

3. any external entity may manage SOMA entitiesthrough the standard MASIF interface (interoper-ability between SOMA and other MASIF-compliantMA platforms).

The first two features are obtained via the CORBA C/Smodule of the SOMA interoperability facility, whichprovides functionality to simplify the application de-signer duty in deploying CORBA-compliant compo-nents: agents can play the role of CORBA clients or canregister themselves as CORBA servers to offer an appli-cation access point outside the SOMA system (see thenetwork and systems management service in Sect. 5).Even if there is no conceptual problem for a mobileagent to register itself as a CORBA server, we cur-rently grant this possibility only to SOMA agents thatdo not migrate during their lifetime (stationary agents)in order to avoid the burden of de/registering to theCORBA Naming Service at any migration.

The third functionality is more complex an issue,and is addressed by the MASIF standard. MASIFdoes not suggest standardization of local agent oper-ations such as agent interpretation, serialization, ex-ecution and deserialization because these actions areapplication specific, and there is currently no rea-son to limit MA system implementations to a singlerigid architecture. MASIF proposes a standardizationfor agent and agent system names, for agent systemtypes and for location syntax. It defines two interfaces(MAFAgentSystem and MAFFinder) with the typical setsof functionality respectively for agent management andfor agent tracking. Agent management allows an exter-nal system to control agents of a MASIF-compliant MAsystem: MASIF defines interfaces for actions such as


suspending/resuming/terminating agents or for movingagents from an MA system to another one if the twosystems have a compatible type. Agent tracking per-mits the tracing of agents registered with MAFFinders,which essentially provide an MA name service, sincethe CORBA Naming Service is not suitable for entitieslike agents, which are mobile by nature. Agent com-munication is outside the scope of MASIF, since it isextensively addressed by CORBA as object communi-cation.

The CORBA and MASIF standards recognize theneed of security information and its management; allthe implementations are required to introduce tools andmechanisms to enforce security when interacting withexternal components. SOMA also considers the addi-tional security threats introduced by CORBA interop-erability. On the one hand, sending/receiving CORBArequests/replies requires security techniques for chan-nel encryption to ensure privacy on message exchange.On the other hand, the possibility for SOMA agents toact as CORBA servers and for SOMA places to hostnon-SOMA agents call for mechanisms for client/agentauthentication, auditing and access control. SOMAtakes into account the security problems by providingsolutions compliant to both CORBA Security Services(CORBA SSs) [19] and MASIF security features.

4. The SOMA Implementation

SOMA is implemented in Java to exploit its easy inte-grability with the Web scenario and its intrinsic porta-bility in heterogeneous environments: we have devel-oped the system on SUN Solaris workstations, and eas-ily ported it to Win9x/NT PCs. Our support operateson both architectures and uses the Java 2 Platform [20].

The OO nature of the Java language has helped thedesign of the SOMA system: the encapsulation princi-ple suits the abstraction needs of both resources andagents; the classification principle makes possible to in-herit behavior from already specified components; mul-tithreading, garbage collection and error managementsimplify writing robust CORBA objects.

A well-known problem of Java is the lack of fullmobility support, especially for Java threads: it is notpossible to save the whole state of a thread before itsmigration to a different node. This restriction can beovercome either by modifying the JVM or by provid-ing a new operation at the application level. We havechosen the latter solution to preserve portability. Thenew operation for mobility allows one agent to moveitself during execution, by specifying the itinerary ithas to follow and the method to be activated after anymigration.

4.1 The Security Facility Implementation

A large number of security mechanisms is available in

order to provide large flexibility in the choice of themost suitable security level for the specific context (ap-plication type, agents coming from trusted/untrusteddomains and communicating in a secure/insecure net-work).

The protection of execution environments frommalicious agents is addressed by authentication and ac-cess control mechanisms, and is based on a public keyinfrastructure with X.509 certificates. Security poli-cies define the permissions to operate on local resourcesfor any recognized role in the system. Policies are de-fined at both the place and the domain levels and arestored in encrypted files. SOMA provides also a graph-ical management tool for domain/place administrationthat can add/delete/modify entries in the policy file atrun-time, with no need to suspend execution.

From the agent perspective, integrity and secrecyfor message exchange and agent transfer are achieved bystandard cryptographic mechanisms. When configuringthe SOMA system for untrusted environments, it is pos-sible to choose between the DES channel encryption, orthe SSL protocol solution (that is just about to be in-tegrated in the next release of SOMA). In the formercase, any agent traversing an insecure path is encryptedwith a secret key, previously exchanged through eitherthe RSA or the DH protocol, and only valid for onesession of interaction. In the latter case, we adoptedthe SSL protocol provided by the iSaSiLk package [21]that realizes not only confidentiality but also authenti-cation and integrity on the standard socket communi-cation layer. SSLv3 can support a set of different al-gorithms (RSA/DH/DSA for certification and privatekeys, RSA/DH for secret keys). During a preliminaryhandshake phase, the two socket ends can choose thealgorithms to use, according to the required securityneeds; the choice can be renegotiated at any time dur-ing the communication session.

Finally, SOMA protects agents from misbehaviorof execution environments, by providing several proto-cols to preserve the integrity of both agent code andstate. These protocols prevent malicious environmentsnot only from modifying the information collected byone agent, but also from deleting part of it withoutbeing detected.

The different integrity protocols available in theSOMA environment are targeted to different applica-tion cases, and can exhibit slightly different costs de-pending on the required security level [17]. In partic-ular, Table 1 presents the performance of the MultipleHops (MH) integrity protocol for agent state protec-tion. The experimental results have been obtained byconsidering one agent that gathers 1 kB of data in eachvisited site, in the case of a cluster of 300-MHz Pen-tiumII PCs with Windows NT. Table 1 compares theagent migration cost without any integrity protectionwith the one obtained by considering the MH protocol.

The total migration costs are composed of a trans-


Table 1 Performance evaluations of the MH integrity protocol.

mission cost (TTX) and of the execution overhead(TEXEC) required to perform the needed cryptographicoperations. The transmission cost further consists ofthe network overhead and the serialization one (theSOMA framework employs the Java de/serializationmechanisms to support agent migration), and linearlydepends on agent size. The use of the MH protocol im-poses a slight increase in agent size (and consequently inTTX), and introduces an additional execution overheadTEXEC. The reported results, obtained as an averagemeasure over a large number of tests, show that grant-ing integrity to SOMA applications imposes a limitedand acceptable performance reduction.

4.2 The Interoperability Facility Implementation

Java and CORBA can be seen as two object infras-tructures that complement each other very well. Javadeals with implementation transparency, turning het-erogeneous resources in homogeneous ones through theJVM common software layer. CORBA deals with net-work transparency, by providing the middleware to sup-port C/S distributed applications independent of ob-ject physical location. A platform for universal networkcomputing can be created by using Java as a program-ming language and CORBA as an integration technol-ogy [22].

The CORBA Interface Definition Language (IDL)maps to Java in a simply and intuitive way becauseof the characteristics and the OO nature of the Javalanguage. Moreover, it is possible to achieve portabil-ity across all vendor ORBs†: first of all, the IDL-to-Java standard defines an interface for portable stubsand skeletons, that can be dynamically moved and runwithin any Java ORB that supports the interface; sec-ondly, all vendors have implemented the CORBA 3.0Portable Object Adapter (POA) [23] in their products,overcoming the portability problems of the previousCORBA Basic Object Adapter.

SOMA provides CORBA compliance by means ofthe interoperability facility that is composed by two dis-tinct modules: the first one (CORBA C/S ) simplifiesthe design of SOMA entities as CORBA clients/servers;the second one (MASIFBridge) provides the MASIFfunctionality (see Figs. 4 and 5).

Since MASIF implementation imposes an addi-tional load on the execution place, it is not viable toextend all the SOMA localities with this feature. We

Fig. 5 Places with no/CORBA C/S/full interoperabilityfacility.

have decided that only one place for domain (the de-fault place) should be extended with the MASIFBridgemodule that represents the interoperability access pointtowards other MA systems. On the other hand, theCORBA C/S module is lightweight and many places inthe same domain may use it to access to the CORBAbus, either for calling external services or for registeringas servers.

Any SOMA agent, resident on a CORBA C/Splace, is able to act as a CORBA client/server throughboth static invocation/registration (IDL stub/skeleton)and dynamic ones (DII/DSI). Our implementation,based on the VisiBroker ORB, exploits only theportable functions provided by its POA, for not beingtied to that particular ORB realization.

The MASIF Bridge provides the basic function-ality for agent management and naming (createagent(), fetch class(), receive agent(), get MAF-Finder() methods in the MAFAgentSystem class, andall the methods in the MAFFinder class). We are cur-rently working to integrate the remaining features spec-ified in the MASIF interface in order to achieve thecomplete CORBA compliance. We are also testing theSOMA interoperability with the Grasshopper AgentSystem [24], the unique commercial MA system thathas already implemented the MASIF interface.

From the security point of view, the current SOMAimplementation transfers CORBA requests/replies overa secure transmission channel implemented on VisiBro-ker SSL Pack [25] functionality. On the basis of thisoptional pack of VisiBroker, we have achieved privacyand integrity for CORBA messages, and defined an in-frastructure for X.509 certificate distribution betweennon-SOMA entities. This approach is not an open stan-dard solution, and forces computing entities to a spe-cific proprietary implementation. It is only a temporarysolution, and we are working on the realization of open

†The most diffused Java ORBs, at the moment, are IonaOrbixWeb and Borland VisiBroker for Java.


Table 2 Time performance for SOMA agent migrationthrough MASIF/SOMA.

and portable security services compliant with CORBASSs specifications.

To evaluate the interoperability costs in SOMA,Table 2 compares the average cost of the native migra-tion mechanism with the one imposed by the MASIFinterface. We have carried out the experimental resultsin a SOMA system composed by several domains, andwe have measured the cost for migration between de-fault places of different domains. The measures havebeen taken on an Ethernet LAN of 300-MHz Pentiu-mII PCs with Windows NT. As we expected, MASIFagent migration is more expensive than SOMA propri-etary one, as reported in the Total columns. The Totalcolumns include the initial setup overhead to establish aconnection between previously unconnected places. Forthis reason, any successive migration between the sameplaces achieves better performance, as indicated in thetable. In addition, in the case of MASIF migration, theTotal column includes also the cost to obtain neededreferences to the MAFAgentSystem and MAFFinder fromCORBA and MASIF naming services (as reported inthe phase 1 column).

The results also show that MASIF performance isonly about 10% worse than the SOMA one in the caseof successive migrations for 50 kB-sized agents. Thisis mainly due to the fact that both the VisiBrokerORB and the SOMA framework use the same Javade/serialization mechanisms, and the de/serializationoverhead represents the most relevant factor with theincreasing of agent size. The performance obtainedfor MASIF migration, however, is extremely acceptableand demonstrates the viability of the MASIF approachto interoperability.

5. SOMA Applications: The Network, Sys-tems and Service Management Environ-ment

We have already exploited the SOMA framework todesign, implement and deploy MA-based applicationsin several areas, from network and systems manage-ment (presented in the following) to mobile computingin case of both terminal and user mobility, from adap-tive multimedia distribution with QoS requirements toautonomous retrieval of highly heterogeneous informa-tion for virtual museum services. Additional informa-tion about the SOMA undergoing activity for the real-

ization of distributed applications can be obtained athttp://lia.deis.unibo.it/SOMA/Applications.shtml.

Here, instead, our intention is to sum up our expe-rience in the realization of a network, systems and ser-vice management environment [11], [12] that we haveimplemented upon the SOMA programming frame-work. We have decided to report this experience be-cause management operations particularly stress thecrucial properties of security and interoperability avail-able in SOMA.

Our management environment can help in the au-tomation of management operations: it is capable ofmonitoring the state of the distributed system, of assist-ing and simplifying the dynamic configuration of anynew network component, and of controlling and coor-dinating managed sets of distributed and heterogeneousresources. The MA approach represents an alternativeand flexible solution to the problems of systems man-agement tools, based on traditional protocols, such asSNMP and CMIP, that adopt a C/S model of interac-tion. The SOMA programming framework makes pos-sible to delegate specific controlling actions to agents,that can move autonomously close to the part of thesystem to be managed, exploiting locality and reducingthe message traffic over the network.

The environment already provides a predefined setof agents for systems management and can be easilyextended and tailored to new specific administrationneeds. Any authorized user can dynamically instantiatemanagement agents to perform coordinated tasks eitheron the global scope of her managed system, or on a sub-set of the domains that compose it, or with the granu-larity of a single resource. Agents can autonomouslymonitor both system indicators (e.g. CPU load, filesystem occupation, printers status, available networkbandwidth and collision rate) and application indica-tors (e.g. available services, program versioning, localagent states). They can either trigger agent-performedcorrective operations or alert the administrator whensome even complex threshold conditions are crossed. Inaddition, they can collect management data to reportthe time evolution of specified indicators for off-lineperformance analysis. Agents can obtain the value forsystem indicators both via SNMP interrogation in thecase of SNMP-compliant managed resources, and vialocal interaction with Monitor stationary agents (i.e.objects that permanently execute on a place and exploitplatform-dependent monitor functionality through theJava Native Interface mechanism).

The mobile agents employed in systems manage-ment can be in charge of very sensible operations be-cause agents usually have system duties. The risk of anincorrect action, due to either erroneous or maliciousreasons, is intolerable, therefore the closing propertyshould be considered a key property of managementenvironments. In our environment, the authenticationcheck verifies agent signatures when agents are enter-


Fig. 6 Web-enhanced CORBA access to the configurationGUIs of our SOMA-based management environment.

ing the place, and the authorization phase grants agentsthe right to access local resources according to the rolesof their responsible administrators. To ensure secrecy,management agents can be encrypted when traversingan insecure path. The use of the MH protocol permitsthe detection of any possible violation of agent integrity.

From the interoperability point of view, the man-agement framework is already capable, on the one hand,of requesting external services from CORBA-compliantmanagement tools, based either on SNMP or CMIP.On the other hand, in order to allow the access of au-thorized administrators from a non-SOMA host, ourmanagement tool can also act as a CORBA server.In this way, an administrator can exploit the manage-ment environment also via anywhere available user in-terfaces, such as CORBA-enhanced Web browsers (e.g.Netscape Communicator 4.x, as shown in Fig. 6). Wehave realized user-friendly graphical interfaces to oper-ate directly on the managed resources. For example,Fig. 6 shows how the administrator can control the ini-tial configuration of the system and its modification atrun-time. The administrator is authenticated and is au-thorized to perform different operations, depending onher role. The same interface permits administrators tohandle new roles, to add new places and domains to thesystems, and to provide new resources and behavior.

6. Related Work

Several MA systems have been recently proposed andimplemented, and some surveys on the MA technol-ogy start to appear [3], [26]–[28]. This section tries toidentify the emerging trends in the multiplicity of the

proposals, and, in particular, to examine the differentdirections of solution provided in the security and in-teroperability areas.

The first realized MA platforms supported mobileagents written in a large variety of general-purpose/ad-hoc implementation languages (Ara in Tcl and C/C++,D’Agents in Tcl, Java and Scheme, Tacoma in C/C++,ML, Perl, Python, Scheme and Visual Basic [29]–[31]).A clearly emerging trend in recent MA systems is theuniform choice of Java. Some properties of the Java lan-guage make it particularly suitable to support the MAtechnology. The JVM bytecode is absolutely portable,and can also achieve efficiency due to the enhancementsintroduced by just-in-time compilation [32]. In addi-tion, the Java language simplifies the realization of asecure and interoperable MA framework. The Java 2Platform provides mechanisms and tools for users to de-fine their suitable model of trust. This model of trust isenforced by an embedded Java Security Manager thatcontrols any resource access on the basis of the poli-cies defined by the local administrator. Moreover, thisdefault security manager can be easily refined to dealwith either MA- or application-specific requirements.With regard to interoperability, Java integration withCORBA is facilitated by the package org.omg.CORBA,which is available beginning from Java 2.

From the point of view of security, all the solutionsfor protecting agents/execution sites from malicious in-trusions of agents/execution sites, which are providedin the most diffused MA systems, tend to extensivelyemploy the Java security mechanisms and tools.

The largest part of the research work to protecthosting resources from malicious agents is along the di-rection of extending the Java Security Manager. Voy-ager implements a proprietary security manager [33];Aglets does not allow application developers to subclassits security manager, but permits its dynamic configu-ration via a GUI tool or directly editing policy files[34]; Grasshopper provides customizable policies basedon the identity of the agent and of the group to which itbelongs [24]. SOMA makes available its security man-ager for subclassing and provides role-based policies en-forced at both the domain and the place levels. Agentsare associated with either their launching users or theircode creators or both. In general, user and agent au-thentication mechanisms tends to move toward stan-dards, such as X.509 certificates, in the latest versionsof several platforms (Grasshopper, SOMA). Agent at-tacks, such as denial-of-service, based on malicious con-sumption of host resources, are still difficult to face inan efficient way. The only diffused countermeasuresare to maintain and ascertain the uniqueness of agentidentifiers. Resource managers encapsulate resourcesand are in charge of accounting for resource consump-tion: they are potentially capable of avoiding maliciouscloning and flooding. Not all platforms provide confi-dentiality, integrity and paternity for the transmission


of messages and agents between hosts: aglets use sym-metric cryptography algorithms for domain authenti-cation and message integrity, but provide neither codeencryption nor signing; solutions based on public keycryptography are the most diffused (Grasshopper, Con-cordia [35], SOMA), mainly via the establishment ofan SSL channel from host to host, even if some sys-tems (Concordia, SOMA) consider important the pos-sibility to choose the application-specific proper solu-tion among a variety of available security mechanisms(IDEA, DES, RC4, RC5, Misty or Triple DES sym-metric key encryption mechanisms in Concordia, DES,RSA, DH, DSA in SOMA). The issue of protectingagents from possibly malicious hosting execution sitesis even more difficult to solve, even if some recent worksstart to propose algorithms to protect agent state fromdeletion [15], [17].

From the point of view of interoperability, the re-search interest in the interoperation between heteroge-neous MA platforms and between mobile agents andnon-MA systems is more recent than the one aboutsecurity, and the results achieved suffer from this nov-elty. However, the uniform choice of the Java languagerepresents a milestone that can significantly acceleratethe standardization process toward interoperability. Inaddition, though MASIF standardizes only a little sub-set of the functionality required for inter-working andleaves completely to system designers the responsibilityof how to accommodate incoming foreign agents fromother platforms (possibly written in different languagesand packed with different serialization mechanisms), ithas already achieved a large degree of acceptance andseveral platforms either have worked or are working tobe compliant with it. The FIPA emerging standard hasalso attracted some interest for its possibility of express-ing agent knowledge and behavior in an interoperableway.

Some MA systems, such as Concordia, continues toprovide proprietary non-standard facilities (Concordiabridge) to permit MA-based applications to interoper-ate with legacy services (in the Concordia case, PDAsand smart phones). Other systems consider MASIF butdo not provide yet a fully compliant implementation ofthe standard. The aglets communication API is derivedfrom MASIF, and its default implementation is calledAglets Transfer Protocol, a TCP-based application-level protocol modeled on HTTP. Though aglets use aMASIF-derived interface for the communication layer,which is consequently protocol-independent (ATP, RMIand CORBA IIOP are supported), they do not ex-port it as a CORBA object; therefore, the interfaceis not usable for the inter-working of heterogeneousagents. Other MA platforms provide mobility as an ex-tension to well-assessed architectures for heterogeneousdistributed computing [33], [36]. For instance, Voyageris tightly integrated with distributed processing com-puting via the implementation of a specific ORB mech-

anism (Voyager ORB) that is proprietary, Java-specificand agent-specific. In that way, the integration withtraditional C/S solutions is natural, but close to the ex-ploitation of a proprietary functionality that does notpermit the exchange of heterogeneous agents. On thecontrary, some recent MA systems follow a more openapproach to face the interoperability issue via compli-ance with standards: Grasshopper and SOMA haveadopted and implemented MASIF, while other systemshave announced their intention to become compliant inthe next months. In addition, the last version of theGrasshopper system is the first commercial MA plat-form also compliant with FIPA, which however, prob-ably due to its generality, has not yet achieved the ex-pected interest neither in the industrial nor in the aca-demic MA research.

7. Conclusions

The MA technology is raising increasing interest andseems to be an elegant and uniform solution to awide spectrum of application areas, from network andsystems management to mobile computing, from dis-tributed information retrieval to electronic commerce.Many MA systems already exist, but the major limit totheir use in real complex applications for the Internetstems from their lack of security and interoperability.

SOMA has been designed to provide an inte-grated approach to security: we have implementedmechanisms to protect local resources from maliciousagents, agents from untrusted hosts, and communica-tion among SOMA entities; our role-based policies canflexibly adapt to different contexts in order to obtain asuitable balancing between security and performances.

Interoperability among different MA systemsseems the other missing element to leverage the growthof MA applications industry. SOMA faces the issue ofCORBA compliance, carefully taking into account itscost in terms of the added system overhead. SOMAagents can play the role of CORBA clients/servers; oneplace for domain, at least, publishes the MASIF inter-face to the CORBA ORB, thus permitting the full inter-operability with other external and authorized CORBAsystems, either MA-based or not.

SOMA makes available a large variety of mecha-nisms, policies and tools to achieve flexibly proper lev-els of security and interoperability. These propertiesmake our programming framework particularly suitablefor the design, implementation and deployment of dis-tributed services in several application domains, suchas mobile computing, multimedia distribution and au-tonomous retrieval of museum information. In particu-lar, we have extensively worked in the network, systemsand service management area, where agents fulfill theadministration needs by moving and autonomously ex-ecuting on the managed nodes.


References

[1] A. Fuggetta, G.P. Picco, and G. Vigna, “Understandingcode mobility,” IEEE Trans. Software Eng., vol.24, no.5,May 1998.

[2] J.W. Stamos and D.K. Gifford, “Remote evaluation,” ACMTrans. Prog. Lang. and Syst., vol.12, no.4, Oct. 1990.

[3] K. Rothermel and F. Hohl, ed., Moblie Agents, Proc. 2ndInternational Workshop on Mobile Agents, Springer-Verlag,Lecture Notes in Computer Science, vol.1477, Sept. 1998.

[4] J. Vitek and C. Tschudin, “Mobile object systems towardsthe programmable internet,” Lecture Notes in ComputerScience, no.1222, Springer-Verlag, April 1997.

[5] Object Management Group, CORBA/IIOP Rev 2.2, OMGDocument formal/98-07-01, http://www.omg.org/corba/corbaiiop, Feb. 1998.

[6] GMD FOKUS, and IBM Corp, “Mobile Agent FacilitySpecification,” Joint Submission supported by CrystalizInc., General Magic Inc., the Open Group, OMG TC Docu-ment orbos/97-10-05, ftp://ftp.omg.org/docs/orbos/97-10-05.pdf, 1998.

[7] W. Stallings, Network and Internetwork Security: Principleand Practice, Prentice Hall, 1995.

[8] G. Vigna, ed., “Mobile agents and security,” Lecture Notesin Computer Science, vol.1419, Springer-Verlag, 1998.

[9] T. Sander and C. Tschudin, “Protecting mobile agentsagainst malicious hosts,” in [7].

[10] Foundation for Intelligent Physical Agents—FIPA’99 ver-sion 0.2, http://www.fipa.org/spec/fipa99spec0.2.htm.

[11] P. Bellavista, A. Corradi, and C. Stefanelli, “An open se-cure mobile agent framework for systems management,” J.Network and Systems Management, vol.7, no.3, Sept. 1999.

[12] P. Bellavista, A. Corradi, C. Stefanelli, and F. Tarantino,Mobile Agents for Web-based Systems Management, Inter-net Research, vol.9, no.5, Nov. 1999.

[13] F.M. Assis-Silva and R.Popescu-Zeletin, “An approach forproviding mobile agent fault tolerance,” in [3].

[14] A. Corradi, M. Cremonini, and C. Stefanelli, “Securitymodels and abstractions in a mobile agent environment,”WETICE98 Workshop on Collaboration in Presence of Mo-bility, Stanford, USA, June 1998.

[15] B. Yee, “A sanctuary for mobile agents,” Proc. DARPAWorkshop on Foundations for Secure Mobile Code, March1997.

[16] E. Lupu and M. Sloman, “A policy based role objectmodel,” Proc. EDOC’97, IEEE, Oct. 1997.

[17] M. Cremonini, A. Corradi, R. Montanari, and C. Stefanelli,“Mobile agents and security: Protocols for integrity,” 2ndIFIP Int. Working Conference on Distributed Applicationsand Interoperable Systems (DAIS’99), Helsinki, June 1999.

[18] Microsoft—DCOM, http://www.microsoft.com/com/tech/DCOM.asp

[19] Object Management Group, CORBA Security Services,OMG Document formal/98-12-17, http://www.omg.org/cgi-bin/doc?formal/98-12-17, Dec. 1998.

[20] D. Flanagan, Java Power Reference, O’Reilly & Associates,March 1999.

[21] Institute for Applied Information Processing and Commu-nications—iSaSiLk 3.0, http://jcewww.iaik.at/iSaSiLk/.

[22] S.M. Lewandowski, “Frameworks for component-basedclient/server computing,” ACM Computing Surveys,vol.30, no.1, March 1998.

[23] Object Management Group, The Portable Object Adapter,OMGDocument formal 99-07-15, http://www.omg.org/cgi-bin/doc?formal/99-07-15, July 1999.

[24] IKV++-GrassHopper, http://www.ikv.de/products/ grass-

hopper/[25] Borland—VisiBroker for Java, http://www.borland.com/

visibroker/[26] M.K. Perdikeas, F.G. Chatzipapadopoulos, I.S. Venieris,

and G. Marino, “Mobile agent standards and available plat-forms,” Computer Networks, vol.31, pp.1999–2016, Sept.1999.

[27] N.M. Karnik and A.R. Tripathi, “Design issues in mobile-agent programming systems,” IEEE Concurrency, vol.6,no.3, Sept. 1998.

[28] V.A. Pham and A. Karmouch, “Mobile software agents: Anoverview,” IEEE Commun., vol.36, no.7, July 1998.

[29] H. Peine, “Security concepts and implementations for theara mobile agent system,” Proc. 7th IEEE Workshop onEnabling Technologies: Infrastructure for the CollaborativeEnterprises, USA, June 1998.

[30] R.S. Gray, D. Kotz, G. Cybenko, and D. Rus, “D’Agents:Security in a multiple-language, mobile-agent system,” in[6].

[31] D. Johansen, F.B. Schneider, and R. van Renesse, “WhatTACOMA taught us,” in Mobility, Mobile Agents and Pro-cess Migration—An Edited Collection, eds. D. Milojicic,F. Douglis, and R. Wheeler, Addison Wesley, 1998.

[32] Sun Microsystems—Java HotSpot, http://java.sun.com/products/hotspot/

[33] ObjectSpace—Voyager, http://www.objectspace.com/vo-yager/

[34] D.B. Lange and M. Oshima, Programming and DeployingJava Mobile Agents with Aglets, Addison Wesley, 1998.

[35] Mitsubishi Electric—Concordia, http://www.concordia.mea.com/

[36] Ad Astra Engineering—Jumping Beans, http://www.jumpingbeans.com

Paolo Bellavista received his Lau-rea in electronic engineering from Univer-sity of Bologna, Italy, in 1997. He is cur-rently pursuing a Ph.D. in computer sci-ence engineering at the Dept. Electron-ics Computer Science and Systems of thesame university. His research interests in-clude distributed computing, distributedobjects, mobile agents, network and sys-tems management, adaptive multimediasystems, and distance learning. He is a

student member of the IEEE, ACM and AICA (Italian Associa-tion for Computing).


Antonio Corradi received his Laureain electronic engineering from the Univer-sity of Bologna, Italy, in 1979, and his MSin electrical engineering from Cornell Uni-versity in 1981. He is currently an asso-ciate professor of computer science at theUniversity of Bologna. His scientific in-terests include distributed systems, objectand agent systems, network management,and distributed and parallel architectures.He is a member of the IEEE, ACM and

AICA.

Cesare Stefanelli received his Lau-rea in electronic engineering from the Uni-versity of Bologna, Italy, in 1992 andthe Ph.D. degree in computer science in1996. He is currently an associate profes-sor of operating systems at the Universityof Ferrara. His research interests includedistributed and mobile computing, mobilecode, network and systems management,network security. He is a member of theIEEE and AICA.

protection and interoperability for mobile agents: a secure and open programming environment

Documents