Securing Mobile Agents Implemented in the Scheme Programming ...

Securing Mobile Agents Implemented in the Scheme Programming Language Tony White, Michael Weiss School of Computer Science, Carleton University {[email protected], [email protected]} Abstract: Mobile agents have been proposed as a solution to problems in ecommerce, telecommunications, and many other application domains. However, the mobile agent computing paradigm raises a number of security-related concerns, which have limited their industrial deployment. Mobile agent security issues include: identification, secure messaging, resource access and control, certification and non-repudiation. This paper concerns itself with the resource control and nonrepudiation issues. Several mobile agent environments have been implemented in the Scheme programming language, an observation that motivates the solution described here. The paper describes a mobile agent architecture that is secure and provides performance figures comparing its use with and without security enabled.

1. Introduction Mobile agents were introduced as a problem solving paradigm in the early 1990’s with the release of Telescript [1] by General Magic. According to Chess et al [2], mobile agents promised improved network latency and reduced network load, and increased reliability and fault tolerance. Mobile agents were to provide autonomous problem solving, with adaptation to dynamically changing environments. While many of the claims remain unrealized, the security problems [3] associated with mobile agent deployment were quickly observed [4]. Mobile agent security [5] remains an area of active research, see, for example [6], [7], [8], [9] and [10]. An excellent web-based site for mobile agent security research is maintained by the Mole project [11]. While a description of the security issues raised by mobile agent deployment is provided in the next section, it is the problems of resource control and non-repudiation that motivate the research described in this paper. We are also interested in the performance impact of the solution, which is briefly described in section 4. The resource control problem for mobile agents can be defined as the problem of restricting access to resources within a particular mobile agent execution environment, or group of environments. Essentially, this is equivalent to answering the question, “Can agent X perform the operation Y on resource Z?” A concrete example of such a request could be, “Can MyTravelAgent update the AirlineTimeTable?” In this example, given the likely privileges of a TravelAgent, the update request would be denied – TravelAgent’s would expect to read from, not write to timetables. The non-repudiation problem for mobile agents is the problem of logging access to resources in such a way that the logs cannot be tampered with. Referring once again to the previous TravelAgent request, the log for the request becomes a tuple that includes time, the TravelAgent and ExecutionAgent identities, the AirlineTimeTable identity and the update action.

While the two previous paragraphs have described abstract Mobile Agent Environment problems, solutions to them rely to a lesser or greater extent on the Resource Manager implementation language [13], [16] of the mobile agent Execution Manager environment, its architecture [12] and the application-level security Security Manager services [14], [15] that it provides. The position adopted in this paper System Manager is that the implementation Communication Manager language can be designed, or modified, to provide robust agent resource control and nonFigure 1: Framework Architecture repudiation. Several scripting languages for mobile agents have been developed, with Telescript and Agent TCL being the most well known of the early systems. While the D’Agents mobile agent framework [17] supports multi-language agents, including Scheme, few environments have chosen to support this added complexity. Further, despite the development of the MASIF [18] specification for mobile agent system interoperability, many systems have chosen to remain proprietary as the specification has little to contribute in the area of security. While Java may seem an obvious choice for mobile agent implementation, its policy-based security model is not dynamic and recent observations [20] regarding object finalization, threading, inheritance and several other issues make its choice for secure agent mobility less compelling. However, the JavaSeal [19] environment does provide an important set of abstractions for agent mobility. The remainder of this paper is organized as follows. The next section describes a high-level architecture for a mobile agent environment and uses this environment to highlight the security issues present in mobile agent deployments. Section 3 presents details of the design of SecureScheme, a mobile agent environment based upon the Scheme programming language. Section 4 demonstrates the security aspects of the SecureScheme environment and provides results related to the performance impact of the implemented security features. The paper concludes with a summary of key messages and proposals for future research.

2. Mobile Agent Framework Architecture The mobile agent architecture implemented in this paper is shown in Figure 1. The framework consists of five distinct elements: the Communication Manager, the System Manager, the Security Manager, the Execution Manager and the Resource Manager. The Communication Manager is responsible for the reliable transfer of mobile agents. The Communication Manager supports send, broadcast and receive interfaces. The basic mobile agent transport mechanism is via XML document. Two adapters

