[qhfddxld] Freenet threat model

The threat model of Freenet, that is, the kind of attacks it is designed to, or wants to, protect against is not too frequently articulated. It is given on Toad's (the principal developer) blog (also published as a flog on Freenet.) in the section "Freenet's threat model (very basic version!)". Reprinted here because I think it is important for reasons I will get into in future posts. I've slightly modified it because some of the pronouns were confusing in the original.

We assume that the attacker is initially distant. That is, he knows of an anonymous identity (the author of a freesite etc) which he wants to trace back to its real-world identity. We want to make this task as difficult as possible.

In other words, Freenet is about hiding in the crowd. It's not much use if the author is is already on the attacker's shortlist of suspects. In the more unpleasant regimes, and even in the west quite often, the author has bigger problems at this point (e.g. dawn raids!). In particular, Freenet does not provide strong protection if the author is already connected to the attacker: Provided the attacker can recognise the content (possibly after the fact from logs), he can identify with reasonable confidence that the author is the originator. One consequence of this is the author needs a reasonably large network to hide in, and if the attacker can afford to connect to everyone (or in some cases exclude a group of nodes at a time) he can probably trace the author.

We do not provide the sort of anonymity guarantees that mixnets such as Tor can in theory provide. In practice a scalable mixnet is a difficult problem for similar reasons to why opennet on Freenet is hard, e.g. route selection attacks. But it's a different, and difficult, problem. We do plan eventually to provide stronger protection against nearby attackers, using some form of tunneling (classic mixnet sadly doesn't work on darknet). However, in the near future we have bigger fish to fry, as I will explain below.

The other part of the Freenet threat model is blocking: We want to make it hard to block Freenet on, for example, a national firewall. Again, blocking opennet is straightforward, because you can simply harvest the nodes and block them. We try to make it as difficult as possible to identify the Freenet protocol, and one of our Summer of Code students this year has been working on transport plugins, which will enable us to disguise Freenet traffic as VoIP, HTTP, etc.

Of course, traffic flow analysis can identify any peer to peer network, including Freenet, even if we have very good steganography. The brute force approach of blocking all packets between two "consumer" IP addresses (similar to many of the spam RBLs) will also crush any fully decentralised network. But this is likely to be somewhat expensive and have some collateral damage; provided that VoIP remains important, and largely decentralised in its actual traffic flows, hopefully this won't happen soon, outside of places like Iran.

Obviously traffic analysis can be used to try to identify what is going on on Freenet, combined with malicious nodes, and so on. This is a problem for Tor too. Freenet is designed to have higher latency than Tor, mostly used for big downloads, which is a slight advantage, and there are a lot of things we can do in future. I'm not going to make any promises about traffic analysis here, and no doubt there are other classes of attacks.

The bottom line is use darknet. No, really, use darknet! It's vastly more secure because it's virtually impossible for the attacker to connect to everyone, and very expensive for him even to connect to one more node: he has to either hack your computer or social engineer you. Which isn't necessarily all that expensive - it's just that compared to opennet, where you can just announce to a location, it's very expensive.

Also, for reasons explained below, for now, we only provide strong protection for original content uploaders (and that only if they insert to a random key i.e. SSK@). If you download content, or reinsert it, you are potentially vulnerable. However, we will improve on this; see the next section.