WEB开发网      濠电姷鏁告慨鐑藉极閸涘﹦绠鹃柍褜鍓氱换娑欐媴閸愬弶鎼愮痪鍓ф嚀閳规垿鎮╃€圭姴顥濋梺姹囧€楅崑鎾诲Φ閸曨垰绠涢柛顐f礃椤庡秹姊虹粙娆惧剳闁哥姵鍔欐俊鐢稿礋椤栨艾鍞ㄩ梺闈浤涙担鎻掍壕闁圭儤顨嗛埛鎺楁煕閺囥劌浜滄い蹇e弮閺屸€崇暆鐎n剛鏆犻柧浼欑到閵嗘帒顫濋悡搴d画缂佹鍨垮缁樻媴缁涘娈┑顔斤公缁犳捇銆佸鎰佹▌濠电姭鍋撳ù锝囩《閺€浠嬫煟濡鍤嬬€规悶鍎辫灃闁绘ê寮堕崯鐐电磼閸屾氨效鐎规洘绮忛ˇ瀵哥棯閹佸仮鐎殿喖鐖煎畷鐓庘槈濡警鐎崇紓鍌欑劍椤ㄥ棗鐣濋幖浣歌摕闁绘棃顥撻弳瀣煟濡も偓閻楀棗鈻撳Δ鍛拺閻犲洠鈧櫕鐏€闂佸搫鎳愭慨鎾偩閻ゎ垬浜归柟鐑樼箖閺呮繈姊洪棃娑氬婵☆偅鐟╅、娆掔疀閺冨倻鐦堥梺姹囧灲濞佳勭閿曞倹鐓曢柕濞垮劤閸╋絾顨ラ悙鏉戝妤犵偞锕㈤、娆撴嚃閳哄骞㈤梻鍌欐祰椤鐣峰Ο鑲╃煋妞ゆ棁锟ユ禍褰掓煙閻戞ɑ灏ù婊冪秺濮婅櫣绱掑Ο铏逛桓闂佹寧娲嶉弲娑滅亱闂佸憡娲﹂崹閬嶅煕閹达附鐓欓柤娴嬫櫅娴犳粌鈹戦垾鐐藉仮闁诡喗顨呴埥澶愬箳閹惧褰囩紓鍌欑贰閸犳牠顢栭崨鎼晣闁稿繒鍘х欢鐐翠繆椤栨粎甯涙繛鍛喘濮婄粯鎷呴悷閭﹀殝缂備浇顕ч崐鍨嚕缂佹ḿ绡€闁搞儯鍔嶅▍鍥⒑缁嬫寧婀扮紒瀣崌瀹曘垽鎮介崨濠勫幗闁瑰吋鐣崹濠氬煀閺囥垺鐓ユ慨妯垮煐閻撶喖鐓崶銉ュ姢缂佸宕电槐鎺旂磼濡偐鐣虹紓浣虹帛缁诲牆鐣峰鈧俊姝岊槺缂佽鲸绻堝缁樻媴缁涘娈愰梺鎼炲妺閸楀啿鐣烽鐐茬骇闁瑰濮靛▓楣冩⒑缂佹ɑ鈷掗柍宄扮墦瀵偊宕掗悙瀵稿幈闂佹娊鏁崑鎾绘煛閸涱喚鎳呮俊鍙夊姇铻i悶娑掑墲閺傗偓闂備胶绮崝鏇炍熸繝鍥у惞闁绘柨鐨濋弨鑺ャ亜閺冨洦顥夐柛鏂诲€濋幗鍫曟倷閻戞ḿ鍘遍梺鍝勬储閸斿本鏅堕鐐寸厱婵炲棗绻掔粻濠氭煛鐏炵晫效鐎规洦鍋婂畷鐔碱敆閳ь剙鈻嶉敐鍥╃=濞达絾褰冩禍鐐節閵忥絾纭炬い鎴濇川缁粯銈i崘鈺冨幍闁诲孩绋掑玻璺ㄧ不濮椻偓閺屻劌鈽夊Ο澶癸絾銇勯妸锝呭姦闁诡喗鐟╅、鏃堝礋椤撴繄绀勯梻鍌欐祰椤曟牠宕伴弽顐ょ濠电姴鍊婚弳锕傛煙椤栫偛浜版俊鑼额嚙閳规垿鍩勯崘銊хシ濡炪値鍘鹃崗妯侯嚕鐠囨祴妲堥柕蹇曞閳哄懏鐓忓璺虹墕閸旀挳鏌涢弬娆炬Ш缂佽鲸鎸婚幏鍛矙鎼存挸浜鹃柛婵勫劤閻挾鎲搁悧鍫濈瑨闁哄绶氶弻鐔煎礈瑜忕敮娑㈡煛閸涱喗鍊愰柡灞诲姂閹倝宕掑☉姗嗕紦 ---闂傚倸鍊搁崐鎼佸磹閻戣姤鍊块柨鏃堟暜閸嬫挾绮☉妯哄箻婵炲樊浜滈悡娑㈡煕濞戝崬骞樻い鏂挎濮婅櫣鎹勯妸銉︾彚闂佺懓鍤栭幏锟�
开发学院软件开发Java MIDP 2.0安全机制 与 MIDlet 数字签名 阅读

