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”中。