Secure Object Spaces 1 Introduction

Secure Object Spaces

A coordination model for Agents Ciaran Bryce

Manuel Oriol

Jan Vitek

Abstract

Coordination languages based on shared data spaces are well suited to programming parallel applications composed of cooperating software components. Secure Object Spaces (SOS) extend this model to support composition of independently developed, mutually suspicious, software components. SOS provides exible and ecient security facilities based on a cryptographic re-interpretation of object types. We discuss the implementation of secure object spaces in the context of a Java-based mobile agent system.

1 Introduction Coordination languages based on shared data spaces have been around for over fteen years. Oftentimes, researchers have advocated their use for structuring distributed and concurrent systems. This because the mode of communication provided by these languages, sometimes called generative communication , is anonymous | processes interact by reading and writing entries in a shared space without having to know their interlocutor(s); and is uncoupled | processes are not tied to their communication partners. These characteristics make it straightforward to program resource discovery protocols that match up clients with servers based on their respective oers [24], to program in an event-driven style [20] and to dynamically recon gure running systems [14]. All of these features are important for distributed systems. Yet, the practical applications of coordination languages remain limited to parallel programs made up of cooperating components coming from the same source. To make good on the promises of the approach, coordination languages must support the composition of independently developed software components coming from multiple sources and, at least in some cases, mutually suspicious components. This requires more structured communication primitives and security mechanisms that are lacking in existing models. The shortcomings of generative communication are inherent to the model. Generative communication is at its best when all processes that have access to a shared space, have been designed carefully and are well-behaved. Unfortunately, mistakes are easily made, the simplest example is reading an entry which is part of another protocol [24, 15], and nothing prevents malicious processes from spying or even corrupting the data exchanged over the common space. In this paper we present the Secure Object Spaces coordination model, or SOS, and argue that this model can be used to solve the above mentioned diculties. In a SOS, entries in the shared space are protected by keys. These 1

keys, both symmetric and asymmetric, are used to query the data space and to protect the contents of the data space entries. Our contributions are a formal presentation of the SOS model as a process calculus, a relation between types and cryptography that permits to eschew encryption in favor of dynamic typing, and a description of an implementation in the Java programming language.

Outline This paper looks at the shortcomings of generative communication from a particular angle; our goal is to provide tools for composing mobile agent applications. Section 2 gives some background on mobile agents and lists their needs in term of coordination. Section 3 present the SOS model, introduces the SOS calculus giving it an operational semantics, and formalizes the relationship between types and cryptographic primitives. Section 4 presents our implementation of SOS in Java and gives some examples that relate to the requirements of Section 2. Sections 5 and 6 present related work and our conclusions.

2 Coordinating mobile agents Spurred by the success of the Internet, a number of projects are experimenting with new approaches for constructing distributed systems. Mobile agents are software components comprising code (agent behavior) and data (agent state). Agents carry out distributed computations by moving around the network. When running on a site, an agent may use that site's resources and interact with other agents located at the same site [21, 9, 27, 26, 3]. Mobile agent applications are programmed in a style that emphasizes a clear separation between local and remote interaction; local interaction takes place amongst co-located agents, on the other hand, remote interaction is obtained by moving agents. Not surprisingly, a key issue for agent programming is how to structure and regulate the communication between agents . Agent communication is essential | without it there would be little point in moving | it is thus desirable to facilitate the expression of communication protocols by providing high-level primitives to that end. Yet, for obvious security reasons, this communication must be regulated and structured. Consider as an example, the JavaSeal mobile agent system [26]. In JavaSeal, agents communicate through a message passing interface. Their communication is regulated by strong restrictions: agents are hierarchically structured and they are allowed to communicate only with their direct parent. Thus it is possible to lter and control all communication between agents. A parent may, for example, choose to disallow communication between agents of dierent security levels simply by refusing to transfer messages. Message based communication is appropriate for certain forms of interaction, but it can also be cumbersome. This is especially true in the case of JavaSeal where all interaction between agents is routed by their parents, and this routing coded by the user. Our goal is to extend JavaSeal with a form of generative communication which simpli es the coding of some common patterns of interaction between agents without breaking the security model. Generative communication is attractive as it simpli es the task of introducing agents to each other and recon guring links between agents. Both are important aspects of agent programming. This has led us to consider the addition of a Linda-like [10] shared data space 2

mechanisms to JavaSeal1 . The main weaknesses of Linda for our purpose are its lack of access control mechanisms and the absence of support for structured communication. Multiple data spaces are a possible solution to the access control problem [4, 11, 12, 23]. In this view, data spaces are considered as protection domains, and granting access to a data space to an agent implies that the agent is trusted to manipulate the data in that space and to interact with other agents which currently have access to the same space. The disadvantages of this approach are that in highly dynamic environments such as ours, with high migration rates (new agents arriving, old agent leaving), the task of managing the data spaces (creation, granting of space access rights, destruction) is dicult and likely to pose serious eciency problems. Moreover, multiple spaces solve only part of the problem. In agent applications, protecting the values stored in the data space is dierent from protecting the data space itself. In particular, an agent that plays the role of a garbage collector may have the right to retrieve entries from a common space, but should not be able to access their contents. The entries should be treated as opaque values. The lack of structured communication shows up when programming logical channels [24]. Logical channels structure communication. For example in a client-server interaction, only the client should read the server's reply. In group communication, messages are addressed to members of the group and not to an arbitrary process that happens to emit a matching request. These structures are increasingly important when one wishes to run independent applications on top of the same data space, and where sharing only exists for basic services. To summarize, we place the following requirement on a mobile agent coordination model: Privacy: The privacy of secret data contained in the elds of an entry must be preserved. Thus it should be possible to communicate a password or bank account number without fear of disclosure. The implication of privacy is that access to the elds (the contents) of a data space entry may be restricted. Clearly, privacy must be preserved outside of the agent platform including in network and disk storage formats. Layered security: Security policies are layered when several dierent components in an environment can formulate restrictions on the same operation. In an agent system, we may have a sandbox agent that allows all agents executing within it to communicate, while another agent may speci es that no communication between the sandbox and the rest of the system is permitted. Garbage collection: A shared resource is a target for denial of service attacks. Thus an agent may ood the data space with useless entries for the sole purpose of degrading performance. In a data space there is no cut and dried criterion for deciding which entries are not needed anymore. Garbage collection algorithms are thus application speci c and are implemented at user level with possibly several dierent garbage collector agents working in parallel on the same space. Typical policies include 





