A Secure ModularMobile Agent System

Adam Pridgen and Christine JulienThe Center for Excellence in Distributed Global Environments

The Department of Electrical and Computer EngineeringThe University of Texas at Austin

{atpridgen, c.julien}@mail.utexas.edu

ABSTRACTApplications in mobile multi-agent systems require a highdegree of confidence that code that runs inside the systemwill not be malicious and that any agents which are mali-cious can be identified and contained. Since the inception ofmobile agents, this threat has been addressed using a multi-tude of techniques, but many of these implementations haveonly addressed concerns from the position of either the plat-form or the agent, and very few approaches have undertakenthe problem of mobile agent security from both perspectivessimultaneously. Furthermore, no middleware exists that fa-cilitates provision of the required security qualities of mobileagent software while extensively focusing on easing the soft-ware development burden. In this paper, we introduce amobile agent system that enhances security functionality byintegrating core software and hardware assurance qualities,as well as addressing security concerns from the perspectivesof both the platform and the agent.

Categories and Subject DescriptorsD.2.2 [Design Tools and Techniques]: [Computer-aidedsoftware engineering]; K.5 [Security and Protection]: [Au-thentication; Unauthorized access (e.g., hacking, phreak-ing)]; K.6.3 [Software Management]: [Software develop-ment]

General TermsDesign, Security, Standardization

KeywordsMobile Agents

1. INTRODUCTIONMobile agent systems and applications are becoming

highly prominent for tasks such as information sharing, anal-ysis, evaluation, and response. Before these systems fulfill

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SELMAS’06, May 22–23, 2006, Shanghai, China.Copyright 2006 ACM 1-59593-085-X/06/0005 ...$5.00.

their promise, they must overcome the challenging obsta-cles of effective software development and security [12]. Ingeneral, agents are regarded as highly autonomous processeswhich can perform tasks ranging from simple queries to com-plex computations. In all cases, a major component of amobile agent system is the platform that hosts the agents.

Motivating applications for mobile agents range acrossmany domains, and the benefit of using mobile agents canfar outweigh traditional approaches. In epidemic updates,agents carry firmware upgrades to remote clients by intel-ligently propagating through a network. As computer sys-tems become increasingly pervasive, an effective means forpropagating updates to these systems will be required, es-pecially when physical contact with a device is infeasible.Epidemic updates also provide relief to manufacturers whorequire their vehicles to upgrade to a new firmware ver-sion without initiating a massive recall. A dealership couldstrategically deploy updates on a few vehicles, and, whenvehicles stop in public areas such as a market, the updatecan spread to nearby systems to which it applies.

Another distributed information application that couldbenefit from secure mobile agents focuses on collecting andcomparing events in a distributed surveillance sensor net-work. In this system, agents can be utilized to help monitorarrays of many sensors like cameras, acoustics, and pressuresensors. Furthermore, these systems could be integratedlook for elaborate acts of sabotage. The network monitoringagents could even be leveraged as a channel for comparingnetwork-wide events among different organizations withoutdisclosing sensitive or proprietary data.

As mobile agent deployments become more prominent andsophisticated, programming mobile agent components andapplications needs to be simplified. A modular mobile agentplatform could help capture this desired flexibility for easyintegration, but the system must also incorporate trustedcomputing functions and must facilitate the integration offuture technologies. A simple middleware that permits do-main programmers to develop these components and allowsexpert programmers to extend the system is essential. Sincemobile agents and their respective applications have a signif-icant degree of variance, strategies such as cross-layer designshould be employed in many situations.

In this paper, we introduce the Secure Modular Mo-bile Agent System.H (SMASH), which provides modular-ity for agent and platform components, information assur-ances, and mechanisms to assist mobile agents as they movebetween platforms. SMASH is also designed to addresscontext-based agent execution and security, enable coordi-

67

nation among agents and platforms, and, overall, improveprogrammablity, security, and extensibility for highly ver-satile mobile agent applications. SMASH seeks to allow awider range of authentication methods, rather than restrictagent authentication to code signing as employed in Java-based approaches. To support unpredictable travel patterns,SMASH supports strict authorization and resource controlmeasures yet eliminates the burden of excessive authentica-tion for transient agents as they move to their destinations.

The rest of this paper is organized as follows. Section 2reviews previous research Section 3 provides an overviewof our architecture. Details about implementation and theprogramming interface will be further discussed in Section 4.Future work is in Section 5, and Section 6 concludes.

