EMV笔记(总体流程)

 

 

 

 

 

 

 
概述:
根据第四部分,《中国金融集成电路(IC)卡规范 第4部分:借记贷记应用规范》交易流程大致如下:
1:读取PSE支付环境,返回SFI;
2:读取记录(应用AID),建立AID列表(M):终端检测终端与卡片都支持的应用,通过SFI一个个读取记录,进行目录选择,获取卡片支持的应用列表(目录选择法)。终端也可以对列表中包含的每个应用对卡片发送SELECT命令,最终形成候选列表(AID列表选择法) ;(部分匹配还是完全匹配,根据AID参数里面的df01应用选择指示符(ASI))
3: 选择应用,获取PDOL(M):应用选择之后,终端获取卡片PDOL数据(卡片提供给终端卡片需要的tag,终端根据这些tag填充对应的value然后再发给卡片),终端读取卡片该应用的应用数据决定要执行的处理;
4:获取一些读记录的时候没获取到的卡片的静态数据;
5:发起GPO指令,GPO命令主要的功能时告诉卡片,交易的金额,是否支持电子现金,以及终端的交易属性等参数,终端根据第3步得到PDOL,发起GPO指令返回应用交互特征(AIP)+应用文件定位器(AFL);
6:根据AFL发起读取记录
7:内部认证(脱机数据认证)SDA或DDA或CDA。校验卡片真实性。[如果DDA,INTERNAL ANTHENTICATE]( 内部认证,脱机数据认证是终端采用公钥技术来验证卡片数据的方法 ,终端通过公钥验证卡片合法性)
8:持卡人验证(M):验证持卡人身份,通过CVM lists,包括:脱机明文PIN,联机PIN,签名,CVM失败,无需CVM,签名加联机PIN,身份证件验证。[GET DATA & VERIFY]
9: 终端风险管理(M):终端通过数据进行最低限额检查,频度检查,新卡检查,异常文件检查,商户强制交易联机,随机选择联机等完成风险管理。参考:https://blog.csdn.net/chy555chy/article/details/51878285
http://www.cppblog.com/MichaelLiu/articles/10256.html
10:终端行为分析(M):根据脱机数据认证,处理限制,持卡人验证,终端风险管理,的结果以及终端和卡片中设置的风险管理参数决定如何继续交易:脱机批准、脱机拒绝、联机授权。然后终端向卡片请求应用密文,TC为批准,ARQC为联机,AAC为拒绝。[GAC](终端行为分析之后,发送GAC指令)
 11:卡片行为分析(M):卡片行为分析结束后,卡片返回一个应用密文给终端。 AAC表示交易拒绝, ARQC表示请求联机授权,TC表示脱机交易接受。如果卡片和终端都支持CDA,卡片返回的ARQC或TC要作为签名的动态应用数据的一部分(第一次授权)
12.  联机处理(O):终端将卡片产生的ARQC密文发送至发卡行进行联机授权。报文包括ARQC密文和生成密文的数据以及脱机处理结果的指示器。发卡行的响应信息包括授权响应密文ARPC,也可以包括发卡行脚本。如果授权响应包括ARPC而且支持发卡行认证,卡片通过确认ARPC而执行发卡行认证校验响应是否来自真实的发卡行。(发卡行验证卡片的合法性)
13:发卡行的响应可以包括给卡片的二次发卡更新和一个发卡行生成的密文。卡片验证密文确保响应来自一个有效的发卡行。此验证叫发卡行认证,
卡片验证发卡行是否是一个有效的发卡行. 命令是External Authentication, 叫外部认证. 参数是上一步联机处理响应的ARPC和授权响应码. 卡片收到命令后,会用自己的密钥,对ARQC和授权响应码生成ARPC,然后与终端传来的ARPC比较,两都相同,就认为此ARPC是来自一个有效的发卡行后台(卡片认证发卡行,外部认证)
14:  发卡行脚本处理(O):终端直接发送脚本到IC卡,影响卡片后续功能。
脚本通知上送:一般是联机交易前,冲正交易之后上送
终端对卡片发起GC1,卡片返回给终端ARQC,代表允许联机,返回AAC,代表拒绝
终端对卡片发起GC2,卡片返回给终端TC,代表接收交易,返回AAC,代表拒绝(二次授权)
 
15  交易结束(O):除非交易前几个步骤因异常而终止,否则必须有此步骤。卡片和终端执行此处理完成交易,卡片生成TC或AAC(二次授权)。如果终端在授权信息后传送清算信息,则TC应包括在该清算信息里面,对于发卡行批准而卡片拒绝的交易,终端需发起冲正。

 认证总结:
