6 October 20026 October 2002 11PPDP / GPCE 2002PPDP / GPCE 2002

Mobile CalculiMobile Calculi

Catuscia Palamidessi, INRIA Futurs, Catuscia Palamidessi, INRIA Futurs, FranceFrance

joint work withjoint work withMihaela Herescu, IBM, AustinMihaela Herescu, IBM, Austin

forDistributed Programming

2

Mobile calculi The calculus

[Milner, Parrow, Walker ‘89] CCS + Mobility of links

Dynamic reconfiguration of the communication structure

3

Mobile Calculi

The asynchonous calc [Honda-Tokoro’92, Boudol ’91]

Action Calculi [Milner, early ‘90] The Fusion calculus [Parrow, Victor, early ‘90] Join Calculus [Fournet, Gonthier, Levy, …’96]

…

Related calculi Mobile Ambients [Cardelli, Gordon ‘97] The seal calculus [Castagna, Vitek, mid ‘90] Boxed Ambients [Bugliesi, Castagna, Crafa, late ‘90] The spi calculus [Abadi, Gordon, mid ‘90]

a calculus for specification and verification of security protocols based on the calculus

4

The calculus Basic constructs to expess parallelism,

communication, choice, generation of new names (which can be communicated and in turn used as channels), scope

Scope extrusion: a name can be communicated and its scope extended to include the recipient

x y

z z

z R

Q

P

5

Expressive Power of link mobility

network reconfiguration express HO (e.g. calculus) in a natural way

mixed choice solution to distributed problems involving

distributed agreement

6

The expressive power of Example of distributed agreement:

the leader election problem

A symmetric and fully distributed solution in x.Pwins + y^.Ploses | y.Qwins + x^.Qloses

– Ploses | Qwins

P Q

y

x

– Pwins | Qloses

7

: the calculus (w/ mixed choice)

Syntax

g ::= x(y) | x^y | prefixes (input, output, silent)

P ::= i gi . Pi mixed guarded choice| P | P parallel| (x) P new name| recA P recursion| A procedure name

8

Operational semantics Transition system P -a Q

Rules

Choice i gi . Pi –gi Pi

P -x^y P’Open ___________________ (y) P -x^(y) P’

9

Operational semantics Rules (continued)

P -x(y) P’ Q -x^z Q’ Com ________________________

P | Q - P’ [z/y] | Q’

P -x(y) P’ Q -x^(z) Q’ Close _________________________

P | Q - (z) (P’ [z/y] | Q’)

P -g P’ Par _________________ f(Q) and b(g) disjoint

Q | P -g Q | P

10

Implementation issues

It is well known that formalisms able to express distributed agreement are difficult to implement in a distributed fashion

For this reason, the field has evolved towards asynchronous variants of or other asynchronous formalisms for instance, the asynchronous calculus

[Honda-Tokoro’92, Boudol, ’92]

11

a : the Asynchonous

Syntax

g ::= x(y) | prefixes

P ::= i gi . Pi input guarded choice| x^y output action

| P | P parallel| (x) P new name| recA P recursion| A procedure name

12

Operational semantics of a

Additional rule:

Out x^y –x^y 0

Asynchronous communication: we can’t write a continuation after an output,

i.e. no x^y.P, but only x^y | P so P will proceed without waiting for the actual delivery of

the message

Note: the original a did not contain a choice construct. However the version presented here was shown expressively equivalent to the original a by [Nestmann and Pierce, ’96]

13

vs. a

a is suitable for distributed implementation,in contrast to

However, despite the difficulties regarding implementation, the calculus is still very appealing, because of its superior expressive power

Examples of problems that can be solved in and not in a : dining philosophers ( following [Francez and Rodeh, ’82] ) the symmetric leader election problem , for any ring of processes

The solution uses name mobility to fully connect the graph, and then mixed choice to break the symmetry.

This problem cannot be solved in a , nor in CCS [ Palamidessi 97]

14

Towards a fully distributed implementation of The results of previous pages show that a fully distributed

implementation of must necessarily be randomized A two-steps approach:

probabilistic asynchronous

distributed machine

[[ ]]

<< >>

Advantages: the correctness proof is easier since [[ ]] (which is the difficult part of the implementation) is between two similar languages

15

pa: the Probabilistic Asynchonous

Syntax

g ::= x(y) | prefixes

P ::= i pi gi . Pi pr. inp. guard. choice i pi = 1| x^y output action

| P | P parallel| (x) P new name| recA P recursion| A procedure name

16

1/21/2 1/3

1/31/3

1/32/3

1/21/2 1/3

1/31/3

1/32/3

1/21/2 1/3

1/31/3

1/32/3

The operational semantics of pa

Based on the Probabilistic Automata of Segala and Lynch Distinction between

nondeterministic behavior (choice of the scheduler) and

probabilistic behavior (choice of the process)

Scheduling Policy:The scheduler chooses the group of transitionsExecution:The process chooses probabilistically the transition within the group

17

The operational semantics of pa

Representation of a group of transition

P { --gi-> pi Pi } i

Rules

Choice i pi gi . Pi {--gi-> pi Pi }i

P {--gi-> piPi }i

Par ____________________ Q | P {--gi-> piQ | Pi }i

18

The operational semantics of pa

Rules (continued)

P {--xi(yi)-> piPi }i Q {--x^z-> 1 Q’ }i

Com ____________________________________ P | Q {---> piPi[z/yi] | Q’ }xi=x U { --xi(yi)-> pi Pi | Q }xi=/=x

P {--xi(yi)-> piPi }i

Res ___________________ qi renormalized (x) P { --xi(yi)-> qi (x) Pi }xi =/= x

