智能IC卡规范.课件.docVIP

关于 native 卡、java 卡、GP 规范 PBOC 借贷记和小额支付将为 Java 卡带来新商机 目前从全球来看，第一波的 EMV 迁移进程已经接近尾声，现在人们关注的是如何从 SDA( 静态数据认证 ) 进一步升级到 DDA （动态数据认证）或者 CDA （关于 SDA 、DDA 、CDA 的定义参见 EMV 规范），从而 进一步增强卡片的防欺诈能力。 反观国内市场， EMV 迁移几乎还停留在起步阶段，只有为数不多的几家银行发行了少量的 EMV 卡。更多 的银行还在热火朝天地推广普通的磁条信用卡，五花八门的促销手段和普天盖地的广告，让人目不暇接。 国内各家银行会同威士、万事达、 JCB 、美国运通发行的各种双币种信用卡，不仅让普通的消费者无所适 从，也让国内银行间交易处理业务的中国银联感到了市场的严峻，所以中国银联采取各种策略，希望国内 的银行能够发行银联卡， 并且不遗余力地推广 PBOC 借贷记和小额支付规范的应用， 这样从市场上为 PBOC 借贷记和小额支付的大量普及消除了阻力。 PBOC 规范和 EMV 规范 在 EMV2000 芯片卡规范颁布之后， 各个主要的银行卡组织都根据自身的需要对 EMV 规范进行了细化和修 订，其中包括威士推出的 VSDC ，万事达推出的 Mchip 以及 JCB 推出的 Jsmart 等。通过各个银行卡组织 的细化，进一步明确了在 EMV 规范中一些笼统的定义，并且把一些发卡行可以灵活定义的选项作了明确 的约定，这样可以保证同一个银行卡品牌在全球各地的成员银行进行 EMV 芯片迁移的时候可以做到一致， 更好地实现互操作性，当然这也为众多的智能卡厂商在产品开发方面提供了必要的参考依据。 PBOC 规范可以说是中国人民银行针对 EMV 规范的本地化版本， 在 EMV 规范的整体框架内， 根据中国的 银行卡实际进行了适当的修订，所以卡片交易的流程以及个人化指南方面和 EMV 规范几乎完全一致。 PBOC 规范和 Java 卡以及 GP 规范 我们都知道 Java 卡是 SUN 公司推出的面向智能卡的一种 Java 体系结构， 利用 Java 卡可以加快应用开发 的进度，避免开发者苦苦钻研具体的智能卡芯片底层结构，能够以更灵活的方式支持卡片多应用以及卡片 发行后的应用添加和删除。不同应用之间具有防火墙，可用通过安全通道的方式实现卡片和终端之间的保 密通讯。 当然如果仅仅从功能上来看， Java 卡的各种功能也都可以在 Native 卡上实现，不过 Native 卡实现上述功 能的方法在不同厂商之间会存在很大的差别，增加了用户在个人化、应用开发方面的困难。 对于 Java 卡在应用的下载、 删除、 个人化、 卡片生命周期管理等方面都有明确的定义， 这就是 GP（Global Platform ）规范的内容。很多智能卡厂商、芯片厂商、银行卡组织和电信运营商都是 GP 的成员，而 GP 规范最早是威士开发的 Open Platform ，所以在 EMV 卡的个人化方面参照 GP 规范也就不足为奇了。 PBOC 规范在第 10 部分《中国金融集成电路（ IC）卡借记贷记应用个人化指南》中所定义的命令和流程 以及 EMV 卡的个人化流程也是一致的，也就是说同样符合 GP 规范。 因此如果采用 Java 卡进行 PBOC 借贷记应用开发的话，在个人化方面很容易满足个人化指南的要求。但 是对于 Native 卡而言，如果要达到同样的结果不仅所需要的开发周期长，而且开发难度也大。 所以从规范的角度看，虽然 PBOC 规范没有像威士那样明确定义 Open Platform ，但是从内容上看和 Java 卡以及 GP 规范都是一致的，在 PBOC 规范中也同样定义了如何利用 INITIALIZE UPDATE ，EXTERNAL AUTHENTICATE ，STORE DATA （详情参见 GP 规范）等命令进行数据和密钥的个人化。 国内的 Java 卡和 Native 卡应用 虽然支持 GP 规范的 Java 卡在全球市场已经得到了广泛普及，但国内市场的一些项目主要还是 Native 卡 占据主导地位。其中的原因除了成本考虑外，还有其它几方面的因素： ◆ 国内各个不同应用部门机构之间利益分割严重， 难以达成统一的多应用平台， 缺少 Java 卡的应用环境， 使得 Java 卡的多应用优势难以有效发挥； ◆ 因为开发 Java 卡需要向 SUN 公司支付一定的技术转让费用，所以国内一些卡商宁可投入大量的人力 物力，开发属于自己的 Native 卡，也不愿意开发 Java 卡，这样从技术上缺少相应的储备； ◆ 进入国内市场的一些国外厂商虽然有很好的 Java 卡产品，但是在国内的应用环境中丝毫发挥不了 Java