"软掩膜"和“硬掩膜”-智能IC卡

目录

一、“软掩膜”和“硬掩膜”... 2

二、EMV迁移进程... 3

三、PBOC规范和EMV规范对比... 3

四、总结... 5

五、关于SDA和DDA. 6

 

一、“软掩膜”和“硬掩膜”

“软掩膜”和“硬掩膜”的术语常被用在现场试验和智能卡操作系统方面。严格地说，从纯逻辑的观点来 看这两个术语都是没有意义的，因为所谓ROM掩膜就意味着位于ROM里的程序代码总是不变的因而是“硬”的 。然而，在智能卡世界的常用行话里，术语“软掩膜”只表示一些类似于掩膜的东西，当智能卡操作系统的部分或全部程序代码以及相关应用命令是放在EEPROM里时就用这个术语。这就表示程序代码可以相对容易地 进行改变，而不需要制作一个新ROM掩膜的时间和费用。这种类型的“掩膜”是可变的，或者说是“软”的 。软掩膜主要用在试验期间或现场试验中，这样可以纠正错误并迅速地修改程序而花费却最少。其缺点就是它们需要使用具有较大容量的EEPROM芯片，它们确实比程序代码量相同的ROM芯片要贵些。然而，由于现场试验不会涉及到发行上百万张卡的问题，所以采用大容量EEPROM芯片所增的成本是可以承受的。

　　一旦软掩膜的测试或现场试验完成，放在EEPROM中的程序代码再没有任何修改而准各投人正式使用的话， 就可以通过真正的ROM掩膜生产过程把程序代码从EEPROM中转移到ROM中。这样做的结果称之为“硬掩膜”， 因为它不能再轻易地修改了。严格地说，硬掩膜的惟一优点就是对于给定数量的存储器用ROM比用EEPROM所占芯片面积要大大地减少，这样就可以在具有相同数量的程序代码情况下获得更小、更便宜的微控制器。

　　通过软、硬掩膜两步处理，在卡发行到用户之前的很短的时间里对新卡应用来说创造了为程序代码的实际修改提供了更多的灵活性。要是用ROM掩膜(相当于硬掩膜)处理的话，一旦生产商完成了掩膜，再对程序代码做改动就不可能了。相对于旧的处理方式来说，两步处理方式具有明显的优势，现在每当引入新的智能卡应用时几乎在开始时都使用软掩膜技术，只有在对程序代码所有需要的修改都已完成之后才转移为硬掩膜。

　　3．操作系统的API

　　最初的智能卡操作系统没有公开提供可供第3方调用操作系统功能的编程接口，不能把第3方的软件放入卡里执行。但是，现在所开发的智能卡操作系统，诸如MULTOS以及支持JAVA的操作系统，都为把第3方的程序 装入智能卡里提供了可能。因为，这些操作系统包含有考虑周全的应用编程接口API（Application Programming Interface），使之具有访问操作系统的功能。这意味着第3方的程序不需要包含在操作系统已 经提供的例程中。当然，实际上所有的操作系统都有其自己的内部API，这些API并不是设计给外部使用的， 而且通常是保密的。

　　智能卡领域与通常的情况不同，现在还没有一个有关智能卡操作系统API的通用标准。相反，到目前为止， 只有两个已经初步制定了的工业标准。其中之一是JAVA卡API，另一个是Multos API。在相关的规范里所描述的API允许通过文件管理器来存取文件，调用合适的保密功能，当然还有发送和接收数据。具有完整操作系统API并允许下载程序代码的智能卡操作系统实际上与PC操作系统仅仅在所使用的存储器的数量上有所差异而已。

二、EMV迁移进程

PBOC借贷记和小额支付将为Java卡带来新商机 ，目前从全球来看，第一波的EMV迁移进程已经接近尾声，现在人们关注的是如何从SDA(静态数据认证)进一步升级到DDA（动态数据认证）或者CDA（关于SDA、DDA、CDA的定义参见EMV规范，混合数据认证），从而进一步增强卡片的防欺诈能力。

反观国内市场，EMV迁移几乎还停留在起步阶段，只有为数不多的几家银行发行了少量的EMV卡。更多的银行还在热火朝天地推广普通的磁条信用卡，五花八门的促销手段和铺天盖地的广告，让人目不暇接。国内各家银行会同VISA、万事达、JCB（日本）、美国运通发行的各种双币种信用卡，不仅让普通的消费者无所适从，也让国内银行间交易处理业务的中国银联感到了市场的严峻，所以中国银联采取各种策略，希望国内的银行能够发行银联卡，并且不遗余力地推广PBOC借贷记和小额支付规范的应用，这样从市场上为PBOC借贷记和小额支付的大量普及消除了阻力。 

三、PBOC规范和EMV规范对比 