2. RELATED WORKInformation assurance for mobile agents is a daunting task

because security threats arise from agents attacking otheragents or platforms and from platforms attacking agents.The ultimate challenge is to manage trust between compo-nents of the agent system. Providing middleware for suchsystems is non-trivial because it must forecast and abstractimplications which may arise in the various roles and actionsof remote agents and platforms. Issues such as software ex-ceptions, resource availability, etc., can open subtle holes forexploitation or even cause a system to fail.

In the area of software assurance, a number of projectshave increased the probability of dynamically detecting dataor code tampering. One such framework [6] re-arranges codeat compile time to obtain a unique binary and then embedsa unique watermark created from standard encryption al-gorithms. This dramatically suppresses the ability of anadversary to manipulate any portion of the code and canalso be useful in maintaining a light-weight agent.

Page et. al. [11], explore a method in which each agentperforms a randomly periodic self-examination to ensureno modifications have been made while the agent was ex-ecuting. Other methods use reference states [5], state ap-praisals [3], and even agent execution traces [18]. Thesemethods can add weight to the agent code and payload,require a priori knowledge or consistent connectedness ofplatforms for verification, and, under some circumstances,data appended to the agent can be forged.

Most mobile agent systems have been built on Java orvarying scripting languages. Projects using Java utilizethe JVM’s Security Manager, but this management sys-tem can be intractable due to an excessive number of secu-rity policies and unscalable as mobile agent systems becomemore complex. On the flip side, Java offers more robust,object-oriented programming, an elaborate API library, andportable code. Mobile agent systems implemented in script-ing languages are also portable and have stronger mobility,but they do not provide extensive security management andthey tend not to be as object-oriented.

There are a number of middleware projects for secure mo-bile agents, and we sample only a small fraction of themhere. MARS [1] explicitly separates the data an agent canaccess from the host’s file system through a novel coordina-tion approach, but this reduces flexibility and requires sig-nificant a priori knowledge to populate the agent accessibledata space. In addition, MARS is dramatically limited inthe granularity of access control it can provide. Nomads [15]implements many promising features such as fine-grained ac-

cess control, strong mobility, and flexible execution profilesbased on application and context; however, Nomad agentsrun in a custom execution environment that dramaticallyreduces the code portability of the agents. D’Agents [4] sup-ports multiple agent implementation languages and also dif-ferentiates anonymous and authenticated agents. Aglets [8]are applet agents based on Javascript. They provide con-ditional access rights and moderate access control based onaglet “identity.”

Ajanta [9] is another mobile agent system built on Javathat implements extensive access control measures ratherthan relying entirely on Java’s Security Manager. Ajantasuffers due to Java’s constrained policy system. Ajantaintroduces containers for appending read-only data and astronger security manager that controls access to resourcesby requiring agents to set-up resource proxies that accessresources through the manager as established by the plat-form’s policies. In an effort to make agents lightweight, eachagent carries an address for a trusted code server from whichit can dynamically load supplemental Java classes.

Java has been a very important tool in the mobile agentcommunity. Java’s portability, type safety, automated mem-ory management, serialization, and built-in security man-agement have made it the language of choice for many de-velopers. However, for the purposes of strict informationassurance, Java has fundamental inadequacies. For exam-ple, the JVM is not intended as a multi-user execution en-vironment, so a Java-based mobile agent system has limitedability to govern all resources of agents and threads [10].A second issue with Java-based systems is that they weremeant typically for on-platform management in which anagent derives its platform access rights from those estab-lished locally on the platform. There is no method for theplatform to dynamically check access policies within a localdomain. Also, because access controls are issued per do-main, either each visiting agent must have its own domainor agents must share domain privileges. The former is un-scalable and unfriendly to open systems. The latter neglectsThe Principle of Least Privilege allowing dissimilar agentsto have the same permissions even when those privileges areunnecessary [14]. Additionally, Java cannot authorize accessbased on a particular task or goal, dramatically restrictingthe potential for context-based authorization and privileges.

SMASH strives to enhance the software engineering ofmobile agents by introducing a modular and adaptable sys-tem, so application developers can quickly customize mobileagents and platforms to their needed specifications and se-curity requirements. SMASH emphasizes security by designbut provides modularity so future application designers donot need to design around the architecture, but rather de-sign for their application.

3. SMASH: AN OVERVIEWIn this section we introduce our middleware, the Secure