卡片认证发卡行:GAC返回ARQC给终端,终端发给发卡行,发卡行返回ARPC,由终端发给卡片,卡片自己计算生成ARPC,比对;(外部认证)
发卡行认证卡片:金融IC卡在申请联机交易时,发卡行会进行验证卡片的合法性,发卡行通过GAC得到卡片返回的ARQC,与发卡行自身产生的ARQC进行比较,如果一致,则说明是由发卡行发行的合法卡片,同时对ARQC及认证码进行3DES计算,返回ARPC;
 
终端认证卡片:脱机数据认证,内部认证,通过从发卡行下载的公钥来认证卡片的合法性;(内部认证)
卡片认证终端: 
 
 
具体流程:
 
1->读取PSE支付环境:
 
●  PSE为接触支付环境,非接为PPSE,PSE为一个DDF(目录里面还有目录);
●  PBOC3.0开始,PSE里面不再含有DDF,只有ADF(里面只有文件),PBOC2.0在读取记录的时候有可能读取到的是DDF,这个时候需要通过返回的SFI再去选择    DDF后再去读记录,循环执行,直到读取到ADF;
●  PSE里面有1个或多个SFI标记(tag 88)的文件,每个文件里面有一个或者多个记录,把每个记录读出来,直到返回6A-83,每个记录对应一个aid;
●  进入PSE的方法为目录选择法,还有一个AID列表选择法,终端把自己所有的AID一个个发到卡片,看是否匹配,目录选择法失败的时候才会进行列表选择法
C-00 a4 04 00 0e 00         (00 a4:选择命令      P1:04:通过名称选择    P2:00    0e:数据长度14)
Len: 14
31 50 41 59 2e 53 59 53 2e 44 44 46 30 31 (1PAY.SYS.DDF01)
R-SW: 90-00
Len: 34                                                    (表B.26定义了成功选择PSE后回送的FCI)
6f 20 84 0e 31 50 41 59 2e 53 59 53 2e 44 44 46                 (6F:FCI:模板文件控制信息模板        84:DF名字:1PAY.SYS.DDF01)
30 31 a5 0e 5f 2d 04 7a 68 65 6e 9f 11 01 01 88                 (A5   (FCI数据专用模板)    14(长度))
01 01
                         88   (目录基本文件的SFI)  01(长度) 01   (短文件标识符(Short File Identifier))
                         5F2D (语言选择)           02         7A68
                         9F11 (发卡行代码表索引)   01         01
                         BF0C (发卡行自定义数据FCI)05         9F4D020B0A

 

EMV2000规范:

 

 

 

 

●  (PBOC规范5 )B.13.2 命令报文:

 

 

 

 

 
2->读取记录号01(READ RECORD):
 
如果在执行读记录( READ RECORD)命令查找第1个记录时,卡回送状态字“ 6A83,则表示目录入口为空,使用AID列表选择法。
P1:记录号    P2:选择支付环境返回的SFI;
tag 87:若应用优先级指示器的b8=1,持卡人选择应用;若应用优先级指示器的b8=0,终端选择应用;)
 
C-00 b2 01 0c 00 00                                                   (00 b2:读记录     P1:记录号    P2:应用控制参数(0C:读p1指定记录)     GETDATA 获取数据)
R-SW: 90-00
Len: 45                                                                        (70:标签, 2b:数据域长度, 61:标识符, 29:目录入口1长度)
70 2b 61 29 4f 08 a0 00 00 03 33 01 01 01 50 0a      (4F:ADF名称:aid)50 42 4f 43 20 44 65 62 69 74 87 01 01 9f 12 0d       (50:应用标签(PBOC Debit),   87:应用优先权标识符: )
                        (多个候选应用列表的时候,终端ICS支持持卡人确认的话就让持卡人确认,不支持的话就按优先级,,不看每个应用的b8
只有一个候选应用时要看每个应用具体的b8,如果b8为1,需要让持卡人确认的,正常情况下多应用都是需要列出来,然后应用优先级高的排前面,正常情况终端都支持持卡人确认功能)
49 43 42 43 20 50 62 6f 63 43 61 72 64                       (9f 12:应用优先名称:ICBC PbocCard )    

 

 
 
    读取记录号02
