对任何重要的 p2p 应用程序而言，对等机之间的安全通信都是一个核心要求。尽管安全的细节依赖于如何使用该应用程序和该应用程序将要保护什么，但通过使用现有技术，例如 ssl 实现强壮的、一般用途的安全通常是可能的。本月，todd sundsted 演示如何在 p2p 安全中使用 ssl（通过 jsse）。
　　上月我们考察了 p2p 应用程序中的信任角色。信任的等级是衡量我们确信程度的尺度，即我们正与之通信的人是否是我们以为的那个人，以及我们正访问的资源是否是我们以为的那些。我们也研究了用于在所有分布式应用程序，包括 p2p 应用程序中建立信任的三个构件：认证、授权和加密。
　　
　　现在我们将通过修改我们的简单 p2p 应用程序把上个月的课程应用到实践中。特别地，我们将用 x.509 证书扩展该应用以支持 p2p 认证和加密。我们将在将来的文章中处理授权问题。
　　
　　安全认证
　　一个应用程序的安全需求在很大程度上依赖于将如何使用该应用程序和该应用程序将要保护什么。不过，用现有技术实现强大的、一般用途的安全通常是可能的。认证就是一个很好的示例。
　　
　　当顾客想从 web 站点购买某个产品时，顾客和 web 站点都要进行认证。顾客通常是以提供名字和密码的方式来认证他自己。另一方面，web 站点通过交换一块签名数据和一个有效的 x.509 证书（作为 ssl 握手的一部分）来认证它自己。顾客的浏览器验证该证书并用所附的公用密钥验证签名数据。一旦双方都认证了，则交易就可以开始了。
　　
　　ssl 能用相同的机制处理服务器认证（就如在上面的示例中）和客户机认证。web 站点典型地对客户机认证不依赖 ssl ? 要求用户提供密码是较容易的。而 ssl 客户机和服务器认证对于透明认证是完美的，对等机 ? 如 p2p 应用程序中的对等机之间一定会发生透明认证。
　　
　　安全套接字层（secure sockets layer（ssl））
　　ssl 是一种安全协议，它为网络（例如因特网）的通信提供私密性。ssl 使应用程序在通信时不用担心被窃听和篡改。
　　
　　ssl 实际上是共同工作的两个协议：“ssl 记录协议”（ssl record protocol）和“ssl 握手协议”（ssl handshake protocol）。“ssl 记录协议”是两个协议中较低级别的协议，它为较高级别的协议，例如 ssl 握手协议对数据的变长的记录进行加密和解密。ssl 握手协议处理应用程序凭证的交换和验证。
　　
　　当一个应用程序（客户机）想和另一个应用程序（服务器）通信时，客户机打开一个与服务器相连接的套接字连接。然后，客户机和服务器对安全连接进行协商。作为协商的一部分，服务器向客户机作自我认证。客户机可以选择向服务器作或不作自我认证。一旦完成了认证并且建立了安全连接，则两个应用程序就可以安全地进行通信。请参阅参考资料以获得更多有关 ssl 的信息。
　　
　　按照惯例，我将把发起该通信的对等机看作客户机，另一个对等机则看作服务器，不管连接之后它们充当什么角色。
　　
　　在 java 应用程序如何使用 ssl
　　用于 java 应用程序的 ssl 由“java 安全套接字扩展”（java secure socket extension（jsse））提供。jsse 是最近发布的 jdk 1.4 beta 测试版的一个标准部件，但对早些版本的 java 平台它是作为一个扩展可用的。
　　
　　jsse 用 ssl 作它的安全套接字的底层机制。jsse 安全套接字除了支持透明认证和加密之外，其工作方式与常规套接字相似。因为它们看起来也与普通套接字（它们是类 java.net.socket 和类 java.net.serversocket 的子类）相似，所以使用 jsse 的多数代码不用修改。受到影响最多的代码是那些处理安全套接字工厂（secure socket factory）的创建和初始化的代码。
　　
　　如果您想在早于版本 1.4 的 java 平台中使用 jsse，那么您将不得不自己去下载并安装 jsse 扩展（请参阅参考资料）。安装说明非常简单，所以我不想在这里重复。
　　
　　名为 a 和 b 的两台对等机想安全地进行通信。 在我们简单的 p2p 应用程序的环境中，对等机 a 想查询对等机 b 上的一个资源。
　　
　　每个对等机都有包含其专用密钥的一个数据库（名为 keystore）和包含其公用密钥的证书。密码保护数据库的内容。该数据库还包含一个或多个来自被信任的对等机的自签名证书。
　　
　　对等机 a 发起这项事务，每台对等机相互认证，两台对等机协商采用的密码及其长度并建立一个安全通道。完成这些操作之后，每个对等机都知道它正在跟谁交谈并且知道通道是安全的。
　　
　　初始化
　　因为 jsse 和 ssl 的介绍对初始化代码有很大影响，所以让我们来考察对等机 a 中负责初始化的代码。
　　
　　清单 1. 安全初始化代码
　　// each peer has an identity that must be locally (but not globally)
　　// unique. this identity and its associated public and private keys
　　// are stored in a keystore and protected by a password. each
　　// peer also has a name that must be globally unique.
　　string stringidentity = null;
　　string stringpassword = null;
　　string stringname = null;
　　
　　// the code that prompts the user for his/her identity
　　// and password goes here. the user´s name is
　　// generated (if necessary) later.
　　
　　// create home directory. this is a very portable way
　　// to create a home directory, but it has its problems --
　　// the various flavors of microsoft windows put the directory
　　// in widely different locations in the directory hierarchy.
　　string stringhome = system.getproperty("user.home") + file.separator + "p2p";
　　file filehome = new file(stringhome);
　　if (filehome.exists() == false)
　　filehome.mkdirs();
　　
　　// create keystore. we must run an external process to create the
　　// keystore, because the security apis don´t expose enough
　　// functionality to do this inline. i haven´t tested this widely enough
　　// to know how portable this code is, but it works on everything i
　　// tried it on.
　　string stringkeystore = stringhome + file.separator + "keystore";
　　file filekeystore = new file(stringkeystore);
　　if (filekeystore.exists() == false)
　　{
　　system.out.println("creating keystore...");
　　byte [] arb = new byte [16];
　　securerandom securerandom = securerandom.getinstance("sha1prng");
　　securerandom.nextbytes(arb);
　　stringname = new string(base64.encode(arb));
　　string [] arstringcommand = new string []
　　{
　　system.getproperty("java.home") + file.separator + "bin" + file.separator + "keytool",
　　"-genkey",
　　"-alias", stringidentity,
　　"-keyalg", "rsa",
　　"-keysize", "1024",
　　"-dname", "cn=" + stringname,
　　"-keystore", stringhome + file.separator + "keystore",
　　"-keypass", stringpassword,
　　"-storetype", "jceks",
　　"-storepass", stringpassword
　　};
　　process process = runtime.getruntime().exec(arstringcommand);
　　process.waitfor();
　　inputstream inputstream2 = process.getinputstream();
　　ioutils.copy(inputstream2, system.out);
　　inputstream inputstream3 = process.geterrorstream();
　　ioutils.copy(inputstream3, system.out);
　　if (process.exitvalue() != 0)
　　system.exit(-1);
　　}
　　
　　// once the application has created/located the keystore, it
　　// opens it and creates a keystore instance from the data
　　// in it.
　　char [] archpassword = stringpassword.tochararray();
　　fileinputstream fileinputstream = new fileinputstream(stringhome + file.separator +
　　
　　"keystore");
　　keystore keystore = keystore.getinstance("jceks");
　　try
　　{
　　keystore.load(fileinputstream, archpassword);
　　}
　　catch (ioexception ioexception)
　　{
　　system.out.println("cannot load keystore. password may be wrong.");
　　system.exit(-3);
　　}
　　if (keystore.containsalias(stringidentity) == false)
　　{
　　system.out.println("cannot locate identity.");
　　system.exit(-2);
　　}
　　
　　// create key manager. the key manager holds this peer´s
　　// private key.
　　keymanagerfactory keymanagerfactory = keymanagerfactory.getinstance("sunx509");
　　keymanagerfactory.init(keystore, archpassword);
　　keymanager [] arkeymanager = keymanagerfactory.getkeymanagers();
　　
　　// create trust manager. the trust manager hold other peers´
　　// certificates.
　　trustmanagerfactory trustmanagerfactory = trustmanagerfactory.getinstance("sunx509");
　　trustmanagerfactory.init(keystore);
　　trustmanager [] artrustmanager = trus