Modular Mobile Agent System.H (SMASH), which facil-itates openness, security, and modularity in mobile agentsystems. SMASH fosters openness by allowing anonymousmobile agents to move freely through platforms while stillcoordinating with other agents. Additionally, SMASH en-ables coordination among these anonymous entities. Secu-rity is provided for more robust agents by integrating hard-ware and software assurance methods to prevent tampering,enhance authentication, and to authorize agents and plat-

68

Figure 1: Depiction of a Mobile Agent in SMASH

forms through traditional and contextual means. SMASH’score design principle is modularity, which improves mobil-ity, eases the programming effort, and allows customization.Thus, SMASH focuses on adapting the system to an appli-cation not an application to the system.

3.1 SMASH Agents and FunctionalityTo adhere to an open architecture, SMASH supports two

types of agents, anonymous and authenticated agents, in amanner similar to [4]. An anonymous agent is simply onethat has not authenticated with the platform. When anagent is unauthenticated, its functionality on the platformis restrained. Such an agent may access only designatedread-only data, read and write to a Blackboard, performsimple computations, or leave. This anonymous classifica-tion allows agents to move through intermediate platformswithout having to authenticate with each of them, whichcan improve performance and reduce the latency caused byunnecessary authentication. An authenticated agent, on theother hand, is one that has sufficiently proven its identity tothe platform. An agent’s identity refers to with whom theagent is associated (e.g. user, group, platform, etc.). Oncean agent’s identity is verified, it is awarded rights based onthat identity and/or the context of its task(s).

Figure 1 represents the components of a SMASH agent.All agents are composed of modules, which are simply de-fined architectural types, methods, and functions of the mo-bile agent. SMASH agents contain an immutable main mod-ule shown at the top of the figure. This main module com-prises the following submodules: an agenda, code, creden-tials, application data, itinerary, and a time-to-live. Theagent’s agenda contains the agent’s goals, described in moredetail in Figure 2, which shows the goal definition for anagent performing a firmware upgrade. This agenda can alsobe used a dossier or condition upon which the agent is ad-mitted to the platform, and if the agent violates the agendaconstraints, the agent can be removed from platform.

There are at least three required fields for any goal: the

<Goal><Task>

<Upgrade><attribute>

Description = "Upgrade Firmware"</attribute><type=Firmware>

<attribute> Version = "3.0 Beta" </attribute><attribute> PreviousVersion = "2.99" </attribute><attribute> SystemArch=any </attribute><attribute> ApplyAt="12:00a" </attribute><attribute> EstimatedTime="3 minutes" </attribute>

</Firmware></Upgrade>

<Task><Resources>

<Internal><attribute> UpgradeData = "./Firmware3.bz2"</attribute>

</Internal><Network>

<attribute> BandwidthRate = 10Kb </attribute><attribute> BandwidthUsage = 5MB </attribute><attribute> PortUsed = 80 </attribute><attribute> PortHandle = "NHandle" </attribute>

<attribute> RemoteHost = "foo.bar.org" </attribute></Network><WorkingDirectory>

<attribute> Directory = "" </attribute><attribute> FileAccessRights = "rwx" </attribute><attribute> DirectoryHandle = "FHandle" </attribute>

</WorkingDirectory></Resources><AuthorizationRequirements>

<attribute> User = "operator" </attribute><attribute> Directory = "/usr/bin" </attribute><attribute> FileAccessRights = "rw" </attribute>

</AuthorizationRequirements></Goal>

Figure 2: Model of an Update Goal

Task, Resources, and AuthorizationRequirements. TheTask is functionality of the specified goal, and the Resourceslist what resources the agent needs to use to complete thetask, which may consist of system resources, remote re-sources or data, and even external functions. Finally, theAuthorizationRequirements provide a recommended set ofprivileges to accomplish the task; however the final decisionabout the privileges is left to the platform. The code is theexecutable portion of the agent, and the application datacontains static data accessed during the agent’s execution.

The itinerary submodule contains the agent’s travel planand designates the platforms the agent plans to visit. Anitinerary includes several components associated with eachtarget platform. First, if the agent intends to use privi-leged services, the itinerary includes a checksum of the ex-pected software the platform should be running. Second,the itinerary also includes information unique to each plat-form, so the agent can authenticate with it. Finally, theitinerary designates whether the agent will allow a particu-lar platform to refer it to another trusted platform. A refer-ral occurs if a platform does not have a resource, but knowsof another platform with the agent’s required resources. Ifthe agent accepts referrals, then the agent will go to the re-ferred platform and honor the trust relationship between theplatforms; this relies on a third party authentication servicethat enables the agent and platform to verify each other’sidentity.