1 The coordinationmechanismswe envisage diers from SUN's JavaSpace [20] in that spaces are not distributed, and that the goal here is to coordinate agents on the same platform

3





removing entries after an agent migrates and associating a time-to-live to entries. Logical channels: Support for a exible notion of logical channels (unicast and multicast) is required. Eciency: As data space operations are frequent, their computational overhead must be as low as possible.

3 Secure Object Spaces We introduce a coordination model that meets the above mentioned requirements. The essence of our proposal is to view all object space manipulations as cryptographic primitives. We use the term secure object space , or SOS, both to refer to the model and the actual shared data structure. A secure object space is a relative of the Linda tuplespace . In Linda, processes write ordered sequences of data elements, tuples , into a common tuplespace (out) and retrieve tuples by querying the tuplespace with a partially speci ed tuple called a template (in and read). The role of the tuplespace is to associate a template with one of its tuples, this process is called matching . There can be multiple candidates that match a given template; the tuplespace choses one of them non-deterministically. In a SOS, instead of tuples, entries are objects which contains a set of elds . Each eld has a value and a label . For example, the object x : 1999; yz : "JohnDoe"i

h

has two values, an integer and a character string, which are labeled x and yz respectively. Writing a value to an object space is viewed as an encryption operation in the course of which every value of the object is encrypted under its label. In the example, x is a symmetric key and yz is an asymmetric key pair. Thus the object actually inserted in the SOS is KxS (1999); KyA("JohnDoe")i

h

The matching performed by the SOS is the inverse operation. The matching procedure is given a template object, the labels of which will be used as decryption keys and the values for comparison. Thus, the template containing a single eld, labeled x and containing the special \don't care" value ? is x : ?i

h

This template matches the object presented above. The semantics of matching is to try to decrypt each eld of each object in the space with x. Any successful decryption means that a match has been found, in case of multiple matches the SOS returns one non-deterministically. The object returned from the space does not reveal the content of its second eld, at most one may know that there is an encrypted eld, but without the key nothing more can be learned. The following template also matches z : ?; x : 1999i

h

4

Here z is the decryption key of yz . The order in which the elds appear is not relevant. Note also that eld values can be used in matching (albeit only after decryption). Readers familiar with the overhead of cryptography will by now be wary about the eciency of an implementation of SOS. The key to our proposal is that while the semantics that we outlined informally are those we want to reason with, we provide an implementation that (almost) never actually encrypts anything. Matching is implemented at the programming language level by dynamic type checking. Encryption is only required when values leave the control of the language runtime, e.g., to be stored on disk or shipped over the network. We present the SOS model in the setting of a process calculus inspired by the -calculus [16]. This minimal setting highlights the unique features of the model and allows us to give a precise semantics to SOS operations. The calculus allows multiple object spaces, this feature is not essential, it was added to make some of the examples clearer.

3.1 Syntax and Basic De nitions

