EMV技术学习和研究-脱机数据认证之SDA

脱机数据认证的方式有：SDA、DDA、CDA三种。最常用的的就是SDA、DDA，所以先讨论研究这两个认证方式，CDA放到后面。

终端究竟采用什么方式做脱机数据认证，取决于两个要素AIP和终端性能。

读完记录结束以后，将会有四个要素伴随IC卡交易的整个流程，AIP、终端性能（接触式9F33，Q是9F66）、TVR、TSI。

AIP是GPO时候卡片返回的，之前也提到过，表明卡片的特性。终端性能通常是终端根据交易的特性来设定一个默认值（目前看到的改变这个值的地方，主要是根据AID参数里面下发的是否支持联机PIN要素，要改变终端交易性能），TVR表明终端验证结果，TSI表明交易状态信息。

交易过程中，每往下走一步，都要首先分析AIP和终端性能的各个位的情况，而交易每执行完一步都要对TVR和TSI进行置位或者清零。

简单说明一下：应用开发工程师，分析IC卡失败交易的第一步应该是看TVR和TSI，看看终端做过什么，终端哪一步失败了，然后在分析某个步骤失败的原因。

上面的分析确定了终端脱机数据认证的方式（三种方式优先级不同，但是最终只会选定一种优先级最高的），下面我们研究一下脱机数据认证的数据来源、脱机数据认证的方式和算法，以及脱机数据认证的一些特性。

一、数据来源

文档上对于参与脱机数据认证的SFI有明确分类，分为SFI从1-10以及11-30两类。

1-10的SFI在参与脱机数据认证的时候，其文件标志“70”和记录长度不参与脱机数据认证，而SFI为11-30的，则70和记录长度也要参与脱机数据认证。

特别说明: 这里通过AFL的SFI所组织获得的用于签名的脱机数据，将会在后面多个地方用到，比如恢复发卡行公钥，比如恢复IC卡公钥等等，后面还有别的数据，所以特别描述一下，对这个数据加深印象。

首先插入一个交易的AFL返回值，这块数据在GPO的时候已经用于举例，现在单独把AFL的内容提取出来。

[html]  view plain copy

1. 08 01 02 00  
2. 10 05 06 01  
3. 10 08 08 00  
4. 18 01 02 00  
5. 20 01 01 00  
6. 28 01 01 00  

上述6行数据就是GPO之后返回的AFL，为了方便说，我把AFL的解释也从文档摘出来，我们取一条实例来说明，比如08 01 02 00，这一组读记录的结果中，70和记录长度都不用参与脱机数据认证，10 05 06 01 以及 10 08 08 00 也是一样的。

然后再看除了10 05 06 01之外，其余的五组最后一个字节均为00，对比字节4我们看，就是表示用于脱机数据认证的连续记录个数为0，也就是说这五组读记录的结果中没有数据是用于脱机数据认证的。

经过上述分析应该可以很清楚的看到，用于脱机数据认证的数据应该怎么取了。

二、认证方式

SDA和DDA数据认证方式不一样，先看SDA如何认证。

SDA分为三步，第一步获取认证中心公钥，第二部恢复发卡行公钥，第三部进行数据认证。

第一步认证中心公钥，首先是通过公钥下载将服务端的公钥挨个下载到终端。在获取认证中心公钥的时候，只要做两个判断即可，首先判断应用选择时候选择的AID的5个字节即为RID，其次需要用到读记录时候获取到的发卡行公钥索引(8F)，通过RID和索引可以唯一选择到一组公钥，选择完成后，获取认证中心公钥的步骤就算是OK了。

第二步恢复发卡行公钥，这个步骤比较复杂一点，接下来慢慢看。

首先，读记录的时候已经获取到发卡行90（签名处理过的发卡行公钥），92（发卡行公钥余项），9F32，所以这个时候就可以使用CA公钥利用RSA算法对90数据进行解密。

解密后的数据为一个比较复杂的数据格式，需要对数据的头尾，以及中间数据做判断，其中对后续才做有用的数据是“哈希值”，执行完这一步，终端已经获取到了卡片计算出的哈希值，卡片计算哈希值的方法和终端一样，所以这个位置，只要知道这里获取到了发卡行公钥或者发卡行公钥最左边的部分以及获取到了哈希值就行了。

我们已经获取到了卡片返回的哈希值，终端自然也需要再计算一个哈希值出来。

计算方法如下，首先需要组织一长串数据，格式为：证书格式 + 发卡行标识(主账号最左面的3 -8 个数字) +证书失效日期 +证书序列号 +哈希算法标识 +发卡行公钥算法标识 +发卡行公钥长度 +发卡行公钥指数长度 +发卡行公钥模数的完整数据 128 个字节+发卡行公钥指数

特别说明：发卡行公钥模数的完整数据一部分是在还原发行卡公钥数据过程中获取的，还有另外一部分是在卡片读记录的时候通过92tag获取到的。除此之外，其他数据都为卡片返回原始数据，或者是一些固定写死的值。

组织好数据之后，我们可以进行sha1哈希值的计算，计算出的哈希值将和我们在恢复发卡行公钥中获取到的哈希值一样，到此，恢复发卡行公钥的步骤已经完成完成，其中任何一部失败都会认为是静态数据认证失败。

这个地方之所以做一个哈希，就是为了判断卡片提供出来的发卡行公钥是不是真的由CA签发的。

特别说明，步骤一和步骤二在DDA过程中也是要用到的，一模一样的。

第三步，验证签名数据

第三步的过程其实和第二步很类似的，第二步是用认证中心公钥来恢复发卡行公钥，第三步自然就是用发卡行公钥来恢复签名的静态数据，恢复出签名数据中有一部分是需要在终端计算hash值中使用的

（将表5中的第二个到第五个数据元素（即从签名数据格式直到填充字节）从左到右连接，再把本规范第三册的第II 部分中指明的需认证的静态数据加在后面。如果静态数据认证标签列表存在，并且其包含非‘82’的标签，那么静态数据认证失败…………摘自EMV2000 BOOK2）

组织签名数据首先按照之前描述的sfi的规则获取脱机认证数据，还有个特别的地方，如果存在9F4A的话，需要将AIP作为签名数据,不需要包含tag和L，只要V就可以。最后对组织好的数据，进行sha1运算，获得hash值，然后和恢复签名数据时获取的哈希值比较，如果相等则SDA成功，然后将计算出的hash保存在9F45的标签中。SDA流程就算是结束了。

其实在整个SDA过程中用到了很多数据值，一个优秀的emv内核应该是在sda之前就选判断上述所需的数据是否存在，如果不存在的话，则应该直接终止交易，提高终端软件的性能。

 作者:小旭