PeAgent – A Mobile Agent System to Support Secure Internet
and Web Applications
Qingkai Ma, Wei Hao, Wei Li, Manghui Tu, I-Ling Yen, and Farokh Bastani
Computer Science Department, University of Texas at Dallas
Corresponding Author:
I-Ling Yen
Computer Science Department
University of Texas at Dallas
MS EC-31, Box 830688
Richardson, TX 75083-0688, USA
Phone: (972)883-6446
Fax: (972)883-2349
Email: [email protected]
Abstract
Mobile agent technologies offer a new paradigm for distributed applications, especially for Webbased and Internet-based applications. Many agent-based systems have been developed over the past
decade; however, security issues have usually not been addressed adequately. In order to make the mobile
agent paradigm more useful and acceptable for Web and Internet applications, 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 supports a fine-grain agent privilege assignment and control mechanism. A two-level
domain hierarchy is constructed to organize the large number of Internet nodes in the agent system into
manageable units. Thus, the authentication and authorization of agents and hosts can be done more
precisely. Also, the PeAgent system supports agent migration with external data objects. A context
hierarchy is defined to facilitate fine-grained resource management, including both the agent-owned
resources as well as the agent host resources. Based on the context hierarchy, agents can easily define the
access privileges and resource sharing policies for their external resources. 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 Internet-based applications.
Keywords. Mobile agent systems, security, Internet-based applications, agent authorization, agent
authentication, agent protection.
1
1 Introduction
Mobile agent (MA) technology offers a new computation paradigm for distributed applications,
especially for large-scale heterogeneous network environments such as the Internet. Mobile agents are
software modules that move through the network autonomously, carrying out their assigned tasks on
remote servers. Many Web-based applications can take advantage of the MA paradigm to obtain
performance gains or to implement 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 not doing 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 security loopholes of the host and gain extra privileges 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]. A basic mechanism that is required for any host protection
approach is agent authentication. An agent host should only admit trustable agents. However, in most of
the existing MA systems, authentication of agents is done in an ad hoc way, lacking a global control in
deciding the trustworthiness of agents. Along another direction, it is desirable to differentiate between
agents and authorize them with different privileges, such as disk quotas, CPU time limits, 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.
The second security aspect in MA systems is the protection of the privacy and integrity of the agents,
including their code, states, and external resources (such as data files) that they carry with them. An agent
can be easily 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 product. 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 more comprehensive and robust mechanisms are still needed. Also, most of the
2
existing MA systems do not address agent protection issues. The proposed agent protection mechanisms
are not yet incorporated in deployed MA systems.
Protecting agent-owned resources is another area that has not been widely studied. An agent may
need to carry data files or other objects with it to achieve its task. Also, the agent may need to share its
data objects with its coordinating agents running on the same host. Thus, the agent host should provide
some mechanism to allow an agent to specify the sharing policies of its resources and be able to enforce
the policies. However, most MA systems only consider the migration of an agent and its state, not
additional objects that are external to the agent. Almost no MA systems consider the protection, sharing,
and access control of agent-owned resources.
In this paper, we discuss the design and implementation of a mobile agent system, PeAgent [PeA],
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.
 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 fine-grained 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.
 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.
 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.
 The PeAgent system provides different levels of security protection mechanisms for agents throughout