69

Figure 3: SMASH Platform Architecture

The final submodule in the agent’s main module con-tains the agent’s credentials. This component provides atamper detector comprising a public key, a signature, andthe agent’s prescribed authentication methods, authentica-tion submodules, which describe how an agent can authen-ticate with platforms it encounters. Each authenticationsub-module contains the information necessary to completethe prescribed authentication method. The platform mustsupport at least one of an agent’s prescribed methods, orthe two will not be able to mutually authenticate.

The tamper detector protects all sub-modules within themain module. When the agent is completely assembled andprepared for dispatch, the creating entity will select a privatekey to use to sign the agent. Before signing the main module,the creator will place the public key into the credentials andidentify the asymmetric algorithm being used. The agentthen signs the main module using the selected private key.

In addition, an agent may contain an additional dynamicmodule, shown in the lower portion of the agent in Figure 1.This module stores vital state and process data with a highdegree of confidence as the agent moves from platform toplatform. The execution state includes information aboutthe variables in memory and the instruction where the agentleft off on the previous platform. The data refers to any com-putation results, accumulation of logs, etc., that the agentgenerates throughout its tasks and wishes to maintain. Aneffort is made to protect this data from tampering using adigest. Before departing a platform, the agent creates a hashof the execution state and application data (using a functionlike MD-5) and passes this hash to the platform. The plat-form signs the combination of the hash and the platform’spublic key. The agent receives the signed hash and the pub-lic key from the platform, which it stores as a digest andthe digest public key. When the agent initializes on a newplatform, it verifies the data and state information using thereverse process. The public key is also matched against thepublic key of the previous platform in the agent’s itinerary.If a the key cannot be found or the digest is wrong, the agentwill self-destruct.

3.2 SMASH Platform and FunctionalityLike SMASH agents, the host platform is engineered to

provide support for an open architecture, extensibility, andvarious levels of security. As shown in Figure 3, we usea layered approach to compartmentalize our architecture’s

functionality and to prevent an outbreak of malicious activ-ity. At the lowest level of the architecture, the operatingsystem handles issues like communication, system level ac-cess controls, etc. When an agent arrives at the platform, anintegrity check is administered, and, upon successful comple-tion, the agent is moved to the Untrusted Layer. The agentthen moves through the Authentication and AuthorizationLayer, where the agent and platform mutually authenticateto become a trusted entity. After successful authenticationand authorization, the agent is placed into the Trusted Con-tainment Zone (TCZ). From here up, the agent will interactdirectly with the Security Manager to obtain the requiredresources and be executed. Within the Security Manager,the Task Manager determines if the platform can provideuseful services to the agent (based on the agent’s goals),and the Resource Manager sets-up proxies so the agent canaccess resources external to the execution environment. TheAgent Manager tracks all agents on the platform.

SMASH’s final components, shown to the right in Fig-ure 3, represent publicly accessible platform resources. TheBlackboard is a memory-constrained FIFO queue that isavailable to any agent (authenticated or anonymous) forread-write access. Agents can use this space to coordinatetasks. Since agents are kept completely isolated, this is oneof two ways that they may interact with each other; theother method will be discussed later. This data space alsoallows agents to mark a platform as visited. The platformalso has the ability to make other parts of memory publicand read-only (similar to a glass-enclosed bulletin board).

Figure 4 shows the entire process of admitting an agentto a platform. When an agent first arrives at the platform,the agent and platform perform initial integrity checks. Theplatform will use the tamper detector located in the agent’scredentials discussed earlier. The agent queries a specialhardware chip that provides the agent with a checksum ofthe currently running system software. The agent comparesthe hardware module’s result with the one stored in theagent’s itinerary. If they match, the platform’s check haspassed and the agent will register with the Agent Man-ager (AM) as an anonymous agent and proceed to the Un-trusted Containment Zone (UCZ).

The agent receives few privileges in the UCZ. Here theagent has limited processing power, may read and writeto the platform’s Blackboard, may access to the platform’sread-only memory, or may leave the platform. The agentmay also piggyback on the platform to get to some physi-cal location. When the agent is registered with the AgentManager (AM), it is scheduled to receive minimal processingtime in a low-priority queue. The AM also monitors agents,and, if they die unexpectedly, removes them from the UCZ.If an agent simply needs to obtain some public data from theplatform, it can use its processing time to query and thenleave. On the other hand an agent may also use this pro-cessing time to inform the AM that it wishes to authenticatewith the platform.

