MIDP 2.0安全机制 与 MIDlet 数字签名（转自j2medev）

本篇文章转自www.j2medev.com/bbs/dispbbs.asp

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

本文档是 WoTrust 根据 Forum Nokia 提供的技术文档《MIDP 2.0: Tutorial On Signed MIDlets》翻译整理的，请同时参考此英文原文文档。请用户在编写 MIDlet 和签名 MIdlet 之前阅读此文档，以便对 MIDP2.0 的安全机制有一个深刻的理解，有助于用户能用好 MIDlet 代码签名证书。  一、概述     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 次使用是需要确认：     如下图 2 所示，您可以下拉所有功能组的许可设置，如“ Network Access ”就有 4 个选项可以修改： Ask first time 、 Ask every time 、 Always allowed 和 Not allowed ：      而如下图 3 所示，在“ Real Life ”模式，也就是实际手机的运行模式，可以看出：定义的 7 个功能组都是“ Always allowed ” ( 总是允许 ) ，这就显示出 MIDlet 签名对于开发商来讲是多么的重要，将大大方便了用户的使用，再也不需要用户操作烦人的系列确认了。