Towards a Calculus of Secure Mobile Computations - CiteSeerX

Towards a Calculus of Secure Mobile Computations Jan Vitek Giuseppe Castagna

Abstract The S EAL 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 S EAL calculus are presented and its expressive power is demonstrated with an example secure mobile

1

Introduction

Advances in computer communications and computer hardware are changing the landscape of computing. Networking is now cheap and pervasive. We are beginning to view the Internet as a platform on which large scale distributed programs may be deployed and run. This paper reports on research in the design of the next generation of computer languages: languages to program the Internet. We propose a model of distributed programming based on mobile computations [1] and study this model within the framework of a calculus, which we christen the SEAL calculus. Mobile computations, which we call seals, are agents capable of moving across the network from host to host without interruption of the logical flow of their execution. The purpose of this form of mobility is to offer a finer 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 efficient 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 offered at each site. But our main goal is to provide, in the calculus itself, protection mechanisms to implement flexible 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:



Agent ! Host attacks: one or more mobile agents mount a concerted effort to breach the privacy or the integrity of their host or of other agents running on the host.

 Presented at

the Workshop of Internet Programming Languages (WIPL), Chicago, IL, USA, May, 1998.

31

32

Calculus of Secure Mobile Computations



Host ! Agent attacks: a host attempts to breach the privacy or the integrity of an agent that is running on it.

Both attacks are equally serious, while it is clear that resources of the host must be protected from roaming programs, the converse is true as well, the private 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). Specific security policies are not enforced directly by the S EAL 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 fine 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 different 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 configuration 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 , and two subseals, sandbox and unrestricted. Process P is a firewall 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. 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.

J. Vitek and G. Castagna

33 ip1

P sandbox agent

unrestricted

Q

Figure 1 A seal configuration. sandbox

agent

S

Q

P

Figure 2 Security protocol S .

2

Seal calculus

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.

2.1 Syntax We start by defining the syntax of the calculus. We assume a countable set N of names ranged over by meta-variables x; y; z; : : : ; N is the  = x. set of co-names x; z; z : : : ; N and N are disjoint and are in bijection via (); we declare 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 prefixes, ranged over by , is defined by the grammar



::=

xhy i x s

x @y1 : : : yn x @y

34

Calculus of Secure Mobile Computations The set T of terms, ranged over by P; Q; R; S , is defined by the grammar

P

::= (x)P

restriction composition replication inactivity seal action located action

P jQ !P 0

x [P ] :P s():P

We will see that the term s(x  s ) will be considered as meaningless (see Footnote 2).

2.2 Notation We describe notation used throughout the paper.

    

We abbreviate (possibly empty) sequences of identifiers x1 : : :xn to x ~. An empty seal process, x [], is an abbreviation for x [0], the inert seal. When communication is used purely to synchronize 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 : : : ).

j

To avoid writing too many parentheses, we let actions bind tighter than tighter than  , so that (n)nhimhi j nhi means (n)((nhimhi) j nhi)

and

j

bind

 [x:=y] is our meta notation for the substitution of y for x. term P

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

2.3 Informal explanation The terms of the calculus are processes. We describe the constructions informally paying particular attention to the new constructs.

-calculus core

j

(x)P restricts the scope of the name x and its co-name x  to process P . P Q denotes the parallel composition of processes P and Q. !P denotes replication of process P , that is parallel execution of an unlimited number of copies of P . 0 denotes the inactive process. :P denotes an action prefix followed by process P . The prefix actions are the following. x y is an input action on channel x binding y . Conversely, x y is an output action on channel x of name y .

hi

hi

J. Vitek and G. Castagna

35

As customary, in both cases we call x the subject and y the object. The polarity of a subject is positive for input and negative for output. Names are used for input and co-names for output.

Communication between processes is synchronous, i.e. in the term x hy i:P j x hz i:Q both process P and Q are frozen until synchronization takes place, which cause the term to reduce to P j Q[z :=y ]. Seals 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 specified, synchronization within P uses P ’s private channels. The syntax allows seal nesting. In general a seal configuration 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 configuration 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 y hi:P waits on a channel y located within seal x, while process yhi:Q waits on a different 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 . Portals Portals are linear capabilities used to control access to resources. They are linear in the sense that a 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

36

Calculus of Secure Mobile Computations

P c

P c

x

P

x c

Q

Q

Q

(a)

(b)

(c)

Figure 3 Three flavors of synchronization between processes P and Q along channel c: (a) local synchronization, (b) external synchronization, (c) internal synchronization. specifies 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 figure 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 positive action along channel x, (2) an external negative portal action, x  y , allows y to perform a negative action along x, (3) an internal positive action, 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

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.

J. Vitek and G. Castagna

37

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 located in the parent,

