

Cyber Crime Scene Investigations through Cloud Computing [pdf] - BWStearns
http://www.cs.uml.edu/~xinwenfu/paper/SPCC10_Fu.pdf

======
s_q_b
Surely the sudden spike in entry and exit nodes would make the attack obvious.
The central directory authority service could be modified to blacklist nodes
from the master OR directory list that join within too small of a time
interval.

On a more practical note, few cloud providers are going to let their network
suddenly become a massive transit space for Tor traffic.

Before this could be successfully deployed in the wild, the problem can be
easily corrected.

~~~
D9u
But the NSA could easily add a few hundred Tor nodes given their capabilities
regarding hundreds of Linux cloud servers as part of XKeyScore et al.

~~~
s_q_b
A few hundred Tor nodes would be useless in trying to break anyone's
anonymity.

With ~4k relays (entry/exits) and ~2k bridges (pure relays of encrypted
connections) and only a few hundred hostile relays, the odds of an OP's (end-
user's) connection's flowing through both a hostile entry node and a hostile
exit node are infinitesimal.

Let's say you add 400 ORs to the network. Let's further assume no one in the
privacy-conscious, some would say paranoid, Tor community notices this
unexplained 10% spike in entry/exit nodes. Your odds of compromising any given
Tor circuit (connection) are a compound probability: P(A and B) = P(A) * P(B).
In this case: .1 * .1 = .01, or approximately 1%.

When you add to the fact that the network automatically tries to route to
entry and exit nodes in different countries, the chances of compromising the
network in this fashion are virtually nill.

Everyone in the Tor community has known this attack has been possible, which
is why the network growth metrics are watched closely. If any shenanigans are
detected, the authority is prepared to add a notion of OR trust to the
directory file.

------
BWStearns
I did out the math for what was necessary to control the entire path of 50% of
the network traffic. I might post the resulting charts and stuff but when I
did it out a few months ago it required 12,000 nodes. Entry/Exit are
sufficient when also combining timing attacks but why not go whole hog? Also
the increased security from new-identitying every few minutes increases the
chance that at least some of your traffic would be caught while this type of
attack is going on.

In reply to s_q_b: Amazon actually hosted this guy's demonstration, so at
least one good cloud provider has in fact done this. Additionally, if you time
your attack correctly and don't have persistent objectives, then it's pretty
much moot that the spike is obvious because who checks the total amount of
nodes frequently while surfing? Finally, if you do have persistent objectives,
then you could mask it by introducing nodes by the dozen or so randomly spaced
over a year or two.

Edit: just to clarify: Not my paper. No one has commented to that effect yet,
but I just realized that that could be a conclusion drawn. I've only done some
analysis on this type of attack.

------
peanut_merchant
Limited understanding of TOR infastructure but any chance we could see
something like this : [http://arstechnica.com/security/2013/08/tor-usage-
doubles-in...](http://arstechnica.com/security/2013/08/tor-usage-doubles-in-
under-a-week-and-no-one-knows-why/)

~~~
BWStearns
That's an increase in clients, not Entry/Exit nodes. Until they begin flipping
over into nodes there is nothing to worry about wrt this type of attack from a
freak influx of clients.

------
deerpig
From what I understand, the real vulnerability with the Tor model is if there
aren't enough entry/exit nodes. Is there a tipping point after which, there
are so many entry/exit nodes that the system would be relatively secure from
this kind of attack?

~~~
BWStearns
Given the ridiculously cheap cost of the computing necessary to host a node,
even the increased difficulty of doubling the number of entry/exit nodes
wouldn't drive the cost of this attack into the realm of the unachievable even
for modestly wealthy individuals.

------
Amadou
I read the abstract. I'm thinking this attack is mitigated by increasing Tor
popularity. The more total Tor traffic, the less likely that deploying high-
bandwidth ingress and egress nodes will grab the specific traffic the attacker
is looking for.

~~~
BWStearns
Not quite true. The vulnerability to this kind of attack is dependent upon the
total number of exit/entry nodes, not the total number of clients.

------
stugs
While a good read, this paper is over 3 years old

~~~
BWStearns
It is in fact old, however I hadn't seen it posted anywhere even back then,
figured I'd pass it in since there was some speculation about the feasibility
of such an attack given the spike in Tor client usage.

------
SilliMon
A good read. Is the recent speed improvement in TOR due to this being done?

~~~
ZoF
Published in 2010 so I doubt it...

------
ericmsimons
OP - you accidentally linked to the paper via the google result link and not
the actual one.

~~~
galapago
[http://www.cs.uml.edu/~xinwenfu/paper/SPCC10_Fu.pdf](http://www.cs.uml.edu/~xinwenfu/paper/SPCC10_Fu.pdf)

