Paper for IFIP Middleware 2000, Work in Progress Session

s-agent: The Design of Secure Mobile Agent System

Satoshi Makino1, Tadashi Okoshi1, Jin Nakazawa1 and Hideyuki Tokuda1,2 1Graduate School of Media and Governance, Keio University 2Faculty of Environmental Information, Keio University 5322 Endo, Fujisawa, Kanagawa, 252-8520 Japan Tel: +81-466-47-5111 Fax: +81-466-47-0624 {mak,slash,jin,hxt}@ht.sfc.keio.ac.jp

Abstract. This paper proposes a secure mobile agent system s-agent. There exists a wide range of security issues in using mobile agents. We categorized the attacks against mobile agent security into three: attacks by hosts against agents, ones by agents against hosts and ones between agents. s-agent system provides an architecture which covers these three categories of attacks. Existing researches solve some parts of the problems, leaving the others still unsolved. For the agents to be widely used, as many problems as possible must be solved. This system is distinctive in its inter-agent access control. Modification detection and DoS-attack-resistant security manager are also featured. s-agent: The Design of Secure Mobile Agent System

Abstract. This paper proposes a secure mobile agent system s-agent. There exists a wide range of security issues in using mobile agents. We categorized the attacks against mobile agent security into three: attacks by hosts against agents, ones by agents against hosts and ones between agents. s-agent system provides an architecture which covers these three categories of attacks. Existing researches solve some parts of the problems, leaving the others still unsolved. For the agents to be widely used, as many problems as possible must be solved. This system is distinctive in its inter-agent access control. Modification detection and DoS-attack-resistant security manager are also featured.

1 Introduction

Mobile agents are the programs which migrate among hosts continuing their executions. They pro- vide many benefits for the users. For example, intelligent information processing by their autono- mous migrations can be possible. In addition, the programmers can easily implement complex network program, since it is abstracted into simple move operation of the agent (e.g. agent.move- To(“Tokyo”); in pseudo code). They are promising as the new platform for distributed computing. Despite the benefits mentioned above, mobile agents also bring some serious security problems. Hosts cannot expect what the agents they have accepted will do. And in turn, agents cannot expect what the hosts they have visited will do. Who is intended to make the agent do the particular action on the particular host becomes uncertain, since the agent migrates among the hosts. Therefore with regard to mobile agents, exactly who is on the fault (that is, who is responsible for the agent) is very difficult to determine. The possible attacks listed below are illustrated in Fig. 1, where an oval or a rectangle with solid lines mean an entity and an arrow means the data flow. Attacks listed in a rectangle with broken lines are possible in the corresponding data flow. We define the security attacks against mobile agent systems as classified into the following three categories:

- 2 - Agent Other Agent s - Stealing / - Stealing / Modifying Data Modifying Data - Masquerading - DoS Attack

Current Host

Fig. 1: Examples of possible attacks

Attacks by Agents against Hosts Malicious agents can steal or modify the data on the host. They can also commit Denial of Ser- vice (DoS) attacks. Attacks by Hosts against Agents Malicious hosts can attack the agent, by means of stealing or modifying its own data. Mas- querading the agent is also possible. Attacks between Agents Malicious agents can also attack another agent by stealing or modifying their data, as the hosts do.

Although other attacks can be possible[1], such as eavesdropping the agent in transfer and com- mitting Denial of Service (DoS) attacks on the network layer or below, this paper does not cover them. We regard these problems as the network security problems rather than the mobile agent security problems, to be solved elsewhere. This paper offers an architecture which solves these three problems. In section 2, some related works and their common problems are shown. In section 3, the design goals of s-agent system are discussed. In section 4, the design detail of s-agent is clarified. Section 5 summarizes this paper.

2 Related Works

Ajanta[2], SignedObject, GuardedObject and SealedObject (SGS)[3], Embedded Cryp- tographic Systems (ECS)[4] and Computing with Encrypted Data (CED) [5] are designed for security-aware mobile agent systems. Their functionalities corresponding to the problems in section 1 are summarized in Table 1. Table 1: Comparison of related works

Ajanta SGS ECS CED Access Control by OK OK NG NG Hosts against Agents DoS Attack NG NG NG NG Prevention - 3 - Access Control by Only Write Only Read Only Read Only Read Agents against Hosts Protection Protection Protection Protection Inter-Agent Only Only NG NG Access Control Isolation Isolation As shown in Table 1, the following three points are not achieved in any researches:

・ Selective inter-agent access control ・ DoS attack prevention ・ Selective access control by agents against hosts

These researches do not solve all the problems at once. Partial solutions do not help users to use mobile agents securely. More general solution must be provided.

3 Design Goals

