 | Level: Introductory Todd Sundsted (todd-p2p@etcee.com), Chief Architect, PointFire, Inc.
19 Jun 2002 As soon as a P2P application grows to the point where it becomes interesting, the issues of trust and security appear on the horizon. Trust and security are seldom problems in small applications where every user knows every other user. Useful P2P applications seldom remain that small, however. This month, Java architect Todd Sundsted explores issues of trust and security in P2P applications, and introduces you to the tools that make trust possible in distributed applications.
Trust is an issue in every non-trivial distributed application -- peer-to-peer applications included. In a distributed application, the level of trust is the metric that measures how confident we are that we are communicating with whom we think we are, and that we are accessing the resources we think we are. It's easy to establish trust in small networks where every entity knows every other entity. In small networks entities are on a first-name basis, and trust can be maintained by the same social forces that operate in the real world. The difficulty establishing trust arises when a network application grows big enough that conventional social forces no longer fit the bill. The exact size of the network obviously depends on the application, but growing pains typically begin at the point at which any entity on the network no longer expects to interact only with known entities. At this point we immediately encounter two problems: peer authentication and authorization. First, entities can no longer assume that other entities are who they say they are. This is the authentication problem. Second, entities can no longer simply allow other entities indiscriminate access to the functionality they provide and the resources they manage. This is the authorization problem. Even before trust becomes an issue, we encounter the issue of privacy. Whether an interaction is between two entities that have never before met or between two long-standing acquaintances, the entities concerned must have a guarantee that their interaction is secure. There is one final aspect of trust that is not given the attention it deserves in many P2P applications. While peer authentication is clearly important, it is often just as important to authenticate shared resources -- content in particular. Without a guarantee on the integrity and identity of shared content, a P2P application runs the risk of introducing so many security holes that Microsoft Outlook -- never a good example of security -- will look like Fort Knox by comparison. Does trust matter?
Is trust really important in P2P applications? While many existing P2P applications seem to run fast and loose with the issue of trust, I strongly believe that trust is necessary in any distributed application -- P2P applications included. The open nature of many P2P applications does not preclude trust, nor does it reduce its importance. I am sure many of you are familiar with the cartoon captioned, "On the Internet, no one knows you're a dog" (Peter Steiner, The New Yorker magazine). The fact that this saying rings true underlines the importance of establishing trust as the first step in an interaction between entities. To encourage the use of certain types of P2P applications (e-commerce applications being an excellent example) across a naturally anonymous medium such as the Internet, the entities involved must be able to trust each other. The veil of anonymity must be pulled aside, and the other party shown to be a dog (or at least a dog without a valid credit card). Trust is just as important when it comes to the management and distribution of content -- the central activity of many P2P applications. As long as the content consists of relatively innocuous audio and video files exchanged without warranty or cost, trust isn't important -- you get what you pay for. However, consider a fee-based system for media or application content distribution. If you shell out cash, you want the goods -- "let the buyer beware" isn't good enough. Trust can become a serious issue for P2P applications that distribute processing work to distributed computing nodes and then collect the results. Witness the recent cheating by members of one team in the Seti@Home distributed computing application (see Resources). To ensure trust, a network application and its infrastructure must make a number of guarantees. First, the connection between entities must be secure. The infrastructure must also make it possible to either accurately identify the other entity or at least conclusively determine that identification is not possible. Finally, the resources managed or exchanged via the application must be subject to the same scrutiny.
The elements of secure systems
While the P2P domain might seem exciting and new, the elements of secure computing in a distributed environment remain the same. Trust is established by a combination of the three standard elements:
-
Authentication. The process of determining whether or not some entity is in fact who or what that entity declares itself to be. In practical terms, authentication comes in two forms. The first form involves peers authenticating themselves to other peers over a network such as the Internet. The second form involves users of a P2P application authenticating themselves to the application. In some P2P applications, these two forms are the same.
-
Authorization. The process of giving an authenticated entity permission to do some action or access some resource. In a P2P application, a peer might be authenticated to access some subset of the resources on another peer.
-
Encryption. The process of converting readily understandable information (plaintext) into a form difficult to understand by unauthorized individuals and systems (ciphertext). Decryption is the reverse of this process.
In a P2P application, encryption can play many roles. One obvious use of encryption is to protect the information that flows between peers on an unsecured network such as the Internet. This, combined with secure authentication of each peer, ensures that the exchanged data won't be eavesdropped upon during communication. If the information is digitally signed or a MAC (Message Authentication Code) is added to the information, both parties can be sure that the information wasn't modified, as well.
As you'll see in the examples below, these three elements are combined to create a secure distributed application.
Security in practice
To better understand how authentication, authorization, and encryption help establish trust between peers in a P2P application, let's consider the example shown in Figure 1. Pay close attention to the roles authentication, authorization, and encryption play.
Figure 1. Sequence of operations between peer A and peer B
Peer A on the left desires to initiate secure communication with peer B on the right.
- Peer A connects to peer B and announces its identity.
- Peer B asks peer A to authenticate itself. Authentication can occur in many ways. Both peer A and peer B can use a shared key to exchange a secret message, or peer A can use the private key that corresponds to a public key that peer B holds to perform the same operation.
- Peer A asks peer B to authenticate itself.
- Peer B authorizes peer A to access certain resources by assigning privileges to peer A.
- Before further communication takes place, the two peers can arrange to encrypt the channel connection between them.
If peers A and B haven't met, they must rely on a trusted third party, peer C, to arrange an introduction, as shown in Figure 2.
Figure 2. Peer C introduces peer A and peer B
Here is the sequence of operations for the introduction:
- Peer A initiates secure communication with peer C as described above. Peer C gives peer A the information necessary to authenticate peer B. This may include peer B's public key, a shared key, or a token or certificate that enables the communication.
- Peer B initiates secure communication with peer C and performs the same operations.
- Once this information has been transferred, peer A may initiate communication with peer B.
There are other mechanisms for establishing secure communication between two peers. The method described above follows the pattern used by standard security layers such as SSL (see Resources).
How safe is the content?
If you trust an entity you might be tempted to trust the content it provides. In some cases, this assumption is reasonable. If the content being accessed contains information about the entity being the origin of the information, or if it contains the information from a service that the entity provides, the fact that you trust the entity is enough justification to trust the content you get from the entity. If, on the other hand, the entity is not the origin of the content, but is acting as a cache or intermediary for the content, it might be wise to validate the content. Certain kinds of content, such as active content (applets), are dangerous enough that validation should be mandatory. There are many ways to validate content, including simple checksums, encryption and watermarking. I will describe a mechanism based on digital signatures.
- Peer A establishes a secure connection with peer B as illustrated in Figure 1.
- After it establishes the channel, peer A requests a piece of content from peer B. If peer B originates the content, it digitally signs the content before transferring it. If peer B is merely distributing content created elsewhere, the content is already signed.
- After peer A receives the content, it verifies the digital signature attached to the content.
The verification of many types of content is already standard operating procedure for many mainstream applications. It must become standard operating procedure for P2P applications as well.
Conclusion
The use of authentication, authorization, and encryption establishes trust in P2P applications. Without a foundation of trust, many types of interesting applications (such as e-commerce) won't take hold on top of the P2P infrastructure. Next month, I will demonstrate how to extend the simple P2P architecture I described in the last installment to include these elements of security.
Resources
About the author | | | Todd Sundsted has been writing programs since computers became available in desktop models. Though originally interested in building distributed applications in C++, Todd moved on to the Java programming language when it became the obvious choice for that sort of thing. In addition to writing, Todd is co-founder and chief architect of PointFire, Inc. Contact Todd at todd-p2p@etcee.com. |
Rate this page
| |
