On Wednesday 23 Feb 2011 16:50:54 Matthew Toseland wrote: > Assuming an attacker that can do mobile attacker source tracing but not > global attacks, which is true 1) on darknet, and 2) on opennet if the > attacker has limited budget and the network is large: > - We encrypt all the CHKs below the top block randomly. > - We use an SSK for the top block, and make sure that there are multiple CHKs > immediately below it (for reliability). > > An SSK consists of a nearly 1KB pubkey, 100 bytes of headers and a 1KB data > payload. > > We can therefore use very expensive onion routing with a very low actual > overhead: > > We route through 3 nodes, which are roughly speaking globally random. The > reason for them being globally random is to satisfy the 2 basic criteria for > mixnets: > 1. The selection of this node, our predecessor or our successor must not give > us a lot of information about the originator. > 2. The exit node must not be able to tell that it is close to the originator. > It could be far away or near, the set of possible originators must be very > large. > > We obtain each node via a rendezvous tunnel: We send out 3 "anchor" requests, > initially routed randomly and then to a random key specified by the > originator, and each one routed through a different original peer. When the > anchor requests converge a shared secret scheme establishes a connection, and > we return an acknowledgement down the shortest anchor connection. > > The actual insert is encrypted onion-style to the three nodes and sent > between them by routing to the node's location (possibly including its > previous few locations and some sort of globally unique ID e.g. the hash of > the pubkey). We do not expect a response. We allow a fairly high latency on > each hop to provide mixing and hence resistance to traffic analysis and some > resistance to traffic labelling attacks. So it's similar to Mixmaster. It can > be attacked by not doing the insert. One solution to this is to subscribe to > the key ourselves: For a WoT, chat or messaging application, we will be > subscribed to the key. For a freesite or other predictable key, likewise > there is nothing unusual about fetching the key. If we don't see it in a > reasonable time we can send another insert, through different nodes. > Alternatively we can insert down 2 or 3 paths at once. > > Even if we have to insert down 3 paths, and even if it takes 7 hops for each > route, because the payload is so small, this is not a big deal: > > 2KB > (unfortunately we will need to include the pubkey since it's encrypted) > * > 3 > (we are using 3 paths) > * > 3 > (O -> A, A -> B, B -> C; 3 nodes) > * > 7 > (hops at each point) > > Gives 126KB. Which is actually not all that much. 42KB for one path (assuming > we reinsert if we don't see it; there is some risk in this), 84KB for two > paths. > > The main difficulty is what happens if an attacker's nodes just swallow the > insert and never relay it - either as one of the chosen nodes or one of the > nodes along the path. > > But the effectiveness of such an attack is only linear. > > We can completely prevent traffic labelling by not expecting any feedback and > creating a new tunnel for each request. On the other hand, this combined with > the number of nodes involved results in a large number of predecessor > samples. But without traffic labellng these predecessor samples are worthless > unless all the nodes are conspiring or the flow can be identified. > > So, provided we can limit it to *SSK inserts*, and provided the attacker > doesn't have sufficient penetration to block inserts (they would need approx > 1 in 21 nodes, 1 in 7 if we use 3 tunnels), we can have an effective onion > routing system for the parts that need to be onion routed. > > For CHK inserts, it would be possible but rather expensive, possibly > infeasibly so. > > For requests we need a reply so would have to be more conventional - long > lived tunnels, worrying about predecessor samples, it'd be a different > system, and it'd be expensive, probably infeasibly so. > Using one tunnel per message/insert is predicated on traffic labelling being impossible. That means that predecessor samples are useless.
The problem is you probably can do predecessor labelling even in a high latency system where there are no streams, where the whole message (insert in this case) is received before it is relayed: You simply send messages for node A at time T1, messages for node B at time T2, and so on, and cycle through them. However, the amount of information that can be conveyed this way is severely limited. To pull off such an attack you'd need to either target a specific node or have a lot of nodes scattered through the network (both are very difficult on darknet; on opennet you can also try to attack peer selection by Sybil'ing large parts of the keyspace, on darknet you can do this but only if you can break swapping). If you have a lot of nodes, as long as delays are largish, you probably won't be able to convey enough information, at least not without taking a very long time. An important point is if, on the first stretch of the onion, an attacker is close to the originator, it might be possible for it to identify the originator, e.g. by routing locations. The other question is do the same arguments apply when there is a response, possibly through a different tunnel? If it's through the same tunnel the attacker has the additional information of the time taken. If it's through a different tunnel he only has one time for each tunnel. Although returning data requires setting up a tunnel in advance to receive data (attacker might have the time between the setup and the returned data). Specifying the reply onion in advance without testing it is possible but unreliable given the latency of the request going out; specifying backup routes may help (although it complicates the onion construction). Of course, swallowing inserts and not doing anything with them is possible now, without tunnels... So: - Swallowing inserts and not doing them is a greater threat with onions because they go through twice the number of hops or more. However it's basically the same, and there are reasonable countermeasures. - Backup routes are probably a good idea. - As pointed out already, any such mechanism would be expensive and so would usually only protect the top blocks, forum posts etc. However this provides a lot of protection for relatively little cost. - If packets rather than streams are onion routed, with high-ish latency mixing (wait until enough packets have arrived before forwarding), traffic labelling attacks are hard, low bandwidth, and therefore predecessor samples, while very numerous, are not necessarily very useful. - Mixing (non-onion) makes a lot of sense for regular requests: On bulk transfers, don't relay CHKs packet by packet, wait for the whole transfer and then wait until we have some number to send. Eliminates a lot of traffic analysis possibilities. - Freenet's threat model remains focused on a distant attacker. Protection against a treacherous friend would be expensive. Options: -- Short random-rendezvous tunnels: Best way to beat this is probably to fake different identities to different friends - somewhat costly in the broad sense. Predecessor samples an issue if the tunnel happens to be short. Could be long lived or short lived. -- Simple tunnels involving friends and FOAFs: Probably not feasible without giving away too much information to the end node by the selection of the second node. -- Cellular structure with relaying: Even with FOAFs we're probably looking at 6 hops. -- Cellular structure with direct connections: 3 hops, traffic analysis issues if low volume / low latency (e.g. protecting browsing freesites). -- If data is very popular we could use Dining Cryptographers (both for the key and to estimate its popularity) and broadcast the returned data within the cell. -- Maintaining a cell would be very difficult given uptime issues. -- I suspect the best option is to not worry about local attackers, except maybe the first option. - Another interesting idea w.r.t. high latency allowing better concealment: In MAXIMUM, always use bulk requests. If we don't have a freesite in cache, offer to download it. Need much better notifications and need to download everything needed to display a page/site. - If data is popular and there's a big tree of requesters, they all have reasonable plausible deniability - they may be requesting it for others. Although if watched long term there may be issues - if it always subscribes while it's up, is it subscribing for itself? Relaying data for offline peers will help with this. - Can we tunnel the requests and then return the data through the subscription fabric? Probably not - DoS's. Subscriptions and passive requests don't fit well with tunneling as they require very long lived tunnels, the nodes involved may go down, etc, although we could use alternative routes and if necessary cache the data on the way back ... - Basically, it is more important to protect publishers most of the time, and it looks like it's easier too. Our threat model is 1) distant attacker, 2) inserts are more dangerous than requests. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20110223/b12f8178/attachment.pgp>
