Exploring DHT security

[dsluijk]

DHT's are not know for there security, but in a general-purpose p2p network there aren't really any viable alternatives. This issue tries to do research on DHT security and eventually maybe find a solution.

The attacks

The main issue is that keeping nodes available against a large adversary. Message security and integrity are fairly straightforward to implement. There are a few main types of attacks for availability:

• Sybil attack. This is where a lot of nodes are added to the network, to swing the consensus of that network.
• Eclipse attack. This is where a specific node is encircled by a lot of other nodes, essentially blocking access to that node.
• Routing and storage attacks. This is where evil nodes will intentionally mess up the routing system, to try to make the network unavailable. This could be achieved by sending bogus responses, or denying the existence of a key.

Related work

This has had a lot of prior work, which should be considered in the design. Below is a non-complete list in no particular order. Not everything has been fully explored yet:

• A survey of DHT security techniques
• Sybil-resistant DHT routing
• TrustChain: A Sybil-resistant scalable blockchain
• BitTorrent DHT security
• PolderCast
• SpiderCast
• Scribe
• Building Content-Based Publish/Subscribe Systems with Distributed Hash Tables
• TrustChain (outdated version)
• Eclipse Attacks on Overlay Networks: Threats and Defenses
• DHT Routing Using Social Links
• Pastry
• Kademlia
• Cjdns
• Ethereum
• Barabási–Albert model
• Scale-free network
• Small-world network
• IPFS

Specifically about trust

• The Social Mechanisms of Trust
• TRUST - making and breaking cooperative relationships

Speculation

I'm currently exploring four ideas, which are mainly towards solve eclipse attacks:

• Limiting the amount of new which could be added. This can be done by using a computational and memory hard hashing algorithm to calculate the mid of a node. Argon2 would be perfect for this, as it makes the playing field a bit more level against adversaries with a lot of resources. This could even be extended with a challenge response at the handshake, so one node can't accept a huge number of other nodes to poison.
• Introduction of a centralized entity. If a public key is not signed by a central system it will not be accepted in the network. This essentially drops the evil nodes in the system to near zero, but with the trade-off of all the issues currently with PKI's.
• Introduction of a web of trust in the network, using Trustchain. This is essentially the same as previous idea, but in a decentralized way. A node is only accepted in the network if it's public key is signed by a trusted peer. This removes the trade-off of the PKI's, but could let more evil nodes in.
• As discussed above the main issue is the availability of nodes. A simple solution is to drop any node which is not delivering and replace it with a new one. I think this would converge to good nodes being grouped together, while evil nodes are left out. This does need more research because it has a high probability of being exploited. The main issue is that it could add a lot of churn to the network.

This is all very much a work in progress, but I thought it would be a good idea to write out my initial findings so it could be discussed.

[arvidn]

this may be of interest: https://libtorrent.org/dht_sec.html

[dsluijk]

Thank you, I have added it to the list.

[devos50]

I'm currently exploring four ideas, which are mainly towards solve eclipse attacks:

Focussing on a single attack (in contrast to solving the full range of DHT vulnerabilities) is usually a good idea. If you want to explore Eclipse Attacks in more detail, I recommend this survey. There is also interesting work related to blockchain p2p networks since eclipsing miners in a blockchain network could be an effective way to limit the rewards of miners (since their blocks are not propagated at full efficiency).

Limiting the amount of new which could be added.

Your idea is based on (existing) Proof-of-Work mechanisms where one has to put in some effort to perform an action. This idea actually goes back to ~1990 already, where Proof-of-Work was proposed to prevent mail spam. Bitcoin (and many other blockchains) ofcourse also uses this mechanism.

Introduction of a centralized entity.

That's my favorite solution to address problems in decentralized networks :). Although it compromises on decentralization, which is not always possible or desired.

Introduction of a web of trust in the network, using Trustchain.

This is a bit of a "hybrid" solution since it still requires trusted entities for bootstrapping in the network.

As discussed above the main issue is the availability of nodes. A simple solution is to drop any node which is not delivering and replace it with a new one. [...] This does need more research because it has a high probability of being exploited.

This would require a reputation mechanism where nodes with a low reputation are kicked out of the network and honest nodes are rewarded in some way (e.g., preferential treatment). It is well-known that building secure reputation mechanisms in decentralized network is far from trivial (our lab also has much prior work on this).

I would suggest to do a bit more research on each individual idea and to get an idea of what would be the required components to implement each idea. Often, it turns out that an idea is already researched (and published). If you want, you can also drop by our office if you want to discuss these ideas in more detail 👍

[dsluijk]

Focussing on a single attack (in contrast to solving the full range of DHT vulnerabilities) is usually a good idea. If you want to explore Eclipse Attacks in more detail, I recommend this survey. There is also interesting work related to blockchain p2p networks since eclipsing miners in a blockchain network could be an effective way to limit the rewards of miners (since their blocks are not propagated at full efficiency).

I think that by having a good defense against an eclipse attack you can also mitigate most other attacks. The Route-and-Storage attack is dependent on the eclipse attack for efficient poisoning. The Sybil attack is not really an issue here, as the network is not dependent on a reputation system. I think this is an issue to be solved on the application level. If a good trust function is ever invented it might be appended to the protocol. I do intent to look at the BitTorrent, Bitcoin and Etherium network as they probably have some sort of defense against this.

Your idea is based on (existing) Proof-of-Work mechanisms where one has to put in some effort to perform an action. This idea actually goes back to ~1990 already, where Proof-of-Work was proposed to prevent mail spam. Bitcoin (and many other blockchains) of course also uses this mechanism.

This is exactly what I'm referring to, and where I got the idea from. It's proven to be at the very least somewhat effective so I don't really see a reason not to add it.

That's my favorite solution to address problems in decentralized networks :). Although it compromises on decentralization, which is not always possible or desired.

Yes, that compromise is why this is still an issue. In cases where it is possible it is the best solution. In a lot of cases it is not, therefore we have the other solution.

This is a bit of a "hybrid" solution since it still requires trusted entities for bootstrapping in the network.

Yes, my idea was that you are always referred by someone, with who you can connect with directly. This person vouches for you, giving access to nodes trusted by this person. Depending on the person you can access a larger amount of nodes. You can then "befriend" other people you know, making you circle larger by every connection you make. This gives the network a small world property, and automatically puts trusted users together, excluding most potential threads. I think this has the most potential of all solutions, as this takes a more practical approach.

This would require a reputation mechanism where nodes with a low reputation are kicked out of the network and honest nodes are rewarded in some way (e.g., preferential treatment). It is well-known that building secure reputation mechanisms in decentralized network is far from trivial (our lab also has much prior work on this).

I know this is a hard issue, I did my research :). I was thinking way simpler than that, and just dropping any connections which are dropping frames. This does not account for any reputation or something like that. I try to avoid that inside of the network.

I would suggest to do a bit more research on each individual idea and to get an idea of what would be the required components to implement each idea. Often, it turns out that an idea is already researched (and published). If you want, you can also drop by our office if you want to discuss these ideas in more detail +1

I had written this down to start a conversation and write down any ideas I already had. I'm not even halfway trough all the papers mentioned on the top of the page. Only when I think I read all interesting papers will I continue to focus on the most promising idea of the bunch. I don't really feel like making the same mistakes made 30 years ago. I'll be at the office on the first of august, so we can talk in more detail by then.

[synctext]

As discussed today, it will take a whole month of reading to become a trust expert of the basic level.

Many people in our lab worked full-time on this. This is one of the more high-level overview starting points: #31 (comment). We now have 2 full-time people in the lab working on the trust model. Please read their issues in detail: first two items in this table