在左边的对等点 A 希望和在右边的对等点 B 建立安全的通信:对等点 A 连接到对等点 B 并通告自己的身份。对等点 B 要求对等点 A 认证它自己。认证可以通过许多途径。如对等点 A 和对等点 B 都可以用一个共享密钥交换秘密的讯息,或对等点 A 可以使用对应于对等点 B 持有的公用密匙的私用密钥来完成同样的操作。
对等点 A 要求对等点 B 认证它自己。对等点 B 通过分配给对等点 A 特权的方式来授权对等点 A 访问某些资源。在进一步的通信发生之前,这两个对等点可以协商加密它们之间的通道连接。假如对等点 A 和对等点 B 没有相遇过,那么它们就必须依靠一个可以信任的第三方,对等点 C,来安排一个介绍,如图 2 所示:
图 2. 对等点 C 为对等点 A 和对等点 B 作介绍
这是介绍操作的顺序: 如上所述,对等点 A 开始与对等点 C 的安全通信。对等点 C 给予对等点 A 认证对等点 B 的必要信息。这可能包括对等点 B 的公用密匙,共享密钥或者一个可以启动通信的令牌或证书。对等点 B 开始与对等点 C 的安全通信并执行同样的操作。一旦该信息被传送完成,对等点 A 就可以开始与对等点 B 的通信了。还有别的机制也可以在两个对等点间建立起安全通信。上述方法遵循的是标准安全层次(如 SSL)所使用的模式。
另一方面,假如实体不是内容的来源,而是作为内容的一个缓存或中转站,比较明智的做法就是验证内容。某些种类的内容,比如活动内容(applets),就非常危险以至于验证是强制要执行的。有许多方法可以验证内容,包括简单的校验和,加密和水印技术。下面我将描述一个基于数字签名的机制。如图 1 所示,对等点 A 和对等点 B 建立了一个安全的连接。
在它建立好通道后,对等点 A 向对等点 B 要求一个内容。假如对等点 B 创建了该内容,它就会在传送该内容之前为其数字签名。假如对等点 B 只是发布在别处创建的内容,那么该内容是已经被签名过的。
在对等点 A 收到内容后,它将验证附在内容上的数字签名。对许多主流的应用而言,验证各种类型的内容已经是标准的操作过程。这同样也将成为 P2P 应用的标准操作过程。