C-00 b2 02 0c 00 00
R-SW: 6a-83
SltDDF PrsSFIofDDF Ret: 01
PSE SLT end:00
EA_EMV_AppSelection Return
Len: 65
01 a0 00 00 03 33 01 01 01 00 00 00 00 00 00 00
00 08 50 42 4f 43 20 44 65 62 69 74 00 00 00 00
00 00 0a 49 43 42 43 20 50 62 6f 63 43 61 72 64
00 00 00 0d 01 01 7a 68 65 6e 00 00 00 00 04 01
01

 

 

●  (PBOC规范5 )B.12.2 命令报文:

 

 

 

 

 

 

 

 

 

3->最终选择应用:
应用选择完成后,终端获取到了PDOL数据9f 38(这个不是必须的,卡片也可以不给终端提供PDOL,如果终端没有获取到PDOL,则GPO数据域直接传递8300)。
这里包含了4个tag,这四个tag的数据就是作为GPO指令数据域传送给卡片, 0c:长度,9f 7a:电子现金指示器  9f 02:授权金额  5f 2a:交易货币代码   df69
 选择pse和选择ADF返回的报文不同,参考B2.6、2.7,FCI模板不同
C-00 a4 04 00 08 00(选择具体应用a0 00 00 03 33 01 01 01)
Len: 8
a0 00 00 03 33 01 01 01
R-SW: 90-00
Len: 94
6f 5c 84 08 a0 00 00 03 33 01 01 01 a5 50 50 0a
50 42 4f 43 20 44 65 62 69 74 87 01 01 5f 2d 04
7a 68 65 6e 9f 11 01 01 9f 12 0d 49 43 42 43 20
50 62 6f 63 43 61 72 64 9f 38 0c 9f 7a 01 9f 02
06 5f 2a 02 df 69 01 bf 0c 14 d1 02 31 32 c2 04
49 43 42 43 9f 4d 02 0b 0a df 4d 02 0c 0a

 

 

 

 

 

 

4->获取数据(GET DATA):
C-80 ca 9f 51 00 00          (P1\P2:要访问数据的标签)
R-SW: 90-00
Len: 5
9f 51 02 01 56
C-80 ca df 71 00 00
R-SW: 6a-88

 

 

 

 

 

5->GPO(获取处理选项(Get Processing Options):C-80 a8 00 00 0c 00) 指令
返回格式:80 + 长度 + 应用交互特征(AIP)+应用文件定位器(AFL);
AIP(7C 00):bit8:RFU;   bit7:1=支持SDA;  bit6:1=支持DDA; bit5:1=支持持卡人认证 bit4:执行终端风险管理
         bit3:支持发卡行认证;bit2:RFU;bit1:1=支持CDA; 字节2:RF:;
       这个列表说明了卡片的支持能力
      同样终端如果也支持响应的功能则在交易的过程中将选择响应的功能,需要注意的是对于认证的优先级PBOC是做了如下的规定CDA>DDA>SDA,也就是说如果双方都支持  CDA,  那么终端优先进行CDA认证,终端必须选择双方共同支持的认证方式中优先级最高的,请注意两个关键词,双方共同支持与优先级最高
AFL(应用文件定位器),每个AFL包括4个字节,AFL的定义如下: 包含终端将要读取用来交易处理的卡片数据文件的SFI和记录范围
       终端将根据AFL的提示读取所有要求的记录,这里请注意第四个字节,这些数据是要进行脱机数据认证的,所以终端必须保存起来
       字节1:bit8-bit4:SFI(短文件标识符)  bit3-bit1:000
       字节2:文件中要读的第1个记录的记录号(不能为0)
       字节3:文件中要读的最后一个记录的记录号(大于或等于字节2)
       字节4:从字节2的记录号开始,用于静态数据记录的个数(从0开始,不大于(字节3)-(字节2)+1)
AIP列出了交易在处理过程中执行的功能;AFL列出交易需要读出的数据存放的短文件标识符、记录号、记录个数以及脱机数据认证需要的静态签名数据的存放位置。 
GPO命令主要的功能时告诉卡片,交易的金额,是否支持电子现金,以及终端的交易属性等参数,在选择应用时,卡片会返回一个PDOL标签值,其标签为9F38,终端应该保存这个列表,GPO命令的数据域就是依据PDOL列表发送的,数据发送的顺序是按照标签在PDOL中的顺序排列的;      
GPO命令的响应与你所选择的用用有关,例如你选择了qPBOC那么返回的会是以77为首的标签,以77为首的标签也会返回ATC与AFL但是数据是以TLV格式返回的;
   PBOC返回的是80;    
 
 
