PBOC规范研究之十 ---标准动态数据认证（转）

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卡的动态签名。分别将认证中心私钥S_CA应用到表6中指定的数据以及将发卡行私钥S_I应用到表7中指定的数据，以分别获得发卡行公钥证书和IC卡公钥证书。

      认证中心的公钥有一个N_CA个字节的公钥模。认证中心公钥指数必须等于3或2¹⁶+1。

      发卡行的公钥有一个为N_I个字节（N_I≤N_CA）的发卡行公钥模。如果N_I>（N_CA-36），那么发卡行公钥模被

分成两部分，即一部分包含模中最高的N_CA-36个字节（发卡行公钥中最左边的数字）；另一部分包含剩下的模

中最低的N_I-（N_CA-36）个字节（发卡行公钥余项）。发卡行公钥指数必须等于3或2¹⁶+1。

       IC卡的公钥有一个为N_IC个字节（N_IC≤N_I≤N_CA）的IC卡公钥模。如果N_IC>（N_I-42），那么IC卡公钥模被分成两部分，即一部分包含模中最高的N_I-42个字节（IC卡公钥中最左边的数字）；另一部分包含剩下的模中最低的N_IC-（N_I-42）个字节（IC卡公钥余项）。IC卡公钥指数必须等于3或2¹⁶+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卡动态数据的字节长度L_DD满足0≤L_DD≤N_IC-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”中。