Peer-to-Peer Computing: network trust and security

Once a P2P application reaches a high level of interest, trust and security problems emerge. Trust and security are rarely a problem in small applications that users know each other. However, useful P2P applications rarely maintain such a small scale. This article will discuss the trust and security issues in P2P applications, and introduce you to tools that make trust in distributed applications possible.

Trust is a problem in every distributed application with a certain scale (including peer-to-peer applications. In a distributed application, the level of trust is the measure of our degree of confidence, that is, whether the person we are communicating with is the one we think, and whether the resources we are accessing are what we think.

It is easy to build trust in a small network where entities know each other. In small networks, entities are built on mutual familiarity, and trust can be maintained by the same social forces that operate in the real world. When a network application expands to the conventional social forces and does not meet the requirements, the difficulty of building trust will increase. The exact size of the network obviously depends on the application. However, when no entity in the network only expects to interact with the recognized entity, the problem occurs in the above expansion process.

Now we have two problems: Peer-to-Peer authentication and authorization. First, entities cannot assume that other entities are what they claim. This is an authentication issue. Second, entities cannot simply allow other entities to access the functions they provide and the resources they manage without selecting them. This is an authorization issue.

We even encountered the issue of confidentiality before trust became a problem. Whether an interaction is between two entities that have never been met before, or between two familiar entities, the related entities must ensure that their interaction is safe.

Concerning trust, in many P2P applications, there is still a decisive aspect that has not been given due attention. Peer-to-Peer authentication is undoubtedly important, but it is usually equally important to authenticate shared resources-especially content. Without the guarantee of integrity and identity of shared content, a P2P application may introduce many security vulnerabilities, so Microsoft Outlook-Never a good example of security-in comparison, it will be like Fort Knox.

Is trust really important in P2P applications? Although many existing P2P applications seem to run like a fly, but do not take the trust seriously, I still insist that trust in any distributed application is necessary-including P2P applications. The openness of many P2P applications does not reject Trust, nor even weaken its importance.

"No one knows you are a dog on the Internet" (Peter Steiner, The New Yorker magazine). I'm sure many of you are familiar with the cartoon title. The facts reflected in this statement accurately emphasize the importance of building trust as the first step in the interaction between entities. To promote the use of certain types of P2P applications (electronic transaction applications are an excellent example) on a natural and anonymous media (such as the Internet), entities involved must be able to trust each other. The veil of anonymity must be uncovered so that the other party can expose itself as a dog (or at least a dog without a valid credit card ).

When it comes to content management and publishing-this is the main activity of many P2P applications and trust is equally important. As long as it is composed of relatively unimportant audio and video files (their exchange requires no authorization or cost, trust is not important-you will get anything you want to pay. However, this is not the case in a paid media or application content publishing system. If you pay, you must get the goods-"exercise customer caution" is not good enough.

For P2P applications that distribute processing work to distributed computing nodes and then collect results, trust can become a serious problem. Evidence is the spoofing behavior of a Member in a group recently in the SETI @ Home distributed application.

To ensure trust, a network application and its infrastructure must be guaranteed. First, the connection between entities must be secure. The infrastructure must also make the following conditions possible: the ability to accurately identify other entities, or at least be sure to assert that such recognition is impossible. Finally, resources managed or exchanged through applications must meet the same requirements.

Although the P2P field may seem exciting and brand new, the elements of Secure Computing in a distributed environment are still the same. Trust is built by integrating the following three standard elements:

1. Authentication

Determines whether or not certain entities are actually people or things they claim. In practice, there are two authentication methods. The first form involves authenticating peers in a network (such as the Internet) to other peers. In the second form, users of a P2P application authenticate themselves to the application. In some P2P applications, the two are the same thing.

2. Authorization

The process of authorizing an authenticated entity to perform certain behaviors or access certain resources. In a P2P application, a peer may be authenticated to only access some resources of another peer.

3. Encryption

The process of converting understandable information (plaintext) into a form (ciphertext) that is hard to understand for unauthorized individuals and systems. Decryption is the inverse process of this process. In a P2P application, encryption can play many roles. An obvious purpose of encryption is to protect information flowing between peers in an insecure network (such as the Internet. This is combined with the security authentication of each peer to ensure that the exchanged data is not eavesdropped in communication. If the message is digitally signed or a MAC (message authentication code) is added to the message, both parties can determine that the message has not been modified.

In the following example, you will see that these three elements are combined to create a secure distributed application.

Security in actual use

In order to better understand authentication, authorization and encryption help to build trust between peers in a P2P application. Let's take a look at the example in section 1. Pay special attention to the role of authentication, authorization, and encryption.

Figure 1. Operation Sequence between peer A and peer B

Peer A on the left wants to establish secure communication with peer B on the right: Peer A connects to peer B and notifies itself of its identity. Peer B requires Peer A to authenticate itself. Authentication can be performed in many ways. For example, both peer A and peer B can exchange private messages with a shared key, or Peer A can use the private key corresponding to the public key held by peer B to perform the same operation.

Peer A requires peer B to authenticate itself. Peer B authorizes Peer A to access certain resources by assigning the privilege to peer. Before further communication, the two peers can negotiate to encrypt the channel connection between them. If Peer A and peer B have never met each other, they must rely on a trusted third party, peer C, to arrange an introduction, as shown in Figure 2:

Figure 2. Introduction of peer point C as peer point A and peer point B

This is the sequence of operations:

As mentioned above, Peer A starts secure communication with peer C. Peer point C provides necessary information for peer point A to authenticate peer point B. This may include the public key, shared key, or a token or certificate that can start communication for peer B. Peer B starts secure communication with peer C and performs the same operations. Once this information is transmitted, Peer A can start to communicate with peer B. Other mechanisms can also be used to establish secure communication between two peers. The preceding method follows the mode used by standard security levels (such as SSL.

If you trust an entity, you may naturally trust the content it provides. In some cases, this assumption is reasonable. If the accessed content contains some information that is related to the entity of the information source or contains information from the service provided by the source entity, therefore, you trust this entity to trust the content you have obtained from this entity.

On the other hand, if an object is not a source of content, but a cache or transfer station of content, it is wise to verify the content. Some types of content, such as activity content (applets), are so dangerous that verification is enforced. There are many ways to verify the content, including simple checksum, encryption, and watermarking techniques. The following describes a digital signature-based mechanism. As shown in figure 1, Peer A and peer B establish a secure connection.

After the channel is established, Peer A requests a content from peer B. If peer B creates the content, it will sign the content before it is sent. If peer B only publishes the content created elsewhere, the content has been signed.

After receiving the content, Peer A verifies the digital signature attached to the content. For many mainstream applications, verifying various types of content is already a standard operation process. This will also become a standard operation process for P2P applications.