Len: 12
83 0a 00 00 00 00 00 00 01 01 56 00                              (83+PDOL的部分,直接把Tag 9F38之后的数据部分填充进来即可,如果没有PDOL那么就是83+00 )
R-SW: 90-00
Len: 20
80 12 7c 00(AIP) 08 01 01 00    10 01 04 00      18 01 01 01   01 20 01 00(AFL)
返回格式:80 + 长度 + 应用交互特征(AIP)+应用文件定位器(AFL)

 


 
假设由上一步从卡片中得到的数据的AFL为: 08 01 01 00     10 01 02 01
1.首先分析AFL:
由上面的数据可以知道有两个AFL entry,分别是 08 01 01 00 和 10 01 02 01
第一条: 08 01 01 00
第一个字节08:可以知道SFI 为01; 第二个字节为01,表示开始读记录号为01; 第三个字节表示最后读的记录号为01,所以SFI 为01时,只读一条记录,记录号为 01; 第四个字节为 00:表示SFI为01时,没有需要参与到脱机数据认证的数据。
第二条: 10 01 02 01
 
第一个字节10:SFI为02; 第二个字节为01,第三个字节为02,可知SFI为02时,需要读两条记录 01 和02; 第四个字节为01:表示参与到脱机数据认证的有1条记录,就是SFI为02,记录号为01。
 
 

 

 

 
 
 
6->根据GPO返回的AFL发送读记录命令
 
C-00 b2 01 0c 00 00                                                       (08 01 01 00根据AFL发送读记录命令, 发送第1条命令:SFI为01,记录号为01,01:p1,记录号   0C:SFI)
R-SW: 90-00
Len: 102
70 64 57 13 62 22 03 10 01 00 76 15 39 1d 27 11          (57:二磁道等效数据)
22 03 00 99 91 71 4f 5f 20 14 20 20 20 20 20 20            (5f 20:持卡人姓名)
20 20 20 20 20 20 20 20 20 20 20 20 20 20 9f 1f            (9f 1f:磁道一自定义数据)
18 30 30 37 31 34 30 30 30 30 30 30 30 30 30 30
33 30 30 30 30 30 30 30 30 5f 34 01 01 9f 61 12             (5f 34:应用主帐号序列号)
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 9f 62 01 20                                                               (9f 62 :证件类型)
C
-00 b2 01 14 00 00 (10 01 04 00) R-SW: 90-00 Len: 254 70 81 fb 90 81 f8 21 e4 40 c5 04 29 cd 94 7d 33 (90:发卡行公钥证书:用于脱机数据认证) 13 2c ba 1b 9b 10 57 7c 1e 15 e1 11 0c eb 79 7a ba f8 c0 5b 39 64 77 57 33 81 0c af 81 2c fe 8b b5 cd 6c 56 6b 79 28 4a ca be 9a 1b 3f 2e 27 b2 fb 43 2f a7 c7 b7 ba fa d3 45 96 62 7e b1 a9 82 34 72 af 57 57 87 fd 36 9d 3c 1e cd 31 f4 fe cb c8 c8 93 82 75 29 1f 51 96 93 79 a8 ce 39 08 d2 1f c5 a1 35 34 a2 7d 49 7a 0b 0c 58 3f 32 0a e3 a9 84 f2 4b 82 11 33 2a dc c9 0f bb 0d ce b0 77 aa 04 88 9c 2f af c4 15 da 6e 60 fd b7 90 75 16 69 6a 60 d2 88 95 90 b4 eb 8a 20 de ab 89 92 b4 22 40 05 34 0b 3a bc 05 a2 7b 93 71 ac 9b fd 8b c0 9b 4f ea 3a 6a 6b e7 a2 ac ba 5d a5 a4 f5 10 03 e6 fb 09 60 66 b6 0f 63 da 76 64 aa ae c1 41 86 40 d6 e4 d7 ec 32 e1 07 10 64 ec 8d 61 c4 d8 cc d8 8f ee 32 99 9d 4a c9 20 3a c1 2b d6

 


 
    ->根据AFL发送读记录命令2
