PBOC2.0安全系列之—脱机认证之动态数据认证(DDA)

动态数据认证:

一,什么是动态数据认证(DDA)

由于上篇<< PBOC2.0安全系列之—脱机认证之静态数据认证(SDA)>>已经对静态数据认证部分做了详细的分析,一些基本知识本章不重复说明,需要明确指出的是:无论SDA和DDA,两者都是属于脱机认证的范围。

在上一篇中,我们知道静态数据认证(SDA)的目标是解决发卡行静态数据的防篡改,但局限是无法防止复制卡或者伪造卡的情况,而这种复制卡和伪造卡恰恰是金融卡安全面临的最大问题。

举两个现实的例子:

1,笔者本人亲自遇到的:某天突然收到招行信用卡中心的电话,说监控发现我的卡在某个异地有从pos查询余额的记录,需要确认是否我本人的操作,我否认后,招行即可冻结了我的卡,然后要求我本人在某台ATM上做一次查询操作(笔者理解是招行想确认卡真正在我的手上),完成了回拨招行信用卡中心,答复是卡被非法复制的可能性非常大,要求及时换卡,所幸的是没有遭受财产损失。

2,大家经常在电视上或者网上看到的ATM犯罪场景:犯罪分子拿着自己定制的读卡器和摄像头到ATM去,把ATM插卡的卡套去掉换成了自己的读卡器,然后在ATM的某个不引人注意的角落里面安装上自己的针孔摄像头,当用户来取钱的时候,由于用户不小心把卡插入到了犯罪分子的读卡器,读卡器就可以把卡里面的数据都读出来并存储到自己的读卡器,同时,通过针孔摄像头拍摄用户输入的密码,然后他们回去将卡数据复制到新的空白卡,有了卡和密码,接下来的情况大家都可以猜到了…

而动态数据认证(DDA)就是要解决卡被复制后的认证问题,使得终端有能力发现卡是伪造的,基本的核心点是:卡里面有些东西是无法复制的,且无法复制的部分是埋入了卡的唯一认证密钥。

上面这句话可能比较抽象,不过不用担心,接下来笔者会重点阐述具体的原理。

二,动态数据认证(DDA)的实现原理

我们已经知道,动态数据认证的目的主要是用于防止伪造卡片。但具体如何实现呢?

1,基本原理:

再说明DDA的基本原理前,我们先review一下SDA的主要流程,方便我们进行对比:从实现技术角度看,SDA是利用发卡行公钥,CA公钥进行认证,IC卡发卡行发卡的时候写入静态数据,如卡号等,为了证明这些静态数据是发卡行写入的,而不是其他非法的机构写入的,发卡行要用自己的发卡行私钥进行签名,当然主要是对这些数据先进行计算一个摘要,然后对摘要进行签名,得到一个数字签名,并把这数字签名也一起写入卡片。这样,在实际的交易过程中,卡片插到终端后,卡片会发送这些静态数据和数字签名一起给到终端,终端会通过数据中的CA公钥余项找到对应的CA证书,然后用CA证书中的CA公钥认证发卡行的证书,通过认证后,拿到发卡行公钥证书,再用发卡行公钥来解密验证数字签名,然后拿这个结果和卡片发送过来的数据进行对比。

而DDA相比SDA来说,重点在于IC卡公私钥对,IC卡私钥是放在安全存储区域的,而验证过程是在SDA的基础上,在终端验证静态数据以后,终端会发送内部认证命令(内部认证就是终端认证卡片,外部认证就是卡片认证终端)给到卡片(见图的红色画圈部分),命令中包含了由DDOL指定的数据元,IC卡会根据这个列表中指出的数据用IC卡私钥进行加密生成数字签名,这个结果即是签名的动态应用数据,接下来,终端收到这数据后,会像SDA一样,用CA公钥证书->发卡行公钥证书->IC公钥证书,从IC卡公钥证书拿到IC卡公钥来解密IC卡私钥加密的数据,并进行比较结果。