After the agent signals the AM that it wishes to authenti-cate, the AM moves the agent into the Authentication andAuthorization Layer (AAL). In the AAL, the agent and theplatform mutually authenticate each other. The platformqueries the agent about how it can authenticate, and theagent does the same for the platform. If the two possesssome method of authentication in common, then they canmutually authenticate. If this is not the case the agent is

70

Figure 4: Decision Tree Used by the SMASH Platform.

removed from the AAL and flagged in the AM, meaning itcan no longer attempt to authenticate. If mutual authenti-cation succeeds, an authorization service is launched. Theauthorization service will look locally, to a remote server,and even employ another mobile agent service [13] to grantthe agent access privileges. The authorization source isplatform-dependent, but it must establish whether the agentcan use the platform, at what privilege level, and which re-sources should be accessible. The agent can leverage thesame services to authorize the platform to ensure no revo-cations have taken place since it was dispatched. Once theseauthorizations complete, the status of the agent is updatedto authenticated in AM, and the agent is moved into theTrusted Containment Zone (TCZ).

After the agent is given an initial set of privileges, itpasses its agenda to the Security Manager (SM). From here,the agent will interact only with the SM. The SM passesthe agenda to the Task Manager (TM), which analyzes theagenda, the agent’s privileges, and which of the agent’s tasksare currently permissible. If the TM sees a possible match,(i.e., some task is permissible and requires equal or less ac-cess than the agent’s currently assigned privileges), the TMpasses the agent’s requested resource list to the ResourceManager (RM), which locates the desired resources and ini-tiates proxies for the agent to use to access those resources.The RM adheres to the order in which resources are re-quired, if the agent provides such information. This expe-dites the agent’s execution, reduces idle time, and helps re-lease resources in a timely manner for other agents runningon the platform.

When the necessary resources become available, the agentis moved into the Agent Staging Area (ASA), and the sta-tus of the agent is updated in the AM. In the ASA, theagent’s Bootstrap Code (BC) is identified and loaded intothe staging area. The BC first goes through all of the agent’smodules to ensure no tampering or corruption has occurredin the agent’s immutable sections. The BC then loads theagent into memory. The agent checks all execution envi-ronment parameters such as handles and variables and ini-tializes them appropriately for this platform. This allowsan agent to resume execution at the point it previously leftoff. If any failure occurs, the BC aborts, and the agentself-destructs or returns home. Finally, the BC updates theagents status with the AM to executing.

While the agent executes, the SM monitors the agent forany deviant behavior like excessive bandwidth usage or at-tempts to access restricted resources. Depending on theseverity of the violation, the SM can restrict or kill theagent, or force the agent to leave. When the agent’s ex-ecution ends, the BC moves the agent back to the agentstaging area. Here, the BC checks the agent’s integrity andinventories the modules. The BC will obtain a digital sig-nature for the data and execution state (the digest). Afterthe BC completes the clean-up, it will signal to the AM itsintention to leave.

4. SMASH INTERNALSSMASH eases programming of secure mobile agent appli-

cations by providing a modular and extensible frameworkfor anonymous and authenticated agents. SMASH also pro-

71

vides the support necessary for these agents to authenticateand validate the platforms they visit and vice versa.

4.1 SMASH Implementation DetailsIn this section, we explore aspects of the implementation

details of the SMASH middleware. To enable several aspectsof tamper detection in SMASH, our implementation utilizesSecurity Enhanced Linux (SELinux [16]) which is a Linuxkernel modified and partly maintained by the National Secu-rity Agency. SELinux, which can be ported to some mobiledevices [2], enables granular access controls and provides apowerful but securable multi-user environment. In addition,we require each platform to incorporate a Trusted PlatformModule (TPM), a hardware chip specified by the TrustedComputing Group [17]. In combination, this hardware andoperating system enable our implementation of the securityand trust mechanisms outlined in the previous section. Sincethe mobile agents run within SMASH, this condition helpsto promote security by way of a sandbox like environment,which is not achievable using just system libraries.