C-00 b2 02 14 00 00     (18 01 01 01根据AFL发送读记录命令, 发送第1条命令: SFI为02,记录号为01)
R-SW: 90-00
Len: 13
70 0b 9f 32 01 03 8f 01 04 9f 47 01 03                          (发卡行公钥指数)     (8f:公钥索引)
C-00 b2 03 14 00 00
R-SW: 90-00
Len: 182
70 81 b3 93 81 b0 87 e2 27 9f 2a e5 b8 7d 25 0f                 (93:签名的静态应用数据:SDA)
ed 84 7d 69 1e 76 29 75 d8 3e 25 f2 f6 e1 0c 17
5e eb 30 96 fa 39 94 4f f2 4f d5 41 7a 3d 20 ff
e7 81 c2 62 4e 48 e0 10 1a b5 96 b8 e5 de 85 1f
68 62 8f 2b b6 ee 2c 83 24 96 d8 17 0e cc 70 c3
9f f1 b6 b0 10 fc 36 80 e2 2e 83 b0 5d 02 f3 d9
3d 72 52 de ce 9b 8f e0 81 17 d8 da 1c 94 f9 78
b3 e2 5d 21 4e ef 57 b9 f7 52 21 2f 8c 5f a5 25
41 05 4e 95 d3 97 72 d8 30 2a ce 35 37 33 b9 81
8c 24 07 8c f5 ed a4 3e 63 17 1e 32 a0 fa 4d 27
47 ee 60 be 15 c5 c6 26 39 fd 97 6f 20 65 12 19
c6 13 5b ad 4e 06

 


 
   ->根据AFL发送读记录命令3
C-00 b2 04 14 00 00
R-SW: 90-00
Len: 183
70 81 b4 9f 46 81 b0 15 4c 65 cb 9f 65 94 a7 c8  (9F6:IC卡公钥证书)
1f 41 7e 24 3e e3 70 87 e5 cf ad 46 87 01 40 9c
03 e4 ac 89 d2 4d 0d 43 05 fb 88 9a 83 58 f3 61
0a 8d 04 48 fb 42 06 78 9e a4 b2 7e eb 4f a4 f9
8b 0a c2 5d a1 55 2e 27 98 d4 dc bd 76 a6 08 f8
17 6d 2b e3 66 a3 aa b8 dd b0 75 0c 33 9b dd 16
65 6b e7 81 1c e4 36 51 ca 7a 0a a8 19 a1 f6 4d
4d e2 b0 90 55 79 39 1d 1b c2 59 b5 27 e7 52 18
c8 e2 c0 98 2e ce 12 8f 60 26 9e ef 13 01 db 71
d1 7d 3e 06 1b c0 15 92 52 95 f4 a6 66 92 28 3c
8b 58 7a ae b4 c4 85 c9 81 0a 61 d6 2a 37 98 1a
a3 41 48 11 10 2b a0

 


 
   ->根据AFL发送读记录命令4
C-00 b2 01 1c 00 00
R-SW: 90-00
Len: 55       
70 35 5a 0a 62 22 03 10 01 00 76 15 39 1f 5f 24
03 27 11 30 5f 28 02 01 56 9f 07 02 ff 00 5f 25      (5f 25:应用生效日期)
03 16 12 01 9f 08 02 00 30 5f 30 02 02 20 9f 42      (9f 08:应用版本号) (5f 30:服务码)  (9f 42:应用货币代码)
02 01 56 9f 4a 01 82
C-00 b2 01 24 00 00
R-SW: 90-00
Len: 105                                              (8e:CVM list)
70 67 8e 0e 00 00 00 00 00 00 00 00 02 03 1e 03       (IAC)
1f 00 9f 0d 05 fc 50 8c 00 00 9f 0e 05 04 10 00          (9f 0e:发卡行行为代码:拒绝)
00 00 9f 0f 05 f8 70 8c 98 00 8c 1b 9f 02 06 9f           (9f 0f:发卡行行为代码:联机)
03 06 9f 1a 02 95 05 5f 2a 02 9a 03 9c 01 9f 37          (9f 0d:发卡行行为代码:缺省)
04 9f 21 03 9f 4e 14 8d 1a 8a 02 9f 02 06 9f 03
06 9f 1a 02 95 05 5f 2a 02 9a 03 9c 01 9f 37 04
9f 21 03 9f 49 03 9f 37 04

 


 
 
7->内部认证(脱机数据认证):

静态数据认证由终端使用一种基于公钥技术的数字签名方案来完成。发现在个人化以后对数据的未经授权的改动。

