[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



----- Forwarded message from Michael Rogers <[email protected]> -----

Date: Mon, 29 Jul 2013 16:46:35 +0100
From: Michael Rogers <[email protected]>
To: theory and practice of decentralized computer networks <[email protected]>
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 <[email protected]>

-----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 [email protected] 
> 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
[email protected]
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