JavaME安全策略（一）：使用APDU API与加密硬件通信[1]

【无忧考网 - JAVA】
Java ME提供了大量密码学接口，包括Java加密体系结构（Java Cryptography Architecture，JCA）和Java加密扩展（Java Cryptography Extension，JCE）；而Java ME的基本实现却不包含这些接口。这有多方面的原因，既有技术上的也有法律上的原因；内存占用和计算复杂性使一些Java ME设备难以实现加密，而且如果Java ME绑定了强大的密码学解决方案，那么将限制出口，这就阻碍了一些市场对JavaME的采用。
然而，Java ME的可扩展性质却未受到限制。JSR 177定义了针对J2ME的SATSA（Security and Trust Services API，安全性和信任服务API）。除了支持加密操作，SATSA还包括针对Java ME的可选组件，提供了用于与硬件安全组件通信的API，以及用于证书和签名管理的API。SATSA定义了设备可能支持的4个重要的可选包。
qAPDU（Application Protocol Data Unit，应用协议数据单元）：这个通信API支持应用程序与密码硬件（比如Java智能卡）之间的低级通信。
qSATSA-JCRMI（SATSA-Java Card RMI）：这个通信API支持应用程序与Java智能卡之间的高级通信。
qSATSA-PKI（SATSA-public key infrastructure，SATSA公钥基础设施）：此API支持管理公钥。
qSATSA-CRYPTO：此API提供了java.security包的加密子集。
APDU协议构建在GCF之上，它提供了与Java智能卡、通用用户标识模块（Universal Subscriber Identity Module，USIM）以及安全令牌智能卡通信的通用接口。APDU接口适用于低级通信，它在与加密硬件交换的单个字节上进行处理；对于许多应用程序，SATSA-JCRMI API可能更适合。另外两个API（SATSA-PKI API和SATSA-CRYPTO）为应用程序提供了高级的加密服务。

一、使用APDU API与加密硬件通信
如今的智能卡能够保护许多流行的消费电子设备，包括一些电话、计算机、消费电子机顶盒。它们也是一些行业通信控制系统的重要安全特性。智能卡本质上只是一个小塑料片，其中嵌入了一个或多个硬化的电路，用于提供内存以及可能的处理能力。智能卡通常包括防篡改属性（比如安全文件系统）、一个安全的微处理器以及肉眼可见的篡改识别设备，比如全息图或其他信息。一些智能卡支持密钥生成以及密码算法等加密功能；SATSA API的用途是支持使用受Java ME支持的硬件访问这些卡。
在最低的硬件水平上，Java智能卡或USIM等硬件使用位和字节通道与其主机硬件通信，这种通道类似于网络套接字或串行端口。国际标准化组织（ISO）提供了ISO 7816来描述智能卡与其主机硬件之间的机械、电子和软件通信模式。软件模式依赖于应用程序标识符（AID）的概念，允许选择指定的智能卡功能；与智能卡的通信使用ISO定义的应用协议数据单元（Application Protocol Data Unit）来完成（SATSA包使用APDU作为该协议的名称与智能卡通信）。
由于这种对智能卡功能的低级别访问包括在通信渠道上交换字节，你可能认为Java GCF会提供一种出色的方式来支持这种通信，确实如此。
由SATSA包提供两个接口（java.microedition.apdu.APDUConnection和javax.microedition. jcrmi.JavaCardRMIConnection）为应用程序提供了与智能卡通信的方式。顾名思义，APDUConnection用于执行与智能卡的低级APDU交互，而JavaCardRMIConnection用于执行到Java智能卡的Java RMI——我将在15.2.2节讨论此主题。
就像使用GCF访问FCOP或网络接口时一样，你首先使用一个URI（Uniform Resource Identifier，统一资源标识符），它描述了应用程序将要连接到的实体。对于智能卡，URI具有如下形式：
每个部分的定义如下。
qprotocol：对于基于APDU的连接，此值为apdu（返回一个实现APDUConnection的对象）；对于基于JCRMI的连接，此值为jcrmi（返回一个实现JavaCardRMIConnection的对象）。
qslotid：一个整数，指示用户插入智能卡的插槽。
qtarget：要连接到的指定智能卡应用程序的应用程序标识符，或用于连接到JAVA