Java智能卡平台及其优化技术展望

王同洋，赵 磊

华中科技大学，湖北武汉 430074

0 引言

智能卡（Smartcard）在包括电信、银行、公交、医疗、身份证件、数字电视、安全认证等与普通消费者息息相关的领域均获得了广泛的应用。在未来移动支付、信用卡等更加普及、对个人信息安全有更高诉求的时代，智能卡仍将发挥不可替代的重要作用。

传统的Native卡存在先天缺陷，概括为如下3点：

1）应用开发的难度大、周期长、成本高：native卡以汇编或C语言进行开发，缺乏通用开发平台，开发、调试困难，要求开发人员对硬件的底层细节熟悉；

2）不能很好的支持跨行业应用和一卡多用，而一卡多用是智能卡发展的趋势；

3）应用在卡发行时便已经固定下来，无法实现应用的更新或升级，无法满足客户个性化的需求，也使供应商在增值服务方面无法有所作为；

Native卡在互操作性和多功能应用上的不足，在应用开发时的高难度、高成本已经成为限制智能卡进一步发展的最大障碍。在探索如何解决这些矛盾的过程中，以Sun为代表的公司开始尝试将更通用和安全的Java平台引入智能卡行业，Java卡便应运而生。

1 Java智能卡平台

Java卡是一种可以运行Java程序的微处理器智能卡，在卡中运行的程序叫Java Card Applet。Applet可以由用户动态装载到卡上。Java卡是Java体系中最小的一个平台，Applet可以在任何符合Java卡规范的卡上运行，主要规范包括：Java卡虚拟机规范（JCVM），编程接口规范（API）和运行时环境规范（JCRE），目前最新的规范是3.0版本。

1.1 Java卡体系结构及优点

1.1.1 Java卡体系结构

Java卡的内部结构由 COS、Native Functions、Java VM、Java Framework 以及架构在此上的应用程序Applet所构成，Java卡内部结构如图1所示：

图1 Java卡体系结构

1.1.2 Java卡虚拟机结构

与Java平台相同，Java卡实现跨平台和高安全的关键是虚拟机，同样受限与硬件资源，Java卡虚拟机（JCVM）和普通Java虚拟机（JVM）的最重要的区别就在于JCVM是一个分离的结构——卡外和卡内虚拟机：

图2 Java卡虚拟机分离模型

如图2所示：卡外虚拟机部分主要包括一个converter，它运行在PC或者工作站，主要用来装载和预处理输入的class文件，并将其转化输出为一种Java卡字节码文件（即CAP，Converted Applet）；卡内虚拟机部分包括Java卡字节码解释器Interpreter，用来解释执行Java卡字节码文件。两者结合，就构成了完整的Java卡虚拟机，它们在卡外安装程序和卡上安装器的共同工作下，完成CAP文件下载、安装过程，如图3所示：

图3 CAP文件下载安装过程

1.1.3 Java卡优点

Java卡的优点可以概括如下：

1）平台无关性和互操作性：通过Java卡虚拟机技术实现了跨平台和互操作的能力；

2）支持一卡多用，应用的动态下载及管理；

3）通用和开放：Java卡不但兼容了现有的智能卡行业标准，它还提供了一整套标准的API，使智能卡应用开发回到主流的面向对象编程，开发人员无需了解复杂的智能卡硬件和专用技术；

4）安全：Java卡继承了Java语言的安全特性，包括原子事务、应用防火墙等，从而提供了一个安全高效的执行环境。

1.2 Java智能卡内存管理和对象管理

1.2.1 Java卡内存管理模型和对象类型

作为低端嵌入式设备的Java卡，内存是最宝贵的资源。通常在Java卡内有3种存储体：

1）ROM：通常存储有Java卡虚拟机、API类库、卡内操作系统和卡商预先装入的applet等，并在发卡前将它们掩膜到ROM中；

2）RAM：断电后数据丢失，因此用来存储暂态数据，包括局部变量、方法参数、中间运算结果等；

3）EEPROM：用来存储持久数据，包括下载到卡中的applet class和创建的持久对象。

目前在Java卡中执行应用时，Java卡虚拟机调用new指令创建对象，并默认存储于EEPROM中。对象包括两类：

