[p2p-hackers] P2P Authentication

[Kerry Bonin]

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
> p2p-hackers at zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
> _______________________________________________
> Here is a web page listing P2P Conferences:
> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
>
>