一、ISO14443协议和PBOC关于CID的约定
看过协议的人其实都明白，RATS命令中参数字节的低半字节是CID，期中，CID不能为15。
ISO14443协议中要求当RATS命令的CID等于0时，READER不使用MUTI-ACTIVE协议，换句话说就是每次只能确定一张卡片。卡片可在ATR中指示自己是否支持携带CID，当RATS参数域CID为0而卡片指示支持CID时，ISO14443协议中指示，通讯时可带CID也可不带CID.
但是在PBOC规范中，明确指出这种情况下，读写器必须不带CID。
当RATS命令携带的CID等于15时，READER应进入HALT状态；
当收到一个无效的IBLOCK时，应仍然处于PROTOCOL状态
这其实都是一些犄角旮旯的东西，但是检测中心对这些东西很上心，细节决定成败真是一点不假。
二、PBOC规范中，对于通讯速率的约定
第一、首先先说一下ISO14443协议中关于通讯速率的约定。如图1所示
图 1
其中DS与DR的含义见下表1
卡片实际的通讯速率为106*D.
这是ATR中卡片支持的速率的指示字节。显然ISO14443协议中对卡片支持哪种速率，是否支持双向通讯速率没有进行明确的约定，需要进一步通讯进行确定。
但是在PBOC3.0规范中，明确规定，卡片仅仅支持双向速率相同的情况。且DSI与DRI都应该设置为0，即仅支持106Kpbs的速率。
这样一来，读写器PPS命令的PPS1字节的内容也就随之确定了。
三、TypeB协议
第一、WUPB命令
WUPB命令共包含3个字节，分别为
1、05；
2、AFI字节；
AFI字节，PBOC规范中，READER的约定为该字节必须为0X00，即支持所有应用卡片可支持应用类型部位0X00的AFI;
3、参数字节
bit5:
1：表示读写器支持扩展ATQB
0：表示读写器不支持扩展ATQB
但是卡片可以不理会该字节，即在ATQB中可携带该字节也可不携带该字节
bit4:
1:表示是WUPB
0:表示是REQB
bit3-1：
表示slot号,如下图1所示：
图1
当读写器发送的参数中该域为101或者11x时，卡片应翻译为16个slot
bit8-bit6：
应该为000，当该域不为000时，卡片应忽略该域
PBOC规范明确要求：
不支持扩展ATQB,同时slot号应该设置为000，以确保所有卡片都在slot0给予响应。
2、ATQB
ATQB主要关注协议信息域
1、首字节标明了卡支持的通讯速率：
见下图2：
图2
PBOC规范强制规定：卡片的bit7---bit5与bit3---bit1必须为0，即双向都支持106kbps的通讯速率；读写器应能支持双向的106kbps通讯速率，且可支持更高的通讯速率，我想这是为后续协议的提高做好准备吧！
2、第二字节为帧大小和协议类型
bit8-bit5：表示帧大小
其和实际的帧大小的对应关系见下图3：
图3
当参数为9-F是，应默认为8；
究竟双方通讯时帧的大小还具有ATTRIB中的参数：两个参数取小的；
bit3-bit2：表示TR2的值，PICC应将该位设置为0，即选择最小值，而读写器应忽略该域并将FDT作为TR2最小值
bit1：协议类型选择：
0：表示仅支持ISO14443-3协议
1：表示支持ISO14443-4协议
PBOC规范中要求该位必须设置为1
3、第三个字节
第三个字节由FWI:ADC:FO组成。
bit8-bit5:FWI
FWI用来定义FWT，即帧等待时间，这个时间参数用来约定读写器发送完一帧数据的最后一个bit后，卡片必须给予响应的最长等待时间。其计算公式为：FWT=302*pow(2,FWI) us.但是Attrib命令你除外，Atrtib命令的FWT时间为302*pow(2,4)us,约等于4.8ms。FWI最大值为14，如果出现15则解释为14.
bit4-bit3:ADC
ADC为应用数据编码；
bit4默认设置为0
bit3设置为0，表示私有，设置为1表示在本规范JR/T0025.8中定义。
bit2-bit1:FO,该域定义了卡片可选的支持选项，主要是CID和节点地址。其中bit2设置为1表示支持节点地址；bit1设置为1表示支持CID跟随
很奇怪，PBOC规范里强制要求读写器不使用节点地址和CID.这个是和TypeA不同的一个地方。
第三、扩展字节，这个域是可选的。
bit8-bit5：SFGI,这个数值用来定义起始帧保护时间，用来取代TR2，它的值为0-14，如果该值为15则翻译为0，缺省值是0.
bit4-bit1:0000，如果卡片该域返回的数值不等于0000，表示不支持该标准。其实在发送WUPB或者REQB时，卡片可以设置参数字节（第三个字节）的bit5位为0，告诉卡片自己不支持扩展字节，那么卡片也就不会返回该扩展字节了，省的麻烦。
总结一下ATQB干的事情：ATQB告诉读写器，卡片是否支持CID、是否支持NAD、通讯速率、支持的最大帧长度，当然还有FWT或者SFGT等参数。但是读写器不一定支持这些参数，可以推测到ATTRIB命令中读写器肯定会告诉卡片自己对这些参数的支持情况。双方协商一个大家都力所能及的参数。
第四、ATTRIB命令
1、参数1
参数1的定义如下图4：
图4
PBOC对该字节的要求如下图5：
图5
关于TR0，TR1，TR2参数的含义，我之前单独写过一个文章，这里不再重复了。
2、参数2
参数2定义了最大帧长度，通讯速率。
bit8-bit7：定义了卡到读卡器的通讯速率，见图6
图6
bit6-bit5:定义了读写器到卡的通讯速率，见图7
图7
bit4-bit1:定义了读写器支持的最大帧长度，具体见图3
3、参数3
bit8-bit5:
读写器应设置该域为0000，设置为其他值时，卡片应该不响应。
bit4-bit1：
读写器应设置bit4为0；
如果bit8-bit4不为00000，那么表示支持ISO14443标准；
卡片应不理会bit4-bit2的值，即仍然采用最小TR2
bit1：设置为1表示支持ISO14443-4协议，否则表示不支持。
4、参数4
bit8-bit5：应设置为0
bit4-bit1：定义了CID,如果在ATQB中，卡片告诉读写器自己不支持CID，那么读写器发送的参数中该域应该为0.
PBOC规范中对CID的要求是，卡片可支持CID且应该能同不带CID的读写器进行通讯。但是要求PCD不使用CID。也就是说，该域必须设置为0000
第五、Attrib命令的响应
这里主要关注第一个字节，该字节有两部分组成
bit8-bit5：MBTI
0：表示卡片不提供自身内部的最大缓冲区
1: 表示卡片提供自身内部的最大缓冲区，其计算公式为
MBL=PICC最大帧大小*pow(2,MBTI-1);
bit4-bit1:CID
如果卡片不支持CID，那么该域为0，如果支持，那么该域的值应该和ATTRIB中参数4中分配的CID相同
在PBOC规范中，卡片返回这个域必须是0，读写器不必理会该域。
通过两次交互，读写器和卡片之间协商了双方通讯必须共同遵守的规则。
四、文件结构及访问
第一、文件类别
PBOC规范支持两种文件：专用文件(DF),基本文件EF。
---DF 用于支持应用、文件夹和数据对象存储。一个应用DF对应一种应用。DF可以作为其它文件的父文件。这
些文件成为该DF的直属文件。
---EF 用于存放数据。EF文件不能作为其它文件的父文件。EF可分为两类：
--内部EF:用于存储该卡所解释的数据，即为了管理和控制目的由卡所分析和使用的数据。
--工作EF:用于存储不由卡所解释的数据，即仅由外界待使用的数据。
见图1所示：
图 1
图1显示了一个带有安全结构的DF层次结构，这种结构中，处于根部的DF称为主文件MF。所有DF既可以是应用DF也可以是其它DF结构。
在实际的应用中，为了便于理解，我们往往将根部的DF直接命名为MF，这样卡片相当于有三种文件类型：MF,DF,EF。
第二、具体的应用实例
在PBOC应用中，有如下几种文件:
MF:
每个卡片中只能有一个MF,在PBOC规范中，这个MF的文件名称为"1PAYS.SYS.DDF01"称为支付环境PSE
DF:
又分为
ADF（Application Definition File):应用定义文件
DDF(Directory Definition File):目录定义文件
ADF与DDF的区别在于，DDF为一个目录定义文件，其目录下仍然有下一级的目录，例如有多个ADF或者DDF.而ADF下面不能再有文件目录了，ADF下面就只能是AEF，可以说ADF是下一级没有文件目录结构的DDF,一般情况下，一个ADF定义一个实际应用。而MF可以看做一个DDF因为下面有多个ADF应用。需要注意的是，PBOC3.0里强制要求，DDF下面不能再有DDF了。
AEF(（Application Elementary File):
应用基本文件，当前的金融卡中存在两种基本文件，一种是安全基本文件，例如秘钥文件、PIN，这种文件不能读出，需要通过权限认证才能修改；第二种是工作基本文件，例如二级制文件，记录文件等。只要经过相应的权限认证即可进行读写等操作。
在卡片结构中，这三种文件以树形结构存在：以下图2为例：
图2
上图是一个项目中的金融IC卡文件结构图，省去了另外一个应用下的EF文件，但是仍能够从该图中了解到MF,ADF,AEF的结构。
金融IC卡的MF是一个AID位1PAY.SYS.DDF01的目录，SFI为3F00，我们在进行交易时，总会发送一条命令：
00 A4 00 00 02 3F 00 其实选的就是这个1PAY.SYS.DDF01这个文件。而下面的主控秘钥，传输秘钥，应用维护秘钥等秘钥是管理MF下各文件的操作权限。这些秘钥各自可以不是一组，应用时使用秘钥索引进行引用。
在MF下面有2个ADF，第一个ADF完整自定义了一个实际应用。这个ADF下面的SFI分别为01、02、03、04、05的文件以及秘钥文件等就是AEF即应用基本文件。其中ADF下的秘钥文件定义了一组秘钥，用于管理该ADF目录下各文件的访问权限。
一般情况下，MF和ADF都有各自的管理秘钥，这组秘钥规定了各自管辖范围内文件的读，写，擦除的权限。
用用程序要访问这些文件需要先通过内部认证命令。因而对秘钥文件进行更改时仍然需要通过外部认证。
第二、文件的引用
选择了一个结构，就可以访问其数据，如果选择了一个DF结构就可以访问其子结构。结构的选择有四种方法：
1、通过DF名引用，任何DF都可以通过按照1-16个字节编码的DF名称来引用。任何应用标识符AID都可作为DF名称。为了无二义的通过DF名称选择一个DF,PBOC规定在同一目录下，DF的名称应该是唯一的。例如在金融IC卡中都存在一个名为"1PAY.SYS.DDF01"的文件，可通过文件名对其访问，
例如使用命令
00A40400+sizeof(1PAY.SYS.DDF01）+"1PAY.SYS.DDF01"就可以选择该文件。
2、通过文件标识符引用，任何文件都可以通过按照2字节编码的文件标示符来引用。如果MF通过文件标示符来引用，应使用3F00。例如使用命令00A40000023F00.值FFFF被保留供将来使用。值3FFF和0000被保留。为了通过文件标示符来无二义的引用任何文件，PBOC规范要求在给定的DF下的所有DF和直接EF都应具有独一无二的文件标示符。例如，访问0015文件时使用的命令为00b0950000,具体的操作方式与COS命令手册以及文件的类型有关。也可是使用00A40000020015来进行访问
3、通过EF标示符选择，任何EF都可以通过值从1-30范围内的5为编码的短EF标示符来引用，用作短EF标示符的值0引用了当前选择的EF.在MF级30被保留。短EF标示符不能用在路径中也不能作为文件标示符例如在SELECT命令中使用。在图2中SFI为01、02、03、04、05的文件就可以使用这种方式进行访问
五、安全相关的PKI基础知识
公钥基础设施PKI(Public Key Infrastructure)是以不对称秘钥加密技术为基础，以数据机密性，完整性、身份认证，行为不可抵赖性为安全目的，来提供安全服务的具有普遍适用性的安全基础设施。它的主要内容包括数字证书、不对称密码技术、认证中心。证书和秘钥的管理、安全代理软件、不可否认服务、时间戳服务，相关的信息标准等，具体来说，PKI解决了信息传递中一系列必须解决的问题，例如：接收信息的人是否就是应该接收该信息的人？接收信息的人是否具有相应的安全等级来看这些信息？数据在传输和保存时，是否本人暗中修改过？数据的加密措施是否可靠？等等！必须承认，要解决上述问题虽然PKI不是唯一的方案，但是可以说PKI是目前最完善的唯一最可行的技术。PKI的主要构成如下：
第一、数字证书
是由认证机构经过数字签名后发给网上信息交易主体(企业或者个人，设备或者程序)的一段电子文档。这段文档包括主体名称、证书序列号、发证机构名称、证书有效期、秘钥算法标识、公钥和私钥信息等。签名证书和加密证书分开，最常用的证书格式为X.509 v3，x.509的证书结构如下图所示：
X.509证书格式
版本1、2、3
序列号
在CA内部唯一
签名算法标识符
指该证书中的签名算法
签发人名字
CA的名字
有效时间
起始和终止时间
个体名字
个体的公钥信息
算法
参数
密钥
签发人唯一标识符
个体唯一标识符
扩展域
签名
第二、认证中心(CA Certification Atuthority)
CA是PKI的核心。它是公正、权威、可信的第三方网上认证机构，负责数字证书的签发、撤销、生命周期管理、秘钥管理和证书在线查询等服务；CA为使用公开密钥的用户发放数字证书，以此证明证书中列出的用户名称与证书中列出的公开密钥相对应；CA在数字证书上的数字签名使得攻击者不能伪造和篡改数字证书；
CA还负责数字证书的撤销，公布列入CRL的证书
CA的主要职责如下:
接收验证最终用户数字证书的申请。
确定是否接受最终用户数字证书的申请-证书的审批。
向申请者颁发、拒绝颁发数字证书-证书的发放。
接收、处理最终用户的数字证书更新请求-证书的更新。
接收最终用户数字证书的查询、撤销。
产生和发布证书废止列表CRL（Certificate Revocation List） 。
数字证书的归档。
密钥归档。
历史数据归档。
第三、证书注册审批机构(RA Rregistration Authority)
RA是CA的数字证书发放、管理的延伸。它负责数字证书申请者的信息录入、审核、以及数字证书的发放工作，同时对发放的数字证书进行管理。RA系统是整个CA中心正常运营不可缺少的一部分，是CA和用户的接口。
主体注册证书的个人认证，确认主体所提供的信息的有效性。这里的信息可以是书面形式的，也可以是电子形式的。但签发证书所需的公钥必须是电子形式的。
根据请求信息，验证请求者的身份检查请求信息是否完整和正确。如果正确，则进行下一步，否则，退回请求。对该请求分配一个身份识别符，且该身份识别符是唯一的，并对该请求信息、数字公钥和身份识别符进行签名。将上述签名连同以上信息提交给证书机构CA，并把提交信息在本地做一个备份，在这里信息提交的信道应该是加密的，而且对提交的请求应做数字签名
第四、端实体
包括持有者和验证者两种。持有者是证书的拥有者，是证书所声明的主体。持有者向管理实体申请并获得证书，也可以在需要时请求更新或撤销证书。持有者使用证书向对方证实自己的身份，从而获得相应的权利。验证者通常是授权的，确认对方所提供的证书的有效性和对方是否为该证书的真正拥有者，只有在成功鉴别之后才可授权对方。
第五、证书库
证书库中存取的对象是证书和CRL,其完整性由数字签名保证，因此对证书库的操作可在无特殊安全保护的信道上传输。
不同的实体间通过PKI操作完成证书的请求、确认、发布和撤销、更新和获取等过程。PKI操作分为存取操作和管理操作两类。前者涉及管理实体、终端实体与证书库之间的交互，操作的目的是向证书库存放证书和CRL，或从证书库中读取证书和CRL;后者涉及管理实体与端实体之间或管理实体内部的交互，操作的目的是完成证书的各项管理任务和建立证书链。各实体共同构成了一个PKI系统。
第六、其它
秘钥和证书管理工具：管理和审计数字证书的工具，认证中心使用它来管理一个CA上的证书。
双证书体系：PKI采用双证书体系，非对称算法支持RSA和ECC算法，对称秘钥算法支持国家密码管理委员后制定的算法。
产生、验证和分发密钥方式:
用户自己产生密钥对：用户自己生成密钥对，然后将公钥以安全的方式传送给CA，该过程必须保证用户公钥的可验证性和完整性。
CA为用户产生密钥对： CA替用户生成密钥对,然后将其安全地传给用户，该过程必须确保密钥对的机密性、完整性和可验证性。该方式下由于用户的私钥为CA所知，故对CA的可信性要求更高。
CA(包括PAA、PCA、CA)自己产生自己的密钥对
双秘钥证书的生成过程：
1、用户使用客户端产生双秘钥对
2、用户的签名私钥保存在客户端
3、用户将签名秘钥对中的公钥发给CA中心
4、CA中心为用户的公钥签名，产生签名证书
5、CA中心将该签名证书传给客户端保存
6、KMC为用户产生加密秘钥对
7、KMC备份加密秘钥用于密钥恢复
8、CA中心为加密秘钥对生成加密证书
9、CA中心将用户的加密私钥和加密证书打包成标准格式PKCS#12格式
10、将打包后的文件传给客户端
11、用户客户端装入加密公钥证书和加密私钥
用到的关键技术
数字时间戳技术
时间戳是用来标明一个事件发生的日期和时间的一种记号，它一般是同生成该记号的人或机构的身份联系在一起的。这个标记一般被附加在消息的后面，或以某种方式使其与消息形成逻辑上的关联。
时间戳是由交易各方、可信任的第三方以及电信服务提供商们为了某种目的而生成的。
可信任的第三方会让专门的时间戳服务机构在消息或摘要里附上时间数据后，再对结果进行数字签名。这种时间戳就可以用来作为支持不可否认性的证据。
数字签名
利用发信者的私钥和可靠的秘钥算法对待发送信息或者电子摘要进行加密处理，这个过程和结果就称为数字签名。收信者可以利用发信者的公钥对收到的信息进行解密从而辨别真伪。经过数字签名后的信息具有真实性和不可否认性。 如下图所示，显示了一个完整的验证过程：
首先，甲需要验证乙所用证书的真伪。当乙在网络上将证书传送给甲时，甲使用CA的公钥解开证书上的数字签名，如果签名通过验证，则证明乙持有的证书是真的；其次，甲还需要验证乙身份的真伪。乙可以将自己的口令用自己的私钥进行数字签名传送给甲，甲已经从乙的证书中或从证书库中查得了乙的公钥，甲就可以用乙的公钥来验证乙的数字签名，如果该签名通过验证，乙在网络中的真实身份就能够确定，并能获得甲的的信任，反之，当乙确定了甲的真实身份后，甲乙双方就可以建立相互信任关系
六、变长记录文件
PBOC金融卡根目录下变长记录文件解析
根目录的变长记录文件其实主要的作用是用于脱机数据认证，其tag为70,其组织结构如下图所示：
例如下面的数据是一个变长记录文件的内容:
702A61284F08A000000333010101500B50424F43204352454449549F120B50424F4320435245444954870101
这段内容可分解为如下几个部分:
70:用于脱机数据认证的记录文件Tag
2A:是文件长度
61:应用入口
28:目录入口1长度
4F:目录入口1（ADF或者DDF)，这里4F表示为ADF
08:ADF长度
A000000333010101:表示借记卡;A0000003330101012表示贷记卡
50:EMV规定将成为必备数据，和AID相关的便于记忆的数据，用于应用选择
0B:该数据长度
50424F4320435245444954:应用数据“PBOC2 后边的不知道是什么意思了"
9F12:应用首选名称
0B 50424F4320435245444954:L+V
870101:87为应用优先级指示器首01为长度后01表示优先级，01表示优先级最高，15表示优先级最低
因为是变长记录文件，所以这个文件是可以扩展的，例如这里面可以包含9F62持卡人身份信息，5F20持卡人姓名等等内容。
七 ----应用选择
前言，最近一段时间由于考职称，还有项目比较忙，忽略了博客的更新，现在项目告一段落便将项目中的收获记下来。
PBOC3.0里选择应用总是从选择PPSE开始的，称为支付系统环境。对于非接触卡，选择的字符系统环境为1PAY. SYS. DDF01,而对于非接触卡选择的支付系统环境为”2PAY.SYS.DDF01”
PBOC支持两种搜索目录的方式：第一种为目录选择方式，第二种为AID列表选择方式，现在就对这两种方式分别介绍。在介绍之前，大家必须实现知道两个专用术语：
“AID”用于终端上的应用标识符，
“DF名”用于卡上的应用标识符
第一种、目录选择方式
选择支付系统环境的命令为:
|
代码 |
值 |
|
CLA |
‘00’ |
|
INS |
‘A4’ |
|
P1 |
引用控制参数（见表1） |
|
P2 |
选择选项（见表2） |
|
Lc |
‘05’-‘10’ |
|
Data |
文件名 |
|
Le |
‘00’ |
表1 SELECT命令引用控制参数
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
含义 |
|
0 |
0 |
0 |
0 |
0 |
||||
|
1 |
通过名称选择 |
|||||||
|
0 |
0 |
|||||||
表2定义了选择（SELECT）命令报文的选择选项P2：
表2 选择（SELECT）命令的可选参数
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
含义 |
|
0 |
0 |
第一个有或仅有一个 |
||||||
|
1 |
0 |
下一个 |
||||||
选择PSE后，卡片返回的数据源如下所示:
表3 选择PSE的响应报文（FCI）
|
标识 |
值 |
存在性 |
|||
|
‘6F’ |
FCI模板 |
M |
|||
|
‘84’ |
DF名 |
M |
|||
|
‘A5’ |
FCI数据专用模板 |
M |
|||
|
‘88’ |
目录基本文件的SFI |
M |
|||
|
‘5F2D’ |
语言选择 |
O |
|||
|
‘9F11’ |
发卡行代码表索引 |
O |
|||
|
‘BF0C’ |
发卡行自定义数据（FCI） |
O |
|||
|
‘XXXX’ （根据附录B建立的标签） |
来自从应用提供商、发卡行或IC卡供应商或JR/T 0025定义的专属于’BF0C’标签的1个或多个附加（专用）数据元。 |
O |
|||
其中，M表示必须存在，O表示可选。标签值84称为专用文件名称，即DDF名称，如果这个84标签的值和你选择的支付系统名称相同，则可以直接采用AID列表方式搜索应用。这里标签值88是个关键，终端需要保存起来，通过这个SFI读取记录文件，遍历卡片应用系统目录，以便搜索到可以支持的应用。
其中读记录文件的命令如下所示：
表4 读记录命令报文
|
代码 |
值 |
|
CLA |
‘00’ |
|
INS |
‘B2’ |
|
P1 |
记录号 |
|
P2 |
引用控制参数（见表5） |
|
Lc |
不存在 |
|
Data |
不存在 |
|
Le |
‘00’ |
表5定义了命令报文的引用控制参数。
表5 读记录命令引用控制参数
|
b8 |
b7 |
b6 |
b5 |
b4 |
B3 |
b2 |
b1 |
含义 |
|
X |
X |
X |
X |
X |
SFI |
|||
|
1 |
0 |
0 |
P1为记录号 |
|||||
支付系统目录（以下简称目录）是一个线性EF文件，用1到10的短文件标识符（SFI）标识。目录可以使用第7章中所定义的读记录（READ RECORD）命令进行读取。一个记录可以包含几个入口地址，但一个入口地址只能封装在一个记录中。
支付系统目录中的每一个记录都是一个结构数据对象，其值由如下所示的一个或多个目录的入口组成。
每个记录的格式，见表7。
表6 支付系统目录记录格式
|
‘70’ |
数据域长度 （L） |
标识符 ‘61’ |
目录入口1长度 |
目录入口1 （ADF） |
…… |
标识符 ‘61’ |
目录入口n 长度 |
目录入口n （ADF） |
支付系统目录记录中应当不包含任何通往DDF的入口。如果终端在处理这些记录时遇到了DDF的入口，终端可以忽略这些入口或者处理这些入口，处理入口的方法不在JR/T 0025的讨论范围内。
支付系统目录中的每一个入口都是一个应用模板（标签‘61’），它包含表42或表43所示的信息。除了在模板‘73’中包含的数据元，任何附加数据元都不能在支付系统目录记录（标签‘70’）中出现。由于终端不支持任何发卡行特定操作而未预期的或不能解释的，在支付系统目录记录中出现的模板‘61’或‘73’数据元，都应该被忽略。
任何没有封装在目录记录的应用模板（标签‘61’）当中的数据对象或其它在目录入口中出现但是没有在表7中列出的数据对象都应该被忽略。
表7 ADF目录入口格式
|
标签 |
长度 |
值 |
存在方式 |
|
|
‘4F’ |
5-16 |
ADF名称（AID） |
M |
|
|
‘50’ |
1-16 |
应用标签 |
M |
|
|
‘9F12’ |
1-16 |
应用优先名称 |
O |
|
|
‘87’ |
1 |
应用优先权标识符 |
O |
|
|
‘73’ |
变长 |
目录自定义模板 |
O8 |
|
|
‘XXXX’ （根据附录B建立的标识符） |
变长 |
应用提供商、发行商或IC卡供应商、或JR/T 0025定义的专属于模板’73’的标签增加的1个或多个附加（专用）数据元。 |
O |
|
表8 应用优先权标识符格式
|
b8 |
b7-b5 |
b4-b1 |
定义 |
|
1 |
需要持卡人确认方可选择应用 |
||
|
0 |
不需持卡人确认即可选择应用 |
||
|
‘XXX’ |
预留 |
||
|
0 0 0 0 |
未指定优先权 |
||
|
‘XXXX’ （0 0 0 0除外） |
应用的排列或选择顺序，从1-15，其中最高优先权为1 |
||
终端需要搜索每一个标签61的值，其中4F的值就是我们需要的AID，在保存这些AID之前，终端需要先进行判断自己是否支持对这些AID进行操作，不支持则丢弃掉，支持的话则保存起来，这个50标签是银联强烈建议存在的，我层操作过一些卡发现有的卡里其实并没有这个标签，当没有这个标签时，就存在一个问题：如果卡片仅支持一个应用。且应用优先级指示器的最高位为1，即终端必须将这个应用的名称显示出来让持卡人选择，如果没有这个50标签，请问持卡人怎么选择？同样的道理如果卡片里有多个应用，优先级分别为1、2、3、5、5，这个时候终端最好的办法是按优先级将所有应用从高优先级到低优先级排列，如果优先级相同，则按照卡片返回的顺序进行排列，如果有多个应用没有指定优先级则也按照卡片返回的顺序排列优先级并显示给持卡人，让持卡人选择，如果没有标签50，那么持卡人就没法进行选择。
使用目录方法的选择流程如下图所示：
下面是终端使用目录方法的步骤：
步骤1： 终端通过使用选择（SELECT）命令（见第11章）来选择文件名为“1PAY.SYS.DDF01”的支付系统环
境 而开始，由此建立支付系统环境并进入初始目录。
如果卡被锁定或者选择（SELECT）命令不支持（这两种情况都会回送状态字SW1 SW2
=“6A81”）， 终端必须中断选择过程。
如果IC卡上没有PSE，那么IC卡应该对PSE的选择（SELECT）命令回送状态字“6A82”（文件没有找
到）。在这种情况下，终端必须使用AID应用列表的方式。
如果PSE被锁定，IC卡应该回送状态字“6283”。在这种情况下，终端应该使用AID应用列表的方式。
如果IC卡回送状态字SW1 SW2 =“9000”，终端则转入步骤2。
如果卡回送其他状态字SW1 SW2，终端应该使用12.3.3条所描述的使用应用列表的方式。
如果在步骤2到步骤5中出现任何错误（包括SW1 SW2 ≠“90 00”，“6A 83”），终端应清除候选列
表AID应用列表方式重新进行应用选择，以寻找匹配的应用。
步骤2： 终端使用卡片返回的FCI中的目录SFI，从目录的第1条记录开始，连续读取后续记录，直到卡回送状态字
SW1 SW2=“6A83”，表示所请求的记录序号已不存在（如果读记录（READ RECORD）命令中记录
号大于文件的最后一条记录号时，卡应该回送状态字“6A83”）。如果在执行读记录（READ
RECORD）命令查找第1个记录时，卡回送状态字“6A83”，则表示目录入口为空，转到下面的步骤
5。
对于目录中的每一条记录，终端从第一个目录入口开始，依次对每个目录入口顺序执行步骤3和步骤4所
描述的过程。如果某条记录中不含有目录入口，则终端处理下一条记录。
步骤3： 如果该入口对应某一ADF，且ADF名与终端支持的一个应用相匹配，则在应用选择指示器（ASI）（保
存在终端中，与该AID对应）的控制下将该应用列入最终应用选择的“候选列表”中。
应用选择指示器（ASI）表明终端的应用标识符应完整匹配（长度和值都相同）还是只需部分匹配卡片
中相关的ADF名（标签为‘4F’）。
在下面任一种情况下，该应用将被选入候选列表：
——获得的入口中的ADF是完整匹配，或者
——对应终端中该AID的应用选择指示器（ASI）表明允许部分名称匹配。
如果得到的ADF入口不是完整匹配，并且终端AID的应用选择指示器表明须要完整匹配时，应用不能被
加入候选列表。
步骤4： 当终端处理完最后一个记录中的所有入口后，所有能够按此方法找到的ADF就被确定了，查找和产生
候选列表的工作完成。如果发现了至少一个匹配的ADF，终端将继续执行第三节、应用选择方式条所
描述的处理过程。
如果步骤1到步骤4中没有发现与终端支持的应用所匹配的目录入口，终端应该使用AID应用列表的方
式 来寻找匹配的应用。
第二种：AID列表选择方式
AID 列表选择的方式说的简单一点就是暴力穷举的方式，这是在目录选择方式失败后所采取的方法，具体的操作过程就是终端根据自己支持的AID列表，使用保存在终端的AID列表里的AID逐次发给卡片进行尝试，如果返回的状态字为SW=9000则表示卡片支持该应用，那么就应该将这个AID加入到支持列表。尝试完保存在终端的所有AID后，终端得到一组双方都支持的AID列表，如果只支持一个应用，且优先级指示符的最高位为1，则终端可让持卡人对该应用进行确认后再进行操作，否则直接选择该应用进行操作。如果有多个支持的应用，则应该根据优先级指示器对其进行排序，如果有多个应用的优先级相同则按照卡片返回的顺序进行排列，如果有多个应用没有指定优先级则同样按照卡片返回的顺序，没有制定优先级默认为优先级最低。具体的操作流程如下图：
终端执行以下步骤：
步骤1： 终端使用其列表中的第一个AID为文件名发出选择（SELECT）命令。
步骤2： 如果卡被锁定或者选择（SELECT）命令不支持导致选择（SELECT）命令失败（IC卡回送状态字SW1
SW2=“6A81”）， 终端将中断选择过程。
步骤3： 如果选择（SELECT）命令执行成功（SW1 SW2=“9000”或“6283”），终端应比较AID和卡返回
的FCI中的DF名。DF名应该同AID相同（包括长度），或者DF名以AID为开始并且长度大于AID。如
果DF名比AID长，卡将进行部分名称选择处理。如果DF名同AID相同，终端应进入到步骤4。如果进
行了部分名称选择，终端应进入步骤6。如果终端返回其它状态，应进入步骤5。
步骤4： 如果选择（SELECT）命令成功（SW1 SW2=“9000”），终端应将所选择文件的FCI信息添加到候
选列表中并进入步骤5。如果应用已锁定（SW1 SW2 =“6283”），终端应直接进入步骤5而不将
DF名添加到候选列表。
步骤5： 终端使用其列表中的下一个AID发出另一个选择（SELECT）命令，回到步骤3。如果列表中没有剩余
的AID，那么候选列表建立完成，终端按照第三节应用选择方法中规定的步骤进行后续处理。
步骤6： 对应于AID列表，终端还保存了表明卡是否允许有多个应用匹配的应用选择指示器。终端在选择应用
时会检查该指示符。如果指示符表明需要完整匹配（包括长度和名称），那么终端将不会把文件添加
到候选列表，而是进入步骤7。
如果允许多应用匹配，那么部分名称匹配即可。
如果应用没有锁定（SW1 SW2 =“9000”），终端将会添加FCI信息到候选列表，然后进入步骤7。
如果允许多应用匹配但是应用已锁定（SW1 SW2 ≠“9000”），则终端应直接进入步骤7而不将
FCI 信息添加到候选列表。
步骤 7： 终端使用与之前相同的命令数据，但将命令中的P2参数设置为02（“选择下一个”），重复发出选择
（SELECT）命令，如果IC卡返回状态字SW1 SW2=“9000”，“62XX”，或者“63XX”，然后回
到步骤3。如果返回其它状态字，终端转到步骤5。
第三、应用选择方法
当终端确定了卡与终端共同支持的应用列表之后，就进行如下处理：
步骤1： 如果没有共同支持的应用，交易终止。
步骤2： 如果只有一个共同支持的应用，则如果有应用优先级标识符（API），终端检查该应用的应用优先级
标识符的b8位。如果b8=‘0’，则终端选择该应用。如果b8=‘1’并且终端提供持卡人的确认功
能，终端即请求持卡人确认。如持卡人确认，则选择该应用。如果终端不提供持卡人的确认功能，或
终端请求确认而持卡人拒绝，则终端终止该交易过程。
步骤3： 如果有多个共同支持的应用，则可以按照步骤4中的描述显示列表供持卡人选择，或者按照步骤5的描
述自动完成选择。步骤4是首选的方法。
步骤4： 如果向持卡人显示列表，则该列表应该按照级别优先的顺序排列，高优先级的应用应该在前。如果
卡 上没有指定应用的优先顺序，则以终端的应用优先顺序为准，如果终端也没有指定应用的优先顺
序，则按照应用在卡中出现的顺序为准。如果出现多个应用有相同的优先级，或某个入口缺少应用优
先级标识符的情况，也可采用类似的方法。也就是说，在这种情况下，终端可以使用自己的优先顺
序，也可以按卡上应用出现的的顺序将有重复优先级或没有优先级的应用显示出来。
步骤5： 终端可以无需持卡人的介入而直接选择应用。在这种情况下，终端从共同支持的应用列表中选择优先
级别最高的应用。如果终端不提供持卡人对选择的应用确认，则那些不经过持卡人确认就不能选择的
应用（应用优先级标识符的b8=‘1’）应从可选列表从删除。
一旦终端或持卡人确定了待执行的应用，则该应用应被选中。终端向该应用发出选择（SELECT）命
令（按照第11章进行编码，使用建立候选列表时得到的ADF名称（如果采用目录方式）或者FCI中的
DF名（如果采用应用列表方式）作为数据域）。如果命令回送的状态字SW1 SW2≠“9000”，或者
选择命令的响应中有格式错误，则此应用应该从候选列表中删除，然后回到步骤1。如果持卡人选择
或确认了某个应用，而随后该应用又因为应用锁定或其它原因被从候选列表中删除，则应用不能在没
有持卡人确认的情况下被选中。
在任何情况下，终端应该在适当的时候提示持卡人相关动作的完成。
第四、本规范中AID编码的定义
本规范采用GB/T 16649.5规定的应用标识符（AID）基本结构，应用标识符(AID)长度为5-16个字节，由5个字节的注册的应用提供者标识符(RID)和0-11个字节的专有应用标识符扩展(PIX)组成。
应用标识符（AID）唯一标识卡中的应用。由申请机构向金融行业主管部门申请，由管理部门统一组织分配。
4.1. 应用提供者标识符（AID）总体编码
应用提供者标识符（RID）总体编码
依据GB/T16649.5关于AID的规定，应用标识符（AID）编码如下所示：
表9 应用标识符（AID）编码
|
应用提供者标识符（RID） |
专有应用标识符扩展（PIX） |
|
5个字节 |
0至11个字节 |
4.2. 专有应用标识符扩展（PIX）编码
具体定义请见表10。
应用类型代码必须出现，其定义请见表11。
保留位可选出现，若该字段不出现，则其后续字段不应当出现。若该字段出现，则该字段取值由发卡机构自行定义。
专有定义标识可选出现，若该字段不出现，则专有定义字节不应当出现。若该字段存在，则其定义参见表10。
专有定义字节可选出现。
表10 专有应用标识符扩展(PIX)编码
|
应用类型代码 |
保留位 |
专有定义标识 |
专有定义字节 |
|
3个字节 |
0-1个字节 保留给发卡机构 |
0-1个字节 00表示专有定义字节中的内容由本规范保留定义 01-FF保留 |
0-6个字节 |
4.3. 应用类型代码定义
应用类型代码第1字节为00-FE的应用类型代码，保留给本规范使用。其取值的部分定义见表11。
应用类型代码第1字节为FF的应用类型代码，保留给发卡机构使用。
表11 应用类型代码定义
|
值 |
定义 |
|
01 01 01 |
借记 |
|
01 01 02 |
贷记 |
|
01 01 03 |
准贷记 |
如果在最终选择期间给持卡人提供列表，则应用标签和应用优先名称必须保存。DF名和应用优先权标识符在任何情况下都可能需要。
八----GPO命令
第一、GPO命令
GPO命令主要的功能时告诉卡片，交易的金额，是否支持电子现金，以及终端的交易属性等参数，在选择应用时，卡片会返回一个PDOL标签值，其标签为9F38，终端应该保存这个列表，GPO命令的数据域就是依据PDOL列表发送的，数据发送的顺序是按照标签在PDOL中的顺序排列的。
举例来说：
卡片返回的PDOL数据:9F66049F02069F03069F1A0295055F2A029A039C019F3704
具体解析如下
9F6604 标签9F66的定义如下:
表1 终端交易属性（标签为“9F66”）
|
字节 |
位 |
定义 |
|
1 |
8 |
预留 |
|
7 |
1 – 支持非接触式借记/贷记应用 0 – 不支持非接触式借记/贷记应用 |
|
|
6 |
1 – 支持qPBOC 0 – 不支持qPBOC |
|
|
5 |
1 – 支持接触式借记/贷记应用 0 – 不支持接触式借记/贷记应用 |
|
|
4 |
1 – 终端仅支持脱机 0 – 终端具有联机能力 |
|
|
3 |
1 – 支持联机PIN 0 – 不支持联机PIN |
|
|
2 |
1 – 支持签名 0 – 不支持签名 |
|
|
1 |
预留 |
|
|
2 |
8 |
1 – 要求联机密文 0 – 不要求联机密文 |
|
7 |
1 – 要求CVM 0 – 不要求CVM |
|
|
6-1 |
预留 |
|
|
3 |
8-1 |
预留 |
|
4 |
8-1 |
预留 |
终端在GPO命令中应该如实的将终端的性能参数等发给卡片，以便卡片进行下一步的操作。
9F0206 授权金额
所谓授权金额，其实就是在交易时你要消费的金额。或者说终端机持有人输入的金额，然后要求你输入密码确认。
这个授权金额为6个字节，每半个字节代表10进制的一位，且单位为分，请注意不是“元”
例如假如你的银行卡里有563.99元人民币，那么存储的数据格式应该是:
0 0 0 0 0 0 0 5 6 3 9 9刚好占用6个字节
9F03 06,这个是其它金额，目前还没有定义，全部输入6个字节的0
9F1A 02 终端国家代码，中国的国家代码为01 56
95 05 是终端验证结果，这5个字节定义如下:
字节1：
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
意义 |
|
1 |
x |
x |
x |
x |
x |
x |
x |
未进行脱机数据认证 |
|
x |
1 |
x |
x |
x |
x |
x |
x |
脱机静态数据认证失败 |
|
x |
x |
1 |
x |
x |
x |
x |
x |
IC卡数据缺失 |
|
x |
x |
x |
1 |
x |
x |
x |
x |
卡片出现在终端异常文件中 |
|
x |
x |
x |
x |
1 |
x |
x |
x |
脱机动态数据认证失败 |
|
x |
x |
x |
x |
x |
1 |
X |
x |
复合动态数据认证/应用密文生成失败 |
|
x |
x |
x |
x |
x |
x |
0 |
x |
RFU |
|
x |
x |
x |
x |
x |
x |
x |
0 |
RFU |
字节2：
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
意义 |
|
1 |
x |
x |
x |
x |
x |
x |
x |
IC卡和终端应用版本不一致 |
|
x |
1 |
x |
x |
x |
x |
x |
x |
应用已过期 |
|
x |
x |
1 |
x |
x |
x |
x |
x |
应用尚未生效 |
|
x |
x |
x |
1 |
x |
x |
x |
x |
卡片不允许所请求的服务 |
|
x |
x |
x |
x |
1 |
x |
x |
x |
新卡 |
|
x |
x |
x |
x |
x |
0 |
x |
x |
RFU |
|
x |
x |
x |
x |
x |
x |
0 |
x |
RFU |
|
x |
x |
x |
x |
x |
x |
x |
0 |
RFU |
字节3：
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
意义 |
|
1 |
x |
x |
x |
x |
x |
x |
x |
持卡人验证失败 |
|
x |
1 |
x |
x |
x |
x |
x |
x |
未知的CVM |
|
x |
x |
1 |
x |
x |
x |
x |
x |
PIN重试次数超限 |
|
x |
x |
x |
1 |
x |
x |
x |
x |
要求输入PIN，但密码键盘不存在或工作不正常 |
|
x |
x |
x |
x |
1 |
x |
x |
x |
要求输入PIN，密码键盘存在，但未输入PIN |
|
x |
x |
x |
x |
x |
1 |
x |
x |
输入联机PIN |
|
x |
x |
x |
x |
x |
x |
0 |
x |
RFU |
|
x |
x |
x |
x |
x |
x |
x |
0 |
RFU |
字节4：
|
b8 |
b7 |
b6 |
B5 |
b4 |
b3 |
b2 |
b1 |
意义 |
|
1 |
x |
x |
x |
x |
x |
x |
x |
交易超过最低限额 |
|
x |
1 |
x |
x |
x |
x |
x |
x |
超过连续脱机交易下限 |
|
x |
x |
1 |
x |
x |
x |
x |
x |
超过连续脱机交易上限 |
|
x |
x |
x |
1 |
x |
x |
x |
x |
交易被随机选择联机处理 |
|
x |
x |
x |
x |
1 |
x |
x |
x |
商户要求联机交易 |
|
x |
x |
x |
x |
x |
0 |
x |
x |
RFU |
|
x |
x |
x |
x |
x |
x |
0 |
x |
RFU |
|
x |
x |
x |
x |
x |
x |
x |
0 |
RFU |
字节5：
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
意义 |
|
1 |
x |
x |
x |
x |
x |
x |
x |
使用缺省TDOL |
|
x |
1 |
x |
x |
x |
x |
x |
x |
发卡行认证失败 |
|
x |
x |
1 |
x |
x |
x |
x |
x |
最后一次GENERATE AC命令之前脚本处理失败 |
|
x |
x |
x |
1 |
x |
x |
x |
x |
最后一次GENERATE AC命令之后脚本处理失败 |
|
x |
x |
x |
x |
0 |
x |
x |
x |
RFU |
|
x |
x |
x |
x |
x |
0 |
x |
x |
RFU |
|
x |
x |
x |
x |
x |
x |
0 |
x |
RFU |
|
x |
x |
x |
x |
x |
x |
x |
0 |
RFU |
这个标签的含义在于终端将自己操作过程中碰到的错误告诉卡片，卡片根据这个来决定是否拒绝交易，或者需要连接进行确认。这个实在终端行为分析和终端风险管理中进行赋值操作的。
5F2A 02 是交易货币代码，中国的交易货币代码和国家代码一致都是0156
9A 03 9A是交易日期，按年 月 日的方式排列，同样，每半个字节表示一个十进制数
例如交易时间是2014年10月21日，那么这个标签值就是 1 4 1 0 2 1 从10进制的角度来就是20 16 33
9C 01 这是交易类型，交易类型的定义如下：
字节1：交易类型性能
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
意义 |
|
1 |
x |
x |
x |
x |
x |
x |
x |
现金 |
|
x |
1 |
x |
x |
x |
x |
x |
x |
商品 |
|
x |
x |
1 |
x |
x |
x |
x |
x |
服务 |
|
x |
x |
x |
1 |
x |
x |
x |
x |
返现 |
|
x |
x |
x |
x |
1 |
x |
x |
x |
查询 |
|
x |
x |
x |
x |
x |
1 |
x |
x |
转账 |
|
x |
x |
x |
x |
x |
x |
1 |
x |
付款 |
|
x |
x |
x |
x |
x |
x |
x |
1 |
管理 |
字节2：交易类型性能
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
意义 |
|
1 |
x |
x |
x |
x |
x |
x |
x |
存款交易 |
|
x |
0 |
x |
x |
x |
x |
x |
x |
RFU |
|
x |
x |
0 |
x |
x |
x |
x |
x |
RFU |
|
x |
x |
x |
0 |
x |
x |
x |
x |
RFU |
|
x |
x |
x |
x |
0 |
x |
x |
x |
RFU |
|
x |
x |
x |
x |
x |
0 |
x |
x |
RFU |
|
x |
x |
x |
x |
x |
x |
0 |
x |
RFU |
|
x |
x |
x |
x |
x |
x |
x |
0 |
RFU |
这里我们只需将第一个字节传给卡片就行，这是附加终端性能的第一个字节，具体定义在第6部分
9F37 04，不可预知数，随意，最好去随机数
GPO 命令将这些参数传入到卡中，传入的次序与PDOL的次序一致。例如
GPO:80A80000238321600000000000000000000000000000000156000000000001561405306099999999
分解如下21
60000000 终端交易属性
000000000000授权金额
000000000000其它金额
0156 发卡行国家代码
0000000000 终端交易属性tvr
0156 交易货币代码
140530 交易日期 14年5月30日
60 交易类型，为国内服务或者商品
99999999 不可预知数
如果这张卡片式支持电子现金交易，那么其PDOL数据中比寻存在9F7A标签，否则检测时通不过。
第二、GPO响应
GPO命令的响应与你所选择的用用有关，例如你选择了qPBOC那么返回的会是以77为首的标签，以77为首的标签也会返回ATC与AFL但是数据是以TLV格式返回的，当以80为首返回时，返回的格式如下:
AIP和AFL,其中AFL是以4字节的倍数存在的。
例如
响应:800E7C000801020010010401180103009000
响应命令的解析如下:
80标签
0E长度
7C00 表示应用交互特征AIP AIP的定义如下:
字节1：
位8：1=RFU
位7：1=支持SDA
位6：1=支持DDA
位5：1=支持持卡人认证
位4：1=执行终端风险管理
位3：1=支持发卡行认证
位2：RFU（0）
位1：1=支持CDA
字节2：RFU（“00”）
这个列表说明了卡片的支持能力
同样终端如果也支持响应的功能则在交易的过程中将选择响应的功能，需要注意的是对于认证的优先级PBOC是做了如下的规定CDA>DDA>SDA,也就是说如果双方都支持CDA，那么终端优先进行CDA认证，终端必须选择双方共同支持的认证方式中优先级最高的，请注意两个关键词，双方共同支持与优先级最高
关于认证，后续将会详细介绍，这里不再赘述。
08010200 10010401 18010300 这三组数据，每组4个字节成为应用文件定位器AFL，AFL的定义如下：
包含终端将要读取用来交易处理的卡片数据文件的SFI和记录范围。每个要读取的文件在AFL中对应四个字节含义如下：
字节1：短文件标识符
字节2：文件中要读取的第1个记录的记录号
字节3：文件中要读取的最后一个记录的记录号
字节4：从第1个记录开始的用于脱机数据认证的连续记录数
终端将根据AFL的提示读取所有要求的记录，这里请注意第四个字节，这些数据时要进行脱机数据认证的，所以终端必须保存起来
第三、错误
卡片在一条或多条记录中返回同一个标签两次及两次以上；
卡片在某条记录中返回了卡片已经在GPO响应中返回的标签;
卡片中缺少必须有的数据;
数据格式错；
READ RECORD命令返回状态字不是“9000”当返回6985时，终端应该讲该条应用从所支持的应用列表中删除，从新选择下一个优先级最高的应用。
九---静态数据认证
SDA的目的是确认存放在IC卡中的由应用文件定位器（AFL）和可选的静态数据认证标签列表所标识的，关键的静态数据的合法性，从而保证IC卡中的发卡行数据在个人化以后没有被非法篡改。
支持静态数据认证的IC卡个人化后应包含下列数据元：
1. 认证中心公钥索引,标签值为8F：该单字节数据元包含一个二进制数字，指明终端应使用其保存的相应的认证
中心公钥中的哪一个来验证IC卡,PBOC规范明确要求终端至少应能保证可以存储6条CA公钥；
2. 发卡行公钥证书，标签值为90：该变长数据元由认证中心提供给发卡行。
3. 签名的静态应用数据：由发卡行使用同发卡行公钥证书所认证的发卡行公钥相对应的发卡行私钥产生的变长
数据元。它是一个对存放在IC卡中的关键静态数据元的数字签名；
4. 发卡行公钥的余项
5. 发卡行公钥指数。
为了支持静态数据认证，每一台终端应该能为每个注册的应用提供商标识（RID）存储六个认证中心公钥，而且必须使得和密钥相关的密钥信息能够同每一个密钥相关联（以使终端能在将来支持多种算法，并允许从一个算法过渡到另一个）。在给定RID和IC卡提供的认证中心公钥索引的情况下，终端应能定位这样的公钥以及和公钥相关的信息。
公钥的分发过程如图1所示：
1、 认证中心和发卡行都自行产生自己的公私钥对，并各自保存自己的私钥；
2、 发卡行将自己的公钥发送给认证中心
3、 认证中心用自己的私钥对发卡行公钥进行签名并发送给发卡行，这个签名就是发卡行公钥证书；
4、 认证中心将自己的公钥传给收单行，收单行将这些公钥下载给终端设备，一般终端至少能保存5条认证中心
公钥
5、 发卡行用自己的私钥对卡内重要数据进行签名并连同发卡行公钥证书一起存储于卡片内；
6、 终端在与卡片的交互过程中，获取发卡行公钥证书以及签名的数据，以及这些签名数据对应的认证中心公钥
索引
7、 终端根据认证中心公钥索引搜索存储在终端的认证中心公钥
8、 终端采用寻找到的认证中心公钥恢复发卡行的公钥
9、 终端根据发卡行公钥恢复卡片的公钥
10、终端根据卡片公钥验证签名数据的合法性
静态数据认证包括三个步骤，即：
——由终端恢复认证中心公钥；
——由终端恢复发卡行公钥；
由终端验证签名的静态应用数据。
1.密钥和证书
为了支持静态数据认证，一张IC卡必须包含签名的静态应用数据，它是用发卡行私钥签名的。发卡行公钥必须以公钥证书形式存放在IC卡中。
为了获得发卡行公钥证书，使用认证中心私钥SCA，对表1中指明的数据进行签名。
认证中心的公钥有一个公钥模，该公钥模为NCA个字节。认证中心公钥指数必须等于3或216+1。
为了获得签名的静态应用数据，使用发卡行私钥SI，对表2中指明的数据应用11.2.1条中指明的签名方案。
发卡行的公钥有一个发卡行公钥模，该公钥模为NI个字节（NI≤NCA）。如果NI>（NCA-36），那么发卡行公钥模被分成两部分，即一部分包含公钥模中高位的NCA-36个字节（发卡行公钥中最左边的数字）；另一部分包含剩下的低位NI-（NCA-36）个字节（发卡行公钥的余项）。发卡行公钥指数必须等于3或216+1。
所有静态数据认证需要的信息在表3中详细说明，并存放在IC卡中。除了RID可以从AID中获得外，其它信息可以通过读取记录（READ RECORD）命令得到。如果缺少这些数据中的任意一项，静态数据认证即告失败。
表1 由认证中心签名的发卡行公钥数据（即哈希算法的输入）
|
字段名 |
长度 |
描述 |
格式 |
|
证书格式 |
1 |
十六进制，值为‘02’ |
b |
|
发卡行标识 |
4 |
主账号最左面的3-8个数字。（在右边补上十六进制数‘F’）应用主账号的标签值为5A。 |
cn8 |
|
证书失效日期 |
2 |
MMYY，在此日期后，这张证书无效 |
n4 |
|
证书序列号 |
3 |
由认证中心分配给这张证书的唯一的二进制数 |
b |
|
哈希算法标识 |
1 |
标识用于在数字签名方案中产生哈希结果的哈希算法 |
b |
|
发卡行公钥算法标识 |
1 |
标识使用在发卡行公钥上的数字签名算法 |
b |
|
发卡行公钥长度 |
1 |
标识发卡行公钥模的字节长度 |
b |
|
发卡行公钥指数长度 |
1 |
标识发卡行公钥指数的字节长度 |
b |
|
发卡行公钥数位或发卡行公钥的最左边部分 |
NCA–36 |
如果NI≤NCA–36，这个字段包含了在右边补上了NCA–36–NI个值为‘BB’的字节的整个发卡行公钥。 如果NI>NCA-36，这个字段包含了发卡行公钥最高位的NCA–36个字节，这个域是可变的，其实只要对比发卡行公钥长度就知道有效的公钥长度。 |
b |
|
发卡行公钥余项 |
0或NI–NCA+36 |
这个字段只有在NI>NCA–36时才出现。它包含了发卡行公钥最低位的NI–NCA+36个字节 |
b |
|
发卡行公钥指数 |
1或3 |
发卡行公钥指数等于3或216+1 |
b |
表2 由发卡行签名的静态应用数据（即哈希算法的输入）
|
字段名 |
长度 |
描述 |
格式 |
|
签名数据格式 |
1 |
十六进制，值为‘03’ |
b |
|
哈希算法标识 |
1 |
标识用于在数字签名方案中产生哈希结果的哈希算法 |
b |
|
数据验证代码 |
2 |
由发卡行分配的代码 |
b |
|
填充字节 |
NI–26 |
填充字节由NI–26个值为‘BB’的字节组成3 |
b |
|
需认证的静态数据 |
变长 |
在JR/T 0025.5的9.3.1条指明的需认证的静态数据 |
- |
认证过程的输入由被AFL标识的记录组成，其后跟有AIP[如果AIP被可选的静态数据认证标签列表（标签“9F4A”）标识]。如果静态数据认证标签列表存在，则它必须仅包含标识AIP用的标签“82”。
表3 静态数据认证用到的数据对象
|
标签 |
长度 |
值 |
格式 |
|
- |
5 |
注册的应用提供商标识 |
b |
|
‘8F’ |
1 |
认证中心公钥索引 |
b |
|
‘90’ |
NCA |
发卡行公钥证书 |
b |
|
‘92’ |
NI–NCA+36 |
发卡行公钥的余项（如果有） |
b |
|
‘9F32’ |
1或3 |
发卡行公钥指数 |
b |
|
‘93’ |
NI |
签名的静态应用数据 |
b |
|
- |
变长 |
在JR/T 0025.5的9.3.1条指明的需认证的静态数据 |
- |
2. 认证中心公钥获取
终端读取认证中心公钥索引，这个索引的标签值为8F,终端获取到AFL后通过读记录获取该标签的值，使用这个索引和RID，终端必须确认并取得存放在终端的认证中心公钥的模、指数和与密钥相关的信息，以及相应的将使用的算法。如果终端没有存储与这个索引及RID相关联的密钥，那么静态数据认证失败。
3. 发卡行公钥获取
3.1. 如果发卡行公钥证书的长度不同于在前面的过程中获得的认证中心公钥模长度，那么静态数据认证失败。
3.2. 为了获得在表4中指明的恢复数据，使用认证中心公钥和相应的算法恢复发卡行公钥证书。如果恢复数据的
结尾不等于“BC”，那么静态数据认证失败。
表4 从发卡行公钥证书恢复数据的格式
|
字段名 |
长度 |
描述 |
格式 |
|
恢复数据头 |
1 |
十六进制，值为‘6A’ |
b |
|
证书格式 |
1 |
十六进制，值为‘02’ |
b |
|
发卡行标识 |
4 |
主账号最左面的3-8个数字（在右边补上十六进制数‘F’） |
cn8 |
|
证书失效日期 |
2 |
MMYY，在此日期后，这张证书无效 |
n4 |
|
证书序列号 |
3 |
由认证中心分配给这张证书的，唯一的二进制数 |
b |
|
哈希算法标识 |
1 |
标识用于在数字签名方案中产生哈希结果的哈希算法 |
b |
|
发卡行公钥算法标识 |
1 |
标识使用在发卡行公钥上的数字签名算法 |
b |
|
发卡行公钥长度 |
1 |
标识发卡行公钥的模的字节长度 |
b |
|
发卡行公钥指数长度 |
1 |
标识发卡行公钥指数的字节长度 |
b |
|
发卡行公钥或发卡行公钥的最左边字节 |
NCA-36 |
如果NI≤NCA–36，这个字段包含了在右边补上了NCA–36–NI个值为‘BB’的字节的整个发卡行公钥。 如果NI>NCA-36，这个字段包含了发卡行公钥最高位的NCA–36个字节 |
b |
|
哈希结果 |
20 |
发卡行公钥以及相关信息的哈希值 |
b |
|
恢复数据结尾 |
1 |
十六进制，值为‘BC’ |
b |
3.3. 检查恢复数据头。如果它不是“6A”，那么静态数据认证失败。
3.4. 检查证书格式。如果它不是“02”，那么静态数据认证失败。
3.5. 将表6中的第2个到第10个数据元（即从证书格式直到发卡行公钥或发卡行公钥的最左边字节）从左到右连
接，再把发卡行公钥的余项(标签值为92）加在后面（如果有），最后是发卡行公钥指数。
3.6. 使用指定的哈希算法（从哈希算法标识得到）对上一步的连接结果计算得到哈希结果。
3.7 .把上一步计算得到的哈希结果和恢复出的哈希结果相比较。如果它们不一样，那么静态数据认证失败。
3.8. 检验发卡行标识是否匹配主账号最左面的3-8个数字（允许发卡行标识可能在其后补“F”）。如果不一致，
那么静态数据认证失败。
3.9. 检验证书失效日期中指定月的最后日期是否等于或迟于今天的日期。如果证书失效日期在今天的日期之前，
那么证书已过期，静态数据认证失败。
3.10. 检验连接起来的RID、认证中心公钥索引、证书序列号是否有效。如果无效，那么静态数据认证失败。
3.11. 如果发卡行公钥算法标识无法识别，那么静态数据认证失败。
3.12. 如果以上所有的检验都通过，连接发卡行公钥的最左边字节和发卡行公钥的余项（如果有）以得到发卡行
公钥模，以继续下一步签名的静态应用数据的检验。
4. 签名的静态应用数据验证
4.1. 如果签名静态应用数据的长度不等于发卡行公钥模的长度，那么静态数据认证失败。
4.2. 为了获得在表5中指明的恢复数据，使用发卡行公钥和相应的算法应用到签名的静态应用数据上。如果恢复
数据的结尾不等于“BC”，那么静态数据认证失败。
表5 从签名的静态应用数据恢复数据的格式
|
字段名 |
长度 |
描述 |
格式 |
|
恢复数据头 |
1 |
十六进制，值为‘6A’ |
b |
|
签名数据格式 |
1 |
十六进制，值为‘03’ |
b |
|
哈希算法标识 |
1 |
标识用于在数字签名方案中产生哈希结果的哈希算法 |
b |
|
数据验证代码 |
2 |
由发卡行分配的代码 |
b |
|
填充字节 |
NI–26 |
填充字节由NI–26个值为‘BB’的字节组成 |
b |
|
哈希结果 |
20 |
需认证的静态应用数据的哈希值 |
b |
|
恢复数据结尾 |
1 |
十六进制，值为‘BC’ |
b |
4.3. 检查恢复数据头。如果它不是“6A”，那么静态数据认证失败。
4.4. 检查签名数据格式。如果它不是“03”，那么静态数据认证失败。
4.5. 将表7中的第2个到第5个数据元（即从签名数据格式直到填充字节）从左到右连接，再把JR/T 0025.5的9.3.1
条中指明的需认证的静态数据加在后面。如果静态数据认证标签列表存在，并且其包含非“82”的标签，那
么静态数据认证失败。
4.6. 把指定的哈希算法（从哈希算法标识得到）应用到上一步的连接结果从而得到哈希结果。
4.7. 把上一步计算得到的哈希结果和恢复出的哈希结果相比较。如果它们不一样，那么静态数据认证失败。
如果以上所有的步骤都成功，那么静态数据认证成功。在表7中的恢复得到的数据验证代码应被存放在标签
“9F45”中。
十 ---标准动态数据认证
1. 概述
DDA的目的是确认存放在IC卡中和由IC卡生成的关键数据以及从终端收到的数据的合法性。DDA除了执行同SDA类似的静态数据认证过程，确保IC卡中的发卡行数据在个人化以后没有被非法篡改，还能防止任何对这样的卡片进行伪造的可能性。
支持动态数据认证的IC卡必须包含下列数据元：
1.1. 认证中心公钥索引：该单字节数据元包含一个二进制数字，指明终端应使用其保存的相应的认证中心公钥
中的哪一个来验证IC卡；
1.2. 发卡行公钥证书：该变长数据元由相应的认证中心提供给发卡行；
1.3. IC卡公钥证书；
1.4. 发卡行公钥的余项；
1.5. 发卡行公钥指数；
1.6. IC卡公钥的余项；
1.7. IC卡公钥指数；
1.8. IC卡私钥。
支持动态数据认证的IC卡必须生成下列数据元：
---签名的动态应用数据：一个由IC卡使用同IC卡公钥证书所认证的IC卡公钥相对应的IC卡私钥生成的变长数据
元。它是一个数字签名。
---为了支持动态数据认证，每一台终端必须能够为每个注册的应用提供商标识存储5个认证中心公钥，而且必须
使同密钥相关的密钥信息能够同每一个密钥相关联（以使终端能在将来支持多种算法，允许从一个算法过渡
到另一个）。在给定RID和IC卡提供的认证中心公钥索引的情况下，终端必须能够定位这样的公钥以及和公钥
相关的信息。
动态数据认证过程中的主要步骤如下：
由终端恢复认证中心公钥；
由终端恢复发卡行公钥；
由终端恢复IC卡公钥。
DDA证书和公钥体系结构如图1所示：
可以说DDA详细的认证过程如下：
1. 认证中心和发卡行各自产生自己的公私钥对；
2. 发卡行将自己的公钥传给认证中心；
3. 认证中心用自己的私钥对发卡行的公钥进行签名;
4. 发卡行在将卡片分发给持卡人时，由卡片产生自己的公私钥对，并且卡片将自己的公钥传给发卡行
5. 发卡行用自己的私钥对卡片的公钥进行签名；
6. 发卡行将认证中心签名的发卡行公钥证书，以及用发卡行私钥签名的卡片公钥证书一起些人IC卡内
7. 发生交易时，终端通过READ RECORD命令获取认证中心公钥索引，发卡行公钥证书，IC卡公钥证书
8. 终端根据该认证中心公钥索引检索存储在终端的认证中心公钥，
9. 终端将认证中心公钥和RSA算法应用于发卡行公钥证书，恢复出发卡行公钥
10. 终端将发卡行公钥和RSA算法应用于IC卡公钥证书，恢复出IC卡公钥
11. 终端发送内部认证命令给卡片，内部认证命令的数据位4字节长度的不可预知数
12. 卡片返回签名的动态应用数据，其标签值为9F4B
13. 终端使用IC卡公钥对该数据进行恢复；
14. 终端使用SHA1算法验证动态签名的正确性
2. 密钥和证书
为了支持动态数据认证，一张IC卡必须拥有它自己的唯一的公私钥对，公私钥对由一个私有的签名密钥和相对应的公开的验证密钥组成。IC卡公钥必须存放在IC卡上的公钥证书中。
动态数据认证采用了一个三层的公钥证书方案。每一个IC卡公钥由它的发卡行认证，而认证中心认证发卡行公钥。这表明为了验证IC卡的签名，终端需要先通过验证两个证书来恢复和验证IC卡公钥，然后用这个公钥来验证IC卡的动态签名。分别将认证中心私钥SCA应用到表6中指定的数据以及将发卡行私钥SI应用到表7中指定的数据，以分别获得发卡行公钥证书和IC卡公钥证书。
认证中心的公钥有一个NCA个字节的公钥模。认证中心公钥指数必须等于3或216+1。
发卡行的公钥有一个为NI个字节（NI≤NCA）的发卡行公钥模。如果NI>（NCA-36），那么发卡行公钥模被
分成两部分，即一部分包含模中最高的NCA-36个字节（发卡行公钥中最左边的数字）；另一部分包含剩下的模
中最低的NI-（NCA-36）个字节（发卡行公钥余项）。发卡行公钥指数必须等于3或216+1。
IC卡的公钥有一个为NIC个字节（NIC≤NI≤NCA）的IC卡公钥模。如果NIC>（NI-42），那么IC卡公钥模被分成两部分，即一部分包含模中最高的NI-42个字节（IC卡公钥中最左边的数字）；另一部分包含剩下的模中最低的NIC-（NI-42）个字节（IC卡公钥余项）。IC卡公钥指数必须等于3或216+1。
如果卡片上的静态应用数据不是唯一的（比如卡片针对国际和国内交易使用不同的CVM），卡片必须支持多IC卡公钥证书，如果被签名的静态应用数据在卡片发出后可能会被修改，卡片必须支持IC卡公钥证书的更新。
为了完成动态数据认证，终端必须首先恢复和验证IC卡公钥（这一步叫做IC卡公钥认证）。IC卡公钥认证需要的所有信息在表8中详细说明，并存放在IC卡中。除了RID可以从AID中获得外，其它信息可以通过读取记录（READ RECORD）命令得到。如果缺少这些数据中的任意一项，那么动态数据认证失败。
表1 由认证中心签名的发卡行公钥数据（即哈希算法的输入）
|
字段名 |
长度 |
描述 |
格式 |
|
证书格式 |
1 |
十六进制，值为‘02’ |
b |
|
发卡行识别号 |
4 |
主账号最左面的3-8个数字。（在右边补上十六进制数‘F’） |
cn8 |
|
证书失效日期 |
2 |
MMYY，在此日期后，这张证书无效 |
n4 |
|
证书序列号 |
3 |
由认证中心分配给这张证书的唯一的二进制数 |
b |
|
哈希算法标识 |
1 |
标识用于在数字签名方案中产生哈希结果的哈希算法 |
b |
|
发卡行公钥算法标识 |
1 |
标识使用发卡行公钥的数字签名算法 |
b |
|
发卡行公钥长度 |
1 |
标识发卡行公钥模的字节长度 |
b |
|
发卡行公钥指数长度 |
1 |
标识发卡行公钥指数的字节长度 |
b |
|
发卡行公钥或发卡行公钥的最左边字节 |
NCA–36 |
如果NI≤NCA–36，这个字段包含了在右边补上了NCA–36–NI个值为‘BB’的字节的整个发卡行公钥。 如果NI>NCA-36，这个字段包含了发卡行公钥最高位的NCA–36个字节 |
b |
|
发卡行公钥的余项 |
0或 NI–NCA+36 |
这个字段只有在NI>NCA–36时才出现。它包含了发卡行公钥最低位的NI–NCA+36个字节 |
b |
|
发卡行公钥指数 |
1或3 |
发卡行公钥指数等于3或216+1 |
b |
表2 由发卡行签名的IC卡公钥数据（即哈希算法的输入）
|
字段名 |
长度 |
描述 |
格式 |
|
证书格式 |
1 |
十六进制，值为‘04’ |
b |
|
应用主账号 |
10 |
主账号（在右边补上十六进制数‘F’） |
cn20 |
|
证书失效日期 |
2 |
MMYY，在此日期后，这张证书无效 |
n4 |
|
证书序列号 |
3 |
由发卡行分配给这张证书的唯一的二进制数 |
b |
|
哈希算法标识 |
1 |
标识用于在数字签名方案中产生哈希结果的哈希算法 |
b |
|
IC卡公钥算法标识 |
1 |
标识使用在IC卡公钥上的数字签名算法 |
b |
|
IC卡公钥长度 |
1 |
标识IC卡公钥的模的字节长度 |
b |
|
IC卡公钥指数长度 |
1 |
标识IC卡公钥指数的字节长度 |
b |
|
IC卡公钥或IC卡公钥的最左边字节 |
NI–42 |
如果NIC≤NI–42，这个字段包含了在右边补上了NI–42–NIC个值为‘BB’的字节的整个IC卡公钥。 如果NIC>NI–42，这个字段包含了IC卡公钥最高位的NI–42个字节 |
b |
|
IC卡公钥的余项 |
0或 NIC–NI+42 |
这个字段只有在NIC>NI–42时才出现。它包含了IC卡公钥最低位的NIC–NI+42个字节 |
b |
|
IC卡公钥指数 |
1或3 |
IC卡公钥指数等于3或216+1 |
b |
|
需认证的静态数据 |
变长 |
在JR/T 0025.5的9.3.1条详细说明了需认证的静态数据 |
b |
认证过程的输入由被AFL标识的记录组成，其后跟有AIP[如果AIP被可选的静态数据认证标签列表（标签“9F4A”）标识。如果静态数据认证标签列表存在，它必须仅包含标识AIP用的标签“82”。
表3 动态认证中的公钥认证所需的数据对象
|
标签 |
长度 |
值 |
格式 |
|
- |
5 |
注册的应用提供商标识 |
b |
|
‘8F’ |
1 |
认证中心公钥索引 |
b |
|
‘90’ |
NCA |
发卡行公钥证书 |
b |
|
‘92’ |
NI–NCA+36 |
发卡行公钥的余项（如果存在） |
b |
|
‘9F32’ |
1或3 |
发卡行公钥指数 |
b |
|
‘9F46’ |
NI |
IC卡公钥证书 |
b |
|
‘9F48’ |
NIC–NI+42 |
IC卡公钥的余项（如果存在） |
b |
|
‘9F47’ |
1或3 |
IC卡公钥指数 |
b |
|
－ |
变长 |
在JR/T 0025.5的9.3.1条详细说明了需认证的静态数据 |
- |
2.1. 认证中心公钥的获取
终端读取认证中心公钥索引。使用这个索引和RID，终端能够确认并取得存放在终端的认证中心公钥的模，指数和与密钥相关的信息，以及将使用的相应算法。如果终端没有存储与这个索引及RID相关联的密钥，那么动态数据认证失败。
2.2. 发卡行公钥的获取
2.2.1. 如果发卡行公钥证书的长度不同于在前面的章条中获得的认证中心公钥模长度，那么动态数据认证失败。
2.2.2. 为了获得在表9中指明的恢复数据，使用认证中心公钥和相应的算法恢复发卡行公钥证书。如果恢复数据的
结尾不等于“BC”，那么动态数据认证失败。
表4 从发卡行公钥证书恢复数据的格式
|
字段名 |
长度 |
描述 |
格式 |
|
恢复数据头 |
1 |
十六进制，值为‘6A’ |
b |
|
证书格式 |
1 |
十六进制，值为‘02’ |
b |
|
发卡行标识 |
4 |
主账号最左面的3-8个数字（在右边补上十六进制数‘F’） |
cn8 |
|
证书失效日期 |
2 |
MMYY，在此日期后，这张证书无效 |
n4 |
|
证书序列号 |
3 |
由认证中心分配给这张证书的唯一的二进制数 |
b |
|
哈希算法标识 |
1 |
标识用于在数字签名方案中产生哈希结果的哈希算法 |
b |
|
发卡行公钥算法标识 |
1 |
标识使用在发卡行公钥上的数字签名算法 |
b |
|
发卡行公钥长度 |
1 |
标识发卡行公钥的模的字节长度 |
b |
|
发卡行公钥指数长度 |
1 |
标识发卡行公钥指数的字节长度 |
b |
|
发卡行公钥或发卡行公钥的最左边字节 |
NCA-36 |
如果NI≤NCA–36，这个字段包含了在右边补上了NCA–36–NI个值为‘BB’的字节的整个发卡行公钥。 如果NI>NCA-36，这个字段包含了发卡行公钥最高位的NCA–36个字节 |
b |
|
哈希结果 |
20 |
发卡行公钥以及相关信息的哈希值 |
b |
|
恢复数据结尾 |
1 |
十六进制，值为‘BC’ |
b |
2.2.3. 检查恢复数据头。如果它不是“6A”，那么动态数据认证失败。
2.2.4. 检查证书格式。如果它不是“02”，那么动态数据认证失败。
2.2.5. 将表9中的第2个到第10个数据元（即从证书格式直到发卡行公钥或发卡行公钥的最左边字节）从左到右连
接，再把发卡行公钥的余项加在后面（如果有），最后是发卡行公钥指数。
2.2.6. 使用指定的哈希算法（从哈希算法标识得到）对上一步的连接结果计算得到哈希结果。
2.2.7. 把上一步计算得到的哈希结果和恢复出的哈希结果相比较。如果它们不一样，那么动态数据认证失败。
2.2.8. 检验发卡行识别号是否匹配主账号最左面的3-8个数字（允许发卡行识别号可能在其后填充的“F”）。如
果不匹配，那么动态数据认证失败。
2.2.9. 确认证书失效日期中指定月的最后日期等于或迟于今天的日期。如果证书失效日期在今天的日期之前，那
么证书已过期，动态数据认证失败。
2.2.10. 检验连接起来的RID、认证中心公钥索引、证书序列号是否有效。如果无效，那么动态数据认证失败。
2.2.11. 如果发卡行公钥算法标识无法识别，那么动态数据认证失败。
2.2.12. 如果以上所有的检验都通过，连接发卡行公钥的最左边字节和发卡行公钥的余项（如果有）以得到发卡行
公钥模，从而继续下一步取得IC卡公钥。
2.3. IC卡公钥的获取
2.3.1. 如果IC卡公钥证书的长度不同于在前面的章条中获得的发卡行公钥模长度，那么动态数据认证失败。
2.3.2. 为了获得在表12中指明的恢复数据，使用发卡行公钥和相应的算法应用到IC卡公钥证书上。如果恢复数据
的结尾不等于“BC”，那么动态数据认证失败。
表5 从IC卡公钥证书恢复数据的格式
|
字段名 |
长度 |
描述 |
格式 |
|
恢复数据头 |
1 |
十六进制，值为‘6A’ |
b |
|
证书格式 |
1 |
十六进制，值为‘04’ |
b |
|
应用主账号 |
10 |
主账号（在右边补上十六进制数‘F’） |
cn20 |
|
证书失效日期 |
2 |
MMYY，在此日期后，这张证书无效 |
n4 |
|
证书序列号 |
3 |
由发卡行分配给这张证书的唯一的二进制数 |
b |
|
哈希算法标识 |
1 |
标识用于在数字签名方案中产生哈希结果的哈希算法 |
b |
|
IC卡公钥算法标识 |
1 |
标识使用在IC卡公钥上的数字签名算法 |
b |
|
IC卡公钥长度 |
1 |
标识IC卡公钥的模的字节长度 |
b |
|
IC卡公钥指数长度 |
1 |
标识IC卡公钥指数的字节长度 |
b |
|
IC卡公钥或IC卡公钥的最左边字节 |
NI-42 |
如果NIC≤NI–42，这个字段包含了在右边补上了NI–42–NIC个值为‘BB’的字节的整个IC卡公钥。 如果NIC>NI-42，这个字段包含了IC卡公钥最高位的NI–42个字节 |
b |
|
哈希结果 |
20 |
IC卡公钥以及相关信息的哈希值 |
b |
|
恢复数据结尾 |
1 |
十六进制，值为‘BC’ |
b |
2.3.3. 检查恢复数据头。如果它不是“6A”，那么动态数据认证失败。
2.3.4. 检查证书格式。如果它不是“04”，那么动态数据认证失败。
2.3.5. 将表10中的第2个到第10个数据元（即从证书格式直到IC卡公钥或IC卡公钥的最左边字节）从左到右连
接， 再把IC卡公钥的余项（如果有）和IC卡公钥指数加在后面，最后是JR/T 0025.5的9.3.1条指明的需认
证的静态数据。如果静态数据认证标签列表存在，并且其包含非“82”的标签，那么动态数据认证失败。
2.3.6. 把指定的哈希算法（从哈希算法标识得到）应用到上一步的连接结果从而得到哈希结果。
2.3.7. 把上一步计算得到的哈希结果和恢复出的哈希结果相比较。如果它们不一样，那么动态数据认证失败。
2.3.8. 比较恢复得到的主账号和从IC卡读出的应用主账号是否相同。如果不同，那么动态数据认证失败。
2.3.9. 检验证书失效日期中指定月的最后日期是否等于或迟于今天的日期。如果不是，那么动态数据认证失败。
2.3.10. 如果IC卡公钥算法标识无法识别，那么动态数据认证失败。
2.3.11. 如果以上所有的检验都通过，连接IC卡公钥的最左边字节和IC卡公钥的余项（如果有）以得到发卡行公钥
模，继续按下面章条的描述执行实际的动态数据认证。
2.5. 动态签名的生成
假定终端已成功地按上面讲述的过程取得了IC卡公钥。
动态签名的生成按以下的步骤进行：
2.5.1.终端发出内部认证（INTERNAL AUTHENTICATE）命令，命令中包含由DDOL指定的数据元
IC卡可能包含DDOL，但终端应有一个缺省的，由支付系统指定的DDOL，以防在IC卡没有提供DDOL的情况下使用。
DDOL必须包含由终端生成的不可预知数（标签“9F37”，4个字节的二进制数）。
如果下面的任一情况发生，动态数据认证失败。
——IC卡和终端都不含有DDOL；
——IC卡上的DDOL不包含不可预知数；
——IC卡上没有DDOL并且终端上缺省的DDOL不包含不可预知数。
2.5.2.IC卡使用IC卡私钥和相应的算法生成数字签名。这个结果叫做签名的动态应用数据。
表6 需签名的动态应用数据（即哈希算法的输入）
|
字段名 |
长度 |
描述 |
格式 |
|
签名的数据格式 |
1 |
十六进制，值为‘05’ |
b |
|
哈希算法标识 |
1 |
标识用于产生哈希结果的哈希算法 |
b |
|
IC卡动态数据长度 |
1 |
标识IC卡动态数据的字节长度LDD |
b |
|
IC卡动态数据 |
LDD |
由IC卡生成和/或存储在IC卡上的动态数据 |
- |
|
填充字节 |
NIC–LDD–25 |
（NIC-LDD–25）个值为‘BB’的填充字节 |
b |
|
终端动态数据 |
变长 |
由DDOL指定的数据元连接而成 |
- |
IC卡动态数据的字节长度LDD满足0≤LDD≤NIC-25。IC卡动态数据的最左边的3-9个字节应该由一个字节长的IC卡动态数字长度后面跟随的2-8个IC卡动态数字的值（标签“9F4C”，2-8个二进制字节）组成。IC卡动态数字是由一个由IC卡生成的，随时间而变的参数，（例如它可以是不可预知数或者IC卡每收到一个内部认证（INTERNAL AUTHENTICATE）命令就加一的计数器）。JR/T 0025建议使用ATC作为IC卡动态数字。
除了表8中指明的数据，动态数据认证所需的数据对象在表12中详细说明。
表7 生成和检验动态签名所需要的其它数据对象
|
标签 |
长度 |
值 |
格式 |
|
‘9F4B’ |
NIC |
签名的动态应用数据 |
b |
|
‘9F49’ |
变长 |
DDOL |
b |
2.6. 动态签名的验证
1.如果签名的动态应用数据的长度不同于IC卡公钥模的长度，那么动态数据认证失败。
2.为了获得在表13中指明的恢复数据，使用IC卡公钥和相应的算法应用到签名的动态应用数据上。如果恢复数据的结尾不等于“BC”，那么动态数据认证失败。
表8 从签名的动态应用数据恢复的数据格式
|
字段名 |
长度 |
描述 |
格式 |
|
恢复数据头 |
1 |
十六进制，值为‘6A’ |
b |
|
签名数据格式 |
1 |
十六进制，值为‘05’ |
b |
|
哈希算法标识 |
1 |
标识用于在数字签名方案中产生哈希结果的哈希算法1 |
b |
|
IC卡动态数据长度 |
1 |
标识IC卡动态数据的字节长度 |
b |
|
IC卡动态数据 |
LDD |
由IC卡生成和/或存储在IC卡上的动态数据 |
- |
|
填充字节 |
NIC- LDD–25 |
（NIC-LDD–25）个值为‘BB’的填充字节 |
b |
|
哈希结果 |
20 |
动态应用数据以及相关信息的哈希值 |
b |
|
恢复数据结尾 |
１ |
十六进制，值为‘BC’ |
b |
3.检查恢复数据头。如果它不是“6A”，那么动态数据认证失败。
4.检查签名数据格式。如果它不是“05”，那么动态数据认证失败。
5.将表15中的第2个到第6个数据元（即从签名数据格式直到填充字节）从左到右连接，再把DDOL中指定的数据元加在后面。
6.把指定的哈希算法（从哈希算法标识得到）应用到上一步的连接结果从而得到哈希结果。
7.把上一步计算得到的哈希结果和恢复出的哈希结果相比较。如果它们不一样，那么动态数据认证失败。
如果以上所有的步骤都成功，那么动态数据认证成功。在表13中恢复得到的IC卡动态数据中所包含的IC卡动态数字应被存放在标签“9F4C”中。
十一 ---复合动态数据认证
1. 概述
CDA由IC卡动态签名的生成和终端对签名的验证组成。由于直到CDA签名验证时才需要公钥，公钥的恢复可以在CDA签名前的任何时候。在公钥恢复阶段，发现的错误可能导致CDA失败（TVR“复合动态数据认证/应用密文生成失败”位设置为1）。这些错误包括但不限于公钥恢复的错误和无效格式的记录文件。
对于第一个GENERATE AC命令，和第二个GENERATE AC命令,在“不能联机”的情况下，终端请求的密文类型总是由GENERATE AC命令前的终端行为分析决定。如果在终端行为分析前发现存在以上错误，终端不应该在GENERATE AC命令中请求CDA。当GENERATE AC命令中执行了CDA的请求，在后续的处理中发现了以上错误，终端应脱机拒绝交易。
要进行复合动态数据认证，卡片和终端都必须满足如下条件：
1. IC卡和终端都支持复合动态数据认证／应用密文生成；
2. 产生的密文请求不是AAC，也就是说，终端行为分析的结果没有导致脱机拒绝；
3. 终的终端行为分析前，TVR“复合动态数据认证/应用密文生成失败”位没有设置为1。
除返回密文AAC外，当终端请求CDA时，IC卡总是返回CDA签名。
在第一个GENERATE AC命令情形下
1. 当请求ARQC时，终端可以请求CDA签名也可以不请求CDA签名。
2. 当请求ARQC，同时不请求CDA时，终端应该在发送GENERATE AC命令前，设置TVR“未进行脱机数据
认证”位为1。
在第二个GENERATE AC命令情形下
1. 终端应该在发送GENERATE AC命令前，设置TVR“未进行脱机数据认证”位为0。如果终端处理当前交易
为“不能联机”，那么终端应该在终端行为分析前设置TVR的位。
2. 当请求TC
2.1. 如果终端处理当前交易为“不能联机”（并且终端行为分析的结果是请求TC），则终端应该请求
TC/CDA。
2.2. 如果终端处理当前交易是联机授权的，则终端可以请求TC，同时请求CDA也可以不请求CDA。
3. 当请求AAC，终端应该请求AAC/不请求CDA。
2. 动态签名的生成
复合动态签名和应用密文生成按以下的步骤进行：
2.1.终端 生成应用密文（GENERATE AC）命令，并且命令中CDA请求位为1。
2.2.如果IC卡将以TC或ARQC作为响应，则IC卡执行如下步骤：
2.2.1. IC卡生成TC或ARQC；
2.2.2. IC卡应用由哈希算法标识指示的哈希算法对从左到右连接的如表1所示数据元进行运算：
2.3. 在第一个GENERATE AC命令情形下：
2.3.1. 由PDOL中指明，并按在其中出现的顺序，由终端在GPO命令中发送给IC卡的数据元的值；
2.3.2. 由CDOL1中指明，并按在其中出现的顺序，由终端在第一个GENERATE AC命令中发送给IC卡的数据元
的值；
2.3.3.IC卡在响应该GENERATE AC命令返回的数据元的标签、长度和值，根据它们返回的顺序且不包括签名动
态应用数据。
2.4. 在第二个GENERATE AC命令情形下：
2.4.1. 由PDOL中指明，并按在其中出现的顺序，由终端在GPO命令中发送给IC卡的数据元的值；
2.4.2. 由CDOL1中指明，并按在其中出现的顺序，由终端在第一个GENERATE AC命令中发送给IC卡的数据元
的值；
2.4.3. 由CDOL2中指明，并按在其中出现的顺序，由终端在第二个GENERATE AC命令中发送给IC卡的数据元
的值。
2.4.4. IC卡在响应该GENERATE AC命令返回的数据元的标签、长度和值，根据它们返回的顺序且不包括签名
动态应用数据。20字节的运算结果称作交易数据哈希值。
2.4.5. IC卡利用卡片中保存的IC卡私钥SIC对表1中的数据数字签名方案和相应算法，将结果称作签名的动态应
用数据。
表1 需签名的动态应用数据（即哈希算法的输入）
|
字段名 |
长度 |
描述 |
格式 |
|
签名的数据格式 |
1 |
十六进制，值为‘05’ |
b |
|
哈希算法标识 |
1 |
标识用于产生交易数据哈希值和数字签名方案中哈希结果的哈希算法 |
b |
|
IC卡动态数据长度 |
1 |
标识IC卡动态数据的字节长度LDD |
b |
|
IC卡动态数据 |
LDD |
由IC卡生成和/或存储在IC卡上的动态数据 |
- |
|
填充字节 |
NIC–LDD–25 |
（NIC-LDD–25）个值为‘BB’的填充字节 |
b |
|
不可预知数 |
4 |
由终端生成的不可预知数 |
b |
IC卡动态数据的字节长度LDD满足0≤LDD≤NIC-25。IC卡动态数据的最左边的32-38个字节由表2中指明的数据连接而成。
表2 IC卡动态数据的内容
|
长度 |
值 |
格式 |
|
1 |
IC卡动态数字长度 |
b |
|
2-8 |
IC卡动态数字 |
b |
|
1 |
密文信息数据 |
b |
|
8 |
TC或ARQC |
b |
|
20 |
交易数据哈希值 |
b |
IC卡动态数字是一个由IC卡生成的，随时间而变的参数。（例如它可以是不可预知数或者IC卡在交易时每收到一个生成应用密文（GENERATE AC）命令就加1的计数器）。JR/T 0025建议使用ATC作为IC卡动态数字。
IC卡对生成应用密文（GENERATE AC）命令的响应必须按照带有标签“77”的结构数据对象编码，且必须包含表3中指明的三个必须数据对象（在响应中按TLV编码），或可选包含发卡行应用数据。
表3 在CDA中GENERATE AC命令返回的数据对象
|
标签 |
长度 |
值 |
存在 |
|
‘9F27’ |
1 |
密文信息数据 |
必须 |
|
‘9F36’ |
2 |
应用交易计数器 |
必须 |
|
‘9F4B’ |
NIC |
签名的动态应用数据 |
必须 |
|
‘9F10’ |
变长，最长32 |
发卡行应用数据 |
可选 |
2.5. 如果IC卡以AAC作为响应，那么IC卡的响应分两种格式，
2.5.1. 格式1：
响应报文中的数据对象是一个标签为‘80’的基本数据对象。数据域由表B.8所示的数据对象连接而成，各数据对象之间没有分隔符（标签和长度）。
表 B.8 GENERATE AC响应报文数据域格式1
|
值 |
存在性 |
|
密文信息数据 |
必备 |
|
应用交易计数器（ATC） |
必备 |
|
应用密文（AC） |
必备 |
|
发卡行应用数据 |
可选 |
2.5.2. 格式2：
响应报文的数据对象是一个标签为‘77’的结构数据对象。数据域中可以包含多个BER-TLV编码对象，但是应包括密文信息数据、应用交易序号和由IC卡计算出的密文（可以是应用密文或专有密文）。对于响应报文中可能包含的专有数据对象的应用和解释，不在JR/T 0025的范围之内。
如果响应报文含有动态数据签名，对CDA的响应，则采用格式2。
如果卡片不执行CDA，命令的响应报文数据域中的数据对象按照格式1编码
如果卡片执行CDA，命令的响应报文数据域中的数据对象按照格式2编码。
以上两种格式中，在生成应用密文命令的响应报文中包括的密文数据按照表B.9的方式编码。
表 B.9 密文信息数据编码
|
b8 |
b7 |
b6 |
b5 |
b4 |
b3 |
b2 |
b1 |
意义 |
|
0 |
0 |
AAC |
||||||
|
0 |
1 |
TC |
||||||
|
1 |
0 |
ARQC |
||||||
|
1 |
1 |
RFU |
||||||
|
x |
x |
支付系统密文 |
||||||
|
0 |
未请求通知 |
|||||||
|
1 |
请求通知 |
|||||||
|
x |
x |
x |
原因/通知/授权参考码 |
|||||
|
0 |
0 |
0 |
无信息 |
|||||
|
0 |
0 |
1 |
不允许服务 |
|||||
|
0 |
1 |
0 |
PIN重试超限 |
|||||
|
0 |
1 |
1 |
发卡行鉴定失败 |
|||||
|
x |
x |
x |
其它值保留 |
2.6. GENERATE AC命令响应报文数据域格式中指明的格式1或格式２编码，且必须包含表4中指明的三个必须数据对象，可选包含发卡行应用数据。
表4 生成AAC时GENERATE AC命令返回的数据对象
|
标签 |
长度 |
值 |
存在 |
|
‘9F27’ |
1 |
密文信息数据 |
必须 |
|
‘9F36’ |
2 |
应用交易计数器 |
必须 |
|
‘9F26’ |
8 |
应用认证密文 |
必须 |
|
‘9F10’ |
变长，最长32 |
发卡行应用数据 |
可选 |
除了明文的密文信息数据，在签名动态应用数据的验证过程中，也能够恢复出密文信息数据，如果该数据存在，则必须使用这个恢复出来的密文信息数据来判断返回的密文类型，否则，使用明文的密文信息数据。
如果存在发卡行应用数据（标签“9F10”），应按照表5所示的格式编码。
表5 发卡行应用数据
|
标签 |
长度 |
值 |
存在 |
|
1 |
长度指示符 |
必须 |
|
|
1 |
分散密钥索引 |
必须 |
|
|
1 |
密文版本号 |
必须 |
|
|
4 |
卡片验证结果（CVR） |
必须 |
|
|
1 |
算法标识 |
必须 |
|
|
变长 |
发卡行自定义数据 |
可选 |
分散密钥索引指示IC卡产生应用密文所使用的是哪个密钥，密文版本号指示了应用密文的计算方式，
3.动态签名的验证
如果IC卡以AAC响应，那么终端应该拒绝交易。
如果IC卡以TC或ARQC响应，那么终端从响应中取回表4中前面的四个数据对象并且执行以下步骤。
3.1. 如果签名的动态应用数据的长度不同于IC卡公钥模的长度，那么复合动态数据认证／应用密文生成失败；
3.2. 为了获得在表6指明的恢复数据，将IC卡公钥RSA算法应用到签名的动态应用数据上。如果恢复数据的结尾不
等于“BC”，那么复合动态数据认证／应用密文生成失败。
表6 从签名动态应用数据恢复的数据的格式
|
字段名 |
长度 |
描述 |
格式 |
|
恢复数据头 |
1 |
十六进制，值为‘6A’ |
b |
|
签名数据格式 |
1 |
十六进制，值为‘05’ |
b |
|
哈希算法标识 |
1 |
标识用于产生交易数据哈希值和数字签名方案中哈希结果的哈希算法 |
b |
|
IC卡动态数据长度 |
1 |
标识IC卡动态数据的字节长度 |
b |
|
IC卡动态数据 |
LDD |
由IC卡生成和/或存储在IC卡上的动态数据 |
- |
|
填充字节 |
NIC- LDD–25 |
（NIC-LDD–25）个值为‘BB’的填充字节 |
b |
|
哈希结果 |
20 |
动态应用数据以及相关信息的哈希值 |
b |
|
恢复数据结尾 |
1 |
十六进制，值为‘BC’ |
b |
3.3. 检查恢复数据头。如果它不是“6A”，那么复合动态数据认证／应用密文生成失败。
3.4. 检查签名数据格式。如果它不是“05”，那么复合动态数据认证／应用密文生成失败。
3.5. 从IC卡动态数据中取得表6中指明的数据。
3.6. 检查从IC卡动态数据中取得的密文信息数据是否等于从产生应用密文（GENERATE AC）命令的响应中获得
的密文信息数据。如果不等，那么复合动态数据认证／应用密文生成失败。
3.7. 将表21中的第2个到第6个数据元（即从签名数据格式直到填充字节）从左到右连接，再把不可预知数加在
后面。
3.8. 把指定的哈希算法（从哈希算法标识得到）应用到上一步的连接结果从而得到哈希结果。
3.9. 把上一步计算得到的哈希结果和恢复出的哈希结果相比较。如果它们不一样，那么复合动态数据认证／应用
密文生成失败。
3.10. 将下列数据元从左到右连接：
3.10.1. 在第一个GENERATE AC命令情形下：
由PDOL中指明，并按在其中出现的顺序，由终端在GPO命令中发送给IC卡的数据元的值。
由CDOL1中指明，并按在其中出现的顺序，由终端在第一个GENERATE AC命令中发送给IC卡的数据元的值。
IC卡在响应该GENERATE AC命令返回的数据元的标签、长度和值，根据它们返回的顺序且不包括签名动态应用数据。
第一个GAC命令发送的数据源如下：
|
数据元 |
来自终端的数据 |
在交易证书（TC）哈希中的顺序 |
卡片内数据 |
|
授权金额 |
ü |
ü |
|
|
其它金额 |
ü |
ü |
|
|
终端国家代码 |
ü |
ü |
|
|
终端验证结果 |
ü |
ü |
|
|
交易货币代码 |
ü |
ü |
|
|
交易日期 |
ü |
ü |
|
|
交易类型 |
ü |
ü |
|
|
不可预知数 |
ü |
ü |
|
|
应用交互特征（AIP） |
ü |
||
|
应用交易计数器（ATC） |
ü |
||
|
卡片验证结果（CVR） |
ü |
3.10.2. 在第二个GENERATE AC命令情形下：
由PDOL中指明，并按在其中出现的顺序，由终端在GPO命令中发送给IC卡的数据元的值。
由CDOL1中指明，并按在其中出现的顺序，由终端在第一个GENERATE AC命令中发送给IC卡的数据元的值。
由CDOL2中指明，并按在其中出现的顺序，由终端在第二个GENERATE AC命令中发送给IC卡的数据元的值。
IC卡在响应该GENERATE AC命令返回的数据元的标签、长度和值，根据它们返回的顺序且不包括签名动态应用数据。
GAC2数据域中的数据时按照CDOL2列表的顺序添加数据的。
3.11. 把指定的哈希算法（从哈希算法标识得到）应用到上一步的连接结果从而得到交易数据哈希值。
3.12. 把上一步计算得到的交易数据哈希值和步骤5中从IC卡动态数据中恢复出的交易数据哈希值相比较。如果它们不一样，那么复合动态数据认证／应用密文生成（CDA）失败。
如果以上所有的步骤都成功，那么复合动态数据认证／应用密文生成（CDA）成功。在表17中恢复得到的IC卡动态数据中所包含的IC卡动态数字和ARQC或TC应被相应地存放在标签“9F4C”和“9F26”中。
十二 ---外部认证
外部认证
在GAC命令时，当返回ARQC时都会返回8个字节的密文数据，这8个字节的密文数据计算过程如下:
第一． 三种秘钥
在卡片内至少得存如下三种秘钥，其中应用密文主密钥简称ENC,安全报文认证秘钥简称MAC,安全报文加密秘钥简称DEK,其用途见下表1所示：
表1.秘钥及用途
|
密钥类型 |
用途 |
长度 |
|
应用密文主密钥 |
产生IC卡应用密文子密钥，用于应用密文的产生和验证 |
16字节 |
|
安全报文认证（MAC）密钥 |
产生IC卡MAC子密钥，用于安全报文鉴别码的产生和验证 |
16字节 |
|
安全报文加密密钥 |
产生IC卡加密子密钥，用于加密解密安全报文 |
16字节 |
发卡行主密钥可以分散出IC卡子密钥，在交易过程中从子密钥派生出相应的过程密钥，其中MAC密钥用来产生报文的鉴别码（MAC），用于安全报文命令，如数据安全更新、发卡行脚本等，加密密钥用来加密安全报文，AC密钥用来对TC、ARQC、AAC、ARPC进行加密计算。
第二． 子秘钥的产生过程
子秘钥的产生是用发卡行主密钥IMK对应用主账号（PAN）这一方式以主账号（PAN）和主账号序列号（如果主账号序列号不存在，则用一个字节“00”代替）的最右16个数字作为输入数据，以及16字节的发卡行主密钥IMK作为输入，生成16字节的IC卡子密钥MK作为输出：
2.1. 如果主账号和主账号序列号X的长度小于16个数字，X右对齐，在最左端填充十六进制的“0”以获得8字
节的Y。如果X的长度至少有16个数字，那么Y由X的最右边的16个数字组成。
2.2. 计算2个8字节的数字
需要特别注意的是，这些DES秘钥必须确保经过了奇校验。
第三． 过程秘钥的产生
分散因子是这样产生的，获取当前交易的ATC,这个ATC一般在GAC1命令后返回，在其昨天补6个字节的0X00作为分散因子的左半部分，将ATC与0XFFFF进行异或后在前边补足6个字节的0x00凑足8个字节作为分散因子的右半部分。采用子秘钥对这16个字节的分散因子进行加密得出过程秘钥。
第四． 密文的计算与验证
密文的计算需要如下数据:
|
值 |
来源 |
|
授权金额（数字） |
终端 |
|
其它金额（数字） |
终端 |
|
终端国家代码 |
终端 |
|
终端验证结果 |
终端 |
|
交易货币代码 |
终端 |
|
交易日期 |
终端 |
|
交易类型 |
终端 |
|
不可预知数 |
终端 |
|
应用交互特征 |
IC卡 |
|
应用交易计数器 |
IC卡 |
使用过程秘钥对以上数据进行CBC 三重MAC计算即可得出8个字节的密文（其实是MAC值）。将计算出的密文同卡片在GAC1返回的密文进行对比，如果相同则进入下一步，否则返回
第五．联机密文
在联机过程中，发卡行会返回两个字节的授权响应码，在这两个授权响应码的后边补足6个字节的0X00凑足8个字节，将这8个字节与GAC1返回的应用密文进行一对一的亦或运算。
使用过程秘钥对亦或结果进行加密得出ARPC
第五． 发送外部认证命令
外部认证命令的格式为 00 82 00 00 0a 其中10个字节的数据域为8个字节的ARPC和两个字节的授权响应码，这里的授权响应码不是终端在终端行为分析中得到的授权响应码而是在联机过程中，发卡行发送的授权响应码。如果卡片返回0x9000则表示外部认证通过。
十三 ---安全报文MAC计算
安全报文MAC计算
在进行电子现金交易或者进行圈存时时，当交易成功后，需要对卡上的电子现金余额进行更改，就要用到安全报文MAC计算，MAC计算的过程如下：
第一． 三种秘钥
在卡片内至少得存如下三种秘钥，其中应用密文主密钥简称ENC,安全报文认证秘钥简称MAC,安全报文加密秘钥简称DEK,其用途见下表1所示：
表1.秘钥及用途
|
密钥类型 |
用途 |
长度 |
|
应用密文主密钥 |
产生IC卡应用密文子密钥，用于应用密文的产生和验证 |
16字节 |
|
安全报文认证（MAC）密钥 |
产生IC卡MAC子密钥，用于安全报文鉴别码的产生和验证 |
16字节 |
|
安全报文加密密钥 |
产生IC卡加密子密钥，用于加密解密安全报文 |
16字节 |
发卡行主密钥可以分散出IC卡子密钥，在交易过程中从子密钥派生出相应的过程密钥，其中MAC密钥用来产生报文的鉴别码（MAC），用于安全报文命令，如数据安全更新、发卡行脚本等，加密密钥用来加密安全报文，AC密钥用来对TC、ARQC、AAC、ARPC进行加密计算。
第二． 子秘钥的产生过程
子秘钥的产生是用发卡行主密钥IMK对应用主账号（PAN）这一方式以主账号（PAN）和主账号序列号（如果主账号序列号不存在，则用一个字节“00”代替）的最右16个数字作为输入数据，以及16字节的发卡行主密钥IMK作为输入，生成16字节的IC卡子密钥MK作为输出：
2.1. 如果主账号和主账号序列号X的长度小于16个数字，X右对齐，在最左端填充十六进制的“0”以获得8字节的Y。如果X的长度至少有16个数字，那么Y由X的最右边的16个数字组成。
2.2. 计算2个8字节的数字
需要特别注意的是，这些DES秘钥必须确保经过了奇校验。
第三． 过程秘钥的产生
分散因子是这样产生的，获取当前交易的ATC,这个ATC一般在GAC1命令后返回，在其昨天补6个字节的0X00作为分散因子的左半部分，将ATC与0XFFFF进行异或后在前边补足6个字节的0x00凑足8个字节作为分散因子的右半部分。采用子秘钥（MAC秘钥）对这16个字节的分散因子进行加密得出过程秘钥。
第四． MAC的计算
MAC的计算需要如下数据
4.1. PUT DATA命令头 04 DA 9F 79 0A
4.2. 两个字节的ATC
4.3. GAC1命令返回的8个字节的密文数据
4.4. 6个字节的电子现金余额重置值
采用过程秘钥对这些数据进行三重CBC MAC计算的出8个字节的MAC值，取昨天的4个字节
在发送PUT DATA命令时采用如下格式:
04 DA 9F 79 0A + 6个字节的电子现金重置值 + 4字节MAC发送给卡片