Secure Object SpacesA coordination model for AgentsCiar�an Bryce Manuel Oriol Jan VitekAbstractCoordination languages based on shared data spaces are well suitedto programming parallel applications composed of cooperating softwarecomponents. Secure Object Spaces (SOS) extend this model to supportcomposition of independently developed, mutually suspicious, softwarecomponents. SOS provides exible and e�cient security facilities basedon a cryptographic re-interpretation of object types. We discuss the im-plementation of secure object spaces in the context of a Java-based mobileagent system.1 IntroductionCoordination languages based on shared data spaces have been around for over�fteen years. Oftentimes, researchers have advocated their use for structuringdistributed and concurrent systems. This because the mode of communicationprovided by these languages, sometimes called generative communication, isanonymous | processes interact by reading and writing entries in a sharedspace without having to know their interlocutor(s); and is uncoupled| pro-cesses are not tied to their communication partners. These characteristics makeit straightforward to program resource discovery protocols that match up clientswith servers based on their respective o�ers [24], to program in an event-drivenstyle [20] and to dynamically recon�gure running systems [14]. All of these fea-tures are important for distributed systems. Yet, the practical applications ofcoordination languages remain limited to parallel programs made up of cooper-ating components coming from the same source.To make good on the promises of the approach, coordination languages mustsupport the composition of independently developed software components com-ing from multiple sources and, at least in some cases, mutually suspicious com-ponents. This requires more structured communication primitives and securitymechanisms 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 ashared space, have been designed carefully and are well-behaved. Unfortunately,mistakes are easily made, the simplest example is reading an entry which ispart of another protocol [24, 15], and nothing prevents malicious processes fromspying or even corrupting the data exchanged over the common space.In this paper we present the Secure Object Spaces coordination model, orSOS, and argue that this model can be used to solve the above mentioneddi�culties. In a SOS, entries in the shared space are protected by keys. These1

keys, both symmetric and asymmetric, are used to query the data space and toprotect the contents of the data space entries. Our contributions are a formalpresentation of the SOS model as a process calculus, a relation between typesand 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 communicationfrom a particular angle; our goal is to provide tools for composing mobile agentapplications. Section 2 gives some background on mobile agents and lists theirneeds in term of coordination. Section 3 present the SOS model, introduces theSOS calculus giving it an operational semantics, and formalizes the relationshipbetween types and cryptographic primitives. Section 4 presents our implemen-tation of SOS in Java and gives some examples that relate to the requirementsof Section 2. Sections 5 and 6 present related work and our conclusions.2 Coordinating mobile agentsSpurred by the success of the Internet, a number of projects are experiment-ing with new approaches for constructing distributed systems. Mobile agentsare software components comprising code (agent behavior) and data (agentstate). Agents carry out distributed computations by moving around the net-work. When running on a site, an agent may use that site's resources andinteract with other agents located at the same site [21, 9, 27, 26, 3]. Mobileagent applications are programmed in a style that emphasizes a clear separa-tion between local and remote interaction; local interaction takes place amongstco-located agents, on the other hand, remote interaction is obtained by movingagents.Not surprisingly, a key issue for agent programming is how to structure andregulate the communication between agents. Agent communication is essen-tial | without it there would be little point in moving | it is thus desirableto facilitate the expression of communication protocols by providing high-levelprimitives to that end. Yet, for obvious security reasons, this communicationmust be regulated and structured.Consider as an example, the JavaSeal mobile agent system [26]. In JavaSeal,agents communicate through a message passing interface. Their communicationis regulated by strong restrictions: agents are hierarchically structured and theyare allowed to communicate only with their direct parent. Thus it is possibleto �lter and control all communication between agents. A parent may, for ex-ample, choose to disallow communication between agents of di�erent securitylevels simply by refusing to transfer messages. Message based communicationis appropriate for certain forms of interaction, but it can also be cumbersome.This is especially true in the case of JavaSeal where all interaction betweenagents is routed by their parents, and this routing coded by the user.Our goal is to extend JavaSeal with a form of generative communicationwhich simpli�es the coding of some common patterns of interaction betweenagents without breaking the security model. Generative communication is at-tractive as it simpli�es the task of introducing agents to each other and recon�g-uring 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 space2

