[p2p-hackers] P2P Authentication

Kerry Bonin kerry at vscape.com
Thu Oct 27 15:22:55 UTC 2005


In a p2p PKI, attacking the CA[s] does NOT take down the network, it 
only prevents new users from joining during the attack! 

There is also a simple way to harden against this - never publish the CA 
IPs to the network, only publish (D[s]HT) a list of current proxies that 
can access the CAs.  Attacking the CAs then means attacking the proxies, 
and any known CA addresses.  During an attack, it is possible to 
republish the proxy list.  If your attackers are following the CA proxy 
list then you have a larger problem, but that can also be mitigated by 
exponentially increasing the active proxy list, which is simple if this 
proxy service is part of the peer protocol suite.  This may expose more 
CA IPs via compromised nodes, but using a second layer of proxies 
selected by uptime or other trust metrics can further limit.  It is also 
possible to use "honey pot" strategies to identify which proxies are 
leaking CA IPs.  This approach, plus using a connect protocol that 
includes DDOS resistance like client puzzles, the attacker has quite a 
hard time taking down the CA's.  There are more tricks, these are just 
some of my favorite...

Alen Peacock wrote:

>On 10/27/05, Kerry Bonin <kerry at vscape.com> wrote:
>  
>
>>I think some people are put off by the size and
>>complexity of the libraries involved,
>>    
>>
>
>  Personally, I'm put off by the centralization.  I'm not really
>concerned about the library size or complexity of PKI,.  In fact, my
>experience indicates that implementing centralized CAs is a good deal
>less complex than trying to distribute identity verification
>throughout the system with no centralization.
>
>  Completely decentralized p2p applications have the advantage of
>being especially resilient to DoS and other attacks on centrality. 
>Introducing centralized components negates this advantage.  In the
>case of using CAs in a p2p app, the entire network can be disabled by
>attacking the CAs.
>
>  p2p networks pose an interesting challenge because you have to
>design for the fact that malicious or misbehaving clients *will* be
>present.  Since there is no single entity or known group of entities
>controlling the nodes (as in typical distributed applications), there
>is no way to enforce adherence to protocols other than with the
>protocols themselves.  This may sound idealistic and naive, perhaps
>justly so, but the further away from protocols that require
>centralized architectures we get, the better (IMHO, of course).
>
>  Alen
>_______________________________________________
>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
>
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zgp.org/pipermail/p2p-hackers/attachments/20051027/e77b80d2/attachment.html


More information about the P2p-hackers mailing list