java卡gp规范.docx
- 文档编号:28517410
- 上传时间:2023-07-18
- 格式:DOCX
- 页数:13
- 大小:25.43KB
java卡gp规范.docx
《java卡gp规范.docx》由会员分享,可在线阅读,更多相关《java卡gp规范.docx(13页珍藏版)》请在冰豆网上搜索。
java卡gp规范
竭诚为您提供优质文档/双击可除
java卡,gp规范
篇一:
智能ic卡规范.
关于native卡、java卡、gp规范
pboc借贷记和小额支付将为java卡带来新商机
目前从全球来看,第一波的emV迁移进程已经接近尾声,现在人们关注的是如何从sda(静态数据认证)进一步升级到dda(动态数据认证)或者cda(关于sda、dda、cda的定义参见emV规范),从而进一步增强卡片的防欺诈能力。
反观国内市场,emV迁移几乎还停留在起步阶段,只有为数不多的几家银行发行了少量的emV卡。
更多的银行还在热火朝天地推广普通的磁条信用卡,五花八门的促销手段和普天盖地的广告,让人目不暇接。
国内各家银行会同威士、万事达、jcb、美国运通发行的各种双币种信用卡,不仅让普通的消费者无所适从,也让国内银行间交易处理业务的中国银联感到了市场的严峻,所以中国银联采取各种策略,希望国内的银行能够发行银联卡,并且不遗余力地推广pboc借贷记和小额支付规范的应用,这样从市场上为pboc借贷记和小额支付的大量(java卡,gp规范)普及消除了阻力。
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规范最早是威士开发的openplatform,所以在emV卡的个人化方面参照gp规范也就不足为奇了。
pboc规范在第10部分《中国金融集成电路(ic)卡借记贷记应用个人化指南》中所定义的命令和流程以及emV卡的个人化流程也是一致的,也就是说同样符合gp规范。
因此如果采用java卡进行pboc借贷记应用开发的话,在个人化方面很容易满足个人化指南的要求。
但是对于native卡而言,如果要达到同样的结果不仅所需要的开发周期长,而且开发难度也大。
所以从规范的角度看,虽然pboc规范没有像威士那样明确定义openplatform,但是从内容上看和java卡以及gp规范都是一致的,在pboc规范中也同样定义了如何利用initializeupdate,exteRnalauthenticate,stoRedata(详情参见gp规范)等命令进行数据和密钥的个人化。
国内的java卡和native卡应用
虽然支持gp规范的java卡在全球市场已经得到了广泛普及,但国内市场的一些项目主要还是native卡占据主导地位。
其中的原因除了成本考虑外,还有其它几方面的因素:
◆国内各个不同应用部门机构之间利益分割严重,难以达成统一的多应用平台,缺少java卡的应用环境,使得java卡的多应用优势难以有效发挥;
◆因为开发java卡需要向sun公司支付一定的技术转让费用,所以国内一些卡商宁可投入大量的人力物力,开发属于自己的native卡,也不愿意开发java卡,这样从技术上缺少相应的储备;
◆进入国内市场的一些国外厂商虽然有很好的java卡产品,但是在国内的应用环境中丝毫发挥不了java卡的优势,比如电信领域的ota应用,在java卡中都有很好的实现,可惜不论是中国移动还是中国联通都撇开成熟的技术不用,另起炉灶开发自己的ota系统,把众多的卡商弄的无所适从;
◆开发国内银行ic卡电子钱包应用和社保应用的一些系统集成商已经熟悉了广泛应用于native卡的那套密钥传递、管理机制和文件建立的流程,对于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卡的前景也会越来越乐观。
附:
本文提到的相关规范可以浏览以下链接获得详情:
1.emV规范:
emV
2.java卡规范:
java卡
3.gp规范:
gp规范
其中emV那个地址打开有些慢,再提供一个下载标准pdf的地址,下载emV1.1关于sda和dda:
脱机数据认证是pboc2.0中的重要部分的,是验证金融ic卡的有效手段。
未来,消费者在使用符合pboc2.0要求的金融ic卡进行持卡消费的时候,布置在商家的pos系统会与ic卡交互完成脱机数据认证工作,判断该卡是否被恶意篡改过或非法复制。
在pboc2.0中定义了两种脱机数据认证的方式,即静态数据认证和动态数据认证。
静态数据认证(简称sda),由终端验证ic卡中的数字签名来完成。
其目的是确认存放在ic卡中关键的静态数据的合法性,以及可以发现在卡片个人化以后,对卡内的发卡行数据XX的改动,不仅能有效地检测ic卡内关键静态数据的真实性,而且防止卡片的非法复制和伪造。
动态数据认证(简称dda)。
在动态数据认证过程中,终端验证卡片上的静态数据以及卡片产生的交易相关信息的签名,dda能确认卡片上的发卡行应用数据自卡片个人化后没有被非法篡改。
dda还能确认卡片的真实性,防止卡片的非法复制。
dda可以是标准动态数据认证或复合动态数据认证/应用密文生成(cda)。
关于native卡:
native卡是和java卡相对应的概念,通常所说的native卡是指卡片的cos和硬件平台紧密相关,卡片不具有通用性和二次开发的api接口,应用的开发和底层cos密不可分,而且多数的native卡仅支持单一应用,即便是支持多应用也是事先固化在芯片里的多应用,不能够像java卡那样支持多应用的动态下载。
篇二:
gp卡片规范(附录b-h)
11.算法(加解密和hashing)
gp卡可以支持多种类型的安全功能供应用使用。
本附录包含几个可能用于gp的加解密算法和hash方法的示例。
11.1数据加密标注(des)
数据加密标准(des)是对称加解密算法,它要求使用相同的密钥来加密和解密数据。
在它的最简单形式中它使用一个8字节密钥来加密一个8字节数据块,并且相同的密钥用于解密获得原始的明文。
3des使用组合的des操作进行加密和解密。
本规范中使用的3des采用iso/iec18033-3中定义的密钥选项2。
11.1.1加密/解密
对加密定义了两种不同变化。
11.1.1.1cbc模式
cbc模式的3des采用如[ansix9.52]和[iso10116]中的定义,初始化链接值为‘0000000000000000’。
11.1.1.2ecb模式
ecb模式的3des采用如[ansix9.52]和[iso10116]中的定义。
11.1.2mac计算
链接数据加密方法在[iso9797]中定义。
11.1.2.1完全3desmac
完全3desmac是在[iso9797-1]中定义的mac算法3,采用输出转换3,不截断,并用des代替块加密。
11.1.2.2单一des加最终3desmac
这也是大家所知道的零售密钥。
它是在[iso9797-1]中定义的mac算法3,采用输出转换3,不截断,并用des代替块加密。
11.2哈希算法
哈希是单向摘要操作,对于任意长度的数据返回一个固定长度的哈希值。
哈希不是加解密算法而只是提供数据的完整性。
它不提供认证或保密性。
11.2.1安全哈希算法(sha-1)
sha-1在[iso10118-3]和Fipspub180-1中定义。
11.2.2multos非对称哈希算法
对gp的multos的非对称哈希算法在multos文档[mao-doc-ReF-009]中描述。
11.3公开密钥加解密方案1(pkcs#1)
不同于des,使用共享的密钥,公开密钥加解密使用私钥(秘密保存在一个实体上)和公钥。
Rsa(Rives/shamir/adleman)是gp所用的公开密钥算法之一。
产生一个Rsa签名的过程包括使用pkcs#1标准。
签名方案是pkcs#1中定义的Rsassa-pkcs1-v1_5。
该方案应用于要签名数据的摘要,通过sha-1算法生成。
签名结果的大小同公钥模块的大小相同。
校验一个签名的过程为,将公钥应用于(提供哈希的)签名,并比较此哈希值和要校验的数据的哈希值。
11.4des填充
除非相反地指定,在执行des操作之前对一块数据进行填充可通过下列方式进行:
在数据块的右边添加一个80;
如果合成后数据块长度是8字节倍数,则不需要填充其它的;
在数据块右方添加2进制0,直到数据块长度是8的倍数。
如果填充的数据块要用于生成mac,在des操作后删除填充的数据。
12.安全内容管理
本附录定义了安全地改变和/或修改gp卡内容应当采用的一些不同方法。
在现在这个时候,这些方法是为gp指定的仅有的方法。
取决于卡片的实现,可以支持这些方法的任何子集。
12.1密钥
为了执行后续小节中描述的卡片内容管理操作,需要各种不同的密钥。
12.1.1令牌和收条密钥
如果支持委托管理,具有令牌验证权限的安全域和具有生成收条权限的安全域,应当有不同
表c-1:
令牌和收条密钥
建议Rsa密钥为大于上述最短长度的32位的倍数。
12.1.1.1令牌密钥
如果卡片支持委托管理,具有令牌验证权限的安全域应当有一个Rsa公钥用于验证令牌。
如果令牌验证密钥不存在,令牌验证和相应的委托管理操作应当失败。
12.1.1.2收条密钥
如果卡片支持委托管理特别是产生收条,具有产生收条权限的安全域应当要么有一个公认的无歧义的des密钥,或者一个Rsa私钥用于产生收条。
如果收条生成密钥不存在,生成收条和相应的委托管理操作应当失败。
12.1.2dap验证密钥
如果安全域支持dap验证,则安全域应当要么有一个Rsa公钥或者一个des密钥来验证加载文件数据块(lFdb)签名。
表c-2:
其它额外的安全域密钥
建议Rsa密钥为大于上述最短长度的32位的倍数。
12.2
加载文件数据块哈希(lFdbhash)
如果发生委托管理加载和/或加载文件包含一个或多个dap块,则需要install[forload]命令中存在加载文件数据块哈希(lFdbhash)域。
此域的用途是提供加载文件数据块(lFdb)的sha-1摘要,并用于确保加载文件数据块(lFdb)的内容未被以任何方式修改。
因为hash自身是没有用任何方式来保证安全的,因此它用于其它安全操作中用以确保加载文件数据块(lFdb)未被修改并用修改后的数据生成了一个新的hash。
open应当在创建可执行加载文件(elF)前验证加载文件数据块(lFdb)的完整性。
图c-1详细说明了安全域、应用提供方和控制授权机构计算加载文件数据块哈希(lFdbhash)的方法。
图c-1:
加载文件数据块哈希计算
数据的填充按sha-1中的定义。
摘要在加载文件数据块(lFdb)被封装到加载文件的tlV结构(即不包含标签c4和它的长度)之前生成。
如果发生委托管理,加载令牌是包扩此哈希的多个域的签名,从而证明发卡方是为连接此哈希的加载文件数据块(lFdb)生成的令牌。
如果加载文件包含dap块,dap验证是此哈希值的实际签名,证明该dap块是由验证连接此哈希的加载文件数据块(lFdb)的内容的机构所生成的。
12.3加载文件数据块签名(dap验证)
加载文件数据块签名提供对加载文件数据块的验证,在开始处理实际的加载文件数据块之前。
open应当请求连接该加载文件数据块签名的安全域来验证此签名。
加载文件数据块签名是对加载文件数据块哈希的签名。
每个加载文件数据块签名都和它所连接的安全域aid一起放在tlV结构的dap块中。
dap块放在加载文件的开头。
图c-2详细说明了应用提供方或控制授权机构执行加载文件数据块签名计算的方法。
图c-2:
加载文件数据块签名计算
12.4令牌
令牌是公开密钥签名,由发卡方生成。
令牌证明发卡方授权执行卡片内容管理操作,它们根据本附录生成和验证。
生成的令牌可被在多张卡上使用,取决于发卡方的安全策略。
令牌是Rsa签名,是对适当数据的sha-1消息摘要(用令牌私钥)解密。
数据填充采用sha-1和pkcs#1中定义的机制。
令牌的签名方案在附录b.2.1中定义–安全哈希算法(sha-1)。
12.4.1加载令牌
加载令牌是将应用代码传送到卡片的签名授权。
它允许对加载请求进行验证。
open应当请求具有令牌验证权限的安全域来验证加载令牌。
下图所示为加载令牌的产生。
图c-3:
加载令牌计算
生成加载令牌时确保如下各项:
只有此签名包含的应用代码(加载文件数据块的哈希)可被装载到卡片上;加载文件数据块的aid仅可以是包含在签名中的那个;
可执行加载文件(从加载文件数据块中导出的)和可执行加载文件中的所有可执行模块
仅可以和签名中包含的安全域相关联。
令牌的发行方仅可以是具有令牌验证权限的安全域的安全域提供方(如卡片发行方)。
加载令牌是对下面数据的Rsa签名,这些数据包含在要传送到卡片的实际install[forload]
篇三:
javacard技术简介
javacard技术简介:
第1部分
许多关于无线java站点的文章都以j2me平台为重点。
本系列文章(共分为两部分)将介绍另一种重要的移动java技术:
支持智能卡编程的javacard。
由于这些可移植技术具有非常强的专用性,因此本系列文章涵盖了相当广泛的内容。
本系列文章的第一部分将介绍智能卡、javacard技术和javacard小应用程序(applet)元素。
第二部分将介绍javacard技术的开发部分。
简介
javacard技术适用于java平台,可应用于环境高度专用化、内存和处理约束比j2me设备更苛刻的智能卡和其他设备。
智能卡在个人安全领域发挥着举足轻重的作用。
它们可以用于添加身份验证,并对安全级别很高的信息系统提供安全访问。
存储在智能卡中的信息是可移植的。
借助javacard技术,您可以携带有价值且敏感的个人信息,例如病历、信用卡号或者存储在压缩但非常安全的介质中的电子现金余额。
什么是智能卡?
智能卡不是什么新鲜事物。
早在20年前,欧洲就以(非智能形式)内存卡的形式引入了智能卡的概念,使用它保存重要的电话信息,其作用是减少盗打付费电话的可能。
智能卡技术由一项国际标准组织(iso)和国际电工委员会(iec)组成的联合技术委员会(jtc1)定义并管理的工业标准。
1987年推出的iso/iec7816国际标准系列在20xx年推出了它的最新的升级版本,界定了智能卡的方方面面,包括物理特性、物理接触界面、电子信号和传输协议、命令、安全体系、应用程序标识符和公用数据元素等。
智能卡是一个含有嵌入式集成电路(ic)的塑料卡片。
类似于一张信用卡。
当用作sim卡时,这个塑料卡片很小,但大小刚好能插入手机中。
智能卡从设计上保证高度安全性,窜改一点点内容都会导致毁坏它所包含的信息。
在智能卡使用的某些领域中,它们仅仅提供受保护的非易失性存储。
更高级的智能卡还有用于安全处理和存储的微处理器和内存,可以用于使用公钥或共享密钥算法的安全应用程序。
智能卡上的非易失性存储是最宝贵的资源,可以用于保存安全密钥和数字证书。
一些智能卡有单独的加密协处理器,支持象Rsa、aec和(3)des这样的算法。
智能卡不含电池,只有在和智能卡读取器相连时才被激活。
当被连接时,在执行完一段复位序列后,智能卡仍保持被动状态,等待接受从客户机(主机)应用程序发来的命令请求。
智能卡可以是接触式的或者非接触式的。
正如其名称所暗示的,接触式智能卡通过介于智能卡读取器与智能卡8触点之间的物理接触进行通信并工作;而非可接触式智能卡依靠在小于2英尺的一般距离之内的射频信号进行通信。
非接触式智能卡的射频通信基于类似于用于保存反盗窃和记录清单的无线射频识别(RadioFrequencyid,RFid)标记技术。
图1描述了接触式和非接触式智能卡:
图1a.接触式智能卡
图1b.非接触式智能卡
javacard技术也存在不同于智能卡的外形规格,例如智能按钮和usb令牌(如图2所示)。
它们可以同智能卡一样验证用户或传送敏感信息。
智能按钮包括一块电池而且是基于可接触模式,而usb令牌则可以直接插入到个人计算机的usb端口,而无需使用接触式或非接触式读取器。
这两种类型的javacard均提供与智能卡相同的编程功能,并具有防篡改特性。
图2a.带有java功能的智能按钮
图2b.带有java功能的usb令牌
javacard规范
多年以前,sunmicrosystem就实现了智能卡和类似的资源约束设备的潜能,并为java技术的子集定义一套规范,以便为javacardapplet创建应用程序。
支持这些规范的设备简称javacard平台。
在javacard平台上,来自不同供应商的多个应用程序可以安全地共存。
一台典型的javacard设备有一个运行于3.7mhz的8位或16位cpu,带有1k的Ram和多于16k的非易失内存(eepRom或闪存)。
高性能的智能卡带有单独的处理器、加密芯片和内存加密,某些智能卡还带有32位cpu。
javacard技术规范的最新版本为2.2,由三部分组成:
javacard虚拟机规范,定义了用于智能卡的java程序编程语言的一个子集和虚拟机。
javacard运行时环境规范,详细定义了基于java的智能卡的运行时行为。
javacardapi规范,定义了用于智能卡应用程序的核心框架和扩展java软件包和类。
sun还提供了javacard开发工具(jcdk),其中包括javacardRe和javacardVm的参考实现以及其他帮助开发的javacardapplet。
本文第二部分将介绍详细jcdk。
javacard技术和j2me平台
让我们比较一下javacard和j2me平台技术:
图3javacard技术和j2me平台
cdc和cldc配置以及相关配置文件都是j2me平台的组成部分,而javacard是一个为智能卡环境而专门创建的单独平台专门。
javacard应用程序的元素
完整的javacard应用程序由一个后端应用程序、系统、一个主机(卡片外部)应用程序、一个接口设备(卡片读取器)和卡片内部applet、用户证书和支持软件组成。
所有这些元素一起构成了一个安全的端到端应用程序:
图4.javacard应用程序的架构
一个典型的javacard应用程序并不是独立的,而是包含卡片端、读取器端和后端元素。
下面详细介绍一下每个元素。
后端应用程序和系统
后端应用程序提供支持卡
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- java gp 规范