Towards a Calculus of Secure Mobile

Towards a Calculus of Secure Mobile Computations Jan Vitek

Object Systems Group, Centre Universitaire d'Informatique, Universite de Geneve, Geneve, Suisse [email protected]

Abstract

Giuseppe Castagna

C.N.R.S, Laboratoire d'Informatique de l'Ecole Normale Superieure, 45 rue d'Ulm, Paris, France [email protected]

ruption of the logical ow of their execution. The purpose of this form of mobility is to oer a ner control over locality. By moving to a particular host, an agent is able to obtain local access to services and data resident on that host, the local interaction with the host is more ecient and more secure than by going over an open network. The Seal calculus gives us the means to express these mobile programs directly and also to describe the services oered at each site. But our main goal is to provide, in the calculus itself, protection mechanisms to implement exible security policies. Security is undoubtedly the key to the acceptance of a paradigm that advocates unfettered mobility of running programs over an open network of the scale of the Internet. The security threats are obvious. Both agents and hosts may have been engineered to try to breach the security of distributed systems. Security thus implies defensive programming to prevent two categories of attacks:

The Seal calculus is a calculus of mobile computations designed for programming secure distributed applications over large scale open networks. The calculus is a distributed variant of the -calculus that incorporates agent mobility as well as strong protection mechanisms. Linear, revocable, capabilities control access to resources and ensure that agents may only use resources that have been allocated to them. Capabilities are also used to protect agents from the hosts on which they execute. The syntax and semantics of the Seal calculus are presented and its expressive power is demonstrated with an example secure mobile application.

1 Introduction

Advances in computer communications and computer hardware are changing the landscape of computing. Networking is now cheap and pervasive. We are be-  Agent ! Host attacks : one or more mobile ginning to view the Internet as a platform on which agents mount a concerted eort to breach the large scale distributed programs may be deployed and privacy or the integrity of their host or of other run. This paper reports on research in the design agents running on the host. of the next generation of computer languages: languages to program the Internet.  Host ! Agent attacks : a host attempts to We propose a model of distributed programming breach the privacy or the integrity of an agent based on mobile computations [1] and study this that is running on it. model within the framework of a calculus, which we christen the SEAL calculus. Mobile computations, Both attacks are equally serious, while it is clear that which we call seals, are agents capable of moving resources of the host must be protected from roamacross the network from host to host without inter- ing programs, the converse is true as well, the private 1

data of an agent must preserved as it might, for example, contain information about its human owner (a shopping agent is likely to contain user buying preferences). Speci c security policies are not enforced directly by the Seal calculus. The calculus is policyless, but it provides protection mechanisms to implement policies. The design focuses on resources, our goal was to control resource access and usage. For this reason the Seal calculus incorporates a strong resource access control based on linear revocable capabilities called portals. The semantics of the calculus guarantees that all mobile computations are subject to access control, thus agents may only use resources to which they have been given access. Access control is ne grained. It is possible, for instance, to allow a particular agent to use a given resource only once. It is also possible to revoke capabilities. Denial of service attacks (CPU and memory for example) is the subject of undergoing research. The Seal calculus enforces a hierarchical protection model. A host controls all external resources used by its resident agents. Agents may move (enter or leave) a host only with the hosts explicit permission. Communication between agents and other agents located on the same host, or on dierent hosts, is also under the host's control. Thus a host may choose to isolate an agent: the semantics guarantees that an isolated agent may not communicate with the outside. On the other hand, agents can protect themselves from their host by controlling visibility and access to their own resources. The Seal calculus is based on the -calculus of Milner, Parrow and Walker [4] since it provides an elegant treatment of concurrent computation and a wealth of theory. Our contribution lies in the extensions for distribution, mobility and security. Locations (administrative as well as geographical) are represented by the seal abstraction.1 Agents|mobile computations|are also represented as seals. An example seal con guration is shown in Fig. 1. The outermost seal, labeled ip1 , is referred to as the root seal, it represents a host running a process, P ,

ip1

P sandbox agent

unrestricted

Q

