Chinaunix首页 | 论坛 | 博客
  • 博客访问: 233789
  • 博文数量: 82
  • 博客积分: 30
  • 博客等级: 民兵
  • 技术积分: 505
  • 用 户 组: 普通用户
  • 注册时间: 2011-02-23 14:59
文章分类

全部博文(82)

文章存档

2015年(81)

2011年(1)

我的朋友

分类: 信息化

2015-01-05 09:22:38

最近在做一个基于PBOC电子现金卡的终端应用, 项目还没有完成, 但电子现金部分的处理模块已完成,剩下的基本是UI和调试的事情了. 想把对PBOC电子现金理解整理成一篇文章.

    电子现金的概念是在PBOC规范的第十三部分<<基于借记/贷记应用的小额支付规范 >>里提出的。可以这样理解,电子现金是PBOC里的一个应用,它基于借贷记. 这个应用被提出的目的就是实现我们经常听说的一个功能, 小额支付功能.

    基于电子现金的卡目前来讲,一般有如下几个特点:

    1 是由银行发行, 这个是必须的,否则就不会叫金融IC卡了.

    2 卡里只有一个应用,也就是一个AID,因为目前国内推行PBOC的卡都是先从单应用开始做试点. 从卡片的角度来讲,实现多应用不成问题,但是, 如果卡片支持多应用, 还需要终端(包括圈存终端和消费终端)以及银行后台的相应配合, 这部分的工程量就很大了, 所以暂时以单应用为主.

    3 一般用这张卡做小额支付,并且非实名制,消费无需密码,且是脱机消费.

    4 这种卡一般只在银行内部或企业内部使用(企业内部也是与银行合作), 目前很难推广到一些大的公共事业中(比如交通), 因为这些行业是国家建设部管的, 这里面有很多非技术的原因导致银行这种金融机构与建设部难以坐在一起协商.

    电子现金的应用, 主要做两种类型的交易,一是圈存交易,一是消费交易. 我这里以终端圈存交易为例,简单描述一下PBOC的交易流程.

    所谓电子现金圈存, 是指把用户在银行帐户里的钱转到这张电子现金的卡上. 说白了就是从你的***上转钱到电子现金的IC卡上. 由于目前还没有实现PBOC卡的多应用,整个圈存过程实际上需要两张卡,终端先读取***信息(包括卡号,密码以及充值金额等信息), 扣费成功后下一步才是走PBOC交易流程,对电子现金卡写卡. 而推广PBOC的终极目标就是实现一卡多应用, 也就是说,未来的某个时候,就可以用一张卡完成圈存,只是不同的应用.

    我这里简单通俗的介绍一下电子现金充值PBOC的流程. 更详细的内容可以直接看PBOC 2.0规范.

    前面说到,电子现金应用是基于借贷记的, 所以它兼容借贷记应用,可以说是精简版的借贷记应用. 每一笔交易,所执行的PBOC流程就是简化版的借贷记流程.

    第一步, 选择应用, 所用命令是select, 传的参数是 应用AID号. 这里跟标准的PBOC交易流程并不一样, 因为标准流程里面, 前面还有两步, 就是读取支付系统目录, 建立应用列表.为什么可以省掉这两步, 因为前面说到,卡里一般只有一个应用AID,目前还没有实现多应用, 这个AID号应该在卡片个人化时就已经固定好,只要你知道了该AID号,直接跳过前两步选择该应用可以了. 卡里只有一个应用,就无所谓应用列表了. 当然,一个好的程序设计建议还是走标准流程,这样,以后卡片实现了多应用, 你的终端程序也可以通吃.

    应用选择后,卡片返回一串信息, 这串信息里面有个很重要的数据叫PDOL, 这是一个列表,卡片通过这个列表告诉终端,它需要哪些数据, 这些数据用来给卡片做应用初始化. 举个列子,比如卡片可能会需要授权金额(就是圈存的金额), 货币代码等数据. 终端程序解析PDOL,按照一定的规则拼接数据,进入第二步.

    第二步, 应用初始化. 命令是GPO, 参数就是前一步根据PDOL所组的数据包. 该步表示终端通知卡片交易开始了. 卡片会返回AIP和AFL两个数据. AIP告诉终端卡片支持的功能, 比如卡片是否支持脱机数据认证, 是否支持发卡行认证等. AFL是要告诉终端, 如果要完成这笔交易,你终端该从卡上读什么数据。AFL里就包含了这些数据的位置和名称. 举个例子,这些数据可能有当前的交易序号,该张卡片的卡号(PBOC里叫PAN,应用主帐号)等.

    第三步,读数据. 命令是read record. 参数是前一步得到的终端所需卡片数据的位置和名称. 终端要把AFL指定的所有数据读出,并保存到终端供下面的流程所用. 每次读到的数据是包含在卡片的返回信息中的, 终端解析返回信息,提取相关的数据.

    第四步, 产生应用密文. 命令是GAC. 参数是密文类型和产生密文所需的数据. 密文类型有三种,分别是交易证书(TC), 应用认证密文(AAC),授权请求密文(ARQC). 因为这一步是为下一步联机处理做准备,所以终端应用请求卡片产生的密文类型应该是ARQC,查看卡片是否允许联机处理. 卡片收到产生密文类型后,返回的信息有两个重要的数据, 第一个就是密文类型,该数据指示卡片是否愿意做联机处理,如果愿意,返回的是ARQC,与终端一致,否则返回AAC,表示拒绝联机. 终端判断卡片返回的是否是ARQC,如果是,终端要读取卡片返回的另一个重要的数据,应用密文(AC), 该密文是卡片用存放在卡里的密钥,对终端发过来的明文数据,用3DES算法生成的.

    第五步, 联机验证卡片. 这一步,卡片本身没有操作. 终端把前一步得到的应用密文,产生应用密文的一些数据,还有其它的信息(比如交易日期,交易时间等),打包发送到发卡行PBOC后台, 通信方式一般是用TCP/IP。 后台通过验证ARQC密文来认证卡片, 如果认证成功会返回授权响应密文(ARPC), 这个ARPC是后台通过3DES算法,对ARQC密文和二个字节的授权响应码加密生成的.

    第六步,第五步的目的是发卡行验证卡片的合法的性,这一步是卡片验证发卡行是否是一个有效的发卡行. 命令是External Authentication, 叫外部认证. 参数是上一步联机处理响应的ARPC和授权响应码. 卡片收到命令后,会用自己的密钥,对ARQC和授权响应码生成ARPC,然后与终端传来的ARPC比较,两都相同,就认为此ARPC是来自一个有效的发卡行后台.

    第七步, 联机圈存报文, 验证了卡片和发卡行的合法性之后,终端向发卡行后台请求圈存,上传的数据包括充值金额,卡内原来的余额等信息, 发卡行后台返回一个写卡的脚本命令, 终端解析这个脚本,直接发给卡片即可. 到这里,卡片充值成功.

    第八步,这一步要发送第二请求密文命令(GAC2), 它的作用说白了就是告诉卡片交易结束。与第四步的GAC1不同的是,GAC2的参数里面多了授权响应码,并且请求的密文类型是TC,也就是希望卡片接受交易。如果卡片返回的也是TC,表示接受交易.

    第九步, 读交易日志,在整个流程执行的过程中,卡片会以一定的格式读录当前这笔交易的信息,比如授权金额,卡号,交易时间,终端只需通过一个命令就可以把些信息读出,然后提取出有用的信息,以便日后结算.

