PBOC卡片应用分析（二）

最新推荐文章于 2024-09-26 08:26:48 发布

詹天佐

最新推荐文章于 2024-09-26 08:26:48 发布

阅读量3.5k

点赞数

分类专栏：智能卡文章标签：信用卡支付智能卡终端标签

本文链接：https://blog.csdn.net/youngbug/article/details/11518729

版权

智能卡专栏收录该内容

17 篇文章

订阅专栏

接上一篇，上次基本上卡在了选择ADF之后的操作，选择完ADF之后根据Response的数据，需要做获取处理选项GPO，但是对PDOL这个东西一直搞不明白，GPO指令的数据域是PDOL，PBOC规范上对GPO的指令写的也是很模糊，只说了没有PDOL的发8300，有PDOL项的发PDOL，但是泛泛的浏览PBOC规范，对选择应用之后返回的数据中PDOL的内容也没有细说，折腾了半天才反应过来PDOL的格式，仔细对照规范对PDOL的解析如下。

+-----------+----------+-------------------+----+---------+----+--------------+-----+

+-----------+----------+-------------------+----+---------+----+--------------+-----+

| 9F38 | 09 | 9F7A | 01 | 9F02 | 06 | 5F2A | 02 |

+-----------+----------+-------------------+----+---------+----+--------------+-----+

下面发送GPO指令，这个PBOC3.0规范上关于GPO的APDU的描述Lc固定值写为0，不知道这一部分是哪个单位的人写的，Lc明显不能写成0啊，开始我还老老实实的写0，仔细想，即使没有PDOL，Data域也要发8300，Lc也得为2的，如果符合了PBOC3.0的规范，那就跟7816规范矛盾了，必须是起草者写错了。下面对GPO命令报文按我自己的修正后的说明一下以防又有人跟我已经糊里糊涂的。

APDU	取值说明
CLA	80
INS	A8
P1，P2	00
Lc	PBOC3.0规范上写的是0，实际应该是数据域长度
Data	83+PDOL的部分，直接把Tag 9F38之后的部分填充进来即可，如果没有PDOL那么就是83+00
Le	0

下面发送GPO指令

7.GPO

APDU:80A800000B 83099F7A019F02065F2A02

SW1SW2：6114

8.GET RESPONSE

APDU:00C0000014

RETURN:80127C0008010100100103011007070018010400

SW1SW2：9000

规范中说GPO的Reaponse数据中应该是一个BER-TLV编码的数据对象，有两种格式一种是标签为‘80’，一种是标签为‘77’，这个明显是标签为‘80’的。数据对标表示了AIP和AFL。AIP列出了交易在处理过程中执行的功能；AFL列出交易需要读出的数据存放的短文件标识符、记录号、记录个数以及脱机数据认证需要的静态签名数据的存放位置。

下面对报文进行解析，在规范上没有看太明白，一边baidu一边看规范进行解析的。

80是Tag，12是长度，7C00是AIP.

7C00按照规范是

bit
bit8=0	规范说1=RFU
bit7=1	支持SDA
bit6=1	支持DDA
bit5=1	支持持卡人认证
bit4=1	执行终端风险管理
bit3=1	支持发卡行认证
bit2=0	0=RFU
bit1=0	不支持CDA
第2字节	RFU=0