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