Data-Security in Heterogeneous Agent Systems ? Piero A. Bonatti1, Sarit Kraus2 , Jose Salinas3, V.S. Subrahmanian4 1 2
Universita di Torino, E-mail
[email protected] Bar-Ilan University, E-mail
[email protected] 3 Army Research Lab, E-mail
[email protected] 4 University of Maryland, E-mail
[email protected]
Abstract. In this paper, we describe: (i) how agents can protect information from other agents and (ii) how servers that support agent cooperation can help in this process. We show that agents' data security policies can be encoded through three structures called metaknowledge , history and agent security tables . We develop a framework that allows arbitrary metalanguages and history maintenance policies to be \plugged in", and develop complexity results, including polynomial (eciently computable) approximations.
1 Introduction Developing a platform for the interaction of multiple agents requires contributions from several areas of computer science, ranging from systems software to support interoperability, network software to support multiagent communications, heterogeneous data and software integration to meaningfully exchange data, and arti cial reasoning to support intelligent reasoning and decision making tasks. With these goals in mind, we are conducting a joint research e ort between the US Army Research Lab, the University of Maryland, Bar-Ilan University (Israel), the Technical University of Vienna, the University of Torino (Italy), and the Universities of Gieen and Koblenz in(Germany). An ever-present, and important issue in the area of agent based systems, is the need to provide a wide range of security services. Such services range from: { Authentication of agents (\Is Agent A who is requesting a service really agent A?") { Network security services which ensure that network packets do not get improperly read by unauthorized intruders, and { Data security in which each agent wishes to hide some of its data (and/or capabilities) from other agents. In this paper, we will focus on Data Security only. We make the following contributions: First, we will precisely identify how each agent enforces data security. For this, each agent must specify three types of information: (1) metaknowledge it ?
Partially supported by the Army Research Oce under grant DAAH-04-95-10174, by the Air Force Oce of Scienti c Research under grant F49620-93-1-0065, by ARPA/Rome Labs contract Nr. F30602-93-C-0241 (Order Nr. A716), and by an NSF Young Investigator award IRI-93-57756.
has about other agents (\what do I believe agent A knows?"), (2) historical information it has about past interactions with other agents (\what did I tell agent A before?") and (3) an agent security table that speci es how it will respond to other agents' requests. Metaknowledge may be expressed in many languages as exempli ed in the vast quantity of work in the area of knowledge and belief [28]. We show complexity results for the problem of meta-reasoning when the meta-language L is allowed to vary.5 We identify classes of languages L that allow polynomial computations. Finally, Historical data: An agent that stores entire histories is liable to get quickly overwhelmed by physical storage requirements. On the other hand, storing detailed histories is often desirable from the point of view of data security. We provide a general framework to specify and maintain historical archives. The semantics of the history speci cation language may be obtained through an encoding into a fragment of logic programs under the well known stable model semantics [16]. Even though the complexity of stable models is well known to be NP-hard, the fragment we identify yields polynomial time results under some simple conditions. The organization of this paper is as follows: rst, we overview our IMPACT system for supporting multiple interacting software agents. The architecture consists of two parts { a set of IMPACT servers, and agents themselves; security must be maintained on both sides. We describe, in sections 3.1 and 3.2, servers' and agents' data security, respectively.6 Finally, in Section 4, we relate our work to the few existing works in this area.
2 Preliminaries: IMPACT Architecture7 A platform to support the creation and deployment of multiple software agents will need to interoperate with a wide variety of software sources. Any de nition Def of what it takes for a software package S (in any programming language) to be considered an agent program, must come accompanied with tools to augment, modify, or massage S into an agent according to the de nition Def. In IMPACT, an agent is built on top of a piece of software code S , represented by a pair S = (T ; F ) where T is the set of all data types manipulated by the software package S , and F is the set of all pre-de ned functions of the package S that are provided by the package's application programmer interface.8 For example, the Oracle DBMS may be viewed as a body of software code S where T consists of a set of attribute domains, tuples over these attribute domains, and relations (sets of such tuples), while F consists of the classical relational operations. S
S
S
S
S
S
5
This exibility in allowing the language L to vary is particularly useful, as in most real-world applications, we expect di erent agents to reason di erently. 6 Section 3.2 { the heart of this paper { contains the key new technical contributions. 7 The contents of this section are not new, see [7, 1, 24, 21, 22] for more details. 8 This assumption is consistent with all well known object based software interoperability frameworks such as CORBA/ODE [12] and ODMG's ODL [10].
An agent is built on top of S by adding: (1) a service description (in a special language described in [3]) which describes the services provided by the agent, (2) a message box that handles messages to other agents, (3) a decision layer (described in [14]) specifying how the agent takes actions, and (4) a security layer that describes the security policies associated with the agent. Due to space reasons we are unable to go into the full details of these layers { the interested reader is referred to [3]. The IMPACT architecture contains a set of replicated, mirrored servers that provide a variety of services, including agent yellow-pages (to nd agents that provide a requested service), an agent ontology service, as well as type/thesaurus services. Notation. Let S = (T ; F ) be a body of software code. Given any type 2 T , we will assume that there is a set V ar( ) of variable symbols ranging over . If X 2 V ar( ) is such a variable symbol, and if is a complex record type having elds f1 ; : : :; fn , then we require that X:fi be a variable of type i where i is the type of eld fi . In the same vein, if fi itself has a sub- eld g of type
, then X:fi:g is a variable of type , and so on. In such a case, we will call X a root-variable, and the variables X:fi , X:fi :g, etc. path-variables. An assignment of objects to the variables is a set of equations of the form V1 = o1 ; : : :; Vk = ok where the Vi 's are variables (root or path) and the oi 's are objects { such an assignment is legal, if the types of objects and corresponding variables match. De nition1 code call. Suppose S = (T ; F ) is some software code and f 2 F is a prede ned function with n arguments, and d1 ; : : :; dn are objects or variables such that each di respects the type requirements of the i'th argument of f.9 Then S : f(d1 ; : : :; dn ) is called a code call. A code call is ground, if all the di 's are objects. S
S
S
S
S
De nition2 code call atom. If cc is a code call, and X is either a variable symbol, or an object of the output type of cc, then in(X; cc) is a code call atom.
Intuitively, a code call atom succeeds (returns true ) just in case X is in the result set returned by cc. As an example of a code call atoms that we have implemented, consider in(X; oracle : select(emp:rel; salary;>; 150000)). This code call atom would succeed, instantiating X to any single tuple in relation emp that has a salary eld of over 150,000.
De nition3 code call condition. A code call condition is de ned as follows: 1. Every code call atom is a code call condition. 2. If s,t are either variables or objects, then s = t is a code call condition. 3. If s,t are either integers/real valued objects, or are variables over the integers/reals, then s < t; s > t; s t and s t are code call conditions. 4. If 1; 2 are code call conditions, then 1 & 2 is a code call condition. 9 In general, each function f 2 F has a signature, specifying the types of inputs it takes, and the types of outputs it returns.
A code call condition satisfying any of the rst three criteria above is an atomic code call condition. (Intuitively, the operator & is just logical and .)10
3 Security in IMPACT In this paper, we will concentrate on Data Security , i.e., keeping a designated set of facts secret.11 We observe that security may be violated in the following ways. First, the IMPACT Servers may have some data that may get compromised. For example, information about which agents provide which services. In general, the fact that an agent A o ers some service s1 may only be disclosed under some conditions (e.g. A may provide code for the RSA public key cryptosystem, but this may only be disclosed to agents in the US). Secondly, agents may have security requirements on their own data. For example, consider an FBI face recognition agent; some of the mugshot data (e.g. of under-age criminals) may be made available only to users with a high clearance level. Existing agents may have their own security protocols, and need/desire nothing else. By contrast, our results in this paper apply to a situation where an application developer who builds some of his own agents, wishes to include some security/access control methods in his system. Third, we must be sure that through the Interaction between agents and the IMPACT Servers, no secrets are \leaked" by an agent to the IMPACT Server (or vice versa). In the rest of this section, we tackle each of these three parameters, by providing a simple security architecture. Our solution is quite generic, and applies to a wide variety of languages and architectures.
3.1 IMPACT Server Security Services Suppose A is an agent, which o ers services s1 ; : : :; sn. A non-disclosure agreement between the IMPACT Servers and agent A speci es that the fact that agent A o ers service si will only be disclosed to other users/agents if they meet certain speci ed conditions. In this section, we show how non-disclosure agreements can be articulated and enforced within IMPACT servers. Throughout this section, we assume the existence of a partially ordered set, (SL; v), whose members are called security levels. If `1 v`2 , we say that security level `1 is \lower" than `2 . A service description consists of a service name, a set of mandatory inputs required to use that service, a set of inputs (not required) that may be provided, and a set of outputs generated by the agent providing that service. A service
10
The current implementation, based on our HERMES platform [24, 7, 21, 8, 1], supports Ingres, Dbase, Paradox, packages for face recognition, nonlinear planning and terrain reasoning, operations research software, a GIS and a text indexing system. 11 Further important issues relate to access control and authentication protocols [23] that we do not address here for space reasons.
name consists of a verb (e.g.\plan" and \sell" above) and a noun-term, de ned as: (i) if n is a noun, then n is a noun term, (ii) if n1 ; n2 are nouns, then n1 (n2) is a noun term (e.g., \route" and \tickets(opera)" above are noun-terms). See [3] for more details. The IMPACT Server maintains a Verb Hierarchy and a Noun-Hierarchy that are weighted directed acyclic graphs. Each node in the graph is labeled by a set of synonymous words. The edges denote ISA relationships. When a service vQ : ntQ is requested (where vQ is a verb and ntQ is a noun-term), the IMPACT Server conducts a k-nearest neighbor search through the verb and noun hierarchies to \relax" the query. Then it may return agents which provide services within a given distance from vQ : ntQ in the hierarchies. The IMPACT servers' data structures and algorithms (cf. [3]) can be easily extended to incorporate security paradigms. When an agent A registers a service named v : nt with the IMPACT Server, it also provides a set of conditions specifying to whom the fact that agent A o ers this service may be released. The IMPACT Server maintains two tables (implemented in Oracle DBMS): { An agent table having the schema (AgentId,SecLevel,ConnectionInfo) where SecLevel is the agent's security level, and ConnectionInfo is a speci cation of how other agents may connect to this one. { A service table with four attributes { Verb, NounTerm, Agent, and Condition. The last column speci es a condition that must be satis ed by a client in order to access this information. For example, the tuple: (retrieve; surveillance(video); agent1; in(T; oracle:select(emp;dept; =; security)) & = (T:name; U ) & tsvLevel(U ))
says that \Agent-1" provides a service called \retrieve:surveillance(video)" that may only be used by individuals in the Security-Department having a top-secret (ts) or higher clearance. In order to precisely de ne the syntax of the \Condition" eld of the service table, we need the following de nitions: De nition4 ordering terms/atoms. 1. If U is either a variable over userids, or is a user-id, then Level(U) is an ordering term. 2. Every member of SL is an ordering term involving no variables. If t1; t2 are ordering terms and op is any binary relation in fv;
