1. 6 October 2002 1 PPDP / GPCE 2002 Mobile Calculi Catuscia Palamidessi, INRIA Futurs, France joint work with Mihaela Herescu, IBM, Austin for Distributed Programming

2. 2 Mobile calculi The  calculus [Milner, Parrow, Walker ‘89] CCS + Mobility of links Dynamic reconfiguration of the communication structure

3. 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. 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 xy z z z R Q P

5. 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. 6 The expressive power of  Example of distributed agreement: the leader election problem A symmetric and fully distributed solution in  x.P wins + y^.P loses | y.Q wins + x^.Q loses –   P loses | Q wins PQ y x –   P wins | Q loses

7. 7  : the  calculus (w/ mixed choice) Syntax g ::= x(y) | x^y |  prefixes (input, output, silent) P ::=  i g i. P i mixed guarded choice | P | P parallel | (x) P new name |rec A P recursion | A procedure name

8. 8 Operational semantics Transition system P -a  Q Rules Choice  i g i. P i –g i  P i P -x^y  P’ Open ___________________ (y) P -x^(y)  P’

9. 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. 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. 11  a : the Asynchonous  Syntax g ::= x(y) |  prefixes P ::=  i g i. P i input guarded choice |x^y output action | P | P parallel | (x) P new name |rec A P recursion | A procedure name

12. 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. 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. 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. 15  pa : the Probabilistic Asynchonous  Syntax g ::= x(y) |  prefixes P ::=  i p i g i. P i pr. inp. guard. choice  i p i = 1 |x^y output action | P | P parallel | (x) P new name |rec A P recursion | A procedure name

16. 16 1/2 1/3 2/3 1/2 1/3 2/3 1/2 1/3 2/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 transitions Execution: The process chooses probabilistically the transition within the group

17. 17 The operational semantics of  pa Representation of a group of transition P { --g i -> p i P i } i Rules Choice  i p i g i. P i {--g i -> p i P i } i P {--g i -> p i P i } i Par ____________________ Q | P {--g i -> p i Q | P i } i

18. 18 The operational semantics of  pa Rules (continued) P {--x i (y i )-> p i P i } i Q {--x^z-> 1 Q’ } i Com____________________________________ P | Q {--  -> p i P i [z/y i ] | Q’ } x i =x U { --x i (y i )-> p i P i | Q } x i =/=x P {--x i (y i )-> p i P i } i Res___________________ q i renormalized (x) P { --x i (y i )-> q i (x) P i } x i =/= x

19. 19 Implementation of  pa Compilation in Java > :  pa  Java Distributed > = >. start(); >.start(); Compositional > = > jop > 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. 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. 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 R Pi Qi Ri f f f The problem is reduced to a generalized dining philosophers problem where each fork (lock) can be adjacent to more than two philosophers Further, we can reduce the generalized DP to the classic case, and then apply the algorithm of Lehmann and Rabin S R’i f Si

22. 22 Dining Philosophers: classic case Each fork is shared by exactly two philosophers

23. 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. 24 The algorithm of Lehmann and Rabin 1. Think 2. choose first_fork in {left,right} %commit 3. if taken(first_fork) then goto 3 4. take(first_fork) 5. if taken(first_fork) then goto 2 6. take(second_fork) 7. eat 8. release(second_fork) 9. release(first_fork) 10. goto 1

25. 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. 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. 27 1. Think 2. choose first_fork in {left,right} %commit 3. if taken(first_fork) then wait 4. take(first_fork) 5. if taken(first_fork) then goto 2 6. take(second_fork) 7. eat 8. release(second_fork) 9. release(first_fork) 10. goto 1 1. Think 2. choose first_fork in {left,right} %commit 3. if taken(first_fork) then goto 3 4. take(first_fork) 5. if taken(first_fork) then goto 2 6. take(second_fork) 7. eat 8. release(second_fork) 9. release(first_fork) 10. goto 1 The algorithm of Lehmann and Rabin Modified so to avoid the need for fairness The algorithm of Lehmann and Rabin

28. 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. 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. 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. 31 Example: The dining cryptographers Crypt (0) Crypt (1) Crypt (2) Master pays0notpays0 An example of achieving anonymity

32. 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. 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. 34 The dining cryptographers: Solution Crypt (0) Crypt (1) Crypt (2) Master Coin( 2) Coin (1) Coin (0) pays0notpays0 look20 out1