在EMV2000芯片卡规范颁布之后，各个主要的银行卡组织都根据自身的需要对EMV规范进行了细化和修订，其中包括VISA推出的VSDC，万事达推出的 Mchip以及JCB推出的Jsmart等。通过各个银行卡组织的细化，进一步明确了在EMV规范中一些笼统的定义，并且把一些发卡行可以灵活定义的选项作了明确的约定，这样可以保证同一个银行卡品牌在全球各地的成员银行进行EMV芯片迁移的时候可以做到一致，更好地实现互操作性，当然这也为众多的智能卡厂商在产品开发方面提供了必要的参考依据。 

PBOC规范可以说是中国人民银行针对EMV规范的本地化版本，在EMV规范的整体框架内，根据中国的银行卡实际情况进行了适当的修订，所以卡片交易的流程以及个人化指南方面和EMV规范几乎完全一致。 

 

PBOC规范和Java卡以及GP规范 

我们都知道Java卡是SUN公司推出的面向智能卡的一种Java体系结构，利用Java卡可以加快应用开发的进度，避免开发者苦苦钻研具体的智能卡芯片底层结构，能够以更灵活的方式支持卡片多应用以及卡片发行后的应用添加和删除。不同应用之间具有防火墙，可通过安全通道的方式实现卡片和终端之间的保密通讯。 

当然如果仅仅从功能上来看，Java（相当于Android平台）卡的各种功能也都可以在Native卡上实现（相当于IOS操作系统），不过Native卡实现上述功能的方法在不同厂商之间会存在很大的差别，增加了用户在个人化、应用开发方面的困难。 

Native卡是和Java卡相对应的概念，通常所说的Native卡是指卡片的COS和硬件平台紧密相关，卡片不具有通用性和二次开发的API接口，应用的开发和底层COS密不可分，而且多数的Native卡仅支持单一应用，即便是支持多应用也是事先固化在芯片里的多应用，不能够像Java卡那样支持多应用的动态下载。

对于Java卡在应用的下载、删除、个人化、卡片生命周期管理等方面都有明确的定义，这就是GP（Global Platform）规范的内容。很多智能卡厂商、芯片厂商、银行卡组织和电信运营商都是GP的成员，而GP规范最早是威士(VISA)开发的Open Platform，所以在EMV卡的个人化方面参照GP规范也就不足为奇了。 

PBOC规范在第10部分《中国金融集成电路（IC）卡借记贷记应用个人化指南》中所定义的命令和流程以及EMV卡的个人化流程也是一致的，也就是说同样符合GP规范。 

因此如果采用Java卡进行PBOC借贷记应用开发的话，在个人化方面很容易满足个人化指南的要求。但是对于Native卡而言，如果要达到同样的结果不仅所需要的开发周期长，而且开发难度也大。 （因此目前标准金融卡都已使用Java平台，只有社保卡还是native平台）

所以从规范的角度看，虽然PBOC规范没有像VISA那样明确定义Open Platform，但是从内容上看和Java卡以及GP规范都是一致的，在PBOC规范中也同样定义了如何利用INITIALIZE UPDATE，EXTERNAL AUTHENTICATE，STORE DATA（详情参见GP规范）等命令进行数据和密钥的个人化。 

国内的Java卡和Native卡应用 

虽然支持GP规范的Java卡在全球市场已经得到了广泛普及，但国内市场的一些项目主要还是Native卡占据主导地位。其中的原因除了成本考虑（可见native卡比java卡便宜）外，还有其它几方面的因素： 

◆ 国内各个不同应用部门机构之间利益分割严重，难以达成统一的多应用平台，缺少Java卡的应用环境，使得Java卡的多应用优势难以有效发挥； 

◆ 因为开发Java卡需要向SUN公司支付一定的技术转让费用，所以国内一些卡商宁可投入大量的人力物力，开发属于自己的Native卡，也不愿意开发Java卡，这样从技术上缺少相应的储备； 

◆ 进入国内市场的一些国外厂商虽然有很好的Java卡产品，但是在国内的应用环境中丝毫发挥不了Java卡的优势，比如电信领域的OTA应用，在Java卡中都有很好的实现，可惜不论是中国移动还是中国联通都撇开成熟的技术不用，另起炉灶开发自己的OTA系统，把众多的卡商弄的无所适从； 

◆ 开发国内银行IC卡电子钱包应用和社保应用的一些系统集成商已经熟悉了广泛应用于Native卡的那套密钥传递、管理机制和文件建立的流程，对于Java卡缺少了解。 

但是我们也看到相关的单位和部门在智能卡多应用方面已经有所行动，比如去年成立的国家金卡工程多功能卡应用联盟，号召各个应用部门之间协调合作，力推一卡多用（要想实现一张卡片装载多个应用，这只能是Java卡的天下）。而Java卡是得到全球用户广泛认可的多应用产品，在未来中国的多功能卡应用中也同样会发挥其独特的作用。 