MIDP 2.0安全机制 与 MIDlet 数字签名

 2007-12-23 12:40:25 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹妞嬪孩顐芥慨姗嗗厳缂傛氨鎲稿鍫罕闂備礁婀遍搹搴ㄥ窗閺嶎偆涓嶆い鏍仦閻撱儵鏌i弴鐐测偓鍦偓姘炬嫹闂傚倸鍊搁崐鎼佸磹妞嬪海鐭嗗〒姘e亾妤犵偛顦甸弫鎾绘偐閹绘帞鈧參姊哄Ч鍥х仼闁诲繑鑹鹃悾鐑藉蓟閵夛妇鍘甸梺瑙勵問閸犳牠銆傛總鍛婄厱閹艰揪绱曟牎闂侀潧娲ょ€氫即鐛幒妤€绠f繝闈涘暙娴滈箖鏌i姀鈶跺湱澹曟繝姘厵闁绘劦鍓氶悘杈ㄤ繆閹绘帞澧涚紒缁樼洴瀹曞崬螖閸愬啠鍓濈换娑樼暆婵犱胶鏁栫紓浣介哺閹瑰洤鐣烽幒鎴僵闁瑰吀鐒﹂悗鎼佹⒒娴g儤鍤€闁搞倖鐗犻獮蹇涙晸閿燂拷濠电姷鏁告慨鐑藉极閸涘﹥鍙忔い鎾卞灩缁狀垶鏌涢幇闈涙灈鐎瑰憡绻冮妵鍕箻鐎靛摜鐣奸梺纭咁潐濞茬喎顫忕紒妯肩懝闁逞屽墮宀h儻顦查悡銈夋煏閸繃鍋繛宸簻鎯熼梺瀹犳〃閼冲爼宕濋敃鈧—鍐Χ閸℃鐟愰梺鐓庡暱閻栧ジ宕烘繝鍥у嵆闁靛骏绱曢崢顏堟⒑閹肩偛鍔楅柡鍛⊕缁傛帟顦寸紒杈ㄥ笚濞煎繘鍩℃担閿嬵潟闂備浇妗ㄩ悞锕傚箲閸ヮ剙鏋侀柟鍓х帛閺呮悂鏌ㄩ悤鍌涘闂傚倸鍊搁崐鎼佸磹妞嬪孩顐芥慨姗嗗厳缂傛氨鎲稿鍫罕闂備礁婀遍搹搴ㄥ窗閺嶎偆涓嶆い鏍仦閻撱儵鏌i弴鐐测偓鍦偓姘炬嫹  闂傚倸鍊搁崐鎼佸磹閻戣姤鍤勯柤鍝ユ暩娴犳氨绱撻崒娆掑厡缂侇噮鍨堕妴鍐川閺夋垹鍘洪悗骞垮劚椤︻垶宕¢幎鑺ョ厪闊洦娲栨牎闂佽瀵掗崜鐔奉潖閾忓湱纾兼俊顖氭惈椤矂姊洪崷顓涙嫛闁稿妫濋幆鈧い蹇撴祩濡嫰姊洪崫鍕拱婵炲弶岣块幑銏犫攽婵犲嫮鏉搁梺鍝勬川婵兘鎮伴妷鈺傗拻濞达絽鎼敮璺侯熆閻熷府鏀荤紒鍌氱Т楗即宕煎锝呬壕闁哄啫鐗嗙粈鍐┿亜韫囧海顦﹀ù婊堢畺閺屻劌鈹戦崱娑扁偓妤€顭胯閸犳牠婀侀梺缁樕戦悷銉р偓姘煎枤缁粯銈i崘鈺冨幈濡炪倖鍔戦崐鏇㈠几鎼淬劍鐓熼煫鍥ь儏閸旀粓鏌曢崶褍顏€殿喗娼欒灒闁告繂瀚濠碉紕鍋戦崐鎴﹀垂濞差亝鍋¢柍鍝勬噹缁犳牠鏌嶉埡浣告殲闁稿海鍠栭弻鏇㈠炊瑜嶇花濠氭煙閸戙倖瀚�
