Security and Agent Based Computing Environments
Security and Agent Based Computing Environment
Feng Zhang, Markus Kaiser, Hien Nguyen and Shu Wang
Department of Computer Science and Engineering
University of Connecticut
Abstract
This project aims at addressing the security issues in a multi-agent distributed goal satisfaction system (MADGS). We use the role-based security approach to protect the agent platform and agents themselves. We implemented two separated models in which the first model explores the user of JINI to provide security to agent environment and the second one builds a separated security component inside MADGS. We enforce the security polices from these two models on the main functions of MADGS including the agent migration and communication. We empirically compare these two models based on their performances, integrity and scalability.
1. Introduction
1.1. Motivation
Mobile agent technology offers a new computing paradigm in which a program in the form of an agent software can suspend its execution at an agent platform, transfer itself to another agent platform and resume its operations there. This technology also opens a new challenge in term of associated security in such a system. This term project is inspired by our interests of addressing security issues in a mobile agent system and our ongoing research of Multi-Agent Distributed Goal Satisfaction (MADGS) project. MADGS is developed by the University of Connecticut, Wright State University and Air Force Research Laboratory. It supports distributed mission planning and execution in a complex mobile agent environment focusing on distributed goal satisfaction. There are four main components in MADGS: Prodigy, Carolina Agent Server, Distributed Goal Satisfaction(DGS) and AgentTool[21]. Prodigy is a legacy planning tool. Carolina is an in-house agent execution environment developed at University of Connecticut[19]. DGS is in charge of adjusting the plan locally in case of insufficient resources, sub-goal failures or other unexpected events. AgentTool is a tool for design and validation that focuses on the creation, deployment and validation in an agent-based system [3].
MADGS currently doesn’t employ any security mechanism. Therefore, the users and designers of MADGS are facing of three main security threats. They are unauthorized access, denial of services and disclosure of information.
- Unauthorized access is used to refer to accesses of an agent or an agent platform to the resources that they do not have privileges to access to. Currently, in MADGS, there is no control over the process of agent migration and communication. An agent can move to any machine that runs the Carolina server environment. Therefore, any malicious agents can take bunch attacks on specific Carolina servers. Besides, there are no constraints over the process of sending and receiving messages among agents. Any agent can send any messages to any other agents. For example, a very low-level agent should not pass on information to a high-level agent without authorization. Again, without any control in message transmission, a bad agent can send a lot of trashed messages to any other agent and blocks the communication channel. From the stress test on MADGS system, we found out that the Java Virtual Machine will be out of memory if several agents just send out messages to each other without receiving messages since all these messages are kept on Carolina server until being read by targeting agents.
- Denial of services is used to refer to the attack from malicious agents or agent platform to other agents and platforms so that they block other’s agent requests to the being attacked objects. Currently, AgentTool can accept an online request from any agent when it needs to create a brand-new agent. Therefore a malicious agent can send as many requests as possible to AgentTool. This may lead to several severe situations. First of all, AgentTool may be overloaded. It has to process all of these requests even that they are useless. Secondly, Carolina server has to reserve resources for unnecessary agents, which consume memory and CPU time without bringing any benefits. Thirdly, uncontrolled requests will waste available network bandwidth. If we only let trustful agents send out their requests, all of these issues can be avoided. Another example is related to the request of resource allocation. In the air force mission planning domain, we use resource agents to manage military resources like planes, ships and ammunition. At this time, any agent can use these resources without any discrimination. This may lead to the situation where an agent can use up all of available tangible resources. We need a scheme that can distinguish agents and provide resources to those authorized agents.
- Disclosure of information is used to refer to the situations where the contents of the communication among agents or between agents and agent platforms are spied, copied, and updated without permissions. This issue is currently addressed by encrypting the message when it is sent and by decrypting the message when it is received. As message encryption can be realized by using SSL, Secure IP service and other techniques, we will not address this issue in our project.
1.2. Objective:
The objective of this project is to address the security issues of agents in the existing java-based multi-agent distributed goal satisfaction system (MADGS)[19][21]. As discussed above, the security in MADGS is a very important issue, which affects all of the operations of other components and functionalities such as the migration of an agent from one server to another, and the process of allocating resources for each agent. There should be a scheme that ensures the agent is moving under control, that agents are not allowed to pass on information to other agents indiscriminately and that agents are only permitted to request and access specific resources. In this project, we are aiming at addressing this issue by implementing and evaluating a security scheme in MADGS using role-based security approach [4]. More specifically, we are going to employ results of role-based security for distributed resource environments in [4] to explore the use of JINI to provide security for agent environments and implement an individual security component in MADGS based on the main idea in [4]. We will compare these two models based on their performance, integrity and scalability. In addition, we also take this opportunity to explore the possibility of allowing any MADGS agents to use JINI resources with security enforcement from JINI. The remaining of this report is organized into five sections. In the next section, we will report our literature search on agent security and its related issues. Section 3 discusses the architectures of the two main models. The implementation of the project is described in section 4. We report the empirical evaluation and comparison of the system in section 5. Finally, the summary and future research direction is presented.
2. Related work
Addressing the security threats in a mobile, multi-agent system is a challenging problem that attracts a lot of attention from the security and agent community. There is a number of works being done in this regard. In this section, we categorize existing approaches in agent security into two main streams based on the security threats in a multi agent system [6]. They include the approaches to protect the agents’ platforms and the agents themselves. Agent platforms and agents are two main components in a mobile, multi-agent system. An overview of related work in role-based approach is also discussed. In addition, we also report a brief survey on the existing mobile agent systems and how they address the security threats. Finally, a survey of replication methods used in implementing the security service is presented.
2.1. Protecting agent platforms
An agent platform provides the computational environment in which an agent operates. An agent host can be attacked from malicious agents operating on it and other external entities including other agents and other agent platforms. The set of threats to agent platforms includes masquerading, denial of service and unauthorized access. When an unauthorized agent claims the identity of another agent, it is said to be masquerading. The denial of service happens when an agent consumes an excessive amount of the agent platform’s computing resources. Finally, unauthorized access refers to illegal access to the services and resources on an agent platform. The existing approaches to this issue are software-based isolation, safe code interpretation, signing code, proof carrying code, status checking and path history.
Software-based Fault Isolation [26], as known as sandboxing technique, is to allow untrusted code to be executed on a trusted platform by isolating application modules into distinct fault domain enforced by software. For safe code interpretation approach[14][7], the main idea is that commands considered harmful can be either made safe for or denied to an agent. The best known of the safe interpreters for script based languages is SafeTcl [7] which was used in the early development of the Agent Tcl system. Safe Tcl employs a padded cell concept, whereby a second “safe” interpreter pre-screens any harmful commands from being executed by the main Tcl interpreter. These two techniques may be not strong enough to apply in MADGS because they both introduce a serious overhead and problems of resources as the sizes and the agents’ codes may be varied.
Signed code [9] and proof carrying code[11] are very much similar to each other because they both are done by the creators of agents. However, proof carrying code is a prevention technique while signing code is an authenticity and identification technique used to determine the unsafe code. In the signing code technique, mobile agent systems commonly use the signature of the user as an indication of the authority under which the agent operates. This technique uses the public key cryptography which relies on a pair of keys associated with an entity. One key is kept private by the entity and the other is made publicly available. The agent code, signature and public key certificate can be forwarded to a recipient who can easily verify the source and authenticity of the code. The decision to execute an agent could be taken only with endorsement of a site security administrator, given in the form of a digital signature applied to the code. One disadvantage of this technique is that obtaining quality security reviews in a timely fashion is difficult to achieve. The proof carrying code technique [11] is used to prove that the agent program possesses safety properties previously stipulated by the agent platform. The code and the proof of safety are sent together to the agent platform where they are verified. A safety predicate representing the semantics of the agent program is generated directly from the native code to ensure that the companion proof corresponds to the code. Once verified, the code can run without further checking. One advantage of this technique is that its underlying theoretical background is based on well-established principles from logic, type theory and formal verification. The purpose of these two approaches is to protect the agent’s illegal access to agent platforms using cryptographic techniques. They suffer from the pros and cons of the cryptographic approaches. Unlike these approaches, we assign a role to each agent which define what an agent can or cannot do on an agent platform.
Security community also looked at the possibility of checking the previous history of the agent and the current status of the agent to determine if the agent is behaving maliciously. The approach State Appraisal [5] is to predict the harmful alternations to an agent’s state by appraisal functions. Appraisal functions, produced by the owner of an agent, are used to determine what privileges to grant to an agent based on both conditional factors and whether identified state invariants hold. It may be difficult to apply this technique to MADGS because the state spaces of a MADGS agent are dynamically generated and they can be very large. Besides, although appraisal functions for obvious attacks may be easily formulated, more subtle attacks may be significantly harder to detect. The other similar approach is called Path Histories [13], which is to maintain an authenticable record of the prior platforms visited by an agent. Thus, a newly visited agent platforms can determine whether to process the agent and what resource constraints to apply. This path history requires each agent platform to add a signed entry to the path, indicate its identity and supply the complete path history to the next platform. This technique is a reasonable possibility to incorporate in MADGS except that path verification becomes more costly as the path history increases.
2.2. Protecting agents.
The security threats to agents include the attack from a malicious agent or from a malicious platform. A malicious agent or a malicious agent platform may disguise its identity in order to deceive the other agents that it communicates with. They also can repeatedly send messages to the other agents so that the trusted agents are unable to operate normally. A malicious agent can also participate in a transaction or communication and later on claims that it never does. It can invoke the other agents’ public methods without permissions to do so. A malicious platform can monitor and intercept of secret communications of agents which operate on it. It even can change the agent’s code, state and data. For this stream, it is difficult to prevent malicious behaviors of other agents and agent platforms from occurring. Therefore, it is important to be able to detect the malicious behavior early. All of the existing approaches are geared to this direction. The current techniques to protect agents include environmental key generation, computing with encrypted functions, black box security, and recording mutual itinerary.
Environmental key generation technique [17] describes a scheme that allows an agent to take a predefined action when some environmental conditions are true. The environmental conditions are hidden through either one way hash or public key encryption of the environmental trigger. One weakness of this approach is that an agent platform which has a complete control over an agent could simple modify the agent to print out the executable code upon receiving the trigger instead of executing it. Another short-coming of this technique is that an agent platform typically limits the capability of executing dynamically generated code. Computing with encrypted functions approach [20] determines a method by which mobile code can safely compute cryptographic primitives such as a digital signature even the code can be executed in unsafe host. For example, if agent A possesses an algorithm to compute a function f. An agent B has input x and wants to use the agent’s A function to compute f(x) for agent A. However, agent A does not want agent B to know anything about the function f. If this function can be encrypted in a way that results in another function E(f), then agent A can create a program P(E(f)) which implements E(f) and sends it to agent B. The agent B runs this function and returns the result to the agent A for decrypting. Now, if f is a signature algorithm, the agent has an effective means to sign information without agent platform discovering the key. Similarly, black box security [8] is a technique which scramble the code in such a way that no one is able to understand or to modify it without detection. A serious problem of this technique is that there is no well-known algorithm for providing black box protection.
Recording mutual itinerary with and without replication [18][22], tracing execution [25] are dealing with capturing the previous and current agent’s operations. Recording mutual itinerary [18] assumed that only a few agent platforms are malicious and even if an agent encounters one, the agent platform is not likely to collaborate with another malicious platform being visited by the agent. While an agent is moving from one agent platform to another, it conveys the information about its last, current and future visited platform to the cooperating peer through an authenticated channel. This technique is not appropriate for MADGS because it does introduce some overhead in creating an extra authenticated channel to communicate between agents. Besides, it is difficult for the cooperating agent to determine which of the two platforms is responsible if the agent is killed. Similarly, Scheider in [22] suggested incorporate the recording itinerary of agents with replicating. The main idea of this approach is to maintain multiple copies of an agent. By doing so, although a malicious host may corrupt a few copies of the agent, enough agents have been replicated to avoid the encounter to successfully complete the computation. One clear drawback of this approach is that the replication requires a lot of resources. Similarly to these above approaches, tracing execution [18] is used to detect unauthorized modification of an agent through recording of the agent’s behavior during its execution on each agent platform. In this technique, each agent platform creates and retains a log or trace of the operations performed by the agent while it is on this platform. It then submits a cryptographic hash of the trace upon conclusion as a trace summary. A trace is composed of a sequence of statement identifiers and platform signature information. This technique defines a secure protocol to convey agents and associated security related information among the various parties involved. However, this approach has a number of drawbacks. The size of the log to be kept is a problem for this technique. The detection process is triggered occasionally based on suspicious results may be not enough. This technique relies on the agent platform to obtain accurate relevant trace summaries of the agent.