Java智能卡平台及其优化技术展望
- 格式：doc
- 大小：109.50 KB
- 文档页数：5
Java智能卡平台及其优化技术展望
摘要Java智能卡的跨平台、多应用、高安全的特性已经使它成为未来智能卡的标准,但这些优点是以牺牲应用的执行性能为代价。
本文分析了Java卡的平台体系及其存在的性能问题,在总结分析已有的典型优化方法的基础上,提出了未来优化的一些可行的方向,为相关研究人员提供有用的参考。
关键词Java智能卡;平台体系;内存管理模型;优化技术
引言
智能卡(smartcard)在包括电信、银行、公交、医疗、身份证件、数字电视、安全认证等与普通消费者息息相关的领域均获得了广泛的应用。
在未来移动支付、信用卡等更加普及、对个人信息安全有更高诉求的时代,智能卡仍将发挥不可替代的重要作用。
传统的Native卡存在先天缺陷,概括为如下3点:
1)应用开发的难度大、周期长、成本高:native卡以汇编或C语言进行开发。
缺乏通用开发平台,开发、调试困难,要求开发人员对硬件的底层细节熟悉;
2)不能很好的支持跨行业应用和一卡多用,而一卡多用是智能卡发展的趋势;
3)应用在卡发行时便已经固定下来,无法实现应用的更新或升级,无法满足客户个性化的需求,也使供应商在增值服务方面无法有所作为;
Native卡在互操作性和多功能应用上的不足,在应用开发时的高难度、高成本已经成为限制智能卡进一步发展的最大障碍。
在探索如何解决这些矛盾的过程中,以Sun为代表的公司开始尝试将更通用和安全的Java平台引入智能卡行业,Java卡便应运而生。
1Java智能卡平台
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、JavaFramework以
及架构在此上的应用程序Applet所构成,Java卡内部结构如图1所示:
1.1.2Java卡虚拟机结构
与Java平台相同。
Java卡实现跨平台和高安全的关键是虚拟机,同样受限与硬件资源,Java卡虚拟机(JCVM)和普通Java虚拟机(JVM)的最重要的区别就在于JCVM是一个分离的结构——卡外和卡内虚拟机:
如图2所示:卡外虚拟机部分主要包括一个conventer,它运行在PC或者工作站,主要用来装载和预处理输入的class文件.并将其转化输出为一种Java卡字节码文件(即CAP,ConvenedAp#et);卡内虚拟机部分包括Java卡字节码解释器Interpreter。
用来解释执行Java卡字节码文件。
两者结合,就构成了完整的Java 卡虚拟机,它们在卡外安装程序和卡上安装器的共同工作下,完成CAP文件下载、安装过程,如图3所示:
1.1.3 Java卡优点
Java卡的优点可以概括如下:
1)平台无关性和互操作性:通过Java卡虚拟机技术实现了跨平台和互操作的能力;
2)支持一卡多用,应用的动态下载及管理;
3)通用和开放:Java卡不但兼容了现有的智能卡行业标准,它还提供了一整套标准的API,使智能卡应用开发回到主流的面向对象编程,开发人员无需了解复杂的智能卡硬件和专用技术;
4)安全:Java卡继承了Java语言的安全特性,包括原子事务、应用防火墙等,从而提供了+安全高效的执行环境。
1.2Java智能卡内存管理和对象管理
1 2.1Java卡内存管理模型和对象类型
作为低端嵌入式设备的Java卡,内存是最宝贵的资源。
通常在Java卡内有3种存储体:
1)ROM:通常存储有Java卡虚拟机、API类库、卡内操作系统和卡商预先装入的applet等,并在发卡前将它们掩膜到ROM中;
2)RAM:断电后数据丢失,因此用来存储暂态数据,包括局部变量、方法参数、
中间运算结果等:
3)EEPROM:用来存储持久数据,包括下载到卡中的appletclass和创建的持久对象。
目前在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优化技术的探讨。