1）暂态对象（Transient Object），它分为两种类型：CLEAR_ ON_RESET和CLEAR_ON_DESELECT。通过调用Java卡API来创建，并存储在RAM中，断电后对象的字段（field）值、字段类型等数据自动丢失。CLEAR_ON_RESET类型的对象在一次会话期间或进行applet选择切换时会保存下来，但进行复位操作时被复位为默认值；而CLEAR_ON_DESELECT类型的对象无论是复位操作还是applet选择切换，都无法保存。对暂态对象的操作不是原子的；

2）持久对象（Persistent Object）：由new操作符创建，并默认存储在EEPROM中，它在卡被拔出后依然存在。对持久对象数据的操作必须是原子的，即更新操作要么全部完成，要么中断更新并回滚恢复到原来的状态；

无论是暂态对象还是持久对象，当没有其他任何对象引用它时，该对象就不再可以访问，也就成为垃圾，但它们所占据的空间只有被回收后才能再次利用。

1.2.2 现有模型的性能问题

在字节码文件下载解析过程中，以及虚拟机执行应用的过程中都遭遇了性能问题，而其中消耗绝大部分执行时间的是EEPROM写操作，原因总结如下：

1）为了支持持久对象的原子性操作，保证数据的完整性，Java卡在EEPROM中开辟了一块特殊的存储区域来存储原有的数据，以执行数据的回滚。将旧有数据写入Transaction-Buffer的次数占据了所有EEPROM写操作的75%～80%，而写EEPROM的时间为3ms～10ms，比RAM慢1 000倍；

2）写EEPROM操作采用了机制，即先将数据写入Page-Buffer，然后再写入EEPROM，清除Page-Buffer后再重复下一次的写过程。这种写入—删除—再写入的机制在大量写操作时是十分缓慢的；

3）在下载CAP文件时，对常量池等组件的解析过程在EEPROM中完成。同样的，虚拟机在执行applet实例的时候，大部分对象的创建也是在EEPROM中完成，两者都产生了大量的EEPROM写操作。

2 优化技术的探讨

2.1 已有的典型优化技术

为了解决Java卡的性能问题，研究人员提出了一些典型优化方法，分析归纳如下：

1）在Java卡虚拟机分离模型的基础上，采用分离模式的CAP文件解析优化方案，即将静态解析过程放在卡外执行，该过程只访问CAP文件，而无需访问卡内资源。将动态解析过程留在卡内进行，该过程必须获得卡内资源才能完成解析。最后设计一种伪指令集来衔接优化后的解析执行过程 ；

2） 改 进Java卡 已 有 的 事 务（transaction） 机 制，将Transaction-Buffer分配在RAM中，并将事务开始后的新数据写入这个Buffer。如果事务顺利完成，则将其中的数据写入EEPROM并替换旧数据；如果事务中断，比如卡被拔出等，由于RAM的易失性，Buffer中的数据自然消失，而EEPROM中原始的数据也并没有被更改，也就保证了数据的完整性。该方法大大减少了对EEPROM的写操作，很好的提高了应用的执行性能。不足之处是加大了对本就稀有的RAM资源的开销；

3）引入cache策略，改进传统的写EEPROM机制。这个方法的基础是Java卡在执行应用期间，写操作的数据拥有高度的局部相似特性（即cache拥有较高的命中率），基于这个特性，在传统的Page-buffer的基础上在RAM中增加一个Object-buffer，并通过引入cache策略，从而在大量写操作发生的时候可以大幅度提高性能；

4）改进对象模型，将applet实例和静态数据成员之外的大部分对象都存储在RAM中，而非传统的EEPROM中。该方法需要在编写applet时考虑到数据的持久性要求，如事务平衡值，并将这些数据成员的类型设为static，从而将其保存在永久性的EEPROM中。需要指出的是该方法对RAM空间有较高的要求[5]；

5）采用压缩算法对字节码文件进行优化或对字节码文件中的Method组件的指令码进行折叠优化。但这些方法对有标准格式要求的字节码而言，优化的空间有限且往往会产生优化的负效应[6]。