z [ " (x hu i):P ] j x hy i:R j x  z :S reduces to z [P [u:=y ]] j R j S ; (2) external output: z outputs along x located in its parent,

z [ " (x hy i):P ] j x hu i:R j x  z :S reduces to z [P ] j (3) internal input:

R[u:=y] j S ; 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 difficult to implement (this would be a reason for adopting asynchronous communication, but with the restriction on communication, synchrony is easier to achieve). We disregard located actions where  is a portal prefix (no semantics is given) since they would allow a seal to control the ressources of a different seal. 2

38

Calculus of Secure Mobile Computations

Mobility Entire running seals may move atomically. When a seal moves it ceases to exist in its source environment and appears in its new environment unchanged. A seal need not be aware it has been moved: thanks to the use of " the seal is dynamically bound to the new environment. A move is initiated by a send action x @y :P which means send along channel x a subseal named y and continue with P . If y does not exist, the process blocks. In parallel, a process must be ready to receive the mobile seal; a (simplified) receive action is written x @z :P

which means receive a (nameless) seal along channel x, name it z and continue with P . Note that the name of the seal is chosen by the receiver process and need not be the one under which the seal was sent. The full form of the receive action allows to specify a sequence of names

x @~z :P where z~ = z1 : : :zn . The action creates n copies of the seal named z1; : : :; Zn (names need not be disjoint). Mobility is similar to communication in that it uses channels, requires portals and is restricted to moving one level up or down in the hierarchy. It is not possible to move a parent into a child nor a seal into itself. Note that mobility is not under the control of the seal, but rather its parent. The parent initiates moves and controls the location of its subseals. A move is local when both sender and receiver processes are located in the same seal, e.g. the term 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.

Non local moves involve processes located in different seals and require portals. There are four cases of inter-seal mobility: (1) external send: a seal z is willing to send subseal y up into the parent along channel x located in the parent, while the parent has a portal open for z to perform a negative action on x and is ready to receive a seal (and name it w) along x,

z [ y [R] j " (x @y ):P ] j x @w :Q j x  z :S reduces to z [P ] j w [R] j Q j S ; (2) internal send: z is willing to send y along its own channel x and has a portal open for the parent to perform a positive action along x, the parent is ready to receive a seal (and name it w) along x located in z , z [ y [R] j x @y :P j x  ":S ] j z(x @w ):Q reduces to z [P j S ] j w [R] j Q; (3) external receive: z is willing to receive a seal (and name it w) along x located in the parent, the parent has a portal open for a positive action on x by z and is ready to send y along x, z [ " (x @w ):P ] j x @y :Q j x  z :R j y [S ]

J. Vitek and G. Castagna

39

reduces to z [P j w [S ]] j Q j R; (4) internal receive: z is willing to receive a seal (and name it w) along x and has a portal open for a negative action along x by the parent, the parent is willing to send y on x in z ,

z [ x @w :P j x  ":R ] reduces to z [P j w [S ] j R] j Q.

j z(x @y ):Q j y [S ]

2.4 Semantics The semantics of the SEAL calculus is given in terms of a labeled transition system. Labels correspond to actions and a distinguished label  corresponds to the silent action i.e. synchronization. The set L of action labels, ranged over by l, is



l

::=

::=



xhy i

x @P x @y  s()

Note that the label for a receive action does not include the name under which the seal will be received rather, it includes the body P that will be received.

Restriction and input prefix are binding operators, thus (x)P binds x in P and x hy i:P binds y in P . Free names fn (P ) and bound names bn (P ) of a process P have standard definitions. We say that a process P is closed if and only if fn (P ) = ;. We define structural congruence, that the following laws hold:

, to be the smallest congruence relation over T

such

1. Terms are identified if they only differ in a change of bound names, 2. (T = 3. 4. 5. 6. 7.

 ; j ; 0) is a symmetric monoid, !P  P j !P , (x)(y )P  (y )(x)P , (x)(P j Q)  P j (x)Q if x 62 fn (P ), (x)0  0, x [(y)P ]  (y)x [P ] if y = 6 x.

The operational semantics of the calculus is presented in terms of the labeled transition l l system LTS (T ; L; fP ! Q j P; Q 2 T ; l 2 Lg). The action relation P ! Q is the smallest relation that obeys the axiom and rule schemas in Fig. 4.

40

Calculus of Secure Mobile Computations

Structure [PAR]

[RES]

l P ! Q x 62 fn (l) l (x)P ! (x)Q

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

[S TRUCT]

[SEAL]

[L-ACT]

l P  P0 P ! Q Q  Q0 l P0 ! Q0

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

:P ! P 0 ) 0 s():P s(! P

Communication [O UT]

[I N]

[COM-L OC]

!P x hy i:P x hyi

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

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

[C OM-E XT]

[COM-I NT]

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

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

Mobility [S EN]

[REC]

x @y :P x @!y P

x @y1 : : : yn :P x @!Q P j y1 [Q] j : : : j yn [Q] [MOV-L OC]

[S EN-E XT]

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

[REC-E XT]

@y ) 0 P x @!y P 0 Q "(x@!R) Q0 P "(x ! P Q x@!R Q0 z [P j y [R]] j Q j x  z :S ! z [P 0] j Q0 j S P j z [Q] j x  z :S j y [R] ! P 0 j S j z [Q0] [S EN-I NT]

[REC-I NT]

@R) 0 @y ) 0 Q P z(x! P x @!y P 0 Q z(x! P Q x @!R Q0 0 0 P j z [Q j x ":S ] j y [R] ! P j z [Q j S ] 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 S EAL calculus.

J. Vitek and G. Castagna

3

41

Example

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 definition of two useful operations, renaming and linking.

3.1 Renaming The renaming of a seal is a frequent and general operation. Therefore we define a new operator x BE y, which atomically renames seal x to y as follows:

x BE y:P = (n) n @x j n @y :P We use small capitals to denote defined operator, which for simplicity may be infix and composed of several keywords. Renaming is implemented by a local move. The action n @x moves seal x along channel n. n @y receives a seal and names it y . In order to avoid interferences, the temporary name n is used for the local channel. (Contrast this to renaming in the ambient calculus [1] in which a seal renames itself).

3.2 Linking Another interesting operator is the one that performs a single communication between two (sub)seals:

n; m)

LINK(

VIA

c :P = n(c hx i) j m(c hx i):P

It simply reads x on channel c from seal n and transmits it on the same channel to m.

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:

ip1; P1) j : : : j

MACH (

ipn ; Pn)

MACH (

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;

42

Calculus of Secure Mobile Computations

the portion of the network transport layer that takes care of routing a packet to a given machine and port.

ip; P ) = !( pkt ) ip(out @pkt ) :pkt (hdr hipdest ; port i) :ipdest (port @pkt )

MACH (

j ip [ !out @leave j !out  " j P ] 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.

3.4 Packets We do not give a general description of how incoming packets are handled by machines, since this would be too specific. 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 define two general operators that machines will use to handle packets. These operators named PACK and UNPACK are defined as follows:

n; ip; port ) AS p :P = ( t) t [ in @k :hdr hip ; port i :out @k j in  ":hdr  ":out  " ]

PACK (

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.

J. Vitek and G. Castagna

43

3.5 Upgrade protocol 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 definition 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 defined), 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.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 .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.

44

Calculus of Secure Mobile Computations An upgrader that upgrades machines in a random order is obtained as follows:

upgrader [UPGRADE (ip1) j UPGRADE (ip2) j : : : ] 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 first property that we wanted to obtain is what is called the perfect firewall 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 firewall 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 firewall, the following operation will eventually trap a seal x TRAP

x = ( c t) c @x j c @t

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] implies that

P ! P 0

This is a very informative property since it tells us that the upgrade affects 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 ).

J. Vitek and G. Castagna

45

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 modified 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 define a cloning action: CLONE

x AS y = ( c) c @x j c @x ; y

Then we define the test for the protocol as follows (we mark by (*) the added/modified lines):

P

TEST UPGD PROT.

=

upgrade  " j !( upg pkt )upgrade @pkt .UNPACK pkt AS upg .upg (request happ ; chn i) .CHECK(app ; chn ) .upg(sysinfo hvv i) .( x) CLONE app AS x .LINK (upg, x) VIA chn .upg (next hip i) .PACK(upg ; ip ; upgrade )

Let end be a name such that end

(*) (*) AS

leave.P

62 fn (P ) then:

ip [TEST UPGD PROT :end [] j P ] ! ip [end [] j P 0] implies

P ! P 0

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 affect 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.

46

Calculus of Secure Mobile Computations 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 used to surreptitiously carry away some (partner) seal3 .

The security properties we have studied in this section relate to protection of the host from the action of mobile computations, to present a comprehensive solution we should also devise a protocol that provides some guarantees to mobile computations. Although the host may not modify the internal behavior of the upgrader, a malicious host may (1) lie about its serial number, (2) learn the itinerary of an upgrader, (3) trap an upgrader, (4) impersonate an upgrader, (5) listen in on the conversation between an upgrader and the upgraded application.

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 benefited greatly from multiple discussion with Luca Cardelli, we are grateful for his insightful advice. We also wish to thanks Laurent Dami, Ciar´an Bryce and Walter Binder of the OSG for reading previous drafts of this paper and discussing the ideas developed here.

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. L´evy, L. Maranget, and D. R´emy. 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 Specification, ed. F. L. Bauer, W. Brauer and H. Schwichtenberg, Springer-Verlag, 1993.

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 infinite number of hitchhikers that will come out as soon as the passenger is on the train.