核心提示:本文档是 WoTrust 根据 Forum Nokia 提供的技术文档《MIDP 2.0: Tutorial On Signed MIDlets》 翻译整理的,请同时参考此英文原文文档,MIDP 2.0安全机制 与 MIDlet 数字签名,请用户在编写 MIDlet 和签名 MIdlet 之前阅读此文档,以便对 MID
本文档是 WoTrust 根据 Forum Nokia 提供的技术文档《MIDP 2.0: Tutorial On Signed MIDlets》 翻译整理的,请同时参考此英文原文文档。请用户在编写 MIDlet 和签名 MIdlet 之前阅读此文档,以便对 MIDP2.0 的安全机制有一个深刻的理解,有助于用户能用好 MIDlet 代码签名证书。

充分理解 MIDP2.0 的安全机制后就可以向 WoTrust 申请 Thawte 或 VeriSign 的 java 代码签名证书来签名 MIDlet ,请同时参考:
  Nokia MIDlet(MIDP 2.0) 代码签名证书申请和使用指南

  J2ME MIDlet( MIDP 2.0) 代码签名证书申请和使用指南

一、概述

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 不会被非法篡改和非法盗用。

二、 MIDP 2.0 安全机制

  MIDP 是一个开放的平台,使得任何人都可以为支持 MIDP 的设备开发各种应用软件,一般都是移动终端设备。 MIDlet 套件可以以匿名方式通过网络下载,非常方便,但这也会带来许多安全问题和隐私信息保护问题,用户会问: MIDlet 能把用户的个人信息发给不知道的服务器吗?会自动产生没有授权的呼叫或短消息而给用户带来费用吗?恶意软件会破坏手机?等等。

除了 Java 语言的安全特性外, MIDP 还增加了许多安全考虑。 MIDP 2.0 比 MIDP 1.0 增强了安全策略,把 API 分为普通 API 和敏感 API ,如:通过  HTTP 协议访问移动网络,由于会给用户产生费用, 所以被列为 敏感 API 。 MIDlet 2.0 推出了可信任 MIDlet(trusted) 和不可信任 MIDlet(untrusted) 的概念,一个不可信任 MIDlet 只能访问有限的 API ,同时还需要用户手动确认并修改其安全策略;而可信任 MIDlet 则自动继承系统中的安全策略而获得访问许可。

许可 (Permissions) 用于需要身份认证的 敏感 API 。 MIDP 2.0 要求调用 敏感 API 之前必须获得必要的许可,这些许可包的命名同 J2SE 许可,如: HTTP 连接许可同样称为: javax.microedition.io.Connector.http 。 有关许可的文档同意归类在受保护 API 中。

2.1 PRotection Domains( 保护域 )

保护域是 MIDP 2.0 中一个非常重要的安全概念,一个保护域就是一个许可集和一种交互模式,这些许可既可以是自己继承的,也可能是用户设置的,前者称为允许 (allowed) ,而后者称为用户允许 (user permission) 。当一个 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 所要求的许可必须是安装时分配的保护域所具有的许可的子集。如: Nokia S60 MIDP Emulator Prototype 2.0 (SDK) 有一个叫做“ minimum ”的域,此域没有任何许可。所以,如果一个含有许多许可的已经签名的 MIDlet 如果被安装到此域,则会安装失败,因为此域不支持这些许可。同样,如果一个许可的名称有拼写错误,则一样会导致安装失败,因为域中没有此拼写错误的许可。

MIDP 2.0 为 GSM/UTMS 设备定义了 4 种保护域: manufacturer( 设备制造商 ) , Operator( 移动运营商 ) , trusted third party( 可信任的第三方 ) , and untrusted( 不受信任域 ) ,除了 untrusted 域外,每个保护域都对应一组根证书,用于签名 MIDlet 的签名证书的根证书必须包含在这些根证书中,使用不同的签名证书签名的 MIDlet 将被自动归类予根证书所属的保护域,根证书与保护域的关系是:一个保护域可以有许多个根证书,而一个根证书只能对应于一个保护域。

