Analysing the MUTE Anonymous File-Sharing System Using the Pi-calculus

1. Analysing the MUTE Anonymous File-Sharing System Using the Pi-calculus Tom Chothia CWI

2. Anonymous File-Sharing system 800,000 downloads Appeal for donations Informal description Source code

3. Introduction • I want to know if using this system really is anonymous. • It looks good and seems to be well made. • But is it correct? • To find out I model MUTE in the pi-calculus • This is a formal, mini-concurrent language. • Modeling MUTE in the pi-calculus formalise its specification and allows us to check correctness.

4. Peer-to-Peer File-Sharing • Peer-to-Peer file-sharing allows a large number of users to obtain files, without putting all the load on one central system. • Any peer in the network can act as a client and a server, and passes on copies of files it has downloaded. • Many designs of peer-to-peer network exists. File-sharing networks must be “searchable”.

5. Peer-to-Peer File-Sharing In newer networks peers record the IP address of other peers. A searcher sends a request to all of it’s “neighbours”. This is forwarded to all of there neighbours, up to a fixed hops. A

6. Peer-to-Peer File-Sharing The search request includes A’s IP address. Any peer with the requested file contacts A directly. Peer “A” may then request the file. A

7. Peer-to-Peer File-Sharing No anonymity from peers inside the network: The search message gives the searcher’s IP address and name of the files they are looking for. By requesting a file, you can find out the IP address of all peers that are offering the file. A

8. MUTE • MUTE removes the IP address from the file exchange. • Peers only know the IP address of their direct neighbours. • Peers choose random “pseudo ID”. • Files are not sent directly between peers. Instead files are sent via a number of peers. • MUTE uses a version of the “Ants” ad-hoc routing protocol.

9. A A A A A A A A MUTE: Search The search takes place as before, but this time the message uses its pseudo ID as the “from ID”. Each peer builds a routing table by records the ID and the connection. A probabilistic time-to-live counter limits the search. A

10. A B B A A A A B A A MUTE: Reply If B wants to reply it sends a message to A’s pseudo ID. This message is routed using the ad-hoc routing table. The route to B is also recorded B A A

11. MUTE • A peer can claim that it is forwarding packet for some other peer. • A 3 phase probabilistic time to live counter is used to make it hard to tell where a search starts or stops. • The first phase counter is set to n with prob. 2/(3^n). • The second phase counts 5 steps. • Once the second phase counter runs out peers forward the search with prob. 1/(3 x 2n) • In MUTE all the probabilistic choices are fixed when a peer starts. This protects against statistical attacks.

12. Anonymity Provided by MUTE • MUTE makes it hard to link the IP address of a peer with its pseudo ID. • Peers only know the ID address's of their direct neighbours. • The network should provide enough cover to let a neighbour deny using a particular ID. • If an attacker can complete surround a peer it looses anonymity.

13. Anonymity Provided by MUTE It should be impossible for an attacker who • is acting as any number of peers, • and can observe any number of connections, • but does not know what the network looks like, i.e., cannot be sure that they have surrounded a peer to be able to link any IP address and pseudo ID with an arbitrarily high probability.

14. The Pi-calculus • The pi-calculus is a mini-concurrent language. • It has a precise semantics, so processes can be checked by hand, or automatically. • Our version of the pi-calculus is asynchronous and includes an “if” and a finite number of numbers. P,Q ::= stop | send a (b) | rev a (b);P | repeat P | new a;P | ( P | Q ) | if (cond) then P

15. Key Semantics a<b> a(x) send a (b)  0 rev a (x);P  P P P` Q  Q` P | Q P` | ( Q` [ b /x ] ) e.g. send a(b) | rev a(x);send x send b No communication across a new: send a(b) | new a; rev a(x);send x -\ a<b> a(x) 

16. Weak bi-simulation • Two systems are weakly bi-similar if: • every input and output of one systems is matched with the same input or output and any number of internal transitions in the other system • and the resulting processes are also bi-similar. • Weak bi-simulation defines the observation power of the attacker. • Using bi-simulation, rather than trace equivalence gives the attacker the power to detected states where a possible action has been ruled out.

17. Simplifications Made by the Model • No actual file transfer: single “search” message is responded to with a “reply” message. • The random choices a peer makes are given as parameters of the process. • Message to an ID are routed along any connects over which a peer has previously received a message from that ID.

18. Simplifications Made by the Model • We assume that the “to ID” is always known. • We do not test and drop repeat messages. • We do not model a message going round a loop and returning to a peer that has seen it before.

19. The Pi-calculus Model of MUTE • We make pi-calculus models of • an “innocent” peer: I, that only forward messages. • A “guilty” peer : G, that forwards messages and replies to requests for a file. • And an environment: E, • These processes are parameterised on the communication channels that run between them... • and the choices the peer makes at start up.

20. The Pi-calculus Model of MUTE • We can use these processes as building blocks to make any network. e.g. I(c1,c2,c3) | G(c2,c4) | G(c3,c5) | E(c4,c5) e.g. new c2,c3,c4,c5; I(c1,c2,c3) | G(c2,c4) | G(c3,c5) | E(c4,c5) c4 c2 c1 Env c3 c5

21. Model of an Innocent Peer. Innocent Peer ( (ci1, co1), (ci2, co2), for, ttl ) = new my_id, repeat { rev ci1 (kind,to_id,from_id,phase,counter); send memory(from_id,co1); | if [kind = search] then Forward | if [kind = reply] then Reply ... } | repeat { send co1 (search,_,my_id,1,ttl) } ...

