Re: [tor-dev] Attack linking Tor circuits

[Paul Syverson <paul.syverson@xxxxxxxxxxxx>]

Hi Otto,

This looks cool and complements nicely research that I have
back-burnered for a long time now around what middle relays can
observe from guards and how this is affected by the number of guards,
amongst other things. The plans to move to a single guard are indeed
well underway, so your work is timely. 

You considered randomizing circuit lifetime, but did you also consider
the mitigating effect of randomizing circuit lifetime overlap? That
is, if clients did not mostly use exactly one circuit at a time but
continued making new connections for a (random length) period over an
existing circuit even after they started using a new circuit how that
would affect things?  It sounds like this was not considered.  I have
similar timing questions about circuit build times, although for
pre-emptively built circuits I would think there is a likely advantage
to some synchronization and mixing across the network.  Anyway cool
stuff. I'd like to hear more about it.  Are there drafts of your work
available?

aloha,
Paul

On Fri, Sep 19, 2014 at 01:10:06PM +0300, Otto Huhta wrote:
> Dear Tor developers,
> 
> 
> 
> Weâve been working on an MSc Thesis project looking into an attack that
> links different Tor circuits back to the same user, using only information
> available to a Tor middle node. Weâve discovered that an adversary can
> quite accurately determine if two consecutive circuits are used by the same
> user just by looking at when these circuits are built and destroyed or when
> they begin and stop relaying traffic. This is mainly the result of the
> fixed 10 minute circuit lifetime and the fact that the transition to using
> a new circuit is quite sharp. According to our measurements, circuits
> belonging to the same user are built at very close to 10 minute intervals.
> Also, when one circuit stops relaying traffic another one suddenly becomes
> active, at almost the very same moment.
> 
> 
> 
> Thanks to these properties we could train a classifier to quite efficiently
> identify matching pairs of circuits (9% EER). We looked into the threat
> posed by this attack to Tor users and concluded that because of entry
> guards the threat is real, given that an adversary can control a
> significant portion of middle node traffic. Finding matches among all
> possible Tor circuits would result in too many false positives but thanks
> to entry guards an adversary can focus only on circuits built through these
> specific nodes and quite efficiently determine if two circuits belong to
> the same user. Possible plans of moving to using only a single guard node
> make the situation much more severe: we concluded that for a user picking a
> slow guard node, the adversary can find almost all circuits belonging to a
> same user (again assuming control of a large portion of middle node
> bandwidth). We thus see that before moving on with any such plans, one
> should consider the effect of our findings on the threat posed by a middle
> node linking user circuits.
> 
> 
> 
> As a final note, we considered the effects of randomizing the circuit
> lifetime (e.g. between 5-15 minutes) to mitigate this threat but concluded
> that it would not necessarily solve the problem. The most prominent feature
> linking two circuits together seems to be the time difference between
> traffic ending on one circuit and beginning on another circuit, and this
> link cannot be broken by varying the circuit lifetime. However, if someone
> were to devise such a modification, we would be happy to re-run our tests
> to see what kind of an effect this would have on the success rate of an
> adversary.
> 
> 
> 
> For those interested in our findings, the full thesis Linking Tor Circuits
> can be found at:
> 
> http://www0.cs.ucl.ac.uk/staff/G.Danezis/students/Huhta14-UCL-Msc.pdf
> 
> 
> 
> Best regards,
> 
> Otto Huhta, UCL

> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev