JavaCard简介(中文版).docx

1、简介Java Card 3 平台由两个版本组成Classic Edition和Connected Edition：Classic Edition是一个基于2.2.2版本的前端兼容的演化平台，针对资源有限的设备仅支持applet-based应用。如果你只对Classic Edition中提供的功能感兴趣的话就可以忽略Connected Edition。Connected Edition提供了一个显著增强的运行时环境和一个新的虚拟机。包含了一些新的面向网络的应用，例如提供了针对web应用的Servlet APIs，并且支持一些新的applet功能增强。一个Connected Edition的应用可能会用到Classic Edition提供的特性，因此这两个版本的规范应用一起使用。1.1 动机Java Card技术使得用Java编程语言编写的程序可以运行在智能卡和其他小的资源紧张的设备上。开发人员可以用标准的软件开发工具和环境来编译和调试程序，然后把程序转化成能被Java Card支持的格式。Java Card上的应用程序被称为Applet，或者更明确的称为Java Card Applet或者Card Applet（为了和浏览器Applets做区分）。Java Card技术使得用Java语言编写的程序可以在智能卡上运行，然而如此小的设备远不足以支持Java平台的全部功能。因此，Java Card平台仅仅支持一个被仔细挑选，定制的Java平台属性的的子集。这个子集使得写的程序在小设备上有更好适应性，并且保持了Java语言的面向对象的特性。一个简单的途径是定义一个代码可以在所有Java Card环境下移植的Java虚拟机的子集。结合JVM的子集规定和信息，智能卡提供商可以在Java Card规范上构建自己的工具。虽然手段是可行的，但有一个严重的缺点，目标平台将会丧失字节码的移植性。Java平台的规范允许Java的代码在所有Java平台上移植，Java的“写一次，所有地方运行”的属性或许是平台的最重要的特性。部分Java Card平台创建的工作就是为了把这种代码移植性带到智能卡行业。在世界上有千百万的不同处理器和配置的智能卡，为支持软件派发所支持的多种代码格式的代价是不能承受的。这个Java Card的虚拟机规范（版本3.0.1Classic Edition)是提供代码移植性的关键。理解这个规范做了什么的一个方法是和Java平台的对应副本进行比较。Java虚拟机规范定义了一个引导和按指令集执行Java类文件的引擎。类文件是Java体系结构里面核心的部分，并且是代码移植性的支柱。Java Card的虚拟机规范（版本3.0.1Classic Edition）仍然定义了一个实现了Java Card平台代码移植性的文件格式：CAP文件格式是软件被导入到实现了Java Card虚拟机规范的设备的格式。1.2 The Java Card Virtual MachineJava Card虚拟机的角色在Java Card平台的生产和开发流程下很好理解。Java Card虚拟机和若干个组件组成一个Java Card系统，一个Converter(转换器),一个终端安装工具，和一个运行在设备上的安装程序。如下图1-1和1-2。开发一个Java Card应用和开发其它的Java程序一样：一个开发者写出一个或者多个类文件，应用使用模拟设备环境的模拟器模拟运行，测试和调试，包含应用的类文件被Java Card Coverter转化成一个CAP文件。Converter把构成一个Java包的所有类作为输入。一个包含了一个或者多个非抽象的直接或者非直接的javacard.framework.Applet的子类的包被称作一个应用包(appet package)。否则被称为一个库包（library package)。Converter也可以把一个或者多个导出文件（export file）作为输入。一个导出文件包含了被转化类需要的导入的其它类的名字和链接信息。当一个应用或者库包被转化，转化器也可以产生这个包的导出文件。经过转化，CAP文件被拷贝到一个卡片终端，例如一个带有读卡器设备的桌面计算机。然后一个在终端上的安装工具载入CAP文件并且传输到Java Card设备里。一个存在于Java Card设备上的安装程序接收CAP文件的内容并且准备好被Java Card虚拟机运行的应用。虚拟机自己不需要导入或者操作CAP文件，它只需要执行在被安装程序导入的CAP文件中发现的应用的代码。Java Card虚拟机和安装程序工程的区分使得两者都更小，安装程序可以被实现为一个Java程序并且在Java Card虚拟机的上层执行。因为Java虚拟机的指令比典型的机器码更稠密，这样做可以降低安装器的大小。组件性可以使得在一个Java Card虚拟机实现上可以使用不同的安装器。1.3 Java Language Security一个Java虚拟机的基本属性是通过类文件校验实现的强大的安全性。许多实现了Java Card平台的设备可能太小不足以支持在自己设备上的校验。这个考虑使得设计上允许在设备上认证但是并不信赖它。CAP文件中校验相关的数据被和应用执行的真正数据分开放置。到允许安全管理更灵活的被实现。在Java Card设备上有几个提供语言级别安全的选项。概念上最简单的是在CAP文件下载时和下载后验证文件内容。这个选项通常在比较大的设备上可行。其它的选项信赖一些捆绑的属性：安全终端的物理安全，在下载时候的算法校验过程，在下载之前预校验CAP文件。Java Card平台规范在CAP文件安装和安全规则这儿尽量的少说。因为智能卡在不同的安全需求的不同系统里作为安全的处理器，有必要允许很多灵活性来适应智能卡发行人和用户。1.4 Java Card Runtime Environment SecurityJava Card平台的标准运行环境叫做JCRE，JCRE由Java Card虚拟机以及Java Card API的类构成，既然Java Card虚拟机有保证Java语言层安全的责任，JCRE保证附加的运行态的安全。这部分的附加属性在JCRE规范中。JCRE最基本的运行态安全特性是用一个应用防火墙把应用隔离开。应用防火墙阻止一个应用创建的对象被其它的应用访问，阻止了对未授权的实例的属性和方法的访问（访问数组的长度类似）。应用的隔绝是一个重要的安全属性，但是它需要一个机制来允许应用间在需要内部操作的时候共享对象。JCRE允许使用共享接口对象（shareable interface object）的概念来进行这样的共享。这些对象提供了一个应用让它的对象可能被其他应用使用的唯一的方式。更多的使用共享接口对象的信息参见API手册中javacard.framework.Shareable接口的描述。一些防火墙相关的属性的描述为共享接口提供了一定的参考。应用防火墙还避免了对JCRE自身拥有的对象的未授权使用。JCRE可以使用不在JCAPI中体现的机制使得它的对象可以被应用使用。JCRE隔离和共享的相关属性可以在JCRE规范中得到体现。2、A Subset of the Java Virtual Machine2.1 Why a Subset is Needed典型的卡片设备只有1.2K的RAM，16K的非易失性存储（EEPROM or flash）以及32K-48K 的ROM。2.2 Java Card Platform Language SubsetJava Card平台的Applets用Java语言编写并用Java编译器编译。Java Card技术应用Java语言的一个子集。2.2.1 Unsupported Items2.2.1.1 Unsupported FeaturesDynamic Class Loading ,Security Manager ,Finalization ,Threads ,Cloning ,Access Control in Java Packages ,Typesafe Enums ,Enhanced for Loop ,Varargs ,Runtime Visible Metadata (Annotations) ,Assertions.2.2.1.2 Unsupported KeywordsNative, synchronized, transient , volatile ,strictfp , enum ,assert.2.2.1.3 Unsupported Typeschar, double, float, long, arrays of more than one dimension.2.2.1.4 Classes总之，没有任何的Java语言核心API类在Java Card平台获得完全支持。java.lang.package包中的有些类得到支持而剩下的则不支持，例如不支持String, Thread类，以及像Boolean ,Integer这样的包装类。SystemClass java.lang.System不被支持，Java Card平台提供javacard.framework.JCSystem作为系统功能接口。2.2.2 Supported Items如果一个语言特性没有被Java Card规范明确声明为不支持，那么它就属于支持子集的一部分，值得注意的支持特性在本节描述。2.2.2.1 FeaturesPackages, Dynamic Object Creation, Virtual Methods, Interfaces, Exceptions, Generics, Static Import, Runtime Invisible Metadata (Annotations)2.2.2.2 Keywords2.2.2.3 TypesJava的类型boolean, byte, short, int是被支持的，Objects（类的实例和一维数组）也是支持的，数组可以包含被平台支持的原始数据类型，对象和其它数组。有些java Card实现可能不支持int类型。2.2.2.4 Classes大部分java.lang package中的类在java Card平台中不被支持。下面的java.lang中的类被有限的支持。Object同Java语言一样，java Card平台API类继承于java.lang.Object，类Object中的大部分方法都无法使用，但是Object本身被作为继承系统的根得以保留。Throwable类Throwable和它的子类得以支持。在Java Card API中Throwable的大部分方法无法使用，但是类本身作为exceptions的祖先得以保留。2.2.3 Optionally Supported Items本节描述Java Card platform的可选特性。作为可选特性并不需要被一个Java Card platform兼容实现支持。但是一旦一个实现支持了一个可选特性，它就必须按照本规范来支持所有的可选特性。2.2.3.1 Integer Data Type2.2.3.2 Object Deletion Mechanism2.2.4 Limitations of the Java Card Virtual Machine 硬件资源的限制使得JCVM不能支持Java平台的所有特性。2.2.4.1 PackagesPackage References在一个包中可以引用最多128个其它包。Package Name包全名必须小于255字。2.2.4.2 ClassesClasses in a Package一个包中最多有255个类和接口。Interfaces一个类包括它的父类最多能实现15个接口。一个接口最多可以从14 个接口继承。Static Fields一个applet package中的类可以包含最多256个public or protected static non-final fields，一个库包中的类包含最多255个public or protected static non-final fields，而对static final fields无限制。Static Methods一个applet package中的类可以包含最多256个public or protected static methods，一个库包中的类包含最多255个public or protected static methods。2.2.4.3 ObjectsMethods一个类可以实现 128 个公共的或受保护的实例方法，以及带有软件包可见性的 128 个公共的或受保护的实例方法，包括继承方法。Class Instances一个类实例包括继承成员最多可以包含255个成员，一个int数据类型按照两个成员计算。Arrays数组最多可以包含32767个成员。2.2.4.4 Methods一个方法中最多可以使用255个变量，一个int类型当作两个局部变量。一个方法最多可以达到32767个JCVM字节码。JCVM字节码可能不同于JVM字节码。一个方法的最深操作数栈拥有255个16-bit单元。2.2.4.5 Switch StatementsThe format of the Java Card virtual machine switch instructions limits switch statements to a maximum of 65536 cases. This limit is far greater than the limit imposed by the maximum size of methods.2.2.4.6 Class Initialization2.2.5 Multiselectable Applets Restrictions 实现了javacard.framework.Multiselectable接口的Applets称为Multiselectable Applets，一个包中的Applets要么全是Multiselectable Applets要么全不是。2.2.6 Java Card Platform Remote Method Invocation(RMI) Restrictions2.2.6.1 Remote Classes and Remote Interfaces一个类是远程的则它或它的任一个父类实现了一个远程接口。远程接口要满足以下几个条件：接口名字是java.rmi.Remote 或者直接或间接继承自这个接口；远程接口或者其父接口中的每个方法定义的throws字句中包含java.rmi.RemoteException.在一个远程方法声明中，如果一个远程对象被声明为返回类型，则它应当被声明为远程接口而不是该接口的实现类。JCRMI为远程方法的定义强加了更多的限制。2.2.6.2 Access Control of Remote InterfacesJCRMI不支持包间可见的远程接口。2.2.6.3 Parameters and Return Values远程方法的参数只能是以下几种：Java Card支持的任何原始类型 (boolean, byte, short, int)；Java Card支持的任何原始类型的一维数组（boolean, byte, short, int）。远程方法的返回类型只能是以下几种： Java Card支持的任何原始类型 (boolean, byte, short, int)；Java Card支持的任何原始类型的一维数组（boolean, byte, short, int）；任何远程接口类型；Void类型。2.3 Java Card VM Subset Java Card技术应用了JVM的一个子集。2.3.1 Class File SubsetJava Card虚拟机可以操作以Java平台标准来定义类文件，因为JCVM只支持JVM行为的一个子集，所有它也只支持标准类文件的一个子集。2.3.1.1 Not Supported in Class FilesClass Access Flags在class_info和interface_info结构中access flag ACC_ENUM不被支持。Field DescriptorsField descriptors may not contain BaseType characters C, D, F or J. ArrayType descriptors for arrays of more than one dimension may not be used.Constant PoolFieldsIn field_info structures, the access flags ACC_VOLATILE, ACC_TRANSIENT and ACC_ENUM are not supported.MethodsIn method_info structures, the access flags ACC_SYNCHRONIZED, ACC_STRICT,ACC_NATIVE, and ACC_VARARGS are not supported.2.3.1.2 Supported in Class FilesClassFileAll items in the ClassFile structure are supported.Field DescriptorsField descriptors may contain BaseType characters B, I, S and Z, as well as any ObjectType. ArrayType descriptors for arrays of a single dimension may also be used.Method DescriptorsAll forms of method descriptors are supported.Constant PoolFieldsIn field_info structures, the supported access flags are ACC_PUBLIC,ACC_PRIVATE, ACC_PROTECTED, ACC_STATIC and ACC_FINAL.The remaining components of field_info structures are fully supported.MethodsIn method_info structures, the supported access flags are ACC_PUBLIC,ACC_PRIVATE, ACC_PROTECTED, ACC_STATIC, ACC_FINAL and ACC_ABSTRACT.The remaining components of method_info structures are fully supported.AttributesThe attribute_info structure is supported. The Code, ConstantValue,Exceptions, LocalVariableTable, Synthetic, InnerClasses,RuntimeInvisibleAnnotations, RuntimeInvisibleParameterAnnotations and Deprecated attributes are supported.2.3.2 Bytecode Subset2.3.2.1 Unsupported Bytecodes2.3.2.2 Supported Bytecodes2.3.2.3 Static Restrictions on Bytecodes一个类文件的静态字节码必须遵守以下限制：ldc, ldc_wldc, ldc_w只能被用于装载整型常量。常量池的入口必须是一个CONSTANT_Integer入口，如果一个程序含有的指令用于装载小于-32768或大于32767的整型常数，那么程序需要额外的整形指令支持。lookupswitchnpairs 操作数的值必须小于65536，这个限制远远大于对方法的强加限制。如果一个程序使用了含有int数据类型的lookupswitch指令，那么程序需要额外的整形指令支持。另外，这个int类型的值必须位于-32768和32767之间。Tableswitch字节码可以包含最多65536字，这个限制远远大于对方法的强加限制。如果程序不使用额外的整形指令支持，high和low操作数的值必须位于-32768和32767之间。wideThe wide bytecode can only be used with an iinc instruction2.3.3 ExceptionsJava Card平台支持Java 平台的所有异常机制，用户可以像在Java 平台中一样define, throw and catch异常。不是所有的Java 平台异常都在Java Card平台中得到支持。与那些平台不支持的特性相关的异常自然也不会得到支持。类装载异常（大部分强制异常）不被支持。请注意，有些异常可能予以支持，如果可以认为他们的出错状态能够被正确的检测，当然会发生这种异常的类不会被放入API中。可以被支持的异常子集描述在下表中。2.3.3.1 Uncaught and Uncatchable Exceptions在Java平台中未捕捉的异常和错误会引起当前线程退出，而Java Card平台是单线程的未捕捉的异常和错误会引起JCVM停顿。虚拟机对这种停顿之后的处理属于虚拟机实现的具体策略问题。有些出错状态是不可恢复的。抛出一个不能被捕捉的运行时异常或错误也会引起虚拟机停顿，对于这种未捕捉的异常，当虚拟机停顿以后具体的平台实现机制应该给出更多的相应。被Java Card平台支持的那些无法捕捉的异常和错误可能不会反映在API中，虽然Java卡平台将正确地检测到错误条件。2.3.3.2 Checked Exceptions2.3.3.3 Runtime Exceptions2.3.3.4 Errors3、Structure of the Java Card Virtual Machine在Java卡虚拟机规范在许多方面是与Java虚拟机十分相似的，这种相似当然是故意的，Java卡虚拟机的设计是以Java虚拟机为基础的。所以本规范主要在于描述JCVM与JVM不同的新特性。3.1 Data Types and ValuesJCVM和JVM一样支持两种数据类型：primitive types and reference types.同样，这两种类型通过primitive values and reference values来使用。JCVM支持的原始数据类型有：numeric types, the boolean type, and the returnAddress type.numeric types包括：byte, 8位有符号二进制的补整数short,16位有符号二进制的补整数有些JCVM实现支持附加的整型类型：Int,32位有符号二进制的补整数JCVM对boolean 和reference类型的支持同JVM一样。3.2 WordsJCVM按照称为“字”的抽象存储单元来定义。此规范并未规定一个特定的平台上，一个字的实际大小。一个字的大小应该足够容纳一个byte, short,reference, returnAddress类型的值，双字应该能容纳一个int类型的值。实际的存储情况是与平台实现相关的。CAP文件的描述组件中有足够的信息使得平台实现者可以优化变量的存储以及堆栈使用。3.3 Runtime Data AreasJCVM只支持单线程运行。基于每个线程复写的任何运行时数据区将只有一个在JCVM中的全球副本。JCVM堆栈不需要垃圾回收，从堆中分配的对象并不一定被回收。本规范不包括对本地方法的支持，因此不存在本地方法堆栈。另外，运行时数据区是为虚拟机做记录的。3.4 Contexts每个运行与JCVM上的applet都与一个运行上下文相关联。JCVM使用当前帧的上下文来实施applet操作的安全策略。定义applet的包与其上下文是一一对应的关系，一个简单的看法就是上下文和一个包的运行时等价，因为Java包是编译时结构，并在运行时没有直接的代表，所以来自同一个包的applet实例共享同一个上下文。JCRE也有自身的上下文，框架对象运行于JCRE上下文中。正在运行中的方法的上下文称为当前上下文，JCVM中的每个对象都属于特定的上下文。对象创建时的当前上下文就是对象的所属上下文。当一个上下文中的方法成功调用了另一个上下文中的方法时，JCVM就要进行上下文切换。之后被调用方法的上下文称为当前上下文，当被调用的方法返回后，上下文再次切换回调用以前的上下