Figure 1: A seal con guration. and two subseals, sandbox and unrestricted. Process P is a rewall that checks credentials of incoming agents allowing only trusted seals to execute within unrestricted. The process within sandbox provides only restricted services to the visiting seal agent (e.g. no network communication and no access to graphical devices). Reasoning about security properties of mobile computations is one of the major design requirements of our calculus. We designed it so that security code could be localized in small protocols and these protocols be proved independently of the context. Thus consider Fig. 2, sandbox is running a (small) security protocol S and some (large) process P . If the protocol grants entrance to a mobile seal agent running a process Q (in our notation agent [Q]), then the security properties of the protocol should be analyzed without having to make assumptions about the behavior of P and Q. agent

Q

sandbox

S

P

Figure 2: Security protocol S .

1 Seals are related to the Ambients of Cardelli and Gordon [1] and the mobile agents of [2], a detailed comparison is outside of the scope of the present paper.

2

2 Seal calculus

 An empty seal process, x [], is an abbreviation for x [0], the inert seal.  When communication is used purely to synchro-

The Seal calculus is a distributed variant of the calculus extended with mobile locations and resource access control. This section presents the syntax of the calculus, explains informally the intent of the constructions and presents the semantics.

nize processes, the argument is inconsequential and we abbreviate x hy i (output of a |in this case useless| argument y on channel x) to xhi and input x hu i to xhi.  Sequences of restrictions, (n)(m) : : : , are abbreviated to (n m : : : ).

2.1 Syntax

We start by de ning the syntax of the calculus. We assume a countable set N of names ranged over by meta-variables x; y; z; : : : ; N is the set of co-names x; z; z : : : ; N and N are disjoint and are in bijection via (); we declare x = x. The set N is extended with a distinguished name " 62 N . We use x to denote either x or x and s to denote either x or ". The set Act of action pre xes, ranged over by , is de ned by the grammar

 To avoid writing too many parentheses, we let actions bind tighter than j and j bind tighter than  , so that (n)nhimhi j nhi means (n)((nhimhi) j nhi)  [x:=y] is our meta notation for the substitution

of y for x. That is, P [x:=y] denotes the term P where y is substituted for every (free) occurence of x.

 ::= xhy i

x s x @y1 : : : yn x @y

2.3 Informal explanation

The terms of the calculus are processes. We describe the constructions informally paying particular attenThe set T of terms, ranged over by P; Q; R; S , is tion to the new constructs. de ned by the grammar -calculus core (x)P restricts the scope of the name x and its coP ::= (x)P restriction name x to process P . P j Q denotes the parallel P j Q composition composition of processes P and Q. !P denotes repli!P replication cation of process P , that is parallel execution of an 0 inactivity unlimited number of copies of P . 0 denotes the inx [P ] seal active process. :P denotes an action pre x followed :P action by process P . The pre x actions are the following. s():P located action x hy i is an input action on channel x binding y. Conx hy i is an output action on channel x of name We will see that the term s(x  s ) will be considered yversely, . As customary, in both cases we call x the subject as meaningless (see Footnote 2). and y the object. The polarity of a subject is positive for input and negative for output. Names are used 2.2 Notation for input and co-names for output. Communication between processes is synchronous, We describe notation used throughout the paper. i.e. in the term x hy i:P j x hz i:Q both process P and  We abbreviate (possibly empty) sequences of Q are frozen until synchronization takes place, which cause the term to reduce to P j Q[z:=y]. identi ers x1 : : : xn to x~ . 3

Seals

P

Seals are the main new abstraction of the calculus. A seal, x [P ], is an agent with a name x, and a body process P . The seal's body is kept separate from all other processes executing in parallel with the seal. This separation is meaningful for synchronization as the process P has local channels and, unless explicitly speci ed, synchronization within P uses P 's private channels. The syntax allows seal nesting. In general a seal con guration is a tree with a single (implicit) root seal. Thus, with exception of the root, every seal is executing within the body of another seal; we call this enclosing seal the parent and denote it by the symbol ". Seal names are external handles, chosen and used by the parent to recognize and interact with its (sub)seals. Names of subseals need not be unique and need not be preserved by mobility. A seal does not necessarily know its name. Seal boundaries are the main protection mechanism provided by the calculus; they can not be dissolved thus guaranteeing that the body process may never mix freely with the environment (unlike [1]). A seal con guration with seal y nested within seal x that runs a process Q is written x [ y [P ] j Q] As an example of the protection boundaries around seals we show a term which does not reduce x [ yhi:P ] j yhi:Q Here process yhi:P waits on a channel y located within seal x, while process yhi:Q waits on a dierent channel also named y but located in x's parent. Fresh names bound by restrictions do not \belong" to a particular seal; during a computation the scope of restrictions may be extend outside of their seal of origin. Thus the following terms are equivalent x [( y)P ]  ( y)x [P ] provided that x 6= y.