implementing the aforementioned interfaces have been designed: an HTTP adapter and a JXTA adapter. Upon receipt, the mobile agent payload is presented to the System Manager for processing. Upon departure, the mobile agent is packaged by the System Manager and presented to the Communications Manager for transport. Transport may or may not be encrypted. The System Manager is responsible for the initialization of the mobile agent framework, monitors the status of the other managers in the system and records agent lifecycle events; i.e. arrival, start, suspend, resume and depart. The System Manager also provides interfaces to the outside world. We have implemented adapters conforming to the management interfaces for JXTA and using the Simple Network Management Protocol (SNMP). The Security Manager has three main functions. The first is the authentication of the mobile agent when it arrives; only authenticated agents are allowed to run within the Mobile Agent Environment. The second function is the authorization of access when the Execution Manager is asked to access a resource. Finally, the Security Manager is also responsible for logging access to resources and agent lifecycle events. The Execution Manager is responsible to interpreting the mobile agent SecureScheme statements. Execution is assumed to start with the function defined by the START_AGENT_FUNCTION parameter associated with the mobile agent. The Execution Manager will be extensively described in the next section and is the principal focus of this paper. The Resource Manager is the interface between the Mobile Agent Framework and the device on which it is executing. As such, this manager mediates all requests for access to objects outside of the framework. The Resource Manager is also responsible for persistence; i.e. managing agent state that persists after the agent has departed. All persistent state has an associated lifetime. In some sense, this can be thought of in the same way as cookies are managed in the Web environment.

2.1.

Security Issues in Mobile Agent Frameworks

The framework shown in Figure 1 raises a number of security concerns [5]. Using the breakdown in [5], there are four security threats: agent-to-platform, agent-to-agent, platform-to-agent and other-to-agent platform. The agent-to-platform threat deals with agent exploitation of the security weaknesses of an agent platform or agents launching attacks against the platform. Masquerading, denial of service and unauthorized access are examples of threats. Masquerading involves the exploitation of flaws in the SecurityManager, which is responsible for authentication. Denial of service involves exploitation of the ResourceManager and/or the SecurityManager as a sophisticated SecurityManager monitors an agent’s consumption of CPU and other platform resources. Unauthorized access attempts to exploit the SecurityManager, which relies of the identity of the agent having been established upon agent startup. The agent-to-agent category represents the set of threats in which agents exploit the security weaknesses of other agents or launch attacks against other agents. Agents interact with other agents via interfaces provided by the underlying platform. Agents are

themselves considered to be resources, so access from one agent to another is essentially asking the question, “Can AgentX communicate with AgentY?” As with the previous category of threat, the ResourceManager and SecurityManager are involved, so similar considerations apply. A further threat is present in agent-to-agent interactions, that of repudiation. It is essential that all inter-agent interactions be logged in order that denial of activity is impossible; i.e. the SecurityManager must log all access requests in a tuple of the form described in the previous section. The platform-to-agent category represents the set of threats in which platforms compromise the security of agents. Along with masquerading, denial of service, new threats of eavesdropping and alteration are present. A malicious platform, while supporting agent execution may not be implemented using the above architecture so it is difficult to make architectural comments regarding how the threat can be defeated. For this reason we have chosen to assume trustworthy agent platforms in our solution. However, research in this area is ongoing [21], [22]. Finally, the other-to-agent platform category represents the set of threats in which entities external to the platform threaten the integrity of the agent platform. Threats here include masquerading, denial of service, unauthorized access and copy and replay. As with the previous section, we impose no limitation on the architecture of the system on which our mobile agent framework runs. So, for this reason we have again chosen to assume a robust, secure operating system environment, which treats applications such as our mobile agent platform like a black box and allowing no communication-by-side-effect between applications, thereby avoiding buffer overflow and other familiar attacks.