静态数据认证要求存在一个认证中心,这个认证中心具有高级别的安全性来签名发卡行公钥。每一台符合本规范的终端都必须为每一个它能识别的应用保存相应的认证中心的公钥。
 

 

 

 

 

  PBOC文档第5部分   B.9.2,终端通过公钥验证卡片的合法性
  内部终端认证过程:https://blog.csdn.net/xuture/article/details/9264109
  一次交易中只进行一种脱机数据认证。CDA优先级高于DDA,DDA的优先级高于SDA。如果卡片和终端一种脱机数据认证都不支持,脱机数据认证不执行。 如果终端测定卡片和终端都支持CDA,执行CDA;否则,如果都支持DDA,执行DDA;否则,如果都支持SDA,则执行SDA
  优先级是 CDA>DDA>SDA
          https://www.xuebuyuan.com/1607729.html
  step1:认证中心公钥:通过公钥下载将认证中心服务端的公钥挨个下载到终端;
       step2:恢复发卡行公钥:第6步读记录的时候已经获取到发卡行90(签名处理过的发卡行公钥),92(发卡行公钥余项),9F32,所以这个时候就可以使用CA公钥利用RSA算法对90数据进行解密);
       step3: 使用发卡行公钥经过RSA算法解密签名应用数据TAG:93(上面读记录获取)
  1.发卡行的密钥管理系统产生发卡行公/私钥对PISI,并将公钥PI传送至根CA;

  2.根CA用自己的私钥SCA对发卡行公钥PI进行数字签名,产生发卡行证书,连同根CA公钥信息返回给发卡行密钥管理系统;

  3.发卡行密钥管理系统用发卡行私钥SI对卡片静态数据进行数字签名,将签名结果和发卡行证书传送至发卡系统;

  4.发卡系统在个人化时将发卡行证书和数字签名写入每一张卡片中;

  5.根CA将其公钥PCA,经收单行传送至终端管理系统;

  6.收单行终端管理系统把根CA公钥PCA通过远程下载至终端;

  7.IC卡进行脱机交易的静态数据认证,受理终端完成如下过程:

  终端从卡片中读取出发卡行证书及签名数据,使用CA公钥PCA恢复出发卡行公钥PI;

  终端使用恢复的发卡行公钥PI解密卡片签名数据;

  终端将解密结果与卡片静态数据进行比对,保存比对结果;

  8.将验证结果返回给卡片。

 
C-00 88 00 00 04 00                               
Len: 4                                                         (1:认证中心公钥:终端已经下载过公钥,通过RID和8F(公钥索引,读记录获取):锁定认证中心公钥)
ef 08 3f 1a                                                   (2:恢复发卡行公钥:)
R-SW: 90-00
Len: 98
80 60 ae e5 aa 73 89 34 ad cc cc 54 4b 45 c6 23
a5 3a 65 9b bd d0 50 5f 50 be ce ed 7c ac da 93
43 6b 92 a2 99 52 b2 56 4e 3b b8 50 d8 09 b2 6c
4d 51 7d 9f f1 74 fa 2d e2 be 46 a5 59 fd 2e e0
fd 11 b3 4e 9b 28 a4 60 02 30 21 22 d6 76 5c e3
2e 8e 84 fd 96 e2 a6 33 2e 60 fc c1 55 92 fe 5c
26 fe

 


 
 
8: 持卡人验证
文档第5部分 11.1
参考:
 
CVM LIST:[Tag 8E]
Len: 14                                                            (02:联机加密PIN验证    03:如果终端支持)(85页)
00 00 00 00 00 00 00 00 02 03 1e 03 1f 00

  持卡人认证并不是必备的EMV流程, 终端是否应该执行持卡人认证, 决定因素在两点. 一是AIP表明是否支持, 二是在读数据阶段,卡片是否返回CVM list:

  前面8个字节为金额,第9个字节,这里为02, 0000 0010,对应“联机加密PIN”验证;
 CVR不是CVM Results。CVR是卡片验证结果,与TVR(终端验证结果)对应,所以CVR来源于卡片,无tag表示,我们不关心。而CVM Results则是持卡人验证结果,我们很关心的,这个是终端数据。
  再看03,03的含义是“如果终端支持这个CVM”,这个怎么理解呢?终端有一个很重要的数据,终端性能(9F33),终端性能中明确指出了终端所支持的验证方法,所以03的意思就是如果终端支持持卡人签名验证,那么这个交易就使用签名作为验证方法。当持卡人验证条件为03时,内核对于终端性能的判断也是直接影响持卡人验证成功与失败的关键要素

 CVM 代码 指出如果这个CVM 失败,是执行下一CVM 还是认为CVM 失败
字节9 (CVMCode):
bit 8: 0 = 只有符合此规范的取值(如果不为1,说明有自定义的值)
bit 7:
1 = 如果此CVM失败,应用后续的
0 = 如果此CVM失败,则持卡人验证失败
bits 6–1 (CVM Type):
000000 = CVM失败处理
000001 = 卡片执行明文PIN核对
000010 = 联机加密PIN验证
000011 = 卡片执行明文PIN核对+签名(纸上)
000100 = EMV保留
000101 = EMV保留
011110 = 签名(纸上)
011111 = 不需CVM
000110–011101 = 保留给加入的支付系统
100000–101111 = 保留给各自独立的支付系统
110000–111110 = 保留给发卡行
111111 = RFU 