We assume an in nite set of names ranged over by meta-variables a; b; c. The set of labels is composed of pairs of names, ab, meta-variable ` ranges over labels. We de ne the co-label function as ab = ba. We assume a distinguished void element, denoted by ?, sole inhabitant of set . The set of basic values, ranged over by x; y; z , is the disjoint union of and . The notation, x T , states that x is of type T (either or ). The subtype relation on basic values is an order relation with . In a full

edged language, we expect a richer type system and a more interesting subtype relation, but this suces for our purpose. An object `1 : x1; : : :; `n : xn is a possibly empty sequence of elds , ` : x, where ` is the eld label and x is the eld value . Labels are unique, i.e., `i = `j i = j . We assume a set of object variables ranged over by . The sets of processes , ranged over by P; Q, of objects ranged over by t, elds ranged over by f , and expressions ranged over by e are de ned by the grammar: L




B

L

B

2

L



h

B

L  B

i

,

Processes P ::= j j j j j

0

P jQ !P in(t; )@e : P out(t)@e ( a)P

inactivity composition replication input output restriction

Expressions e ::= ? ab t:e f ::= e : e t ::= hf~i j tf j  j

j

label selection eld object extension variable

0 denotes the inert process. P j Q denotes parallel composition. ! P denotes replication of process P . in(t; )@e : P is a synchronous input primitive which binds  to an object matching template t in space e, then proceeds as P . out(t)@e is an asynchronous output primitive that places object t in space 5

e. ( a)P denotes the creation of a fresh name, a, in P . Expressions include selection of a eld in an object t:e and extension of an object with a eld t  f .

Notation Some notational conventions. We abbreviate possibly empty sequences of elds f1 : : : fn to f~. Trailing inert processes are elided, thus in(t; )@e : 0 becomes in(t; )@e. The notation for capture avoiding substitution is P t= . By convention we abbreviate labels of the form aa to a when no ambiguity can arise. We write ` : x ` : x; `1 : x1; : : :; `n : xn . f

2 h

g

i

3.2 Relating types to cryptography

In SOS, object types are related to cryptographic operations. We present some relevant facts about cryptography. Symmetric schemes such as DES, [17], use a shared key to encode data into ciphertext and the same key to decrypt the data. We write KaS (v) to denote the encryption of v under shared-key a, and note that KaS (KaS (v)) = v. Asymmetric schemes, also known as public-key cryptography use key pairs [19]. One key is used to encrypt data, the other to decrypt. So, given a pair p; s, we denote the encryption of value v under s by KsA (v) and we have KpA (KsA (v)) = v. In the remainder we make some standard assumptions about cryptography (from [2]): The only way to decrypt a value is to know the corresponding key. An encrypted packet does not reveal the key under which it was encrypted. There is sucient redundancy in messages so that the decryption algorithm can detect whether the ciphertext was encrypted with a given key. An SOS object is made up of elds (label/value pairs). The SOS operations will treat labels as keys. In our syntax we write ab = ba to denote that a is a public key and b is the corresponding private key. The relation is symmetric in that a public key may be used for encryption as well as decryption. We write aa to denote shared key cryptography. (In our notation the following holds: ab = ab and aa = aa .) The co-relation is not explicitly represented, rather writing ` = ` implies that it is possible to decipher with ` a value encrypted with `. Note that as a slight simpli cation, the calculus allows any pair of names to be used as keys. In practice key pairs are generated, but this is not signi cant for the present discussion. In the SOS, an object such as `1 : x1; : : :; `n : xn is stored encrypted in the space as K`1 (x1 ); : : :; K`n (xn) To retrieve it, it is necessary to present a subset of `1; : : :; `n to the object space. Possession of any of the n keys then grants access to the corresponding values. We now turn to object types and subtyping. This discussion will lead up to the de nition of the notion of type-matching and the associated theory. Subtyping allows one to view a value of some type T as if it were of some other type 








h

i

i

h

f

6

g

T , provided that T and T are related by subtyping (T  T ). Even though a T object may have more elds than those de ne at type T ; these elds are hidden when the object is viewed as a T object. The type protects hidden elds. Infor0

0

0

0

0

mally, we may view a type as some kind of shared-key which controls the access to objects. We will push the analogy and extend it to public-key cryptography. Public-key cryptography introduces an asymmetry that leads us the de nition of the type-matching relation (E) which is related to subtyping, but which has signi cantly dierent mathematical properties.

De nition 1 (SOS object type) An object f~ is of type = `1 : T1 ; : : :; `n : h

i

T

f

Tn g, written hf~i 2 T , i f~ = `1 : x1; : : :; `n : xn ; and xi 2 Ti . We also de ne a co-type as T = f`1 : T1 ; : : :; `n : Tng.

Subtyping in SOS is structural, that is, the order of elds is disregarded. This choice allows multiple independent extensions to the same objet. We shall return to this later.

De nition 2 (subtyping) The object subtype relation relates object types: 

T  T

for all ` : T

i

0

there exists ` : T

2 T

0

2 T

0

and T = T

0

Immediately it follows that is a partial order relation on object types (transitive, re exive, antisymmetric). We introduce the type-matching relation which will be used when checking a template object t against a candidate object t . 

2 T

2 T

0

De nition 3 (type-matching) The match relation E relates types: and T T E i for all ` : T there exists ` : T T

T

0

0

2 T

2 T

0

0



Intuitively, type-matches if each eld of , ` : T , is matched by a eld, ` : T of and the type of the value in is a subtype of that of . In other words, may have more elds than , but the elds in may be more speci c. We now give some properties of type-matching. T

T

0

T

T

T

T

0

0

0

0

T

T

T

0

Lemma 1 (E relation) 1. If E ; E and E then E . 2. E . 3. If E ; E then = . 4. If E 1; 1 E and E 2; 2 E then = and 1 = 2 . 5. If 1 1 ; 2 2 and 1 E 2 then 1 E 2 Proof Points 1, 2 and 5 follow from straightforward application of the de T

T

T

0

T

0

00

T

T

00

T

000

T

T

000

T

T

T

T

T

T

 T

0

T

0

T

0

T

T

T

0

T

0

 T

T

T

0

T

0

T

0

T

T

0

T

T

nitions.

7

T

T

T

0

T

T

Point 3 By De nition 1 we have = `1 : T1; : : :; `n : Tn and = `1 : T1 ; : : :; `n : Tn . Two applications of De nition 3 yield: E E i for all ` : T there exists ` = ` : T and T T

0

0

T

0

0

T

f

g

T

0

0

f

g

T

0

2 T

