MIDP2.0安全机制与MIDlet数字签名
本文档是 WoTrust 根据 Forum Nokia 提供的技术文档《MIDP 2.0: Tutorial On Signed MIDlets》翻译整理的,请同时参考此英文原文文档: http://www.wotrust.com/support/resou...ts_v1_1_en.pdf 。请用户在编写 MIDlet 和签名 MIdlet 之前阅读此文档,以便对 MIDP2.0 的安全机制有一个深刻的理解,有助于用户能用好 MIDlet 代码签名证书。
充分理解 MIDP2.0 的安全机制后就可以向 WoTrust 申请 Thawte 或 VeriSign 的 Java 代码签名证书来签名 MIDlet ,请同时参考:Nokia MIDlet(MIDP 2.0) 代码签名证书申请和使用指南: http://www.wotrust.com/support/Nokia...ning_guide.htm
一、概述
MIDP2.0采用了全新的安全机制,这对于需要调用一个敏感的(重要的)函数和API的MIDlet开发者来讲是必须了解的,如:网络连接API、消息API和推(Push)函数等,还有一些可选的MIDP包也有许多受限制的API。
虽然购买代码签名证书需要费用,但签名MIDlet对开发者来讲是收益非浅的,因为许多受保护的API都是需要签名的,以保护开发者和用户的利益。当然,有些应用是不需要签名的,如有些不需要联网的仅用到一些图形API的小游戏软件。但一些重要的应用,如:连接网络、发送短消息(短信和彩信)或访问移动终端(智能手机、PDA等,以下简称为手机)上的PIM(个人信息管理)数据等等都需要签名。
数字签名MIDlet的好处包括:
(1)基于MIDlet的安全策略,某些功能是必须签名才能使用的,而有些功能虽然不签名也可以使用,但必须要求用户在使用时确认和修改其安全策略,如:写用户数据缺省是不允许没有签名的MIDlet操作的;
(2)基于手机的系统安全和移动网络的安全考虑,某些手机制造商、移动运营商等可能拒绝没有签名的MIDlet在手机上安装和运行;
(3)大大改善用户体验,让用户使用方便,使得用户不会遭遇调用受保护API时的安全警告的烦恼;
(4)出于安全考虑,安装没有签名的MIDlet是会有安全警告的,而相反,安装已经签名的MIDlet则不会出现烦人的警告,手机会自动验证签名而顺利地安装成功;
(5)已经签名的MIDlet将使得用户能改善其低安全策略设置,提高手机的安全性;
(6)确保已经签名的MIDlet不会被非法篡改和非法盗用。
二、MIDP2.0安全机制
MIDP是一个开放的平台,使得任何人都可以为支持MIDP的设备开发各种应用软件,一般都是移动终端设备。MIDlet套件可以以匿名方式通过网络下载,非常方便,但这也会带来许多安全问题和隐私信息保护问题,用户会问:MIDlet能把用户的个人信息发给不知道的服务器吗?会自动产生没有授权的呼叫或短消息而给用户带来费用吗?恶意软件会破坏手机?等等。
除了Java语言的安全特性外,MIDP还增加了许多安全考虑。MIDP2.0比MIDP1.0增强了安全策略,把API分为普通API和敏感API,如:通过HTTP协议访问移动网络,由于会给用户产生费用,所以被列为敏感API。MIDlet2.0推出了可信任MIDlet(trusted)和不可信任MIDlet(untrusted)的概念,一个不可信任MIDlet只能访问有限的API,同时还需要用户手动确认并修改其安全策略;而可信任MIDlet则自动继承系统中的安全策略而获得访问许可。
许可(Permissions)用于需要身份认证的敏感API。MIDP2.0要求调用敏感API之前必须获得必要的许可,这些许可包的命名同J2SE许可,如:HTTP连接许可同样称为:javax.microedition.io.Connector.http。有关许可的文档同意归类在受保护API中。
2.1ProtectionDomains(保护域)
保护域是MIDP2.0中一个非常重要的安全概念,一个保护域就是一个许可集和一种交互模式,这些许可既可以是自己继承的,也可能是用户设置的,前者称为允许(allowed),而后者称为用户允许(userpermission)。当一个MIDlet被安装后,它被分配到一个指定的保护域而获得它的许可和交互模式。
而用户允许则需要用户自己决定是否同意,用户既拒绝一个许可,也可以同意。用户允许有3种交互模式:blanket(普遍适用)、session(短期适用)和oneshot(本次适用),普遍适用模式就是MIDlet安装时获得的许可一直有效,除非用户取消这些许可;而短期适用模式则是指第一次调用API时需要用户允许,有效期到此MIDlet套件运行结束;而本次适用模式则在每次调用API时都要求用户允许。保护域为用户许可定义了缺省的交互模式。
一个MIDlet套件使用MIDlet-Permissions和MIDlet-Permissions-Opt属性来明确地定义其许可,可以是在JAD文件中定义,也可以在manifest文件中定义。其中:MIDlet-Permissions定义了MIDlet套件中必须具有的许可,而MIDlet-Permissions-Opt则定义希望具有的许可。如:一个应用软件的基本要求是要有http连接才能正常工作,同时,也可以使用https连接(服务器部署了SSL证书)来增强安全性,但不是必须的,这样,这个应用软件的应用描述可以是这样:
MIDlet-Permissions:javax.microedition.io.Connector.http
MIDlet-Permissions-Opt:javax.microedition.io.Connector.https
请注意:一个MIDlet所要求的许可必须是安装时分配的保护域所具有的许可的子集。如:NokiaS60MIDPEmulatorPrototype2.0(SDK)有一个叫做“minimum”的域,此域没有任何许可。所以,如果一个含有许多许可的已经签名的MIDlet如果被安装到此域,则会安装失败,因为此域不支持这些许可。同样,如果一个许可的名称有拼写错误,则一样会导致安装失败,因为域中没有此拼写错误的许可。
MIDP2.0为GSM/UTMS设备定义了4种保护域:manufacturer(设备制造商),operator(移动运营商),trustedthirdparty(可信任的第三方),anduntrusted(不受信任域),除了untrusted域外,每个保护域都对应一组根证书,用于签名MIDlet的签名证书的根证书必须包含在这些根证书中,使用不同的签名证书签名的MIDlet将被自动归类予根证书所属的保护域,根证书与保护域的关系是:一个保护域可以有许多个根证书,而一个根证书只能对应于一个保护域。
具体来讲,manufacturer域属于设备制造商,其根证书是设备制造商自己的根证书;而operator域运营商,一般使用其SIM卡中的根证书;而trustedthirdparty域则预置了全球知名的数字证书颁发机构(CA)的根证书,用于验证由CA颁发的MIDlet签名证书;而untrusted域没有根证书,将用于没有签名的MIDlet和MIDP1.0。
Thawte和VeriSign的根证书已经预置在trustedthirdparty域中,其Java代码签名证书可以用于签名MIDlet。当然,用户也可以选择使用设备制造商和移动运营商颁发的证书,只要其根证书已经包含在手机的4个保护域中。据WoTrust了解,大多数摩托罗拉(Motorola)手机只支持设备制造商域,所以,只能向Motorola申请签名服务了。
请注意:由于MIDP2.0也在不断地修改和增补,所以,可能不用的移动网络运营商有不同的保护域和许可,用户可能需要向移动运营商了解详细信息。而最简单的方法是检查目标用户所使用的手机的根证书是否有计划购买的MIDlet签名证书的根证书。
2.2UntrustedMIDlet(不受信任的MIDlet)
MIDP2.0定义了那些API是untrusted的,这些Jar文件的来源和完整性是不能被手机验证的。但这并不意味着这些MIDlet不能被安装和运行,而是运行这些MIDlet需要用户人工确认允许。而所有MIDP1.0的MIDlets都被定义为untrusted。
untrusted的MIDlets只能调用一个不需要许可保护的API,如:
java.util
java.lang
java.io
javax.microedition.rms
javax.microedition.midlet
javax.microedition.lcdui
javax.microedition.lcdui.game
javax.microedition.media
javax.microedition.media.control
如果untrustedMIDlet套件试图调用一个被保护的API而且没有被人工允许,则会产生一个SecurityException而被MIDlet按照安全策略处理。请注意:Nokia的UIAPI是不被保护的,包括类:com.nokia.mid.sound和com.nokia.mid.ui。
2.3TrustedMIDlets(可信任的MIDlets)
如果手机能验证MIDlet的身份和完整性(也就是已经数字签名),则会自动分配一个合适的保护域这种MIDlet套件就称为可信任的MIDlet。一个可信任的MIDlet套件所要求的许可将被准许,只要所属的保护域拥有这种许可,假如许可:javax.microedition.io.Connector.http已经在所属保护域中是允许的,则MIDlet在打开一个http连接时是不需要用户确认的。
请不要混淆了可信任的MIDlet套件和可信任的保护域的不同,每个可信任的MIDlet套件依据安全策略被分配到一个特定的保护域。
您需要使用一个手机中已经预置的根证书的证书颁发机构颁发的代码签名证书来签名MIDlet,否则将不能通过身份验证。成功签名后的JAD文件中一定会包含有整个签名证书的证书链,属性名称为:MIDlet-Certificate-1-1就是您的签名证书,而MIDlet-Certificate-1-2就是CA的中级根证书,而MIDlet-Certificate-1-3就是CA的顶级根证书。同时还会有一个MIDlet-Jar-RSA-SHA1属性就是JAR文件的摘要。
当一个MIDlet被下载或被安装时,MIDlet应用管理器首先会检查JAD文件中是否包含了MIDlet-Jar-RSA-SHA1属性,如果有,则启动如下验证过程:首先会读出MIDlet-Certificate-1-1、MIDlet-Certificate-1-2和MIDlet-Certificate-1-3属性中的证书,并与已经预置的根证书相比较,如果证书链能被根证书验证,则表明开发者身份已经被验证。接着就会使用用户证书来解密MIDlet-Jar-RSA-SHA1属性的摘要,再计算出已经下载的Jar文件的摘要,比较两个摘要是否相等,如果相等,则表明MIDlet代码自签名后没有被修改。这样,既验证了身份又检查了完整性的MIDlet会被分配到所属根证书所对应的保护域中。但是,如果MIDlet中的许可属性(MIDlet-Permissions)中有一个或多个不属于所属的保护域,则仍然不允许安装。而如果MIDlet中的可选许可属性(MIDlet-Permissions-Opt)中有一个或多个不属于所属的保护域,会允许安装。可见,正确设置许可属性和可选许可属性非常重要。
2.4FunctionGroups(功能分组)
为了简化用户管理操作,MIDlet把一些类似功能分组,这样,用户只需对功能组设置许可即可。如:许可“NetAccess”(网络访问)组来代替许可javax.microedition.io.Connector.http,这对于简化手机的交互操作非常有用。
MIDP2.0和JTWI定义了如下7个功能组:
(1)NetAccess:包括所有网络连接许可;
(2)Messaging:包括所有与发送和接收短消息(短信和彩信等)相关的许可;
(3)AutoInvocation:包括与自动启动MIDlet相关的许可,如:PushRegistration
(4)LocalConnectivity:包括与本地连接相关的许可,如:IrDA或蓝牙;
(5)MultimediaRecording:包括与允许录音、照相、摄像等相关的许可;
(6)ReadUserData:包括读取用户数据相关的许可,如:通讯录、日程表等;
(7)WriteUserData:包括写用户数据相关的许可。
不同的手机支持不同的功能组,如:MultimediaRecording就不会包含在没有摄录装置的手机中。当然,也有可能将来会增加更多的功能组。
功能组也同时定义了不同的域的不同交互方式,如:在不信任域,“NetAccess”(网络访问)被设置为session(短期适用)或denied(拒绝),而在可信任域则可以设置为oneshot、blanket和denied的。
三、仿真器和手机的缺省安全设置
让我们来看看具体的使用 Thawte 或 VeriSign 代码签名证书签名后的 MIDlet 在 trusted third party域中的所有缺省许可,如下图 1 所示,点击 NDS 3.0 的“ Config Emulators ”就可以看到仿真器在 trustedthird party 域的缺省安全设置是“ Ask first time ”,即第 1 次使用是需要确认:原文地址:http://www.j2megame.org/index.php/content/view/1867/125.html