2.2 优化方向的探索

2.2.1 优化的目标

1）提高应用的下载、安装速度：减少CAP解析过程对EEPROM的写操作次数，从而提高Java卡对CAP文件的下载解析速度；

2）提高应用的执行性能：减少applet生命周期过程中对EEPROM的写操作次数，提高applet的执行性能；

3）提高内存使用率：减少内存碎片和提高空间回收效率，从而更加高效的利用宝贵的Java卡内存资源。

2.2.2 可行的技术方案

1）实现新的对象模型和新的堆存储区模型，保证有一种合理的算法实现对EEPROM（或Flash）和RAM堆空间的高效管理；

2）优化传统的事务机制，在保证持久对象的原子性和一部分敏感暂态数据的安全性的同时，减少事务机制带来的性能负效应；

3）探索一种能用于智能卡的合理高效的cache算法，配合写入策略（Normal Write & Tear-Proof Write）来优化现有的EEPROM写入机制；

4）围绕对象模型，对现有的Java卡堆栈操作指令，以及涉及对象管理和事务机制的API进行分析，对其中实现效率不高的进行优化、合并或扩展，或直接在底层用native代码实现，从字节码指令层提高应用的执行性能；

5）设计一种新的CAP文件解析策略，结合RAM空间的使用，减少在CAP文件下载和安装过程中对EEPROM的写操作，提高下载和解析的速度。

2.2.3 技术方案的评估

在设计新的算法或方案对Java卡平台进行优化之后，需要有一个合理的评估方案实现对优化结果的测评以考察其有效性[7]。性能评估从两个方面进行：

1）Java卡正常使用（事务正常完成）的应用执行性能，需对如下几个方面进行测评：

（1）内存管理：包括对象创建和数据更新时的堆栈读写等；

（2）指令的派遣和执行。

2）整个平台的性能，包括平台特性和在非正常情况下Java卡的性能表现（即事务中断），可以细分为对如下几个环节的测评：

（1）应用的下载和安装速度；

（2）内存回收策略：包括对象删除和垃圾回收等的效率；

（3）JCRE：事务中断，即发生数据回滚时的性能表现；

（4）API：Java卡API方法的执行效率。

3 结论

Java卡分离的虚拟机结构和有限的内存资源决定了Java卡应用的执行性能无法与Native卡相比。随着Java卡应用领域的不断拓展（如在3.0规范中推出的基于Java卡的Web Server应用），对Java卡的性能提出了更高的要求。随着Java卡处理器性能的提升和内存资源的丰富，在压缩字节码、优化内存管理算法等传统优化途径之外，在卡中实现垃圾收集器和数据库管理系统（DBMS）也都将成为合理的优化手段，以不断提高Java卡的性能。

[1]ZhiqunChen，JavaCardTechnologyforSmar tCards：ArchitectureandProgrammer’sGuide，Addison-Wesley，2000.

[2]M.Oest reicher，K.Ksheeradbhi，ObjectLi fetimesinJavaCard，Proc.UsenixWork-shopSmar tCardTechnology，UsenixAssoc.，Berkeley，Calif.，1999:129-137.

[3]常青，靳伟，李春龙，张其善.JCVM解析优化设计与实现[N].北京航空航天大学学报，2004,30(12).

[4]Min-SikJin，Won-HoChoi，Yoon-SimYang，Min-SooJung，AStudyonFastJCVMwithNewTransactionMechanismandCaching-BufferBasedonJavaCardObjectswithaHighLocality，InternationalFederationforInformationProcess（IFIP），2005.

[5]Min-SikJin，Min-SooJung，AStudyonFastJCVMbymovingobjectfromEEPROMtoRAM，Proceedingofthe11thIEEEInternationalConferenceonRTCSA，2005.

[6]ClausenL.R.，SchultzU.P.，ConselC.，JavaBytecodeCompressionLow-EndforEmbeddedSystem，InACMTransactionsonProgrammingLanguagesandSystems，2000，22(3).

[7]PierreParadinas，SamiaBouzefrane，JulienCordry，HowtomeasuretheperformanceofJavaCardPlatforms，CEDRICLab.CNAM(Paris)，2007.