确保无线 J2ME 的安全

随着移动商业从时髦的口号逐渐变成现实，对于移动用户和无线应用程序开发人员这类人而言，事务安全性正在成为一个重要方面。网络整体安全性的强度取决于其最薄弱环节，而在移动商业网络中，最薄弱环节是客户机端设备。无线信号的可截取本质以及大多数手持设备有限的内存和计算能力，使无线系统极易受到数据窃贼的攻击。

但客户机并非移动商业网络上的唯一薄弱环节。随着 Web 服务技术成为因特网领域中日益重要的组件，无线网络将面临一些全新的弱点。Web 服务使用开放通信协议并在组织的防火墙之外运行，当在企业中部署这些系统时，这将会造成非常实际的安全性威胁。（请参阅 文章侧栏以获得 Web 服务的定义。）

解决方案正在形成，尽管尚需时日。尤其是，Web 服务本身可以用来提供安全性解决方案。新的 Web 服务规范计划标准化和集成使用 xml 消息传递的先进的安全性解决方案（如 Kerberos 认证和授权、数字证书、数字签名和公／私钥加密）。可互操作的 Web 服务可以将那些安全性解决方案用作产品和服务供应商的一类实用程序。但即使正在出现这些有希望的解决方案，对于您如何有效地保护自己的无线应用程序及运行应用程序的网络而言，开发平台的选择将始终起到举足轻重的作用。

在本文中，我们将重点讨论在 java 2 Platform，Micro Edition（J2ME）上进行开发的优缺点。我们首先对 J2ME 的基本概念和优点作简单概述。接下来，我们将深入研究基于 J2ME 的应用程序相对于其它无线备选应用程序（如 WAP 和本机应用程序）的潜在安全性优点。我们将说明当前在 J2ME 平台上可用的应用程序安全性模型，以及该平台对于一些可预料未来趋势的适用性。作为讨论的一部分，我们将提出一些增强 J2ME 应用程序的网络和数据安全性的可能方法。在结束部分，我们将总结使用 J2ME 技术开发用于最小型无线设备的高级安全应用程序的可行性。在整篇文章中，我们将主要集中讨论当前的和即将出台的（2.0）MIDP 规范，假定 MIDP 是最广泛使用的 J2ME 概要文件。

因为 Web 服务承诺了在移动商业和无线安全性的发展中扮演重要角色，所以在整篇文章中，我们都将讨论包含 Web 服务的技术。我们将花一些时间研究 Web 服务对您的 J2ME 开发策略的影响。但是，我们不会很深入地讨论这个话题。要了解更多 Web 服务与无线应用程序编程和安全性之间的关系，请参阅 参考资料一节。

J2ME 基础知识

将 Java 平台用于无线设备开发的最大优点是能够生产可在多种平台上运行的可移植代码。但即使有这个优点，各种无线设备在内存、处理能力、电池寿命、显示屏大小和网络带宽等方面的能力差异还是相当大的。不可能将运行在成熟的机顶盒上的应用程序的全部功能都移植到移动电话上。即使对于类似的设备（如 PDA 和高级智能电话），在两者间建立可移植性也常常使一种设备超负荷而另一种设备利用不充分。只能在多组类似设备之间实现真正的可移植性。因为认识到一种规格并不能适合所有设备，所以小心地设计 J2ME 以在可移植性和可用性之间取得平衡。

Web 服务是具有基于因特网接口的自包含的、自我描述的、动态发现的应用程序。Web 服务由远程方法调用驱动，这些调用是用标准的、基于 XML 的消息和编码封装的，如简单对象访问协议（Simple Object access PRotocol (SOAP)）。Web 服务用 WSDL（Web 服务定义语言）定义了它们的编程接口并通过 UDDI（通用描述、发现和集成）注册中心来发布它们本身。Web 服务在开放的因特网上通过 HTTP 协议与客户机和其它 Web 服务通信。这种“HTTP 上的 XML”模型致力于通过在服务接口之间添加一个开放、健壮和容易被人理解的抽象层来消除它们之间的耦合。Web 服务是松散耦合、与平台无关、可重用的分布式软件组件。它们成功的关键在于开放的标准和服务供应商之间的互操作性。

J2ME 分成几种不同的配置和概要文件。 配置包含用于一系列设备的 Java 语言核心库。当前有两种配置：连接的设备配置（Connected Device Configuration (CDC)）被设计用于相对较大和功能强大的设备（如高端 PDA、机顶盒与网络设备）；有限连接设备配置（Connected Limited Device Configuration (CLDC)）被设计用于小型的资源有限的设备（如移动电话和低端 PDA）。CDC 的安全性、计算能力和 I/O 功能比 CLDC 高级得多。

