[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
>
>


_______________________________________________
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

----- 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

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]