J2ME安全应用——Bouncy Castle Crypto API

1、前言 随着移动商业的不断发展，对于移动用户和无线应用程序开发人员而言，安全性正在成为一个重要方面。无线通信是无线电波拦截容易获取的目标，而无线设备几乎没有任何计算能力来支持所有通信数据的强加密。而目前开发得很好的点对点安全性技术（如 SSL/TLS 和 HTTPS）并不适合于多供应商、多中间 Web服务的网络拓扑图。因此重点必须集中在保护内容本身而不是传递内容的连接上。 本文将讨论使用一种常见的安全性技术：数字签名。数字签名可以满足网络通讯安全的四方面标准： 可认证性：通信双方必须标识其本身。公钥证书上的数字签名可以验证该公钥的可靠性以及持有它的那一方的可靠性。 数据完整性：通信双方必须确保内容在传送期间不被改变。数字签名是保证数据完整性的最常用技术。 数据机密性：有时候，通信数据是敏感的，必须保密。数字签名不提供数据机密性。我们必须使用数据加密。 不可抵赖性：消息发送之后，发送方随后应该不能否认它。数字签名提供了部分解决方案。如果以数字方式对消息进行签名，则发送方无法否认其责任，因为只有他能提供这种签名。 2、j2me安全机制简介 J2ME 平台是由配置（Configuration）和简表（Profile）构成的。配置是提供给最大范围设备使用的最小类库集合，在配置中同时包含Java 虚拟机。简表是针对一系列设备提供的开发包集合。在J2ME 中还有一个重要的概念是可选包（Optional Package），它是针对特定设备提供的类库。 目前，J2ME 中有两个最主要的配置，分别是Connected Limited Devices Configuration（CLDC）和Connected Devices Configuration（CDC）。他们是根据设备的硬件性能进行区分的，例如处理器、内存容量等。CLDC 主要针对那些资源非常受限的设备比如手机、PDA、双工寻呼机等。而CDC 主要面对那些家电产品，比如机顶盒、汽车导航系统等。简表是以配置为基础的，例如Mobile Information Devices Profile（MIDP）就是CLDC 上层的重要简表。 CLDC规范定义了3个级别的安全机制：底层安全机制，应用级别安全机制和端对端的安全机制。在这里有一点需要强调的是字节码验证过程。JVM 提供了防止恶意代码进入企业系统的服务，字节码验证过程保证了应用程序不能访问内存空间或使用其域外的资源。字节码验证还防止应用程序重载 Java 语言核心库，这是一种可以用来绕过其它应用程序级安全性措施的方法。但是，由于这种操作高昂的计算开销，MIDP VM 不在运行时执行完整的字节码验证，而是增加了预审和机制。要求应用程序开发人员必须在把应用程序部署到移动设备中之前，在开发平台上预先验证类。预验证过程优化执行流，创建应用程序中包含指令目录的堆栈映射（stackmap），然后将堆栈映射添加到经预验证的类文件。在运行时，MIDP VM 迅速地对字节码进行线性扫描，将每个有效的指令与合适的堆栈映射项相匹配。 此外在MIDP2.0中规定了许可和保护域概念。应用程序通过对敏感API 提出许可申请来试图获得相应的权限。提供了信任域与非信任域，不同的设备提供的保护域可能是不同的，一般我们开发的MIDlet都是存放到非信任域的。如果想成为可信任的MIDlet需要想一个可信任的组织提出认证申请。 关于更多详细的内容可以参看www.j2medev.com撰写的《j2me中文教程》，里面有对j2me安全机制的详细介绍。   3、Bouncy Castle Crypto API Bouncy Castle 是一种用于 Java 平台的开放源码