每个配置上面都有几个概要文件。 概要文件定义了更高级的、特定于设备的 API 库，包括 GUI、联网和持久存储 API。每个概要文件有自己的运行时环境并适合于一系列类似的设备。为一个特定概要文件编写的 Java 应用程序可以在由该概要文件支持的所有硬件／OS 平台之间进行移植。移动信息设备概要文件（Mobile Information Device Profile (MIDP)）和 PDA 概要文件（PDA Profile）是 CLDC 的两个比较重要的概要文件。基础概要文件（Foundation Profile）和个人概要文件（Personal Profile）是 CDC 的两个重要的概要文件。

个人概要文件构建在基础概要文件之上，以便在高端 PDA 上运行。个人概要文件配置了完全兼容 Java 2 的虚拟机实现。个人概要文件应用程序可以利用所有基于 Java 2 标准版（J2SE）域的安全性管理器，以及大量可用于 J2SE 应用程序的密码术和安全性库。总之，个人概要文件提供了成熟的安全性解决方案，它们类似于用于 J2SE 应用程序的那些解决方案。（要了解更多关于 J2SE 安全性的内容，请参阅 参考资料一节。）

实现安全 MIDP 应用程序要困难得多，因为 CLDC 配置的数学计算能力有限并且许多底层设备的处理能力不足。但是，MIDP 设备是使用最广泛的无线设备，因此在那些设备上启用安全应用程序很重要。在本文中，我们主要集中讨论 MIDP 应用程序的安全性挑战以及当前可用的或处于开发中的解决方案。

J2ME vs. WAP

我们的经验是，无论是在特性还是安全性方面，本机应用程序和 J2ME 应用程序都比那些以无线应用程序协议（Wireless application Protocol (WAP)）构建的应用程序提供多得多的功能。但 WAP 是一种瘦客户机开发协议，J2ME 是一种专用于智能应用程序的开发平台。无论应用程序是用 J2ME 还是本机技术构建的，智能应用程序都比 WAP 应用程序多提供了下列安全性优点：

• 由于中间没有 WAP 网关，智能应用程序能够提供从后端到无线设备的可伸缩的端到端安全性。当后端发展成消息驱动的 Web 服务框架时，这一点就尤其重要。
• 智能应用程序能够在本地存储和处理数据，因此减少了网络流量。这不仅节省了宝贵的无线带宽和减少了延迟时间，而且降低了关键信息被截取或阻断（例如，通过拒绝服务攻击）的可能性。
• 智能应用程序有效地利用了设备处理能力。胖客户机可以根据内容建立全面分级的安全性策略，而不是无论是否需要都以相同的密钥强度加密所有内容。

因为智能应用程序比 WAP 页面能干得多，所以，运行智能应用程序确实增加了软件崩溃和／或病毒攻击的风险。接下来，我们将讨论，与那些设备本机应用程序相比，J2ME 应用程序有哪些处理和安全性优点。

J2ME vs. 本机平台

正如我们已经提到的，与本机平台相比，Java 平台的主要优点是它允许我们编写可移植的应用程序。Java 平台的可移植性来自其执行模型。具体地说，它是由于在运行时使用 JVM 来将 Java 字节码处理成机器码，因而在硬件之上提供了一个兼容性层。Java 平台的执行模型还引入了一些在设备本机应用程序中缺乏的重要安全性优点。这些优点如下：

• JVM 验证类装入器中所有的类并确保应用程序不会执行任何危险操作。
  因为对于 MIDP VM 而言，运行时类验证在计算上代价很高，所以 MIDP 有特殊的两步字节码验证模式。我们将在后面一节中讨论这种方案。
• JVM 有用来防止运行时应用程序错误的监控机制。
  垃圾收集器是一个好示例。JVM 能够在运行时自动清理应用程序内存堆。这有助于避免发生内存泄漏，内存泄漏是导致本机应用程序崩溃的主要原因。
• JVM 可以提供用于应用程序的安全性管理器或沙箱。从 Web 上偶然下载的病毒和其它敌意代码可能造成严重的安全性风险。
  在 Java 平台上，可以对整个应用程序（例如 JAR 文件）进行数字签名。JVM 安全性管理器根据签名者的信任级别，向签名的应用程序授予访问特定 API（域）的特权。在后面的一节中，我们将更详细地讨论基于域的移动代码安全性。

与 WAP 和本机应用程序相比，智能的、注重可用性的设计和 Java 平台内置的执行模式赋予了 J2ME 应用程序显著的性能和安全性优势。但 J2ME 并不完美。在后面的一节中，我们将研究 J2ME 安全性框架的优缺点，尤其是当它应用于 MIDP 应用程序时。我们将首先研究应用程序安全性，然后继续讨论网络和数据安全性。

字节码验证

