Re: [p2p-hackers] Dealing with malicious nodes in decentralized p2p network

----- Forwarded message from Michael Rogers ----- Date: Mon, 29 Jul 2013 16:46:35 +0100 From: Michael Rogers To: theory and practice of decentralized computer networks Subject: Re: [p2p-hackers] Dealing with malicious nodes in decentralized p2p network User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 Reply-To: theory and practice of decentralized computer networks -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm not sure whether your message just came through to the list or whether I just noticed it. Either way, I hope it's not too late to reply. The following papers describe attacks that can be carried out by malicious nodes in structured P2P networks: E. Sit and R. Morris. Security considerations for peer-to-peer distributed hash tables. 1st International Workshop on Peer-to-Peer Systems (IPTPS ?02), Cambridge, MA, USA, March 2002. http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.7175 M. Castro, P. Druschel, A. Ganesh, A. Rowstron, and D.S. Wallach. Secure routing for structured peer-to-peer overlay networks. 5th Symposium on Operating Systems Design and Implementation, Boston, MA, USA, December 2002. http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.118.1870 I'd recommend checking out the papers that cite those papers, some of which propose solutions to some of the attacks. Cheers, Michael On 13/03/13 05:44, offbynull wrote:

Hi,

Does anyone know of any strategies to prevent, identify, or work-around malicious nodes in a structured overlay? I'm specifically interested in Chord's ring overlay. It seems like there are a lot of things a malicious node could to to interfere with normal operations (e.g. routing / lookup / etc..), or to bypass certain regions of the ring.

Examples of things that a malicious node could do ...

1. Imagine someone wanted to prevent others from accessing a key-value pair. That person would create a malicious node with an id of hash(key), ensuring that queries for that key would end up at the malicious node. When the malicious node receives queries for that key, it simply ignores them or responds that the key was never set.

2. This is similar to the one above. Imagine someone wanted to prevent others from accessing a key-value pair, but a legitimate node already existed with an id of hash(key). That person would create a malicious node with an id of hash(key) - 1. When other nodes ask the malicious node to be routed to that key, the malicious node would respond with a node other than it's successor, ensuring that the request never gets routed to its true destination.

3. Imagine someone wanted to cut out a portion of the nodes in the overlay. That person would create a malicious node that has its finger table set to skip over a bunch of existing nodes in front of it.

Are there strategies to deal with this, or is this just something that's expected with Chord's design (as in peers can't be untrusted nodes)?

_______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR9o5bAAoJEBEET9GfxSfMj0AIALZ+lSnA7GDh+Y3iifdVotwK YXdjGjv+qJcvOIO/rHtTEyPMzp7yqz0X0VxeiC8XIjXP6rwvFGOXuClqd0NAjFW9 lHYtO9tHBkCV/LOU5hHrD3510Ry6gYkuDnyDeWBlwQ2i/zUU160PqGr+Esd1IpNP zu5JKSHHq61wr5GisXOB+pWOxrKEEKtQAtv3ibFNBDXhGyJwg+U/LCe9Q14V9Q4t BiOKgce8xHhbytY8B/5t3HW6cCavQAq/TR0CfjpWRtz823hs0lTdepJJXPnKVYIo HD0u+cwnCGr7LNF5szMvkvdEkyXsbXGLYX+2cK7aHBPO4kGoXw5DrNAhS2Gkh+g= =xMmD -----END PGP SIGNATURE----- _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5