22. Correctness We want to show that the environment provides cover for a guilty peer: i.e., for all guilty peers G and environments Env there exists an innocent peer I and environment Env’ such that G | E ≈ I | E’ Env Env’ ≈ G I

23. Checking the Model We check that: new c1.( Guilty_Peer(c1,c2,pg,) | Env (c2,e1 ) ) ≈ new c1.( Innocent_Peer(c1,c2,pi) | Env (c2,e2 )) This is small enough to do by hand ~ 24 states to check. We can also check it automatically using ABC.

24. Another Bisimulation Checker • ABC is a bisimulation based on the Mobility Work Bench. • Only finite sets of numbers are possible. • No mismatch (can be encoded by trying to match all other values). • User interface is messy and new names handled poorly.

25. Stop for model checking demo

26. Failure of Bisimulation The output is sequence of actions: • receive a search message from the attacker, • sent a reply from the guilty peer / the environment, • receive a well formed search message from the guilty peer’s ID, • receive a reply message “from” the guilty peers ID. • Then the innocent network can perform . • a receive the same reply back • The guilty network cannot perform this action.

27. What Happened? Guilty: • The guilty network shares its file and makes its ID public. • The innocent network matches this with a file from the environment. • The attacker makes a search message using this ID as the from address and sends it back. Env A A Innocent: Env A B

28. What Happened? Guilty: • A record of that ID and the connection is added to peers routing table. • This is an “incorrect” entry in the routing table. • It routes messages away from their real owner and to the attacker. A Env A A Innocent: A Env A B

29. What Happened? Guilty: • Now the attacker sends a reply message to that ID. • The innocent peer may send it back. • Whereas, the guilty peer will always accept the message. A Env A Innocent: A Env B

30. Description of the Real Attack • The attacker tries to steal an address by sending a large number of fake message. • The attacker then sends 50+ reply messages, use the target ID. • If the reply is not returned to the attacker then there is a high probability that it belongs to the neighbour.

31. Fixing MUTE • We can fix this problem by using authentication keys as the peers pseudo IDs. • Each peer then signs the IDs of its messages. • Hence the attacker cannot forge messages.

32. Results • This fix was added to the latest version of MUTE. • Along with time stamp to stop an attacker hording messages until their drop off the seen message list. • We use a Lamport style counter to stop the attacker gaining information from the time stamp.

33. Conclusion • We have modelled the MUTE system in the pi-calculus and tested its anonymity using: For all pg,e1 there exists pi,e2 s. t. Guilty_Peer(pg,) | Env (e1 ) ≈ Innocent_Peer(pi) | Env (e2 ) • We found a significant fault in the protocol and designed a correction that has now been downloaded over 60,000 times.

34. Questions?

35. Message Format • The messages sent over channels have the format: (type of message, to id, from id, counter phase, counter value ) e.g. (search,_,my_id,1,ttl) or (reply,to_id,from_id,_,_) • Channels are split into input and output parts.

36. Checking the Bi-simulation A connection to a guilty peer should be act the same as from a connection to an innocent peer For all parameters pg and e1 there must exist parameters pi and e2 such that: Guilty_Peer(pg,) | Env (e1 ) ≈ Innocent_Peer(pi) | Env (e2 )

37. Model of an Innocent Peer Forward = if (phase =1 and counter > 1 ) then send co1(search,to_id,from_id,1,counter-1) send co2(search,to_id,from_id,1,counter-1)... Reply = if (to_id =/= my_id) then ( new loop; send loop | rev loop; rev memory (x,ch); | if x = to_id then send ch(reply,to_id,from_id,_,_) | if x =/= to_id then send loop | send memory (x,ch) }

38. Model of a Guilty Peer Guilty Peer ( (ci1, co1), (ci2, co2), for, ttl ) = new my_id, repeat { rev ci1 (kind,to_id,from_id,phase,counter); send memory(from_id,co1); | if [kind = search] then { Forward | send co1 (reply,from_id,my_id,_,_) } | if [kind = reply] then Reply } | repeat { send co1 (search,_,my_id,ttl) } ...

39. The Environment Env ( (ci, co), ( (id1,p1,c1),..,(idn,pn,cn) , j ) = repeat { rev ci(kind,to_id,from_id,phase,counter); if [kind = reply] then { send co(reply,from_id,id1,_,_) | ... | send co(reply,from_id,idj,_,_) } | repeat { send co(search,_,id1,p1,c1) | ...| send co (search,_,idn, pn,cn) }

40. “Old” Peer-to-Peer File-Sharing Peers “A” to “I”, “A” would like to get file “x” First generation networks used a central database. Peers told this database what files they have. I H G F E D C B A A

41. “Old” Peer-to-Peer File-Sharing Peer “A” asks the database for “x”. The database tells “A” which peer has the file. “A” downloads the file from that peer. “A” tells the database it has the file. Other peers can then download the file from “A” I H G F E “x” D “x” C “x”? B A,E E A “x”? “x”? I have “x” “x”?

42. Example: Anonymous File-Sharing • The user may wish to hide • that they are offering files • that they are taking part in data transfer • that they are running the software at all. • The user may want to have plausible deniability or go complete unnoticed.

43. Example: Anonymous File-Sharing • The user may wish to hide • that they are offering files • that they are taking part in data transfer • that they are running the software at all. • The user may want to have plausible deniability or go complete unnoticed.