3. A Mobile Agent Framework with SecureScheme In order to provide agent-to-platform and agent-to-agent security, it was decided that the focus of our design should be the ExecutionManager. Our highest priority requirement was to embed security at the lowest level of execution, using a language accepted by the mobile agent community. The Scheme programming language was chosen for this reason. Scheme is well known for its clean denotational semantics and small virtual machines, with a large number of interpreters being available in the public domain. Choosing Scheme also allowed us to change the basic behaviour of the ExecutionManager at runtime; clearly an essential requirement for an operational, highly available and robust system. SecureScheme is a variant of the Scheme programming language. Our SecureScheme implementation is based upon the Kawa Scheme interpreter [23], chosen because of Kawa’s ability to compile M a s te r functions to Java bytecode, its ease of S e s s io n integration with Java components and the fact that it is written in Java. The function set available to SecureScheme mobile agent developers is a subset of those defined by the Figure 2: Interpreter Hierarchy R5RS specification. The highly simplified architecture of the

ExecutionManager is shown in Figure 2. The design of the ExecutionManager allows for the association of a SecureScheme interpreter with each client session. There are master sessions created for the communication adapter class, which are created during the initialization phase of the ExecutionManager. During startup, all of the files indicated by the em.management.SecureScheme.file.x, x=1,2,3,4 … and (define (foo a) (+ 1 a)) em.client.SecureScheme.file.x, x=1,2,3,4 … properties statements in the em.ini file are loaded into the ExecutionManager. The bindings for functions defined in these files are added to the top-level interpreter for each protocol. The interpreter trees for the two protocol adapters are maintained Figure 3: Function Definition separately for security reasons. The class of the interpreter used for each interpreter tree is defined by the em.management.SecureScheme.class and em.client.SecureScheme.class properties. The default value for these properties is em.lang.SecureScheme. It is possible to protect these functions against modification; the mechanism by which this is achieved is detailed in the next section. During run time, all function evaluations are performed within a client interpreter. The lookup for a function starts within the client interpreter and continues to the master interpreter if the function is unknown to the client. Functions that are defined during a session are added to those defined with a client session with one exception. The EMLoad function adds bindings to the master session for the HTTP protocol adapter. An example may serve to explain the previous statements. In Figure 3, two client sessions are defined. If we evaluate (foo 1) in either session, the number 2 should be returned. The function lookup fails in both the client session interpreters but succeeds in the master session interpreter. In Figure 4, the function foo is defined in both the master and the right-most client session. Evaluating (foo 1) in the left session the result will be 2. Evaluating (foo 1) in the right session yields the result 3. In the first case the function lookup has succeeded in the master session. In the second case the function lookup has succeeded directly in the client (define (foo a) (+ 1 a)) session. Effectively the client session has masked or overridden the foo function in this case. Obviously this ability needs to be controlled, this being part of the (define (foo 1) (+ 2 a)) motivation for SecureScheme. Part of the control mechanism Figure 4: Functions in master and client relies on the concept of levels: each interpreter has an associated

maximum and default execution level. Functions, when defined, also acquire an execution level, which can be altered using management activity. A more interesting session arises when functions are being defined, something that occurs regularly in a typical ExecutionManager run. Evaluating foo in the client sessions will result in the bar function being defined within the client interpreter even though the lookup succeeds in the master session. Further, the two functions will have different definitions. The two bar functions returning 3 and 4 respectively for the evaluation (bar 2) in the left and right hand sessions respectively. Evaluating (bar 2) in the left hand session by an evaluation of bar in the right hand session causes an “Unbound Symbol” exception to be thrown in the right hand session, thereby demonstrating that the bar function is defined in the client session. The separation of the two functions can also be observed by evaluating (bar 2) in the two client sessions. The results remain unchanged – 3 and 4 – implying that function redefinition within the client sessions does not occur. Clearly, even though function lookup has succeeded in the master session, function definition has occurred in the client session. Similarly, using the load function within (define (foo p) (lambda (a) (+ p a))) a client session adds functions to the client session; the (define bar (foo 2)) (define bar (foo 1)) master and other client sessions remain Figure 5: Functions in client and master unaffected. This facility – separation of client-defined bindings – is particularly important from a security standpoint. One client session is not able to affect another. Visibility, overloading or overwriting of bindings is controlled by the SecureScheme implementation and is described in the next section. Should a function not be defined in the client or the master session, an attempt is made to load the function from the database of functions. master The em.lang.SecureScheme class implements the Function DB em.util.LambdaLoaderInterface, an interface that is used to load a function from persistent storage, client or possibly over the network. The em.util.LambdaLoader implements this interface and defers the actual loading of the lambda to an object that also implements the interface. A Figure 6: Function Loading database adapter performs the actual loading of

