【iShout】谁在背后保护 Apple Pay 的安全，让你安心买买买？

编者注：本文作者吴智宁，是小米支付的产品经理，对信用卡领域有深入研究。在 Apple Pay 与我们渐行渐近之时，也是时候了解一些 Apple Pay 背后的安全机制 Tokenization。在看这篇专业解析之前，也不妨再温习一下之前 “小米生活” 产品经理带来的《关于 Apple Pay，你一定要看这篇文章》。

随着 Apple Watch 的正式发布，Apple Pay 最近在网上也越来越如火如荼的被提起。也多有传闻称：iOS 8.3 发布时，Apple Pay 在国内会同时上线。

而在 Apple Pay 中，用来保护用户隐私的技术中，最为引人注目的技术便是 Tokenization。这项技术是信用卡在介质上进行的一次革命，可谓 “为无卡支付而生”。因为在用户的用卡过程中，最担心的是卡的支付信息被盗；而 Tokenization 着重解决的便是用户的信用卡卡号等支付要素被盗的问题。

那么，Tokenization 和现有的线上支付系统有什么区别呢？在讨论这个问题之前，我们不妨先回顾一下历史：

传统无卡交易及安全

我们先来说明一下无卡交易：在信用卡组织的定义中，持卡人不需要将物理卡片出示给商家的交易，就算无卡交易。

在常见的无卡交易发生时，用户需要输入卡号、姓名、有效期和三位验证码（CVV2）。

如果商家记录下您的这些信息，那么就可以通过这些信息去其他的商家进行无卡消费。为了避免这样的惨剧发生，在支付卡安全标准（PCI-DSS）中明确规定，商家不得储存用户的验证码。

从上表中可看出：验证码（CAV2/CVC2/CVV2/CID/CVN2）属于用户敏感数据，商户不可保存。

但是许多商家为了用户下次可以更方便的支付，会悄悄保存用户的验证码。而如果此类商家的服务器被攻破，信用卡信息被窃，盗刷惨剧就从此发生。去年某商旅网站爆出漏洞之后，许多银行的客服电话被要求换卡的用户打爆了，这从侧面说明传统无卡交易的安全隐患已如危巢之卵，风险随时可能爆发。

Tokenization 之外的解决方案

正是因为传统无卡支付易于出现持卡人信息泄露的风险，因此各发卡组织为了避免出现大规模盗刷，一直都在努力尝试各种解决方案。

在 Tokenization 出现之前，目前常见的解决方案包括：3-D Secure（Verify By Visa / Master SecureCode 等）、短信动态口令和协议支付。这三种方式都从一定程度上解决了盗刷问题，在这里让我们先回顾一下这些方案：

3-D Secure

3-D Secure（以下简称 3DS）是 Arcot Systems（不是任天堂哟）推出的一套安全解决方案，它通过用户设置的独立支付密码来增强帐户安全。

在 Visa，3DS 还有一个名字：Verify By Visa；而在 MasterCard，3DS 则被称为 Master SecureCode。

当用户开启 3DS 验证之前，需要额外设置一个 3DS 支付密码；而之后在支持 3DS 验证交易的网上商家交易时，都需要输入这个 3DS 支付密码，发卡行通过验证 3DS 密码来确认是否为客户本人交易。

而在验证密码的过程中，密码通过持卡人本人与发卡银行之间建立的加密通道传输，因为网上商户/第三方支付机构无法获得持卡人的 3DS 密码，因此银行相信这样可以增强用户网上交易的安全性。

当然，这项技术需要银行额外开发，因此不是所有银行都支持 3DS 验证。国内支持银行如下：

中国农业银行
中国工商银行
中银信用卡（国际）有限公司（注：中银国际卡有，中国银行信用卡无此服务）
中国建设银行
招商银行
交通银行
中国民生银行
中信银行
中国光大银行
兴业银行

中国工商银行
中国农业银行
中国建设银行
中国交通银行
招商银行
中国民生银行
华夏银行
兴业银行

3DS 验证除了需要银行支持之外，它最大的敌人是木马程序。因为 3DS 支付密码是在用户的电脑上输入的，而当用户输入了这个密码的时候，依据《欺诈责任转移政策》FLS，用户/发卡行无法提出欺诈拒付。而在用户输入密码的过程中，如果电脑上被安装如屏幕监控程序之类的木马，那么密码将很容易丢失。而如果用户丢失密码，这张卡就成为盗卡组织眼中的肥羊。

既然 3DS 验证存在这些问题，但是这是一种国际通用的支付解决方案。让我们把视线回到国内，看看国内如何解决支付安全问题：

短信动态口令

短信动态口令与 3DS 不同，它并不需要用户额外设置支付密码，而是在验证用户的支付要素之外，通过向用户的手机下行一条验证码短信来验证用户目前持有这张银行卡。银行认为：若用户正确输入短信中的验证码，则银行认为用户已授权支付这笔款项。

