智能卡中Java软件的开发

    如何去开发一个智能卡的java程序并运行它？第1件事是所开发的程序用于文本编辑器时能产生真正的java 源代码，然后用任何所期望的java编译器编译源代码，它产生与机器无关的字节码。到此为止，和用java对 pc机编程的过程是一样的。 

    现在，字节码作为类文件被传送到java虚拟机的卡外部分（卡外vivi），卡外vm检查其格式、语法、字段 基准和与程序有关的方面。如果所有这些检查都通过，则卡外vm建立起一个称为卡的应用cap（card application）文件。如有必要，可以随应用以数字签名的方式来提供，数字签名的提供保证了cap文件已被 卡外vm检查过并已被鉴明。如果这里不存在可以被验证的签名，则就将有可能用一个受操纵的支程序绕过卡 内vm的安全机制，因为在智能卡上没有足够的存储器能使卡内vm本身去进行所有的安全检查。在此之后，支 程序以cap文件的格式装入智能卡中。智能卡首先验证通常会存在的数字签名，一旦检验通过后就把支程序 传给卡内vm。在此之后所发生的事在很大程度上和pc机里的虚拟机执行程序的情况很相似。卡内vm逐行测试 并解释字节码，产生智能卡处理器的机器指令，这一过程如图1所示。 

    图1所产生的目标处理器的本机程序代码被执行后将产生相应的响应apdu，从命令apdu到响应apdu的数据流 程如图2所示。

    实际的过程，自然要比上面所述的要复杂些。希望程序员在接受到任务后不要立即开始java代码的编写， 相反，首先要分析和设计确定真正的需求。然后，才可开始编程。 

图1 从程序开发到智能卡微控制器中的java虚拟机执行程序的过程

