论 Web 系统中文文档的数字签名问题

2008-04-02 10:57:35来源：互联网阅读 ()

假设我们正在开发一个信息系统，这个系统拥有基于Web的用户界面，通过因特网我们可以使用这个界面。这个系统的用户必须能够发送文档到服务器。而且这些文档可以是不同格式的文件——Ms Word .doc 文件、Adobe Acrobat .PDF 文件、MS Excel .XLS 文件、JPEG和GIF图像、文本文件等等。为了追踪发送者的标记并且保证没有人在他们发送之后修改文档，系统有必要为用户提供数字签名发送的文件。让我们讨论一下在实现这种系统的过程中所产生的问题。

公匙加密方法

为了数字签名的需要，系统可以使用公匙加密算法，并且为了校验签名该文档的用户的标记，使用数字证书是最方便的。

使用自签发证书

证书可以是自签发的（self-signed ），或者是由认证机构颁发的。如果用户给自己颁发自签发的证书并且是用它们来签名文档，那就不能保证某些恶意用户不给自己颁发另一个名字的证书并且即使它是其他用户他也能签名文档。我们应该找到更好的方法来避免这个安全漏洞。

使用本地认证机构

负责系统维护的人——系统管理员——发行数字证书，这是有可能的。有两种方法可以做这件事，要么系统管理员为用户生成公匙和私匙，要么他们自己生成。在第一种情况下很有可能系统管理员会滥用职权。保留用户亲自生成他们的公匙和私匙的可能性，在他们发送公匙和有关他们标记的信息给系统管理员之后，系统管理员相应的颁发证书。这种设计的缺陷就是无法保证用户不伪造它们的标记信息。唯一可做的就是每个用户亲自提交他的公匙并且管理员在仔细检查他的ID证件后才给他颁发证书。这种方案要更加可行一些，但是实际上管理员充当了认证机构的角色，并且他仍然能够滥用他的证书颁发权利。

使用许可的认证机构

为了管理证书的问题，我们可以使用许可的认证机构的服务。系统中的每个用户可以从认证机构处购买证书，并且认证机构能够保证证书确实属于他所颁发的用户。对应于任何证书的私匙只有他的所有者才能使用，其他人不能。这就保证了当用户使用许可的认证机构颁发的证书签名文档时，确实是他的签名。只有在恶意用户获得其他用户的私匙时才有可能伪造，而用户是要为私匙承担个人责任的。

数字证书购买对于每个用户来说都有一定的费用，但是这是保证安全性的唯一可靠方法。通常除了证书之外，用户还会获得一个PFX文件，这个文件包含证书以及对应的私匙，私匙受密码保护。如果购买的结果是认证机构直接安装证书到客户端的Web浏览器上，那么用户就能够将它扩展成一个PFX文件（采用PKCS#12 的格式）并且从安装的那一刻起就可以用它来签名文档。我们假定拥有他们自己证书的用户也拥有受保护的密码存储（PFX文件），该密码存储保存着他们的私匙以及他们的证书。只在客户端的设备上签名是可能的

签名需要访问签名用户的私匙。因为每个用户的私匙只有他自己才能访问的道，所以有必要让签名在他的PC上进行。否则用户就不得不发送他的私匙给服务器，这就面临着一个潜在的安全危险——密码可能在途中被盗。在用户的PC上对Web应用中的文档进行签名不是一件容易的事情，因为在他的配置中客户端只有一个标准的Web浏览器——他没有为签名文档配置内建的功能。

在客户端的设备上数字签名的方法

我们将分析在客户端的PC上签名文档的可能方法。我们还要考虑将签名过程与负责接收签过名的文档的Web 应用集成。

使用外部签名工具

一种可能的方法就是使用户在他们的PC上安装某些专门设计的软件，但是这个有一定的困难。一个就是签名软件必须有支持用户使用的不同操作系统的不同版本。而且，对这种软件做支持是很笨重的，因为对它的任何修改都会迫使用户下载和安装新版本。与系统的Web接口集成也是一件困难的任务，并且如果软件安装不好的话，用户用起来就会有麻烦。用户不想在他们的PC上安装该软件还有一个可能原因就是安全性，而且如果他们不使用它们自己的设备，他们就无法使用外部签名工具。上述原因使得我们不得不寻找另外一条解决在客户端的设备上数字签名问题的方法。

使用客户端脚本技术

使用JavaScript或者其他客户端脚本技术，如ActiveX、 Macromedia Flash、.NET Windows Forms Controls 或者 Java-applets，是可行的。

JavaScript语言的问题就是他并不支持处理数字签名和证书所需的标准功能。除了他不能获得到安装在用户的Web浏览器上的证书的访问之外，他还不能访问外部的受保护的密码存储。而且JavaScript还不能访问本地的文件系统，从而不能读取应该被签名的文件。

Macromedia Flash 技术也不支持数字签名和证书，而且它不能访问本地的文件系统，而这是必须的，因为在签名之前，文件必须读取。从技术上来说，ActiveX controls 提供了一个解决方案，但是他们只能作用于Microsoft Windows 上的Internet Explorer。意外地，除了IE之外一些其他的浏览器也支持ActiveX controls，但是ActiveX技术不能在非微软的操作系统上运行。这就将用户限制在那些使用MS Windows和IE的用户群之中。

Windows Forms Controls 也只能作用于IE，并且它们还需要额外安装Microsoft .NET Framework。要求用户为了能够签名Web应用中的文档就使用IE、MS Windows 和.NET Framework，这是不能接受的。

最后一个方案就是使用Java applets。他们的优点是他们能够作用于所有知名的浏览器，也能运行在所有的操作系统上。缺点就是他们不能访问他们正在运行的设备上的本地文件系统，但是使用签名的Java applets可以克服这个缺陷。我们来看看Java applets究竟能给我们提供什么。

Java Applets

Java applets 可编译成Java 程序，这个程序可作为对象嵌入到HTML文档中，并且浏览该文档时可被Web浏览器执行。嵌入applet到Web页中与嵌入图片非常相似，不同的是applets 不仅仅是图形图像。他们是为他们的图形用户界面使用它们所在页面的整个矩形区域的程序。

Applets包含一个（或者几个）编译的Java 类，这些类保存在JAR文件中。与所有的Java程序一样，applets可被Java Virtual Machine (JVM) 执行，因此所有的Java激活的Web浏览器都有虚拟设备，这些虚拟设备要么内建，要么另外安装。当包含applet 的HTML 文档被打开时，浏览器装载它的虚拟设备并在其里面启动该applet。为了保证用户的安全性， applets不允许执行可能访问运行该applet的设备上的用户信息的操作。通常applet不能访问本地文件系统，这使得为数字签名的目的而使用该技术变得有点困难。