[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