c

P c

x

P

x c

Q

Q

Q

(a)

(b)

(c)

Figure 3: Three avors of synchronization between processes P and Q along channel c: (a) local synchronization, (b) external synchronization, (c) internal synchronization.

portal grants one particular seal the right to use a given portal (with a given polarity) only once. A portal action written x  s :P speci es x, the name and polarity of a channel, and s, a seal name. Its meaning is to allow seal s to perform one action interaction at x and to continue as P . Portals are symmetrical, they protect a seal from its subseal as well as a (sub)seal from its parent. We say that there are three kinds of synchronization in the calculus depending on where the channel used for the communication is located. Local synchronization occurs between two processes in the same seal using a local channel. External synchronization takes place when a seal synchronizes on a channel located in its parent (the parent opens a portal) and internal synchronization occurs when a seal opens a portal for a process in the parent (synchronization uses a local channel). These three modes of synchronization are graphically depicted in Fig. 3. Only two of the modes require portals (represented in the gure by black boxes): internal and external syncronization. There are four cases of portals: (1) an external positive portal action, x  y , allows subseal y to perform a Portals positive action along channel x, (2) an external negPortals are linear capabilities used to control access ative portal action, x  y , allows y to perform a negto resources. They are linear in the sense that a ative action along x, (3) an internal positive action, 4

x  ", allows the parent to perform a positive action along x, and (4) an internal negative portal action, x  ", allows the parent to perform a negative action along x. Choosing synchronous portal actions permits to write

xhi

