|
JavaCard |
Native |
|
|
功能特性 |
||
|
开发语言 |
l 纯面向对象的Java语言的子集。 Java语言先进灵活，开发调试速度快，实现灵活。 l Java没有指针，并且有内部安全机制可以有效的避免越界访问造成的程序的错误和崩溃。 l 所有的变量在Java中创建时，都会被自动进行初始化。 |
l 汇编和标准C，面向过程的语言。 l 汇编语言作为机器语言，比较晦涩，开发速度慢，使现有局限，但是运行速度快，效率高。 l C语言有指针，可以灵活的实现各种内存操作，但容易因为越界访问造成错误和崩溃。 l C中的变量需要手工初始化，容易因为忽略造成错误。 |
|
体系构架 |
分为两层结构。 l 底层为按照JavaCard规范实现的JavaCard平台，向上提供规范定义的接口（API），通常支持JavaCard API和GP API。 l 上层为按照应用需求开发的Applet，相当于Native卡片上的ADF。可以根据不同类型的应用，开发多个Applet。这些Applet相互独立，通过AID来选择。 |
统一通过卡片操作系统（COS）来实现所有的功能。 l COS内部也按照功能的不同，分为多个层次，包括应用层具体交易APDU的实现，通讯协议层的实现，以及和芯片的具体交互等等。 l 通常通过创建不同的ADF文件的方式，来区分不同的应用。 |
|
应用(ADF)选择 |
l JavaCard规范定义，只支持通过AID选择应用（ADF）。 l 在应用内部，可以通过程序实现，用AID或者DFID选择ADF。 |
l 可以通过AID或者DFID选择应用(ADF)。 |
|
个人化流程 |
JavaCard规范推荐统一的通用个人化流程(CPS)，在创建安全通道后，通过统一的Store Data命令完成卡片的个人化。 |
不同厂家定义完全不同的个人化流程，采用完全不同的个人化指令，纷繁复杂，不便于掌握，也不便于统一。 |
|
卡片锁定 |
卡片锁定后，再向卡片发送指令，由卡片上的JavaCard平台按照规范定义统一处理，不受具体应用(Applet)的控制。 |
卡片锁定后，在向卡片发送指令，仍然由卡片操作系统（COS）处理，应用指令通过程序内部予以屏蔽。 |
|
RSA密钥长度支持 |
按照JavaCardAPI接口V2.2.1，支持512，736，768，896，1024，1280，1536，1984，2048位长度的密钥。 |
可以支持芯片所能支持的按8字节或者4字节长度递增的密钥长度。 |
|
协作开发 |
l 可以开发一种特殊的Applet，作为可以被其他应用Applet调用的通用的功能模块(Library)，以便于统一提供一些功能的实现。 l 可以通过Shareable Interface安全的调用其他Applet授权可以访问的方法。 |
源代码级别上的协作开发，通过代码的重用，实现功能上的协作。 |
|
安全性 |
||
|
规范定义 |
l JavaCard规范，目前普遍支持2.2.1版本。 l GP规范，目前普遍支持2.1.1版本。 l 安全性由这些规范定义和保证，并经过SUN的权威认证。 |
没有统一的国际性规范。 安全性由各卡片COS生产厂家，通过管理和测试进行保证。 |
|
安全控制机制 |
多种安全机制的参与，包括Applet之间的防火墙，安全域和安全通道的控制。 |
主要通过状态机来实现。特殊指令使状态机跳转，访问文件时判断状态机是否满足条件。 |
|
应用数据独立性 |
不同应用之间的数据直接访问是严格禁止的，由JavaCard平台实现的防火墙实现物理隔离。 |
将不同应用的数据组织为不同的ADF文件，靠的是卡片存储空间上的边界来区分。 |
|
数据访问 |
存储在RAM上的缓存数据，可以在应用失去选择，或者卡片Reset之后自动清除，无法再次访问，确保临时数据不会泄密。 |
存储在RAM上的缓存数据，在卡片Reset之后自动清除，无法再次访问，确保临时数据不会泄密。 |
|
数据存储 |
数据存储分为文件和内部数据对象两种方式。 l 对于像密钥一类的敏感数据，采用JavaCard规范定义的内部数据对象存储，该对象由JavaCard平台实现，对这些敏感数据进行特殊保护。 l 其他的普通存储数据，以文件形式组织，便于访问和管理。 |
数据统一按照文件的形式组织和存储。 l 不论是密钥还是数据，不论是敏感数据还是普通数据，都存放在文件中。 l 对密钥等敏感数据可能采取加密存储的方式，或者存放在特殊访问权限的文件中。 |
|
功能的修改和增/删 |
||
|
修改APDU指令 |
l 对相应的Applet源代码进行单独的修改，不影响其他应用的实现和稳定性，不影响底层的JavaCard平台的实现和稳定性。 l 只需要对修改的Applet进行测试和认证。 |
l 对卡片操作系统（COS）进行修改，可能会影响其他应用的指令的实现和稳定性。 l 需要重新进行整体的测试和认证。 |
|
添加全新的指令 |
l 对相应的Applet源代码进行单独的修改，不影响其他应用的实现和稳定性，不影响底层的JavaCard平台的实现和稳定性。 l 只需要对修改的Applet进行测试和认证。 |
l 对卡片操作系统（COS）进行修改，可能会影响其他应用的指令的实现和稳定性。 l 需要重新进行整体的测试和认证。 |
|
不同应用下，相同的指令支持不同功能 |
l 分别对不同应用对应的Applet进行单独修改，互不影响，也不会造成冲突。 l 实现简单，安全。 |
l 对卡片操作系统（COS）进行修改，因为对相同的指令要有不同的解释，所以可能会有冲突。 l 需要通过转义表的方式，判断当前在哪一个应用对应的ADF文件下，来进行何种解释。 l 实现起来比较复杂，有一定风险。 |
|
添加全新的应用和交易 |
l 开发一个全新的Applet应用。不影响其他应用的实现和稳定性，不影响底层的JavaCard平台的实现和稳定性。 l 只需要对新增的Applet进行测试和认证。 |
l 对卡片操作系统（COS）进行修改，增加新的应用和交易。可能会影响其他应用的指令的实现和稳定性。 l 需要重新进行整体的测试和认证。 |
|
删除对某种应用的支持 |
直接将应用对应的Applet从卡片中删除即可。 |
对卡片操作系统（COS）进行修改，删除对应的应用的交易和指令。 |
|
应用和案例 |
||
|
主要应用范围 |
l EMV2000借贷记应用(VSDC, MChip, PBOC2.0 DC)， l 积分， l ED/EP， l NFC等新业务应用领域， l 复合应用，例如金融应用+积分应用，NFC应用+电信应用， l 电信SIM卡。 |
l EMV 96，PBOC1.0 ED/EP， l PBOC2.0 DC， l 社保， l PSAM或者ESAM， l Key卡， l USBKey。
|
|
案例数量 |
数量逐步增加，突出表现在借贷记应用领域、新业务领域和复合应用领域 |
已经广泛的在应用在一些传统的领域，或者有一定历史的项目中。 |
|
容量和价格 |
||
|
EEPROM空间大小 |
通常为20K，36K，72K或者更大，便于对于多应用的支持 |
通常为8K,16K或者32K,36K，便于节约成本，大批量展开。 |
|
芯片平台 |
l 通常采用高端芯片平台， l 通常支持RSA和双界面， l 芯片频率高，处理速度快。 |
l 采用中高低端各种芯片平台， l 可选支持RSA和双界面。 |
|
卡片价格 |
l 由于卡片EEPROM空间通常比较大，芯片平台比较高端，所以价格比较高。 l 还存在JavaCard授权的问题，可能需要向SUN支付授权费用，这个费用包含在卡片费用中，由卡片生产厂家支付。 |
由于卡片EEPROM空间通常小一些，所以价格相对比较便宜。 |