Language support for secure mobile agents Shigeru Chiba
Kenji Kono
Institute of Information Science and Electronics University of Tsukuba
Department of Information Science University of Tokyo
[email protected]
[email protected]
Abstract
This paper deals with language supports for protecting mobile agents from untrusted servers, which may be potentially malicious. It rst discusses the features that mobile-agent systems should provide for ideal security, and then presents the mobile agent system called Krypton, which we are currently developing. Krypton is a mobile-agent system that provides higher-level abstraction for the programmers to easily de ne secure mobile agents against potentially malicious servers.
1 Introduction Mobile agent [7] is an emerging paradigm for constructing distributed systems. The client-server paradigm, which is popular nowadays, introduces asymmetry into the systems; the servers are always passive but they can never transfer data to the clients except when replying the requests from the clients. On the other hand, the systems based on mobile agents are symmetric. The agents can act as either a client or a server. They can send a request to another agent and also receive a request from another. This feature gives the system designers greater exibility. It makes it easier to develop a system that needs complex communication among distributed computers. As far as we know, there are no consensus of the de nition of the agents. In this paper, we use the word \agent" to mean a concurrent object autonomously moving from a \server" to another. Here, the server means a 1
platform (or an interpreter) running on every machine to execute the agents. It receives agents from another server, executes them, and sends them to another if needed. Since the agents are concurrent objects, the system is multi-threaded. An agent may include more than one thread at a time, and hence synchronization within the agent is explicitly controlled by the programmer as in the Java language [4]. The focus of this paper is security issues of mobile agents. The mobility of the agents largely enhances the need for security mechanisms since the system may include unidenti able agents and untrusted servers [3, 5]. Especially, we discuss mechanisms to protect mobile agents from malicious servers. Although the mechanisms for protecting the server and the underlaying operating system from potentially malicious agents, which come from untrusted sites, are actively investigated, the research community is not paying much attention to the mechanisms for protecting agents from potentially malicious servers. However, the protection from malicious servers cannot be neglected in practice. For example, if an agent holds private data such as a credit card number, then the agent system needs to prohibit the server that the agent visits from reading the private data without appropriate permission. In the rest of the paper, we rst show features that ideal secure agent systems should support, and then present a prototype design of our secure agent system called Krypton. This system provides language mechanisms for the programmers to use the underlaying lower-level security mechanisms and de ne secure agents. We believe that these mechanisms make it easy to de ne secure agents as well-designed parallel languages facilitate to program parallel computing. On the other hand, since Krypton is made feasible with reasonable performance, it does not support all the features that ideal secure systems should support. We also discuss the tradeo between the feasibility and the degree of security.
2 Security for mobile agents Security is one of the most important design issues of agent systems. Because of the power of the agent paradigm, the system needs more complex mechanisms than the client-server systems to keep privacy of computation and guarantee that an agent can access other agents only if it has the right permission. If a mobile-agent system is secure, it should satisfy the following three criteria. (1) The system should keep the privacy of the communication be2
tween the servers. (2) It should protect the servers from potentially malicious agents. (3) Also, it should protect the agents from potentially malicious servers. This paper mainly deals with the last criterion | the protection from malicious servers. As for the rst two criteria, a lot of research work has been already done. In this section, we rst overview the status of the art for the rst two criteria, the privacy of the communication and the protection from malicious agents. Then, we mention details of the last criterion, which this paper deals with.
2.1 Privacy of the communication
The rst criterion is the protection from the world out of the agent system. Any agent system cannot guarantee the perfect security if the underlaying operating system or network do not provide security at a sucient degree. Especially keeping the privacy of the communication through the internet is a considerable issue since the internet is open to the public, which may include untrusted sites. To keep the privacy of the communication, the underlaying network system should be able to:
Hide the contents of the communication. The data transferred between the servers should be protected from the outside snoopers. For example, credit card numbers included in an agent should be kept secret while the agent is moving on the network. Hide who are communicating. Some people may also want to keep it secret. For example, if a company uses an agent to purchase materials for their new products, they would not want their competitors to know that they send the agent to the server of the company selling the materials. Prevent spoo ng by the outside programs. The agent system should prevent the outside programs for pretending to be one of the trusted server of the system. For example, it should be impossible that someone runs a server that pretends to exist on a trusted host of a major bank.
To keep the privacy of the communication mentioned above, a few infrastructure for secure communication has been developed. One of the famous 3
infrastructure for this is SSL (Secure Sockets Layer)[2]. SSL enables a secure TCP/IP connection, which prevents snoopers who are monitoring the network from stealing data exchanged through the connection. Since SSL includes an authentication mechanism, it also prevents spoo ng by the outside program. However, SSL cannot be used to hide who are communicating because SSL is implemented on top of the TCP/IP layer. The TCP/IP packets include source and destination IP addresses for the packet routing, and hence it is extremely dicult to prevent someone who can snoop the TCP/IP packets from knowing where the packets come from and go to. This problem may be addressed by the next version of TCP/IP called IPv6. The privacy of the communication is usually provided by operating systems or the middleware layer like SSL. Our thought is that this level of security should be invisible from the language level of the agent system, that is, no explicit language support is needed. The agent system should simply use the mechanisms provided by the operating system or the underlaying middleware and transparently keep the privacy of the communication.
2.2 Protection from malicious agents
The second criterion is the protection from malicious agents. Since the server may receive an agent from an untrusted server, it needs to have a mechanism for the protecting the server from the malicious attack from that agent. For example, the malicious agent should be disable to: Know which agents are running on the server. Without explicit permission, it should be impossible for agents to obtain the list of the other agents running on the server. This list can be a hint for breaking the security mechanism, and also exposing this list is invasion of privacy for some people. For example, they may want to keep it secret to send an agent to the server for purchasing something there. Read the internal states of other agents on the server. The internal states of agents should be accessible only through authorized protocol. Since agents may include secret data, such as a credit card number or a password, the server needs to hide those data from malicious agents. Invoke methods of other agents without permission. For the same reason as the item above, only agents with permission can invoke the methods of other agents. 4
Perform prohibited computation such as reading a le on the local disk of the server. Agents should be able to access external resources such as a le system and a network. However, the ability of the agents to access the external resources should be limited to avoid making security holes.
To summarize the items shown above, the server should force the access control mechanism to any agent including potentially malicious ones. Doing this is not dicult if the execution performance is not crucial and the server can interpret agents. If interpreted, cheating the access control mechanism of the server is extremely dicult for the agent. On the other hand, if the execution performance is crucial and the program of the agent is compiled into machine code, forcing the access control mechanism is not straightforward. Inspecting whether the machine code is subject to the access control mechanism is dicult and a few techniques to address this problem has been developed. For example, sandboxing [6, 1] enables to isolate an agent in a fault domain implemented by software. Otherwise, the server has to give up forcing the access control mechanism, and thus accept only the agents digitally signed to guarantee that they are not malicious.
2.3 Protection from malicious servers
The last criterion is the protection of agents from malicious servers. The agent system we present in this paper was designed for addressing this criterion. It provides language mechanisms to help the programmers facilitate the underlaying encryption mechanism and de ne agents secure against malicious servers. Since the server is the platform for running agents, it inherently has the unlimited ability to read and modify the program and the internal states of the agents. However, the ideal agent system should disable any server for (1) stealing private data contained by an agent and (2) \brainwashing" an agent to steal private data from other severs or to spread false information. These two kinds of ability are major sources of attacks on innocent agents by malicious servers.
Stealing private data. A malicious server may read the internal state of the agent and nd secret data such as credit card numbers and passwords. Or, the malicious server may read the program of the agent and collect the information 5
on what the user who created the agent wants to do. Furthermore, the malicious server may read both the internal state and the program of the agent, and then replicate the agent. The replicated agent can be used for confusing and cheating other agents. Brainwashing an agent. If the malicious server brainwashes the agent, the server can use it to give false information to the user who created the agent. Suppose that you want to buy the most discounted ticket from Tokyo to Toulouse. You will create an agent and send it to the servers of several airlines. The agent you create will talk there to the agent of the airlines and nd the most discounted ticket. If one of the airline is malicious, the server may brainwash your agent and force it to report to you that the best ticket is of the airline's ight going via Chicago. The brainwashed agent is useful not only to send false information but also to illegally access an agent running on a trusted server. Because the brainwashed agent still has the access permission that the agent had before being brainwashed, the malicious server can rewrite the program of the brainwashed agent and make a new agent that steals private data from other agents with the illegally obtained permission. Then, the malicious server can send that agent to a trusted server and easily steal private data from the agents running there. If the agent can directly send a message to another agent on a di erent server through a network, the malicious server may not need modifying the program of that agent to illegally access agents running on other servers. The server can send a false message as if it is actually sent by the agent. The server receiving it cannot distinguish whether the message is false or not.
3 Krypton We above mentioned what a secure agent system should disable for protecting the agents from potentially malicious servers. In this section, we present the preliminary design of the mobile agent system, Krypton, that we are currently developing. The design goal of this system is to provide language mechanisms for protecting the agents from malicious servers.
6
3.1 Overview
Krypton is a mobile agent system with some security mechanisms. The Krypton agents are concurrent objects written in a Java-like language and they can autonomously move from a server to another. As for the model of the concurrency and synchronization, we are simply using Java's one for the time being. The programmers can explicitly make a new thread of control and specify synchronized methods, and so on. The unique features of the Krypton agents against regular Java objects are that the agents can move from a sever to another and they have mechanisms for security. We show details of those features below.
Moving between servers
The Krypton agents can autonomously move from a server to another. They can move to a di erent server and call a method of an agent running on that server. On the other hand, this is the only means to communicate with a remote agent. The agents cannot directly send a message through a network to talk to agents running on di erent servers. They need to explicitly move to that server where the agents they want to communicate with are running. If an agent move to another server, the agents (i.e. objects) contained by that agent are moved together to that server. The server collects all the agents pointed to by the elds of the agent that moves, and the server moves all of them together to the destination server. This design would give the readers a question | what happens if an agent is shared by two agents and one of the two moves? Krypton simply addresses this problem. The shared agent is duplicated when it is moved together with one of the agents sharing it; one remains at the server and the other moves together to another server. Moreover, to control the duplication of the shared agent, Krypton provides a special kind of pointer called weak pointer. If the agent is pointed to by a weak pointer, it is not duplicated or moved when the agent including the weak pointer moves. The reference of the weak pointer occurs a runtime error after the agent moves from the initial server.
Security
To protect agents from a malicious server, Krypton provides language mechanisms for the programmers. These language mechanisms encapsulate lowerlevel encryption mechanisms and enable the programmers to de ne secure agents with higher-level abstraction. The Krypton programmers do not have 7
to directly describe the algorithm for the protection in the programs of the agents. Instead, they can declare that the programs are write-protected, elds of the agents are read-only, and so forth. This feature of Krypton separates the policy and the mechanism for the protection, and hence, the implementor of the Krypton servers can alter the underlaying encryption mechanisms without rewriting the programs of the agents. This feature is signi cant because none can guarantee that any encryption mechanism is perfect or includes no security hole. The Krypton programmers can declare the following attributes:
Write-protected program: The programmer can prohibit the servers from modifying the program of an agent. The program is transferred with the digital signature between the servers, and the (trusted) servers check the signature to make sure that the program is not modi ed. Since all the agents are labeled the server where they are created, for example, the programmers can allow crucial computation only if the agent is created on a trusted server and its program is write-protected. To simply do this, the next attribute is useful. Execute-once method: The programmer can declare that a method of an agent can be called only by the agents explicitly permitted to call it. Also, the number of the calls that these permitted agents can execute is speci ed for each agent. For example, some agents may be able to call the method only once, and others may be able to call it until a certain time limit. Because of the limitation of the encryption technique, it is not feasible to guarantee that the execute-once method is correctly executed even on a malicious server. In the current design of Krypton, therefore, the agent with an execute-once method cannot move from the server where the agent is created. Or, if it moves to another server, the executeonce method is not e ective any more; it may be executed more than once. Read-only/Invisible eld: The programmer can declare that a eld of an agent is invisible or read-only except on speci c servers. For example, the eld can be made accessible only on the server where the agent is created. Or, the 8
programmer can allow only a group of trusted servers to update the eld and the other servers only to read it. If the eld is invisible, the value of the eld is encrypted by the private key of the server that can exceptionally access it. The other servers that do not have the private key cannot access the eld, and thus, if the program attempts to access it on those servers, a runtime error occurs. On the other hand, if the eld is read-only, the value of the eld is digitally signed with the private key of the server that can update the eld. All the servers can check the digital signature and make sure that the eld is updated by the authorized server. The program of the agent containing a read-only eld or an invisible one is automatically write-protected. Otherwise, a malicious server can easily cheat this security mechanism. For example, it can read the encrypted value of the invisible eld, make an agent containing that encrypted value. Then, it can send the agent to the trusted server that has the private key, and let the agent copy the value of the invisible eld to a regular eld of the agent. This copying succeeds since the trusted server has the private key. If the agent comes back to the malicious server, the decrypted value of the invisible eld is found in the regular eld. However, if the program of the agent is write-protected, the trusted server stops the copying the value of the invisible eld because the program of the agent is not correctly digitally signed. The invisible elds can be used to implement capability-based authentication. The authentication using execute-once methods is powerful but the range of its applicability is limited. The capability-based authentication allows a method call if the caller agent knows the callee agent, that is, the pointer to the callee agent. This authentication is workable if the pointer is correctly protected by the invisible eld. It is not as powerful as the authentication using execute-once methods, but more exible. For example, the access right is exchangeable between agents.
3.2 Connection to external authentication systems
In practice, the security system of Krypton should be connected to external authentication systems. For example, Krypton should be able to use login passwords for the authentication. Also, the programmers may want to give special permissions to agents coming from the same NIS domain. The connection to external authentication systems is \black-box"ed in 9
a implementation-dependent agent called a name server. The name server exists on every server and is used for agents coming from other servers to look up publicly accessible agents on the server. For example, the agent for purchasing a plane ticket will rst request the name server to look up an agent reporting the ight schedule. The name server performs the authentication when it processes the request, and it returns only the agents that the requesting agent can access. For example, if the requesting agent comes from a good customer's server, the name server will check the IP address of the server and return the agent that shows discounted prices instead of regular prices.
4 Discussion To protect agents from potentially malicious servers, Krypton provides higherlevel abstraction for the programmers. This achieves the separation of the policy and the mechanism for the protection, and thus, the programmers are released from concerning details of the encryption algorithms while the implementor of the Krypton server gets the freedom to alter the lower-level encryption mechanism if a security hole is found in the encryption mechanism currently used. In this section, we discuss how the language mechanisms provided by Krypton satisfy the criteria mentioned in Section 2.3 if the underlaying encryption mechanism correctly works. To make the system feasible, Krypton cannot satisfy part of the criteria and needs inconvenient restriction. However, we believe that Krypton is still workable in the real world.
Stealing private data
Without protection, a malicious server can read the internal state of the agent and steal private data such as a credit card number. This stealing is prevented if the private data is stored in the invisible eld. However, the defect is that the private data is only readable on a particular group of servers that have the private key for the decryption. Krypton has only the limited solution for the illegal duplication of agents. It cannot prevent a malicious server from duplicating an agent. Instead, Krypton provides a mechanism for minimizing the damage by the duplication as much as possible. For example, if the duplicated agent is digital cash, we need to prevent the duplicated agent from calling the method of the cyber bank's agent to transfer money to the attacker's bank account. This problem can be avoided by using the execute-once method. If the method 10
for the money transfer is an execute-once method, the duplicated agent fails to call that method at the second time because the duplicated agent shares the same identity as the original one's. Finally, Krypton cannot prevent a malicious server from knowing what the user who created the agent want to do with that agent. We do not have a mechanism to address this problem so far. It seems impossible to let a potentially malicious server execute the agent while prohibiting the server from reading the program of that agent.
Brainwashing an agent
The second criterion that Krypton should satisfy is to prevent brainwashing an agent. Brainwashing is executed by either modifying the program of the agent or modifying the elds of the agent. Krypton provides the write-protected program and the read-only eld, respectively, to address this problem. The defect of the Krypton's solution is that the server cannot update the read-only eld without the secret key even if the server correctly executes the program of the agent. This is because we cannot distinguish whether the server truly execute the program or not, but the ideal agent system should enable the servers to update elds of any agent while preventing a malicious server from brainwashing the agent. Another brainwashing technique is that the malicious server directly sends a false message to an agent on a trusted server as if that message is actually sent by an agent running on the malicious server. This technique is not e ective in Krypton since the Krypton agents cannot directly send a message through a network. To prevent this kind of brainwashing, all the communication in Krypton involves the movement of the agents. Although this slightly increases the amount of the packets transfered through the network, it simpli es the language. We believe that our decision on this issue is better than introducing a new mechanism for secure network communication like SSL [2].
5 Conclusion In this paper, we discussed the signi cance of the protection of mobile agents from potentially malicious servers. We rst overviewed the three aspects of the security for mobile agents. The rst was the privacy of the communication between servers, and the second was the protection of servers from potentially malicious agents. The last was the protection of mobile agents 11
from malicious servers, which is the main issue this paper dealt with. We mentioned that secure mobile-agent systems should prevent potentially malicious server to steal private data from mobile agents or to brainwash agents to give false information to the users. Then, we presented the preliminary design of our secure mobile-agent system called Krypton. It provides higher-level abstraction to help the programmers to de ne secure agents without concerning details of the encryption algorithms. Unfortunately, Krypton does not ideally protect the mobile agents from the malicious server because of being a feasible system. It involves inconvenient restriction to protect the agents. We also described the tradeo in our design of Krypton. The current design of Krypton is still at a preliminary stage. We will investigate security issues more and improve the design of Krypton through writing example programs.
References [1] Adl-Tabatabai, A., G. Langdale, S. Lucco, and R. Wahbe, \Ecient and Language-independent Mobile Programs," in Proc. of Conf. on Programming Language Design and Implementation, pp. 127{136, May 1996. [2] Freier, A., P. Karlton, and P. Kocher, The SSL protocol version 3, 1195. [3] General Magic Inc., \An Introduction to Safety and Security in Telescript," tech. rep., General Magic Inc., 1996. [4] Gosling, J. and H. McGilton, \The Java Language Environments: A White Paper," tech. rep., Sun Microsystems, 1995. [5] Ousterhout, J. K., J. Y. Levy, and B. B. Welch, \The Safe-Tcl security model," tech. rep., Sun Microsystems Laboratories, Nov. 1996. [6] Wahbe, R., S. Lucco, E. Anderson, and S. L. Graham, \Ecient Software-based Fault Isolation," in Proc. of ACM Symp. on Operating Systems Principles (SOSP), pp. 203{216, 1993. [7] White, J. E., Mobile Agents. MIT Press, 1996. To appear.
12