their life-cycles, including agent transmission, agent computation, and agent caching phases. Multiple
protection mechanisms are provided in the PeAgent system to protect an agent’s privacy and/or
3
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 security mechanisms provided in existing MA systems. We first
introduce various mechanisms used for agent host protection. Then we discuss the problems in agent
protection and the existing approaches. In Section 3, we present 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 presents the multi-level agent protection mechanisms used in the
PeAgent system design. Section 6 states the conclusion of the paper.
2 Security Mechanisms in Existing MA Systems
2.1
Agent Host Protection
A malicious agent makes use of the security loopholes of a host system to conduct attacks. It may
cause damages ranging from denial of services, breach of privacy, to damages to host resources. A lot of
techniques have been developed to protect agent hosts against malicious agents. Many Java-based mobile
agent systems rely on the built-in Java security mechanisms for host protection [Agl, Pha98]. Java
incorporates the sandbox concept, which confines agents’ memory and method accesses to their own
protected domains [Fug98]. Sandbox security is enforced through a variety of mechanisms. Static type
checking in the form of byte code verification is used to check the safety of foreign code. A distinct name
space can be maintained for untrusted code. Safe code interpretation prevents agents from interfering with
one another or the underlying agent platform. In addition, all accesses to system resources in Java have to
go through a security manager, which monitors agents’ accesses to system resources.
Most of the notable Java-based mobile agent systems take 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 an agent’s accesses to system resources such as file
systems, network ports etc. This scheme is also adopted in Ajanta [Kar01] and Concordia [Wal98], but it
can only verify the signer or source of the agent code, which is far from fine-grain access control.
Voyager [Pha98] converts existing Java classes into Virtual Objects by a Virtual Code Compiler (vcc
utility) to embody the mobility nature. It only provides basic security which the Java language itself
carries. D’Agents [Gra98] is a multi-lingual mobile agent system. Its uses language-specific enforcement
modules such as Java’s built-in security manager to enforce resource access control.
However, security mechanisms provided in Java do not cover all the aspects of security requirements
in MA systems. Additional mechanisms are called upon to build a moderately secure agent system. For
example, agents should be authenticated based on globally recognizable certificates. It should also be
4
possible to assign differentiated privileges to agents. Fine-grained resource management schemes should
be incorporated in agent hosts to enforce resource access control policies [Cza98].
In existing MA systems, agent authentication is usually done through a digital signature created by
agent owner [Pul00]. In Ajanta [Kar01], every agent carries a tamper proof certificate, called credentials,
which is assigned by its owner. However, there is no global or centralized control of credentials issuing
and management. D’Agents [Gra98] adopts Pretty Good Privacy (PGP) for digital signature and agent
encryption. An agent is certified by its owner or its originator platform. It assumes that all the agent
system entities are under a single administrative control and, hence, would trust each other. There is no
global authentication and authorization control.
Another critical security issue for the agent hosts is to control access privileges and quotas for
admitted agents during their execution [Bel01]. Some systems use on-line monitoring mechanism to
observe the agents’ runtime resource access activities and subsequently enforce resource management
policies. For instance, a Monitoring Application Programming Interface (MAPI) is integrated into the
Secure and Open Mobile Agents (SOMA) platform [Bel00] for resource management. MAPI exploits
JVMPI [Sun] (a Java extension technology to export several JVM internal events for debugging and
monitoring purpose) to collect several application-level events (e.g., object allocation and method
invocation). In D’Agents [Gra98], the resource control is simply implemented through absolute resource
limits and a currency-based model. In Ajanta [Kar01], besides Java’s built-in access control list
mechanism for the system level resource control, a trusted proxy mechanism is employed for managing
application-defined resources. Resources are protected by encapsulating them in proxy objects, which are
created dynamically and customized for each specific agent. This enables the usage-metering and
accounting mechanisms in the proxy. However, resource control on individual agent hosts only is not
sufficient. A unified global control of resources and agent privileges should be incorporated to facilitate
fine-grain control.
Existing mobile agent systems do not consider integrated privilege management mechanisms. They
do not consider global authentication scheme and lack fine-grain control of access privileges and quotas.
Also, no existing MA systems consider the issues involved in agent-owned resources. We have developed
the PeAgent system to address these problems. In the PeAgent system, we use domain concept to
organize hosts in our system. A two-level certificate mechanism for agent authentication and privilege
assignment is introduced. Certificate authorities are available at the global and the domain level to issue
certificates.
5
2.2
Agent Protection
Protecting agents against malicious hosts is a much more difficult problem compared to protecting
agent hosts against malicious agents. Since agents run on the host platform, the agent host can look into
the agents’ code, data, and assets and trace their execution. The attacks to agents can be classified into
denial of services, masquerading, breach of privacy, and modification attacks. Unfortunately, very few
MA systems (those have actually been deployed) have incorporated agent protection mechanisms. None
has considered the policy definition and protection of agent-owned assets.
To cope with modification attacks, Ajanta [Kar01] allows the agent programmer to declare parts of
the agent state as read-only and/or append-only. Simple integrity coding mechanisms can be used for
tamper detection of the read-only or append-only data. This protection mechanism is relatively limited,
offers no protection to dynamic data and cannot be used for privacy protection. To counter masquerade
attack, several MA systems incorporate host authentication protocols. Anchor Toolkit [Mud99] achieves
server authentication by using X.509 certificate. Aglet [Kar97] plans to incorporate mutual authentication
in its future version.
Other agent protection mechanisms have been explored in the literature, but have not been integrated
into deployed MA systems. First, consider the denial-of-service attacks. There is nothing that the agent
can do if the host simply ignores the agent requests or even removes the agent without notification. The
only counter action for denial-of-service attacks is agent replication [Sch97, Min96]. Full replication is
costly. Thus, techniques using partial redundancy can be considered.
A malicious host may modify the code or data purposefully to gain some benefits. As discussed
above, Ajanta addresses the problem using immutable data. In [Wil99], an approach for agent protection
using tamper-proof hardware has been discussed. The use of special hardware is costly and difficult to
deploy widely. In [Far96], Farmer and Guttman suggest to use state appraisal functions to verify that
acceptable parameters are used during agent execution. This mechanism further provides protection to the
integrity of agent’s dynamic data. However, it is generally difficult to come up with the appropriate
appraisal functions for agents and additional cost is imposed on the development of the agent software.
Agent privacy can be easily breached by a malicious host since the host can monitor each instruction
executed by the agent, all the public and unencrypted data the agent brought to the host, and all the data
generated at that host. The host can also eavesdrop on the conversation during agent communication. In
some cases, even if the agent doesn’t reveal any secret information, the host can infer some useful
information by monitoring its behavior on that host. In [Gra98], a security model is proposed for agent
privacy protection, including agent partitioning (keeping sensitive data on its home machine), encrypted
components, and encrypted program execution, etc. It simply suggests using a collection of currently
available techniques for agent protection. None of the algorithms is implemented for agent systems. Also,
6
the techniques only offer partial solutions for agent privacy-preserving computation. In [You97], Young
and Yung suggest using agent public key to encrypt information collected at a host. This approach
protects the information collected from one host from being known by other hosts. It is suitable for
information collecting agents. But it doesn’t protect secret data that have to be used in computations at an
agent host. In [San97], a protocol that allows computation on encrypted data has been proposed, but only
polynomial function computation can be achieved. Other than protecting the secrecy of agent data, agent
code protection can be achieved using code obfuscation techniques. However, obfuscation only provides
temporary secrecy protection.
3 Global PeAgent System Design
Due to the lack of sophisticated security mechanisms in existing MA systems, we have developed the
PeAgent system to provide a 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 imply the common characteristics of the two.
Pigeons are famous for their migration behavior and navigation capability, which is in line with agents in
many MA systems. Pigeons are also famous for their use in carrying and delivering messages, just as the
agents in PeAgent system can carry data objects or files (agent assets) 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 the PeAgent system.
3.1
PeAgent System Overview
As illustrated in Figure 1, 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 created at a source server. The source
server interacts with users to create agents, obtain authentication certifications, and send agents out to the
hosts. 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 (DLM). The DCA issues certificates for servers and
agents within the domain. The DLM registers the current locations of mobile agents originating from the
domain or executing in the domain.
7
A global management unit (GMU) is the only entity at the global level. It consists of the global
certificate authority (GCA) and the global location manager (GLM). The GCA maintains the privilege
information of individual domains, including their trustworthiness, entitled access privileges and resource
quotas, etc. It also issues the domain-level certificate to each DMU based on the privilege information of
the corresponding domain. The GLM coordinates the location management activities of all the DLMs.
Global Mgmt. Unit
…
Domain Mgmt. Unit 1
PeAgent
Server 1
…
PeAgent
Server n
Source
Server 1
…
Source
Server m
Domain Mgmt. Unit k
PeAgent
Server
…
Source
Server
Figure 1. PeAgent system infrastructure.
3.2
PeAgent Privilege Authorization Protocol
In the 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 privileges and resource quota.
To ensure scalability, privilege specification is provided hierarchically. At the domain level, the maximal
access privileges 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, needs, and contributions
of a domain. The access privileges and resource quotas imposed by individual 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 privileges (such as read-write, read-only, or none), disk quota, network access privilege,
network port quota, other device access privileges, and context operation privileges. With this fine-grain
control, we can effectively control the agent activities and prevent denial-of-service attacks by malicious
agents. The domain certificate contains the same information with one additional field that specifies the
maximum number of agents that can be dispatched from the corresponding domain to a PeAgent host.
The data structures for the domain certificate and the agent certificate are shown in Figure 2.
8
Agent information, like
name,source server, etc
Domain information, like
name, ip address, etc
DCA’s public key
Agent’s public key
Certificate expire time
Domain Level
information
Certificate expire time
Agent’s Privilege
information
Privilege
GCA’s signature on the
above content
DCA’s signature on the
above content
(b) Agemt Certificate
(a) Domain Certificate
Figure 2. 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, namely, the agent’s
domain certificate, the agent certificate, and the GCA’s public key.
3.2.1 GCA and DCA
The GCA maintains the privilege information of individual domains. The GCA administrator
maintains the domain information and assigns privileges to each domain. Each DCA assigns different
privileges to different users and ensures that the privileges do not exceed the specified limits for the
domain.
In a closed environment, all entities in the system should have their registration records set up 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 incorporate the trustability management [Wee01] concept
in the 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 the GCA receives feedback 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 to adjust privileges for the corresponding domain.
At start up time, the DCA first contacts the GCA to obtain a certificate. Then it processes requests
from source servers and PeAgent hosts. There are mainly three types of requests. First, the source servers
may issue the “GetDomainCertificate” request to the DCA. Correspondingly, the DCA simply returns its
certificate. Second, both the source servers and the PeAgent hosts may issue the “GetGlobalPublicKey”
request. The DCA returns the Global Public key and its expiration time to the requester. The third type of
9
request is “GetCertificate” from the source server. Upon receiving this type of request, the DCA server
first checks its validity and if it is valid, then generates and returns a certificate for the agent.
3.2.2 Public Key Update Protocol
Given sufficient time and computation power, the public key cryptography is still breakable. To
ensure security, the public key of the GCA must be updated periodically. Once the GCA changes its
public key, all the copies of the key maintained by the DCAs, PeAgent hosts, and source servers must
also be updated. Since MA systems are widely distributed, it is very expensive to make a synchronous
update. We allow each site to update the cached GCA key asynchronously. When a site needs to use the
key and discovers that the key has expired, it contacts the GCA to get the latest version. To avoid
unnecessary communication overhead, we allow a grace period during which both the old and the new
public keys can be used. During the grace period, if the request to the GCA is signed by the old key, then
the updated key is sent back along with the response to the requester.
The public key of a DCA is updated in a similar way. In addition, the DCA needs to send the
“UpdateKey” request to the GCA immediately after the key update to refresh GCA’s records for the
domain.
3.3
Agent Migration Protocol
When migrating an agent, we need to validate the involved PeAgent server as well as the agent.
Before migration, the sender (source server or PeAgent server) first obtains a certificate for the agent.
According to the security requirement of the agent, the agent may be encrypted during transmission (other
options include transmitted with integrity code or with no protection at all). If encryption is needed, the
sender negotiates with the destination PeAgent server to establish a session key. The pseudo-code for the
sender is given as follows:
begin
receive agent migration request from migration decision maker;
retrieve the destination PeAgent server’s identity Ad;
send agent certificate request (agent identity, desired privilege) to DCA;
wait for the certificate;
if received certificate is valid then
if encryption is needed then
send request to location manager to get Ad’s public key Pk;
negotiate a session key Ks with Ad using Pk;
encrypt the agent using Ks and send to Ad;
else
send agent with the certificate to Ad;
endif
wait for acknowledgement from Ad;
endif
end
10
The DCA maintains the public keys of all agent servers and source severs in the domain as well as a
list of all users and their privilege information. When the DCA receives an “agent certificate” request, it
verifies the user information and the signature of the sender. If the request is valid, it generates an agent
certificate according to the privilege information of the corresponding user. The agent certificate is
concatenated with the domain certificate and sent back to the sender.
When a PeAgent host receives an “agent migration” request, it verifies the signature and extracts the
privilege information of the agent. The final agent privilege is determined based on the information from
the certificate and the specific privilege constraints at the PeAgent host. The pseudo-code is as follows:
begin
receive the migration request from sender;
if the request is encrypted then
use the established session key to decrypt the request;
endif
if the certificate and the signature of the migration request is valid then
send acknowledgement to the sender;
decide agent’s privilege;
serve the agent;
else
generate and send error message to the sender;
endif
end
4 PeAgent Host Design
An agent host provides fundamental facilities, the execution environment, for mobile agents. It should
also provide sufficient security mechanisms to protect its own resources as well as agents executing on it.
In the following subsections, we discuss the security mechanisms used on PeAgent hosts.
4.1
PeAgent Host Context Hierarchy
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 accesses to its resources and to allow agents to conveniently specify the sharing privilege
of their assets, we have incorporated the “context hierarchy” concept.
A context hierarchy is a tree structure as illustrated in Figure 3. The root context is created when a
PeAgent host starts up. Under the root context, additional contexts can be created by the PeAgent host or
by other privileged users who sends a context creation request to the PeAgent host. 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,
the user needs to provide the context key for privilege verification.
11
Root Context
Context A
Agent A
Context C
Agent C
…
Context B
Agent B
Agent D
Context D
…
…
Context E
Agent E
…
…
…
Figure 3. The context hierarchy.
Specific resource access privileges and quota can be defined on each context by its creator. Host-wide
access constraints and resource quotas can be given to the root context. The policies for privilege/quota
definitions on sub-contexts 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 contexts and agents in C’s subtree 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 100 MB disk quota is given at
the root context. It means that the PeAgent host provides 100 MB 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 4 agents should be less than or equal to 100 MB.
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 privileges, socket communication privileges, socket port quota, device access privileges, and
CPU time (execution time) limits.
A policy is needed to distribute the quotas 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 sub-context CS is created under a parent context CP, CS’s resource quota is determined
by a default distribution policy. When new sub-contexts are created under CP, quotas allocated to CS may
be reduced due to the demands from other sub-contexts. Similarly, if the agents under CS demand more
resources and there are more resources available under CP, then the resource quota for CS can be
increased. To flexibly control the agent activities is essential in achieving better system performance and
12
security. The resource manager also keeps track of the statistical resource usage information of the agents
and the overall system. If the available resource ratio falls below a certain pre-defined threshold, the host
may force some agents to migrate to other hosts. In this way, system performance can be guaranteed and
denial-of-service attack can be prevented.
4.2
Agent Privilege Negotiation
Though the owner of an agent can define its access privileges and resource quota, consensus has to be
reached with other entities in the system. The list of the authorities and the negotiation protocol for
deciding the final access privileges and resource quota for an agent on a specific PeAgent host is given in
the following.
 User. The user who creates the agent specifies the desired access privileges and quotas.
 GCA and DCA. The domain certificate given by the GCA specifies the limitations of access privileges
