[p2p-hackers] P2P Authentication

[Alen Peacock]

Introducing a certificate authority not only requires that every
participant in the network have complete trust in the authority, but
creates a central choke point for congestion, failure, and attack.

Here's a rough sketch of an alternative I've been thinking about. 
Please poke holes if you see them:

Allow each node to choose its own identity in the form of a random,
locally generated public/private key pair.  A node's ID is the public
key, or the hash of the public key.  Each node needs to maintain trust
records of other nodes it interacts with.

In order for trust to work, it has to be intractable for imposters to
hijack a node's identity.  To accomplish this, the sender issues a
challenge for every operation (or session), encoded using the public
key of the receiver.  The challenge contains the sender's public key
concatenated with some random data.  The receiver decodes the
challenge with their own private key, and verifies that it contains
the sender's public key.  If it does, the sender responds with the
decoded challenge.  If it doesn't, the sender ignores the node (to
prevent relay/man-in-the-middle attacks) and decreases trust in
communication coming from that node.  The sender likewise verifies the
receiver's identity by issuing the same type of challenge in the
opposite direction.

In other words, given a node 'A', a node 'B', and an attacker 'C',
each with a public/private key pair (Au/Ar, Bu/Br, etc):

A ---- challenge Cb = enc(Au+rand, Bu) -------------------> B

A <--- response Ra = dec(Cb, Br) iff Ra contains Au ------- B
A <--- challenge Ca = enc(Bu+rand, Au) -------------------- B

A ---- response Rb = dec(Ca, Ar) iff Rb contains Bu ------> B

A <--------------- data, signed with Br ------------------- B

Now, attacker C cannot pose as A when talking with B, nor as node B
when talking with A (it wouldn't be able to form the correct response
to the challenges).  C can still proxy requests, but cannot tamper
with the challenge/response or data without being detected. The only
way for C to be a successful imposter is if it had possession of A or
B's private keys.  This is the identity guarantee required for trust
to work.  Anyone see how to compromise this guarantee?

If you get a rogue or malicious node in the network, you can use the
trust system to minimize its effectiveness.

I don't think this scheme is new, and it is a tad inefficient if done
for every operation.  Using it to set up some type of secure session
would be a useful improvement.  You may want to consult some of the
literature on trust systems.  The GNUnet project in particular has a
nice paper on excess-based economics and trust, but the literature has
many other examples as well.  Reputations are another variant.

  Alen


On 10/25/05, Frank Moore <francis.moore at rawflow.com > wrote:
>  Hi,
>
> I have the following problem:
>
> 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.
>
> 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?
>
> Is there a standard (or any) way of authenticating peers in p2p
> networks that doesn't require secret shared keys?
>
> Cheers,
> F.