----- Forwarded message from Kerry Bonin <[EMAIL PROTECTED]> ----- From: Kerry Bonin <[EMAIL PROTECTED]> Date: Mon, 31 Oct 2005 07:25:20 -0800 To: "Peer-to-peer development." <[EMAIL PROTECTED]> Subject: Re: [p2p-hackers] P2P Authentication User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) Reply-To: "Peer-to-peer development." <[EMAIL PROTECTED]>
Frank, In my experience w/ pretty hardcore authentication and security domains, it is pretty much impossible to guarantee that a remote node connecting over an untrusted network is running trusted code. For every clever way to try and detect a compromised client, there are even more clever ways to subvert the detection process. The simplest model - simply reverse engineer the network traffic via packet capture, and write a client that looks identical from the network traffic. One example of a common client validation approach is requesting a strong checksum of some random range of the client or its dataset, but this is pretty trivial to circumvent once you have a complete copy of the client and have reverse engineered its checksum algorithm. In my experience, if you really care about what your node are doing, then NEVER trust ANY node - validate every bit of every packet. If you are trying to catch compromised nodes, there are clever ways to do that - build heuristic models that examine what nodes are doing, and forward captures to admin nodes for human analysis for heuristic refinement and analysis of what your attackers are up to. While it is in theory impossible to allow users to do "anything" and still catch a user "doing something they're not supposed to", it may be possible to specify terms in your EULA that define constraints users would not typically violate, and respond with penalties that are not too strong for the corner cases where a user triggers a false positive by crossing the line. An example of this in the file sharing domain would be temporary bans on nodes that initiated too many searches in some time frame, suggesting spidering. On the other hand, clever counter-heuristics and large numbers of zombies can defeat most heuristics - see SPAM for many examples... Kerry Frank Moore wrote: >Matthew Kaufman wrote: > >>I think what you're asking here is "is it possible to design a p2p >>network >>such that the peers must be running the official code that does the >>right >>thing, instead of running some subverted code that does something >>'wrong'?" >> >> >Matthew, > >Very eloquently put. Yes, this is exactly what I was asking. >We supply the client as well as the server and we just need to make >sure that any client that joins the >network is our client and not a 'rogue'. > >>The one exception is that you *can* in some cases design the network >>such >>that peers that don't behave "properly" are shunned or dropped by the >>rest >>of the network, assuming that such behavior is detectable. For >>instance, in >>a distributed file store, you could store test data and see if it sticks >>around... If it doesn't, that peer is "cheating". >> >> >We have a way (we think) of authenticating the stream put out by a >peer, so we can catch a 'rogue' client this >way, but it seems more logical to prevent someone from logging into >the network in the first place. > >Thanks for your help, >Frank. >_______________________________________________ >p2p-hackers mailing list >[EMAIL PROTECTED] >http://zgp.org/mailman/listinfo/p2p-hackers >_______________________________________________ >Here is a web page listing P2P Conferences: >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > _______________________________________________ p2p-hackers mailing list [EMAIL PROTECTED] http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org";>leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
signature.asc
Description: Digital signature