这里笔者也附上来自PBOC规范对DDA部分原理的说明:终端要求卡片提供由IC卡私钥相比SDA使用的是发卡行私钥签名静态数据,这里使用的是不同的IC卡私钥,这个私钥存储在IC卡的一个安全区域内,无法进行复制)加密动态交易数据生成的密文,动态交易数据是由终端和卡片为当前交易产生的唯一数据。终端用从卡片上获取的IC卡公钥来解密动态签名,如果还原的数据与原始数据匹配证实了此卡不是由合法卡复制出的赝品卡。复合动态数据认证/应用密文生成把动态签名生成与卡片的应用密文生成相结合,确保卡片行为分析时返回的应用密文来自于有效卡。

2,实现步骤:

在分析实现步骤前,我们先重点分析一下各个关键实体需要持有的证书或者密钥对的情况:


实体


拥有证书或者密钥对等


发卡行


发卡行私钥


IC卡


发卡行证书(经过CA签名的发卡行公钥),

IC卡证书(用发卡行私钥进行签名),

卡片私钥,

卡片静态数据和用发卡行私钥对静态数据进行签名的数字签名


终端


CA公钥

从上面可以看到,相比SDA,DDA的证书和密钥持有情况最大的不同是:IC卡多了IC卡证书和卡片私钥。

因此,DDA相比SDA来说,除了具备SDA的防篡改保护外,最强大的地方是防止卡复制,相比SDA,它的签名是动态的,SDA的签名在卡发行的时候就已经定好了,它签名所用的私钥是发卡行私钥,而DDA每次用来签名的数据是当前交易中的一些动态数据,签名所有的密钥是IC卡私钥(不同的IC卡具有不同的IC私钥),这个存储在IC卡里面的一个安全存储区域内(这个非常重要,一般是专门的安全芯片,是无法读出的),而终端这边通过从IC卡读取出对应的IC卡公钥来解密验证。那么如何实现防复制呢?

举个例子:张三的卡被李四复制了一张,当李四拿着复制的卡到ATM进行取钱的时候,终端会要求认证IC卡,于是发一串动态的交易数据给IC卡,IC卡会生成一个用自己IC卡密钥签名的应用密文给到终端确认,而关键的地方就在这里,这个签名需要用到IC卡私钥来签名,而这个IC私钥是存储在IC卡的安全芯片内,李四复制的卡无法拿到,因此无法生成对应的签名数据给到终端确认或者随便用一个私钥进行签名拿到一个串给到终端,而终端这个时候是用IC卡对应的公钥来解密,发现通不过,因为终端解密的IC卡公钥和复制卡的IC私钥不是配对的,因此验证失败,交易中止。

需要重点说明的是:IC卡是CPU卡,智能卡,里面有复杂的文件结构,不像磁条卡结构那么简单,并且最关键的是有一个IC卡私钥存储于IC卡文件安全区域,相当于XP系统的系统文件,有权限都复制不了,即就是把整个卡都复制了,IC卡私钥也没有被复制进去,而DDA就是依赖这个IC卡私钥来确认卡片的真实性,防止卡片的非法复制。

动态数据认证有标准动态数据认证(DDA)复合动态数据认证(DDA/AC-CDA)两种。

并且DDA是在卡片行为分析前执行,此时,IC卡将来自卡片的动态数据以及由动态数据认证数据对象列表(DDOL)所标识的终端数据用IC卡私钥生成一个数字签名。

标准动态数据认证(DDA)的详细过程如下:

密钥和证书分发阶段:

1,发卡行的密钥管理系统产生发卡行公私钥对SI和PI,以及为每一张IC卡生成一对公私钥对SICC和PICC,并将发卡行公钥PI传输至根CA;

2,根CA用自己的私钥SCA对发卡行公钥进行数字签名,产生发卡行证书,连同根CA公钥信息返回给发卡行密钥管理系统;

3, 发卡行用发卡行私钥SI对每个IC卡公钥PICC进行数字签名,产生IC卡证书;--关键一步

4,发卡行密钥管理系统将发卡行证书及IC卡证书,IC卡私钥传送至发卡系统;

5,发卡系统在个人化时将发卡行证书和IC卡证书写入卡片中,(笔者标识:同时在制卡的时候,把IC私钥一起存入卡的安全存储芯片中)