As described in Section 2, we avoid using the Java pro-gramming language for creating agent systems due to itsmany restrictions in securing application interactions. In-stead, our middleware platform is implemented using C++.On top of this, we use Python to provide a more flexible andeasy-to-use programming interface to the application devel-oper, as well as the agent’s execution environment. Thenext section describes this interface in a bit more detail.Python is a powerful object-oriented language whose fea-tures make it attractive for rapid application development.Admittedly, C++ lacks in areas like typesafety and memorymanagement, but we intend to use C++ to implement ourplatform, which is eases the interfacing with the SELinuxoperating system and services, making many of the subtleaspects of the system described in Section 3 possible. Fi-nally, SMASH assumes network communication to be han-dled by the operating system, and the middleware simplyhandles agent movement between platforms at the applica-tion level.

4.2 SMASH Application DetailsBecause our goal is to simplify the process of programming

secure mobile agents, SMASH provides much of the agent’sreusable functionality within the middleware. The program-ming interface through which developers create SMASHagents is presented in Python, an intuitive object-orientedlanguage. Specifically, the middleware provides an agentbase class (agent) that any application agent must derive.This base class contains an init method to which thederiving agent can provide the aspects of the main mod-ule depicted in Figure 1. Each of these submodules exceptthe agent’s code (i.e., the agenda, the itinerary, the creden-tials, the creator key, the TTL, and the application data)are represented by additional Python classes in the SMASHmiddleware that the developer can instantiate. Ultimately,when an application developer’s agent is created, its init

method is invoked, and, within this method, the submod-ule components are either received as parameters or cre-ated, and the method agent. init ( ...) is called withthe submodule components as parameters. This successfullyinitializes an agent.

One thing worth noting about this organization of the pro-gramming interface is the ease with which the submodules

can be initialized. Take as an example the XML-style defi-nition of goals (shown in Figure 2). To initialize its agenda,the agent needs only to pass the XML file(s) defining theagenda to the Python agenda class, and the mechanics forparsing and properly storing the details of the goals areimplemented within the middleware. The agent’s itinerary(which includes not only the ids of the target platforms butalso keys and other cryptographic information used for agentadmission) is also defined via a standard XML format thatcan be automatically processed by the middleware. Similarstandard approaches for representing the other submodulesare used; details are omitted here for brevity.

SMASH is engineered to provide both strong and weakmobility. As such, the agent base class in the middlewarecontains two methods; an agent overrides one or the otherdepending on whether it desires strong or weak mobility.In addition, the deriving agent sets a flag in the base classindicating its selection. The two methods, strong run andweak run have no functionality defined in the base class, butin the former case, when the derived agent decides it is timeto move to a new platform, the exact execution state is savedand later restored on the new platform. This means that theagent actually records how much processing has occurredand restarts itself on the new platform in exactly that loca-tion. In the case of weak mobility, when the agent moves,its weak run method simply restarts from the beginning. Tomove, a derived agent calls the move method in the agent

base class, which first determines which mobility methodis being used and (if necessary) saves the agent’s executionstate. Then the move method hooks into the remainder ofthe middleware to find the next platform in the itineraryand move there. Functionality implemented within the mid-dleware handles the admission of the agent as described inSection 3, and eventually, if all checks pass successfully, thePython derived agent class is restarted.

5. FUTURE WORKThe SMASH middleware infrastructure as described in

Section 4 is currently under development. Future work willsee the completion of the middleware as described here andthe development of several agent-based applications usingthe middleware to demonstrate not only the range of secu-rity concerns the middleware covers but also the range ofapplication domains in which it can be applied. This evalu-ation will be an important point in the process of SMASHdevelopment because we hope to gain insight into the lan-guages and representations we have chosen for modules andsubmodules (e.g., the representation of the agent’s tasks andresources using XML).

At the model level, SMASH currently incorporates con-text information into security decisions by accounting foran agent’s intended tasks and requested resources. In thefuture, we plan to extend this framework to incorporatethe use of more context information into security processes.This work will build on our previous work in construct-ing context-sensitive access controls [7]. We envision thatcontext information such as the other agents present on ahost, available resources, network connectivity, and qualityof service will be able to positively influence agents’ andplatforms’ admission and authorization decisions to provideefficient behavior to the platforms and the best possible levelof service to the mobile agents.

72

6. CONCLUSIONIn this paper, we have presented SMASH, a secure mo-

