3-D Secure 2.0 协议研究与分析*

彭启维，陈恭亮，2，周志洪，2

（1.上海交通大学，上海 201100；2.上海市信息安全综合管理技术研究重点实验室，上海 201100 ）

0 引言

国际芯片卡标准化组织（Europay MasterCard Visa Company，EMVCo）于2016 年发布3-D Secure 2.0 标准，用于在移动互联网背景下，发卡行对持卡人和商户的身份进行认证。该协议是基于VISA于2001 年推出的3D-Secure 1.0 协议标准升级而来的。3DS 2.0 协议可以在信用卡支付场景中高效地验证持卡人和商户的身份，为用户提供多样化的身份认证手段，并保护持卡人隐私。此外，监管机构也可实现对支付的穿透式监管。因此，在移动支付普及的今天，3DS 2.0 协议是十分有研究价值的。同时，不只是支付领域，在其他应用场景中也可以借鉴3DS 2.0 协议的思路来对用户进行身份认证。

1 3DS 2.0 协议的研究背景

2001 年至2002 年，VISA 推出了“VISA 验证”，用于认证信用卡持卡人的身份，其核心技术就是3-D Secure 协议。3D-Secure 协议将身份认证中的各实体划分为三个域：发卡域、收单域和交互域，使得各方可以在支付过程中明确自己的责任。

如图1 所示，在3-D Secure 协议中，由持卡人发起身份认证，商家通过安装在其服务器上的插件（Merchant Server Plug-in，MPI），将持卡人信息经Visa 的目录服务器（Directory Server，DS）转发给发卡行的访问控制服务器（Access Control Server，ACS）。ACS 验证持卡人是否合法注册，并将结果通过DS 发送给MPI。MPI 将支付认证请求通过持卡人的浏览器发送给ACS，由ACS 与持卡人进行交互，实现对持卡人身份的认证，并将身份认证结果通过持卡人的浏览器发送给MPI。之后，MPI 将身份认证结果发送给收单行，收单行和发卡行完成支付授权，将授权结果返回给商家。

随着移动互联网时代的到来，3-D Secure 1.0协议的缺点日益暴露。

一是组织关系不明确。3DS 1.0 协议最初由VISA 研发，之后授权给万事达、美国运通等支付卡组织，这些卡组织也基于3DS 1.0 协议规范发展了自己的标准。由于3DS 1.0 协议所有权为VISA，因此其适用范围有所限制，仅适用于欧洲国家及其监管体系，在欧洲推广较为成功。

图1 3D-Secure 1.0 协议流程图

二是仅支持持卡人基于浏览器的支付。3DS 1.0协议推出于2001 年，移动支付尚未出现，持卡人主要是通过浏览器来完成网络支付。随着智能手机、移动支付的发展，需要在移动端等新场景支持对持卡人的身份认证。

三是处理效率低。根据上文介绍的认证流程，对持卡人和商家的身份认证繁琐复杂，用户体验不好，交易成功率也不高。因此，许多持卡人为了交易效率宁愿放弃使用更安全的3DS 1.0 认证服务。

基于以上三个原因，由国际芯片卡标准化组织（EVMCo）牵头，研发了3DS 2.0 协议标准。在组织关系方面，由EVMCo 牵头，使得该协议可以应用于更多国家和地区，兼容不同的监管规定。在硬件支持方面，3DS 2.0 标准不仅适用于浏览器，而且提供基于APP 的支付协议标准，满足了移动支付时代的需求。在处理效率上，提供了平滑型、挑战型两种身份认证模式，有效提升了对持卡人身份认证的效率，改善了用户体验。

2 3D-Secure 2.0 协议的工作原理

3DS 2.0 标准包含三个域：发卡域（Issuer Domain）、收单域（Acquirer Domain）和交互域（Interoperability Domain），并根据ACS 的风险评估，提供平滑型（frictionless）和挑战型（challenge）两种认证信息流模式。3DS 2.0 标准支持基于App 的身份认证与基于浏览器的身份认证两种模式，其中基于App 的身份认证是2.0 版本的一大进步。因此，本文以基于App 的3DS 2.0 身份认证协议为例，介绍该协议的工作原理。

2.1 3DS 2.0 协议的组件

2.1.1 收单域组件

3DS 客户端（3DS client）：一项面向消费者的组件，安装在消费者的设备上，允许消费者与3DS请求方交互以启动3DS 协议。在基于App 的模型中，3DS 客户端是集成在请求方应用中的3DS SDK，用于和持卡人互动。该SDK 向持卡人展示UI，从用户设备中收集安全信息，支持ACS 对用户挑战认证流程，并保护持卡人的认证信息流。