lambdas, which are stored centrally on trusted machines in either MS SQL or Oracle databases. Referring to the figure above, a reference to a function starts in the client interpreter and continues upward to the parent interpreter – the master – when the function cannot be found. If not defined there, the client then accesses its lambdaLoader, which results in a SQL query being generated. The string returned is evaluated using the client interpreter, resulting in the definition of the policy being defined in its environment. The function is compiled to Java byte code and cached. Subsequent references to the function result in the evaluation of the memory-resident, compiled function. If the requested function is not present in the database, or a database error occurs, an em.util.LambdaNotFoundException is thrown. It should be noted that the function returned could refer to other yet-to-beloaded functions. Should this be the case, the functions referred to will be loaded by recursive invocation of the lambda loader. As mentioned in a previous paragraph, it is possible for a client session to manipulate the bindings of the master session for a protocol adapter. This occurs through use of the EMLoad function. The EMLoad function first accesses the master interpreter associated with the protocol and uses the standard Scheme load function to read in JXTA master HTTP master commands stored in the resource file indicated by the function argument. client client The bindings appear in the master environment associated with the protocol, not in the client Figure 7: Managing SecureScheme Interpreters management session. This is shown in Figure 7. Clearly, the EMLoad function is a powerful one and is restricted to mobile agents having a management role. This functionality allows bindings available to the JXTA protocol to be manipulated at run time using mobile agent management activity. Bindings defined in both master sessions are set up during ExecutionManager initialization. Being designed to be a highly available server, functionality is provided in order to update policy bindings that have been loaded via a lambda loader, compiled and cached. The SecureScheme functions addFunction and updateFunction have been defined to allow centrally held function (re)definition at run time. The add and update functions update the centrally held database of functions. These functions are only accessible to management sessions; i.e. mobile agents executing with a management role. Once successfully committed, all client sessions are notified of the function change. Each session interpreter then loads the new function definition using the lambda loader mechanism discussed above. It should be noted that the function is loaded regardless of whether the function

had been loaded by client action. The update mechanism is implemented via the Observer pattern and is implemented directly in the em.lang.SecureScheme class. Functions defined within the Master session for the two protocols are unaffected by the addition of or change to centrally held functions. For that reason, centrally held functions are not loaded into these sessions.

4. Design Mechanism The SecureScheme interpreter, implemented in the em.lang.SecureScheme class, uses the constraint handling capability associated with the Kawa implementation of Scheme. It uses a concept of levels; a level being associated with the function when it is defined, this level being obtained from the level associated with the interpreter. Interpreter and function levels can be modified dynamically. An interpreter level is assigned when the mobile agent arrives and a new SecureScheme interpreter is created to handle mobile agent execution. The interpreter level is determined as part of the authentication process, this information being stored centrally on trusted authentication servers. Scheme, being a functional language, is based upon the concept of first class objects that are bound to specific environments. In the Kawa implementation of Scheme, the classes gnu.mapping.Binding and gnu.mapping.Environment represent these entities. SecureScheme extends the environment class with em.lang.SecureSchemeEnvironment and is implemented as an extension of the kawa.standard.Scheme class. The SecureScheme interpreter extends the em.lang.SecureScheme class by associating a secure environment with it. This secure environment is implemented in the em.lang.SecureSchemeEnvironment. This secure environment is key to the design of the security associated with the interpreter. When a new binding is created for a new symbol, or function, it has a constraint associated with it. Initially, this is an unbound constraint, meaning that the binding has no actual content and will throw an “unbound exception” if we attempt to access the symbol. In the case of the SecureSchemeEnvironment, the constraint associated with the binding is of the class em.lang.SecureUnboundConstraint. When a binding has an object associated with it; i.e. the function is defined, the constraint associated with the binding is changed to that of an em.lang.SecureConstraint, this being performed inside of the set method within the SecureUnboundConstraint class. When a function is defined using the Scheme “define” function, the define method within the SecureSchemeEnvironment class is called which causes a SecureConstraint to become associated with the binding as described above. Within the “define” function, the getLevelForFunction method is called is order to determine the level at which the function should be defined. The level is an integer, and the higher the number, the higher the trust required by the user before the function can be evaluated. The level associated with a function is stored in the private attribute “level” that is part of the definition of the SecureConstraint class. The getLevelForFunction method first looks at the function profile for the mobile agent (essentially the contents of the SecureScheme.ini file) to determine the level to associate with the function. If a level is not defined, the current execution level of the interpreter is associated with the function.