mechanisms to JavaSeal1 . The main weaknesses of Linda for our purpose areits lack of access control mechanisms and the absence of support for structuredcommunication.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 trustedto manipulate the data in that space and to interact with other agents whichcurrently have access to the same space. The disadvantages of this approach arethat 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 di�cult and likely topose serious e�ciency problems. Moreover, multiple spaces solve only part ofthe problem. In agent applications, protecting the values stored in the dataspace is di�erent from protecting the data space itself. In particular, an agentthat plays the role of a garbage collector may have the right to retrieve entriesfrom a common space, but should not be able to access their contents. Theentries should be treated as opaque values.The lack of structured communication shows up when programming logicalchannels [24]. Logical channels structure communication. For example in aclient-server interaction, only the client should read the server's reply. In groupcommunication, messages are addressed to members of the group and not to anarbitrary process that happens to emit a matching request. These structuresare increasingly important when one wishes to run independent applications ontop of the same data space, and where sharing only exists for basic services.To summarize, we place the following requirement on a mobile agent coor-dination model:� Privacy: The privacy of secret data contained in the �elds of an entrymust be preserved. Thus it should be possible to communicate a passwordor bank account number without fear of disclosure. The implication ofprivacy is that access to the �elds (the contents) of a data space entrymay be restricted. Clearly, privacy must be preserved outside of the agentplatform including in network and disk storage formats.� Layered security: Security policies are layered when several di�erentcomponents in an environment can formulate restrictions on the sameoperation. In an agent system, we may have a sandbox agent that allowsall agents executing within it to communicate, while another agent mayspeci�es that no communication between the sandbox and the rest of thesystem is permitted.� Garbage collection: A shared resource is a target for denial of serviceattacks. Thus an agent may ood the data space with useless entries forthe sole purpose of degrading performance. In a data space there is nocut and dried criterion for deciding which entries are not needed anymore.Garbage collection algorithms are thus application speci�c and are im-plemented at user level with possibly several di�erent garbage collectoragents working in parallel on the same space. Typical policies include1The coordinationmechanismswe envisage di�ers from SUN's JavaSpace [20] in that spacesare not distributed, and that the goal here is to coordinate agents on the same platform3

removing entries after an agent migrates and associating a time-to-live toentries.� Logical channels: Support for a exible notion of logical channels (uni-cast and multicast) is required.� E�ciency: As data space operations are frequent, their computationaloverhead must be as low as possible.3 Secure Object SpacesWe introduce a coordination model that meets the above mentioned require-ments. The essence of our proposal is to view all object space manipulations ascryptographic primitives. We use the term secure object space, or SOS, both torefer to the model and the actual shared data structure.A secure object space is a relative of the Linda tuplespace. In Linda, pro-cesses write ordered sequences of data elements, tuples, into a common tu-plespace (out) and retrieve tuples by querying the tuplespace with a partiallyspeci�ed tuple called a template (in and read). The role of the tuplespace isto associate a template with one of its tuples, this process is called matching .There can be multiple candidates that match a given template; the tuplespacechoses 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 objecthx : 1999; yz : "JohnDoe"ihas two values, an integer and a character string, which are labeled x and yzrespectively. Writing a value to an object space is viewed as an encryptionoperation in the course of which every value of the object is encrypted under itslabel. In the example, x is a symmetric key and yz is an asymmetric key pair.Thus the object actually inserted in the SOS ishKSx (1999);KAy ("JohnDoe")iThe matching performed by the SOS is the inverse operation. The matchingprocedure is given a template object, the labels of which will be used as decryp-tion keys and the values for comparison. Thus, the template containing a single�eld, labeled x and containing the special \don't care" value ? ishx : ?iThis template matches the object presented above. The semantics of matchingis to try to decrypt each �eld of each object in the space with x. Any successfuldecryption means that a match has been found, in case of multiple matches theSOS 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 thekey nothing more can be learned. The following template also matcheshz : ?; x : 1999i4

