PBOC规范研究之九---静态数据认证（转）

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

       为了获得发卡行公钥证书，使用认证中心私钥S_CA，对表1中指明的数据进行签名。

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

为了获得签名的静态应用数据，使用发卡行私钥S_I，对表2中指明的数据应用11.2.1条中指明的签名方案。

发卡行的公钥有一个发卡行公钥模，该公钥模为N_I个字节（N_I≤N_CA）。如果N_I>（N_CA-36），那么发卡行公钥模被分成两部分，即一部分包含公钥模中高位的N_CA-36个字节（发卡行公钥中最左边的数字）；另一部分包含剩下的低位N_I-（N_CA-36）个字节（发卡行公钥的余项）。发卡行公钥指数必须等于3或2¹⁶+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”中。