19

Implementation of pa

Compilation in Java << >> : pa Java

Distributed<< P | Q >> = << P >>.start(); << Q >>.start();

Compositional<< P op Q >> = << P >> jop << Q >> for all op

Channels are one-position buffers with test-and-set (synchronized) methods for input and output

The probabilistic input guarded construct is implemented as a while loop in which channels to be tried are selected according to their probability. The loop repeats until an input is successful

20

Encoding into pa

[[ ]] : pa

Fully distributed [[ P | Q ]] = [[ P ]] | [[ Q ]]

Uniform[[ P ]] = [[ P ]]

Correct wrt a notion of probabilistic testing semantics

P must O iff [[ P ]] must [[ O ]] with prob 1

21

Encoding into pa

Idea: Every mixed choice is translated into a parallel comp. of

processes corresponding to the branches, plus a lock f The input processes compete for acquiring both its own

lock and the lock of the partner The input process which succeeds first, establishes the

communication. The other alternatives are discarded P

Q

RPi

QiRi

f

f

f

The problem is reduced to a generalized dining philosophers problem where each fork (lock) can be adjacent to more than two philosophersFurther, we can reduce the generalized DP to the classic case, and then apply the algorithm of Lehmann and Rabin

SR’i

f Si

22

Dining Philosophers: classic case

Each fork is shared by exactly two philosophers

23

Dining Philosophers, classic case

The requirements on the encoding pa imply symmetry and full distribution

There are many solution to the DP problem, but in order to be symmetric and fully distributed a solution has necessarily to be randomized. Proved by [Lehmann and Rabin 81] - They also provided a randomized algorithm (for the classic case)

Note that the DP problem can be solved in in a fully distributed, symmetric way. Hence the need for randomization is not a characteristic of our approach: it would arise in any encoding of into an asynchronous language.

24

The algorithm of Lehmann and Rabin

1. Think2. choose first_fork in {left,right} %commit3. if taken(first_fork) then goto 34. take(first_fork)5. if taken(first_fork) then goto 26. take(second_fork) 7. eat8. release(second_fork) 9. release(first_fork)10. goto 1

25

Dining Phils: generalized case

Each fork can be shared by more than two philosophers

Reduction to the classic case: each fork is initially associated with a token. Each phil needs to acquire a token in order to participate to the competition. The competing phils determine a set of subgraphs in which each subgraph contains at most one cycle

26

Generalized philosophers Another problem we had to face: the solution of

Lehmann and Rabin works only for fair schedulers, while pa does not provide any guarantee of fairness

Fortunately, it turns out that the fairness is required only in order to avoid a busy-waiting livelock at instruction 3. If we replace busy-waiting with suspension, then the algorithm works for any scheduler This result was achieved independently also by Fribourg et al, TCS 2002

27

1. Think2. choose first_fork in {left,right} %commit3. if taken(first_fork) then wait4. take(first_fork)5. if taken(first_fork) then goto 26. take(second_fork) 7. eat8. release(second_fork) 9. release(first_fork)10. goto 1

1. Think2. choose first_fork in {left,right} %commit3. if taken(first_fork) then goto 34. take(first_fork)5. if taken(first_fork) then goto 26. take(second_fork) 7. eat8. release(second_fork) 9. release(first_fork)10. goto 1

The algorithm of Lehmann and RabinModified so to avoid the need for fairness

The algorithm of Lehmann and Rabin

28

Conclusion We have provided an encoding of the

calculus into its asynchronous fragment, enriched with probabilities fully distributed compositional correct wrt a notion of testing semantics

Advantages: high-level solutions to distributed algorithms Easier to prove correct (no reasoning about randomization

required)

29

Future work: Application of pa to Security protocols Propis: a small language based on pa to

express and verify security protocols and their properties, like Secrecy

messages, keys, etc. remain secret Authentication

guarantees about the parties involved in the protocol Non-repudiation

evidence of the involvement of the other party Anonymity

protecting the identity of agents wrt particular events Formal tools for automatic verification

30

Features of PROPIS PRObabilistic PI for Security

pa enriched with cryptographic primitives similar to those of the spi-calculus [Abadi and Gordon]

The probability features will allow to analyse security protocols at a finer level (cryptographic level), i.e. beyond the Dolew-Yao assumptions: In our approach an attacker can guess a key. The point is to prove that the probability that it actually guess the right key is negligible.

The probability features will also allow to express protocols that require randomization.

31

Example: The dining cryptographers

Crypt(0)

Crypt(1) Crypt(2)

Master

pays0notpays0

An example of achieving anonymity

32

The dining cryptographers The Problem:

Three cryptographers share a meal The meal is paid either by the organization

(master) or by one of them. The master decides who pays

Each of the cryptographers is informed by the master whether or not he is paying

GOAL: The cryptographers would like to know whether

the meal is being paid by the master or by one of them, but without knowing who is paying (if it is one of them).

33

The dining cryptographers: Solution Solution: Each cryptographer tosses a coin

(probabilistic choice). Each coin is in between two cryptographers.

The result of each coin-tossing is visible to the adjacent cryptographers, and only to them.

Each cryptographer examines the two adjacent coins If he is paying, he announces “agree” if the results are the

same, and “disagree” otherwise. If he is not paying, he says the opposite

Claim 1: if the number of “disagree” is even, then the master is paying. Otherwise, one of them is paying.

Claim 2: In the latter case, if the coin is fair the non paying cryptographers will not be able to deduce whom exactly is paying

34

The dining cryptographers: Solution

Crypt(0)

Crypt(1) Crypt(2)

Master

Coin(2)

Coin(1) Coin(0)

pays0notpays0

look20

out1