基于JAVA平台的移动代码安全性探讨
开篇：润墨网以专业的文秘视角，为您筛选了一篇基于JAVA平台的移动代码安全性探讨范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
摘要:该文对Java平台中Applet安全性方面的问题,从1.0 版本至今的发展过程进行了讨论。详细讨论了Java 2 平台对移动代码安全性的解决方案及Java 6.0平台安全性的增强,对于在java平台下进行移动代码开发有一定指导意义。
关键词:Java;Applet;SunPKCS11;SunMSCAPI;沙箱;签名
中图分类号:TP309 文献标识码:A 文章编号:1009-3044(2009)15-3874-02
JAVA Platform Based on the Mobile Code Security of Investigate
LIU Meng-fei
(Shandong Yingcai College, Department of Computer, Jinan 250100, China)
Abstract: This paper discusses the history of the security of java applets in java platform. This paper emphasizes discusses the security solution of java applets in Java 2 platform and the Security Enhancements of Java 6 platform. The developer on mobile programs may under this paper's directing.
Key words: Java; Applet; SunPKCS11; SunMSCAPI; Sandbox; Signature
1 移动代码的安全性
随着Java平台的广泛使用,Java平台下移动代码的安全性受到越来越多人的关注。Java 平台的安全模型从JDK1.0 到现在的Java 6.0,Java平台的安全体系不断改进,整体安全性也不断得到加强。
网上程序在动态性上是令人满意的,但它们在安全性和可移植性方面也显示出严重的缺陷。在Java产生以前,当前赛百空间有一半的对象实体无法进入网络世界,是Java为它们打开了便利之门,而且在这个过程中定义了一种全新的程序形式:Applet(Java小应用程序)。
Java可用来生成两类程序:应用程序(Applications)和Java Applet(小应用程序)。应用程序是可以在你的计算机的操作系统中运行的程序。小应用程序是可以在Internet中传输并在兼容Java的Web浏览器中运行的应用程序。小应用程序实际上就是小型的Java程序,能像图像文件、声音文件和视频片段那样通过网络动态下载,它与其他文件的重要差别是,小应用程序是一个智能的程序,能对用户的输入作出反应,并且能动态变化,而不是一遍又一遍地播放同一动画或声音。
Java移动代码是一种可以通过网络从一台计算机传到另一台计算机上运行的Java程序(如:Java Applet),在现代网络计算及电子商务中具有广泛应用。
Java 平台的安全模型经历了一个不断发展的过程,从JDK1.0 到现在的Java 2 SDK v1.4,再到Java 6.0。Java平台的安全体系不断演变,新的安全模型和机制不断提出,而整体安全性也不断得到加强[1]。由此使得Java移动代码的安全性也不断演变。
2 JDK1.1安全模型
在Sun Java平台最初的版本―――Java开发包(Java Development Kit,JDK)1.0.x中,引入了基于沙箱(Sandbox)的安全模型。该模型主要支持安全地下载和运行java Applet,并规避所有针对用户资源的潜在风险。
沙箱模型的实质是本地代码对重要的系统资源有全部的访问权限,而下载的代码(例如Applet)则不被信任并且仅能够访问沙箱提供的有限资源。沙箱模型如图1所示。
在JDK1.0沙箱安全模型中,所有的Applet 都被认为是不可信的,被限制在沙箱模式中运行。这种限制对于计算机环境的安全非常有利,但却太苛刻了。JDK1.1引入了“Signed Applet”的概念,如图2所示。在该版本中,允许在验证Applet签名者的信息后,将Applet作为可信代码下载并执行。为支持签名Applet,JDK1.1.x还新增了对加密算法的支持以便提供数字签名功能。有了这些支持,就可以对Java Applet类进行数字签名,生成Java(Java Archive Format,JAR)归档格式文件。被签名的Applet和他们的签名一起以JAR的格式发送,未签名的Applet仍然运行在沙箱环境中。如果某个Applent的签名者被验证为可信,那么这个Applent就可以像本地资源一样自由的访问系统了。
3 Java 2安全模型
从JDK1.2开始,Sun将Java平台升级为Java 2平台,Java 2安全模型弥补早期安全模型的局限性(此问题的详细论述可参阅文献[2]),并且在Java 2平台提出了全新的安全体系结构,如图3所示。
引入新的安全体系结构的重大优势:
1) 细致的访问控制。这种能力一开始就存在于JDK中,但是使用它需要程序开发人员做大量的编程工作,例如继承(Subclassing)和定制SecurityManager和ClassLoader类。HotJava浏览器1.0就是这样的应用程序,因为它允许浏览器用户选择不同的安全级别。然而,这种编程方法具有极端的安全敏感性,并且要求高超的技术和深厚的计算机安全知识。新的安全体系结构使得这个过程比较简单和安全。
2) 容易配置的安全策略。这种能力也较早出现在JDK中并且不易使用,更为重要的是编写安全代码不够直观,让程序开发人员和用户不需要编程只需配置安全策略,这才是大家所期望的。
3) 容易扩展的访问控制结构。新的体系结构允许类型化的许可权限(每一个许可权限代表着对一个系统资源的访问)以及对正确类型的所有许可权限的自动处理(包括还没有定义的许可权限)。
4) 安全检查扩展到所有的Java程序。不再有内在的“所有本地代码都是可信” 的概念。尽管,需要的话可以让本地代码具有最自由的安全政策――使得那些代码完全被信任并且有效的运行,但是在新的安全体系结构里面,本地代码(例如非系统代码,安装在本地文件上的应用程序包)象Applet一样受到严格的安全控制。
5) 对安全类(包括SecurityManager和ClassLoader)的设计中作内部调整以减少在未来编程中存在细小安全漏洞的风险等。
在Java 6的安全部分,又增加了 XML-Digital Signature (XML-DSIG) APIs, 整合了GSS/Kerberos的操作API、LDAP上的JAAS认证。现在Sun公司的Java 6平台,更是提供了一整套安全有效的移动代码安全性解决方案,我们通过使用Java 6 平台,可以使自己开发的移动代码获得足够高的安全性,以及足够的灵活性。既可以达到安全使用的目的,同时又不丧失移动代码可以进行的工作以及进行操作的简易性。
4.1 算法支持
1) SunPKCS11支持椭圆曲线算法(Elliptic Curve Cryptography)。
如果底层PKCS#11接口支持ECC算法,SunPKCS11可以在Java平台提供ECC的支持,包括了ECDSA签名、验证,ECDH密钥协商,以及EC密钥对生成。
ECC是美国家安全局所选择的下一代安全技术,其宗旨是保护美国政府的机密信息。Java System Web Server中的组件可大大减少完成安全在线处理的时间,因此可提高系统的性能和缩放能力。同时,ECC加密技术也提高了Java System Web Server的安全性能。
ECC加密技术比起传统加密技术在解密时使用的公钥较小,但可获得同等级的安全性能。较小的公钥就能获得更高的资源利用率、更长的电池寿命和更快的计算速度。
2) SunJSSE支持椭圆曲线算法。
现在如果JDK中存在合适的密码算法提供者提供ECC算法(例如,有合适的底层PKCS#11库支持的SunPKCS11),SunJSSE可支持RFC4492(传输层安全(TLS)的ECC密码组)中定义的ECC算法。
4.2 对本地Microsoft Windows系统PKI和密码服务的调用
增加了一个JCE提供者SunMSCAPI,SunMSCAPI使用Microsoft CryptoAPI(CAPI)提供各种RSA算法的功能实现。它成为Java应用程序和通过CAPI中CSP(Cryptographic Service Provider)提供的RSA 算法服务之间的桥梁。SunMSCAPI提供了使用X.509证书和RSA密钥对的方法,可以进行RSA加密和解密,可以创建和验证RSA签名等,同时提供密码算法中使用的随机数生成器。
4.3 强化了PKI证书路径验证的实现
增加了分段和重定向CRL的支持,提高了兼容PKIX 的性能(RFC3280)。
4.4 使用LDAP实现JAAS为基础的身份鉴别
JAAS中增加了一个登录模块,从而用户可以使用LDAP中储存的证书进行身份认证。它为JAAS为基础的那些希望支持使用LDAP进行身份认证的已有应用程序提供了一种解决方式。
4.5 其他相关安全性改善
1) SunPKCS11支持访问NSS(Network Security Services)
SunPKCS11提供者现在支持新的配置方式,使用户可以访问NSS(Netscape Security Services)安全库。这种方式使得Java应用程序可以从NSS数据库文件中读取密钥,从而可以使用ECC算法,并且将NSS软件Token做为一个兼容FIPS140的密码算法提供者。
2) SunJSSE兼容FIPS140
SunJSSE现在实验性的支持FIPS140兼容模式。当一起激活并使用SunPKCS11提供者和经FIPS140认证的合适的PKCS#11接口库,SunJSSE就可兼容FIPS140。
3) 套接字(Socket)读取超时在SunJSSE SSLSocket中已经可以完全支持。
前面的版本中,调用setSoTimout()可能有时导致不可预知的结果,现在已经被修正。
4) SunJCE分组密码中增加CTS(Cipher Text Stealing)模式。
CTS是Bruce Schneier在“应用密码学-第二版”中描述的,并被用在一些Kerberos实现中。CTS是算法的密文挪用模式,处理任意长度的明文且密文的长度匹配明文的长度。
5) Java GSS支持SPNEGO
Java GSS现在支持SPNEGO。SPNEGO(Simple and Protected GSS-API Negotiation)机制是一种伪安全机制,使得GSS-API端端之间可以安全的协商一个公共的安全机制来使用。
6) Java GSS/Kerberos支持新的Pre-Authentication机制。
Java GSS/Kerberos支持在最新的Kerberos规范中描述的Pre-Authentication机制。
7) Java GSS/Kerberos 支持AES加密类型
Java GSS/Kerberos现在可以支持AES加密类型(包括AES128和AES256)。这项改动增强了Java SE Kerberos实现与其他Kerberos实现的互操作性(例如Solaris 10 和MIT Kerberos)。
8) Java GSS/Kerberos 支持RC4-HMAC加密类型
Java GSS/Kerberos现在可以支持RC4-HMAC加密类型。这项改动增强了Java SE Kerberos实现与其他Kerberos实现的互操作性(例如Windows,Solaris 10 和MIT Kerberos)。Windows AD(Active Directory) 支持将RC4-HMAC做为Kerberos默认加密类型。
5 结论及讨论
Java平台的安全模型是经历了一个发展过程才转变为现在的形式,在这个转变过程中Java平台的安全性不断得到加强,并且提供了一整套安全有效的移动代码安全性解决方案,我们通过使用Java 平台,可以使自己开发的移动代码获得足够高的安全性,以及足够的灵活性。既可以达到安全使用的目的,同时又不丧失移动代码可以进行的工作以及进行操作的简易性。Java平台实现的移动代码拥有广阔的前景
参考文献:
[1] Li Gong,Security on the Java Platform: Recent Developments and Future Directions, JavaOne 1998.
[2] Li Gong,Inside Java 2 Platform Security Architechture,API design and Implementation,Sun Microsystems Inc,1999.
[3] JavaTM 2 SDK.Standard Edition Documentation Version 1.4.2. Sun Microsystem,2004.
[4] JavaTM Archive (JAR) Features.Sun Microsystem,2003.
[5] jar-The Java Archive Tool.Sun Microsystem,2003.
[6] [美]CarLisle, Adams SteveLloyd(著),公开密钥基础设施―概念、标准和实施[M].冯登国,译.北京:人民邮电出版社,2001.