保护您的 J2ME/MIDP 应用程序

　　无线 Web 服务中的 Java 技术
　　基于 Java 的 Web 服务和无线 Java 开发是 JavaOne 2002 的两个最突出的主题。它们代表普及计算领域中未来的后端和前端 Java 技术。
　　
　　Web 服务是基于标准 XML 通信协议的松耦合的可互操作的软件组件。Web 服务的使用使供应商能够在其核心竞争力所在的特定市场中提供服务。然后，客户可以根据其不同需要，从多个供应商选择采购服务。这种便利意味着 Web 服务完全适合于为无线前端提供服务。无线信息设备的便利和动态本质允许移动用户利用模块化的且动态可重新配置的后端服务。
　　
　　Java 平台可以在无线 Web 服务应用程序开发中扮演几个重要角色。在无线端，Java 2 Micro Edition（J2ME）为所有无线设备（从蜂窝电话到复杂的家用无线信息家电）提供了跨设备的兼容性、高级语言功能和大量库。J2ME 的一个关键组件是移动信息设备框架（Mobile Information Device Profile(MIDP)），它在蜂窝电话和低端 PDA 上定义 Java API 和运行时环境。由于庞大数量的低端设备，期望在将来能够广泛部署 MIDP。
　　
　　从 Web 服务端，Java 2 企业版（J2EE）已经具有所有必需的 API 和库来处理 Web 服务 XML 消息。通过 Web 服务接口或网关，可以方便地将用 EJB 技术实现的核心 J2EE 功能、JDBC API 和 RMI API 用于外部世界。为了将这些特性集合起来并启用无线 Web 服务应用程序，还提出了 J2ME Web 服务规范，目前它在 Java Community Process（JSR 172）中。
　　
　　无线 Web 服务中的安全性
　　虽然基于 Java 的无线 Web 服务在普及移动商业世界中有一个光明的前途，但当前技术仍不成熟。安全性仍是剩下待解决的问题之一。无线通信是无线电波拦截容易获取的目标，而无线设备几乎没有任何计算能力来支持所有通信数据的强加密。此外，在后端，Web 服务运行在企业防火墙之外并使用开放消息传递协议来彼此交互。无线 Web 服务同样是易招受各种破解攻击的目标。已开发得很好的点对点安全性技术（如 SSL/TLS 和 HTTPS）不适合于多供应商、多中间 Web 服务网络拓扑图 ? 重点必需集中在保护内容本身而不是传递内容的连接上。尽管面临新挑战，然而 Web 服务本身还是能用来增强移动商业安全性。新兴的 Web 服务安全性规范的出现使您能够将 Web 服务用作安全性实用程序。
　　
　　在下面的段落中，我将讨论一种常用的安全性技术：数字签名。我将向您演示如何在 XML 消息中使用数字签名来保证端对端的数据完整性。我将应用一些示例来说明如何通过在无线端上使用流行的 J2ME/MIDP 平台并在后端上使用 JavaServer Pages（JSP）技术来实现 XML 数字签名。最后，我将讨论性能问题以及在当前 MIDP 设备上使用数字签名的可行性。MIDP 编程细节不在本文范围内；如果您需要复习一下，请参阅参考资料一节。
　　
　　安全通信的元素
　　数据完整性只是保护通信的一个方面。数字签名也可以提供其它方面的解决方案。通常，安全的网络通信必须符合下列标准：
　　
　　认证：通信双方必须标识其本身。公钥证书上的数字签名可以验证该公钥的可靠性以及持有它的那一方的可靠性。
　　
　　数据完整性：通信双方必须确保内容在传送期间不被改变。数字签名是保证数据完整性的最常用技术。
　　
　　数据机密性：有时候，通信数据是敏感的，必须保密。数字签名不提供数据机密性。我们必须使用数据加密。
　　
　　不可抵赖性：消息发送之后，发送方随后应该不能否认它。数字签名提供了部分解决方案。如果以数字方式对消息进行签名，则发送方无法否认其责任，因为只有他能提供这种签名。
　　
　　使用数字签名保证数据完整性
　　让我们假设一下，您是一位股票交易者，当您不在交易大厅时，使用蜂窝电话来跟踪股票价格变化。在上下班途中，您的电话提醒您正在监视的一只股票的价格已经跌入您的心理最低价。现在，您应根据此提示买进它并利用此低价来赚一笔吗？在您采取任何行动之前，您必须绝对确保提示本身是可信的。如果竞争者可能拦截并更改消息（例如，更改股票代码），那么他就可能引诱您买进弄错的股票，并将他的高价位股票抛给您。您如何知道消息在从监视服务到您电话的途中没有被篡改呢？
　　
　　数据完整性确实是通信安全性的最重要方面之一。物理上安全的网络十分昂贵，而且并不覆盖范围很广的地理区域。如果您的业务必须依靠因特网才能通信，那么您必须面对因特网本身几乎不提供安全性这一事实。因特网数据包在到达其目的地之前必须途经由非对话双方控制的多个路由器和主机。数据通信在无线因特网上特别容易受到攻击。
　　
　　及时出现的援救工具是公钥基础设施（PKI）和数字签名。（和 MIDP 编程一样，数字签名不在本文范围内；感兴趣的读者可以参考参考资料一节来获取更多信息。）概括地说，在 PKI 数字签名模式中，每一方都有两个密码术密钥：公钥，任何人都可以使用它，而私钥，是保密的，只有某个人本身可以使用。用私钥加密的消息只能由相应的公钥正确解密。当发送方发送消息时，他可以将相同消息的私钥加密版以及他的公钥与该消息一起发送。接收方使用发送方的公钥来解密加密版本。如果它与明文消息匹配，那么接收方可以知道该消息确实可信。该消息的私钥加密版用作完整性验证记号，我们将它称为“数字签名”。
　　
　　因为原始消息可能相当长，而且生成和验证数字签名的公钥算法是资源密集的，所以发送方通常计算称为“摘要”的原始消息的短版本并且仅对该版本进行数字形式的签署。摘要具有固定长度，它是任何长度的输入消息的单向散列；其计算速度非常快。接收方首先验证接收的消息是否产生正确摘要。如果该摘要不匹配，则在执行任何公钥算法之前拒绝该消息。这可以有助于防止攻击造成堵塞，在这种攻击中，攻击者通过用伪造的公钥请求填斥服务器，以耗尽它的计算资源。
　　
　　在大多数实际应用程序中，公钥本身由可信的权威部门进行数字签名，并成为“数字证书”来验证发送方的标识。不过，数字证书的处理不在本文范围内，所以在下列示例中，我将假设发送方是可信的并使用未签署的公钥来说明方法。
　　
　　定义的 XML 数字签名
　　正如我早先提到的那样，XML 正成为 Web 服务世界中一个主要的数据交换协议。驱动 Web 服务的 XML 消息在到达目的地之前，通常需要经过多个中间环节。因此，我们保护从端到端的通信内容是重要的。完成这一任务的最好方法是，将 XML 文档及其安全性信息（如签名、摘要和密钥等等）都装运在一起，作为单个文档。
　　
　　XML 数字签名是将数字签名添加到 XML 文档的 W3C 规范。发送方可以选择对整个文档或者仅它的一部分进行数字签名。数字签名、摘要和公钥被格式化成 XML 元素。那些安全性信息的额外元素可以封装整个原始 XML 消息，或者可以将它们嵌入原始消息。为了方便起见，我将在本文中使用封装格式。
　　
　　为了清晰起见，我在本文中使用的 XML 数字签名示例并不完全与 W3C 相符。例如，我省去了标准（XML 标记的标准化）部分，因为它仅确保 XML 文档的一致性而与安全性本身无关。另外，我将密钥分成几个参数并将那些参数传递到公钥元素 KeyInfo 下的单独 XML 元素中，以代替使用编码的公钥证书。这在密钥和处理它们的 Java 代码之间建立了更明显的连接。
　　
　　处理 MIDP 应用程序中的 XML 数字签名
　　IBM alphaWorks 开发了一种称为 XML Security Suite 的 Java 包，它支持最新的 XML 数字签名规范。JSR 105 是标准化一组 Java API 以处理 XML 数字签名的一项社区成果。然而，它们仅作用于 Java 2 标准版（J2SE），这意味着可以在服务器端上使用 XML Security Suite 或 JSR 105 Java XML 数字签名 API，但不能在 MIDP 无线设备端上使用它们。
　　
　　要处理 XML 数字签名，正在使用的无线设备需要支持下列功能：
　　
　　对 XML 文档读写数据。在示例 MIDP 应用程序中，kXML 解析器将 XML 文档和元素解析成 Java 对象（请参阅参考资料）。除了 kXML 外，还有几个可在不同许可证条款下使用的其它 MIDP XML 解析器。
　　
　　签署消息并验证签名。这些功能需要一个不属于当前 MIDP 1.0 规范的密码术 API。
　　
　　在下一节中，我将讨论一种轻量级 Java 密码术包，您可以在服务器端和无线 MIDP 设备端上使用它来生成并验证 XML 数字签名。
　　
　　安全移动代码中的数字签名
　　数字签名不仅有助于保护应用程序数据通信，它们还有助于保护应用程序本身。无线设备常常需要从无线网络下载应用程序来动态调整自身，以使其适合新环境和任务。怀有敌意的各方可能拦截移动代码分发版并将病毒和其它有害的特洛伊代码段插入下载的应用程序中。我们怎么样才能确保移动代码可信呢？移动代码供应商可以用其数字证书对整个 JAR 压缩文档进行数字签名。无线用户可以根据供应商的可信级别来确定该应用程序的安全性域。
　　
　　Bouncy Castle Crypto API
　　Bouncy Castle 是一种用于 Java 平台的开放源码的轻量级密码术包。它支持大量的密码术算法，并提供 JCE 1.2.1 的实现。因为 Bouncy Castle 被设计成轻量级的，所以从 J2SE 1.4 到 J2ME（包括 MIDP）平台，它都可以运行。它是在 MIDP 上运行的唯一完整的密码术包。
　　
　　不管 Bouncy Castle 包的功能有多强大，它有一个主要问题：缺少文档。不存在在线文档，其 JavaDoc 写得并不好。与许多其它高级密码术包相似，Bouncy Castle 包广泛使用类型多态性来将常规概念与实现算法分开。对于初学者来说，辨认类之间的关系以及方法参数和返回值的正确类型是很困难的。通常，开发人员必须浏览一下源代码和测试用例来研究做事的正确方法。显然，Bouncy Castle 包的指南非常合适。
　　
　　在本文的其

查看本文来源