部分国内银行开始选择Java卡，随着PBOC借贷记卡项目的逐步启动，一些银行在卡片选型方面已经往Java卡方面倾斜。银行之所以选择Java卡，主要看中的就是Java卡所支持的GP规范，为银行开发自己的增值应用提供了可能。 

从国外EMV迁移的经验来看，在项目启动初期大家都急于寻找一个商业模式，以便能够平衡EMV迁移带来的投入，虽然其中包含减少欺诈损失的因素，但是银行还是希望能够在这个功能强大的芯片卡上面挖掘更多的潜能。于是人们自然会把注意力放在芯片卡的多应用方面，银行也会根据不同的客户群开发不同的增值应用，既防止客户流失，也带来了增值收入。 

比如国内部分商业银行正在进行的一些项目预测试，就希望采用具备一定存储空间的Java卡，这样才能够把自己开发的一些应用下载到Java卡上，而且可以利用自己的发卡商权限更好地管理各种应用。 

另外，中国银联也起草了支持非接触交易的PBOC以及小额支付的规范，于是商业银行在PBOC卡片的发行方面就会有自己不同的应用组合模式，Java卡在应用下载、安装、删除方面的通用性和灵活性无疑将会成为最佳选择。 

Java卡在PBOC借贷记和小额支付应用中的优势

◆ 能够满足不同的市场需求：因为国内PBOC借贷记项目以及小额支付项目刚刚开始启动，而且对于项目中如何取舍PBOC规范没有明确定义的数据项，各个商业银行之间也可能存在一些差异，那么在这个时候如果采用完全固化到芯片中的Native卡则很难具备应有的灵活性。但是Java卡因为应用程序本身可以灵活下载，所以可以更好地适应多变的市场； 
◆ 具备快速进入市场的能力：因为多数银行应用的Native卡都需要进行COS的掩模，而且这一过程通常需要2-3个月的周期，无疑延缓了产品上市的时间。而Java卡在应用程序开发完成之后，就可以对外销售，相当于节省了掩模的时间，对于瞬息万变的市场而言，这2-3个月显得弥足珍贵； 

◆ 可以简化产品开发过程：如果采用Native卡开发PBOC借贷记和小额支付应用，需要从底层一点一滴做起，包括通讯协议、加密算法、内存管理、数据存储等，任何环节出现错误都会导致整个项目的崩溃。而利用Java卡进行开发的话，则只需要关注应用本身，只要理清整个交易流程很快就能够开发出满足规范的产品，前面提到的那些底层开发工作已经都包含在Java卡的API里面了，使得开发工作变得简单而容易； 

◆ 项目初期整体成本低：一般来说单张Java卡的成本比Native卡略高，但是Native卡的成本优势只有在大规模应用的时候才能够体现出来，因为芯片厂商都会收取一笔不菲的掩模费。对于初期的PBOC借贷记和小额支付项目应用而言，一般试点规模都是以数万张为限，所以Java卡反而具备更好的成本优势。 

四、总结

目前，Java卡在国内的市场虽然所占的份额还很小，但是我们看到未来的趋势正朝着有利于Java卡的方向发展。而且国内一些具有前瞻性的卡商也开始着手进行Java卡的开发，在GP成员的名单中也有了中国公司的身影。这都说明Java卡得以普及的内部和外部环境都在逐步改善，我们相信伴随着未来几年国内商业银行针对PBOC借贷记、小额支付以及qPBOC芯片卡项目的逐步启动，以及NFC移动支付业务的发展，Java卡的前景也会越来越乐观。 

 

 

 

五、关于SDA和DDA

脱机数据认证是PBOC2.0中的重要部分的，是验证金融IC卡的有效手段。未来，消费者在使用符合PBOC2.0要求的金融IC卡进行持卡消费的时候，布置在商家的POS系统会与IC卡交互完成脱机数据认证工作，判断该卡是否被恶意篡改过（SDA）或非法复制（DDA）。在PBOC2.0中定义了两种脱机数据认证的方式，即静态数据认证和动态数据认证。 

静态数据认证（简称SDA），由终端验证IC卡中的数字签名来完成。其目的是确认存放在IC卡中关键的静态数据的合法性，以及可以发现在卡片个人化以后，对卡内的发卡行数据未经授权的改动，不仅能有效地检测IC卡内关键静态数据的真实性，而且防止卡片的非法复制和伪造。 

动态数据认证（简称DDA）。在动态数据认证过程中，终端验证卡片上的静态数据以及卡片产生的交易相关信息的签名，DDA能确认卡片上的发卡行应用数据自卡片个人化后没有被非法篡改。DDA还能确认卡片的真实性，防止卡片的非法复制。 DDA可以是标准动态数据认证或复合动态数据认证/应用密文生成（CDA）。