正如我们已经讨论的，JVM 提供了防止恶意代码进入企业系统的服务。字节码验证过程保证了应用程序不能访问内存空间或使用其域外的资源。字节码验证还防止应用程序重载 Java 语言核心库，这是一种可以用来绕过其它应用程序级安全性措施的方法。

但是，由于这种操作高昂的计算开销，MIDP VM 不在运行时执行完整的字节码验证。相反，应用程序开发人员必须在把应用程序部署到移动设备中之前，在开发平台或登台区域上预先验证类。预验证过程优化执行流，创建应用程序中包含指令目录的堆栈映射（stackmap），然后将堆栈映射添加到经预验证的类文件。在运行时，MIDP VM 迅速地对字节码进行线性扫描，将每个有效的指令与合适的堆栈映射项相匹配。

因为 MIDP 缺少完整的安全性模型，所以在 MIDP 中禁用了一些 J2SE 特性以使潜在的安全性风险降到最低。例如，为了防止对核心类的非法重载，MIDP VM 不允许用户定义的类装入器。MIDP 也不支持 Java 本机接口（Java Native Interface (JNI)）或反射（reflection）。即使适当地采取了这些安全性措施，也并非所有通过字节码验证的代码都被允许运行。代码签名是 J2ME 应用程序安全性策略中下一个重要元素。

代码签名

要获得高级移动代码安全性的优秀示例，我们只需研究 Java applet，它使用数字签名和安全性沙箱以确保 Web 上的代码安全。这里是关于 applet 安全性工作原理的简要概述：

• 在传输之前，applet 服务器用其数字证书对 applet JAR 文件进行签名。
• 在接收时，浏览器端 Java 安全性管理器验证签名并判断应用程序的发送方和完整性是否可信。
• 如果不能验证数字签名，则运行时退出并给出错误信息。
  如果能够验证签名，则安全性管理器使用数字证书，通过查询客户机或通过使用表来查询可信实体的权限来确定实体的权限域。
• 在成功完成验证过程之后，应用程序代码被传递到客户机。

注：每个权限域包含一组访问特定 API 的规则。例如，不允许来自不太了解的来源的应用程序读／写本地存储设备或建立任意网络连接。

可以用和 Java applet 一样的方式对基于 J2ME/CDC 的移动代码进行签名和传递。理论上，也可以用相同的方法保护 MIDP 应用程序。但是，由于处理能力和内存有限，MIDP 1.0 规范中还不可以使用基于域的安全性管理器。当前的 MIDP VM 只能提供最小的安全性沙箱。例如，MIDlet 套件只能访问它自己创建的持久记录存储。

即将出台的 MIDP 2.0 规范将需要对域安全性模型的支持，包括基于域的安全性管理器、应用程序代码签名和数字证书验证功能。为了更好地支持安全移动代码保障，MIDP 2.0 还将正式包含无线下载（OTA）保障规范。MIDP 2.0 OTA 规范描述了谁拥有安装和删除无线应用程序的权限；什么操作必须由用户确认以及哪些操作可以自动完成；必须向用户提供哪些警告；以及当更新应用程序时可以共享哪些数据。

网络与数据安全性

可以通过建立点对点安全连接来保证网络与数据安全性。象 SSL/TLS（安全套接字层／传输层安全性 ― 以后简称为 SSL）这样的安全性协议允许我们在因特网主机之间打开安全套接字。在连接握手时，SSL 利用公钥算法和数字证书在素不相识的各方之间建立信任并交换当前会话的私钥。于是，SSL 通信各方使用快速的私钥算法来加密和解密通信数据。SSL 协议支持认证、数据完整性和机密性。在电子商业应用程序中，基于 SSL 的安全 HTTP（HTTPS）已经成为传输敏感数据的标准协议。

J2SE 以其通用连接框架（Generic Connection Framework）提供对 HTTPS 的优秀的和透明的支持。所有 J2ME/CDC 应用程序都有权访问 HTTPS 功能，但在 MIDP 1.0 规范中并不正式需要 HTTPS 支持。考虑到 HTTPS 在移动商业中显而易见的重要性，许多 MIDP 设备供应商已经将对 HTTPS 的支持添加到它们自己的 MIDP 运行时实现中。Sun Microsystems 也在其 J2ME Wireless Toolkit 版本 1.0.2 及后续版本中添加了 HTTPS 支持。在即将出台的 MIDP 2.0 规范中，HTTPS 支持将成为正式需求。

保护内容而非连接

尽管 HTTPS/SSL 协议非常流行而且功能又很强大，但它们原本是为有线因特网领域设计的。当我们开始将 SSL 应用于新一代动态无线应用程序时，会出现许多严重问题，如下所示：

• 对等点组和基于订阅的多播应用程序将成将来智能无线应用程序的主要模型。
  作为一种一对一协议，SSL 不能很好地支持多播应用程序。