parent, z [ " (x hy i):P ] j x hu i:R j x  z :S

reduces to z [P ] j R[u:=y] j S ; (3) internal input: z allows its parent to input along a channel x located in z, z [x hu i:P j x ":S ] j z(x hy i):R reduces to z [P [u:=y] j S ] j R; (4) internal output: z allows its parent to output along x located in z, z [x hy i:P j x ":S ] j z(x hu i):R reduces to z [P j S ] j R[u:=y]. Seal communication is restricted to a single level in the hierarchy: a seal may only communicate with its parent or a direct child. An alternative would be to allow any two seals to communicate independently of their respective locations ([3, 2]). This restriction is motivated by security and implementation concerns. From the viewpoint of security, the restriction ensures that siblings may not communicate without the accord of their parent. This is sensible as, for example, control over a process' communication abilities is a key security policy of Java implementations. For the implementer's viewpoint, unrestricted communication and mobility force the underlying architecture to keep track of respective location of communicants. The feasibility of an Internet wide tracking system is dubious. Furthermore, unrestricted atomic communication is dicult to implement (this would be a reason for adopting asynchronous communication, but with the restriction on communication, synchrony is easier to achieve).

j x  y :P j y [P 0] j x  z :Q j z [Q0 ]

where both seal y and seal z are allowed to synchronize on channel x. If y synchronizes then its portal is consumed and P executed; if z synchronizes then it is Q that is unfrozen by the consumption of the portal. An asynchronous discipline would not allow us to know which seal performed the communication; standard encoding of synchronous communication into asynchronous communication require cooperation from the seals involved. This can not be taken for granted as a malicious seal could easily break the encoding.

Seal communication

Communication across seal boundaries is explicit; actions that involve a channel located in another seal are called located actions. The term

s():P

denotes an action  to be performed within some seal s and followed by a continuation P to be performed in the current seal.2 The seal s is either a subseal of the current seal, or the parent ("). In the case there is no seal of the requested name, the action blocks. Communication across seal boundaries requires a matching portal action on the other side. There are four cases of inter-seal communication: (1) external input: a seal z inputs a value along a channel x lo- Mobility cated in the parent, Entire running seals may move atomically. When a z [ " (x hu i):P ] j x hy i:R j x  z :S seal moves it ceases to exist in its source environment and appears in its new environment unchanged. A reduces to z [P [u:=y]] j R j S ; seal need not be aware it has been moved: thanks to (2) external output: z outputs along x located in its the use of " the seal is dynamically bound to the new 2 We disregard located actions where  is a portal pre x (no environment. A move is initiated by a send action semantics is given) since they would allow a seal to control the ressources of a dierent seal. x @y :P 5

which means send along channel x a subseal named y to receive a seal (and name it w) along x located in and continue with P . If y does not exist, the process z, blocks. In parallel, a process must be ready to receive z [ y [R] j x @y :P j x  ":S ] j z(x @w ):Q the mobile seal; a (simpli ed) receive action is written reduces to z [P j S ] j w [R] j Q; x @z :P (3) external receive: z is willing to receive a seal (and which means receive a (nameless) seal along channel name it w) along x located in the parent, the parent x, name it z and continue with P . Note that the has a portal open for a positive action on x by z and name of the seal is chosen by the receiver process is ready to send y along x, and need not be the one under which the seal was z [ " (x @w ):P ] j x @y :Q j x  z :R j y [S ] sent. The full form of the receive action allows to specify a sequence of names reduces to z [P j w [S ]] j Q j R; (4) internal receive: z is willing to receive a seal (and x @~z :P name it w) along x and has a portal open for a negative action along x by the parent, the parent is willing where ~z = z1 : : : zn . The action creates n copies of the to send y on x in z, seal named z1 ; : : : ; Zn (names need not be disjoint). Mobility is similar to communication in that it uses z [ x @w :P j x  ":R ] j z(x @y ):Q j y [S ] channels, requires portals and is restricted to moving one level up or down in the hierarchy. It is not pos- reduces to z [P j w [S ] j R] j Q. sible to move a parent into a child nor a seal into itself. Note that mobility is not under the control of 2.4 Semantics the seal, but rather its parent. The parent initiates The semantics of the Seal calculus is given in terms moves and controls the location of its subseals. A move is local when both sender and receiver pro- of a labeled transition system. Labels correspond to actions and a distinguished label  corresponds to the cesses are located in the same seal, e.g. the term silent action i.e. synchronization. The set L of action labels, ranged over by l, is x [P ] j y @x :Q j y @z :R will send seal x along channel y and receive it under  ::=  the name z, the term reduces to z [P ] j Q j R. xhy i Non local moves involve processes located in difx @P ferent seals and require portals. There are four cases x @ y of inter-seal mobility: (1) external send: a seal z is willing to send subseal y up into the parent along l ::=  channel x located in the parent, while the parent has s() a portal open for z to perform a negative action on x and is ready to receive a seal (and name it w) along Note that the label for a receive action does not inx, clude the name under which the seal will be received rather, it includes the body P that will be received. z [ y [R] j " (x @y ):P ] j x @w :Q j x  z :S Restriction and input pre x are binding operators, reduces to z [P ] j w [R] j Q j S ; thus (x)P binds x in P and x hy i:P binds y in P . (2) internal send: z is willing to send y along its own Free names fn (P ) and bound names bn (P ) of a prochannel x and has a portal open for the parent to cess P have standard de nitions. We say that a properform a positive action along x, the parent is ready cess P is closed if and only if fn (P ) = ;. 6

We de ne structural congruence, , to be the 3.1 Renaming smallest congruence relation over T such that the fol- The renaming of a seal is a frequent and general oplowing laws hold: eration. Therefore we de ne a new operator x be y, 1. Terms are identi ed if they only dier in a which atomically renames seal x to y as follows: change of bound names, x be y:P = (n) n @x j n @y :P 2. (T =  ; j ; 0) is a symmetric monoid, We use small capitals to denote de ned operator, which for simplicity may be in x and composed of 3. !P  P j !P , several keywords. Renaming is implemented by a local move. The action n @x moves seal x along channel 4. (x)(y)P  (y)(x)P , n. n @y receives a seal and names it y. In order to avoid interferences, the temporary name n is used for 5. (x)(P j Q)  P j (x)Q if x 62 fn (P ), the local channel. (Contrast this to renaming in the ambient calculus [1] in which a seal renames itself). 6. (x)0  0, 7. x [(y)P ]  (y)x [P ] if y 6= x.

3.2 Linking

The operational semantics of the calculus is pre- Another interesting operator is the one that performs sented in terms of the labeled transition system a single communication between two (sub)seals: l LTS (T ; L; fP ?! Q j P; Q 2 T ; l 2 Lg). The action link(n; m) via c :P = n(c hx i) j m(c hx i):P l relation P ?! Q is the smallest relation that obeys It simply reads x on channel c from seal n and transthe axiom and rule schemas in Fig. 4. mits it on the same channel to m.

3 Example

3.3 Network

Our network is composed n machines running in parallel, each machine being characterized by an IP number and the process that runs on it: mach(ip1 ; P1 ) j : : : j mach(ipn ; Pn ) More precisely, mach is the description of three things: the actual machine (a seal whose name is the machine's IP number); the protocol that allows the machine to send out packets; the portion of the network transport layer that takes care of routing a packet to a given machine and port. mach(ip; P ) = !( pkt ) ip(out @pkt ) :pkt (hdr hipdest ; port i) :ipdest (port @pkt )

We show by the means of an example the use of our calculus and the properties it yields. Imagine that we have a set of machines denoted by an IP number that execute some application with a temporary license. A license extension is obtained by communicating to the application a license password that encodes the expiration date. A common way to avoid license duplication is to generate a password that uses some system information (e.g., the machine serial number) as a key. This can be obtained by manually executing an upgrade program on every machine at issue or more cleverly by programming the upgrade program as a mobile agent that visits each machine to be upgraded (for the sake of the example we suppose that machines must be upgraded in a given order; but nothing prevents us from creating an upgrade agent for each machine and letting them run in parallel). We start with the de nition of two useful operations, renaming and linking.

j ip [ !out @leave j !out  " j P ] 7

Structure [Par]

[Res] l P ?! Q x 62 fn (l) l (x)P ?! (x)Q

l P ?! P0 bn (l) \ fn (Q) = ; l P j Q ?! P 0 j Q

[Struct]

[Seal]

[L-Act]

P  P 0 P ?! Q Q  Q0 l P 0 ?! Q0

 P ?! P0  x [P ] ?! x [P 0]

 :P ?! P0 s() 0 s():P ?! P

l

Communication [Out]

[In]

[Com-Loc]

x hyi x hy i:P ?! P

x hyi x hz i:P ?! P [z:=y]

x hyi 0 x hyi 0 P ?! P  Q ?! Q P j Q ?! P 0 j Q0

[Com-Ext]

xhyi) 0 xhyi 0 Q P ?! P Q "(?! P j z [Q] j x  z :S ?! P 0 j z [Q0] j S

[Com-Int]

xhyi) 0 xhyi 0 Q P ?! P Q z(?! z [P j x ":S ] j Q ?! z [P 0 j S ] j Q0

Mobility [Sen]

x @y P x @y :P ?!

[Rec]

@Q x @y1 : : : yn :P x?! P j y1 [Q] j : : : j yn [Q]

[Mov-Loc]

x @y 0 @R Q0 P ?! P Q x?! P j Q j y [R] ?! P 0 j Q0

[Sen-Ext]

[Rec-Ext]

x @y ) 0 @R Q0 P Q x?! P "(?!  z [P j y [R]] j Q j x  z :S ?! z [P 0] j Q0 j S

x @R) 0 x @y 0 P ?! P Q "(?! Q  P j z [Q] j x  z :S j y [R] ?! P 0 j S j z [Q0 ]

[Sen-Int]

[Rec-Int]

x @y ) 0 @R Q0 P z(?! P Q x?! P j z [Q j x ":S ] j y [R] ?! P 0 j z [Q0 j S ]

x @R) 0 x @y 0 P ?! P Q z(?! Q  z [P j x ":S j y [R]] j Q ?! z [P 0 j S ] j Q0

Figure 4: Axioms and rules schemas of the Seal calculus. 8

3.5 Upgrade protocol

The network waits for the machine ip to send a new packet on channel out , it generates a new name for it, asks it its destination machine and port and routes it there. Besides running P , the machine moves out every packet whose name is leave .

The only protocol we describe is the upgrade protocol that listens on the upgrade port for programs that upgrade the licence password. This protocol must be run (possibly inside a replication) by every machine that wants to allow licence upgrades. For the sake of simplicity we do not handle the cases in which the upgrade fails. The de nition of the protocol is: upgrade protocol.P = upgrade  "j ( upg pkt ) upgrade @pkt .unpack pkt as upg .upg (request happ ; chn i) .check(app ; chn ) .upg (sysinfo hvv i) .link (upg, app ) via chn .upg (next hip i) .pack(upg ; ip ; upgrade ) as leave .P Let us describe it in detail. The protocol waits on the port upgrade for a packet that contains an upgrade application. The protocol extracts the upgrader application from the packet and names it with the fresh name upg . It then waits for upg to request a communication with a seal app (the application to upgrade) on channel chn . After having performed some security checks (not de ned), the protocol sends to upg some system informations, such as the machine serial number vv (used to generate the new license) and allows a single communication from upg to app to take place. Finally the protocol asks upg its next destination and sends it out within a new packet.

3.4 Packets We do not give a general description of how incoming packets are handled by machines, since this would be too speci c. In general every process P on a machine will run a suite of protocols that listen to given ports and accordingly perform some operations. However, it possible to de ne two general operators that machines will use to handle packets. These operators named pack and unpack are de ned as follows: pack(n; ip; port ) as p :P = ( t) t [ in @k :hdr hip ; port i :out @k j in  ":hdr  ":out  " ]

j t(in @n ) :t be p:P

unpack(p) as q :P =

(x) p be x :x(out @q ):P A packet is characterized by a seal n that represents the encapsulated information, and the IP number and port of destination that it publishes on its header port hdr . The seal n is encapsulated in and extracted from the packet through channels in and out respectively. The action pack(n; ip; port ) as p creates a packet named p encapsulating the seal n and with destination ip and port . Creation uses a temporary seal t to avoid external interferences during construction. The action unpack(p) as q extracts the seal encapsulated in packet p and names it q; the renaming is performed so that after the extraction p has become (x)x [], which is equivalent to the inactive process.

3.6 Mobile upgrader application

The upgrader application sequentially upgrades the application apl in the various machines: upgrader [upgrade(ip1 ):upgrade(ip2 ): : : : ]

The steps performed to upgrade a single machine ip are: upgrade(ip ):P = next hip i 9

.request hapl ; chn i .sysinfo hvv i .chn hnew license(vv)i j request  ":sysinfo  ":chn  ":P First the upgrader broadcasts the ip it wants to visit. Then it requests a communication channel chn to the application apl . This action is performed only after that the upgrader has arrived at its destination. It also expects to receive some system information, before communicating the new licence password (its computation not described here) to apl via chn . An upgrader that upgrades machines in a random order is obtained as follows: upgrader [upgrade(ip1) j upgrade(ip2) j : : : ]

When portals are viewed as capabilities, the trap operator is a non reversible form of revocation while renaming is a reversible revocation. One of the most important security properties of a protocol is \non interference". We want to guarantee, just by examination of the upgrade protocol, that the mobile upgrader can only interact with the application app that it requested explicitly upon arrival. More precisely, if we isolate the seal apl (representing the application to be upgraded) from the rest of the processes running on the machine and we let it interact only with the upgrading protocol then the upgrading application will not be able to interfere with any other process on the machine. Formally, let end 62 fn (P ). Then ip [( apl)(apl [Q] j upgd prot:end []) j P ]  ?! ip [end [] j P 0]

3.7 Security issues

When we developed our calculus we concentrated on security issues. Indeed we wanted a calculus that would allow context independent proofs of security, that is, our goal was to be able to localize security code in small, well delineated, portions of a system and be able to reason about security properties without having to resort to whole program analysis. The rst property that we wanted to obtain is what is called the perfect rewall equation in [1]: this says that an arbitrary process can be completely prevented from any communication and is formally written (x) x [P ] ' 0 where ' is some action-based observational equivalence. This property holds in the Seal calculus because if a seal is given a fresh name which is unknown to any other process, then there can be no portal open for that name (y  x ), nor can there be located communication (x(yhz i)). This property is useful as it guarantees that once a seal in a rewall it can not divulge any information (nor perform any externally visible action). One advantage of our calculus over ambients is that it is possible to force a seal into a rewall, the following operation will eventually trap a seal x trap x = ( c t) c @x j c @t

implies that

 P ?! P0 This is a very informative property since it tells us that the upgrade aects only the apl application that it is supposed to upgrade. Note that in the version of ip the only thing we did is to isolate apl from the rest of the machine. The protocol is unchanged since the  apl does not isolate upgrade protocol from the rest of the machine (but we must suppose that there is no other seal named apl in P ). However, this property does not have the characteristic we were looking for since it is context dependent: we must know the name apl of the application that will be upgraded. On the contrary we want to be able to check our protocol for any application. That is, we want to isolate an application based on the name received on the request channel. We will consider a modi ed version of the upgrade protocol that creates a copy of the application the upgrader wants to communicate with and isolates it from the rest of the machine. First we de ne a cloning action: clone x as y = ( c) c @x j c @x ; y Then we de ne the test for the protocol as follows (we mark by (*) the added/modi ed lines):

10

test upgd prot.P = upgrade  "j

used to surreptitiously carry away some (partner) seal3 .

!( upg pkt )upgrade @pkt .unpack pkt as upg The security properties we have studied in this sec.upg (request happ ; chn i) tion relate to protection of the host from the action of .check(app ; chn ) mobile computations, to present a comprehensive so.upg (sysinfo hvv i) lution we should also devise a protocol that provides .( x) clone app as x (*) some guarantees to mobile computations. Although .link (upg, x ) via chn (*) the host may not modify the internal behavior of the .upg (next hip i) upgrader, a malicious host may (1) lie about its se.pack(upg ; ip ; upgrade ) as leave .P rial number, (2) learn the itinerary of an upgrader, (3) trap an upgrader, (4) impersonate an upgrader, Let end be a name such that end 62 fn (P ) then: (5) listen in on the conversation between an upgrader and the upgraded application.  ip [end [] j P 0] ip [test upgd prot:end [] j P ] ?!

implies

 P ?! P0 There are several points to note. First, contrary to the previous one, this test works also in the case that there are several seals named apl . Indeed the clone action picks up one of them at random, exactly in the same way the upgrader would. Second, this property assures that every mobile computation entering by the port upgrade (and terminating the test protocol) can aect only the application for which it requested the authorization on the request channel (of course provided that this protocol is the only one that handle the upgrade port, e.g., upgrade 62 fn (P ).) This second result can be declined in several consequences: 1. Bound communication: The entering seal cannot communicate with anyone but with the seal requested on the channel request . If this were not the case then it would be easy to build a process P for which the implication above does not hold. Note that this is true even in the case that two seals agreed on some communication protocol and entered independently the machine: only the hosting machine can allow them to communicate. 2. No hitchhiking: Unwanted seals cannot use a seal entering by the upgrade port as a Trojan horse to sneak into the machine, nor once the upgrading seal entered the machine can it be

4 Conclusion We have presented the Seal calculus, a calculus of mobile computations. This calculus is well suited for modeling Internet applications as the key elements of such applications (i.e. parallelism, locations, mobility, protection domains) are represented straightforwardly. We are currently investigating the use of the calculus for representing security policies. One particular area of research is that of denial of service. For this, we plan to extend the notion of resources to memory and cpu time.

Acknowledgments Our work bene ted greatly from multiple discussion with Luca Cardelli, we are grateful for his insightful advice. We also wish to thanks Laurent Dami, Ciaran Bryce and Walter Binder of the OSG for reading previous drafts of this paper and discussing the ideas developed here. 3 Hitchhiking is allowed in the Ambient calculus [1]. In the train example ambients representing passengers enter train stations, and then board trains. In the untyped calculus, there is no way of limiting the number of passengers that board a train and nothing prevents a passenger from hiding a potentially in nite number of hitchhikers that will come out as soon as the passenger is on the train.

11

References [1] L. Cardelli and A. D. Gordon. Mobile ambients. In M. Nivat, editor, Foundations of Software Science and Computational Structures, number 1378 in LNCE, pages 140|155. Springer-Verlag, 1998. [2] C. Fournet, G. Gonthier, J.-J. Levy, L. Maranget, and D. Remy. A calculus of mobile agents. In CONCUR96, pages 406{421, 1996. [3] M. Henessy and J. Riely. Resource access control in systems of mobile agents. Computer Science Technical Report 2/98, University of Sussex, 1998. [4] R. Milner. The polyadic -calculus: a tutorial. Technical Report ECS-LFCS-91-180, Laboratory for Foundations of Computer Science, Department of Computer Science, University of Edinburgh, UK, Oct. 1991. Also in Logic and Algebra of Speci cation, ed. F. L. Bauer, W. Brauer and H. Schwichtenberg, Springer-Verlag, 1993.

12