Cyber Crime Scene Investigations through Cloud Computing [pdf](cs.uml.edu)
cs.uml.edu
Cyber Crime Scene Investigations through Cloud Computing [pdf]
http://www.cs.uml.edu/~xinwenfu/paper/SPCC10_Fu.pdf
11 comments
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.
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.
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.
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.
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.
[deleted]
Limited understanding of TOR infastructure but any chance we could see something like this :
http://arstechnica.com/security/2013/08/tor-usage-doubles-in...
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.
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?
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.
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.
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.
OP - you accidentally linked to the paper via the google result link and not the actual one.
Sorry about that. I couldn't find the paper online until I found it on my hard drive. Googled the title and linked from there.
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.