Analysing%20the%20MUTE%20%20Anonymous%20File-Sharing%20System%20Using%20the%20Pi-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 its
  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 As 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 searchers 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
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
MUTE Reply

• If B wants to reply it sends a message to As
  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/(3n).
• 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 aP ( P Q )
if (cond)
then P
15
Key Semantics
?altbgt
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 -\?

?altbgt
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
Env
c1
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 peers 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
B
A
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
B
A
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_i
  d,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 gt 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
I

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

H
G
F
E
D
C
B
A
A
41
Old Peer-to-Peer File-Sharing
I

• 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

H
G
F
E
x
D
x
C
x?
B
A,E
A
E
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.