保护您的 J2ME/MIDP 应用程序

护您的 J2ME/MIDP 应用程序
基于 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 数字签名模式中，每一方都有两个密码术密钥：公钥，任何人都可以使用它，而私钥，是保密的，只有某个人本身可以使用。用私钥加密的消息只能由相应的公钥正确解密。当发送方发送消息时，他可以将相同消息的私钥加密版以及他的公钥与该消息一起发送。接收方使用发送方的公钥来解密加密版本。如果它与明文消息匹配，那么接收方可以知道该消息确实可信。该消息的私钥加密版用作完整性验证记号，我们将它称为“数字签名”。

因为原始消息可能相当长，而且生成和验证数字签名的公钥算法是资源密集的，所以发送方通常计算称为“摘要”的原始消息的短版本并且仅对该版本进行数字形式的签署。摘要具有固定长度，它是任何长度的输入消息的单向散列；其计算速度非常快。接收方首先验证接收的消息是否产生正确摘要。如果该摘要不匹配，则在执行任何公钥算法之前拒绝该消息。这可以有助于防止攻击造成堵塞，在这种攻击中，攻击者通过用伪造的公钥请求填斥服务器，以耗尽它的计算资源。

在大多数实际应用程序中，