前言

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的架构》

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的出现只是时间问题。