and resource quotas for all agents in the domain. DCA can further specify access limitations for
specific agents in the domain according to its own policies and the trustability of the user.
 PeAgent host. The access privilege and quota of an agent can be further adjusted by individual
PeAgent host according to its local resource availability and security policies. A PeAgent host
specifies its general limitations in a configuration file and the information is loaded and assigned to the
root context when the PeAgent host is initiated.
 Context. Resource constraints assigned to the context of the agent further confines the access
privileges and quota of the agent. The decision is made by the resource manager based on the demands
of the agent and other agents in the same context.
When an agent is created, the source server obtains agent certificate and domain certificate from the
domain server. Resource constraints for the agent are set to the minimum of what the user demands and
constraints specified in the domain certificate. The PeAgent host further makes local adjustments to the
resource limitations based on the local resource availability and constraints. If the resource requirement
specified by an agent is greater than the resource limitations enforced by the PeAgent host (including the
general constraints and the specific ones imposed at the context), then the agent creation request should
be either rejected or the resource constraints for the agent should be further tightened. The user can
specify the mode “Abort” or “Reduce” during agent creation time to instruct the PeAgent host to make
the corresponding decision.
4.3
Context Hierarchy and Protection of Agent Assets
As discussed earlier, each agent can migrate with some assets. Proper mechanisms should be
provided to allow agents to specify their own access control policies for their assets. Access control
13
specification for agent assets is also based on the context hierarchy. The possible specifications for asset
sharing are as follows:
Owner. The asset can only be accessed by the owner agent.
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 belonging to C can access F.
ContextSubtree. Consider an agent A and its asset F. Assume that A belongs to the context C. If F’s
sharing privilege is specified as “ContextSubtree”, then all agents belonging to C or any context that is in
C’s subtree can access F.
All. The asset can be accessed by all agents on the current PeAgent host.
The access privileges can be specified for each agent asset. The PeAgent host keeps track of the agent
assets and their access control information in order to enforce fine-grain access control policies.
4.4
The Proxies
PeAgent provides fine-grained access privilege specification and control. The protection mechanism
provided by JVM (the security manager) can only perform a coarse-grain privilege control. Many existing
MA systems implement additional logic within the security manager to provide better access controls.
However, two problems arise when implementing fine-grain protection mechanisms within JVM’s
security manager. First, when the security manager is invoked by an agent, it resides in the same thread
space as the agent. To support fine-grain access control, information for the agents (agent control block)
and resources (access privileges, input stream pointers, sockets, etc.) should be maintained by the security
manager. If the security manager has the privilege to access the information, so does the agent, since they
are within the same thread. The agent, thus, can obtain or even modify all the information and gain
accesses to all the resources. Also, when the security manager checks the resource properties (such as file
size), the check operation will be recursively trapped by the security manager and, hence, the task can
never be achieved.
In the PeAgent system, we use proxies to enforce security policies and monitor resource usages. The
PeAgent host starts two thread groups, one for the execution of agents and the other for the system level
operations. The customized security manager disables critical resource access operations for agent thread
space. Additional APIs for critical resource access operations are provided to the agents, which simply
forward the access request and agent ID to the corresponding proxy queue. A proxy, upon receiving an
access request, performs security and resource checks. The proxy also suspends the agent thread and
resumes it when the operation is completed and the response is placed in the queue. The interaction
protocol between an agent and the proxy is illustrated in Figure 4.
14
Agent Thread
Proxy Queue
(1) Agent thread invokes Queue
class’s addRequest() method
to put request into the queue.
(2) Agent thread blocks
(3) Agent thread resumes
(4) Agent thread invokes Queue
class’s getResponse() method
to get response from the
queue
RequestQueue
Put the request
Proxy Thread
(1) Proxy
thread
invokes
Queue class’s getRequest()
method to get request from
queue
Get the request
Send Wait signal
and block the
corresponding
agent thread
Send Notify signal and
resume corresponding
agent thread
..
.
(2) Processing, such as
security check
(3) Proxy thread invokes
Queue class’s
addResponse () method to
put response into queue
..
.
Put the response
ResponseHashTable
Figure 4. The basic proxy protocol.
We use one proxy for the control and management of each type of resources. In the current PeAgent
system, there are three major proxies, the file proxy, the network proxy, and the thread proxy. The design
details for these proxies are given in the following subsections. All proxies access the Agent Control
Block (ACB) table, which stores all the information related to individual agents. Figure 5 shows the main
fields maintained in the ACB. The PrivilegeObject field specifies the access privileges of the agent to
system resources, including access privileges for files, network resources, and threads. It contains the
actual privileges granted after the negotiation. The ResourcesUsage field keeps track of the current and
statistical resource usages of the agent. The “ProtectionObject” field specifies the agent protection level.
The FileObject, NetworkObject, and ThreadObject fields are used by the file, network, and thread
proxies, respectively, and will be discussed in the following subsections with the corresponding proxies.
The LocationManager field stores the URL of the location manager and the itinerary for the agent.
AgentId
Agent (object reference)
AgentStates
RresourcesUsage
PrivilegeObject
Protection Object
FileObject
NetworkObject
ThreadObject
LocationManager
Figure 5. The ACB data structure.
15
4.4.1 File Proxy
The file proxy monitors agents’ file I/O operations. It accesses three data structures, including the File
Table maintained by the file proxy and the PrivilegeObject and FileObject maintained in ACB. Each
agent has specific file access privileges and disk quota, which is specified in the PrivilegeObject in ACB.
File access privileges specify agent’s privilege to read various system files and/or to create temporary
files. Disk quota is the total disk space the agent can use to store its own files. If the disk quota for an
agent is 0, then it cannot carry any data files to the host or create new files at the host. FileObject is a list
that keeps track of the files owned or accessed by the agent. Each entry in the list contains an object
reference to the corresponding file entry in the File Table. Actual information related to the file is stored
with the File Table. When the agent terminates, the list is used to ensure that all files accessed by the
agent are closed if no other agents are accessing them. During agent migration, the list is referenced to
gather files that are to be migrated with the agent (a “Migrate” mark is also maintained in the FileObject).
File name
File owner
Access privilege
CanAccessConcurrently
OpenerList
FileStream
Figure 6. The File Table data structure.
File Table, as shown in Figure 6, maintains information about all files that are owned or accessed by
active agents at the agent server. The AccessPrivilege field specifies whether read or read-write accesses
to the file are allowed for agents in the Owner, Context, ContextSubtree, and All groups (which are
defined in Section 4.3). The CanAccessConcurrently field indicates whether the file can be accessed
concurrently. A list of agents that are accessing the file currently is maintained in the OpenerList field. A
file is closed if the OpenerList is empty. The FileStream field stores the file reference of the physical file.
To avoid unnecessary overhead, the file proxy only processes the open and close operations. The
PeAgent APIs, such as PAObjectInputStream and PAFileInputStream, are provided to the agents. The
agents can use PeAgent APIs, instead of Java APIs, to open files. The file pointers are maintained within
the proxy. An agent cannot read or write a file without first opening it to obtain the file reference. Since
read and write operations are far more frequently used than the open and close operations, this design
does not incur much performance overhead.
16
4.4.2 Network Proxy
Network proxy controls the agent communication activities. It accesses the PrivilegeObject and
NetworkObject maintained in ACB. The information maintained in the PrivilegeObject for the network
proxy include the network access privileges (including whether the agent can create UDP, TCP-client or
TCP-server sockets) and network resource quota (including the constraints on the number of UDP/TCP
ports and the range of the listening ports) of the agent. The NetworkObject keeps track of the channels
(the sockets) established by the corresponding agent. It is used to ensure that all ports are freed after agent
termination or migration. It also provides the total number of various types of ports an agent has, which
can be used for enforcing the network resource quota.
The operations for opening and closing sockets have to be processed by the network proxy. The send
and receive operations can be performed directly in the agent thread. The security manager blocks Socket
creation and connection to achieve the objective. Thus, the frequently invoked send and receive
operations do not incur unnecessary overhead. However, UDP protocol does not require a pre-established
channel and the channel is established during each send operation. Thus, UDP send operation does incur
the overhead of going through the proxy for security checks.
4.4.3 Thread Proxy
ThreadObject is used by thread proxy to record how many threads this agent has spawned. An agent
can easily launch a denial-of-service attack by spawning many threads, which consume critical system
resources such as CPU and memory. Thus, there should be a limit on the number of threads an agent can
create. The thread proxy provides thread services for agents including creation, interruption, suspension,
and termination. The PrivilegeObject in ACB maintains the limit of the number of threads the agent can
create. The ThreadObject maintains the list of threads an agent has created.
The security manager blocks Java JDK thread related operations so that the agents cannot create
threads directly. An agent sends a thread creation request to the thread proxy. The proxy processes the
request and returns a wrapped-up reference of the created thread to the agent.
5 Protecting Agents against Malicious Hosts
We identify three phases in an agent’s life-cycle, including the migration, caching, and execution
phases. Agent protection is considered for these three phases. A creator of the agent can specify the
desired level of protection for the agent in each phase. In some protection modes, the protection
mechanism has to be consistent for all three phases and, hence, independent specification will not be
allowed. Agent protection should also include the protection of the agent itself (including code and state)
and the protection of agent assets. The protection levels for the agent itself and each agent asset can also
17
be specified individually according to the requirement of each unit. Again, in some special protection
modes, consistency is required and independent specification will be disallowed.
For the migration phase, the protection levels include “None” (no protection needed), “Integrity”
(only needs integrity protection), “Privacy” (only needs privacy protection), “Full” (needs privacy and
integrity protection), and “Partitioned” (a special mode that will be discussed later). In case protection is
needed (other than “None”), the sender and the receiver of the migration process should negotiate a
session key at the beginning of the migration phase. According to the level of protection specified for the
agent, the key is used to sign and/or encrypt the agent and its assets.
An agent and its assets may be cached by an agent host. The protection levels for the caching phase
are the same as those of the migration phase. Generally, the protection level of the caching phase for an
agent is lower than that of the migration phase since the communication channels are accessible by the
public while a good access control protocol is available on agent hosts. If the user trusts the agent host,
then the protection level “None” can be selected to avoid performance overhead.
If an agent host is not to be trusted and/or the agent and its assets are highly critical, then we need to
consider the computation time protection. General integrity coding and encryption mechanisms cannot be
used for computation time protections since the host has to operate on the agent data in its original form.
Thus, the agent information can be compromised during this phase. In PeAgent system, we provide
computation phase agent data protection by using a secret-sharing mechanism proposed in [Ma02]. In this
approach, each data item is partitioned into n (n  3) secret shares and distributed to n processors. Nearby
PeAgent servers form a group of size n. The source server first decomposes sensitive data items into n
shares and assigns each share to one agent. Then, each agent, carrying one share of data, is sent to one of
the n PeAgent servers in the same group. At the computation time, 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 revealing the secret [Ma02]. We call this protection the “Partitioned”
level of protection. If the user desires the “Partitioned” protection, then this protection level is enforced
for all phases to ensure the effectiveness of the mechanism and the consistency of the protocol.
Partitioned secret shares are encrypted at the migration phase to ensure that no one can pick up all shares
in the public channel and assemble them to get the secret information.
PeAgent system offers an additional protection level for agent code protection, namely, “Obfuscated”.
Code obfuscation technique [Col97] is used to protect code at computation time against malicious
PeAgent servers. Obfuscation techniques transform a program into a form that is hard to analyze. It is
applied at the source server before the agent migrates. Thus, even though the PeAgent server can access
the code in its original form, it is hard to obtain any meaningful information. Generally, code obfuscation
18
only protects the intention of the code from being known easily. Prolonged analysis of the code can still
reveal its function.
6 Conclusion
In this paper, we discuss the issues in developing secure mobile agent systems. The design and
implementation of the PeAgent system have been presented. Several security mechanisms were used in
the PeAgent system 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 to achieve fine-grain
authentication and authorization. A context hierarchy is used at the PeAgent servers to support the finegrain specification of access control policies of agent-owned and host-owned resources. Various proxies
have been developed in the PeAgent system to enforce the security policies.
In the PeAgent system, security mechanisms are also provided to protect agents against malicious
hosts. Users are allowed to flexibly specify the desired protection levels for the agents so that the
protection is done in a cost-effective way without incurring unnecessary overheads. Sophisticated
protection schemes are also developed for the protection of highly critical agents. Furthermore, we
consider the migration and protection of agent assets that may be required in some applications. In the
PeAgent system, agent owners can specify the data objects that are migrated with the agent. Also, the
protection mechanism and sharing policies can be specified for each object independently.
A basic version of the PeAgent system has been completed [PeA]. The global protection protocol and
the domain hierarchy have been implemented in the GCA and DCA programs. The deployed PeAgent
server system supports the agent migration protocol, the context hierarchy, and the agent privilege
negotiation protocol. The file, network and thread proxies are implemented in the PeAgent server.
Additional proxies for the protection of other system resources such as CPU time and special devices
(cameras, special equipments, etc.), will be incorporated. Most agent protection mechanisms have also
been implemented in the PeAgent system. The computation time protection algorithms have been
developed and will be incorporated in the PeAgent system. Currently, We use PeAgent system for widearea distributed systems simulation studies and for Weblet Environment implementation [Hao03].
References
[Agl] “Aglets”, http://www.trl.ibm.co.jp/aglets, 2002.
[Aja] “Ajanta-Mobile agents research project”, http://www.cs.umn.edu/Ajanta, 2002
[Bel00] P. Bellavista, A. Corradi, and C. Stefanelli, “Protection and interoperability for mobile agents: A
secure and open programming environment,” IEICE Transactions on Communications, Vol. E83-B,
No. 5, May 2000.
19
[Bel01] P. Bellavista, A. Corradi, and C. Stefanelli, “How to monitor and control resource usage in
mobile agent systems,” Proc. IEEE International Symposium on Distributed Objects and
Applications, 2001.
[Col97] C. Collberg, C. Thomborson, D. Low, “A taxonomy of obfuscating transformations,” Technical
Report 148, Department of Computer Science, University of Auckland, New Zealand, July 1997.
[Cza98] G. Czajkowski, T. V. Eicken, “Jres: A resource accounting interface for Java,” ACM Conference
on Object Oriented Languages and Systems (OOPSLA), Vancouver, Canada, Oct. 1998.
[Far96] W. M. Farmer, J. D. Guttman, and V. Swarup, “Security for mobile agents: Authentication and
state appraisal,” Proc. European Symposium on Research in Computer Security (ESORIC), 1996.
[Fug98] A. Fuggetta, G. Picco, G. Vigna, “Understanding code mobility,” IEEE Transactions on
Software Engineering, Vol. 24, No. 5, pp. 352-361, May 1998.
[Gra98] R. S. Gray, D. Kotz, G. Cybenko, and D. Rus, “D'Agents: Security in a multiple-language,”
Mobile Agents and Security, Springer-Verlag, 1998, Giovanni Vigna (Ed.), pp. 154-187.
[Hao03] W. Hao, Q. Ma, I. L. Yen, and I. R. Chen, “A Weblet environment to facilitate proxy caching of
web processing components,” submitted to PDCS’03.
[Hoh97] F. Hohl, “An approach to solve the problem of malicious hosts,” TR-1997-03, Institute of
Parallel and Distributed High-Performance Systems, University of Stuttgart, Germany, Mar 1997.
[Kar97] G. Karjoth, D. B. Lange, M. Oshima, “A security model for aglets,” IEEE Internet Computing,
Vol. 1, No. 4, July/August 1997.
[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] Y. Minsky, R. van Renesse, F. B. Schneider, and S. D. Stoller, “Cryptographic support for faulttolerant distributed computing,” Proc. ACM SIGOPS European Workshop, Connemara, Ireland, Sept.
1996, pp. 109-114.
[Mud99] S. Mudumbai, A. Essiari, and W. Johnston, “Anchor Toolkit,” http://www-itg.lbl.gov/Akenti/
Anchor/ma99.html, 1999.
[Pha98] V. Pham and et. al., “Mobile software agents: an overview,” IEEE Communications, Vol. 36, No.
7, July 1998.
[PeA] “PeAgent,” http://escsb2.utdallas.edu/peagent, 2002.
[Pul00] A. Pulianfito, O. Tomarchio, and L. Vita, “MAP: Design and implementation of a mobile agents'
platform,” Journal of System Architecture, Vol. 46, No. 2, Jan. 2000, pp. 145-162.
[San97] T. Sander, “On cryptographic protection of mobile agents,” Proc. Workshop on. Mobile Agents
and Security, Univ. of Maryland, Oct. 1997.
[Sch97] F. B. Schneider, “Towards fault-tolerant and secure agent,” Proc. Int’l Workshop on Distributed
Algorithms, Germany, Sept. 1997.
[Sun] “JavaTM virtual machine profiler interface,” http://java.sun.com/products/jdk/1.3/docs/guide/jvmpi/
jvmpi.html, 2002.
[Wal98] T. Walsh, N. Paciorek, and D. Wong, “Security and reliability in Concordia”, Proc. Annual
Hawaii International Conference on System Sciences, 1998.
20
[Wee01] S. Weeks, “Understanding trust management systems”, Proc. IEEE Symposium on Security and
Privacy, May 2001.
[Wil99] U. Wilhem, “A technical approach to privacy based on mobile agents protected by tamperresistant hardware,” PhD Thesis, Department D’Informatique, Ecole Polytechnique Federale de
Lausanne, 1999.
[You97] A. Young and M. Yung, “Sliding encryption: a cryptographic tool for mobile agents,” Proc. Int’l
Workshop on Fast Software Encryption, 1997.
21