6,根CA将自己的公钥PCA传送给收单行的终端管理系统;

7,终端管理系统把根CA公钥PCA通过远程下发到终端。

交易验证阶段:

1,终端从卡片读取发卡行证书及IC卡证书,使用根CA公钥PCA恢复出发卡行公钥PI,使用恢复的发卡行公钥PI恢复出IC卡公钥PICC;

即发卡行公钥+IC卡证书+RSA算法=IC卡公钥

2,终端向IC卡发送内部认证命令(INTERNAL AUTHENTICATE)请求一个动态签名,卡片连接内部认证命令中的终端数据和在IC卡中动态数据中指定的卡片数据,由存储于卡片安全芯片的卡片私钥SICC对该数据进行数字签名并返回终端;

3,终端使用IC卡公钥PICC对数字签名进行验证,并将验证结果返回给卡片。

复合动态数据认证(DDA/AC-CDA)的详细过程如下:

这种方式是在第一个请求应用密文命令发出后执行,IC卡将来自卡片的数据包括应用密文以及来自终端的数据生成一个数字签名。具体过程跟DDA基本相同:

1,发卡行的密钥管理系统产生发卡行公私钥对SI和PI,以及为每一张IC卡产生一对公私钥对SICC和PICC,并将发卡行公钥PI传送至根CA;

2,根CA用自己的私钥SCA对发卡行公钥进行数字签名,产生发卡行证书,连同根CA公钥信息返回给发卡行密钥管理系统;

3,发卡行用发卡行私钥SI对IC卡公钥PICC进行数字签名,产生IC卡证书;

4,发卡行密钥管理系统将发卡行证书IC卡证书传送至发卡系统;(笔者标识:包括IC卡私钥)

5,发卡系统在个人化时将发卡行证书和IC卡证书写入卡片中。(笔者标识:同时在制卡的时候,把IC私钥一起存入卡的安全存储芯片中)

6,根CA将自己的公钥PCA传送至发卡行的终端管理系统;

7,发卡行终端管理系统将根CA公钥PCA通过远程下发到终端;

交易验证阶段:

1,终端从卡片取出发卡行证书及IC卡证书,使用根CA公钥PCA恢复出发卡行公钥PI,使用恢复的发卡行公钥PI恢复出IC卡公钥PICC;

2, 终端像卡片发出应用密文命令(GENERATE AC),卡片响应该命令;(跟DDA不同点)

3,卡片连接终端通过另外的命令送来的数据及自己的响应数据,由卡片私钥SICC对该数据进行数字签名并返回给终端;

4,终端利用卡片公钥验证卡片动态生成的签名,这一步在联机处理过程中执行,如果验证失败,则交易拒绝。

时间: 2024-08-11 01:02:50

PBOC2.0安全系列之—脱机认证之动态数据认证(DDA)的相关文章

静态数据认证(SDA)与动态数据认证(DDA)的区别

PBOC/EMV里有两个非常重要的概念,SDA(staticdataauthentication)和DDA(dynamicdataauthentication),分别叫做静态数据认证和动态数据认证.这两个认证都是脱机下(off-line)的认证.业内人都知道磁卡和IC卡迁移的一个很重要的原因就是安全问题. 结论: SDA和DDA都是在脱机交易下的认证     举两个磁卡犯罪的例子: 1磁卡本身的构造原理使得它的数据非常容易被非法修改,你肯定不愿意有人非法修改你卡上的数据,当然如果是在你的余额后面

PBOC2.0与3.0的区别