T and i for all ` : T

0

0

2 T

0



there exists ` = ` : T and T T This means that for all ` there is an ` , and also an ` , such that ` = ` = `. By de nition, we also have ` = `. By unicity of labels in objects (De nition 1), we then have T = T and ` = ` . It follows by renumbering elds of that = `1 : T1; : : :; `n : Tn = . Point 4 By De nition 3 we have: E 1E i for all ` : T there exists ` = `1 = ` : T T1 T 1 and T and the symmetric with E 2 E then we know that ` = ` then ` = ` and the two following relations hold: T T1 T and T T2 T . By transitivity of it follows T T and T T and then by antisymmetry T = T . and then have the same entrys and are equals. There is then E 1 E and E 2 E . Using Lemma 1.3 this implies that = 2. 1= Note that the following property does not hold 1 E 1 and 1 2 and 2. 2 E 2 then 1 Some comments about the properties stated in Lemma 1. Property 1 is a form of transitivity. Property 2 states that a type matches with its co-type. Property 3 is a sort of modi ed antisymmetry with co-types. Property 4 is useful for establishing equality between types either between 1 and 2 or between and . Property 5 is the composition of traditional subtyping ( ) and matching types (E). 0

2 T

0

2 T

00

0

00

2 T

00

0

2 T

0

00

T

T

T

0

T

0

T

0

0

f

0



g

0

T

0



T

T

T

T

T

T

T

0

T

T

T













0

0

0

T

T

T

T

T

0

T

0

 T

0

 T

T

T

2

0

T

0

0



0

0

T

0

2 T

T

T

2 T

0

0

T



00

T

0

T



Examples Some examples of type-matching are given to illustrate the de nition: 1. For any , we have E . The empty type matches any other types, but this does not provide access to the elds. Trivially, we have E . 2. A smaller type matches a longer type: a : E a : ; b : . 3. A type matches a more speci c type: a : E a : . 4. A type matches its co-type: ab : E ba : . We may now proceed to give a de nition of the matching procedure which takes a template object t and a candidate object t and establishes whether the candidate meets the speci cation of the template. This de nition use the type-matching de ned above and does not require cryptography. T

hi

T

hi

h

h

h

Li

Li

h

Bi

h

h

L

hi

Li

Li

Li

0

De nition 4 (Matching) The matching relation / relates objects, t / t , i: 1. t ; t and E , 

2 T

0

2 T

0

T

T



0

0

2. ` : x 2 t; ` : y 2 t ; x 2 T and y 2 T implies x = y. 0

A template matches a candidate if the type of the template matches the type of the candidate and if for every eld with matching labels and equal types, values are equal as well. 8

Examples 1.

/ t for any t. This fact can be used in to collect objects without

hi 

considering their contents. 2. `1 : x; `2 : y / `1 : x; `2 : y 3. `1 : x / `1 : x; `2 : y and y and 4. `1 : x; `2 : ? / `1 : x; `2 : y because ? 5. We do not have: `1 : x; `2 : y / `1 : x; `2 : ? 6. Similarly, we do not have: `1 : x; `2 : y; `4 : z / `1 : x; `2 : y; `3 : z or `1 : x; `2 : y; `3 : z / `1 : x; `2 : y; `4 : z . 7. Adding elds to an object restricts its potential for matching, thus with t = ` : x and t = ` : x we have that t / t . But if we extend t with a eld ` : y, the match fails. Thus the following does not hold: (t ` : y) / t . (The de nition of extension is given in the next section.) When dealing with encrypted values, although one may not access the cleartext, it is possible to know if a value was decrypted entirely or not. We have not introduced an operator for testing co-equality of object types, and we do not need to. By Lemma 1.3 we have that if E E then = . The result carries over to object matching. If t / t / t, we say that objects are co-equal, i.e., t = t . Getting ahead of ourselves a little, we show how to ensure that an object has no hidden information. Here process P will execute only if if t = t . (The semantics of the calculus are given in the next section.) h

i  h

h

i

i  h

i

i  h

h

i

h

2 B

i  h

i  h

i  h

h

0

i

L  B

i

h

h

2 L

i

i

i

h



0

0

0





0

T



0

0

T

0

T

T

T

0



0

( a)(out(t)@a j in(t ; )@a : ( out(t )@a j in(t; )@a : P )) 0

0

To summarize, we have presented a notion of matching which relies on properties of object types to implement object matching in the SOS. In particular the de nitions given here provide the same kind of protection as symmetric and asymmetric cryptography primitives but within a safe language environment.

3.3 Reduction semantics

The reduction relation is de ned over processes and represents one step of computation. Reduction is de ned by means of two auxiliary notions: structural congruence and evaluation . Structural congruence, , is the least congruence on processes satisfying axioms and rules described in Figure 1. It does not handle renaming of bound variables. Instead, we consider that alpha-conversions are silently performed whenever needed. The evaluation relation ( ) yields the result of expression involving eld selection and object extension. The reduction relation is the least relation on processes that satis es axioms in Figure 1. Nonsensical terms such as out(t)@? and ? : e; f~ or erroneous f~ ` : x where ` f~ are allowed by the syntax of the calculus. To some extent these terms could be prevented by a type system. In this paper we prefer to consider that computation does not proceed for terms containing these expressions. !



#

!

h

2 h

i

9

i

h

i 

Reduction P ( x)P

! !

P !Q P jR!QjR

Q

( x)Q

P



P

0

P P

0

Q Q ! Q !

0

0



Q

/t e2 # x e 4 # x e 1 # t e 3 # t t  e out(e1 )@e2 j in(e3 ; )@e4 : P ! P f 1= g 0

0

Evaluation e#t tt e#t 0

x#x

t  he1 : e2 ; f~i e1 # ` e2 # x e # ` t:e # x

0

