Internet and the Web. Mobile agents are software modules that move through the network autonomously, carrying out the assigned tasks on remote servers.
PeAgent – A Mobile Agent System to Support Secure Internet and Web Applications Qingkai Ma, Wei Hao, Wei Li, Manghui Tu, I-Ling Yen Computer Science Department University of Texas at Dallas {qingkma, weihao, wxl011400, tumh2000, ilyen}@utdallas.edu
Abstract Many agent-based systems have been developed over the past decade; however, the security issues are usually not addressed adequately. In order to make the mobile agent paradigm more useful and acceptable for Web and Internet applications, the security considerations should go beyond the protection of basic agent execution environments. In this paper, we present the design of a robust Java-based mobile agent system, PeAgent. The PeAgent system not only incorporates a fine-grain agent privilege control mechanism, but also includes a multi-level protection mechanism that can be used throughout the life-cycle of agents. A two-level domain hierarchy is constructed to organize the large number of Internet nodes in the agent system into manageable units: the Global/Domain Management Unit (GMU/DMU). Each unit consists of a Certification Authority (CA) and a Location Manager (LM). The certificates issued from GMU and DMU define the access privileges on the PeAgent servers for each agent. A context hierarchy is built up on the PeAgent servers for fine-level resource access control and agent management. Overall, the PeAgent system provides a secure computing environment for widely distributed applications over a network of heterogeneous platforms. It also facilitates the development of secure Web-based applications.
1 Introduction Mobile agent (MA) technology offers a new computing paradigm for distributed applications, especially for largescale heterogeneous network environments such as the Internet and the Web. Mobile agents are software modules that move through the network autonomously, carrying out the assigned tasks on remote servers. Many Web-based applications can take advantage of the MA paradigm to obtain performance gains or to achieve tasks that have mobility requirements. Security is one of the most important issues in designing mobile agent systems. Many applications that can benefit from the MA paradigm are resisting to do so due to security concerns. MA security includes two aspects. First, the agent servers can be compromised by malicious agents. For example, an agent, while executing on a host, may exploit the security loopholes of the host and gain extra privilege beyond its authorization. Also, without proper monitoring and protection, an agent may advertently make excessive use of some resources and cause denial-of-service attacks. Almost all existing MA systems provide some degrees of host protection [Agl, Aja, Tac]. Most of the notable Java-based
mobile agent systems make full advantage of Java’s built-in security mechanisms to construct its own security framework. Aglet [Agl] simply relies on Java’s access control list mechanism and security manager to control agent’s access to system resources such as file system, network ports etc. This Java features are also used in Ajanta [Kar01] and Concordia [Wal98]. Though Java provides the basic access control mechanism, the proper control of agent access privileges depends on the agent authentication mechanism. Also, it is frequently desirable to differentiate between agents and authorize them with different privileges, such as disk quotas, CPU time limit, network bandwidth limits, access privileges to specific files, access privileges for other system resources, etc. In order to achieve this goal, a scalable and robust agent access control protocol and a stringent monitoring mechanism are required. However, in most existing systems, agent authentication is done through a digital signature created by agent creator [Pul00]. Ajanta let every agent carry a tamperproof certificate, called credentials. But the credential is also assigned by the owner of the agent and, thus, can hardly be trusted. D’Agents [Gra98] has a more sophisticated authentication scheme. It adopts Pretty Good Privacy (PGP) for digital signature and agent encryption, and also builds up a trust model with transitive trust relationships. The second security aspect in MA systems is the protection of privacy and integrity of the agents. An agent can be compromised by a malicious host. Agent protection is generally a difficult task since the host can observe every action that the agent takes, read an agent’s code, data, and state in its entirety [Hoh97], or even alter or forge the agent’s state information. For example, consider an E-marketplace. A seller agent may carry the price-range information to facilitate autonomous negotiation and it surely wants to keep the information private. Nevertheless, a malicious host can easily obtain the information and give it to a buyer and cause a loss to the unfortunate seller. Consider another example where a price query agent X tries to find the lowest price for a merchant. A malicious vendor can change the lowest price X collected to its own price and change X’s itinerary such that it won’t collect any further price information. Some mechanisms have been proposed to protect the integrity of an agent for both its code and its state [Hoh97, Min96, Wil99]. But for the agent secrecy protection, existing research only provides partial solutions and further research is still needed. Furthermore, the existing MA systems almost do not address agent protection issues. Most of the proposed agent
1 Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03) 0730-3157/03 $ 17.00 © 2003 IEEE
protection mechanisms are not yet incorporated in deployed MA systems. In this paper, we discuss the design and implementation of a mobile agent system, PeAgent, that provides sophisticated security mechanisms for both host and agent protections. The design goals and major design concepts of the PeAgent system are outlined in the following. x One major design goal of the PeAgent system is to provide a scalable, fine-grain agent privilege control mechanism. For privilege control, we consider both the access control privileges and quota for individual resources (such as CPU time limit, disk quota, device access privilege, etc.). Also, privilege assignment is fine-grained and specific privileges are assigned to individual agents for individual resources. To achieve scalability, even with the finegrained privilege assignments, we use a hierarchical privilege granting protocol. At the global level, a global certification authority (GCA) is used to certify the domain certification authority (DCA). GCA determines the trustworthiness, access privileges, resource quotas, etc., of agents in individual domains. Within each domain, the DCA further certifies individual agents and determines their access privileges and resource quotas based on their local policies and mechanisms. x In the PeAgent system, agents are allowed to migrate with their private resources (such as files, secret code, and data objects; we will refer to these as assets). The PeAgent system should facilitate the specification and enforcement of the sharing privileges of agents’ assets. A context hierarchy is used in PeAgent hosts to structure the agents and define their relationships. Based on the agent relationships from the context hierarchy, agents can specify the sharing privileges easily. x The agent host should effectively enforce agents’ access privileges and resource quota. We implement proxies on agent hosts to perform privilege enforcement. Agents cannot directly access resources. All accesses by an agent for system resources and sharable assets of other agents should go through the proxies. x The PeAgent system should provide different levels of security protection mechanisms for agents throughout the agent’s life, including agent transmission, agent computation, and agent caching. Multiple protection mechanisms are provided in the PeAgent system to protect an agent’s privacy and/or integrity. The agent can choose appropriate protection mechanisms based on the tradeoff between its own criticality and the cost of the protection algorithm. In the next section, we discuss the major design concepts of the PeAgent system with a focus on the global PeAgent environment. The design issues for PeAgent hosts are discussed in Section 4. Section 5 introduces multi-level agent protection mechanisms in the PeAgent system design. Section 6 states the conclusion of the paper.
2 Global PeAgent System Design Due to the lack of sophisticated security protection mechanisms in existing MA systems, we developed a new MA system, PeAgent, to provide the MA platform with strong security and resource management support. PeAgent stands for Privilege & Protection Enhanced Agent system. As introduced earlier, the major goal of PeAgent system is to provide strong security support for both agent hosts and agents. Also, PeAgent and ‘pigeon’ have similar pronunciations that implicitly implies the common characteristics of the two. The pigeons are famous for their migration behavior and navigation capability, which is in common with agents in many MA systems. Pigeons are also famous for their use in carrying and delivering messages, whereas the agents in PeAgent system can carry data objects or files with them to facilitate effective remote execution. Of course, an agent in PeAgent system is much more than a pigeon. For example, pigeons are definitely not a secure messenger (letter maybe lost en route) and can’t provide any services at the remote site besides message delivery. In the following subsections, we discuss the design and development of PeAgent system.
2.1 PeAgent System Overview PeAgent system is organized into a two-level hierarchy, the global level and the domain level, to increase system scalability. A domain consists of a domain management unit, multiple PeAgent hosts and multiple source servers. An agent is originated from a source server. The source server interacts with users to create the agent, obtains authentication certification, and sends it out to an agent host. On the other hand, a PeAgent host provides the execution environment for agents. It is an entity fundamental to all agent systems. A domain management unit (DMU) can be further divided into the domain certificate authority (DCA) and the domain location manager. A certificate authority provides certificate for servers and agents. The location manager registers the current location of mobile agents. A global management unit (GMU) is the only entity at the global level. It contains the global certificate authority (GCA) and the global location manager. GMU maintains the privilege information of individual domains, including their trustability, entitled access privileges, resource quota limitations, etc. GMU issues the domain-level certificate to each DMU based on the privilege information of the corresponding domain.
2.2 PeAgent Privilege Authorization Protocol In PeAgent system, we provide fine-grain access control at the individual agent and individual resource level. An agent certificate is issued for each agent to specify its privilege and resources quota. To ensure scalability, privilege specification is provided hierarchically. At the domain level, the access privilege and resource quota that an agent in a domain can have is given in a domain certificate issued by the GCA to the DCA. The limitation is determined by the trust level and
2 Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03) 0730-3157/03 $ 17.00 © 2003 IEEE
needs of a domain. The access privilege and resource quota imposed by the agent hosts in a domain is determined by the DCA but stored locally. GCA determines the access privileges at the global level that can be further adjusted at the domain level by the DCAs. The agent certificate contains the information on file access privilege level (such as readwrite, read-only, or none), disk quota, network access privilege, network port quota, other device access privileges, and context operation for an individual agent. With this finegrain control, we can effectively control the agent’s activities and prevent denial-of-service attacks on agent hosts. The domain certificate contains the same information as an agent certificate with one additional field that specifies the maximum number of agents that can be dispatched from this domain to one PeAgent host. The data structures for the domain certificate and the agent certificate is shown in Figure 1. Domain information, like name, ip address, etc
Agent information, like name,source server, etc
DCA’s public key
Agent’s public key
Certificate expire time
Certificate expire time
Domain Level Privilege information
Agent’s Privilege information
GCA’s signature on the above content
DCA’s signature on the above content
(a) Domain Certificate
(b) Agent Certificate
Figure 1. Domain Certificate and Agent Certificate. The DCA, source server, and PeAgent hosts keep the latest GCA public key so that they can extract and verify the information given in a domain certificate with the GCA signature. Also, with the DCA’s public key given in the domain certificate, the information extraction and verification of the agent certificate can be done. A complete certificate an agent holds consists of three parts: the agent’s domain certificate, the agent certificate, and the GCA’s public key. 2.2.1 GCA and DCA Global Certificate Authority keeps the privilege information of individual domains. Upon system startup, administrator sets up the domain information at the GCA and assigns proper privilege to each domain. Then at each domain server, privilege is assigned to different users. The privilege assigned to a user can’t exceed what is allowed for the domain the user belongs to. In a closed environment, all entities in the system should have their registration records setup in the corresponding CAs a priori and CAs can issue certificates accordingly. However, many Web related applications provide services in an open environment, in which CAs may not have bases to determine the appropriate privileges for unknown entities. We use the trustability management concept in PeAgent system. When a DCA, say x, first registers with the GCA, an initial trustability value is assigned to it. This value is updated as
GCA receives feedbacks from other DCAs reporting x’s accountability. The impact of the feedback from a DCA y to the trustability value of x also depends on the trustability of y. The trustability value is used in determining privileges for PeAgents in the corresponding domain. Domain Certificate Authority will contact GCA at start up time to get its certificate. Then it waits for and process certificate or public key requests from source servers and PeAgent hosts. There are mainly three kinds of requests. The first kind is “GetDomainCertificate” request from source servers. For this kind of request, the DCA server simply returns its certificate. The second kind is “GetGlobalPublicKey” request. It can be from the source server or the PeAgent host. For this kind of request, the DCA server returns the Global Public key and the its expire time. The third kind of request is “GetCertificate” request from the source server. The DCA server first checks the validity of the request. If it’s valid, it generates a certificate for the agent and returns it to the source server. 2.2.2 Global / DCA Public Key Update Protocol Although it is hard to break public/private key encryption, given sufficient time, it is still breakable. To ensure security, the public key of GCA server must be updated after a certain amount of time. But since all the DCA servers, PeAgent hosts and source servers need the GCA public key information their copy of GCA public key must also update after the GCA public key changes. In a distributed mobile agent system, it will be very expensive to make all the sites update at the same time, so we let the sites decide when to update. When they want to use the global public key and discover that it expired, they will contact the CA to get the latest version of global public key. To avoid confusion, we set a grace period. From the time the GCA public key changes, both the old and the new public key can be used until the grace period is over. Based on the same consideration, the public key of DCA server must be updated after a certain amount of time. The DCA has a timer; the timer is set to the time when DCA server’s certificate will expire. The timer will trigger a procedure to update the DCA public key. The DCA server first generates a public/private key pair, then generates an “UpdateKey” request and sends it to the GCA server. The request contains the newly generated public key and is signed with its old private key. Source server also has a timer to ensure that it always has the up-to-date DCA public key. Same as the GCA case, there is also a grace period when both the old and new DCA public key can be used.
2.3 Agent migration request validation protocol When migrating an agent, we need to validate the involved PeAgent server as well as the agent. Senders (source servers or PeAgent servers) retrieves certificate for agent before it sends agent to the receiver. According to the requirement of agent, the agent may be unencrypted, partially encrypted or fully encrypted during transmission. If encryption is needed, sender will negotiate a session key with the receiver and use
3 Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03) 0730-3157/03 $ 17.00 © 2003 IEEE
the session key to encrypt the content. DCA performs the authenticating function. When it receivers a agent certificate request, it verifies the request’s signature and user information to see if it’s a valid request. If the request is valid, DCA will generate a certificate for that agent and send it back to sender. The pseudo-code for DCA is as follows: Begin receive the agent certificate request from sender; if the request’s signature and user information is valid then get the corresponding user’s privilege information and put it in agent’s certificate combine the agent certificate with the domain certificate to get a complete certificate; send the complete certificate ( agent privilege, identity, agent’s public key ) to sender; else send error message to sender; endif End When Receiver (PeAgent server) receives a agent migration request, it verifies the certificate and signature to see if that’s a valid migration request. If yes, it will first decide the agent’s privilege based on the privilege information from the certificate and its own platform specific privilege constraints, then serve the agent and sends back response to sender.
3 PeAgent Host Design 3.1 PeAgent Host Context Hierarchy A PeAgent host provides the execution environment for mobile agents. Each PeAgent host may have its own resource access constraints and quota and may wish to change them dynamically. Also, each agent may migrate with their own assets. To allow a PeAgent host to further control the accesses to its resources and to allow agents to conveniently specify the sharing privilege of their assets, we developed the “context hierarchy” concept. A context hierarchy structures contexts in a tree that is similar to the file systems. The root context is created when a PeAgent host starts up. Specific limitations and privileges for accesses to host resources can be given to the root context. Under the root context, additional contexts can be created by the PeAgent host or by other privileged users who sends a context creation request. Resource access privileges and quota can be further defined on each created context by its creator. The policies for privilege/quota definitions on subcontexts are given in the following. 1. Sub-context can’t have higher resource access privileges than that of the parent context. Consider a context C with no network access privilege. All sub-contexts under C and all agents created under C or under a sub-context of C will have no network access privilege. 2. The sum of the resource quota of all sub-contexts and agents under a parent context should be less than or equal to those of the parent context. For example, assume that
1MB disk quota is given at the root context. Then, it means that the PeAgent host provides 1MB disk spaces to all agents. Assume that the root context has 3 sub-contexts and 4 agents. The total disk quota given to these 3 subcontexts and the 4 agents should be less than or equal to 1MB. 3. Sub-contexts should have a higher agent protection level than the parent context. For example, if the agents under a parent context, C, have the code encryption protection, then the agents in a sub-context of C must at least have the code encryption protection. Currently, the access privileges and resource quota considered in PeAgent system include disk quota, file access privilege, socket communication privileges, socket port quota, device access privilege, and CPU time (execution time) limit. A policy is needed to distribute the quota of a parent context to it children. A resource manager is used in the PeAgent system to manage the resource quota distribution and to optimize system resources utilization. When a subcontext CS is created under a parent context CP, its (CS) resource quota is determined based on some default policy. When new sub-contexts are created under the parent context CP, some quota allocated to CS may be reduced due to the demands from other sub-contexts. Similarly, if the agents under the subtree of CS demands more resources, and there is more resources quota under CP to spare, then the resource quota for CS can be increased. Quota assignments and dynamic modifications are controlled by the resource manager. To flexibly control the agents’ activities is essential for system performance as well as security. Resource manager also keeps statistics of agent-based and overall resource usage information. Agent migration will be initiated if available resource ratio is falling below some pre-defined threshold. In this way, system performance can be guaranteed and denial-of-service attack can be prevented. An agent should be created under a specific context, specified by its creator. In order to securely protect a context, every context is assigned a context key. When a user creates an agent or a sub-context under a specific context, s/he needs to provide the context key for privilege verification. Also, the access privilege and resource quota of a context or an agent can be defined by the creator. However, the creator can not solely define these privileges and quota; otherwise, malicious creators can take advantage of this authority. The list of the authorities that can assign the access privileges and resource quota for an agent on a specific PeAgent host is given in the following. x User. The user who creates and migrates the agent can specify the desired resource privilege and quota requirement. x Agent certificate given by DCA and domain certificate given by GCA. The domain certificate specifies the limitations of access privileges and resource quota for all agents in the domain. DCA can further specify the
4 Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03) 0730-3157/03 $ 17.00 © 2003 IEEE
limitations for specific agents in the domain according to its own policies and the trustability of the user. x PeAgent host. The agent certificate and domain certificate specifies a general privilege and quota for each agent on all PeAgent hosts. But the privilege and quota can be further confined by individual PeAgent host according to its local resource availability and security policies. PeAgent host specifies the global limitation in a configuration file and the information is loaded and assigned to the root context when the PeAgent host initiates. x Context. Resource constraints on a PeAgent hosts can be further confined by the context of the agent. The decision is made by the resource manager based on the demands of the agent and other agents in the system. When an agent is created, the source server retrieves agent certificate and domain certificate from the domain server. Resource limitation for the agent is set as the minimum of the user demands, constraints given in agent certificate, and constraints given in domain certificate. The PeAgent host makes local adjustment to the resource limitations based on the local resource availability and constraints. PeAgent host can also decide to grant more privileges to agents from trustworthy domains or collaboration domains. If the resource requirements specified by an agent is greater than the resource limitations enforced by the PeAgent host, then the agent creation request should be either rejected or the requested resource should be shrunk. The user can specify the mode ‘Abortion’ or ‘Shrink’ during agent creation time to instruct the PeAgent host to make the corresponding decision. The agent’s parent context will repeat the process as PeAgent host and decide whether to accept or reject an agent or reduce its resource privilege or quota.
3.2 Context Hierarchy for Agent Assets Protection Each agent can migrate with some assets, such as data files. Proper mechanisms should be provided to allow agent to specify its own access control policies for its assets. Access control specification for agent assets is also based on the context hierarchy. An agent can specify the sharing limitations of its assets. The levels of asset sharing are listed as follows. x Owner. The asset can only be accessed by the owner agent. x Context. Consider an agent A and its asset F. Assume that A belongs to the context C. If F’s sharing privilege is specified as “context”, then all agents belongs to C can access F. x Context subtree. Consider an agent A and its asset F. Assume that A belongs to the context C. If F’s sharing privilege is specified as “context subtree”, then all agents belongs to C or any sub-context that is the descendant of C can access F. x All. The asset can be accessed by all agents on the current PeAgent host. The access privileges can be specified for each agent asset. PeAgent hosts keeps track of the agent assets and their access
control information in order to enforce the fine-grain access control rules.
3.3 The Proxies One of our system goals is to provide privilege control with fine granularity. Different agents from different source users should have different privileges for local resource access. Some agents may not have local resource access privileges at all. For the agents who have local resource access privilege, we should further impose resource constraints on them. For example we should give different disk quota, available network port number and thread number limitations to different agents. The protection mechanism provided by JDK can only perform a coarse-grain privilege control by using security manager. At first we implement our resource manager and ACB (Agent Control Block) inside the security manager and we meet two problems. The first one is when an agent initials a file write operation, our resource manager will check if the file size exceeds its quota via the length method in File class. But the length method will trigger checkRead method in SecurityManager class. So it causes the recursive calling (infinite loop) problem. The second one is security issue. It’s possible for agents to access to the information in resource manager and ACB because agents and security manager reside in the same thread space. So we have to develop a new protection mechanism – protection & privilege control based on proxy.
4 Agent Protection against Malicious Hosts In the previous sections, we mainly considered the protection of PeAgent server. However if the PeAgent server itself is malicious, it may compromise the agents on its platform. We consider the situation in two phases, the storage and execution phases. In addition, we consider agent protection during its migration phase. Note that agent protection should include agent code protection and agent resources (data files) protection. For communication phase protection, we use general encryption and authentication protocols. Two communication peers negotiate a session key and use that session key to encrypt message during transmission. According to user’s different requirement for security, there are two levels of protection. In the first level, only agent’s data are encrypted during transmission. In the second level, both the code and data are encrypted during transmission. For the storage phase protection for both data and code, the user can have two basic options, to have no protection or to store the file in encrypted form. If an agent carries highly sensitive data, then storage time protection may not be sufficient. During computation time, PeAgent server will have to operate on the data in its original form, either by decrypting the encrypted data or collecting the data fragments to reconstruct the data. Thus, the agent data can be compromised during this time. We provide computation phase agent data protection scheme using a secret-sharing based approach proposed in [Ma02]. Nearby
5 Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03) 0730-3157/03 $ 17.00 © 2003 IEEE
PeAgent servers form a group of size n (n is chosen at start up time and has to be greater than or equal to 3). The source server decomposes sensitive data into n shares and assign each share to one agent. n agents are sent to one group of n PeAgent servers, one agent to each PeAgent server. If a user chooses to have this computation time protection, then the data has to be stored in secret shares on n PeAgent servers during the storage phase. During computation phase, each of the n agents performs computation on its own share of the secret data, and communicates with other PeAgent servers in the group for some operations without releasing the secret. We use code obfuscation technique [Col97] for computation time code protection against malicious PeAgent servers. Obfuscation techniques transform a program to a format that is hard to analyze. Thus, even if the PeAgent server has access to the code in computation time or any other phase, it is hard for the PeAgent server to obtain any meaningful information out of the obfuscated code. Code obfuscation will be applied to the code at the source server before the agent is sent out. Once it reaches the PeAgent server, it can be stored on the PeAgent server site either as is or in encrypted form. Code obfuscation only protects the intention of the code from being easily known. Prolonged analysis of the code can still reveal the function of the code. Also, it does not protect the copyright of the code. For copyright protection, user can choose to use watermark technique to insert copyright information into the code.
5 Summary We investigated the issues in developing highly secure and survivable agent systems. First, we designed the PeAgent system to support agent execution. Several security mechanisms were used in PeAgent to protect the PeAgent hosts from malicious agents. A domain hierarchy was used to divide the large number of nodes over the Internet into manageable units and security mechanisms were applied based on the hierarchy. The public key certificates were used to authenticate agents and differentiate agents’ privileges for server resource accesses. We used Java’s SecurityManager mechanism to block all direct resource access request from agents and provided proxies to serve resource access requests by agents. In the proxy, the agent’s privilege is examined to determine whether to perform the requested action. Also, hierarchical structured context is used to provide fine level resource access control. A secure transmission mechanism has been provided to guarantee secure transmission of the agent and its data. The Basic version of PeAgent has been implemented. It provides complete security protection and resource management. In PeAgent system, security mechanisms are also provided to protect agents against malicious servers. Protection is provided at different levels to ensure cost-effectiveness. Threshold secret-sharing scheme is used to partition data so that secrecy can be achieved. Threshold secret-sharing scheme also offers survivability since it guarantees that from less than k shares nothing substantial about the secret can be
inferred. Agent replication is used to provide fault tolerance. Our approach can be better than others in terms of computing power. Other similar approaches do not support generalpurpose computation since they do not consider the conditional branch operations. We will conduct further research to improve our algorithm’s efficiency.
6 Acknowledgement This research was supported in part by the National Science Foundation under Grant number EIA-0103709 and the Texas Advanced Technology Program under Grant 009741-0143-1999.
7 References [Agl] http://www.trl.ibm.co.jp/aglets. [Aja] http://www.cs.umn.edu/Ajanta. [Col97] C. Collberg, C. Thomborson, D. Low, “A taxonomy of obfuscating transformations,” Technical Report 148, Dept. Computer Science, Univ. of Auckland, Jul 1997. [Hoh97] F. Hohl, “An approach to solve the problem of malicious hosts,” Technical Report, Univ. of Stuttgart, Germany, Mar 1997. [Gra98] R. S. Gray, D. Kotz, G. Cybenko, D. Rus, “D'Agents: security in a multiple-language,” in: Giovanni Vigna (Ed.): Mobile Agents and Security. pp. 154-187. Springer-Verlag, 1998. [Kar01] N. Karnik, A. Tripathi, “Security in the Ajanta mobile agent system,” Software - Practice and Experience, Jan 2001. [Ma02] Q. Ma. “Secure and survivable agent computation,” Technical Report UTD-CS-17-02, Department of Computer Science, University of Texas at Dallas, 2002. [Min96] Yaron Minsky, Robert van Renesse, Fred B. Schneider, Scott D. Stoller, “Cryptographic support for fault-tolerant distributed computing,” Proceedings of the Seventh ACM SIGOPS European Workshop, pages 109114, Connemara, Ireland, Sept 1996. [Pul00] A. Pulianfito and O. Tomarchio, “Design and development of a practical security model for a mobile agent system,” Journal of System Architecture, Vol. 46 No. 2, Jan 2000. [Tac]
http://www.tacoma.cs.uit.no/publications.html.
[Wal98] T. Walsh, N. Paciorek, D. Wong, “Security and reliability in concordia”, Proc. 31st Annual Hawaii International Conference on System Sciences, 1998. [Wil99] U. Wilhem. “A technical approach to privacy based on mobile agents protected by tamper-resistant hardware,” PhD Theses Nr. 1961. Department D’ Informatique, Ecole Polytechnique de Lausanne, 1999.
6 Proceedings of the 27th Annual International Computer Software and Applications Conference (COMPSAC’03) 0730-3157/03 $ 17.00 © 2003 IEEE
