[p2p-hackers] P2P Authentication
v100 at braginskaya.net
v100 at braginskaya.net
Wed Oct 26 22:35:47 UTC 2005
Frank Moore:
> I'm working on a hybrid p2p network where there is a central server and
> lots of clients (peers). I need a way for clients to authenticate
> themselves when they join the network. I've looked at doing a challenge
> response type thing using Challenge Handshake Authentication Protocol
> (CHAP) but that means putting a shared secret key in each client and
> the server.
How does a client qualify? What makes it eligible to participate? - You can give each one that does qualify (for whatever reasons) a unique number, a ticket. That's not a cryptographic key, but certainly you would want to make ticket generation impossible for adversaries.
> It seems entirely possible that someone could reverse engineer the
> client executable to get hold of the shared secret key and then write a
> 'rogue' client (or server) to subvert the network?
The attacker could create clones of the client he compromised, if every client has a unique id (or at least unique tickets). At least you could detect who gave up his identity. If tickets have limited lifetime, clients have to re-authenticate regularly. If your authentication is "out-of-band", you could be able to drop a few bad guys.
Btw, have you looked at Kerberos?
> Is there a standard (or any) way of authenticating peers in p2p
> networks that doesn't require secret shared keys?
That does depend on the property you want to authenticate, and on the nature of the principals you want to authenticate. Do you want to do age verification? Or do you want to make sure to deal with a human being? Or with a friend? In many cases you would need cryptographic keys, and a unique shared secret key between the server and each client is probably the easiest way to go.
Cheers,
Harald
More information about the P2p-hackers
mailing list