3DS 请求方（3DS Requestor）：产生3DS 认证请求的组件。以支付认证为例，3DS 请求方指的是电商网站（电商App）。

3DS 服务器（3DS Server）：3DS 服务器是3DS请求方环境与DS 之间的功能接口，从请求方环境中各组件处收集必要的认证数据，并生成认证请求信息，发送给DS。

3DS 请求方环境（3DS requestor environment）：3DS 请求方环境包括3DS 客户端、3DS 请求方和3DS 服务器，均由3DS 请求方控制。该环境负责收集认证请求信息中所需的相关信息，包括持卡人账户信息、商户风险指标、请求方身份认证信息、支付信息、非支付信息和持卡人信息等。

收单方（Acquirer）：一般为某家金融机构，与商家建立关系，接受支付卡交易。收单方同时支持商家参与3DS 协议。经过3DS 安全身份认证后，收单方同时履行其传统的金融机构职责，接受商家的支付授权请求并提供授权回复，将完成的交易提交到结算系统。

2.1.2 交互域组件

目录服务器（Directory Server，DS）：认证3DS服务器和ACS，作为3DS 服务器和ACS 之间沟通的桥梁，为二者之间的信息提供路由服务。此外，目录服务器还提供校验和记录信息的功能。

目录服务器认证中心（Directory Server Certificate Authority，DS CA）：为3DS SDK 生成DS 公钥，用于对持卡人信息加密。同时，DS CA 为3DS 组件生成传输层安全（Transport Layer Security，TLS）证书。

授权系统（Authorization System）：在用户认证后，授权系统执行传统功能，从收单方接受支付授权请求，发送至发卡方，然后为收单方提供授权回复。同时，授权系统为收单方、发卡方提供清算和结算服务。

2.1.3 发卡域组件

持卡人（Cardholder）：支付卡的所有人，在3DS 2.0 协议中，身份认证由持卡人发起。

消费者设备（Consumer Device）：需支持安装运行3DS App 或访问3DS 浏览器。

发卡方（Issuer）：一般为一家金融机构，向持卡人发行一张或多张信用卡。

访问控制服务器（Access Control Server，ACS）：包含身份认证规则，一般由发卡方控制。

2.2 3DS 2.0 协议的工作流程

如图2 所示，由于挑战型3DS 2.0 协议是在平滑型3DS 2.0 协议的基础上，增加了一部分挑战流程，因此本文以基于App 的挑战型协议为例，介绍3DS 2.0 协议的工作流程。

图2 3D-Secure 2.0 协议流程图

启动：由持卡人在消费设备端发起一场交易。持卡人为认证提供一系列必要的信息（包括卡号、消费者信息等）。

（1）由3DS 请求方环境收集必要的3DS 安全信息，提供给3DS 服务器。由SDK 对用户和消费者设备的敏感信息加密，发送给3DS 服务器，3DS根据收到的信息生成认证请求消息（AReq）。

（2）3DS 服务器发出认证请求消息，经过DS路由，转发给ACS。DS 将认证请求消息中SDK 加密的数据信息解密后，放入认证请求消息中的相应字段，并转发给对应的ACS。

（3）ACS 根据认证请求消息评估持卡人身份，并通过DS 向3DS 服务器反馈认证应答消息（Ares）。在挑战型框架内，ACS 可以决定要求持卡人与ACS之间进一步交互，以验证持卡人的身份。

（4）3DS 服务器将认证应答消息中关于认证结果的信息发往请求方环境，并通知持卡人。

（5）对于平滑型架构，此时持卡人已经获得了身份认证成功与否的回应，相应的身份认证流程已经结束。对于挑战型架构，认证应答消息中可能包含三类结果：验证通过（Y）、验证未通过（N）、需要进一步交互（挑战流程，C）。对于认证应答消息要求进一步交互流程的，执行以下流程。

（6）3DS 客户端（SDK）如果愿意接受进一步的身份认证流程，则生成挑战请求消息（CReq），并根据认证应答消息中获得的ACS URL 发送给ACS。

（7）ACS 收到挑战请求消息后，设置相应指标，与客户端通过一对对挑战应答消息（Cres）和挑战请求消息（CReq）来完成进一步验证过程。其中，挑战应答消息内包含要求持卡人在SDK 提供的UI中输入验证信息的内容，如验证码、预留消息等。