图2 以java智能卡层次模型为参考的命令apdu和相应的响应apdu的数据流程

    为了在编码时或其后能迅速对差错定位，程序员可用一个智能卡java仿真器，这使其可对代码的执行逐步跟踪，去检验变量并方便而又迅速做出任何必需的纠正。这种仿真器的样例，如图3所示。

    与此有关的是，对于比较大型的和那些把安全性作为关键的项目要执行一些适当的测试。这些测试对命令和响应的所有成功的结果和最重要的错误结果进行检查。由独立方对源代码所做的检验也可包括在内。

    就像从此例中所看到的，用智能卡的java显著减少了编程所需时间，作为附带的效果它还降低了差错出现的机会。然而，编码本身仅仅是开发智能卡软件的许多部分之一。java对智能卡的主要好处是它使得许多不同的程序员可以共同开发智能卡的可执行程序，而不是少量的由卡制造商雇用的软件开发者。

    为了生产智能卡的java支程序，不仅应把操作系统的特殊性能考虑在内，同时还应顾及java卡2.0规范的性能特点，现将它们列举简述如下： 

    1）执行速度

    除了其存储量的要求外，智能卡java的关键要点还在于其较低的执行速度。然而，在汇编程序和java之间比较难以做出合理的折中，对此的主要理由是只要程序的行为在对终端的接口处相同并没 有绝对的必要像在汇编中那样去在java中建立起同样的处理过程。例如，对于java程序并不总是需要文件系 统，而且可能不会有任何人会用java来编写一个加密算法。 

    另一个普遍的考虑是应当尽可能多的在java架构中使用方法（method），因为它们是部分地使用目标处理 器的本机代码编码的，这样可导致处理速度的明显加快。作为一条准则，纯处理时间，不包括数据传输所需 的时间，可以假定为普通汇编程序的2～3倍。

    2）应用选择

    在java卡中选择一特定的应用相当于用其惟一的aid去选择相关的支程序。支程序在它被选中时就被调用， 所以它能进行任何必需的初始化。此后，支程序自动接收所有从终端发送至智能卡的命令apdu，如果支程序 未被选择，它就是非活性的并且也不涉及任何数据传送。

    3）防火墙——保持应用间相隔离

    从计算的观点看来，在智能卡中的各个支程序相互间是完全绝缘的，任何可能的相互影响都被java虚拟机 的安全管理器和智能卡操作系统所阻止。然而，一个支程序可以使它自己的数据对象在必要时为另外的支程 序使用，一个典型的例子是pin，它对卡中的所有应用（意即那些支程序）是同样有效的。

    4）交易完整性——原子进程（atomic processes）会话期间的突然断电必须不致引起支程序的数据处于未规定的状态。当一对象被修改时，这一点由虚拟机或操作系统隐含地予以保护。然而，如果必须无条件地保证跨越数个对象或过程时的完整性，则支程序的程序员可以采用那些专用的机制，使用这些机制，有可能确切保证所提及的这些对象或是保留在它们原来的状态，或是采取新状态。

    5）文件系统

    对于一个支程序并不强制它必须有自己的文件系统。对于某些应用，它完全合适于建立起与文件无关的数据对象，它们或是可用标准的命令访问或是用程序员自己定义的命令访问（私用命令）。没有文件系统的支程序的好处再次和过去已有的在智能卡中需要节约使用存储量联系起来。此外，java的面向对象的特性使得对数据对象的访问可按照其相关的调用条件来调用对象。在这方面，对某些应用有可能实现满足非常专门需求的访问。例如，该应用或用户有可能提供使其他方面继承他们的访问特权。

    尽管如此，对pc机和智能卡二者来说，通常现在的应用表明对数据的存储和管理仍经常采用面向文件的结构。这种选择并未被java卡规范所排除，因为它提供了它本身的关于iso/iec 7816-4，文件结构的类。这些接口也提供了兼容已有的具有标准文件树的应用的java智能卡基础。

     6）删除对象——持久的和暂时的对象

    所有的对象当它们是用new（）产生时，都一致被建立为EEPROM中的持久对象。持久性指的是一对象保存到会话期结束的能力，它和暂时性是相对的。持久对象在会话期结束和突然掉电两种情况下都能生存而不会丢失数据或连贯性。任何对象都只有在有指向它的引用时才存在，如果引用去掉了，虽然它仍旧占据着存储器然而对象实际上就不再存在了。对此的惟一的补救法是用一个具有碎片搜索的文件管理器，但是在java卡2．0规范中没有提供它，它占用的存储量太多。

    有可能把一个持久对象转换成暂时对象，然后可以把它放在ram中。转换只能在这一方向上进行。暂时对象的数据在现行会话期结束时会丢掉，然后用其标准值重新初始化。

    7）删除支程序

    java卡2.0规范没有提供在智能卡中删除支程序的机制。最多可以做到的是依靠其本身的功能来阻塞支程序，但是它所占用的存储器将永远失去，不能为别的支程序使用。

    在测试卡时，通常具有可以删掉存储区域中的整个支程序的专门功能，这种能力仅在调整和测试的环境中才能见到其存在，而不存在于已发行的供一般使用的“真正”卡中。 

    如果智能卡java虚拟机的未来版本能够包括一个碎片收集器，就将有可能从存储器中删除支程序。

    8）加密算法

    现在一般使用的许多加密算法或是做了些修改并在位水平上（诸如des）有所改变，或是使用了长数字（诸如rsa）的算术。目前，有java的智能卡不适合于用java对这些算法编程，这是由于其执行速度较低或存储容量有限的缘故。

    结果，在这些卡中通常有着javacardx，ct）rpto类，它们对用本机代码编程的算法的实现提供了一个接口（api）。例如，这样就使得具有三个独立的56位密钥的真正的3－des加密算法用相继三次调用适当的具有56位密钥的单重des算法得以用java编程。用java这样实现的3－des所提供的数据保护水平仅仅较用本机汇编代码所提供的约低30％。

    9）密码术和出口限制

    许多国家对具有通用操作系统并经内部接口可自由使用数据加密和解密功能的智能卡的出口是需要许可证的。这就是说，这些类型的智能卡完全不能出口到某些国家，或者必须等待数月之久以取得由负赍机关发给的适当的许可证才能出口。

    因此，在java卡中的加密功能的类被构造成它们可直接用于对一般数据的解密和mac计算但却不能加密。这完全适合于许多应用，因而在许多国家可以使用‘简化’的出口许可过程。

    然而，如果一特定的应用需要把数据加密，则卡制造商可把类…cryptoenc。des3ˉenckev和…cryptoenc．des－enckey包括在内，它使加密成为可能。不过，从纯粹的密码术观点看来，完全有可能轻而易举地实现自由地用于加密和解密的处理，而不必使用那些“加密”类。

    10）存储量的使用最少