在左邊的對等點 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 應用的標準操作過程。