When a function is evaluated, the binding in the environment is first obtained and the get method defined for the SecureConstraint object associated with the binding is called. This method uses the level of the function to determine whether the current level associated with the environment is sufficient to access the function. If the level associated with the environment is too low, an UnboundSymbol exception is thrown – effectively telling the user that the function does not exist. While strictly not true (the binding does, in fact, exist), this is considered a security feature, the user being misled by the response of the interpreter. If the level associated with the environment is equal to or exceeds that of the binding, the actual value of the binding is returned; i.e. the function may be successfully evaluated. It is not possible to set the execution level associated with the interpreter to a level above that of the creating interpreter. It is not possible to associate an execution level of less than zero with any interpreter. Attempts to set illegal security levels result in exceptions being generated by the application; these exceptions being gracefully handled and not resulting in the premature termination of the ExecutionManager.

4.1.

Setting up the ExecutionManager

This section provides a description of the SecureScheme interpreter and how it is integrated with the ExecutionManager. In order to use SecureScheme, the ExecutionManager needs to be told what class and maximum level (its creation level) to associate with a protocol. Currently, two protocols may have their interpreter classes and levels defined: HTTP and JXTA. Setting these classes and levels is through the use of properties statements placed in the em.ini file. These statements are: em.management.SecureScheme.class=em.lang.SecureScheme em.management.SecureScheme.securityLevel=5 em.client.SecureScheme.securityLevel=5 em.client.SecureScheme.class=em.lang.SecureScheme The classes that may be used are em.lang.SecureScheme and em.lang.SecureScheme. A full package and class name should be provided. Future security-aware interpreter classes, should they be implemented, will support a constructor with a single Integer object argument. Should the class not be found, the em.lang.SecureScheme class will be used to instantiate interpreters for protocol clients. All implementations of future interpreters should be subclasses of em.lang.SecureScheme. The *.securityLevel property value defined for an interpreter is a positive integer. This value represents the creation level that can be assigned to the interpreter. A default value of 1 is assumed. Any attempt to set the level associated with the interpreter to a higher level through use of the SecureScheme function setSecurityLevel will generate a gnu.mapping.UnboundSymbol exception. Attempts to set the interpreter level to a negative value are ignored. Only functions in the range zero to the creation level can be

defined within the interpreter. Attempts to define a function with a higher level will cause a gnu.mapping.UnboundSymbol to be generated.

4.2.

Defining Default Security Levels for Functions

In order to associate a default level with a function, an entry is placed in the SecureScheme.ini file. These profiles are defined on a per role basis. This file contains statements of the form: functionName = integer The file is consulted when the ExecutionManager creates an interpreter for a mobile agent. An example of the above might be: define=4 Interpreting the above example means that the define function may only be used by interpreters executing at or above level 4. Regular expressions for function names are also supported. This has the form (for example): *=1 This means that all functions not explicitly given a value will be given the level 1. This default value is ONLY used during interpreter initialization; i.e. when the basic R5 Scheme functions associated with the interpreter are created.

4.3.

Association of Functions with Levels

Levels are associated with function through two mechanisms. Either the function is given a level through the mechanism described above or it is defined using the setSecurityLevel function. For example: (setSecurityLevel “foo” 5) will associate the level 5 with the foo function. The function foo will generally not be defined at this point. If it is, its associated level will not be affected. This is a conscious design choice. Should a user wish to change the security level associated with an existing binding, the function updateSecurityLevel must be used. The updateSecurityLevel foo: 4 bar: 3 function takes the same two arguments as the setSecurityLevel function; it does update the existing Level: 4 Level: 3 interpreter binding though. A binding must exist for the updateSecurityLevel function to Figure 8: Function Hiding succeed. If no binding exists, a gnu.mapping.UnboundSymbol