CVM条件码:表示什么时候使用该方法

0 总是执行
1 如果是现金或返现交易
2 如果不是现金或返现交易
3 如果终端支持此CVM
4 如果交易金额小于金额X
5 如果交易金额大于金额X
6 如果交易金额小于金额Y
7 如果交易金额大于金额Y

 

 

7:脱机加密PIN原理:终端从卡片中获取PIN加密公钥证书(可在read data阶段读取),从证书中恢复PIN加密公钥. 当用户输完PIN时, 终端用此公钥加密该PIN,然后能过指令把加密数据传给卡片,卡片收到数据后,先用存在自身的PIN加密私钥解密,然后再验证该PIN的正确性.)

CVM LIST:[Tag 8E]
Len: 14                                                            (02:联机加密PIN验证    03:如果终端支持)(85页)
00 00 00 00 00 00 00 00 02 03 1e 03 1f 00
Term Capp:[Tag 9F33]
Len: 3
e0 f0 c8
***************************************
EA_EMV_NewCardHolderValidate RET=c2
请求联机PIN
call EA_EMV_NewCardHolderValidate:cCmd=00
CVM flg=01
EA_EMV_NewCardHolderValidate RET=1
Call EA_EMV_ActionAnalysis
emvShowActionCode TVR:
Len: 5
00 80 88 80 00

 

9->终端行为分析和卡片行为分析
根据TVR、IAC、TAC参数作出拒绝交易、联机交易或脱机交易的初步决定
TVR前面步骤得到的值,IAC读记录得到,TAC终端设置
当终端向卡发送GenerateAC命令时,IC卡执行卡片行为分析,然后IC卡返回应用密文
C-80 ae 80 00 34 00           (控制参数80: bit8,bit7 :00=AAC--拒绝 、  01=TC--脱机、 10=ARQC--联机、  11=RFU)
 
10->GAC1:(生产应用密文):终端行为分析后发送GAC指令(GAC:GENERATE AC)
(1:文档第5部分:B.6.2
 2:当终端向卡发送GenerateAC命令时,IC卡执行卡片行为分析,然后IC卡返回应用密文
 3:产生应用密文. 命令是GAC. 参数是密文类型和产生密文所需的数据. 密文类型有三种,分别是交易证书(TC), 应用认证密文(AAC),授权请求密文(ARQC). 因为这一步是为下一步联机处理做准备,所以终端应用请求卡片产生的密文类型应该是ARQC,查看卡片是否允许联机处理. 卡片收到产生密文类型后,返回的信息有两个重要的数据, 第一个就是密文类型,该数据指示卡片是否愿意做联机处理,如果愿意,返回的是ARQC,与终端一致,否则返回AAC,表示拒绝联机. 终端判断卡片返回的是否是ARQC,如果是,终端要读取卡片返回的另一个重要的数据,应用密文(AC), 该密文是卡片用存放在卡里的密钥,对终端发过来的明文数据,用3DES算法生成的)
 