具体来讲, manufacturer 域属于设备制造商,其根证书是设备制造商自己的根证书;而 operator 域运营商,一般使用其 SIM 卡中的根证书;而 trusted third party 域则预置了全球知名的数字证书颁发机构 (CA) 的根证书,用于验证由 CA 颁发的 MIDlet 签名证书;而 untrusted 域没有根证书,将用于没有签名的 MIDlet 和 MIDP 1.0 。

Thawte 和 VeriSign 的根证书已经预置在 trusted third party 域中,其 Java 代码签名证书可以用于签名 MIDlet 。当然,用户也可以选择使用设备制造商和移动运营商颁发的证书,只要其根证书已经包含在手机的 4 个保护域中。据 WoTrust 了解,大多数摩托罗拉 (Motorola) 手机只支持设备制造商域,所以,只能向 Motorola 申请签名服务了。

请注意:由于 MIDP 2.0 也在不断地修改和增补,所以,可能不用的移动网络运营商有不同的保护域和许可,用户可能需要向移动运营商了解详细信息。而最简单的方法是检查目标用户所使用的手机的根证书是否有计划购买的 MIDlet 签名证书的根证书。

2.2 Untrusted MIDlet ( 不受信任的 MIDlet)

MIDP 2.0 定义了那些 API 是 untrusted 的,这些 Jar 文件的来源和完整性是不能被手机验证的。但这并不意味着这些 MIDlet 不能被安装和运行,而是运行这些 MIDlet 需要用户人工确认允许。而所有 MIDP 1.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

如果 untrusted MIDlet 套件试图调用一个被保护的 API 而且没有被人工允许,则会产生一个 SecurityException 而被 MIDlet 按照安全策略处理。请注意: Nokia 的 UI API 是不被保护的,包括类: com.nokia.mid.sound 和 com.nokia.mid.ui 。

2.3 Trusted MIDlets ( 可信任的 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.4 Function Groups ( 功能分组 )

为了简化用户管理操作, MIDlet 把一些类似功能分组,这样,用户只需对功能组设置许可即可。如:许可 “Net access”( 网络访问 ) 组来代替许可 javax.microedition.io.Connector.http ,这对于简化手机的交互操作非常有用。

MIDP 2.0 和 JTWI 定义了如下 7 个功能组:

(1) Net Access: 包括所有网络连接许可;

(2) Messaging: 包括所有与发送和接收短消息 ( 短信和彩信 等 ) 相关的许可;

(3) Auto Invocation : 包括与自动启动 MIDlet 相关的许可,如: Push Registration

(4) Local Connectivity : 包括与本地连接相关的许可,如: IrDA 或 蓝牙;

(5) Multimedia Recording : 包括与允许录音、照相、摄像等相关的许可;

(6) Read User Data : 包括读取用户数据相关的许可,如:通讯录、日程表等;


  (7) Write User Data : 包括写用户数据相关的许可。

不同的手机支持不同的功能组,如: Multimedia Recording 就不会包含在没有摄录装置的手机中。当然,也有可能将来会增加更多的功能组。

功能组也同时定义了不同的域的不同交互方式,如:在不信任域, “Net Access” ( 网络访问 ) 被设置为 session( 短期适用 ) 或 denied( 拒绝 ) ,而在可信任域则可以设置为 oneshot 、 blanket 和 denied 的。

三、仿真器和手机的缺省安全设置

让我们来看看具体的使用 Thawte 或 VeriSign 代码签名证书签名后的 MIDlet 在 trusted third party 域中的所有缺省许可,如下图 1 所示,点击 NDS 3.0 的“ Config Emulators ”就可以看到仿真器在 trusted third party 域的缺省安全设置是“ Ask first time ”,即第 1 次使用是需要确认:

MIDP 2.0安全机制 与 MIDlet 数字签名(图一)

如下图 2 所示,您可以下拉所有功能组的许可设置,如“ Network Access ”就有 4 个选项可以修改: Ask first time 、 Ask every time 、 Always allowed 和 Not allowed :

MIDP 2.0安全机制 与 MIDlet 数字签名(图二)

而如下图 3 所示,在“ Real Life ”模式,也就是实际手机的运行模式,可以看出:定义的 7 个功能组都是“ Always allowed ” ( 总是允许 ) ,这就显示出 MIDlet 签名对于开发商来讲是多么的重要,将大大方便了用户的使用,再也不需要用户操作烦人的系列确认了。

MIDP 2.0安全机制 与 MIDlet 数字签名(图三)

(出处:http://www.cncms.com)


Tags:MIDP 安全 机制

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接