exception is generated. A getSecurityLevel function has also been written in order to retrieve the execution level associated with the currently running interpreter. It should return the value of the *.securityLevel parameter defined in the em.ini file. Using function levels provides two important capabilities: 1. function hiding 2. function protection Function hiding is achieved by defining a function at a level that is higher than the executing interpreter. A master and two client sessions are shown in Figure 8. The master interpreter is defined at level 5, although this is an unimportant detail for this example. Two functions are defined: foo at level 4 and bar at level 3. Two client interpreters are defined, one at level 3 and the other at level 4. The level 3 interpreter can invoke the bar function but not the foo function, a gnu.mapping.UnboundSymbol exception being generated when an attempt is made to use it. The level 4 interpreter can see both the foo and bar functions. This is an example of function hiding. It is also possible to make a function read only; i.e. protect it from being overwritten. A read-only function is one defined in an interpreter that cannot be refined. Again referring to the above example, the level 4 interpreter can be prevented from rewriting the foo function by using the setSecurityLevel function once foo is defined. Evaluating (setSecurityLevel “foo” 5) for the master interpreter forces future definitions of the function to occur at level 5; however the binding remains defined at level 4. This has the effect of making it impossible for the level 4 interpreter to define the foo function, as it would be attempting to define a function outside of its interpreter scope. It continues to be able to invoke the foo function, as the binding remains defined at level 4. Should an attempt be made by the level 4 interpreter to define the foo function, the existing binding remains unaltered and a gnu.mapping.UnboundSymbol exception is thrown. If it proves necessary to alter the function level associated with a binding, the updateSecurityLevel function should be used. Evaluating (updateSecurityLevel “foo” 5) forces the binding as well as future definitions of the foo function to be placed at level 5. In this case, the level 4 interpreter would lose access to the foo function. Given the power of the updateSecurityLevel function, care must be taken in assigning its level in order to avoid allowing inadequately authorized individuals from overwriting existing functions and bindings.

4.4.

Logging and Tracing

Setting function levels can be hard, as functions invoke other functions and it is the maximum level of the evaluated functions that determines whether the overall evaluation will succeed. For example, referring once again to the example of the previous section, a function foobar, which evaluates foo and bar in turn needs to be defined at level 4 in order to allow successful evaluation. Defining it at level 3 will cause the function to fail if evaluated within a level 3 interpreter as a result of the foo function being defined at level 4. A logging and tracing framework has been built for this reason. This framework allows tracing of SecureScheme functions to be switched on and off. Facilities have been

provided to: switch logging on and off and setting whether a given function is logged. For example, by typing: (log "char=?" #f), the char=? function is no longer logged. Logs are created on a per-mobile agent basis. Evaluating the code: (define (foo a) (+ 1 a)) generates the output: GET(1) define GET(1) + SC Level: 1 Creation level: 5, SET(1) foo:foo@4600c0 The output generated by the trace consists of a sequence of GET and SET statements. The trace output is formatted as described in section 1 and written to a central logging facility. In the above example, the define and + functions have been looked up in the environment. The number 1 in brackets indicates that these functions were defined at level 1. The “SC Level …” statement means that the secure constraint for the newly defined function is being created at level 1 in an interpreter that has a creation level of 5. The SET statement indicates that the foo function is being defined at level 1. The SET statement is generated whenever the value associated with a binding changes. This is typically seen when a function is defined for the first time.

4.5.

Performance

The use of the constraint indirection has a significant performance impact. In typical mobile agent applications that gather only information from a host, the impact is approximately 25%. The use of logging incurs a considerable cost and so it is important to log only functions of importance, typically those defined for aspects of the application. With full logging enabled, the ExecutionManager runs at up to an order of magnitude slower than with logging switched off. However, with a small number of logged functions this can be reduced to a 50% penalty.

5. Conclusions and Future Work Mobile agent deployment has been limited owing to justified concerns in the area of security. This paper has described an innovative approach to mobile agent security where agents are only allowed to invoke a subset of the functionality available within the Mobile Agent Framework. Security is transparent to the mobile agent in that unbound exceptions are thrown for functions not found. It is not possible for individual agents to determine whether the function exists and is hidden or has not been defined. The framework prevents overloading or overwriting of functions, thereby ensuring that individual agents cannot compromise the platform. Finally, mobile agents with the appropriate authority can alter the behavior of the Mobile Agent Framework thereby minimizing downtime for maintenance. In our future work we intend to look at typical execution profiles for mobile agents in an e-commerce setting. Through analyzing function execution traces we intend to refine the process of function level setting. Given the flexibility of the Kawa Constraint design, we also intend to evaluate other, more complex, constraint evaluations involving state as we feel the current integer-based design has limitations for workflow deployments.

References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]