之前的一篇文章已经对电子现金做了一些介绍, 这篇文章站在开发者的角度,深入的探讨一下电子现金的应用.

    做一个电子现金的交易, 第一步当然是选中当前的应用, 方法是调用select命令, 传入当前的应用AID号, 如果卡片的状态码返回9000,则表示选中成功. 下面举一个例子:

    发送: 00 a4 04 00 08 a0 00 00 04 44 01 01 05 00

    卡片返回:

    6f 45 84 08 a0 00 00 04 44 01 01 05 a5 39 50 0a 50 42 4f 43 20 44 45 42 49 54 87 01 01 9f 38 09 9f 7a 01 9f 02 06 5f 2a 02 5f 2d 02 7a 68 9f 11 01 01 9f 12 0a 50 42 4f 43 20 44 45 42 49 54 bf 0c 05 9f 4d 02 0b 0a 90 00

    先看发送的指令, 其中a0 00 00 04 44 01 01 05这八个字节就是当前应用的AID号. 卡片返回的最后两个字节是90 00, 表示发送成功. 状态码之前是数据域. 数据域是一个TLV结构的FCI, 其中V里面可能也会有TLV结构的数据, 所以,FCI可能是一个嵌套的TLV结构. 6f是整个数据域的tag, 它标识卡片响应的整个FCI. 45表示长度(十六进制),也就是它后面数据域部分的所有字节数.

    不分析所有的数据了, 只说一下里面比较重要的一个数据PDOL. PDOL表示卡片要求终端提供的数据,从而激活当前选择的应用. 找到这一串数据;

    9f 38 09 9f 7a 01 9f 02 06 5f 2a 02

    9f38是PDOL的tag, 09表示长度. 9f 7a 01表示卡片要求终端提供tag为9f7a的元素的值,长度是01, 9f 02 06表示卡片要求终端提供tag为9f02的元素的值,长度是06,5f 2a 02表示卡片要求终端提供tag为5f2a的元素的值,长度是02. 这三个tag的意义如下:

    9f7a:电子现金终端指示器

    9f02:授权金额

    5f2a:交易货币代码

    对于基于电子现金的应用, 这三个元素是必不可少的, 或者说,卡片要求终端至少提供这三个元素的值.

    下一步就是终端需要把上面三个元素通过GPO命令传送给卡片.

    后面两个元素比较容易填, 授权金额就是你的实际交易金额,交易货币代码固定为0156, 那么电子现金终端指示器的值是什么呢?

    根据PBOC 2.0的规范, 只有满足下面三个条件时,电子现金终端指示器的值才能为1, 否则为0. 这三个条件是:

    1 终端支持电子现金交易

    2 授权金额小于终端交易限额

    3 终端交易类型为消费交易

    前面两个条件好理解, 为什么会有第三个条件呢?

    如果卡片接收到的电子现金终端指示器的值是1, 它就认为当前做的是一个电子现金的交易, 而不是普通的借贷记交易, 那么它在GPO指令的响应中就会返回电子现金的AIP和AFL, 而不是普通借贷记的AIP和AFL, 两者区别主要在AFL的不同. 如果卡片认为当前是一个电子现金的交易, 它会返回给终端”电子现金发卡行授权码”, 而电子现金发卡行授权码是用于脱机交易中, 存放在清算报文的授权码中. 而PBOC的消费交易是脱机交易, 这就是为什么会有第三个条件.

    另外,PBOC的圈存交易规定必须联机处理,所以我们也可以得出, 对于基于电子现金的圈存交易,它从AFL人读到的数据其实就是普通借贷记的数据,其交易流程也是借贷记的流程.

    下面是有一个电子现金的卡片做的一个测试,如果电子现金终端指示器的值为0, 返回的AFL如下:

    08 01 02 00, 10 01 03 01, 18 01 02 00, 20 01 01 00

    当电子现金终端指示器的值为1时, GPO命令返回下面六组AFL

    08 01 02 00, 10 05 06 01, 10 08 08 00, 18 01 02 00, 20 01 01 00, 28 01 01 00

    其中电子现金发卡行授权码就是文件标识符为28 的文件中.  

    如果终端能收到卡片返回的AIP和AFL, 就可以根据卡片提供的AFL, 读出卡片提供给终端的所有数据, 并保存在终端, 以备后续的交易使用. 这些数据就包括PAN号等在内的卡片数据, 举个例子, 我用测试卡s读到的发卡行授权码(tag=9f74)的值如下:45 43 43 30 30 31, 对应的ASCII字符就是ECC001.

阅读(767) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~