Most recent edit on 2008-04-22 10:58:15 by MatthewToseland [explain flooding a bit]
Additions:
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 may be viable; it will hopefully be contained, but only by requests being rejected, not only those of the attacker but everyone else's too, and if he has multiple entry points via opennet, he can do some major mischief.
Deletions:
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. :<
Edited on 2008-04-22 10:55:53 by MatthewToseland [explain slightly]
Additions:
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 (and I know he has four peers). 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.
Deletions:
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.
Edited on 2008-03-29 18:55:24 by MatthewToseland [key search attack on darknets]
Additions:
Many of the attacks described on the opennet attacks page may also work against darknets, albeit much more slowly. You can't harvest a darknet, but you can do an adaptive search the same as you would on opennet (the difference is each connection costs much more than it would have on opennet).
Edited on 2008-03-29 18:51:16 by MatthewToseland [formatting]
Additions:
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. At this point most boards are flooded with invisible spam, an effective DoS attack on any one-KSK-queue-per-board based chat system. A new chat system, FMS, is under development, but at the moment is written in C++ and therefore cannot be bundled with the node or integrated into Frost, and has a poor user interface.
Deletions:
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. At this point most boards are flooded with invisible spam, an effective DoS attack on any one-KSK-queue-per-board based chat system. A new chat system, FMS, is under development, but at the moment is written in C and therefore cannot be bundled with the node or integrated into Frost, and has a poor user interface.
Edited on 2008-03-29 18:50:58 by MatthewToseland [FMS]
Additions:
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. At this point most boards are flooded with invisible spam, an effective DoS attack on any one-KSK-queue-per-board based chat system. A new chat system, FMS, is under development, but at the moment is written in C and therefore cannot be bundled with the node or integrated into Frost, and has a poor user interface.
Deletions:
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.
Edited on 2008-03-29 18:49:06 by MatthewToseland [implemented]
Additions:
Cancer nodes could return DNF to every request. We have implemented a partial solution with FailureTables.
Deletions:
Cancer nodes could return DNF to every request. We could maybe do something about this with FailureTables.
Edited on 2008-03-29 18:48:07 by MatthewToseland [better wording]
Additions:
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). This code is disabled at the moment.
Deletions:
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). This mechanism is disabled at the moment.
Edited on 2008-03-29 18:47:17 by MatthewToseland [swap IDs are disabled atm]
Additions:
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). This mechanism is disabled at the moment.
Deletions:
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).
Edited on 2008-03-29 18:46:19 by MatthewToseland [swapping]
Additions:
The location swapping algorithm as currently implemented is not secure. An attacker can damage the network through bogus swap requests. In fact, this happens naturally through nodes joining and leaving the network. So we have made the node randomly reset its location every few days. According to our math guru this should protect the network against natural degeneration. Whether it protects it against an active attack is another question. More info on attacking the swapping algorithm here∞.
We have some ideas on how to secure the swapping algorithm in 0.8 here.
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. It is likely that this will remain the case, and possibly even be expanded in order to try to secure the swapping process.
Deletions:
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∞.
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.
Edited on 2008-03-29 18:40:59 by MatthewToseland [the paper has been published]
Additions:
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∞.
Deletions:
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).
Edited on 2007-12-11 15:48:37 by MatthewToseland [mention weak keys]
Additions:
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.
Deletions:
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.
Edited on 2007-10-26 13:32:35 by MatthewToseland [update for JFK etc]
Additions:
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.
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.
Deletions:
From build 1021 onwards, we use a variant on the Station-to-Station protocol∞ (it's four stages like our old diffie-hellman impl), using the nodes' public/private keys. One of our Summer of Code students is implementing JFki∞, a DoS∞-resistant DH variant which supports pre-calculation of almost everything but is rather complex.
As regards invisibility: We have no fixed session bytes (unlike 0.5), even on connection setup (because it is encrypted using symmetric keys used only for this purpose). 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.
Edited on 2007-09-11 14:24:56 by MatthewToseland [link to OpennetAttacks]
Additions:
Opennet
Opennet deserves an attacks page all of its own.
Edited on 2007-08-21 17:24:28 by MatthewToseland [link to ActualAttacks]
Additions:
Click here for information on actual attacks which we think have been carried out.
Edited on 2007-08-21 15:07:59 by MatthewToseland [add the paper]
Additions:
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).
Deletions:
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.
Edited on 2007-08-21 15:04:29 by MatthewToseland [frost, wording, formatting]
Additions:
From build 1021 onwards, we use a variant on the Station-to-Station protocol∞ (it's four stages like our old diffie-hellman impl), using the nodes' public/private keys. One of our Summer of Code students is implementing JFki∞, a DoS∞-resistant DH variant which supports pre-calculation of almost everything but is rather complex.
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.
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.
Deletions:
From build 1021 onwards, we use a variant on the Station-to-Station protocol∞ (it's four stages like our old diffie-hellman impl), using the nodes' public/private keys. One of our Summer of Code students is implementing JFki∞, a DoS∞-resistant DH variant which supports pre-calculation of almost everything but is rather complex.
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 latency low, while we send larger packets only when transferring data.
Edited on 2007-08-21 15:01:04 by MatthewToseland [location swapping attacks]
Additions:
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.
Edited on 2007-08-21 14:58:02 by MatthewToseland [two more attacks]
Additions:
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.
Deletions:
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.
Edited on 2007-07-29 08:29:40 by KryptoS [Link to JFK]
Additions:
From build 1021 onwards, we use a variant on the Station-to-Station protocol∞ (it's four stages like our old diffie-hellman impl), using the nodes' public/private keys. One of our Summer of Code students is implementing JFki∞, a DoS∞-resistant DH variant which supports pre-calculation of almost everything but is rather complex.
Deletions:
From build 1021 onwards, we use a variant on the Station-to-Station protocol∞ (it's four stages like our old diffie-hellman impl), using the nodes' public/private keys. One of our Summer of Code students is implementing JFKi, a DoS∞-resistant DH variant which supports pre-calculation of almost everything but is rather complex.
Oldest known version of this page was edited on 2007-07-28 19:55:46 by MatthewToseland []
Page view:
Freenet 0.7 Security
Link Level
From build 1021 onwards, we use a variant on the
Station-to-Station protocol∞ (it's four stages like our old diffie-hellman impl), using the nodes' public/private keys. One of our Summer of Code students is implementing JFKi, a
DoS∞-resistant DH variant which supports pre-calculation of almost everything but is rather complex.
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 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 it is encrypted using symmetric keys used only for this purpose). 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.
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.
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.