（8）ACS完成认证后，发送结果请求消息（RReq）给DS，再由DS 路由给3DS 服务器。该消息中包含了认证值（Authentication Value，AV）。

（9）3DS 服务器回复结果应答消息（RRes），经DS 路由转发给ACS。

（10）至此，3DS 2.0 身份认证流程完成。接下来，商家与收单方进行授权交换。若符合要求，商家、收单方或支付处理器可以提交一个标准授权请求。收单方可通过支付系统与发卡方完成支付授权，并将授权结果返回商家。

平滑型认证流程就是在上述工作流程的基础上省去了挑战流程。具体来说，在执行了上述（1）～（4）的步骤后，3DS 的身份认证就完成了，之后执行步骤（10），由收单方与发卡行完成支付授权，并将授权请求返回商家。可以看出，对于平滑型认证流程，持卡人无须进一步与ACS 交互，无须进一步提交相关认证信息，对持卡人而言用户体验更好，效率也更高。

3 3DS 2.0 协议的安全性分析

3DS 2.0 协议虽然应用简便，只需要商户（请求方）在其App 中集成3DS SDK 即可使用，但通过其巧妙的设计，可以在实现对商家、持卡人的身份认证的同时，保障参与各方的信息安全。

3.1 机密性分析

3DS 2.0 协议中，对于认证请求/应答消息、结果请求/应答消息，各组件之间通信链接的建立是基于标准的TLS 协议的，可以对通信双方实现相互认证，使用的公钥证书由DS CA 签名。

对于挑战请求/应答消息，由SDK 根据ARes消息中ACS URL 发起，通信链接的建立基于标准的TLS 协议，由3DS SDK 对ACS 认证，ACS 的公钥证书由商业性CA 签名。

上述消息的传输都基于标准的TLS 协议：消息的发送方首先向接收方索要公钥，并验证证书；接着双方生成会话密钥，之后通过会话密钥加密通信，保障通信信息的机密性。

对于3DS 服务器、DS 和ACS 之间的通信，由于三者的公钥证书都由DS CA 签名认证，而DS CA可以认为是一家可信机构，因此信息的机密性得以保障。

3DS 2.0 相比3DS 1.0 的一大进步，就是持卡人的相关信息（如账户标识符、卡有效期、设备信息等）对商家而言是不可见的，从而保障了持卡人的隐私。具体的实现方式是由SDK 根据DS 的公钥对持卡人的相关信息加密，该加密方案基于JWE/JWA（取决于DS 公钥是RSA 密钥还是EC 密钥）。持卡人相关信息的解密由DS 完成，由于DS 是可信机构，因此保护了持卡人信息相对于商家的机密性。

3.2 不可抵赖性和完整性

3DS 2.0 协议提供对交易不可抵赖性的保证。对于认证请求消息，在3DS SDK 基于JWE/JWA 的加密时需要持卡人数字签名，因此提供了不可抵赖性的保证。对于每一次交易请求，3DS 服务器、DS、ACS 都会生成唯一的一个序列号，DS 也会记录交易信息，由于DS 是可信的，因此也提供了对交易的不可抵赖性保障。

对于完整性，主要通过消息认证码进行验证，接收方每次接收消息，解密后都可通过消息认证码来保证数据的完整性。

4 3DS 2.0 协议的优势与局限性

如表1 所示，3DS 2.0 协议与1.0 协议相比，在各个方面都有所改进。

首先，与3DS 1.0 协议相比，3DS 2.0 协议支持移动端。本协议支持App 与浏览器两种模式，覆盖PC 和手机等移动设备。在挑战环节，3DS 1.0 协议仅支持持卡人口令这一单一的认证形式，而2.0 版本的协议支持短信验证码、静态密码、预留消息、指纹验证、人脸识别等多项技术，更符合移动端用户的需求。

其次，从用户体验的角度而言，3DS 2.0 协议基于对用户的风险评估，提供了平滑型和挑战型两个认证模式。对于支付行为符合持卡人一贯消费模式的情况，ACS 评估后使用平滑型认证模式，用户几乎无须提供任何额外信息。对于那些不符合持卡人日常消费模式的支付请求，ACS 则会要求持卡人提供额外的信息以验证其身份，如静态密码、验证码等。这些不符合持卡人日常消费模式的情况包括：交易金额与日常消费习惯不符，消费者使用的移动设备发生改变、消费地点与历史不同等。通过这样的模式，3DS 2.0 协议的用户体验较1.0 版本有了很大的提升，使得用户可以在日常消费的场景中实现“无感支付”，同时也通过风险评估和挑战流程保障了持卡人账户的安全。