This section clarifies the objectives in designing our mobile agent system s-agent , which stands for Secure Agent. To solve the problems mentioned above, we set up the following five goals.

Reflection of the Agent-Side Policy The notion of protecting the agents or particular objects from others had not introduced until mobile agents appeared. Thus in conventional mobile agent systems, security policy only on the host side is considered. In such systems agents cannot have the security policy. In order to avoid the invalid access from the other agents, an access control list (ACL) is at - tached to each agent and the host includes the ACL into its own security policy. Selective Access Control In some conventional access controlling context, target objects are simply isolated in some re- stricted environment (e.g. “sandbox” in Java language). In such an environment the objects cannot communicate with each other freely and that is inflexible. Highly granulated and flexible access control is needed, such as granting accesses only to a certain data and not granting a certain function invocation to a certain entity. Transparent Access Even if agents are under the context of access control such as isolation, they should not be aware of the security mechanism. That is, agents can directly access other agents or objects using the regular syntax of the pro- gramming language (e.g. otherAgent.someMethod(); in pseudo code), to occur a security exception and fail if the access is against the security policy, or to normally succeed otherwise. Detection of the Modification against Agents Since agents are executed as the objects on the host, hosts can freely read and/or modify the status of the agent. There is no way to completely prevent this. s-agent system offers a mechanism for detecting the modification on agents after it occurred and one for specifying the host actually committed the modification, as an alternative measure.

- 4 - Solution in End-to-End It is possible to set up third-party hosts and delegate them to perform some task such as an audit, which is unrealistic because it is impossible for the trustworthy hosts to exist everywhere. It is also difficult to decide which host to trust. Therefore, we take an end-to-end approach, making the system simple and easy to use.

4 System Design

This section describes the design details of s-agent. Fig. 2 illustrates the system design of s-agent. Items listed in the rectangle with broken lines mean the measures taken to the security attacks described in section 1. As shown in Fig. 2, all the attacks listed in Fig. 1 are covered by s-agent system: inter-agent access control protects the agent from other malicious agents, modification detection protects the agent from malicious hosts, and DoS-attack-resistant security manager protects the host from malicious agents.

4.1 Assumptions s-agent system assumes the following two things: - DoS-Attack-Resistant Security Manager

Agent Other Agent s - Inter-Agent Access Control

- Modification Detection

Current Host

Fig. 2: Measures taken in s-agent system

Java Language Security Model s-agent system is based on the security model of Java language[6]. This system makes use of Java SecurityManager Object, SignedObject, and so on. RSA Key Pairs All the users who dispatch their agents and the administrators of the hosts are supposed to have

- 5 - their own RSA key pairs[7]. And These keys are supposed to be obtained in some reliable ways, which this paper does not cover. These keys are used to identify the entities and to encrypt and decrypt data.

4.2 Inter-Agent Access Control s-agent system provides a mechanism for the access control between agents per each method. In this mechanism, the hosts are supposed to be trustful. For the convenience of explanation, let us assume a shopping mobile agent implemented as an agent in s-agent system. The following code fragments are written in pseudo code. All the variables agents have are declared as private, and they have the corresponding accessor methods, for example:

private long creditCardNum; public long getCreditCardNum(); public void setCreditCardNum(long num); Agents have their own ACLs containing each method name and the source of the agent which they grant to invoke the method. These ACLs are implemented as an array of ProtectionDomain objects in Java, as follows:

ProtectionDomain[] pd = new ProtectionDomain[]; CodeSource cs = new CodeSource(url, signersCertificate); Permissions ps = new Permissions(); ps.add(new MethodInvokePermission(“getCreditCardNum”); pd[0] = new ProtectionDomain(cs, ps); pd[1] = ...

In this pseudo code, if the class file of the agent is downloaded from url and the file is signed by signers, the agent can invoke the method getCreditCardNum. The pseudo code above is equivalent to the following entry in Java policy file:

grant signedBy signers, codeBase url { permission MethodInvokePermission “getCreditCardNum”; } ...

SecurityManager is called in every invocation of security sensitive method, as follows:

- 6 - public long getCreditCardNum() { System.getSecurityManager().checkPermission (new MethodInvokePermission(“getCreditCardNum”)); return creditCardNum; }

When the agent arrives at a host, the host reads the ACL of the agent and merge it with its own ACL, as long as not affecting the current security policy (Policy object) on the host.

void onAgentArrival(Agent a) { ProtectionDomain pd = a.pd; Policy p = Policy.getPolicy(); for(each permission in pd) if(permission not violate the host’s) p.merge(permission); Policy.setPolicy(p); }

As a result, any objects can invoke the getCreditCardNum method of the agent, and whether the invocation succeed or fail is decided on the SecurityManager at the host. When the agent leaves the host, the mergence is also canceled.

4.3 Modification Detection Modification detection means to clarify which host modified which agent and how. In case the computation results brought by the agent is against the expectation, the owner of the agent should be able to trace the route of the agent and see how the agent was executed at each host. To facilitate this, three functions are set up as follows:

Signature Sequence on the Agent-Specific Information The idea of Agent Ticket is introduced. Agent Ticket consists of the date the agent was originat- ed, a sequence number, the name of the source host and the hashed value of the agent Class object. Thus the uniqueness of this ticket is kept through the migration route of the agent. All hosts on the route of the agent must digitally sign the ticket sequentially. By this conven- tion, the route of the agent can be verified with the sign. Since these tickets are linked to the Class objects, malicious agents cannot reuse the ticket of another agent. A sample of an Agent

- 7 - Ticket and the signature sequence are illustrated in Fig. 3. Agent Ticket

Date SeqNum Orig. Host Class Hash

Signature Sequence

Agent Ticket Sign of Host A Sign of Host B ......

Fig. 3: An Agent Ticket and the Signature Sequence

Signing on the State of Agents In the migration of an agent, the source host must digitally sign the current status (serialized form) of the agent. This prevents masquerading of the agent by other hosts and non-repudiation of the computation results. Storing Agents In advance of the agent migration, serialized form of the agent and its destination are stored in the source host for a certain period of time. In case of a trouble on the agent, the host which have caused the trouble can be specified by verifying the stored agents on each host.

4.4 DoS-Attack-Resitant Security Manager Modified Java SecurityManager object is used to protect the host from the DoS attacks on the application level. In the attempt by the agents to create an agent or to access the critical computing resources, the ticket of the attempting agent with the signatures on it is logged by the security manager. This feature is implemented as follows (pseudo code):

public class SAgentSecurityManager extends SecurityManager { public void checkPermission(Permission perm) { log(agent.getAgentTicket(), perm); super.checkPermission(perm); } }

- 8 - The administrator of the host can detect the invalid or wasteful access and can specify the agent which committed the attack by analyzing the log after the DoS attack occurred, therefore the attack on the application level will be avoided afterwards.

4.5 Discussion: Still Possible Attacks Some kinds of attacks are still possible even in the s-agent system, such as:

Hit-and-Run Attacks Since the modification against the agent and DoS attacks can be detected only afterwards, it is possible for the attackers to commit some attacks and hide themselves after that. Fake Sufferings Malicious entities can claim to have been suffered by others, even if in fact they are not suffered at all.

Although these attacks are actually possible, they are less likely to be, because the entities in s-a- gent system are tied with their signatures, making it easy to specify their identities.

5 Summary and Current Status

Mobile agents bring the users many security issues as well as their numerous benefits. The security issues are classified into three categories, corresponding to the attacker and the sufferer. Existing researches such as Ajanta and SignedObject etc. solve only a portion of three problems, not helping the users to use mobile agents. This paper proposes s-agent which covers whole three problems. Inter-agent access control mechanism prevents attacks between agents, DoS-attack-resistant security manager protects the resources on the host against malicious agents and modification detection mechanism helps users specify who have modified the agent and how. Currently we are implementing s-agent system. It is expected to finish the implementation by February 2000. As a future work, modeling the inter-agent communication based on s-agent system is planned. The model will help users describe agents easily by some templates.

References

[1] F. Hohl, An Approach to Solve the Problem of Malicious Hosts in Mobile Agent Systems, Univer- sität Stuttgart, Fakultät Informatik, Bericht Nr. 1997/03. [2] N. M. Karnik et al., Security in the Ajanta Mobile Agent System, Technical Report, Department of Computer Science, University of Minnesota, May 1999.

- 9 - [3] L. Gong et al., Signing, Sealing, and Guarding JavaTM Objects, in G. Vigna (Ed.): Mobile Agents and Security, LNCS 1419, pp. 206-216, Springer, August 1998. [4] E. R. Palmer et al., An Introduction to Citadel - A Secure Crypto Coprocessor for Workstations, in proc. of 10th International Information Security Conference IFIP SEC'94, Curacao, Dutch An- tilles, May 1994. [5] T. Sander et al., Towards Mobile Cryptography, in proc. of the 1998 IEEE Symposium on Securi- ty and Privacy, Oakland, CA, May 1998. [6] S. Oaks, JAVA Security, O’Reilly & Associates, February 1999, ISBN 1-56592-403-7. [7] C. Kaufman et al., Network Security: Private Communication in a Public World, Prentice Hall, March 1995, ISBN 0-13-061466-1.

- 10 -