White J. E., Telescript Technology, The Foundation of the Electronic Workplace, General Magic White Paper, 1994. Chess D., Harrison C. and Kershenbaum A., Mobile Agents: Are they a Good Idea? RC 19887, IBM Research Division, T.J. Watson Research Center, Yorktown Heights, New York, March 1995. Tschudin, C., Mobile Agent Security. In Matthias Klusch (Ed.): Intelligent Information Agents: agent based discovery and management in the Internet, pp. 431-446, Springer-Verlag 1999. Greenberg M. S., Byington J. C. and Harper D. G., Mobile Agents and Security. IEEE Communications Magazine, July 1998, vol. 36, No. 7, pp. 76-85, 1998. Jansen W. and Karygiannis T., Mobile Agent Security. National Institute of Standards and Technology (NIST), Special Publication 800-19, August 1999. Jansen W. and Karygiannis T., Privilege Management of Mobile Agents. National Information System Security Conference, October 2000. Jansen W., A Privilege Management Scheme for Mobile Agent Systems. In Proceedings of the 1st Workshop on Security of Mobile Multi-agent Systems, Autonomous Agents Conference, May 2001. Karnik, N., Security in Mobile Agent Systems. Ph.D. dissertation, Department of Computer Science and Engineering, University of Minnesota, 1998. Vitek J. and Jensen C. (eds), Secure Internet Programming – Security Issues for Distributed and Mobile Objects. Fourth International Workshop (MOS ’98), Brussels, Belgium, July 1998, LNCS 1603. Vigna G. (ed), Mobile Agents and Security. ISBN 3-540-64792-9, Springer-Verlag 1998. Mole Project URL: http://www.informatik.uni-stuttgart.de/ipvr/vs/projekte/mole Gray R. S., Kotz D., Cybenko G. and Rus D., D’Agents: Security in a Multiple-Language, Mobile Agent System. In Mobile Agents and Security, Vigna (Ed.), pp. 154-187, SpringerVerlag 1998. Volpano D. and Smith G., Language Issues in Mobile Program Security. In Mobile Agents and Security, Vigna (Ed.), pp. 25-43, Springer-Verlag 1998. Karjoth G., Lange D. and Oshima M., A Security Model for Aglets. In Mobile Agents and Security, Vigna (Ed.), pp. 1-14, Springer-Verlag 1998. Peine H., Security Concepts and Implementation for the Ara Mobile Agent System. In Proceedings of the 7th IEEE Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, June 17-19 Stanford University, USA, 1998. Gong L. and Schemers R., Signing, Sealing and Guarding Java Objects. In Mobile Agents and Security, Vigna (Ed.), pp. 206-216, Springer-Verlag 1998. Gray R. S., Cybenko G., Kotz D., Peterson R.A. and Rus D., D’Agents: Applications and Performance of a Mobile Agent System. Software-Practice and Experience, 32(6):543-573, May 2002. MASIF URL: http://www.fokus.fraunhofer.de/research/cc/ecco/masif/documents. Bryce C., and Vitek J., The JavaSeal Mobile Agent Kernel. In Proceedings of the 1st First International Symposium on Agent Systems and Applications (ASA'99)/Third International Symposium on Mobile Agents (MA'99), 1999. Binder W., and Roth V., Secure mobile agent systems using Java: Where are we heading? In Seventeenth ACM Symposium on Applied Computing (SAC-2002), Madrid, Spain, March 2002.

[21] Hohl F., A Model of Attacks of Malicious Hosts Against Mobile Agents. In Proceedings of the 4th ECOOP Workshop on Mobile Object Systems (MOS ’98): Secure Internet Mobile Computations, 1998. [22] Ng S-K., Protecting Mobile Agents against Malicious Hosts. Master Thesis. Division of Information Engineering, The Chinese University of Hong Kong, June 2000. [23] Kawa URL: http://www.gnu.org/software/kawa.