前言
Java语言具有的跨平台特性,如果它能被使用在Smart Card的世界中,那它将可以建立一个统一Smart Card开发标准并增加更多可移植性,以及借着下载applets的方式来达到动态功能更新的目的。利用Java来做为开发Smart Card的语言是否可行?或者这只是个梦?这一切如果要成为事实,那必须有赖一个详细的实作规格的建立,而不只是喊喊口号而已。
什么是Java Card?
Java Card就像是一般的Smart Card一样,它符合所有Smart Card的标准,因此,对于目前一些Smart Card-aware的应用方面来说,它也可以支持Java Card而不需要做任何改变。那为何这种card叫做「Java Card」而不称为Smart Card?主要原因是Java Card的实作语言是以Java的开发环境为主,所以Java Card的code是种bytecode。它也是需要JVM (Java Virtual Machine,Java虚拟机)来做为执行的工具。
在Java Card中,它的JVM (Java Virtual Machine)是实作在它的只读存储器(ROM)中,因为这种Java Card的独特性质,使它和一般Smart Card不同。因为Java Card内建了JVM,所以JVM的各种组件(component)可以存取所有Smart Card的一切资源(例如内存与I/O),并且可提供了一般Smart Card的操作系统(OS)所提供的一般性服务。除此之外,Java Card也利用Java的bytecode来执行对外界的通讯行为(例如:签证、登入等)。其架构如(图一)所示:
Java Card的发展观念约在1996年便已经开始,那时是由一个Smart Card的制造商-Schlumberger所展示这发展的可能性。不过在那时候的构想上还有许多问题尚待克服,其中有两个主要缺点存在。第一、那时候Java的应用程序所能用于存取系统功能的函数不多,所以无法利用Java去建立一个完善的Smart Card系统;第二、Java Card必须使用它自己的card上的文件系统去下载Java相关资源,以及常常要对数据做确认与储存的工作,这种运作方法对面向对象的作业环境来说显然是不适合的。
那使用Java Card和使用Smart Card有何不同?这些不同其实是很明显的,那就是Java Card可以让程序写作具有跨平台特性,不因card的架构不同而必须重新撰写程序,这种优点比一般Smart Card多了可移植性。所以各位也许会想,那既然Java Card有这个好处,为何现在还不全面使用?刚刚前面说的就是原因之一,而另一个主要原因是安全方面的考虑。不过随着时间的流逝,现在厂商已经将这些Java Card的功能更加以延伸了,它不但更具有安全性,且在网络存取时,Java Card可以为您的银行帐户做到更好的保密。
虽然到目前为止,我们还不清楚这种跨平台的Java Card会长的什么样子。不过Sun Micro- systems在1996年率先发布第一个Java Card的规格出来,而它所根据的就是那时Schlumberger的实验方式。不过和他们不同的是规格中限制了Java Card的一般性目的与架构,但它仍提供一般Java语言方面的支持能力,并提供Smart Card专用的编码函数。
1997年的Java Card论坛中,制定了Java Card 2.0规格。在这个2.0规格中,它含有更具体的API规格(例如:编/译码的函数实作)与一个比JVM更小巧的JCVM (Java Card Java Virtual Machine)。不过在不同Java Card 的Java code之间与可移植性方面还有问题存在,这些不兼容的问题有些甚至存在于source code层次上面。举例来说,Java Card文件系统的API规格并未普及化,这对那些享有Java Card文件系统专利技术的厂商来说,还是会有不兼容的情形出现。除此之外,编码的函数的缺乏与对不同国家的转换通融性方面,Java Card都还有待改良。所以,因为API方面的实作规格不够详细,导致较复杂的Java Card应用程序函数无法在不同Java Card之间流传应用。
新的Java Card规格
1998年的4月,VISA发表了一个VISA OpenPlatform (VOP)的Smart Card规格,这个规格是为了因应Smart Card的多程序时代的来临所制定。1999年VISA公开VOP的标准,并将它改名为开放式平台2.0(OpenPlatform 2.0, OP)。因为OP标准的开放,促使了ETSI标准化会议选择用OP来当作GSM移动电话之SIM卡的管理标准。OP之所以被重视,是因为Sun或是Java Card论坛,他们都没有为applet建立一个安全的下载标准,而VISA的OP是第一个真实标准的建立者。不过这不意味它对Java Card而言是完备的,因为它也没有为Java Card的应用程序之程序代码文件格式或是指令集(instruction set)下一个定义。这两个东西在1998年的Java Card相关会议里面,是一个重要的讨论议题所在。
有关OP安全方面的概念是着重在对那些多程序卡的软件提供者的角色上面,包含卡的操作系统提供者、制造者、发行者与applet提供者。它必须能确保一旦Smart Card离开制造者之后,只有发行者可以控制Smart Card的内容与使用。OP对于这点,它引入了一种「CardDomain」的观念,它可以让发行者以编码的方法来控制card的存取功能,并决定是否可以下载新的applets。
OP允许不同的applet提供者能在同一张card内运作,除此之外,在OP中还有一个管理安全方面功能,称为「Security-Domain」。这个SecurityDomain和前面说的CardDomain是有点不一样的,连发行者都不知道SecurityDomain的applet code,SecurityDomain可视为一种独立单位。
虽然OP对Java Card的发展工具影响不大,对程序而言,设计师还是必须经由标准的Smart Card终端机,将Java Card CAP (Cardlet Package)档案转换成为Smart Card通讯命令序列,也就是应用程序数据协议单位(application data protocol units,ADPU)。当CardDomain接受数据之后,它就会加载并链接新的applet到card中。
在1999年3月,Java Card 2.1(JC21)的规格被制定出来,它为Java Card的bytecode提供一种称为「code signing」的认证机制,这种认证机制可以被使用在下载方面的安全上。除此之外,Java Card它还引入一种新的观念,那就是「软件防火墙机制」。所谓软件防火墙机制就是说,Java Card的对象可以利用他们的applets相互联系,而每一个对象在另一对象上面的存取权都必须经过JVM的核对,利用这种方式可以增加Java Card安全上面的保障与减少非法存取的可能性。到了1999年的11月做左右,许多新的规格都已经纷纷出笼,例如
●Java Card 2.1 API规格
●Java Card 2.1 Runtime Environment (JCRE)规格
●Java Card 2.1 Virtual Machine (JCVM)规格。
●Java Card 2.1 规格的发行注意事项。
这些都可以在http://java.sun. com/products/JavaCard/找到。
Java card 2.1的延伸功能
JCRE定义了applet执行的相关环境方面的细节问题。
Java card 2.1的虚拟机规格定义了binary的可移植性标准,这标准包含了Java card语法的子集合、JCVM规格与在Java card程序中的binary表示法。
Java card 2.1 API规格主要是修正自Java card 2.0 API规格,它保留了一些基本Java card 2.0的API函数,并且加入了一些新的应用函数(例如︰新的Java Card. security与JavaCardx.crypto套件),以加强Java card的安全保密与可移植性功能。这些API函数与指令参考都可以在上述网站找到。而要为Java Card发展应用程序的方法有许多,一个是自己用一般Java开发工具来撰写函数,另一个方法便是使用Java CardTM 2.1 Development Kit来直接呼叫JC21的API函数。有关这Java CardTM 2.1 Development Kit,各位可以去Java.Sun.Com的网站下载。
Java Card的架构简化
一般比较便宜的Smart Card所含有一些芯片,可能是一个256Bytes的随机存取内存(RAM),与16KBytes的只读存储器(ROM)以及4~8KBytes的可抹写、可程序化内存(EEPROM)。不过这规格不是统一的,例如Rolls Royce的Smart Card硬件架构是一个4KBytes的RAM,一个64KBytes的ROM与一个64 KBytes的EEPROM。虽然他们的的架构上面有所不同,但是在编码上面大都采用DES式或是RSA的编码方法。
这些Smart Card的架构成本关系到Java Card的设计。为了减少成本,许多厂商与Java Card论坛将Smart Card的某些硬件架构,定位在较便宜的芯片可负担的情况下。因为这种因素,导致Java Card必须不能有太多复杂的数据结构。对Java Card而言,浮点数(float)、双精确数(double)与长整数(long)的数据型态将不再被支持。不过还好这些限制,并不会对Java Card的程序写作有太大影响。
Java Card的运作和一般Smart Card是没有什么不同的,也就是说,Smart Card读取器可以对Java Card送出命令,而Java Card会在处理这个命令之后传回结果,就如同一般使用Smart Card一样。不过为了和目前的Smart Card应用程序兼容,Java Card目前只能一次处理一个命令。Java Card applets的实作可以用各种不同的Java发展环境来完成,例如JDK(Java Developer's Kit)、VisualCafe、JavaBuilder、Visual Age等等。完成之后的applets程序代码可以在一般JVM机器上面执行,但是存取动作只限于Smart Card特定界面才可以。
Java Card转换的优化
因为JVM的执行效率比一般原生码来得慢,因此要改善Java Card的byte code转换效率,可以基本上有两个技术:
将指令集优化
如果单纯只改变标准JAVA指令集,可能还达不到我们所要求的效率,不过这却是改良Java Card系统效能上一个可行的方法。作法就是:
1.移除不支持的数据格式指令:将移除之后的剩下指令当作是Java Card的opcodes (operation codes),这样可以让Java Card的JCVM实作上更有效率。
2.Java Card内定只支持短整数运算,因此你可以将Java内的整数集合重新定义,只留下短整数型态。
将数据格式优化
要定义Java Card的文件格式,便避免不了面对复杂的数据结构与讯息链接的安排工作。将这种数据结构重新定义的一个最大用处,就是希望能将Java Card使用到的内存单元减到最小以及让访问时间变短。Java Card的时间存取瓶颈诸要是出现在经由缓慢的Smart Card链接上面去下载数据时,而内存的瓶颈主要出现在下载的Java Card的CAP对随机存取内存之需求与那些需要储存在EEPROM-based的applet执行讯息上面。因此要将Java Card做优化的改良,便可以从时间与内存需求减少方面着手。
结语
到目前为止,Java Card的梦想虽然尚未实现。不过许多讨论依旧在Java Card论坛(http://www. JavaCardforum.org)上面热烈展开,他们还在考虑许多有关Java标准实作的各种观念。虽然Java Card还未真正出现在市面上,但我相信Java Card的出现只是时间问题。