Here z is the decryption key of yz. The order in which the �elds appear is notrelevant. Note also that �eld values can be used in matching (albeit only afterdecryption).Readers familiar with the overhead of cryptography will by now be waryabout the e�ciency of an implementation of SOS. The key to our proposalis that while the semantics that we outlined informally are those we want toreason with, we provide an implementation that (almost) never actuallyencrypts anything. Matching is implemented at the programming languagelevel by dynamic type checking. Encryption is only required when values leavethe control of the language runtime, e.g., to be stored on disk or shipped overthe network.We present the SOS model in the setting of a process calculus inspired bythe �-calculus [16]. This minimal setting highlights the unique features of themodel and allows us to give a precise semantics to SOS operations. The calculusallows multiple object spaces, this feature is not essential, it was added to makesome of the examples clearer.3.1 Syntax and Basic De�nitionsWe assume an in�nite set of names ranged over by meta-variables a; b; c. Theset of labels L is composed of pairs of names, ab, meta-variable ` ranges overlabels. We de�ne the co-label function � as ab = ba. We assume a distinguishedvoid element, denoted by ?, sole inhabitant of set B.The set of basic values, ranged over by x; y; z, is the disjoint union of Land B. The notation, x 2 T , states that x is of type T (either L or B). Thesubtype relation � on basic values is an order relation with L � B. In a full edged language, we expect a richer type system and a more interesting subtyperelation, but this su�ces for our purpose.An object h`1 : x1; : : : ; `n : xni 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, �eldsranged over by f , and expressions ranged over by e are de�ned by the grammar:Processes ExpressionsP ::= 0 inactivityj P j Q compositionj !P replicationj in(t; �)@e :P inputj out(t)@e outputj (� a)P restriction e ::= ?j ab labelj t:e selectionf ::= e : e �eldt ::= h~f i objectj t� f extensionj � variable0 denotes the inert process. P j Q denotes parallel composition. !P de-notes replication of process P . in(t; �)@e :P is a synchronous input primitivewhich binds � to an object matching template t in space e, then proceeds asP . out(t)@e is an asynchronous output primitive that places object t in space5

e. (� a)P denotes the creation of a fresh name, a, in P . Expressions includeselection 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 se-quences of �elds f1 : : : fn to ~f . Trailing inert processes are elided, thus in(t; �)@e :0becomes in(t; �)@e. The notation for capture avoiding substitution is Pft=�g.By convention we abbreviate labels of the form aa to a when no ambiguity canarise. We write ` : x 2 h` : x; `1 : x1; : : : ; `n : xni.3.2 Relating types to cryptographyIn SOS, object types are related to cryptographic operations.We present some relevant facts about cryptography. Symmetric schemessuch as DES, [17], use a shared key to encode data into ciphertext and the samekey to decrypt the data. We write KSa (v) to denote the encryption of v undershared-key a, and note that KSa (KSa (v)) = v. Asymmetric schemes, also knownas 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 valuev under s by KAs (v) and we have KAp (KAs (v)) = v. In the remainder we makesome 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 su�cient redundancy in messages so that the decryption algo-rithm 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 willtreat labels as keys. In our syntax we write ab = ba to denote that a is a publickey and b is the corresponding private key. The relation is symmetric in thata public key may be used for encryption as well as decryption. We write aa todenote shared key cryptography. (In our notation the following holds: ab = aband 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 beused as keys. In practice key pairs are generated, but this is not signi�cant forthe present discussion.In the SOS, an object such ash`1 : x1; : : : ; `n : xniis stored encrypted in the space ashK`1(x1); : : : ;K`n(xn)iTo retrieve it, it is necessary to present a subset of f`1; : : : ; `ng to the objectspace. Possession of any of the n keys then grants access to the correspondingvalues.We now turn to object types and subtyping. This discussion will lead up tothe de�nition of the notion of type-matching and the associated theory. Sub-typing allows one to view a value of some type T as if it were of some other type6

T 0, provided that T and T 0 are related by subtyping (T � T 0). Even though a Tobject may have more �elds than those de�ne at type T 0; these �elds are hiddenwhen the object is viewed as a T 0 object. The type protects hidden �elds. Infor-mally, we may view a type as some kind of shared-key which controls the accessto objects. We will push the analogy and extend it to public-key cryptography.Public-key cryptography introduces an asymmetry that leads us the de�nitionof the type-matching relation (E) which is related to subtyping, but which hassigni�cantly di�erent mathematical properties.De�nition 1 (SOS object type) An object h~f i is of type T = f`1 : T1; : : : ; `n :Tng, written h~f i 2 T , i� ~f = `1 : x1; : : : ; `n : xn; and xi 2 Ti. We also de�nea 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 shallreturn to this later.De�nition 2 (subtyping) The object subtype relation � relates object types:T � T 0 i� for all ` : T 2 T there exists ` : T 0 2 T 0 and T = T 0Immediately it follows that � is a partial order relation on object types (tran-sitive, re exive, antisymmetric).We introduce the type-matching relation which will be used when checkinga template object t 2 T against a candidate object t 2 T 0.De�nition 3 (type-matching) The match relation E relates types:T E T 0 i� for all ` : T 2 T there exists ` : T 0 2 T 0 and T 0 � TIntuitively, T type-matches T 0 if each �eld of T 0, ` : T 0, is matched by a �eld,` : T of T and the type of the value in T 0 is a subtype of that of T . In otherwords, T 0 may have more �elds than T , but the �elds in T 0 may be more speci�c.We now give some properties of type-matching.Lemma 1 (E relation)1. If T E T 0; T 0 E T 00 and T 00 E T 000 then T E T 000.2. T E T .3. If T E T 0; T 0 E T then T = T 0.4. If T E T1; T1 E T 0 and T 0 E T2; T2 E T then T = T 0 and T1 = T2.5. If T1 � T 01 ; T 02 � T2 and T 01 E T 02 then T1 E T2Proof Points 1, 2 and 5 follow from straightforward application of the de�-nitions. 7

Point 3 By De�nition 1 we have T = f`1 : T1; : : : ; `n : Tng and T 0 = f`01 :T 01; : : : ; `0n : T 0ng. Two applications of De�nition 3 yield:T E T 0 E T i� for all ` : T 2 T there exists `0 = ` : T 0 2 T 0 and T 0 �T and i� for all `0 : T 2 T there exists `00 = `0 : T 00 2 T and T 0 � T 00This means that for all ` 2 T there is an `0 2 T 0, and also an `00 2 T , suchthat `00 = `0 = `. By de�nition, we also have ` = `. By unicity of labelsin objects (De�nition 1), we then have T = T 0 and ` = `0. It follows byrenumbering �elds of T 0 that T 0 = f`1 : T1; : : : ; `n : Tng = T .Point 4 By De�nition 3 we have:T E T1 E T 0 i� for all ` : T 2 T there exists `0 = `1 = ` : T 0 2T1 and T 0 � T1 � Tand the symmetric with T 0 E T2 E T 0 then we know that ` = ` then `0 = `and the two following relations hold: T 0 � T1 � T and T � T2 � T 0. Bytransitivity of � it follows T 0 � T and T � T 0 and then by antisymmetryT = T 0. T and T 0 then have the same entrys and are equals. There isthen T E T1 E T and T E T2 E T . Using Lemma 1.3 this implies thatT1 = T = T2.Note that the following property does not hold T1 E T 01 and T 01 � T 02 andT 02 E T2 then T1 � T2.Some comments about the properties stated in Lemma 1. Property 1 isa 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 usefulfor establishing equality between types either between T1 and T2 or between Tand T 0. Property 5 is the composition of traditional subtyping (�) and matchingtypes (E).Examples Some examples of type-matching are given to illustrate the de�ni-tion:1. For any T , we have hi E T . The empty type matches any other types,but this does not provide access to the �elds. Trivially, we have hi E hi.2. A smaller type matches a longer type: ha : Li E ha : L; b : Li.3. A type matches a more speci�c type: ha : Bi E ha : Li.4. A type matches its co-type: hab : Li E hba : Li.We may now proceed to give a de�nition of the matching procedure whichtakes a template object t and a candidate object t0 and establishes whetherthe candidate meets the speci�cation of the template. This de�nition use thetype-matching de�ned above and does not require cryptography.De�nition 4 (Matching) The matching relation �/ relates objects, t �/ t0,i�:1. t 2 T ; t0 2 T 0 and T E T 0,2. ` : x 2 t; ` : y 2 t0; x 2 T and y 2 T implies x = y.A template matches a candidate if the type of the template matches the type ofthe candidate and if for every �eld with matching labels and equal types, valuesare equal as well. 8

Examples1. hi �/ t for any t. This fact can be used in to collect objects withoutconsidering their contents.2. h`1 : x; `2 : yi �/ h`1 : x; `2 : yi3. h`1 : xi �/ h`1 : x; `2 : yi4. h`1 : x; `2 : ?i �/ h`1 : x; `2 : yi because ? 2 B and y 2 L and L � B5. We do not have: h`1 : x; `2 : yi �/ h`1 : x; `2 : ?i6. Similarly, we do not have: h`1 : x; `2 : y; `4 : zi �/ h`1 : x; `2 : y; `3 : zi orh`1 : x; `2 : y; `3 : zi �/ h`1 : x; `2 : y; `4 : zi.7. Adding �elds to an object restricts its potential for matching, thus witht = h` : xi and t0 = h` : xi we have that t �/ t0. But if we extend twith a �eld `0 : y, the match fails. Thus the following does not hold:(t� `0 : y) �/ t0. (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 notintroduced an operator for testing co-equality of object types, and we do notneed to. By Lemma 1.3 we have that if T E T 0 E T then T = T 0. The resultcarries over to object matching. If t �/ t0 �/ t, we say that objects are co-equal,i.e., t = t0. Getting ahead of ourselves a little, we show how to ensure that anobject has no hidden information. Here process P will execute only if if t = t0.(The semantics of the calculus are given in the next section.)(� a)(out(t)@a j in(t0; �)@a : ( out(t0)@a j in(t; �)@a :P ))To summarize, we have presented a notion of matching which relies on propertiesof object types to implement object matching in the SOS. In particular thede�nitions given here provide the same kind of protection as symmetric andasymmetric cryptography primitives but within a safe language environment.3.3 Reduction semanticsThe reduction relation ! is de�ned over processes and represents one step ofcomputation. Reduction is de�ned by means of two auxiliary notions: structuralcongruence and evaluation.Structural congruence, �, is the least congruence on processes satisfyingaxioms and rules described in Figure 1. It does not handle renaming of boundvariables. Instead, we consider that alpha-conversions are silently performedwhenever needed. The evaluation relation (#) yields the result of expressioninvolving �eld selection and object extension. The reduction relation ! is theleast relation on processes that satis�es axioms in Figure 1.Nonsensical terms such as out(t)@? and h? : e; ~fi or erroneous h~f i � ` : xwhere ` 2 h~f i are allowed by the syntax of the calculus. To some extent theseterms could be prevented by a type system. In this paper we prefer to considerthat computation does not proceed for terms containing these expressions.9

ReductionP ! Q(� x)P ! (� x)Q P ! QP j R! Q j R P � P 0 P 0 ! Q0 Q0 � QP ! Qe2 # x e4 # x e1 # t e3 # t0 t0 �/ tout(e1)@e2 j in(e3; �)@e4 :P ! Pfe1=�gEvaluationx # x e # t0 t � t0e # t t � he1 : e2; ~fi e1 # ` e2 # x e # `t:e # xStructural congruenceP j Q � Q j P(P j Q) j R � P j (Q j R) h` : x; ~fi � h~f ; ` : xi` 62 h~f i ) h~f i � ` : x � h` : x; ~fi!P � P j !P(� a)(� b)P � (� b)(� a)Pa 62 fn(P ) ) (� a)(P j Q) � P j (� a)QFigure 1: SOS reduction semantics.We may now proceed with examples that demonstrate the expressiveness ofthe calculus and that show how to meet some of the requirements outlined inSection 2.Synchronization A process may synchronize on an object space, considerthe process out(hi)@a j in(hi; �)@a :Pwhich reduces in one step to Pfhi=�g. Here the empty object is not used further.Repeater A process that reads objects and writes them back is:! in(hi; �)@a :out(�)@aIn this case the matching rules will allow the repeater to retrieve any object andwrite it back immediately after that.Multiple object spaces Although we shall not expand on this point, theSOS calculus has multiple object spaces. Thus the processin(hab : ?i; �)@c : (out(�)@c j out(�)@d)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 tonames, through they are actually labels.)First-class templates Unlike Linda, SOS templates are objects, thus it ispossible to use any object to query the SOS. For example, the following processtakes any object from space a and uses it to query space b:in(hi; �)@a : in(�; �0)@b :PIf we compose the above process in parallel without(ha : ?i)@a j out(ha : bi)@bThe composed term will reduce toPfha:bi=�0gDynamic recon�guration Communication patterns are dynamic, processmay easily change communication partners within an SOS, but they may alsoacquire new SOS identi�ers in the course of computation. Consider the termin(hb : ?i; �)@a :out(�)@�:bThe process starts by retrieving an object encrypted with a symmetric key bwith in(hb : ?i; �)@a. Then it proceeds by writing the object back in a spaceidenti�ed by �:b, that is, the selection and (symmetric) decryption of a �eldlabel b from �. A communication partner for this term could beout(hb : ci)@aBulk encryption In cryptosystems, the di�erence in running time betweenpublic key encryption and shared key encryption are such that it is advantageousto encrypt large volumes of data with a shared key and only encrypt the sharedkey with the private key. In SOS, we can code a process that sends a symmetrickey a encrypted under an asymmetric key bc and a value d encrypted under a.The process is e.g., (� a)out(hbc : a; a : di)@xThe partner that uses d as a space identi�er isin(hcb : ?i; �)@x :out(�)@�:(�:cb)The evaluation rules states that hbc : a; a : di:cb is a and hbc : a; a : di:a is d.Garbage collection We can implement a time-based garbage collector agent(GCA) as a process that mediates access to an object space. Every outputrequest is sent to the GCA which adds some GC speci�c information to theobject before inserting it in the space. For a time-based garbage collector thisinformation may simply be a time-to-live �eld. This is coded in the calculus asin(hi; �)@a :out(�� TTL : x)@b11

assuming that a denotes a space in which insertion requests are placed and bdenotes the actual SOS used for communication. Further, x is some time stamp.The evaluation rule decrees that the extension expression �� TTL : x returnsan object with a TTL �eld, here TTL is a shared key which we assume to beknown only to the GCA.Once a given time stamp ceases to be valid, the following process will collectthe garbage ! in(hTTL : xi; �)@busing the value matching rule to extract only objects that have been stampedat time x.The interesting point here is that the GCA is a user level agent which doesnot gain any knowledge about the content of the objects it manipulates. Sec-ondly, we may have several di�erent GCAs with di�erent policies mediating thesame space. Thirdly, GC information is not visible in normal communication.Processes may retrieve time stamped objects as before but will not be able toaccess that information. (They may �nd out that there is information attachedthough.)Linda It is straightforward to model Linda in SOS. Linda uses positionalnotation for matching values in tuples and does not have any equivalent to ourencryption primitives. A Linda tuple hx; y; zi can be translated to an objecth1 : x;2 : y;3 : zi where 1, 2 and 3 are globally scoped names that standfor positions in the obvious way. A Linda output operation out(hx; yi)@a istranslated to an SOS out(h1 : x;2 : yi)@a. A Linda query in(h?v; yi; a)@ :P istranslated to in(h1 : ?;2 : yi; �)@a :P 0 where all occurrences of v in P will bereplaced with �:1.Asynchronous �-calculus An encoding of the asynchronous �-calculus canbe obtained by using spaces as channels and restricting matching to the trivialcase. Roughly the encoding is as follows. Every � write xy is translated toan output out(hsr : yi)@x and every input pre�x of the form xy :P would betranslated to an input operation in(hrs : ?i; �)@x :P 0 where P 0 is the translationof P with occurrences of the variable y replaced by �:rs.This concludes the presentation of the calculus of secure object spaces. Beforeproceeding with the implementation of the SOS model one last remark. Byintroducing labeled �elds, the SOS model abandons the positional notation usedin Linda systems. Independent of its cryptographic interpretation, the labels ofthe SOS model add structure to generative communication. Linda programs relyon an unwritten agreement on the meaning and use of di�erent �elds in tuples.While positional notation is easy to use, it is also error prone (two tuples ofthe 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 beforecommunicating) and help in making code more robust [7].12

4 Implementing the SOS ModelThe examples of the previous section have demonstrated the expressive power ofthe SOS model. This section looks at its implementation in the context of Java-based mobile agent systems. In particular, we argue that this implementationis e�cient since, though the semantics of encryption are being emulated withkeys, no encryption is actually taking place so long as the agents remain inthe typing environment of the Java virtual machine (JVM). Encryption is onlyrequired when the tuples are transferred outside of this environment, e.g., overthe network or to disk.Our implementation of SOS is integrated into the kernel of the JavaSealmobile agent platform [26]. This means that all SOS operations are underkernel control. The JavaSeal runtime system enforce access control restrictionsusing language based protection mechanisms (static access control and checkedprimitives outlined in [25]) to guarantee that no agent may gain access to theobjects stored within a SOS entry without possessing the proper keys.Encryption is needed in two cases: when an SOS object is backed up ondisk, and when an agent containing an SOS object migrates. In both cases, theSOS object leaves the control of the runtime system, and for this reason can nolonger be protected by programming language techniques. These are the onlytwo cases where we must resort to encryption.The remainder of this section outlines our implementation and the integra-tion of SOS into JavaSeal.4.1 SOS in JavaWe start the section with a look at the Java API implementing the SOS. Addi-tional helper classes are also required though these are not described here. The�nal two paragraphs look at two aspects of the Java programming languagethat can potentially undermine the security of the SOS implementation, andwhich must therefore be used in a controlled manner: inheritance and objectaliasing.4.1.1 ClassesThe SOS model relies on keys to access the �elds of objects. At the implemen-tation, there is an abstract Key class, with two �nal subclasses AsymKey andSymKey which represent the asymmetric and symmetric keys respectively.Key This class de�nes the common attributes of SOS keys. The key �eld isused to store the actual value of the key. This is only used to do real cryptog-raphy when the object that it is guarding is transferred outside of the JVM.The match method compares two key instances. Actual encryption and de-cryption is done with the encrypt and decrypt methods. Here the object beingencrypted/decrypted is the SOS object being guarded by the Key object inthe shared space. The parameters to these operations are Objects rather thanSOSObjects since the latter are stored in serialized form in the SOS. The encryptand decrypt methods are called by the agent transfer code before transfer of theSOS objects over the network. 13

abstract class Key implements Serializable fprivate byte[] key;public abstract boolean match(Key K);public abstract Object encrypt(Object obj);public abstract Object decrypt(Object obj);gSymKey A SymKey represents the shared keys. Its match method expectsits argument to be this, i.e., the same key is used in actual encryption anddecryption.public �nal class SymKey implements Serializable fpublic SymKey(byte[] key);public boolean match(Key K);public Object encrypt(Object obj);public Object decrypt(Object obj);gAsymKey An ASymKey represents asymmetric keys. This class contains thedual key that is needed to match with it. Note also that the constructor isprotected. In e�ect, an asymmetric key is indirectly created. A user �rst createsa KeyPair helper class, which creates the two asymmetric keys. In this way, oneis sure that each asymmetric key has a dual key. The encrypt and decryptmethods use the key �eld for encryption and decryption. This means thatan object encrypted with an asymmetric key in one context (via the encryptmethod) before transfer over the network must be decrypted with a matchingasymmetric key object in the destination agent platform.public �nal class AsymKey implements Serializable fprivate AsymKey dual;protected AsymKey();public boolean match(Key K);public Object encrypt(Object obj);public Object decrypt(Object obj);gSOSObject The SOSObject class implements the behavior of entries in theshared object space. Recall that the notion of subtyping and type matchingde�ned relied on the notion of structural subtyping. This di�ers from the Javatype system since structural subtyping does not require an explicit type hier-archy (such as the hierarchy in Java explicitly de�ned using extends in decla-rations), and structural subtyping naturally allows for multiple supertypes forany given type. The implementation of matching is thus done dynamically inthe match() method of SOSObject which is a �nal method. For the purpose ofmatching, null (the \empty" value for pointers) plays the role of ?.An SOSObject instance is created with a set of key-value pairs. Keys arechecked to be either of type SymKey or AsymKey; a user-de�ned key type isautomatically rejected. The select operation has a method that takes a keyas parameter and returns the object if the key is the correct key, or null if nomatching object is found in the SOSObject.14

The extend operation/method returns a new object obtained by extendingthis with a key-value pair. The operation fails if the pair is already present inthe SOSObject. The match method returns true if the argument SOSObjectmatches. This requires that the keys of both SOSObjects match, and then thatthe values match. We explain how values are matched below, since there aresecurity implications concerning how normal Java objects are compared.public �nal class SOSObject implements Serializable fpublic SOSObject(HashSet �elds);public extend(Key key, Object obj);public boolean match(SOSObject sos);public Object select(Key key);public Object decrypt(Object obj);gSecureObjectSpace This class represents the SOS itself. It provides associa-tive addressing and the methods in, out and read. The latter is a non-destructiveversion of in (modeled as the atomic execution of an in followed by an out). Bothof these are blocking. The out operation is synchronized to guarantee mutual ex-clusion. The SOS represents an object in serialized form within the space; thusout serializes the value component of each SOSObject, in and read deserialize it.public �nal class SecureObjectSpace implements Serializable fpublic SecureObjectSpace();public synchronized void out(SOSObject obj);public SOSObject read(SOSObject obj);public SOSObject in(SOSObject obj);g4.1.2 The di�culty with inheritanceTo match an SOSObject with one in the shared space implies that we havesome way of comparing the value �elds (which are of type Object). There aretwo alternatives to implementing this functionality.The �rst approach is to allow each object to de�ne a match method. Theadvantage of this approach is that the meaning of match can be de�ned for eachclass. For instance, a programmer can decide if a linked list of objects matcheswith another list simply on the basis of the list length, or if a recursive matchof the list elements is also required. This exibility is the main reason whyinheritance exists in languages in the �rst place.On the other hand, allowing each introduced class to de�ne its own matchmethod poses security risks. An attacker could program the match of his classto subvertly execute methods of the object it is being matched with, in theaim of stealing or vandalizing the state of this object. Alternatively, he couldprogram a match method that loops, thereby subjecting the system to a denialof service attack.As an example of the two opposing approaches to allowing classes to de�netheir own match behavior, consider Jada [6] and JavaSpaces [20]. Jada allowsthe programmer to de�ne his own matching behavior for each class that hede�nes. The match function is de�ned by the equals method by default, or by15

a method match for objects that implement the JadaItem interface. The matchfunction is �xed in JavaSpaces; here, an object written to the shared space is�rst transformed to a serialized java.rmi.MarshalledObject. The equals methodof MarshalledObject is used for the match, which the user has no possibility ofoverwriting.We adopt the JavaSpaces solution for SOS because of the serious securityrisks posed by inheritance. The out operation of class SecureObjectSpace seri-alizes 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 canbe interpreted as instances of java.rmi.MarshalledObject, we employ its equalsmethod for object comparison.4.1.3 The di�culty with aliasingAliasing, due to reference semantics, is a fact of life in object-oriented systems. Itis the key to dynamic information sharing, but it is also pretty much unavoidableas most object languages, Java is no exception in that respect, use referencesas their default parameter passing mode. The main problem with aliasing inthe context of the SOS model is that it undermines the role of the space: thatof being the sole communication mechanism for communicating agents, on topof which security policies are enforced.It is important to ensure that an object placed within a SOS does not pos-sess back pointers to the agent. This ensures that the in of a tuple by one agentdoes not inadvertently give pointer access to an object in another agent. Oth-erwise, our goal of centralizing sharing and security at the level of the SOS isundermined.A logical consequence of this is that two SOSObjects not be allowed to ref-erence the same object in the SOS. This means that two consecutive outs of thesame 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 andcopying semantics when selecting �elds from an object satis�es this constraint.Perspectives One feature not yet implemented is the code for saving keysand objects on disk. Also, an extension that we might integrate into the imple-mentation that does not appear in the calculus is to allow a query to the SOSto specify a class name in place of ?, and to ensure that the SOSObject returnedcontains an object which is a subclass of that class in the �eld that matched thekey.4.2 Using SOS for coordinationWe present two examples of our use of the SOS model for communication in theJavaSeal agent environment.Layered security We propose to implement a shared object space as a rootlevel service in JavaSeal. The basic architecture is depicted in Figure 1. In-teractions with the SOS will follow the same general pattern: An agent createsan entry object and sends the SOS object in a message. The message can eitherbe an in message or an out message. In the case of an in message the agent16

expects to get, as a reply, an entry matching its template. Messages are for-warded upwards trough the hierarchy until the root is reached, at which pointthe 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.A1

B1 S1

A2

B2 S2

A3

B3 S3

MPI MPI

Java Virtual Machine

Object Space

in

outFigure 1: JavaSeal system.For instance, an example policy would be to restrict the communication ofagents by their security level. This is done by extending both in templates andout 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 system-atically restrict matching to low-level security processes.SymKey securityLevel = new SymKey() ;String low = new String( \low" );...public SOSObject in( SOSObject request ) fSOSObject extRequest = request.extend( securityLevel , low );return sos.in( extRequest );gpublic SOSObject out( SOSObject request ) fSOSObject extRequest = request.extend( securityLevel , low );return sos.out( extRequest );gSince in JavaSeal there may be several levels of nesting, these restrictions maybe layered on the request at each level. The interesting point is that the clientswill never see this information, it is used only for the match.Logical channels One use of keys is to create logical communication channels.Here we show the example of a server that is specialized in the demandingtask of computing factorials. The protocol for interacting with the server is tosend it a request which contains a number and reply key. The server's job isto await requests to compute factorials and use the reply key included in therequest 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 di�erent processes which willnot be able to hide or fake the reply. Replay attacks can be prevented by addingnonces.5 Related WorkThe work of Gordon and Abadi has inspired some aspects of the theoreticaltreatment of SOS. In the spi calculus, they extend the �-calculus to employcryptography for messages sent over named channels [2]. Abadi also equatesthe security of a protocol which are pre-de�ned message exchanges, to its typecorrectness [1]. While this is clearly applicable for protocols, we do not see adirect relation with the dynamic typing of SOS.The Klaim language (also known as LLinda) takes another approach to se-curity. There, a process requires access rights (read or write) to use a tuplespace [8]. Access rights are represented as types, and a static type analysisis su�cient to determine if a process attempts to read or write a tuple spacewithout possessing the right. This approach complements our proposal. Whiledynamic checking is necessary in a mobile agent context, it is also important toinvestigate the class of security properties that can be veri�ed in SOS using astatic approach such as Klaim's.The role of typing in the matching process has received much attentionrecently. The Laura system, for instance, is a WAN service architecture basedon the shared space model [24]. One reason why the shared space paradigmis exploited is that it allows services to join and leave the system dynamically.Services place o�ers in the space which are matched with requests. An o�er orrequest is an interface form that matches if the type of the service is a subtype of18

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 al-ready cited JavaSpaces [20] and Jada [6]. In particular, section 4.1 mentionedthe di�erent approaches taken by these systems to implementing thematch func-tion. Jada is one example of the shared space paradigm being used to coordinatemobile agents: it is employed in the PageSpace agent architecture. More gen-erally, neither Jada nor JavaSpaces were designed with security issues in mind.Though keys can be employed to protect items in the tuple from agents, thiscan only be done using encryption algorithms, even for agents executing withinthe same JVM which is too ine�cient 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 Ei�el [13]. Interestingly, the papers that treat object-oriented languageshave not considered the security issues posed by inheritance and user de�nedmatching.6 ConclusionIn this paper, we have considered support for multiple independent and mis-trusting 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 theshared space model. Security is enforced through typing, and this is su�cient toemulate the encryption semantics found in crypto-systems. Further, the modelcan be implemented in Java provided that some care is taken with respect toaliasing and inheritance. We showed that in the Java implementation, encryp-tion is only needed when SOS objects leave the type-safe environment of theirvirtual machine, for instance, when they are transferred over a network or beingstored on disk.References[1] M. Abadi. Secrecy by Typing in Security Protocols. Theoretical aspects of Com-puter Software, pages 611{638, September 1998.[2] M. Abadi and A. D. Gordon. A calculus for cryptographic protocols: The Spicalculus. In Proceedings of the Fourth ACM Conference on Computer and Com-munications Security, Z�urich, April 1997. ACM Press, 1997. Long version asTechnical Report 414, University of Cambridge.[3] L. Cardelli. Abstractions for mobile computations. Manuscript, Microsoft Re-search, 1998.[4] N. Carriero, D. Gelernter, and L. Zuck. Bauhaus Linda. In P. Ciancarini, O. Nier-strasz, and A. Yonezawa, editors, Object-Based Models and Languages for Con-current 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 Re-port UBLCS-93-7, The Technical University of Berlin, April 1993.[6] P. Ciancarini and D. Rossi. Jada: Coordination and Communication for JavaAgents. In J. Vitek and C. Tschudin, editors, Mobile Agent Systems: Towardsthe 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 Communi-cation. In D. Tsichritzis, editor, Object Applications, pages 173{204. Universityof Geneva, 1996.[8] R. DeNicola, G. Ferrari, and R. Pugliese. Coordinating Mobile Agents via Black-boards and Access Rights. In D. Garlan and D. LeMetayer, editors, Proc. 2nd Int.Conf. on Coordination Models and Languages, volume 1282 of Lecture Notes inComputer Science, pages 220{236, Berlin, Germany, September 1997. Springer-Verlag, Berlin.[9] C. Fournet, G. Gonthier, J.-J. L�evy, L. Maranget, and D. R�emy. A calculus ofmobile 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 RRYALEU/DCS/R-766, Dept. of Computer Science, Yale University, New Haven,CT, 1990.[13] R. Jellinghaus. Ei�el Linda: an Object Oriented Linda Dialect. ACM SigplanNotices, 25(12), December 1990.[14] G. Matos and J. Purtilo. Recon�guration of hierarchical tuple spaces: Experi-ments with Linda-polylith. Technical report, Computer Science Department andInstitute for Advanced Computer Studies, University of Maryland, College Park,MD 20742, 19??[15] S. Matsouka and S. Kawai. Using Tuple Space Communication in Distributed Ob-ject 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 andII. Journal of Information and Computation, 100:1{77, Sept. 1992.[17] N. B. of Standards. The Data Encryption Standard. Technical Report Publication46, Federal Information Processing Standards, January 1977.[18] A. Polze. The Object Space Approach: Decoupled Communication in C++. InProc. Technology of Object-Oriented Languages and Systems (TOOLS 93), pages195{204, 1993.[19] R. Rivest, A. Shamir, and L. Aldeman. AMethod for Obtaining Digital Signaturesand Public-Key Cryptosystems. Communications of the ACM, 21(2):120{126,1978.[20] Sun MicroSystems. JavaSpaces Speci�cation. Technical report, Sun MicroSystemsInc., July 1998.[21] D. Tennenhouse. Active networks. In USENIX, editor, 2nd Symposium on Op-erating 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 Report1993/7, The Technical University of Berlin, 1993.[23] R. Tolksdorf. Coordinating Java Agents with Multiple Coordination Languages onthe 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 Com-puter Programming, 31:359{381, 1998.[25] J. Vitek and C. Bryce. Secure Mobile Code: The JavaSeal experiment. In sub-mitted for publication, 1999.[26] J. Vitek, C. Bryce, and W. Binder. Designing JavaSeal: or How to make Javasafe for agents. In D. Tsichritzis, editor, Electronic Commerce Objects. Universityof Geneva, 1998.[27] J. Vitek and G. Castagna. A calculus of secure mobile computations. In Pro-ceedings of the IEEE Workshop on Internet Programming Languages, (WIPL).Chicago, Ill., 1998.

21