Freenet 0.7 Security

Link Level

From build 1066, we use JFki∞, a Diffie-Hellman∞ variant which supports pre-calculation of almost everything and is therefore highly resistant to denial of service attacks on both CPU and memory. This is partly thanks to a Summer of Code student. This is surrounded by an outer, symmetric encryption layer using both nodes' identities for invisibility. All Freenet 0.7 packets look like random data. Until late 2007, our DH code (in all versions of Freenet) was vulnerable to weak keys.

At present there is some random size padding and message coalescing. However, we are probably still fairly vulnerable to traffic analysis against a powerful attacker because we have to send very small packets frequently to keep the search latency low, while we send larger packets only when transferring data.

As regards invisibility: We have no fixed session bytes (unlike 0.5), even on connection setup (because of the outer encryption layer). However our profile may be detectable based on packet size and the fact that the connection is UDP. It may help later on to support variable data packet sizes within bulk transfers and block transfers.

Also, at the moment our encryption uses the hash of the plaintext as the IV (after adding 12 bytes of random padding), and the same encryption key in both directions. This probably isn't a good idea. See NewPacketFormat. According to NIST∞, the IV must be unpredictable for CFB mode, so this may be a weakness (we use PCFB∞ but our implementation is identical to CFB∞ because the key size and block size are identical).

Finally, we use Rijndael with 256-bit keys and 256-bit blocks. AES, the form of Rijndael which was approved by FIPS and the NSA (including for top secret documents), uses a 128-bit block size, because most cryptanalysis involved in the standardisation process focused on that block length. So theoretically there may be attacks on Rijndael with 256-bit block size that don't work with 128-bit block size. If you hear of any, tell us!

Request Level: Darknet Peers

On Freenet 0.5, correlation attacks were possible. On Freenet 0.7, they are still possible, but they may be somewhat easier because routing works on 0.7 (and because of how it works).

A correlation attack essentially is of the form "Peer A is doing a group of requests. I recognize that the splitfile he is fetching is X, and that he is fetching exactly 25% of it from me. Therefore, it is probably a local request for that splitfile". This can also be helped by knowing the HTL, and another approach is to look at the closeness of the key to the specialization of the node the requests are being sent to. Essentially it's a statistical attack. The first form relies on the attacker knowing the splitfile; key closeness on the other hand may not have this requirement.

In any case the bottom line is if you fetch, or insert, a large splitfile, and your darknet peers (your supposedly trusted neighbours) do some statistical attacks, they can identify that the request is probably from you. This could be very bad!

The long-term solution is PremixRouting - a layer of onion routing before the request starts. There may be other solutions which help to some degree, for example, fixed routes for large bundles of requests for the first few hops. PremixRouting will probably not be implemented until 0.8, as it appears very difficult either on a darknet or an opennet. It will probably require the network topology to be exposed, and some sort of cellular structure, so that a request has a defined anonymity set; it could have started on any node in the cell.

Of course, you have to get a connection to the target in order to do this. On 0.5, or on opennet, this is easy: create an ubernode, make it pretend to be very many nodes, harvest the network, connect to every known node. On 0.7 darknet this is supposed to be very hard - especially if you don't know who the target is, which is the usual situation. Obviously stupid users will cause security problems by connecting to well known ubernodes which might be run by evildoers.

Datastore

On Freenet 0.5, everything you requested or inserted had a good chance of being stored in your datastore, especially if it wasn't full. This means that if an attacker managed to seize your store, they could identify what you had been browsing - at least in terms of large splitfiles. On 0.7, there will be the option to choose between two policies (at present the second is fixed):
1. Store nothing: Local requests/inserts are not cached in the datastore. The advantage is that if your store is seized, it won't give away much information. The disadvantage is that if your darknet peers are evil they can probe your store after an insert to determine whether your request is local.
2. Store everything: Local requests/inserts are cached in the datastore. You are safe from your darknet peers probing after seeing a request, but if your store is seized it will incriminate you.

Location Swapping and network topology

The location swapping algorithm as currently implemented is not secure. If the topology is explicitly exposed then swaps can be enforced. Exposing the topology to some degree is also required for premix routing, so this is the direction we will move towards in the long term. More here∞ (the paper hasn't been published yet).

Worse, there are indications that not only are attacks on the swapping algorithm both easy and effective, but that the network will degenerate by itself over time into a state of all node locations clustered into a few small parts of the keyspace due to join-leave churn! We are working on a solution to this problem as a matter of urgency, probably involving occasionally resetting nodes' locations.

At the moment a large part of the topology is exposed through swapping: Because swap requests are routed randomly for 6 hops, there is no way of encrypting the exchange. Therefore any intermediate node can see the two nodes' locations and their peers' locations.

Topology debugging/diagnostic tools

Probe requests: We provide a mechanism to send a request for the closest node location greater than a specified value. We send a probe request, this is routed normally, it returns the number of hops it took, the closest location found that is greater than the target, and the closest location found. At the moment this also returns hop by hop information on the locations, peers, and unique identifiers (see below) of the nodes the request passed through.

We have also added a unique identifier to each location in the swap requests. This will enable us to reconstruct the long-range structure of the network by watching the swap requests which pass through our node. Obviously an attacker can do the same analysis. However for short-range topology, this can already be done reasonably accurately, and it's the short range that is really interesting to an attacker (we hope).

The objective of both of these mechanisms is to investigate the topology of the network and determine whether it is unreasonable as a result of not having opennet, or whether there is a problem with swapping etc.

Load Balancing

I am not sure exactly how we will secure the current LoadBalancing system; it does involve feedback going back to the originator of the requests which then changes its frequency of sending requests. Right now this means that it *may* be possible to tell which requests made by your direct peers are locally originated. Maybe premix routing will fix this... maybe not, in the presence of colluding nodes. It is likely that load balancing will undergo radical changes in the not too distant future. Apart from that, flooding the network with requests or inserts will not be constrained in any way by the current load balancing system. :<

Cancer nodes

Cancer nodes could return DNF to every request. We could maybe do something about this with FailureTables.

Opennet

Opennet deserves an attacks page all of its own.

Frost

The Frost message boards system is not part of Freenet proper, however very many Freenet users use it, and it is *seriously* vulnerable to spam as has recently demonstrated. It is probably possible to radically improve its security against spam, but this is currently in the early design / discussion phase.


All in all, Freenet 0.7's security leaves much room for improvement, but in many ways is probably an improvement on 0.5. On a true darknet, whole classes of attacks are far more difficult and there is the possibility of hiding the network and running it in hostile environments where 0.5 may have been blocked very cheaply.

Click here for information on actual attacks which we think have been carried out.