Global key-based search attack
This is the basic mobile attacker on opennet attack. The attacker is trying to find the node that is inserting (or fetching) a set of correlated blocks. These blocks might be correlated because they are part of the same splitfile, or because they are messages from the same poster, or because they are editions of the same freesite, or any number of other reasons.
The attacker looks at incoming requests. He has a list of blocks of interest to compare to. If he sees one of the blocks, then which peer it comes from tells him something about where on the network the originator is. He then changes his location to be closer to the originator's location, and repeats until he is close enough to the originator to perform a correlation attack.
More info
https://bugs.freenetproject.org/view.php?id=3603 Discussion of a possible countermeasurehttp://archives.freenetproject.org/message/20071219.225602.e0c13cfb.en.html
Subject: [freenet-dev] Vulnerability in inserting the manifest before finishing
http://archives.freenetproject.org/message/20071219.230625.63a24cad.en.html
Subject: [freenet-dev] PROPOSAL: Don't calculate the overall key until ALL of a splitfile has been inserted
http://archives.freenetproject.org/message/20071219.231908.e3a0c934.en.html
Subject: [freenet-dev] PROPOSAL: Encrypt splitfiles randomly
Old page text
On opennet, if you get requests which you are interested in finding the originator of, you can use the keys of the requests to work out where the target is (assuming he's not in your immediate vicinity, in which case you can find him trivially anyway).
This attack has been described many times. Here's a post from somebody on Frost who reinvented it for the zillionth time. Note that while the poster was concerned about Frost identities, this will work for most long-term inserts/requests. Because the attacker will want to slowly close in on the target by connecting to closer nodes to it, he needs to know the key in advance, (or have logging on a large fraction of nodes). This works with Frost identities, it works with frequent freesite inserts, it works with splitfile downloads, it works with splitfile uploads if they are predictable i.e. if the attacker has a copy of the file being (re)inserted, or if the key is revealed before the upload is complete.
(Editor's note: there is not a single location associated with a given identity. Rather, the identity has an SSK keypair. The public key is combined (via hashing) with the docname (which will be different for each message) to determine the routing location. So, there is not a single routing location associated with the target location for all of Alice's posts; those are spread evenly through the network. There is, however a single originator location -- Alice's node. Determining this is not trivial, but probably can be done with work.)
Here's a possible attack on Frost identities. I haven't tried it, but it works in my head. ;)
First phase: find out the routing location associated with Alice's Frost identity. (I'll assume that locations are fairly stable; even if that's not currently the case, it's meant to be the case eventually.)
Every time an insert reaches our node we record the key and our current location. In most cases the inserter will be further away from the key's location than we are, otherwise the insert wouldn't have passed through our node. (Sometimes this won't be true because of backtracking, but it's a rule of thumb.) We move to a random location every few hours.
Then, every time we see a Frost message posted by Alice, we check our logs to see if the insert passed through our node. If so, every location that was further away from the key's location than we were is given a 'point'. As Alice continues to post messages using the same identity, some locations accumulate more 'points' than others. Eventually we narrow it down to a small range of likely locations. The more messages Alice posts, the narrower our range gets.
Second phase: find out the IP address associated with Alice's routing location. If Alice is using opennet this is easy: request or insert lots of keys near Alice's location, and the opennet protocol will give us lots of IP addresses near Alice's location. If we gathered enough samples in the first phase we can tell which address belongs to Alice just by the location. If not, we send each of the suspects a series of KSKs that collide with KSKs inserted by Alice. Alice's node will probably detect more of the collisions than any other node.
If Alice is using #freenet-refs, we hang out there looking for refs with suitable locations. Again, if we didn't gather enough samples in the first phase we might need to connect to a few different suspects and use collisions to identify Alice's node.
If Alice is using real darknet connections our job is much harder. For the moment let's assume some of Alice's darknet peers aren't as paranoid as she is; they use opennet or #freenet-refs. We can link their IP addresses with their locations, and we can use the location information in swap requests to discover that they're Alice's peers. So we visit a friendly judge (or not, depending on the jurisdiction) and ask for traffic data for their internet connections (no wiretaps, just traffic data). Alice's address will probably be the only one all of her peers have in common. If not, we ask for traffic data on all of the suspects and find out which one is always online when Alice posts a message.
What if Alice's peers are paranoid too? In that case we'll need traffic data for every Freenet node we can discover. Our goal is to create a map of the network, linking IP addresses to routing locations, by combining the traffic data with location information from swap requests. For example, if swap requests show that node X and node Y share a single peer at routing location Z, and we know the IP addresses of X and Y from opennet or #freenet-refs, we can find out the IP address of Z from our traffic data (it's the only address they both connect to). Then we can repeat the process if Z shares a single peer with X or Y (or any other known node). Pretty soon we have a map of the network, and then we pick the nodes closest to Alice's location and narrow them down using uptime.
So, to cut a long story short, that's why I don't use Frost identities. ;)