一.PBOC规范颁布的历程 1997年12月,PBOC V1.0  定义了五个方面的事项  电子钱包/电子存折应用(EP,ED)  卡片和终端的接口  卡片本身的技术指标  应用相关的交易流程  终端的技术要求等 二.2005年3月,PBOC V2.0 在V1.0基础上修改,增设了 电子钱包/存折应用,拓展电子钱包应用范围 借记/贷记应用个人化指南,促使借记/贷记应用兼容EMV2000标准 非接触式IC卡电气协议特性 小额支付和快速支付领域---非接触支付.基于借记贷记的电子现金等内容(2010

PBOC3.0和PBOC2.0异同

1    数据方面 TAG                                               PBOC2.0                                                                                PBOC3.0                                                                               5F20 持卡人姓名 如果小于26

PBOC2.0与PBOC3.0的区别

2013年2月,中国人民银行发布了<中国金融集成电路(IC)卡规范(V3.0)>(以下简称PBOC3.0),PBOC3.0是在中国人民银行2005年颁布的<中国金融集成电路(IC)卡规范(2.0)>(以下简称PBOC2.0)基础上,经业内专家多次研讨并不断修订.补充完善而成,此次升级适应了银行卡业务发展的新要求,为金融IC卡进一步扩大应用奠定了基础,对推进金融创新和提升金融服务民生的水平有重要意义.  一.PBOC3.0颁布的背景 1997年12月,中国人民银行在借鉴国际有关标准的

WCF 4.0 进阶系列 -- 随笔汇总

WCF4.0 进阶系列–前言 WCF4.0 进阶系列--第一章 WCF简介 WCF4.0进阶系列--第二章 寄宿WCF服务 WCF4.0进阶系列--第三章 构建健壮的程序和服务 WCF4.0进阶系列--第四章 保护企业内部的WCF服务 WCF4.0进阶系列--第五章 在因特网环境下保护WCF服务 WCF4.0进阶系列--第六章 维护服务协定和数据协定 WCF4.0进阶系列--第七章 维持会话状态和设置服务操作的顺序 WCF4.0进阶系列—第八章 使用工作流实现服务 WCF4.0进阶系列—第九章

HTTP知识普及系列:确认访问用户身份的认证

认证:密码.动态令牌.数字证书.生物认证.IC卡. HTTP所使用的认证方式 BASIC认证(基本认证),BASIC认证是从HTTP/1.0就定义的认证方式.Base64编码方式. DIGEST认证(摘要认证),DIGEST认证同样适用质询/响应的方式,但不会想BASIC认证那样直接发送明文密码. SSL客户端认证,SSL客户端认证是借由HTTPS的客户端证书完成认证的方式.凭借客户端证书认证,服务器可确认访问是否来自己登陆的客户端.SSL客户端认证不会仅依靠证书完成认证,一般会和基于表单认证组

Spring Boot 2.0干货系列:(一)Spring Boot1.5X升级到2.0指南

前言Spring Boot已经发布2.0有满久了,多了很多新特性,一些坑也慢慢被填上,最近有空,就把本博客中Spring Boot干货系列对应的源码从1.5X升级到Spring Boot 2.0,顺便整理下升级的时候遇到的一些坑,做个记录.后续的教程就以最新的2.03版本为主.依赖 JDK 版本升级 2.x 至少需要 JDK 8 的支持,2.x 里面的许多方法应用了 JDK 8 的许多高级新特性,所以你要升级到 2.0 版本,先确认你的应用必须兼容 JDK 8. 另外,2.x 开始了对 JDK

[转]asp.net权限认证:HTTP基本认证(http basic)

本文转自:http://www.cnblogs.com/lanxiaoke/p/6353955.html HTTP基本认证示意图 HTTP基本认证,即http basic认证. 客户端向服务端发送一个携带基于用户名/密码的认证凭证的请求.认证凭证的格式为“{UserName}:{Password}”,并采用Base64编码,经过编码的认证凭证被存放在请求报头Authorization中,Authorization报头值类似:Basic MTIzNDU2OjEyMzQ1Ng==.服务端接收到请求之

asp.net权限认证:HTTP基本认证

一.HTTP基本认证示意图 HTTP基本认证,即http basic认证. 客户端向服务端发送一个携带基于用户名/密码的认证凭证的请求.认证凭证的格式为“{UserName}:{Password}”,并采用Base64编码,经过编码的认证凭证被存放在请求报头Authorization中,Authorization报头值类似:Basic MTIzNDU2OjEyMzQ1Ng==.服务端接收到请求之后,从Authorization报头中提取凭证并对其进行解码,最后采用提取的用户名和密码实施认证.认证