C-80 ae 80 00 34 00                                              (控制参数80: bit8,bit7 :00=AAC--拒绝 、  01=TC--批准交易、 10=ARQC--联机、  11=RFU)
Len: 52
00 00 00 00 00 01 00 00 00 00 00 00 01 56 00 80
88 80 00 01 56 18 05 15 00 ef 08 3f 1a 11 02 02
d2 f8 c1 aa b2 e2 ca d4 c9 cc bb a7 00 00 00 00
00 00 00 00
R-SW: 90-00
Len: 32
80 1e 80 00 38 6e b0 d2 f3 72 ed 1b da 07 01 01        ( 80: 模板此模板的响应数据为: 密文信息数据(L:1:80) + 应用交易计数器(L:2:00 3803 a0 28 02 01 0a 01 00 00 00 00 00 00 e1 9e 24       + 应用密文L8:(6e b0 d2 f3 72 ed 1b da ) + 发卡行应用数据)
TM AA=0
CDA reslut 00
GetBaseData TAG state=0

 


 
 
11->IC卡片生产应用密文(一次授权给终端)
(1:卡片行为分析结束后,卡片返回一个应用密文给终端)
 
 
12->联机处理
(1:联机验证卡片. 这一步,卡片本身没有操作. 终端把前一步得到的应用密文,产生应用密文的一些数据,还有其它的信息(比如交易日期,交易时间等),打包发送到发卡行PBOC后台, 通信方式一般是用TCP/IP。 后台通过验证ARQC密文来认证卡片, 如果认证成功会返回授权响应密文(ARPC), 这个ARPC是后台通过3DES算法,对ARQC密文和二个字节的授权响应码加密生成的.)
前面终端执行完终端行为分析后,如果在GAC1的时候,卡片返回ARQC,那么终端就需要进行联机交易流程的处理,这一部分我们主要讨论一下联机交易的处理过程。
在终端获取到卡片返回ARQC后,终端先发起8583报文请求,然后接收到后台返回的报文,提取相关的IC卡数据域。
插个例子,看看某个发卡行返回的55域
  1. 91 0A E3 44 EE 82 E0 0C A8 76 30 30 72 12   
  2. 86 10 04 DA 9F 79 0A 00 00 00 02 00 00 B3   
  3. AB A7 E8 00   
第一步:
处理ARPC(如果不包含,则跳过;如果包含并且AIP特性标志不支持发卡行认证,则跳过)
收到联机返回报文后,获取tag“91”,即ARPC,通过外部认证指令将ARPC发给卡片,如果卡片响应9000,说明ARPC校验通过,否则发起冲正。
第二步:
处理发卡行脚本
再看tag72(或71,在圈存交易时,不允许出现两个脚本),这个是发卡行返回脚本采用tag72作为标签,72后面还是一个TLV,解析tag86(发卡行脚本命令),获取到
  1. 04 DA 9F 79 0A 00 00 00 02 00 00 B3 AB A7 E8 00  
再通过指令将这个命令给到卡片,整个数据就是一个指令,不需要再添加内容,实际操作如下:
  1. send:15  
  2. 04 DA 9F 79 0A 00 00 00 02 00 00 B3 AB A7 E8   
  3. rec:3  
  4. 90 00   
终端并不关心这个脚本命令是要做什么,终端也确实不知道这个脚本命令要干啥,终端的任务就是发脚本给卡片,剩下的内容就有卡片自己处理。
第三步:
第二次GAC,第一次GAC发送GAC指令时组织数据采用的是CDOL1,第二次GAC组织命令时用的是CDOL2,CDOL2也是在读记录时候获取到的。
 
  1. Send:40  
  2. 80 AE 40 00 22 30 30 00 00 00 00 01 00 30 30 30   
  3. 30 30 30 01 56 00 00 04 00 00 01 56 11 03 30 00   
  4. 1C 22 24 13 11 41 45 00   
  5.   
  6. REC:35  
  7. 80 1E 40 06 A0 8B 35 9C A6 4B CC 4F 06 07 02   
  8. 01 03 60 00 02 01 0A 01 00 00 00 07 00 A1 38 E4   
  9. BB 90 00   
这里发送的命令第三个字节为40(01000000),明显这个第二次GAC,终端请求的是TC。
上述例子卡片也是成功返回了TC,卡片成功返回TC后交易结束。
前面所讨论的依然还是不考虑存在CDA的情况,CDA情况比较复杂,先规避一下,完了再专门以一篇研究一下。
 
上述是一个标准的联机交易的流程,但是还有一个情况,假如卡片返回ARQC,但是终端执行联机交易失败。
下面主要研究一下这种情况。
卡片请求ARQC,但是终端无法联机,并不是代表这个交易终止了,终端和卡片还有最后一次尝试,就是所谓的脱机转联机,联机失败再转脱机。
这就好像买东西一样,先去第一家店看了看,觉得东西还行,但是先不买,然后再去第二家店,结果发现第二家店的东西又贵又不好,那再回去第一家店看看,价格能不能商量一下,如果能谈妥,OK,那么就交易。
这个时候首先又需要检查IAC-缺省和TAC缺省执行终端行为分析(这部分在之前终端行为分析中有表详细的描述),并且根绝结果发送第二次GAC指令。
如果第二次GAC指令能够成功返回TC,那么脱机交易批准,如果返回ACC,则交易拒绝,,这个时候不可能再返回ARQC了。
如果脱机成功则响应码为Y3(脱机批准之后,内核产生的ARC 8A的值),但是,如果终端在第一次GAC就获取TC批准脱机交易的话,响应码是Y1,所以通过Y1和Y3就可以知道是哪一种脱机批准。
 
到此为止,整个借贷记交易和电子现金的交易就已经全部处理完了。
 
 
 
 
posted @ 2018-10-26 14:31  蜗牛攀爬  阅读(5187)  评论(0编辑  收藏  举报