bile agent middleware that builds on past research effortsto create a secure, open, and modular mobile agent systemthat can be used to experiment and develop robust appli-cations. SMASH embraces openess by directly consideringagents’ goals and requests in the security process, allowinganonymous agents to move freely through intermediary plat-forms onto their final destinations, and providing a meansfor agents to coordinate or compute without being authen-ticated to a platfrom. Security is provided by integratinghardware and software techniques to protect, detect, andidentify tampering, and to a high degree, provide increasedflexibility with respect to agent authentication and autho-rization. Finally, SMASH’s design modularity enhances theextensibility of mobile agent applications, eases the devel-opment burden associated with mobile agent systems, andempowers developers with tools to create a new generationof mobile agent applications.

7. REFERENCES[1] G. Cabri, L. Leonardi, and F. Zambonelli. MARS: A

Programmable Coordination Architecture for MobileAgents. IEEE Internet Computing, 4(4):26–35, 2000.

[2] R. Coker. Porting NSA Security Enhanced Linux toHand-held Devices. In Proceedings of the LinuxSymposium, 2003.

[3] W. Farmer, J. Guttman, and V. Swarup. Security forMobile Agents: Authentication and State Appraisal.In Proc. of the 4th European Symp. on Research inComputer Security, pages 118–130, Springer-Verlag,September 1996.

[4] R. S. Gray, D. Kotz, G. Cybenko, and D. Rus.D’Agents: Security in a Multiple-Language,Mobile-Agent System. In Mobile Agents and Security,pages 154–187, London, UK, 1998. Springer-Verlag.

[5] F. Hohl. A Framework to Protect Mobile Agents byUsing Reference States. Proc. of the 20th IEEE Int’l.Conf. on Distributed Computing Systems, pages410–419, 2000.

[6] M. Jochen, L. Marvel, and L. Pollock. A Frameworkfor Tamper Detection Marking of Mobile Applications.In Proc. of the 14th Int’l. Symp. on SoftwareReliability Engineering, pages 143–152, 2003.

[7] C. Julien, J. Payton, and G.-C. Roman. AdaptiveAccess Control in Coordination-Based Mobile AgentSystems. In Software Engineering for Large-ScaleMulti-Agent Systems III, volume 3390 of LNCS, pages254–271, February 2005.

[8] G. Karjoth, D. B. Lange, and M. Oshima. A SecurityModel for Aglets. IEEE Internet Computing,1(4):68–77, 1997.

[9] N. M. Karnik and A. R. Tripathi. Security in theAjanta mobile agent system. Software—Practice andExperience, 31(4):301–329, 2001.

[10] P. Marques, N. Santos, L. Silva, and J. G. Silva. TheSecurity Architecture of the M&M Mobile AgentFramework. In Proc. of the SPIE’s Int’l. Symp. onThe Convergence of Information Technologies andCommunications, 2001.

[11] J. Page, A. Zaslavsky, and M. Indrawan. CounteringSecurity Vulnerabilities in Agent Execution Using a

Self Executing Security Examination. Proc. of the 3rd

Int’l Joint Conf. on Autonomous Agents andMultiagent Systems, pages 1486–1487, 2004.

[12] V. Roth. Obstacles to the Adoption of Mobile Agents.In Proc. of the IEEE Int’l. Conf. on Mobile DataManagement, pages 296–297, January 2004.

[13] A. Seleznyov, M. O. Ahmed, and S. Hailes.Agent-based Middleware Architecture for DistributedAccess Control. In Proc. of the 22nd Int’l. Multi-Conf.on Applied Informatics: Artificial Intelligence andApplications, pages 200–205, 2004.

[14] Sun Microsystems. The Java 2 Platform.http://java.sun.com/j2se, January 2006.

[15] N. Suri, J. M. Bradshaw, M. R. Breedy, P. T. Groth,G. A. Hill, R. Jeffers, T. S. Mitrovich, B. R. Pouliot,and D. S. Smith. NOMADS: Toward a Strong andSafe Mobile Agent System. In Proc. of the 4th Int’l.Conf. on Autonomous Agents, pages 163–164, 2000.

[16] The SELinux Project.http://selinux.sourceforge.net/, December 2005.

[17] Trusted Computing Group. Trusted ComputingGroup Hompage.https://www.trustedcomputinggroup.org/home,November 2005.

[18] G. Vigna. Cryptographic Traces for Mobile Agents. InMobile Agents and Security, volume 1419 of LNCSState-of-the-Art Survey, pages 137–153.Springer-Verlag, June 1998.

73