Java2的安全新特性下的Applet数字签名具体实现方法（转载）

喜欢ヅ旅行 2022-08-06 05:26 123阅读 0赞

### 本文原址 ： ###

### [http://blog.ccidnet.com/blog-htm-do-showone-uid-35931-type-blog-itemid-87550.html][http_blog.ccidnet.com_blog-htm-do-showone-uid-35931-type-blog-itemid-87550.html] ###

### Java2的安全新特性下的Applet数字签名具体实现方法 ###

<table> 
 <tbody> 
 <tr> 
 <td> 自从Java技术开始应用以来，人们对Java平台的安全性以及由于部署Java技术所引发的安全问题给予了极大的关注。特别是在1998年11月Java2发布后，Java的安全体系结构发生了根本的改进，对于终端用户而言，它可以保护文件和私人数据不被恶意的程序或病毒感染和破坏，鉴别代码提供者的身份。对于开发者而言，通过使用API方法，能够将安全性功能集成到应用程序中，因为API的体系结构能够定义和集成对特定的资源的使用权限、加密、安全性管理、策略管理，并提供了一些类来管理公钥／密钥对及信任用户群的公钥证书。同时系统管理员、开发者和用户可以使用它提供的工具管理钥匙库，在JAR文件中生成数字签名、签名的完整性检测、创建和修改策略文件。按照Java设计者的观点，Java安全包括2个方面的内容，首先将Java作为一种安全的平台提供给用户，在此平台上，可安全地运行Java程序；其次提供用Java编程语言实现的安全工具和服务，它使得诸如企业界这样一些对安全非常敏感的领域也可应用Java技术。本文将就这二个方面介绍Java2的安全性新特性以及该新特性下的Applet数字签名的具体实现方法。　 　Java2采用了如图1所示的新的安全体系结构，并基于这种安全体系结构提供了很多新特性。 图1 JDK1．2安全模式 1．1　密纹访问控制 　　这种能力从一开始就在JDK中存在。但要使用它，应用程序的编写者不得不做大量的编程工作例如，创建SecurityManager和Classloader类的子类并使其用户化　。HotJava1．0就是一个这样的应用程序，它允许浏览器用户在几个不同的安全等级上进行选择。然而，这种编程涉及非常敏感的安全问题，它要求程序员对计算机安全有精深的理解和纯熟的技巧。新的安全体系结构将使这些变得简单而安全。 1．2　易于配置的安全策略 　　与上述情况相似，这种能力在原来的JDK中也是存在的，但是不便于使用，而且编写安全代码也不是简单明了的事情。于是，人们期望能够允许应用程序的编写者和用户能够不通过编程来设置安全策略。 1．3　便于扩展的访问控制结构 　　一直到JDK1．1为止，为了创建1个新的访问许可，你必须在SecurityManager类中增加1个新的check方法。新的安全体系结构则允许设置各类访问许可（每个都表示对1个系统资源的访问），并能对所有正确访问许可（包括未定义的许可）进行自动处理。 1．4　安全检查扩展至所有Java程序 　　那种所有本地代码是可信的内置概念将不复存在，取而代之的将是本地代码（例如非系统代码，安装在本地的应用程序包等）服从于与Applet相同的安全控制，但是可以声明对本地代码的政策是最宽容的，从而使这些代码可被认为是完全可信而有效地运行。上述原则也可应用于已签字的Applet和任何Java应用程序。 2　Java2安全体系的概念及运行机制 2．1　保护域 　　Java2安全体系结构中的一个基本的概念是保护域（Protected Domain）。1个域可通过对象集来划分范围，这些对象当前可由1个主体直接访问。而主体是在计算机系统中被授予许可的实体。JDK1．0所利用的沙箱就是一个有着固定边界的保护域实例。保护域的概念是一种在保护单元间起着分组和隔离作用的便利机制。例如，我们可以将保护域分开以避免它们之间的直接交互作用，于是，任何允许的交互作用必须通过可信系统代码或被有关的域所明确允许。 　　保护域通常分为明确的2个类别，系统域和应用程序域。所有被保护的外部资源如：文件系统、网络设施以及屏幕和键盘等仅能通过系统域来访问。图2中显示了1个Java应用环境的域的组成。从概念上讲，1个域包括1组类，这些类的实例被授予相同的一组许可。保护域是由现行策略所确定的。Java应用程序环境保持了来自代码（类和实例）到它们的保护域然后再到它们的许可的映射，如图3所示。1个线程的执行可能完全发生在1个单一的保护域中，也可能涉及1个应用程序域或是系统域。例如：1个打印消息的应用程序将不得不与系统域发生交互作用，因为系统域是唯一对输出流的访问点。在此种情况下的任何时候，应用程序域都不能通过调用系统域获得除打印消息外的任何额外许可，否则将是一个严重的安全性隐患。在相反的情形下，1个系统域从1个应用程序域中调用1个方法，如当1个AWT系统域调用1个Applet的绘画方法来显示这个Applet时，有效访问权限与应用程序域所允许的当前权限在任何时候都相同，这一点也是同样至关重要的。换句话说，一个具有较低权限的域不能通过调用一个更高权限的域，或被一个更高权限的域所调用来获得额外的许可。上述有关1个线程涉及2个保护域的讨论自然地归纳为1个遍历多重保护域的线程，计算许可的一个简单而谨慎的经验做法是： 图2 Java应用环境的域的组成 图3 类→保护域→权限的映射 　　（1）一个执行线程的许可集可被认为是由该线程所遍历的所有保护域的许可的交集。 　　（2）当1条代码调用doPrivileged方法时，执行线程的许可集被认为是包括所有代码的保护域以及由它直接或间接调用的保护域的权限。即通过doPrivileged方法可使1条可信代码能临时访问更多的资源，这在某些情况下是必要的。例如，1个应用程序可能不被允许直接访问包含字体的文件，但是，显示文本的系统实用程序必须代表用户获得那些字体。 　　在执行期间，当请求访问1个关键系统资源（如文件I／O和网络I／O）或者API方法需要执行1个敏感的操作时，例如读1个文件，资源处理代码直接或间接地调用1个特殊的称为访问控制（AccessController）类的方法，访问控制类通过检查调用栈来作出决定是否准予该请求或操作发生。在调用栈中是执行该操作需要调用的一些类的成员方法，因为每个类都属于一些保护域，每个保护域都建立了一些策略，因此在调用栈的每个方法都被分配了1组权限。访问控制类由栈顶开始，自顶向下检查每个方法，看是否方法被所在的保护域所允许，如果发现一个方法权限没有得到允许，访问控制类就抛出安全性异常；反之，如果到达栈底仍未抛出异常，即说明调用栈中的所有方法均满足保护域的权限要求，访问控制允许操作发生。其中有一种特殊的情况，即当访问控制遍历调用栈时，将查找是否存在优先域（Privileged Domain），如果存在优先域，即使没有到达栈底，访问控制也将停止遍历调用栈并允许操作发生。虽然新的安全机制初看上去增加了许多调用API方法的消耗，但是Java2确实使用了一些技术去加速检查权限的过程，例如访问控制将过滤掉重复的域并在遇到第一个优先域时停止检查，这说明额外的操作将是一个本地的方法调用，SUN的基准测试显示了新的安全检查是相当快的。 　　最后，每个域包括系统或应用程序域可以对其域边界内的内部资源进行附加保护。例如，一个银行系统的应用程序可能需要支持并保护其内部的一些概念，如查帐、存款和取款等。由于此种保护的语义不像那些可预测的语义可以被JDK预置，因而，在这个层次上的保护最好留给系统或应用程序开发员来做。 　　目前，1个域单独地由1个代码来源（CodeSource）鉴别，它封装了在该域中运行的代码的2个特性：代码基址和公共密钥证书集，公共密钥对应于在该域中为所有代码签字的私有密钥。因而，由相同的密钥签字和来自相同URL的类被放在同一个域中。1个域还包含在该域中授予代码的许可，它是由现行安全策略所决定的。 2．2　证书、钥匙库及其相关工具 　　在Java2的安全体系下，1个Applet开发和运行的过程如下： 　　在代码的分发端： 　　（1）开发Java源程序并对其进行编译。 　　（2）用JAR工具对类文件和资源文件进行封装。 　　（3）用keytool创建公钥和密钥，生成X。509V1签名证书，输出证书。 　　（4）通过jarsigner工具用生成的密钥对JAR文件进行数字签名。 　　在代码的接收端： 　　（1）用keytool输入证书视其为可信任。 　　（2）用policytool创建和修改安全性策略配置文件，授权请求的访问权限。 　　（3）从网络取得字节码，用公钥验证数字签名证书和文档代码的完整性。 　　（4）验证字节码的合法性，根据策略文件分配相应权限。 　　（5）执行代码，完成后被垃圾回收器回收内存。 　　在用公钥验证数字签名证书之前，接收方需要确认公钥自身的可靠性，因此通常情况是提供一个包含公钥的证书而不是公钥自身。1个证书包括： 　　（1）1个公钥。 　　（2）1个唯一的名字实体（个人或公司），它是证书的所有者，包含用户名字、公司、组织、城市、地址、国家代码、省份等信息。 　　（3）数字签名：1个证书被1个分发者的实体签名，保证证书确实包含另1个实体（所有者）的公钥。 　　（4）分发者的标识名信息。 　　对于接收者可以用分发者的公钥来验证他的数字签名，检查证书的合法性。然而公钥可能包含在另一个证书中，而数字签名需要用另一个证书的分发者的公钥来验证，这样嵌套下去，直到一个公钥被接收者确认是可信任的。如果接收者不能建立信任链，例如：1个分发者的证书不合法，那么可以用keytool－import命令来计算指纹，每个指纹是一个相关的短数字，它唯一可靠地标识证书（指纹是一个用信息摘要算法计算的证书信息的哈希值），接收者可以呼叫证书的所有者，并比较发出的证书和接收证书的指纹，如果指纹相同，则证书不同。因此能够保证证书在传递的过程中未被修改。另一个潜在的问题是发送者身份的标识，有时一个证书是自签名的，即使用证书中的公钥相对应的密钥进行签名，如果接收者已经知道或信任发送者，那么就没有任何问题。否则发送者需要从一个可信任的第3方得到证书，这个第3方通常是一个证书的授权机构CA，那么首先发送一个自签名的证书签名请求CSR给CA，由CA验证CSR的签名及发送CSR的身份、许可证以及其它信息。然后CA通过一个用CA的密钥进行签名的证书，授权CSR的发送者作为公钥的所有者，任何人只要信任CA的公钥，都可以用之来验证证书的签名，很多情况下CA自身有一个来自更高一级的CA的证书，从而构成证书链。所有信任的证书实体都可以作为信任证书被引入钥匙库，每个证书中的公钥都可以用来验证用相应的密钥生成的签名。 　　发送者在发送签名的代码和文档时还相应提供包含与签名的密钥相应的公钥证书。用keytool－export命令或API函数可以从钥匙库中输出证书到文件中，然后将这个文件发送给需要的接收者，由接收者用keytool－import命令或API函数将其引入钥匙库中。如果用jarsigner工具为JAR文件生成签名，他会从钥匙库中取出证书及证书链，并和签名一起放入JAR文件。 　　密钥和相应的公钥证书存放在一个由口令保护的数据库中，称为钥匙库（keystore）。1个钥匙库包含2种类型的条目，可信任的证书条目，钥匙和证书条目，每个都包含1个密钥和与密钥相应的公钥证书，在钥匙库中的每个条目都有1个别名进行标识。1个钥匙库的所有者在钥匙库中可以有多个钥匙，可以通过不同的别名进行访问，每个别名通常是用钥匙库的所有者使用的钥匙的特定角色来命名，别名也可以标识钥匙的目的。例如：SignPersonalEmail可以被用来标识1个钥匙库的条目，它的密钥用于签名个人邮件，SignJarFiles用于标识1个条目，它的密钥用于签名JAR文件。 3　Applet的数字签名认证实现的具体方法、步骤 3．1 结合我自己开发的基于JAVA2的Applet 我的项目是使用APPLET制作一个实时消息队列监控程序，由于涉及到了本地资源，对APPLET一定要进行数字签名和认证。我使用的环境是WINDOWS2000，应用服务器是WEBLOGIC6.0，开发环境是JBUILDER4.0。之前我提醒大家一定要注意服务器端和客户端的概念。那些文件应该在服务器端，那些文件应该在客户端。 &nbsp; 首先在客户端使用JRE1.3.0_01（JAVA运行环境1.3.0.1版本）以取代IE的JVM(JAVA虚拟机)，可以到<a href="http://www.java.sun.com/" rel="nofollow">www.JAVA.SUN.COM</a>网站上去下载，下载好了先在客户端安装好，安装过程非常简单。 &nbsp; 在服务器端的调用APPLET的HTML文件中也需要将它包含进来，以便没有事先安装JRE的客户端下载，具体的写法，请接着往下看； 具体步骤如下: &nbsp; 服务器端： &nbsp; 1．将程序需要用到的各种包文件全部解压(我这儿要用到WEBLOGIC的JMS包使用命令jar xf weblogicc.jar)，然后使用JDK的打包命令将编译好的监控程序.class和刚才解压的包一起打包到一个包中。(前提我已经将监控程序和解开的包都放在同一个目录下了)，都是dos状态下的命令，具体命令见jdk1.3(1.2)的bin目录下， 命令如下： jar cvf monitor.jar *.class 此命令生成一个名为monitor.jar的包 2．为刚才创建的包文件（monitor.jar）创建keystore和keys。其中 keystore将用来存放密匙(private keys)和公共钥匙的认证，alias别名这儿取为monitor。 命令如下： keytool -genkey -keystore monitor.keystore –alias monitor &nbsp; 此命令生成了一个名为monitor.keystore的keystore文件， 接着这条命令，系统会问你好多问题，比如你的公司名称，你 的地址，你要设定的密码等等，都由自己的随便写。 &nbsp; 3．使用刚才生成的钥匙来对jar文件进行签名 命令如下： &nbsp; jarsigner -keystore monitor.keystore monitor.jar monitor &nbsp; &nbsp; 这个命令将对monitor.jar文件进行签名，不会生成新文件。 &nbsp; &nbsp; &nbsp; 4．将公共钥匙导入到一个cer文件中，这个cer文件就是要拷贝到客户端的唯一文件 。 命令如下： keytool -export -keystore monitor.keystore -alias monitor -file monitor.cer &nbsp; &nbsp; &nbsp; 此条命令将生成monitor.cer认证文件，当然这几步都有可能问你刚 才设置的密码。 这样就完成了服务器端的设置。这时你就可以将jar文件和keystore文件以及cer文件(我这儿是monitor.jar,monitor.keystore,monitor.cer)拷贝到服务器的目录下了，我用的是weblogic6.0，所以就拷贝到C:/bea/wlserver6.0/config/mydomain/applications/DefaultWebApp_myserver下的自己建的一个目录下了。 &nbsp; 客户端： 1． &nbsp; 首先应该安装jre1.3.0_01，然后将服务器端生成的monitor.cer 文件拷贝到jre的特定目录下，我这儿是： c:/program files/javasoft/jre/1.3.0_01/lib/security目录下。 2． &nbsp; 将公共钥匙倒入到jre的cacerts（这是jre的默认keystore） 命令如下： &nbsp; keytool -import -alias monitor -file monitor.cer -keystore cacerts &nbsp; 注意这儿要你输入的是cacerts的密码，应该是changeit，而不 是你自己设定的keystore的密码。 3． &nbsp; 修改policy策略文件，在dos状态下使用命令 policytool 系统会自动弹出一个policytool的对话框，如图4所示，在这里面首先选择file菜单的open项， 打开c:/program files/javasoft/jre/1.3.0_01/lib/security目录下的java.poliy文件，然后在edit菜单中选择Change keystore ，在对话框中new keystore url:中输入 file:/c:/program files /javasoft/jre/1.3.0_01/lib/security/cacerts, 这儿要注意反斜杠，在new keystore type 中输入JKS，这是cacerts的固定格式，然后单击Add Policy Entry，在出现的对话框中CodeBase中输入： &nbsp; &nbsp; <a href="http://url:7001/" rel="nofollow">http://URL:7001/</a>* 其中的URL是服务器的IP地址，7001是我的weblogic的端口，如果你是在别的应用服务器上比如说是apache，那端口号就可以省略掉。 在SignedBy中输入(别名alias):这儿是Monitor 然后单击add peimission按钮，在出现的对话框中permission中选择你想给这个applet的权限，这儿具体有许多权限，读者可以自己找资料看看。我这儿就选用allpeimission，右边的signedBy中输入别名：monitor 最后保存，在file菜单的save项。 当然你可以看见我已经对多个包实现了签名认证。 &nbsp; 图4-policytool的策略修改命令界面 这样客户端的设置就完成了。在客户端用ie运行该applet程序时，会询问你是不是对该签名授权，选择授权后，包会自动从服务器下载到本地计算机，而且ie会自动启动jre，在右下栏中可以看见，相当于ie的java控制台。 &nbsp; 4．调用applet的html文件 大家都知道由于java2的安全性，对applet的正常调用的html文件已经不能再使用了，而改为ActiveX类型的调用。具体的又分ie和nescape的不同写法，这一些在sun网上都能找到现成的教程。我就不多说了，只是将我的这个小程序为ie写的的html给大家看看。 &lt;html&gt; &lt;META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=gb2312"&gt; &lt;center&gt; &lt;h3&gt;消息中心实时监控平台&lt;/h3&gt; &lt;hr&gt; &lt;OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" &nbsp; width="900" height="520" align="baseline" codebase="<a href="http://192.168.2.217:7001/j2re-1_3_0_01-win-i.exe#Version=1" rel="nofollow">http://192.168.2.217:7001/j2re-1_3_0_01-win-i.exe#Version=1</a>,3,0,0"&gt; &lt;PARAM NAME="java_code" VALUE="wise.monitor.applet.monitorApplet"&gt; &nbsp; &lt;PARAM NAME="java_codebase" VALUE="monitor/classes"&gt; &nbsp; &nbsp; &lt;PARAM NAME="java_type" VALUE="application/x-java-applet;version=1.3"&gt; &nbsp; &lt;PARAM NAME="ARCHIVE" VALUE="monitor.jar" &gt; &nbsp; &lt;PARAM NAME="scriptable" VALUE="true"&gt; &lt;/OBJECT&gt; &lt;/center&gt; &lt;/html&gt; 其中我要强调一点，因为applet每一次的改动都需要重新打包签名，手续非常繁琐，所以在具体的实现中要将一些会变化参数放到html文件中来，传到applet中去，这一点网上文章好多，自己去看吧。 另外一个就是有朋友问我，那这样不是太麻烦了，每一个客户端都要进行复杂的dos命令操作，我只能说一目前我的水平只能将一个已经做好的客户端文件cer文件和java.policy以及cacerts文件直接拷贝到客户端，当然这也有缺陷，如果别人的计算机已经有了认证，就会丢失。就这些问题我们可以一起探讨。 另外还有一点优化，就是在打包的时候，我这儿只讲了把所有要用的涉及到安全性的包和源程序到要打到一个包中。这样如果包非常大的话，会非常影响下载的速度，如果可以使用本地计算机的包就好了，这一点jre也做到了，具体的要到控制面板的jre控制台上去设置。这个就留着读者自己去摸索吧。 </td> 
 </tr> 
 </tbody> 
</table>

[http_blog.ccidnet.com_blog-htm-do-showone-uid-35931-type-blog-itemid-87550.html]: http://blog.ccidnet.com/blog-htm-do-showone-uid-35931-type-blog-itemid-87550.html