Structural congruence ~i  hf; ~ ` : xi P jQQjP h` : x; f ~ (P j Q) j R  P j (Q j R) ` 62 hf i ) hf~i  ` : x  h` : x; f~i !P  P j !P ( a)( b)P  ( b)( a)P a 62 fn (P ) ) ( a)(P j Q)  P j ( a)Q

Figure 1: SOS reduction semantics. We may now proceed with examples that demonstrate the expressiveness of the calculus and that show how to meet some of the requirements outlined in Section 2.

Synchronization A process may synchronize on an object space, consider the process

out( )@a in( ; )@a : P j

hi

hi

which reduces in one step to P = . Here the empty object is not used further. f

hi

g

Repeater A process that reads objects and writes them back is: !in( ; )@a : out()@a hi

In this case the matching rules will allow the repeater to retrieve any object and write it back immediately after that.

Multiple object spaces Although we shall not expand on this point, the SOS calculus has multiple object spaces. Thus the process in( ab : ? ; )@c : (out()@c j out()@d) h

i

10

will read an object from a space c. Then the term proceeds by outputing  in parallel to spaces c and d. (For simplicity we abbreviate space identi ers to names, through they are actually labels.)

First-class templates Unlike Linda, SOS templates are objects, thus it is

possible to use any object to query the SOS. For example, the following process takes any object from space a and uses it to query space b: in( ; )@a : in(;  )@b : P If we compose the above process in parallel with out( a : ? )@a j out( a : b )@b The composed term will reduce to 0

hi

h

i

h

i

P f a:b = g h

i

0

Dynamic recon guration Communication patterns are dynamic, process may easily change communication partners within an SOS, but they may also acquire new SOS identi ers in the course of computation. Consider the term in( b : ? ; )@a : out()@:b The process starts by retrieving an object encrypted with a symmetric key b with in( b : ? ; )@a. Then it proceeds by writing the object back in a space identi ed by :b, that is, the selection and (symmetric) decryption of a eld label b from . A communication partner for this term could be out( b : c )@a h

h

i

i

h

i

Bulk encryption In cryptosystems, the dierence in running time between public key encryption and shared key encryption are such that it is advantageous to encrypt large volumes of data with a shared key and only encrypt the shared key with the private key. In SOS, we can code a process that sends a symmetric key a encrypted under an asymmetric key bc and a value d encrypted under a. The process is e.g., ( a)out( bc : a; a : d )@x The partner that uses d as a space identi er is in( cb : ? ; )@x : out()@:(:cb) The evaluation rules states that bc : a; a : d :cb is a and bc : a; a : d :a is d. h

h

i

i

h

i

h

i

Garbage collection We can implement a time-based garbage collector agent (GCA) as a process that mediates access to an object space. Every output request is sent to the GCA which adds some GC speci c information to the object before inserting it in the space. For a time-based garbage collector this information may simply be a time-to-live eld. This is coded in the calculus as in( ; )@a : out( TTL : x)@b hi



11

assuming that a denotes a space in which insertion requests are placed and b denotes the actual SOS used for communication. Further, x is some time stamp. The evaluation rule decrees that the extension expression  TTL : x returns an object with a TTL eld, here TTL is a shared key which we assume to be known only to the GCA. Once a given time stamp ceases to be valid, the following process will collect the garbage 

!in( TTL : x ; )@b h

i

using the value matching rule to extract only objects that have been stamped at time x. The interesting point here is that the GCA is a user level agent which does not gain any knowledge about the content of the objects it manipulates. Secondly, we may have several dierent GCAs with dierent policies mediating the same space. Thirdly, GC information is not visible in normal communication. Processes may retrieve time stamped objects as before but will not be able to access that information. (They may nd out that there is information attached though.)

Linda It is straightforward to model Linda in SOS. Linda uses positional notation for matching values in tuples and does not have any equivalent to our encryption primitives. A Linda tuple x; y; z can be translated to an object 1 : x; 2 : y; 3 : z where 1, 2 and 3 are globally scoped names that stand for positions in the obvious way. A Linda output operation out( x; y )@a is translated to an SOS out( 1 : x; 2 : y )@a. A Linda query in( ?v; y ; a)@ : P is translated to in( 1 : ?; 2 : y ; )@a : P where all occurrences of v in P will be replaced with :1. h

h

i

i

h

h

h

i

h

i

i

0

i

Asynchronous -calculus An encoding of the asynchronous -calculus can

be obtained by using spaces as channels and restricting matching to the trivial case. Roughly the encoding is as follows. Every  write xy is translated to an output out( sr : y )@x and every input pre x of the form xy : P would be translated to an input operation in( rs : ? ; )@x : P where P is the translation of P with occurrences of the variable y replaced by :rs. h

i

h

i

0

0

This concludes the presentation of the calculus of secure object spaces. Before proceeding with the implementation of the SOS model one last remark. By introducing labeled elds, the SOS model abandons the positional notation used in Linda systems. Independent of its cryptographic interpretation, the labels of the SOS model add structure to generative communication. Linda programs rely on an unwritten agreement on the meaning and use of dierent elds in tuples. While positional notation is easy to use, it is also error prone (two tuples of the same arity can easily get mixed up) and does not lend itself to extensions. Labels make the agreement explicit (it is necessary to agree on names before communicating) and help in making code more robust [7].

12

4 Implementing the SOS Model The examples of the previous section have demonstrated the expressive power of the SOS model. This section looks at its implementation in the context of Javabased mobile agent systems. In particular, we argue that this implementation is ecient since, though the semantics of encryption are being emulated with keys, no encryption is actually taking place so long as the agents remain in the typing environment of the Java virtual machine (JVM). Encryption is only required when the tuples are transferred outside of this environment, e.g., over the network or to disk. Our implementation of SOS is integrated into the kernel of the JavaSeal mobile agent platform [26]. This means that all SOS operations are under kernel control. The JavaSeal runtime system enforce access control restrictions using language based protection mechanisms (static access control and checked primitives outlined in [25]) to guarantee that no agent may gain access to the objects stored within a SOS entry without possessing the proper keys. Encryption is needed in two cases: when an SOS object is backed up on disk, and when an agent containing an SOS object migrates. In both cases, the SOS object leaves the control of the runtime system, and for this reason can no longer be protected by programming language techniques. These are the only two cases where we must resort to encryption. The remainder of this section outlines our implementation and the integration of SOS into JavaSeal.

4.1 SOS in Java

We start the section with a look at the Java API implementing the SOS. Additional helper classes are also required though these are not described here. The nal two paragraphs look at two aspects of the Java programming language that can potentially undermine the security of the SOS implementation, and which must therefore be used in a controlled manner: inheritance and object aliasing.

4.1.1 Classes

The SOS model relies on keys to access the elds of objects. At the implementation, there is an abstract Key class, with two nal subclasses AsymKey and SymKey which represent the asymmetric and symmetric keys respectively.

Key This class de nes the common attributes of SOS keys. The key eld is

used to store the actual value of the key. This is only used to do real cryptography when the object that it is guarding is transferred outside of the JVM. The match method compares two key instances. Actual encryption and decryption is done with the encrypt and decrypt methods. Here the object being encrypted/decrypted is the SOS object being guarded by the Key object in the shared space. The parameters to these operations are Objects rather than SOSObjects since the latter are stored in serialized form in the SOS. The encrypt and decrypt methods are called by the agent transfer code before transfer of the SOS objects over the network. 13

abstract class Key implements Serializable f private byte[] key; public abstract boolean match(Key K); public abstract Object encrypt(Object obj); public abstract Object decrypt(Object obj); g

SymKey A SymKey represents the shared keys. Its match method expects

its argument to be this, i.e., the same key is used in actual encryption and decryption. public nal class SymKey implements Serializable f public SymKey(byte[] key); public boolean match(Key K); public Object encrypt(Object obj); public Object decrypt(Object obj); g

AsymKey An ASymKey represents asymmetric keys. This class contains the dual key that is needed to match with it. Note also that the constructor is protected. In eect, an asymmetric key is indirectly created. A user rst creates a KeyPair helper class, which creates the two asymmetric keys. In this way, one is sure that each asymmetric key has a dual key. The encrypt and decrypt methods use the key eld for encryption and decryption. This means that an object encrypted with an asymmetric key in one context (via the encrypt method) before transfer over the network must be decrypted with a matching asymmetric key object in the destination agent platform. public nal class AsymKey implements Serializable f private AsymKey dual; protected AsymKey(); public boolean match(Key K); public Object encrypt(Object obj); public Object decrypt(Object obj); g

SOSObject The SOSObject class implements the behavior of entries in the

shared object space. Recall that the notion of subtyping and type matching de ned relied on the notion of structural subtyping. This diers from the Java type system since structural subtyping does not require an explicit type hierarchy (such as the hierarchy in Java explicitly de ned using extends in declarations), and structural subtyping naturally allows for multiple supertypes for any given type. The implementation of matching is thus done dynamically in the match() method of SOSObject which is a nal method. For the purpose of matching, null (the \empty" value for pointers) plays the role of ?. An SOSObject instance is created with a set of key-value pairs. Keys are checked to be either of type SymKey or AsymKey; a user-de ned key type is automatically rejected. The select operation has a method that takes a key as parameter and returns the object if the key is the correct key, or null if no matching object is found in the SOSObject. 14

The extend operation/method returns a new object obtained by extending this with a key-value pair. The operation fails if the pair is already present in the SOSObject. The match method returns true if the argument SOSObject matches. This requires that the keys of both SOSObjects match, and then that the values match. We explain how values are matched below, since there are security implications concerning how normal Java objects are compared. public nal class SOSObject implements Serializable f public SOSObject(HashSet elds); public extend(Key key, Object obj); public boolean match(SOSObject sos); public Object select(Key key); public Object decrypt(Object obj); g

SecureObjectSpace This class represents the SOS itself. It provides associa-

tive addressing and the methods in, out and read. The latter is a non-destructive version of in (modeled as the atomic execution of an in followed by an out). Both of these are blocking. The out operation is synchronized to guarantee mutual exclusion. The SOS represents an object in serialized form within the space; thus out serializes the value component of each SOSObject, in and read deserialize it. public nal class SecureObjectSpace implements Serializable f public SecureObjectSpace(); public synchronized void out(SOSObject obj); public SOSObject read(SOSObject obj); public SOSObject in(SOSObject obj); g

4.1.2 The diculty with inheritance

To match an SOSObject with one in the shared space implies that we have some way of comparing the value elds (which are of type Object). There are two alternatives to implementing this functionality. The rst approach is to allow each object to de ne a match method. The advantage of this approach is that the meaning of match can be de ned for each class. For instance, a programmer can decide if a linked list of objects matches with another list simply on the basis of the list length, or if a recursive match of the list elements is also required. This exibility is the main reason why inheritance exists in languages in the rst place. On the other hand, allowing each introduced class to de ne its own match method poses security risks. An attacker could program the match of his class to subvertly execute methods of the object it is being matched with, in the aim of stealing or vandalizing the state of this object. Alternatively, he could program a match method that loops, thereby subjecting the system to a denial of service attack. As an example of the two opposing approaches to allowing classes to de ne their own match behavior, consider Jada [6] and JavaSpaces [20]. Jada allows the programmer to de ne his own matching behavior for each class that he de nes. The match function is de ned by the equals method by default, or by 15

a method match for objects that implement the JadaItem interface. The match function is xed in JavaSpaces; here, an object written to the shared space is rst transformed to a serialized java.rmi.MarshalledObject. The equals method of MarshalledObject is used for the match, which the user has no possibility of overwriting. We adopt the JavaSpaces solution for SOS because of the serious security risks posed by inheritance. The out operation of class SecureObjectSpace serializes the value elds of the objects, and stores them in this serialized form. The serialized form of objects are used in comparison of values; since these can be interpreted as instances of java.rmi.MarshalledObject, we employ its equals method for object comparison.

4.1.3 The diculty with aliasing

Aliasing, due to reference semantics, is a fact of life in object-oriented systems. It is the key to dynamic information sharing, but it is also pretty much unavoidable as most object languages, Java is no exception in that respect, use references as their default parameter passing mode. The main problem with aliasing in the context of the SOS model is that it undermines the role of the space: that of being the sole communication mechanism for communicating agents, on top of which security policies are enforced. It is important to ensure that an object placed within a SOS does not possess back pointers to the agent. This ensures that the in of a tuple by one agent does not inadvertently give pointer access to an object in another agent. Otherwise, our goal of centralizing sharing and security at the level of the SOS is undermined. A logical consequence of this is that two SOSObjects not be allowed to reference the same object in the SOS. This means that two consecutive outs of the same object create two copies of that object in the SOS. In the implementation, our use of the serialization functions of Java when creating a SOSObject and copying semantics when selecting elds from an object satis es this constraint.

Perspectives One feature not yet implemented is the code for saving keys

and objects on disk. Also, an extension that we might integrate into the implementation that does not appear in the calculus is to allow a query to the SOS to specify a class name in place of ?, and to ensure that the SOSObject returned contains an object which is a subclass of that class in the eld that matched the key.

4.2 Using SOS for coordination

We present two examples of our use of the SOS model for communication in the JavaSeal agent environment.

Layered security We propose to implement a shared object space as a root

level service in JavaSeal. The basic architecture is depicted in Figure 1. Interactions with the SOS will follow the same general pattern: An agent creates an entry object and sends the SOS object in a message. The message can either be an in message or an out message. In the case of an in message the agent 16

expects to get, as a reply, an entry matching its template. Messages are forwarded upwards trough the hierarchy until the root is reached, at which point the actual object space operation is performed. For each level in the hierarchy, the security policy in vigor at that level is applied to the entry. Object Space in out

A1 MPI

B1 S1

MPI

A2

A3

B2 S2

B3 S3

Java Virtual Machine

Figure 1: JavaSeal system. For instance, an example policy would be to restrict the communication of agents by their security level. This is done by extending both in templates and out objects with a shared-key eld that indicates the security level of the sender. For example we show below a class fragment with two methods that systematically restrict matching to low-level security processes. SymKey securityLevel = new SymKey() ; String low = new String( \low" ); ... public SOSObject in( SOSObject request ) f SOSObject extRequest = request.extend( securityLevel , low ); return sos.in( extRequest ); g

public SOSObject out( SOSObject request ) f SOSObject extRequest = request.extend( securityLevel , low ); return sos.out( extRequest ); g

Since in JavaSeal there may be several levels of nesting, these restrictions may be layered on the request at each level. The interesting point is that the clients will never see this information, it is used only for the match.

Logical channels One use of keys is to create logical communicationchannels.

Here we show the example of a server that is specialized in the demanding task of computing factorials. The protocol for interacting with the server is to send it a request which contains a number and reply key. The server's job is to await requests to compute factorials and use the reply key included in the request to return its answer. 17

The client will thus be written as: SymKey myKey = new SymKey(); Object[] pair = f new Integer( 3 ), myKey g; Object[] contents = ffactPublicKey, pair g; sos.out( new SOSObject( contents ) ); Object[] template = f myKey , nil g; SOSObject reply = sos.in( new SOSObject( template ) );

The server will be written as: Object[] template = f factPrivateKey , nil g; SOSObject query = sos.in( new SOSObject( template ) ); Object[] pair = query.select( factPrivateKey ); Integer i = pair[0]; SymKey returnKey = pair[1]; Object[] contents = freturnKey, fact( i ) g; sos.out( new SOSObject( contents ) );

The request and reply objects may pass through dierent processes which will not be able to hide or fake the reply. Replay attacks can be prevented by adding nonces.

5 Related Work The work of Gordon and Abadi has inspired some aspects of the theoretical treatment of SOS. In the spi calculus, they extend the -calculus to employ cryptography for messages sent over named channels [2]. Abadi also equates the security of a protocol which are pre-de ned message exchanges, to its type correctness [1]. While this is clearly applicable for protocols, we do not see a direct relation with the dynamic typing of SOS. The Klaim language (also known as LLinda) takes another approach to security. There, a process requires access rights (read or write) to use a tuple space [8]. Access rights are represented as types, and a static type analysis is sucient to determine if a process attempts to read or write a tuple space without possessing the right. This approach complements our proposal. While dynamic checking is necessary in a mobile agent context, it is also important to investigate the class of security properties that can be veri ed in SOS using a static approach such as Klaim's. The role of typing in the matching process has received much attention recently. The Laura system, for instance, is a WAN service architecture based on the shared space model [24]. One reason why the shared space paradigm is exploited is that it allows services to join and leave the system dynamically. Services place oers in the space which are matched with requests. An oer or request is an interface form that matches if the type of the service is a subtype of 18

the requestor's. Alice is the type system employed for matching these interfaces [22]. Dami also investigates type inference for generative communication [7]. As regards implementing the shared object paradigm in Java, we have already cited JavaSpaces [20] and Jada [6]. In particular, section 4.1 mentioned the dierent approaches taken by these systems to implementing the match function. Jada is one example of the shared space paradigm being used to coordinate mobile agents: it is employed in the PageSpace agent architecture. More generally, neither Jada nor JavaSpaces were designed with security issues in mind. Though keys can be employed to protect items in the tuple from agents, this can only be done using encryption algorithms, even for agents executing within the same JVM which is too inecient for generalized use. Apart from Java, the shared space paradigm, usually in its Linda variant, has been integrated into several languages, C, Prolog [5], C++ [18], SmallTalk [15] and Eiel [13]. Interestingly, the papers that treat object-oriented languages have not considered the security issues posed by inheritance and user de ned matching.

6 Conclusion

In this paper, we have considered support for multiple independent and mistrusting software components that cooperate by means of a shared object space. To this end, we presented a model that integrates the notion of keys into the shared space model. Security is enforced through typing, and this is sucient to emulate the encryption semantics found in crypto-systems. Further, the model can be implemented in Java provided that some care is taken with respect to aliasing and inheritance. We showed that in the Java implementation, encryption is only needed when SOS objects leave the type-safe environment of their virtual machine, for instance, when they are transferred over a network or being stored on disk.

References

[1] M. Abadi. Secrecy by Typing in Security Protocols. Theoretical aspects of Computer Software, pages 611{638, September 1998. [2] M. Abadi and A. D. Gordon. A calculus for cryptographic protocols: The Spi calculus. In Proceedings of the Fourth ACM Conference on Computer and Communications Security, Zurich, April 1997. ACM Press, 1997. Long version as Technical Report 414, University of Cambridge. [3] L. Cardelli. Abstractions for mobile computations. Manuscript, Microsoft Research, 1998. [4] N. Carriero, D. Gelernter, and L. Zuck. Bauhaus Linda. In P. Ciancarini, O. Nierstrasz, and A. Yonezawa, editors, Object-Based Models and Languages for Concurrent Systems, volume 924 of Lecture Notes in Computer Science, pages 66{76. Springer-Verlag, Berlin, 1995. [5] P. Ciancarini. Distribued Programming with Logic Tuple Spaces. Technical Report UBLCS-93-7, The Technical University of Berlin, April 1993. [6] P. Ciancarini and D. Rossi. Jada: Coordination and Communication for Java Agents. In J. Vitek and C. Tschudin, editors, Mobile Agent Systems: Towards the Programmable Internet, volume 1222 of Lecture Notes in Computer Science, pages 213{228. Springer-Verlag, Berlin, 1997.

19

[7] L. Dami. Type Inference and Subtyping in Higher-Order Generative Communication. In D. Tsichritzis, editor, Object Applications, pages 173{204. University of Geneva, 1996. [8] R. DeNicola, G. Ferrari, and R. Pugliese. Coordinating Mobile Agents via Blackboards and Access Rights. In D. Garlan and D. LeMetayer, editors, Proc. 2nd Int. Conf. on Coordination Models and Languages, volume 1282 of Lecture Notes in Computer Science, pages 220{236, Berlin, Germany, September 1997. SpringerVerlag, Berlin. [9] C. Fournet, G. Gonthier, J.-J. Levy, L. Maranget, and D. Remy. A calculus of mobile agents. In CONCUR96, pages 406{421, 1996. [10] D. Gelernter. Generative communication in Linda. ACM Trans. Prog. Lang. Syst., 7(1):80{112, Jan. 1985. [11] D. Gelernter. Multiple Tuple Spaces in Linda. In E. Odijk, M. Rem, and J. Syre, editors, Proc. Conf. on Parallel Architectures and Languages Europe (PARLE 89), volume 365 of Lecture Notes in Computer Science, pages 20{27. Springer-Verlag, Berlin, 1989. [12] S. Hupfer. Melinda: Linda with multiple tuple spaces. Technical Report RR YALEU/DCS/R-766, Dept. of Computer Science, Yale University, New Haven, CT, 1990. [13] R. Jellinghaus. Eiel Linda: an Object Oriented Linda Dialect. ACM Sigplan Notices, 25(12), December 1990. [14] G. Matos and J. Purtilo. Recon guration of hierarchical tuple spaces: Experiments with Linda-polylith. Technical report, Computer Science Department and Institute for Advanced Computer Studies, University of Maryland, College Park, MD 20742, 19?? [15] S. Matsouka and S. Kawai. Using Tuple Space Communication in Distributed Object Oriented Languages. In Proc. ACM Object Oriented Programming, Systems, Languages and Applications (OOPSLA 88), pages 1{10. ACM Press, 1988. [16] R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes, Parts I and II. Journal of Information and Computation, 100:1{77, Sept. 1992. [17] N. B. of Standards. The Data Encryption Standard. Technical Report Publication 46, Federal Information Processing Standards, January 1977. [18] A. Polze. The Object Space Approach: Decoupled Communication in C++. In Proc. Technology of Object-Oriented Languages and Systems (TOOLS 93), pages 195{204, 1993. [19] R. Rivest, A. Shamir, and L. Aldeman. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, 21(2):120{126, 1978. [20] Sun MicroSystems. JavaSpaces Speci cation. Technical report, Sun MicroSystems Inc., July 1998. [21] D. Tennenhouse. Active networks. In USENIX, editor, 2nd Symposium on Operating Systems Design and Implementation (OSDI '96), October 28{31, 1996. Seattle, WA, pages 89{??, Berkeley, CA, USA, Oct. 1996. USENIX. [22] R. Tolksdorf. Alice - Basic Model and Subtyping Agents. Technical Report 1993/7, The Technical University of Berlin, 1993. [23] R. Tolksdorf. Coordinating Java Agents with Multiple Coordination Languages on the Berlinda Platform. In Proc. 6th IEEE Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE), pages 121{126, Boston, June 1997. IEEE Computer Society Press.

20

[24] R. Tolksdorf. Laura: A Service-Based Coordination Language. Science of Computer Programming, 31:359{381, 1998. [25] J. Vitek and C. Bryce. Secure Mobile Code: The JavaSeal experiment. In submitted for publication, 1999. [26] J. Vitek, C. Bryce, and W. Binder. Designing JavaSeal: or How to make Java safe for agents. In D. Tsichritzis, editor, Electronic Commerce Objects. University of Geneva, 1998. [27] J. Vitek and G. Castagna. A calculus of secure mobile computations. In Proceedings of the IEEE Workshop on Internet Programming Languages, (WIPL). Chicago, Ill., 1998.

21