在国内第三方支付所提供的快捷支付功能中，通过用验证短信动态口令的方式来验证用户身份已经成为一个公认的行业标准。

看到这里，大家会问：为神马不输入银行卡取款密码呢？因为第三方支付机构无权验证用户的支付密码，而银行也不允许第三方支付机构验证支付密码。

因此，没有短信验证支付，就没有快捷支付。没有快捷支付，大家就不能快乐的在手机上买买买了。

但是，在短信验证支付的实际支付流程中，商户/第三方支付机构依然需要留存用户的支付要素以发起支付请求，因此如果商户/第三方支付机构的服务器被黑客攻破，用户的支付要素依然会被丢失。

为了避免第三方支付机构的服务器被黑客攻破后丢失支付要素，国内许多家银行目前都在快捷支付的过程中使用 “协议支付” 来增强安全性。因此，接下来我们开始聊聊协议支付。

协议支付

协议支付顾名思义，是用户和银行之间签订快捷支付协议，用户在协议签订之后，凭借协议号来进行后续的扣款支付。

比起传统的快捷支付，由于扣款协议是依据商户/第三方支付机构来签订的，其他商户/机构无法使用这封扣款协议；因此即使商户/第三方支付机构的服务器被攻破，即使扣款协议被盗取，用户依然可以正常支付。

在具体实践中，协议支付可以从银行端发起签订（如支付宝卡通），也可以由商户/第三方支付机构发起签订（如部分银行的快捷支付签约）。

但是协议支付并不能取代短信动态口令，因为银行依然认为保存在商户/第三方支付机构的协议是不安全的。银行坚定的认为：通过同时通过验证支付密码/短信验证码的方式来进行风控才是安全滴。

将线上支付带到线下：Tokenization

虽说无卡支付已经有了许多可用的产品，但是这些产品依然无法替代信用卡本身，无卡支付的适用范围依然仅限于线上。

因为：无论是 3D Secure 新增的在线支付密码、还是短信动态口令的短信验证码、甚至是协议支付中限定仅供两方使用的协议，都无法满足卡组织对线下交易的风控需求。

银行主要担心的是：而如果卡片可以随便被复制，那么就可能被不法组织利用。

因此，Apple Pay 选择了一个从技术上 “无法复制” 的介质来存储用户的支付信息，同时通过 Tokenization，将 “复制” 行为演变为向原有信用卡增加一个关联帐户，如此曲线救国，让卡组织放心接纳这项技术。而在 iPhone 5s 之后加入的生物识别技术也已经足够成熟到银行和卡组织愿意去相信。

于是，Apple Pay 就从线上走到了线下。而在这项技术中用以保护用户关键信息的技术，便是 Tokenization。但是它的使用并不限于 Apple Pay，还可以在其他线上/线下使用场景中被使用。

在线下支付中使用 Tokenization

在 Apple Pay 的支付流程中，iPhone 的安全模块中并不存储用户的卡号（PAN）及其余支付信息，取而代之的是苹果公司称之为 DAN（设备帐号 / Device Account Number）的支付 Token。用户输入卡号、姓名、有效期与验证码，银行验证信息之后向手机下发 DAN。

DAN 存放于手机上的安全芯片（Security Element）内，仅本机可读，苹果公司不会将 DAN 上传/备份至服务器，甚至苹果公司在云端都无法访问到 DAN。

在这个过程中，Tokenization 为用户的信用卡新增了一个与卡片唯一关联的设备帐号，而且这个设备帐号仅在这台设备上可用。在用户关联了卡之后，可以通过 DAN 与 Touch ID/锁屏密码来完成支付交易的确认。为了保护用户支付信息的安全，在用户验证 Touch ID/输入支付密码之前，所有的支付要素都不会被发送到收款终端上。少年们，只要将你的手指从 Home 键上移开，你的钞票就不会随便离你而去。

为了保护用户的设备帐户安全，如果用户关闭锁屏密码/注销帐户/擦除设备上的内容，这台设备中绑定的所有卡片都会被自动删除。而在你挂失这台设备的时候，苹果也会主动联系卡组织注销设备中的卡片，这样即使手机被破解，卡片也无法使用。

在无卡支付中使用 Tokenization

Tokenization 的线上使用模式与协议支付类似，区别点在于协议支付存储的是商家/第三方支付机构所生成的协议号；而 Tokenization 方案则存储由卡组织/银行生成的支付 Token。

由于支付 Token 是专用的，因此即使 Token 失窃，其他商家也无法使用它来支付。而卡组织还可以主动挂失 Token，因而 Token 相比其余支付方式有着更高的安全性。

下图是 Tokenization 的流程，它并没有大幅改变传统支付流程，而是在必经流程中改造。这也是目前卡组织愿意接受它的原因。