第三，从保障用户信息安全的角度，3DS 2.0协议保护了持卡人信息的隐私。3DS 1.0 协议中，持卡人的账户、卡有效期等在请求方环境中搜集的信息对于商家而言是透明的，而在2.0 版本中，通过使用SDK 加密、DS 解密的方式，商家无法获得相应的持卡人隐私信息，保障了持卡人隐私。

第四，3DS 2.0 协议作为一项国际芯片卡标准化组织牵头起草的协议，可以适用于更多国家和地区，适合不同的监管体制，较1.0 协议的应用领域更为广阔。

3DS 2.0 协议与1.0 协议一样，都是一个中心化的协议，依赖于目录服务器DS 来运行。在协议中，我们认为DS 是一个可信的第三方，独立于各发卡行。所有的商家和发卡行都需要在DS 处注册，也起到了对商家和发卡行身份认证的功能。DS 负责对SDK 加密的持卡人信息的解密，也检查认证请求消息、认证应答消息、结果请求消息、结果应答消息的合法性。因此，DS 运行的稳定性和安全性对于3DS 2.0 协议而言是至关重要的。此外，作为一个国际化的平台，DS 所需处理的交易量也是十分巨大的，对DS 的性能要求也较高。

表1 3DS 2.0 协议与3DS 1.0 协议对比分析

5 3DS 2.0 协议的影响

首先，3DS 2.0 协议作为EMVCo 牵头推出的一项标准化协议，有助于规范国际信用卡支付交易流程，规范不同卡组织间的身份认证和交易结算方式，从而支持跨境支付业务、跨行支付业务的开展。

其次，支持3DS 2.0 协议有助于实现金融监管。3DS 2.0 协议中，所有交易相对于目录服务器DS 而言都是透明的。因此，作为金融监管机构支持建设的DS 可以在反洗钱以及实现穿透式监管等工作中起到更大的作用。

第三，3DS 2.0 协议是一项高效的、可信的安全协议，实现了对持卡人、商户的验证。只有在DS 注册过的合法商户才能应用3DS 2.0 协议，从而帮助持卡人规避了虚假的商户，实现了反欺诈的作用。

第四，对于中国市场而言，目前中国消费者对于信用卡的依赖性不高，中国信用卡渗透率远低于国际水平，消费者主要依靠支付宝、微信支付等新的互联网支付工具。将3DS 2.0 协议应用于中国的支付市场，不仅可以规范银行间的支付认证，也有助于规范互联网支付，实现全面的穿透式监管。

6 3DS 2.0 协议的其他应用

3DS 2.0 协议虽然是为了支付卡身份认证而设计的，但也可以应用于其他领域的身份认证。从安全性角度，3DS 2.0 协议由消费者（用户）本人发起；从客户隐私角度，3DS 2.0 协议保护了持卡人的隐私安全；从效率和用户体验角度，3DS 2.0 协议通过平滑型、挑战型两种模式，保障了认证效率，提供了良好的用户体验；从监管角度，通过DS 参与身份认证全流程，实现了监管机构的穿透式监管。

因此，除了支付卡领域，在其他一些需要保护用户隐私、保障认证效率、实现穿透式监管的领域中，设计身份认证协议时也可以参考3DS 2.0 协议的设计思路。由于3DS 2.0 协议中最关键的就是要有一个可信的、权威的第三方DS，因此本协议的思想适用于一些强监管的应用领域。例如，对个人保险信息、医疗信息、征信信息的查询中，对个人的身份认证即可应用3DS 2.0 协议的思想；对企业的产权信息、公证信息、抵押信息的查询中，对股东的身份认证也可应用3DS 2.0 协议的思想。

7 结语

本文对EMVCo 于2016 年推出的3D-Secure 2.0协议标准的技术特点等方面作了详细的综述介绍。首先，本文通过对3DS 1.0 协议的介绍，分析其不足之处，介绍了3DS 2.0 协议的研究背景。其次，本文从构成组件和工作流程两方面介绍了3DS 2.0协议的工作原理。本文从机密性、完整性和不可抵赖性等角度分析了3DS 2.0 协议的安全性能。接着本文将3DS 2.0 协议与其1.0 版本相比较，分析了其在技术上、体验上、组织上的进步，并分析了本协议应用的局限性。最后，本文对3DS 2.0 协议的其他应用领域进行了展望。