Apple Pay漫谈一从PCI攻击看支付方式的安全性


要窃取银行卡数据,黑客/攻击高手需要由一些先决条件,包括:

  1. 一个允许大量隐患数据/威胁攻击的接入点(显然,窃取少量数据通常对攻击者没有什么意义,一旦产生窃取或者泄露就会是大量数据)
  2. 一个可以威胁到系统的漏洞或者安全隐患(并且被外部人员获得相关漏洞信息)
  3. 此外还需要一个接入点用来收集泄露数据
PCI DSS实际上对这些安全问题和安全隐患都有考虑。也将类似场景融合进PCI DSS需求规范里面。
当然对规范的严格以依性并不能100%屏蔽安全威胁和攻击。但是如果缺乏严谨的PCI控制,安全攻击和数据泄露几乎会成为一个必然发生的事情。
我们设想一种简化的场景,或者说更直接的初级的攻击:
       既某个坏蛋试图从PoS机直接收集银行卡数据。
在这种情况下如果采用端到端加密既从密码输入键盘开始加密所有持卡人数据,使得持卡人数据在传送给 PoS控制PC前既成为加密数据的话,将很大程度上减少简单直接从PoS环节获取用户数据的攻击和威胁。这就是所谓的PCI P2PE,对PCI P2PE的规范的严格以依性,是商户可以尝试的一个保护客户数据和隐私的简单办法。
虽然在现实当中的攻击手段各有不同,但是通常攻击者能够获取的卡数据(尤其是磁条卡数据)大体一样
    -获得全部第二磁道数据
    -获得加密后的PIN码数据(但是通常很难解密还原成未加密的PIN)
攻击者可以用破获的数据完成卡的复制,而复制的卡是否能正常被使用还取决于卡的类型或者支付环境
在众多的潜在威胁场景里面我们可以再仔细看看所谓无卡支付场景,这种场景被大量使用在互联网支付当中,国内的众多第三方支付如支付宝,微信支付等等都是这种无卡支付的实现。
理论上讲从 PoS环节泄露的卡数据不能用于诸如互联网支付的无卡支付场景。为什么呢?对于PoS部分的攻击和数据泄露仅仅能获得第二磁道上的数据,并不包括所谓的安全码既打印在卡背面签字栏上的3个数字-CVV2,不过现实往往比较残酷,在如下几个场景中,CVV2并没有被用到

-有不少网上商店,商户,或者支付技术提供商商并不要求输入 CVV2,责任在商户自身,但是很多商户尤其是当下用户体验为王的年代为了保证用户体验而省掉了这个环节,可惜!
-有一些发卡行并不对提交的CVV2进行验证,可气!
-有些时候攻击就是玩个概率。在样本空间,或者说泄露的卡数据足够多的情况下,毕竟CVV2仅仅是三个十进制数字组成,1,000次的尝试季卡,大多数发卡行都允许3次试错,这就给了攻击者一个每张卡0.3%的机会完成一次CNP交易。机会不算大,但是如果基数大也就是泄露的数据足够多,比方说泄露了500万张卡数据,那么可以进行暴力破解CVV2进而完成CNP交易的最终数量还是惊人的!

在我们熟悉的支付场景里面,那些是有卡支付那些是无卡支付能?
  • 支付宝钱包:虽然支付宝在通过各种渠道试图打通线下,使用NFC和eSE进行有卡支付,但是这个仅仅限于公交领域,对于臃肿庞大的支付宝应用本身而言,它是基于互联网的无卡支付,只不过是自称风险控制做的好的一个无卡支付。
  • 微信钱包呢?无卡支付无疑,虽然在卡的绑定,用户体验上不得不说微信因为有后发优势,做的比支付宝好,但是微信钱包其实是在后台通过第三方支付平台的绑定实现的基于互联网的无卡支付,而且是不需要验证 CVV2的这种,想一下泄露的威胁,后背有点发凉。
  • 谷歌钱包呢?在初始版本中使用的是内置安全实体的有卡支付,随着推广的不成功,在2.0以后改为无卡支付,而且是需要用户留存数据的无卡支付,安全性更是不靠谱!可以说谷歌是需要用户提交谷歌想要的所有内容,苹果是提交交易中,仅仅交易需要的最少内容,并且中间任何环节不留存,而支付场景是有卡支付,在充分利用线下 NFC环境和接口以及线上有卡的银行后台风险控制都不需要该把 的情况下,安全性,事实容易程度都得到了保证。
所以苹果支付既Apple Pay是有卡支付场景(无论是in store还是 in APP),安全性自然不用说,对银行而言也是更倾向于有卡支付,商户方面也不用担心承担银行数据泄露的风险,如此细想,2015年apple pay着实是会发力啦!

Leave a comment

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>