Private secured P2P Network

Question

I know the concept of building a simple P2P network without any server. My problems is with securing the network. The network should have some administrative nodes. So there are two kinds of nodes:

1. Nodes with privileges
2. Nodes without privileges

The first question is: Can I assign some nodes more rights than others, like the privileges to send a broadcast message?

How can I secure the network of modified nodes that are trying to get privileges?

I'm really interested in answers and resources than can help me. It is important to me to understand this, and I'm happy to add further information if anything is unclear.

Answer 1

You seem lost, and I used to do research in this area, so I'll take a shot. I feel this question is borderline off-topic, but I tend to error toward leaving things open.

See the P2P networks Chord, CAN, Tapestry, and Pastry for examples of P2P networks as well as psuedo-code. These works are all based off distributed hash tables (DHTs) and have been around for over 10 years now. Many of them have open source implementations you can use.

As for "privileged nodes", your question contradicts itself. You want a P2P network, but you also want nodes with more rights than others. By definition, your network is no longer P2P because peers are no longer equally privileged.

Your question points to trust within P2P networks - a problem that academics have focused on since the introduction of (DHTs). I feel that no satisfactory answer has been found yet that solves all problems in all cases. Here are a few approaches which will help you:

(1) Bitcoin addresses malicious users by forcing all users within their network do perform computationally intensive work. For any member to forge bitcoins that would need more computational power than everyone to prove they had done more work than everyone else.

(2) Give privileges based on reputation. You can calculate reputation in any number of ways. One simple example - for each transaction in your system (file sent, database look up, piece of work done), the requester sends a signed acknowledgement (using private/public keys) to the sender. Each peer can then present the accumulation of their signed acknowledgements to any other peer. Any peer who has accumulated N acknowledgements (you determine N) has more privileges.

(3) Own a central server that hands out privileges. This one is the simplest and you get to determine what trust means for you. You're handing it out.

That's the skinny version - good luck.

Answer 2

I'm guessing that the administrative nodes are different from normal nodes by being able to tell other nodes what to do (and the regular nodes should obey).
You have to give the admin nodes some kind of way to prove themselves that can be verified by other nodes but not forged by them (like a policeman's ID). The Most standard way I can think of is by using TLS certificates.
In (very) short, you create couples of files called key and certificate. The key is secret and belongs to one identity, and the certificate is public.
You create a CA certificate, and distribute it to all of your nodes.
Using that CA, you create "administrative node" certificates, one for each administrative node.
When issuing a command, an administrative node presents its certificate to the "regular" node. The regular node, using the CA certificate you provided beforehand, can make sure the administrative node is genuine (because the certificate was actually signed by the CA), and it's OK to do as it asks.

Pros:

• TLS/SSL is used by many other products to create a secure tunnel, preventing "man in the middle" attacks and impersonations
• There are ready-to-use libraries and sample projects for TLS/SSL in practically every language, from .net to C.
• There are revocation lists, to "cancel" certificates that have been stolen (although you'll have to find a way to distribute these)
• Certificate verification is offline - a node needs no external resources (except for the CA certificate) for verification

Cons:

• Since SSL/TLS is a widely-used system, there are many tools to exploit misconfigured / old clients / servers
• There are some exploits found in such libraries (e.g. "heartbleed"), so you might need to patch your software a lot.

This solution still requires some serious coding, but it's usually better to rely on an existing and proven system than to go around inventing your own.