• SSL 是一种保护主机间直接连接的点对点协议。
  然而，新兴的因特网领域是基于 Web 服务的。因此，它需要多个中介来协助处理和传递基于 XML 的服务请求。于是就出现了对端到端安全性解决方案的需求。
• SSL 不加选择地用同一密钥强度加密所有数据，对某些应用程序而言，这是不必要甚至是不合要求的。
  对于某些无线应用程序而言，设置和运行 SSL 连接的计算开销显然是太高了。

当移动商业网络扩展时，目前出现的与 SSL 有关的问题只会变得更严重。为了解决这些问题，我们需要一种具有灵活加密方案的端到端安全性模型以满足一系列不同的需求。我们需要关注保护内容而非连接。我们将通过研究几种很有前途的（用于实现端到端无线安全性的）内容格式、安全性协议和工具来结束这个讨论。

XML 优点

J2ME 应用程序可以在 HTTP 协议上使用 XML 数据格式与后端服务器和其它 J2ME 应用程序通信。遗憾的是，所有那些额外标记使 XML 对于有限的无线带宽而言成为一种相当庞大的格式。尽管如此，XML 还是提供了一些很重要的优点。XML 是一种非常健壮的、易于理解的消息格式。这也是为新一代开放、可互操作的 Web 服务所选的通信数据格式。因此，使用 J2ME 的无线设备必须有处理 XML 的能力，以便访问 Web 服务的世界。此时，使用 XML 的优点远胜于其带宽开销。

在基于 MIDP 的应用程序上支持 XML 很困难，因为 CLDC 基类中的字符串功能很有限。幸运的是，MIDP 应用程序已有几个第三方的、轻量级 XML 解析器可以使用。kXML 包（由 Enhydra 开发）提供了用于 XML 的简单 API（Simple API for XML (SAX)）和有限的文档对象模型（Document Object Model (DOM)）能力。kXML 包还包含一种称为 kSOAP 的特殊实用程序，用于为 Web 服务解析 SOAP 消息。原本计划将内置轻量级 XML 解析支持用于 MIDP 2.0 规范，但最近更改了这一计划。JSR 118 专家组已经决定在即将出台的 JSR 172 J2ME Web 服务规范（请参阅 参考资料）中包含 XML 解析支持，该规范还将包含用于 CDC 和 CLDC 应用程序的基于 XML 的远程过程调用（RPC）。

通过安全 XML 保护内容

XML 是我们为 J2ME 无线应用程序和后端服务之间的数据通信所选的格式。为了提供端到端安全性，我们需要确保 XML 文档的安全。因此，我们需要特殊的 XML 标准以将安全性元信息与单个文档相关联。

已提出了几个 XML 安全性协议以在 XML 应用程序中支持通信数据安全性。其中有下列协议：

所有上述安全性协议都可以绑定到 Web 服务消息传递协议。例如，我们可以将 SAML 段嵌入到 SOAP 消息头中来认证和授权对所请求服务的访问。我们也可以将 XML 数字签名段嵌入到 SOAP 头以认证消息中的信用卡号。

因为缺乏 XML 和密码 API，当前的 MIDP 1.0 规范不支持安全 XML 标准。实际上，甚至 MIDP 2.0 也将不包含通用密码 API。这使得开发人员只能依靠第三方库（如 Bouncy Castle 轻量级密码术包）以在 MIDP 应用程序中支持安全 XML。对于 CDC 和 CLDC 设备，JSR 177 提出了使用 SIM 卡的用于安全性和信任服务的 API。加上 SAML 或 WS-Security，新 API 就能够支持自动标识和单点登录 Web 服务了。

结束语

尽管情况复杂，我们还是可以得出结论，与 WAP 和本机应用程序开发方式相比，J2ME 确实提供了许多优点，包括安全性优点。在高端，CDC 的个人概要文件将 J2SE 的全部功能赋予无线应用程序，在大多数情况下包括在严格的安全性需求下实现成熟的应用程序的能力。

在安全性 API 方面，当前的 MIDP 1.0 规范没有提供足够的支持。但在第三方库和供应商支持的帮助下，我们发现可以用 MIDP 1.0 来实现安全应用程序。而且，正如我们所见，即将出台的 MIDP 2.0 规范承诺提供一套核心安全性 API，这些 API 应该允许我们创建具有更高级和灵活安全性特性的移动商业应用程序。

当开发移动商业应用程序时，要考虑的最重要的因素之一是它们将如何适应 Web 服务域。Web 服务技术正在迅速发展，整个因特网领域也随之发展。我们已经花了一些时间讨论应用于基于 J2ME 的应用程序开发的 Web 服务技术。我们鼓励您从 参考资料一节中的一些参考资料开始，深入研究这个主题。

（出处：http://www.cncms.com）