CN108027926A

CN108027926A - 基于服务的支付的认证系统和方法

Info

Publication number: CN108027926A
Application number: CN201680054476.0A
Authority: CN
Inventors: C·拉杜
Original assignee: Mastercard International Inc
Current assignee: Mastercard International Inc
Priority date: 2015-07-17
Filing date: 2016-06-13
Publication date: 2018-05-11
Anticipated expiration: 2036-06-13
Also published as: JP2018522353A; US11120436B2; CN108027926B; ZA201708474B; WO2017014863A1; EP3326132A4; EP3326132A1; US20210365938A1; US20170017957A1

Abstract

一种采用双因素认证机制执行支付交易的方法。该方法包括利用具有在其中编码的秘密密钥的密码功能来参与密码处理。密码功能存储在计算设备中。秘密密钥充当第一认证因素。该方法进一步包括在执行支付交易中使用第二认证因素。

Description

基于服务的支付的认证系统和方法

相关申请的交叉引用

本申请要求2015年7月17日提交的美国专利申请号14/802,210的优先权，其内容通过引用全部合并于此。

背景技术

例如信用卡账户和借记卡账户等支付账户得到了广泛使用。在访问支付账户的一个常规方式中，账户持有者在零售店的销售点呈递塑料卡。销售点设备从该卡读取账户信息(例如，经由磁条或通过与卡中的集成电路的无线通信，或经由卡上的电触点)并且使用从卡读取的信息发起支付账户交易。

支付账户在电子商务中也被广泛使用。例如，账户持有者可以使用个人计算机或智能电话来访问商户的网上商店网页。在挑选购买的商品并且然后选择“结账”后，提示账户持有者将他/她的支付账户信息输入到下载到他/她的计算机(或智能电话)的数据输入屏幕中。商户的电子商务主计算机然后使用由账户持有者输入的信息来发起支付账户交易。

考虑到支付账户的许多用户可能有不止一个这样的账户，提出了所谓的数字钱包。根据一个类型的所提议协定，钱包服务提供商(WSP)为大量用户维持数字钱包。每个用户在他/她的数字钱包中登记他/她的支付账户中的一些或全部，并且WSP将对应的信息存储在专用于相应用户的数据分区中并且从而形成他/她的数字钱包。当用户试图在电子商务购物交易结束时结账的时候，给予用户在钱包服务提供商处访问他/她的钱包的选项。经由用户的计算机/智能电话之间的数据通信，商户的电子商务主计算机和WSP的计算机，对用户呈现选择他/她登记的支付账户中的一个以供在当前电子商务交易中使用的选项。这可能只需要用户付出很少的努力。一旦用户从他/她的数字钱包选择期望的支付账户，商户就能够使用对应的账户信息以使用用户选择的账户来发起支付账户交易。该类型的协定可以对用户/网购者提供很大便利，因为这使他/她从输入支付账户信息细节(作为电子商务交易的部分)中摆脱出来。同时，用户有在各种支付账户之间选择的选项，并且不需要将他/她的支付账户信息委托存储在商户的电子商务计算机上。

对数字钱包的另一个类型的提议基于启用支付的智能电话或相似的移动设备。可以允许用户将对于若干不同支付账户的信息输入启用支付的智能电话，来代替仅将一组支付账户凭证存储在启用支付的智能电话中。智能电话运行钱包应用，其管理用户对智能电话中存储的支付卡账户信息的访问。对应于智能电话中的钱包功能的账户信息可以存储在智能电话内所谓的“安全元素”(SE)中。在销售点，用户经由智能电话用户界面与智能电话钱包应用交互来选择支付账户中的一个，对于这些支付账户的信息存储在智能电话中。智能电话然后将对于所选支付账户的信息经由NFC(近场通信)或其他标准通信协议无线传送到销售点终端。例如，智能电话可以运行支付账户app(应用程序)，其在它与销售点终端的交互中仿真IC支付卡。销售点终端进而基于它从智能电话接收的支付卡账户信息发起支付卡账户交易。

还提议远程仿真智能电话的SE功能，由此对提供数字钱包功能性的智能电话潜在地降低硬件成本和复杂性。SE在移动网络运营商(MNO)或设备制造商的控制下，因此致使WSP根据MNO或设备制造商来托管卡或卡的发行商。

商业考虑以及在一些司法辖区的法规要求高度安全地保护用户对他/她的数字钱包的访问以免受未经授权的使用的影响。同时，其他商业考虑要求基于当前现有技术平台和分配系统并且没有对例如设备制造商和移动网络运营商(MNO)等方施加繁重或昂贵要求的情况下容易且经济地设立和实行安全措施。也许最重要的是在实施钱包交易中提供简单明了的用户体验的可取性，同时仍遵循适当级别的安全措施。

附图说明

本发明的一些实施例的特征和优势以及实现这些实施例所采用的方式在考虑本发明的下列详细描述结合附图来看时变得更显而易见，附图图示优选和示例性实施例并且不一定按比例绘制，其中：

图1是图示常规支付系统的框图。

图2是图示根据本发明的一些方面提供的支付系统的框图。

图3是图示可以作为图2的系统的一部分并且根据本发明的一些方面提供的计算机系统的框图。

图4是可以结合图2的系统中的支付交易一起使用的移动设备的框图。

图5是示意性地图示如在图2的系统中实现的认证功能性的图。

图6是可以在图2的系统中的用户设备中实现的白箱密码法的图。

图7是示意性地图示用于向用户设备预备认证凭证的常规方法的图。

图8是图示根据本发明的一些方面用于预备认证凭证的方法的图。

图9是图示用于实现图2的系统中的认证规程的架构的图。

图10是图示根据一些实施例用于认证凭证预备的方法的图。

图11是图示根据其他实施例用于认证凭证预备的方法的图。

图12是图示在图2的系统的一些实施例中用于处理用户和设备认证的结构和过程的图。

图13是图示为了图2的系统中的认证过程而生成一次性密钥的过程的图。

图14是示意性地图示在图2的系统中的用户设备中采用的白箱密码技术的图。

图15是根据图2的系统的其他实施例提供用户和设备认证过程的综览的图。

图16是提供图15的过程的初始段的细节的图。

图17是图示与图15的过程的设备认证过程段有关的过程阶段的流程图。

图18是图示在中央服务器中结合安全密钥产生和分发(作为图15的过程的一部分)一起执行的过程段的流程图。

图19是图示与图15的过程的用户认证过程段有关的过程段的流程图。

图20是图示涉及在图2的系统中的用户设备中提供的加密数据库的操作的图。

图21是图示根据一些实施例的图20的加密数据库的示例内容的图。

图22是图示用于使图2的系统中的用户设备的白箱密码功能(function)初始化的过程的流程图。

图23是图示图2的系统中的用户注册过程的图。

图24是图示用于在图2的系统中的用户设备中安装支付功能性的过程的图。

图25是图示在钱包服务器中结合图2的系统中用户设备中的支付应用的初始化一起执行的过程段的流程图。

图26是图示在用户设备中结合涉及的关于图25的支付应用的初始化一起执行的过程段的流程图。

图27是图示在钱包服务器中结合涉及的关于图25的支付应用的初始化一起执行的另外的过程段的流程图。

具体实施方式

通常并且为了介绍本发明的实施例的概念，对钱包访问/支付交易提供双因素认证机制。该两个认证因素可以包括(a)例如智能电话或个人计算机(PC)等用户设备的用户已知并输入的秘密PIN；以及(b)采用受保护方式安全存储在用户设备中的设备专用密码密钥。第二个认证因素(“你拥有的”)可以仅使用软件安全技术实现，而在用户设备中不包括基于硬件的安全元件并且在用户设备中也没有安装信任的执行环境。在参与钱包访问/支付交易中用户也不需要具有或操作除用户设备之外的设备。

在一些实施例中，设备专用密钥可以在用户设备的支付功能性初始化期间在用户设备中实现的密码功能中编码。可以采用白箱密码技术来对用户设备中的秘密密钥提供适当的安全级别。秘密密钥在支付交易期间在用户设备与钱包服务器之间交换加密数据通信方面可以作为传输密钥而采用，主要是为了导入一次性密钥用于认证(SUK_AU)。

在一些实施例中，可以通过在每一个交易时从钱包服务器向用户设备预备待存储在用户设备中以供在下一个交易中使用的经加密的一次性密钥来提供增强的安全性。从而，存储的一次性密钥在用户设备内提供增强级别的纯软件的“你拥有的”认证因素。

在一个增强的安全体系中，每个支付交易包括设备认证阶段和用户认证阶段。设备认证阶段包括来自用户设备的之前交易的会话密钥对钱包服务器的密码隐藏呈现以及钱包服务对该会话密钥的验证。用户认证阶段包括将对于来自钱包服务器的下一个交易的设备认证会话密钥预备给用户设备以及为当前交易预备用户认证会话密钥。用户认证阶段进一步包括由用户输入秘密PIN，其在用户设备中用于提取会话密钥用于用户认证。用户认证阶段可以进一步包括采用密码隐藏的形式将来自用户设备的数据提交给钱包服务器，以供钱包服务器验证。

本文描述的认证技术可以在支付交易期间提供简单、方便的用户体验。此外，那些技术可以达成对涉及交易和凭证安全性的严格法规要求的遵从。此外，本文描述的各种技术可以允许成本/资源消耗vs.提供的安全程度的有利平衡；本文描述的其他技术可以对针对支付基础设施的甚至十分复杂的攻击提供保护，同时仍然是成本有效的。除其他优势外，本文描述的技术还可以利用商用渠道来向用户设备分发软件，同时避免设备制造商和移动网络运营商(MNO)介入或参与的复杂性或困难性。

通过背景技术的方式，将首先简要描述常规支付系统。图1是图示常规支付系统100的框图。

系统100包括常规支付卡/设备102。如本领域内技术人员所熟悉的，支付卡/设备102可以是磁条卡、IC(集成电路)卡、钥匙链、启用支付的智能电话等。

系统100进一步包括与POS终端106关联的阅读器组件104。采用一些已知方式(根据支付卡/设备102的类型)，阅读器组件104能够从支付卡/设备102读取支付账号和其他信息。

阅读器组件104和POS终端106可以位于零售商店端并且由零售商(即，商户)的营业员操作以旨在处理零售交易。支付卡/设备102在图1中示出为与阅读器组件104和POS终端106交互以旨在执行这样的交易。

收单方(收单金融机构)操作的计算机108在图1中也示出为系统100的部分。收单方计算机108可以采用常规方式操作以从POS终端106接收对交易的授权请求。收单方计算机108可以经由支付网络110将授权请求路由到与支付卡/设备102关联的支付卡账户的发行商操作的服务器计算机112。如同样众所周知的，支付卡发行商服务器计算机112生成的授权响应可以经由支付网络110和收单方计算机108路由回POS终端106。

支付网络的一个众所周知的示例称为“银行网络”系统，并且由本公开的受让人万事达卡国际公司运营。

支付卡发行商服务器计算机112可以由或代表向个体用户发行支付账户的金融机构(“FI”)操作。例如，支付卡发行商服务器计算机112可以执行这样的功能，如(a)接收对要记入FI发行的支付账户的支付账户交易的授权的请求并且对其作出响应；以及(b)跟踪并且存储交易且维持账户记录。

如在图1中描绘的系统100的组件仅仅是处理单个交易所需要的那些。典型的支付系统可以处理许多购买交易(包括同时交易)并且可以包括相当多的支付账户发行商和它们的计算机、相当多的收单方和它们的计算机以及许多商户和它们的POS终端以及关联的邻近阅读器组件。系统也可以包括大量支付账户持有者，他们携带支付卡或其他设备用于通过向POS终端的阅读器组件呈递关联的支付账号来发起支付交易。

在如上文阐述的支付系统100的简要描述中，图示的示例交易是店内购买交易。然而，如本领域内技术人员并且消费者也众所周知的，许多支付账户交易相反关于例如网购交易等电子商务交易进行。对于这样的交易，商户的角色可以由电子商务服务器计算机(未示出)充当，其可以取代图1中示出的组件104和106。从而，电子商务服务器可以发起交易授权请求消息，其在先前的图1的描述中提到。交易也可以涉及例如运行移动浏览器的智能电话或个人计算机、膝上型计算机或平板计算机等设备的用户操作，以旨在与上文提到的商户的电子商务服务器所托管的购物网页交互。之前的句子中所涉及的用户设备的类型可以有效地代替图1中示出的项目102。

图2是图示根据本发明的一些方面提供的支付系统200的框图。(与图1中的情况一样，支付系统在图2中仅从单个交易所需要的组件方面描绘；实际上，并且如下文将论述的，支付系统200可以包括至少一些组件的多得多的实例。)

与图1类似，图2示出如上文涉及的支付网络110和发行商服务器计算机112。在一些实施例中，这两个系统组件可以实质上采用常规方式操作来接收和路由支付账户系统交易授权请求和交易授权响应。

为了简单说明，支付系统200的商户和收单方方面由单个框202表示。商户/收单方框202(即，商户或收单方操作或服务提供商为商户或收单方操作的设备)示出为与钱包开关204通信。该钱包开关204可以在客户向商户指示该客户希望访问WSP来为交易提供支付时从商户/收单方框202接收通信。实际上，钱包开关204可以通过将源于商户的交易细节中继到钱包服务器206而使钱包服务器206进入交易。钱包服务器206的细节将在下文论述。钱包服务器206的显著方面包括它对支付系统200的许多用户的数字钱包208的存储，和其用于提供用户和设备认证服务的功能性，如由图2中框210表示的。后面的功能性可以根据本公开的教导提供，并且在显著方面可以背离之前提出的认证实践。应理解，除充当钱包服务器外，组件202还可以充当远程认证服务器。

对交易的认证可以经由在钱包服务器206/认证功能性210和参与与商户的购买交易的用户所操作的用户/支付设备(标号212)之间实施的规程而发生。在图2中，用户/支付设备212描绘为移动设备，例如智能电话，但在例如其他情形中，用户/支付设备212可以是PC、膝上型计算机、平板计算机或类似物，其经由其浏览器程序用于访问当前交易的电子商务站点。用户设备212的非智能电话示例由框214虚幻表示，其在一些实例中可以代替在图中显式指示的用户设备212。对于图2中图示的特定示例交易，用户设备212示出为经由移动认证app(应用程序)216参与与钱包服务器212的交互215。

钱包服务器206与用户设备212之间的交互215可以包括认证以及从钱包服务器206中存储的用户的数字钱包选择账户。认证可以包括设备认证和用户认证，并且如下文描述的，可以用以相当大或甚至非常高的严格程度操作的双因素认证机制来实现。

如通过图2中的连接218示意图示的，移动app 216可以有效地对商户/收单方202指示对网购“购物车”的支付阶段可能完成，其中购物车总额为用户所知；移动app 216也可以指示用户选择特定钱包品牌作为当前交易的优选支付方法。

值得注意的是对于图2中示出的每个组件，系统200的实际实施例中所包括的这样的组件的实际数量可以大于一。例如，可能有许多参与系统的商户，以及甚至更大数量的个体操作用户设备(就交易认证来对其编程)或其他用户/支付设备。还可能有相当多的收单方和发行商，并且或许有许多钱包服务器并且潜在地不止一个支付网络。如将从上文的常规支付系统100的描述中理解到的，图2中示出的支付系统200可以处理许多交易，其包括同时交易。

在支付系统200的典型配置中，钱包服务器206远离商户且远离用户设备212。

图3是图示如在图2中示出并且根据本发明的方面提供的钱包服务器206的示例实施例的框图。

现在参考图3，钱包服务器206在其硬件方面可以是常规的，但可以由软件控制以促使它如本文描述的那样运作。例如，钱包服务器206可以由服务器计算机硬件构成。

钱包服务器206可以包括计算机处理器300，其操作耦合于通信设备301、存储设备304、输入设备306和输出设备308。

计算机处理器300可以由一个或多个常规处理器构成。处理器300操作以执行下文描述的程序指令中所包含的处理器可执行步骤，以便控制钱包服务器206来提供期望的功能性。

通信设备301可以用于促进与例如其他设备(例如钱包开关204和用户设备212)的通信。例如，通信设备301可以包括许多通信端口和接口用于促进(i)在空中经由一个或多个移动通信网络(未示出)与由支付系统200的许多用户作为用户设备操作的移动设备通信；和/或(ii)通过互联网与PC及类似物通信。

输入设备306可以包括典型地用于将数据输入计算机的任何类型的外围设备中的一个或多个。例如，输入设备306可以包括键盘和鼠标。输出设备308可以包括例如显示器和/或打印机。

存储设备304可以包括任何适合的信息存储设备，其包括磁存储设备(例如，硬盘驱动器)、例如CD和/或DVD等光存储设备和/或例如随机存取存储器(RAM)设备和只读存储器(ROM)设备等半导体存储器设备以及所谓的闪速存储器的组合。这样的信息存储设备中的任一个或多个可以视为计算机可读存储介质或计算机可用介质或存储器。

存储设备304存储一个或多个程序用于控制处理器300。这些程序包括程序指令(其可以称为计算机可读程序代码部件)，其包含钱包服务器206的处理器可执行过程步骤，这些过程步骤由处理器300执行以促使钱包服务器206如本文描述的那样运作。

程序可以包括一个或多个常规操作系统(未示出)，其控制处理器300以便管理和协调钱包服务器206中资源的活动和共享，并且充当在钱包服务器206上运行的应用程序(在下文描述)的主机。

存储设备304存储的程序也可以包括例如用户登记应用程序310。该用户登记应用程序310可以控制处理器300以使钱包服务器206能够处理用户登记钱包服务器206提供的钱包服务的请求。例如，这可以至少部分包括在钱包服务器206上打开用户账户，并且登记许多用户的支付账户以包含在钱包服务器206上为用户提供的数字钱包中。用户的支付卡账户的登记在至少一些情况下可以经由PAN(主账号)，其识别谈论中的支付卡账户和/或可以经由万事达卡国际公司、Visa和美国运通在2013年11月发布的“Payment TokenInteroperability Standard(支付令牌互操作性标准)”中涉及的那类支付令牌。

用户与钱包服务器206交互来建立用户的数字钱包可以例如经由对钱包服务器206所托管的网站的访问。

存储设备304还可以存储钱包维护应用程序312，其控制处理器300以使钱包服务器206能够存储和维护已由用户在钱包服务器206中建立的数字钱包。

另外，存储设备304可以存储程序指令314，例如允许钱包服务器206作为如本文详细描述的远程认证服务器操作所需要的。

存储设备304还可以存储支付交易处理程序316，其控制处理器300以使钱包服务器206能够从钱包开关204对钱包服务器206所涉及的许多交易的钱包账户选择。在一些实施例中，程序314和316的功能性可以在单个程序中组合或可以包含相关程序之间的合作。

存储设备304也可以存储未示出的其他程序，并且钱包服务器206也可以执行这些程序。例如，这样的程序可以包括报告应用，其可以对系统管理员对关于钱包服务器206所执行的活动的报告的请求作出响应。其他程序也可以包括例如一个或多个数据通信程序、网站托管程序、数据库管理程序、设备驱动器等。

存储设备304还可以存储钱包服务器206操作所需要的一个或多个数据库318。这样的数据库可以包括例如用于存储对应于数字钱包的数据和对用户/持卡人维持钱包服务器206中的关联支付账户信息的数据库(在图3中未单独指示)。一个或多个其他数据库-例如，用于认证目的的用户数据库和用于认证目的的设备数据库(未在图3中示出，项目318除外)-可以关于它的认证功能被钱包服务器206所采用，如下文描述的。

如上文指出的，具有互联网连接的许多不同类型的设备(包括智能电话、PC、膝上型计算机、平板计算机等)可以作为基于钱包的支付交易的用户/支付设备而采用。考虑到在许多实例中可以采用例如智能电话等移动设备来担任该角色，值得说明的是这样的设备的方面，如在所附图4中进行的。

图4是可以关于图2的支付系统200中的支付/钱包访问交易使用的移动设备(对于这幅图分配标号400)的实施例的框图。

在一个示例实施例中，移动设备400在其硬件方面可以是典型的智能电话并且在大部分软件方面也是，所不同的是可以对移动设备400适当编程以允许它与例如商户设备并且与如本文描述的钱包服务器206交互。简而言之，移动设备400可以对商户设备识别它自己，并且可以参与关于钱包服务器206的操作，例如设备认证、用户认证、钱包数据的接收和从钱包账户之中选择。这些操作的细节将在下文提供。在任何情况下，现在将提供移动设备400的突出方面的简要综览。

移动设备400可以包括外壳402。在许多实施例中，外壳的前面主要由触屏构成，该触屏是移动设备400的用户界面404的关键元件。

移动设备400进一步包括常规移动处理器/控制电路406，其包含在外壳内。移动设备400中还包括存储/存储器设备或多个设备(标号408)。存储/存储器设备与处理器/控制电路406通信并且可以包含程序指令来控制处理器/控制电路以管理和执行移动设备400的各种功能。如众所周知的，这样的功能包括作为移动语音通信设备经由与移动电话网络(未示出)的交互的操作。另外的常规功能包括作为移动数据通信设备的操作，并且还作为实际上是袖珍型个人计算机经由利用许多应用程序或“app”的编程的操作。(app在图4中的框410处表示，并且实际上可以存储在框408中，以采用无数种方式对处理器/控制电路406编程。)上文引用的移动通信功能由框412表示，并且除经编程的控制功能外，移动通信功能也依赖硬件特征(未单独示出)，例如天线、收发器电路、麦克风、扬声器等。

图4中的框414代表使移动设备400能够采用本文描述的多个方式参与支付系统200的特征。这可以牵涉例如钱包app(有时也称为支付app或支付应用)，其可以具有根据本公开的教导提供的功能性。从下文的论述还将看到，支付功能414可以管理存储/存储器408使得一个或多个专用数据库(在图4中未单独指示)可以维持在移动设备400中。

从前面的论述，将意识到图4中描绘为移动设备400的组件的框实际上可以互相重叠，并且/或在图中未明确示出的框之间可以存在功能连接。

已指出移动设备400可以体现为智能电话，但该假设不意在为限制性的，因为移动设备400备选地在至少一些情况下可以由具有移动通信能力的平板计算机或由其他类型的移动计算设备构成。如上文指出的，其他类型的计算设备根据本发明的方面也可以用作用户设备。

图5是示意性地图示如在图2的系统中的一些实施例中实现的认证功能性的图。

根据本发明的一些方面，在用户设备212或214(实际上在其中具有软件实体)与钱包服务器206的认证/验证功能512(图5)之间提供强大的认证方法。在一些方面，图5中呈现的架构可以遵循是本公开的受让人的万事达卡国际公司发布的DSRP(数字安全远程支付)系统的模型。如本文公开的认证方法可以提供对电子商务支付交易的法规体系(例如，欧洲中央银行体系)的完全遵照，同时还对用户提供方便且简单的体验而不涉及-至少对于每个交易-硬件元件，例如IC支付卡、个人读卡器(PCR)或类似物。相反，在一些实施例中，可仅需要用户在某一场合使用他/她的IC支付卡和PCR，即，在向他或她的数字钱包添加特定卡/支付账户时(例如，为了遵照欧洲中央银行(ECB)关于反洗钱/反恐怖主义融资(AML/CTF)的要求)。在其他实施例中，对用户在关于数字钱包中或钱包交易中支付账户登记的任何场合使用IC支付卡和/或PCR可没有要求。本文公开的认证方法还可以避免依赖复杂的基础设施，像涉及已提议的其他用户认证方法的复杂的基础设施。

图5中图示的架构的一个特征是可以采用便利方式对用户提供强大的用户认证，即在实施购物体验所通过的相同渠道中。例如，可以经由移动设备212中的移动钱包app502提供有“inApp inChannel”认证；或者，如果用户设备是PC 214或类似物，inAppinChannel认证可以经由与在PC 214上运行的操作系统兼容的应用程序。如在504处指示的，移动钱包app 502可以包含根据该公开的教导提供的以实现移动设备212中的“纯软件”认证令牌的认证功能性504。

备选地，根据本发明的方面，在移动设备212或PC 214中，可以提供“inBrowserinChannel”认证功能，例如，经由浏览器扩展506或在浏览器内运行的网页(例如，PC浏览器508或移动浏览器510)。

将注意认证功能性504/浏览器扩展506根据情况示出为与钱包服务器206的认证/验证功能性512交互，其也可以包含在提供钱包服务中的自定义“存档卡(CoF)”功能性514。

随着使用纯软件认证令牌，避免在以下中可能另外涉及的潜在不便或困难，这是可能的：(a)在MNO提供的SIM卡上托管认证令牌(即，不需要获得与MNO的合作)；(b)为了支付安全的目的而提供专用硬件安全元件(SE)(即，获得与设备制造商的合作的需要减少或不需要这样的合作)；或(c)在设备中包含信任执行环境(TEE)电路(获得与设备制造商的合作的需要再次减少或不需要这样的合作)。

可以用于提供“防篡改”来支持纯软件认证令牌的实现的技术可以使用静态和动态白箱密码(WBC)，如例如在图6中图示的(其中上部分602图示静态WBC并且下部分604图示动态WBC)。

在静态WBC实现(部分602)中，秘密密钥K是固定的，但在分组密码结构中编码使得它无法被攻击者逆向工程化。它在钱包app的编译时与钱包app的实现成为一体。

图6的下部分604示出了动态白箱(DWB)实现，其中密钥K可以在每一个调用时变成钱包app。在这样的实施方式中，动态密钥K作为参数来传递，但它在通过传送未受保护的环境之前首先经过安全变换。可能的变换类型包括：

●未加密的t变换o(K)，其中安全性依赖变换自身的保密性-o(K)可以视为模糊函数。这可以实现为具有秘密编码/解码表的模糊变换。从而o^-1(K)是在经过不安全的环境之后允许在目的地恢复会话密钥的逆模糊变换。

●利用通用目的加密/解密算法eR(K)的加密。生成的实施方式使用密钥R，其每个用户/移动设备是唯一的、用于在生成它之后对动态密钥K加密并且在DWB(E)原语(primitive)内部对它解密以供加密算法E使用。

对于每个设备中的WBC构造，编码可以与分发给(例如，从“app商店”)每个用户设备的相同，但后来特定用户设备上的WBC构造可以用对每个用户专用的会话传输密钥来初始化。从而，WBC构造加上执行特殊化WBC所在的硬件/软件平台的组合可以被看作“你拥有的”(即，所有权认证因素)。

可以用于支持对认证令牌的防篡改的另一个技术可以基于如在下文的图8中图示的预备方法，并且可以用白箱密码技术来构建。初始参考图7，其代表典型的预备方法，一旦认证且在认证(如在702处指示的)之前预备参数/密钥用于在硬件防篡改认证令牌704中多次存储和使用。对于认证的多个后续使用与存储的参数一起在图7中的706处指示。

相比之下，根据该公开的教导，并且如在图8中图示的，用于认证的秘密参数/认证密钥由钱包服务器认证服务功能性-在“云”中-新生成并且在认证本身之前的每个会话中提供，如在图8中的802处指示的。另外，秘密参数/认证密钥可以受PIN或密码保护，这从而提供-“了解”型/“你知道的”的第二个认证因素。

再进一步，在一些实施例中，会话认证密钥从不以纯文本在执行环境内显示。相反，会话密钥与在动态白箱密码原语内的钱包app中使用它的认证功能一起置于沙箱中。

为了满足一些法规要求或安全目标，可以明智地在向钱包服务器中的数字钱包添加卡/支付账户的操作阶段期间使用单独用户认证基础设施，但之后关于使用该账户数据的交易，可不必使用这样的单独用户认证基础设施。

图9是图示用于实现图2的系统中的认证规程的架构的综览的图。该架构可以适合于在基于服务器的DSRP模型中提供强大的用户认证服务，并且包含在软件中专门实现的双因素认证，如标识为本文之前的论述中的优选目标。图9中图示的机制可以在可以托管在PC、平板计算机、智能电话等的不安全存储器中的纯软件环境中实现。图9中示出的元件在下文根据OATH(开放认证倡议)框架来解释。

现在参考图9，认证令牌(标号902)可以在用动态白箱密码创建的软件防篡改环境中实现有抗密码性单向函数(OWF)904。认证方法(标号906)可以用客户端应用910利用挑战/响应协议908来实现。客户端应用901可以是认证令牌902中的OWF 904与钱包服务器206中的认证验证服务器功能912之间的透明代理。客户端应用910可以例如实现为移动钱包app或与常规PC操作系统兼容的PC型应用；或在浏览器扩展或服务于PC/平板/移动浏览器的HTML5网页上实现。

令牌接口(标号914)可以是例如专有API(应用编程接口)-标号916-其仿真例如EMV协议(和它的APDU-应用协议数据单元)，或备选地可以是允许实现认证方法906的任何其他API。

Web服务可以经由钱包服务器206实现以在被认证验证服务器功能912正确认证后提供用户对客户数据库918中他/她的结账数据/存档卡的访问，其中服务器功能912已验证从认证令牌902传达到服务器功能912的“认证器”(即，数据实体)。

图9的架构中的预备和管理服务可以包括与钱包服务器206关联的令牌管理实体920。该令牌管理实体可以对系统中登记的每个认证令牌902生成并且存储唯一令牌主密钥供认证(TMK_AU)。预备和管理服务可以进一步包括令牌凭证实体922，其利用每个认证会话从令牌主密钥TMK_AU导出新会话密钥用于认证-指示为SK_AU。

在后续论述中，将存在用于实现认证令牌902和认证方法906的两个或以上特定机制的描述。

在图10中图示根据该公开的教导的相对简单的用户认证模型。图10的模型包括预备(标号1002)密钥和/或其他参数用于用户认证，加上用户认证本身(标号1004)。该模型的描述包括下文的图12-14的论述。

在图11中图示根据该公开的其他方面具有增强安全性特征的认证模型。图11的模型可以防止广泛攻击，例如用户假冒、设备身份被盗、增强式加密等。后面的模型包括预备(标号1102)密钥用于用户认证，从而进一步预备(标号1104)密钥用于在下一个用户认证会话时的设备认证以及设备和用户两者的认证(标号1106)，其中前面的认证使用来自之前会话的密钥并且后者使用来自当前会话的密钥。图11的模型的描述包括下文的图15-19的论述。

图12是图示认证令牌(基于软件的)1202与认证验证服务器1204之间交互以实现在上文关于图10简要涉及的认证模型的图。

继续参考图12，现在将描述认证令牌1202的结构。

认证令牌1202可以包括认证器发生器，其可以采取抗密码性单向函数(OWF)1206的形式。充当认证器发生器的OWF 1206产生认证器(提交给认证验证服务器1204的数据实体)以供在评估用户的真实性方面使用。OWF/认证器发生器1206可以根据以下的公式计算认证器：

认证器＝OWF[SK_AU,令牌简档](挑战，会话数据，令牌数据)

OWF可以用如在该公开后来的部分处描述的数学函数f来实现。函数可以用密码密钥和令牌简档来参数化，如下文描述的。OWF取认证数据作为输入，并且产生认证器。认证数据的示例的细节在该公开后来的部分在表中描述。在一些实施例中，认证数据总是包括由认证验证服务器产生的新的挑战值连同从在客户端与认证验证服务器之间建立的连接收集的会话数据。

之前的段落中涉及的令牌简档可以包含对认证令牌的个性化数据，其对于特定用户是专用的。该个性化数据可以包括令牌标识号(TIdN)，其可以是标识在钱包服务器和/或钱包服务器的运营商的技术和管理界线内所述的认证令牌的唯一数字。

个性化数据可以进一步包括有效日期，其是令牌在认证系统中将停止被认为有效时的日期。

个性化数据可以进一步包括令牌属性，其可以描述这样的特定条件(例如，它从哪个类型的设备生成、在哪个类型的交易中可以使用它，等)，在该特定条件内认证令牌可以视为用于验证。

在一些实施例中，可以存在两个不同类型的令牌简档。例如，可以存在令牌简档“TP-MA”，其可以对应于具有认证令牌特征的移动钱包app并且可以用TIdN1来指定；并且可以存在令牌简档“TP-BE”，其可以对应于具有认证令牌特征的浏览器扩展或网页并且可以用TIdN2来指定。

再进一步，认证令牌可以包括密钥容器，其可以用于利用密码密钥对OWF的参数化。密码密钥由图12中的标签SK_AU(标号1208)表示并且可以称为认证会话密钥。

作为使密钥容器永久存储“卡主”密钥(其可以在每一个交易时多样化)的备选方案，相反在每个用户认证会话开始时钱包服务器的令牌凭证服务认证可以对密钥容器提供新的一次性密钥(SUK_AU)用于认证(如在上文在图8和10中示意性图示的)。这可以是解决在移动(钱包)app或浏览器扩展/网页的纯软件环境中潜在缺乏安全性的合适方式。

在一些实施例中，SUK_AU-如由令牌凭证服务产生的-可并未被OWF直接用作密码密钥，而相反可以与由用户键入客户端软件的PIN面板软件仿真器部分内的PIN或密码结合，从而生成会话密钥SUK_AU。

在一些实施例中，OWF可以具有如下文描述的特性。

抗密码性单向函数f可以具有下列特征：(a)f的描述是公开已知的；(b)给出输入x，容易计算f(x)，而对于在f的范围内的所有图像，得到输入x使得y＝f(x)在计算上不可行(该特征有时叫作抗第一原像性)；(c)即使存在论证x≠x’(对其f(x)＝f(x’))，给出一对(x,f(x))，找到x’使得f(x)＝f(x’)在计算上也不可行(该特征有时叫作抗第二原像性)；(d)找到任何论证x≠x’(对其f(x)＝f(x’))在计算上必定不可行，在该情况下函数据称是防碰撞的。

这些特征中的一个或多个在预防外部攻击者方面可趋于有效，这些外部攻击者可能只观察(x,f(x))对而无法影响x的抉择。这些特征中的一个或多个在预防内部攻击者(例如不诚实的用户)方面可趋于有效，这些内部攻击者随后将试图放弃用户实际上经过认证的交易。

在一些实施例中，OWF可以选择为未加密函数或具有对称密钥的加密函数。

在一些实施例中，作为未加密函数的OWF可以实现如下。

函数f可以选为未加密函数，即，其中没有使函数参数化所需要的密码密钥。用户的秘密信息(无论是会话密钥还是直接是密码)可以在函数f的论证中直接传递，即，

认证器＝f[SK_AU](挑战，会话数据)＝H(SK_AU，挑战，会话数据)

通常，在该类别中，可以选择哈希函数。使用哈希函数用于实现实体认证服务的基本思想是将任意长的属性集的真实性转移为它的哈希代码的真实性。

未加密的OWF的两个示例是：(1)由OATH联盟提议的基于HMAC的一次性密码算法[HOTP]；以及(b)基于SHA-256的哈希函数。

在一些实施例中，作为秘密对称加密函数的OWF可以实现如下。

当函数f是消息认证代码(MAC)时，数据的真实性依赖秘密密钥SK_AU的保密性和真实性，这保证了数据的来源。

秘密对称加密函数的一个常用示例是在众所周知的EMV支付交易协议中使用的函数。这通常称为应用密码，其一般缩写为AC：

认证器＝AC＝MAC[SK_AU](挑战，会话数据)

这是具有56位的对称密钥的基于DES的MAC，通常称为会话密钥SK_AC。这是从每个应用的主密钥(称为MK_AC)的密钥导出的结果。

用户设备的客户端、认证令牌和认证验证服务器可以参与挑战/响应认证方法来履行用户认证服务。这可以执行如下。

客户端可以提交用户_ID，其唯一标识钱包服务器的用户数据库中的用户。客户端还可以提交设备_ID，其唯一标识设备数据库中的用户的设备；即，可以唯一标识由用户用于对钱包服务器认证的设备。

基于用户_ID/Token_ID，认证验证服务器检索令牌主密钥用于认证(TMK_AU)并且使用它来对认证协议的当前执行生成用户认证会话密钥(SK_AU)。会话密钥将用于验证用户设备提供的认证器。

认证验证服务器产生新的挑战值(例如，随机或伪随机生成的值)并且收集通过连接与用户设备的客户端交换的当前认证会话数据。该数据的全部都提交给客户端，客户端向认证令牌发出认证命令(其中挑战和会话数据作为参数)的需求。

客户端还对用户设备提供PIN面板软件仿真器，使得提示用户键入用户的秘密知识，即PIN或密码。

在用户键入PIN/密码之后，在相同会话期间-从钱包服务器的令牌凭证服务接收的供认证的一次性密钥(SUK_AU)可以被解密来产生认证会话密码(SK_AU)以供在产生认证器中使用。在挑战/响应认证机制中认证器要作为对认证验证服务器的挑战的响应来传送。

如由认证令牌计算的认证器通过用户设备的客户端传送到认证验证服务器。

认证验证服务器可以检索之前导出的会话密钥SK_AU来计算在会话数据和挑战上的authenticator_witness并且将该authenticator_witness与从用户设备接收的认证器比较。如果authenticator_witness与认证器匹配，认证视为成功并且允许用户访问包含用户的存档卡钱包数据的钱包分区。

认证器计算可以采用下列方式执行。

认证器发生器使用SK_AU来计算待发送给钱包服务器的令牌交易处理实体的认证器AU_Cr以供认证验证服务器验证：

AU_Cr＝MAC(SK_AU)[Auth_Data]

认证数据(Auth_Data)可以例如包括在下列表中示出的数据元素中的一个或多个(具有它们的配置)：

金额，经授权(数值)	‘000000000000’	6
			金额，其他(数值)	‘000000000000’	6
终端国家代码	‘0000’	2
			终端验证结果	‘0000000000’	5
交易货币代码	‘0000’	2
			交易日期	‘000000’	3
交易类型	‘00’	1
			不可预知的数字	如由钱包服务器发送的RAND	4
应用互换简档	在MPP精简版[AU]中个性化的AIP	2
			应用交易计数器	保持在MPP精简版[AU]中的ATC	2
卡验证结果	‘A50000000000’	6

在一些实施例中，根据认证验证服务器是否提供金额和交易货币代码，那些数据项在Auth_Data中可以呈现有不同于零的值。

在一些实施例中，Au_Cr可以在对第一生成AC命令的响应的标签‘9F26’中发送。

在一些实施例中，MAC功能可以实现为如对EMV支付交易协议定义的EMV密码原语。

图13是图示根据一些实施例的认证会话密钥的导出和安全传输的图。对于图13中图示的过程/计算的一个输入是WSP_MK_AU(标号1302)，其是认证服务的专用系统主密钥，如由钱包服务提供商维持的(即，由钱包服务器的运营商提供)。

对于具有专用TIdN的每个认证令牌，WSP_MK_AU系统密钥对用于认证的令牌主密钥(TMK_AU；标号1304)而多样化，可以从钱包服务器提供商为认证目的而保留的与例如令牌化/数字化服务一致的特殊BIN(银行标识号)范围分配该专用TIdN。在多样化数据中也可以包括令牌属性。

用于向钱包服务器认证用户的认证会话密钥SK_AU可以通过使用认证令牌的认证器交易计数器(ATC；标号1306)作为多样化器而从TMK_AU生成。ATC在每个认证会话时递增，并且认证验证服务器使该值保持与对每个用户_ID/设备_ID的认证令牌同步。在一些实施例中，可以使用已知的EMV CSK会话密钥算法。

SK_AU与哈希值结合来生成一次性密钥用于使用如上文描述的函数FnH来认证(SUK_AU)。在一些实施例中，SUK_AU而不是SK_AU本身被传送到认证令牌。

相应地，认证令牌接收的SUK_AU将与哈希值结合来使用函数FnH采用下文描述的方式检索初始SK_AU。

哈希值可以根据以下公式计算：

HASH＝H1[RAND，H2(WSP_AU_PIN，SALT)]

其中：

●WSP_AU_PIN是用户使用来对他/她的结账资源/CoF认证的4-6位数长PIN。WSP_AU_PIN可以视为仅用户知道的“解密”密钥，其作为他/她的允许恢复待用于产生认证器的SK_AU(来自SUK_AU)的知识的证明。

●SALT是在对每个用户的PIN注册或PIN改变时自动生成的多样化器。它用于增加对钱包服务器的“散布式PIN”表的蛮力攻击的难度。“散布式PIN”表包括对于用户数据库中每个用户的记录的字段H2(WSP_AU_PIN,SALT)。

一次性密钥SUK_AU从令牌凭证922(图9)传送到用户的移动app或浏览器扩展/网页。在该方面，用AES 256-E加密算法(图13，标号1308)使用对用户设备特定且指示为KTR(传输密钥；标号1310)的传输密钥根据以下来对SUK_AU加密：

ESUK＝AES256-E[K_TR](SUK_AU)

在一些实施例中，传输密钥K_TR未在令牌库中通过对钱包服务提供商特定的导出过程生成；相反，传输密钥可以在初始化阶段期间由用户的移动app/浏览器扩展/网页随机生成并且安全发送到钱包服务器且在用户数据中更新为传输服务密钥。

在一些实施例中，用于产生认证会话密钥的安全参数可以如下：

□H2＝SHA-256

□H1＝在SHA-256的4个字节上经截短的输出

函数FnH(nKey，H1)用于支持SUK_AU从SK_AU密钥和4个字节的H1值的下列转化。

输入是：

□H1表示为十六进制值(多至8个半字节)和16字节数据块

□nKey指示待变换的密钥的16字节数据块

输出是16字节数据块。

函数编码如下

for(i＝0；i＜H1Length；i++)

{

nKey[i]^＝(sH1[i]＜＜1)；//Left part of the key

nKey[(i+8)]^＝(sH1[i]＜＜1)；//Right part of the key

}

其中：

□^是XOR运算符

□＜＜1是左移一位(基于字节的)

□[i]是变量的第i个字节

□H1Length是H1的长度(＝位数＝8)

□sH1是H1值的ASCII表示

该公开的下列段落涉及认证会话密钥的预备。

钱包服务器206的预备服务器功能的令牌凭证块922(图9)可以使用带有加密的安全通道来对认证令牌提供SUK_AU用于每一个认证会话的执行。

为此，每个认证令牌可以用特定传输密钥K_TR来初始化，使得认证令牌能够使用AES256-I分组密码采用解密方式正确地对如从预备服务器接收的经加密ESUK值解密。

SUK_AU＝AES256-I[K_TR](ESUK)

该公开的下列段落涉及认证器计算的动态白箱密码实现。

如上文论述的，在一些实施例中，认证器(AU_Cr)的计算的实现可以在“app”中执行。app可以是：

●从应用商店下载的通用移动交易应用；

●从web商店下载的浏览器扩展；

●从安全服务器下载的HTML 5网页。

为了实现app的纯软件安全，可以使用两个软件组件的叠加，如在图14中呈现的。在图14中示出的布置中，在认证令牌中利用组合的灰箱和DWBC(动态白箱密码)来执行认证器计算。灰箱(标号1402，图14)和DWB 1404(图14)方面在下文描述。

在创建整个app时，可以通过软件模糊使用灰箱法用于保护整体软件、密码构造(包括DWB)和敏感操作参数，像当存储在app中时的SALT以及在键入客户端的PIN面板软件仿真器中且传送到app时的WSP_AU_PIN或甚至存储在app中以在没有显示PIN面板仿真器而只是利用“触控”来触发动作的情况下非常方便和流畅的用户体验的WSP_AU_PIN。然而，在仅灰箱保护下没有留下密码密钥；相反，它们受到利用在下文解释的DWB密码构造的第二级保护。

app的纯软件安全组件还可以包括动态白箱(DWB)密码构造，例如在图6的部分604中图示化的，其中变换T()是对称密钥解密原语。

在一些实施例中，相同的通用app可以用于根据是否发生app的用户初始化或它是否得到用户设备支持来实现SWB安全级(较低)或DWB安全级(较高)。

解密算法可以用静态白箱(SWB)AES 256-I算法来实现，该算法对唯一系统密钥K_SYS编码。在该情况下，实现处于SWB安全级，其中全系统密钥在所有用户设备中散播，但具有不一定要让用户和钱包服务器参与初始化阶段的优势。

如果在app上用户结合钱包服务器/WSP执行的初始化阶段期间，用设备或用户特定传输密钥K_TR来代替SWB AES 256-I的K_SYS，则可以在DWB提供增强安全级。

DWB的优势是在系统密钥K_SYS变成由app随机生成的特定用户传输密钥K_TR之后，这可以防止攻击者进行有效代码或数据提升攻击，即使灰箱保护因为攻击者将不能在他或她自己的硬件上复制相关进程(因为密钥K_TR将不可用)而被规避也如此。

利用该布置，DWB构造关于在初始化过程期间在用户设备中的随机生成的密钥K_TR变成用户/设备专用的，这将用作传输密钥以用于将敏感认证会话密钥从钱包服务器带入app。操作的基本原理是移动交易应用在调用初始化规程的时候仅用随机密钥K_TR来示例。该密钥将在敌对环境中用作传输密钥，以用于在采用加密形式ESUK将SUK_AU密钥从它在钱包服务器的令牌凭证服务器功能中的生成延续下去直到它用于认证器的MAC计算。DWB实现然后执行解密来检索SUK_AU，并且进一步用HASH＝H1[RAND,H2(WSP_AU_PIN,SALT)]进行FnH变换来检索SK_AU。

在一些实施例中，在使认证令牌结构的灰箱和/或DWB部分初始化方面可以采用移动指纹或其他设备专用数据。

在一些实施例中-作为对DWB产生动态密钥的基于服务器的安全的备选方案，如本文描述的，对于DWB的动态密钥可以从用户设备中的时钟功能生成。在任一情况下，动态密钥可以存储在本地加密数据库(也称为“加密的数据库”或“DBE”)中，如本文描述的。

下列论述涉及其中提供增强安全措施的支付系统200的实施例。

图15提供对于高度安全用户认证过程的交易流的综览。更多细节将在下文提供，但在高级别，过程流包括(a)从认证令牌到钱包服务器的认证请求(标号1502)(认证服务)；(b)认证令牌与钱包服务器之间安全通信信道的建立(标号1504)；以及(c)隧道认证会话(标号1506)，其包括(i)设备认证段1508；(ii)会话密钥的产生和传输(从钱包服务器到认证令牌)，如在1510处指示的；以及(iii)用户认证段1512。

接下来论述安全信道建立、设备认证、会话密钥产生和分发以及用户认证的细节。

如图15中示出的交易流以由认证令牌对令牌凭证服务器的认证开始，紧接着在令牌凭证服务器与认证令牌之间建立安全信道。在该段，认证令牌扮演客户端的角色，而令牌凭证服务器扮演服务器的角色。

TLS(传输层安全性)握手协议允许服务器对客户端认证。它还允许与对应密码密钥协商对称密码算法。经协商的密钥对于在客户端与服务器之间的安全会话期间建立的任何连接对记录协议操作可用。握手协议在下文用该公开的认证机制可能需要的元素来描述，并且在图16中示意图示。

在一些实施例中，支付网络运营商(在图中和接着的论述中指示为“MCW”)可以充当认证令牌和令牌凭证服务器都信任的认证机构。

认证令牌用KV_MC--MCW公共验证密钥来初始化。

轮到令牌凭证时用以下来使它初始化：

●KV_MCW—MCW公共验证密钥

●Cert_Server＝Cert_MCW(KE)-由MCW对令牌凭证服务器发布的公共加密密钥证书

●KE-令牌凭证服务器的公共加密密钥

●KD-令牌凭证服务器的私密解密密钥

在握手协议的第一段，钱包服务器基础设施中用户的认证令牌和令牌凭证服务器如下那样参与稍微更改的TLS握手协议：

●步骤1602--认证令牌将认证请求转发到令牌凭证服务器。作为该命令的参数，它提供：

□用户数据库中用户的标识符(用户_ID)。

□设备数据库中用户设备(其托管认证令牌)的标识符设备_ID。

□具有它支持的加密算法的标识符的CipherSuiteClient提议集(要与令牌凭证可能性同步-注意匹配算法可以因为双方在系统中知道彼此而预先建立)。

□随机数R_C，作为对服务器的客户端挑战的部分。

●步骤1604--在接收认证请求之后，令牌凭证服务器执行下列操作：

□它使用用户_ID来核实用户在系统中的登记并且从用户数据库检索他/她的密码参数：

{TIdN，Token_Attriubutes，H_2U＝H2(WSP_AU_PIN，SALT_U)}

□它使用设备_ID来核实用户设备的登记，令牌凭证服务器基于此从设备数据库检索设备的密码参数并且存储它们，即：

{H_2D＝H2(MD_Fingerprint，SALT_D)}

□它检索它自己的CipherSuiteServer集并且使之与如在CipherSuiteServer中描述的认证令牌所支持的加密算法相匹配-这些加密算法例如可以是RSA，但备选地可以支持其他算法。

□它生成随机数R_S作为对客户端的服务器挑战的一部分。

□它检索它的公共加密密钥证书Cert_Server＝Cert_MCW(KE)。

□它形成下列负载并且将其发送到客户端：

服务器响应{R_S,Cert_Server,CipherSuiteServer}

●步骤1606--在从令牌凭证服务器接收服务器响应之后，认证令牌执行下列操作：

□它检索令牌凭证的CipherSuiteServer并且将RSA标识为通常支持的具有它自己的CipherSuiteClient的加密算法。

□它验证了所接收的Cert_Server的锁定对应于见证锁定迹线，其对应于认证令牌自它的初始化以来存储在它之中的令牌凭证服务器的公共加密密钥证书。

□它使用MCW公共验证密钥KV_MCW来验证Cert_Server并且获得令牌凭证服务器的公共加密密钥KE的真实副本。

□它随机生成预备主密码(pms)。

□它使用KE计算pms上的数字信封(即，DE＝RSA(KE)[pms])并且将它发送到服务器。

●步骤1608--在从认证令牌接收数字信封之后，服务器执行下列操作：

□使用KD来打开DE以用于检索pms，即pms＝RSA(KD)[DE]。

□从认证令牌提议的pms值连同在会话期间交换的随机值(R_C,R_S)来计算TLS的记录协议待使用的安全信道密钥K：

K＝SHA(pms，R_C，R_S)

□计算密钥确认值V＝SHA(K.R C.R S)并且将它发送到认证令牌。

●(继续步骤1608)--在从令牌凭证接收密钥确认值V之后，认证令牌使用与服务器K＝SHA(pms,R_C,R_S)相同的公式产生它自己的安全信道密钥K的副本，并且对照它的计算来验证它，即：

Verify V?＝SHA(K，R_C，R_S)

如果成功通过验证，则令牌凭证服务器被视为真实的并且安全信道密钥K被传递到记录协议用于对所有后续数据交换加密直到与令牌凭证服务器的会话结束。

图17是图示图15中的步骤1508(设备认证)的细节的流程图。对于下列论述，“ATC”指示认证交易计数器的当前值，并且“ATC-1”指示该计数器从用户认证协议之前(紧接其之前)的执行/会话的值。

步骤1702，图17—认证令牌读取加密数据库(DBE)来检索：

●用于协议的所有执行的公共值，即：

□H_2D＝H2(MD_Fingerprint，SALT_D)

□SALT_U

注意：

用于包含密码字典攻击的SALT对于设备认证具有不同的值—如在设备数据库的设备指纹表中保持的，即：

H_2D＝H2(MD_Fingerprint，SALT_D)

并且对于如在用户数据库中保持的用户认证具有不同的值，即

H_2U＝H2(MSP_AU_PIN，SALT_U)

●在对应于“ATC-1”的DBE中在存储器索引处存储的来自密钥产生和分发的先前会话的值，即：

□ESUK*_MD＝AES256-E[K_TR](SUK*_MD)

□RAND*-在先前用户认证会话中使用的随机(挑战值)

注意：下文的算法针对ATC>0运作。当ATC＝0时，设备认证依赖在初始化阶段期间由WSP分发的认证代码，其如下文描述的那样使用

步骤1704，图17--认证令牌使用DWB构造来计算：

DA_Cryptogram＝MAC[SK*_MD](R_S，ATC)

其中：

●R_S是在握手段(步骤1604，图16)中由令牌凭证服务器发送到认证令牌的挑战值。

●ATC--认证器交易计数器的当前值(ATC_crt)

●SK*_MD＝SUK*_MD FnH H1(RAND*，H_2D)，其中RAND*和H_2D是从DBE检索的值。

●SUK*_MD＝AES256-I[ESUK*_MD]，其中ESUK*_MD是从DBE检索的值。

步骤1706，图17--认证令牌将DA_Cryptogram传送到令牌凭证服务器用于验证设备的真实性证据。

步骤1708，图17--令牌凭证服务器要求令牌管理库将用于设备认证的令牌主密钥TMK_MD计算为：

TMK_MD＝3DES[WSP_MK_MD](Device_ID，MD_Fingerprint)，

其中：

●WSP_MK_MD是对于设备认证服务的WSP的系统密钥。

●Device_ID是如在设备数据库中记录的设备的标识符

●MD_Fingerprint是由认证令牌软件配置上的移动OS或浏览器扩展计算的唯一迹线。

令牌凭证服务器使用TMK_MD用于将对于在之前的执行中使用的设备认证的会话密钥计算为：

SK*_MD＝3DES[TMK_MD](ATC-1)

令牌凭证服务器现在可以计算设备认证器的见证值并且将它与所接收的值DA_Cryptogram比较，即，

MAC[SK*_MD](R_S，ATC)？＝DA_Cryptogram

如果等式成立，设备被视为真实的并且可以执行用户认证协议的下列阶段。

令牌凭证服务器使用在步骤1504(图15)从数据库检索的用户和设备参数，并且要求令牌交易行进来生成新的RAND(挑战值)用于接着的挑战/响应执行，即图15的步骤1510。从而，下列值对协议的下一个段可用：

●{TIdN，Token_Attributes，H_2U＝H2(WSP_AU_PIN，SALT_U)}

●{H_2D＝H2(MD_Fingerprint，SALT_D)}

●RAND

在本公开的该部分中描述的消费者认证系统依赖特殊密钥产生和分发方案，其可以关于安全服务实现的密码密钥的存储减少纯软件安全模型的潜在脆弱性。

如下文描述的密钥产生对于一些实施例并不依赖存储在一些加密数据库中的每个设备一个长期服务密钥的使用(作为安全元素的对等物)，其通过具有ATC的认证令牌而多样化以用于实现会话密钥来运行相应服务。

相反，在对于这些实施例的机制中，提出使用两个“一次性”会话密钥，如在图11中示意图示并且如下文概述的：

(1)对于设备认证安全服务，多方使用用于设备认证的会话密钥，指示为SK_MD，其在当前用户认证交易中由令牌凭证服务器产生以由认证令牌用于在下一个用户认证会话期间实现设备认证服务。该密钥SK_MD在ATC＝0时认证令牌初始化期间在认证令牌中在值验证代码处设置。

(2)对于用户认证服务，多方使用用于用户认证的会话密钥，指示为SK_AU，其在当前用户认证交易中由令牌凭证服务器产生以由认证令牌用于在相同的用户认证会话期间实现用户认证服务。该密钥SK_AU从未存储在认证令牌中。

图18是图示图15的步骤1510的细节的流程图，其涉及刚刚描述的两个密钥的产生。

然后参考图18：

步骤1802，图18--令牌凭证服务器使用它在步骤1708(图17)获得的密钥TMK_MD用于将用于设备认证、在用户认证的下一个执行会话期间待使用的会话密钥计算为：

SK*_MD＝3DES[TMK_MD](ATC)

步骤1804，图18--令牌凭证服务器要求令牌管理库将对于消费者认证的令牌主密钥TMK_AU计算为：

TMK_AU＝3DES[WSP_MK_AU](TIdN，Token_Attributes)，

其中：

●WSP_MK_AU是对于用户认证服务的WSP的系统密钥。

●TIdN是如在用户数据库中记录的认证令牌标识符。

●Token_Attributes是描述令牌可以仅用于用户认证协议而不用于支付交易本身的属性的集。

令牌凭证服务器使用TMK_AU用于将用于用户认证、在用户的认证协议的当前执行中待使用的会话密钥计算为：

SK_AU＝3DES[TMK_AU](ATC)

步骤1806，图18--令牌凭证服务器计算对于会话密钥仅朝向规定接收者(即，用户和他/她的用户设备(用依赖唯一传输密钥K_TR的DWB构造来初始化))的“已通过(over)”安全传输(已经有带加密的TLS隧道)和安全调派的“隐藏”参数(例如，哈希值)：

●HASH_U＝H1[RAND，H2(WSP_AU_PIN，SALT_U)]-对于用户认证会话密钥SK_AU的隐藏参数。

●HASH_D＝H1[RAND，H2(MD_Fingerprint，SALT_D)]-对于设备认证会话密钥SK*_MD的隐藏参数。

步骤1808，图18--令牌凭证服务器计算安全分发到认证令牌的会话密钥作为通过“隐藏”参数变换的一次性密钥(SUK)：

●SUK_AU＝SK_AU FnH HASH_U。SK_AU将由认证令牌用于完成当前用户认证会话。

●SUK*_MD＝SK*_MD FnH HASH_D。SK*_MD将首先存储在认证令牌的DBE中并且被认证令牌用于完成在下一个用户认证会话中的设备认证阶段。

步骤1810，图18--为了执行认证令牌的DWB构造所允许的第三级加密，令牌凭证服务器可以最后一次对一次性密钥(SUK_AK,SUK*_MD)加密。加密用设备的专用传输密钥K_TR来执行。从而，一次性密钥(SUK_AU)可以仅由用户的认证令牌安全调派，该认证令牌的DWB构造在初始化时随机生成K_TR：

●ESUK＝AES256-E[K_TR](SUK_AU)

●ESUK*_MD＝AES256-E[K_TR](SUK*_MD)

步骤1812，图18--令牌凭证服务器将ESUK、ESUK*_MD和RAND传送到认证令牌。

该公开的下列部分涉及设备/用户认证会话的用户认证阶段。

图19是图示图15的步骤1512的细节的流程图。

步骤1902，图19--认证令牌将ESUK*_MD和RAND存储在DBE中用于在用户认证协议的下一个执行期间完成设备认证阶段。

步骤1904，图19--认证令牌从DBE检索SALT_U(SALT_U将充当加密计算的输入数据，如下文指示的)。

步骤1906，图19--认证令牌弹出虚拟PIN面板以要求钱包认证的消费者PIN，即WSP_AU_PIN。用户键入所需要的密码(即，提示并且接收PIN的用户输入)。

步骤1908，图19--认证令牌计算：

AU_Cr＝MAC(SK_AU)[Auth_Data]，其中Auth_Data如在上文在论述图12之后该公开的章节中描述的。

用于认证的会话密钥SK_AU由具有DWB构造的认证令牌检索如下：

SK_AU＝SUK_AU FnH HASH_U，

其中：

●HASH_U＝H1[RAND，H2(WSP_AU_PIN，SALT_U)]，其中WSP_AU_PIN如由用户提供作为认证证据。

●SUK_AU＝AES256-I[K_TR](ESUK)，如由用户设备的DWB构造从令牌凭证服务器接收的信封ESUK解密。

步骤1910，图19--认证令牌将密码AU_Cr发送到钱包服务器配置内的令牌交易处理。

步骤1912，图19--令牌交易处理执行下列处理：

●它检索它在完成对于令牌凭证服务器的步骤1708(图17)之后产生的初始RAND(挑战值)。

●它从令牌凭证服务器检索在步骤1804(图18)计算的SK_AU。

●它采用与认证令牌从RAND和ATC开始所做的相同的方式(按照在图12的论述之后的该公开的章节)对Auth_Data重新编译。

●它比较接收的AU Cr？＝MAC(SK_AU)[Auth_Data]。如果两个值相等，令牌交易处理服务器接受用户的真实性。

在成功完成设备和用户认证时，钱包服务器可以允许用户经由用户设备访问他/她的数字钱包。例如，可以准许用户选择一个支付账户以供在当前购买交易中使用，其中该支付账户是用户的数字钱包的众多“存档卡”。购买交易然后可以推进到对所选的支付账户进行对交易的收费。

对于至少一些目的，在完成设备认证阶段或段之后发生的图15的过程的所有部分可以视为过程的用户认证阶段或段。

该公开的下列章节提供对纯软件认证系统可能需要的各种实体的设置操作的综览，其包括例如令牌凭证服务器的MPA/BE(移动支付应用/浏览器扩展)和数据库。

下文的一个章节关于用于在用户设备中的-DBE-加密数据库的机制。随着使用静态白箱技术，可以对用户设备中的潜在脆弱参数提供相对简单且有效的保护。

下文的另一个章节提供关于在用户设备中用设备专用/唯一传输密钥对DWB构造初始化的细节，使得用户设备在一些实施例中可以充当“你拥有的”认证因素。该技术可以允许包括使用单序列代码，例如在所有用户设备中的标准可下载钱包/支付app/MPA/BE中，其中app将在设备操作的初始化阶段期间对每个用户设备上的每个用户不同地初始化。

下文的另一个章节提供系统200中的用户注册阶段的综览，并且额外章节涉及用户设备上MPA/BE的安装和初始化。为了简化接着的论述，将仅参考MPA，但相对于MPA的论述也应视为能适用于BE。

论述的下列章节包括上文提到的DBE的描述。图20示意性地图示静态白箱(SWB)密码构造的细节(按照图6的部分602)，其可以用于提供DBE中需要的变换。

在图20的左手边上示出写操作(标号2002)--将索引i和ATC值输入静态白箱算法，其使用嵌入式K_SYS来对该索引值创建密钥Ki，该密钥然后通过与移动指纹(MD_Fingerprint)结合而对移动设备个性化以形成K’i。K’i然后用于对参数PARAMi加密来形成加密参数EPARAMi，其然后在该索引i下存储。

读操作是写程序的逆，并且在图20的右手边上示出(标号2004)。K’i使用与起初用于创建它的相同程序来重新计算。K’i然后用于对EPARAMi解密来重新创建PARAMi。

图20的所有程序可以进一步受到软件模糊的保护-即，该整个过程可以在“灰箱”中发生。

图20的方法假设没有MPA的用户定制化-移动指纹在MPA(其是完全通用的)运行时提供。

为了用户认证协议的目的，DBE如下存储数量减少的参数(在图21中图示)：

●在索引＝1，ATC＝0--对于写和读操作两者-存储有具有PARAM11＝SALT_U(标号2102)和PARAM12＝H2_D(标号2104)的合适K’i密钥的加密值。

●在索引＝2，其中对于写来说ATC＝ATC_crt并且其中对于读来说ATC＝ATC_crt-1，存储有PARAM21＝ESUK*_MD(标号2106)和PARAM22＝RAND*(标号2108)。待存储在DBE中的初始参数PARAM21已经是由具有设备专用传输密钥K_TR的令牌凭证服务器产生的密码，如在上文关于图18解释的。当作为EPARAM21存储在DBE中时，在由ATC的当前值确定的密钥K’i下对它双重加密。

本公开的下列章节关于用户设备中的DWB构造的初始化。

动态白箱(DWB)构造的功能性的该论述与图4有关。下面还代表图6的下部分604中示出的方法的实施方式。在如下文描述的实施方式中，在图6的下部分604中示出的变换可以是利用指示为K_TR的密钥(指示为“传输密钥”)的解密。

至于关于图20和21论述的SWB构造，该整个过程在灰箱环境中发生，这可以是可取的，其中HASH＝H1[RAND,H2(WSP_AU_PIN,SALT)]的整个计算通过软件模糊技术而得到保护。在DWB构造中实现的解密算法可以是在DWB构造的白箱保护环境中密钥K_TR集作为参数的参数化AES256-I算法。

在用户执行的初始化段期间，从应用商店下载的通用MPA可以对于在初始化之前使对于SWB AES256-I的系统密钥K_SYS用在初始化之后对于设备专用块AES256-I的设备密钥K_TR替代。

在各种实施例中，相同的通用MPA可以根据MAP初始化是否发生或它是否得到移动计算设备的支持而用于实现SWB或DWB安全级。

在密钥从K_SYS变为K_TR之后，因为攻击者将不能在他或她自己的硬件上复制相关过程(因为密钥K_TR将不可用)，攻击者将不再能够进行有效代码或数据提升攻击，即使MPA的灰箱保护得到规避也如此。

解密块SWB AES256-I实际上现在是设备专用的并且作为具有随机密钥K_TR的动态白箱实施方式AES256-I而生成。令牌凭证服务器从SUK_AU生成的时刻保护它一直到用传输密钥K_TR对它加密的时刻。

操作的基本原理在一些实施例中是MPA在调用初始化程序的时候仅用随机密钥K_TR例示(也参考在下文关于图25-27的论述)。该密钥将在敌对环境中用作传输密钥以采用加密形式使操作密钥SUK_AU从它在令牌凭证服务器中的生成延续下去直到它被MPA用于计算SK_AU。MPA的动态白箱实施方式然后通过使用传输密钥K_TR来执行解密操作以采用在白箱强化沙箱外部没有暴露关于该密钥的信息的方式获得密钥SUK_AU。

DWB初始化序列由用于解密的加密API的下列示例调用组成：

图22是图示DWB初始化序列的流程图。

●(步骤2202，图22)随机生成关于16个字节的传输密钥ktr，即，ktr＝RANDOM(16)。

●(步骤2204，图22)使用MPA的原生SWB-E K_SYS构造(如在上文关于图20和21论述的)来对令牌凭证服务器创建包含ktr的信封，即，EKTR＝SWB-E[K_SYS](ktr)。这可以导致编码为例如：

EKTR＝NativeS_Encrypt_WBC(ktr,16)

该信封将在初始化阶段中发送到令牌凭证服务器。

●(步骤2206，图22)利用密钥ktr创建SWB解密函数S_Decrypt_WBC，以供在DWB构造中使用：

S_Decrypt_WBC(input，size)，

其中：

○input是具有ktr的加密信封ESUK，其传输一次性密钥SUK_AU。

○size是它的字节长度(例如，16个字节)

该函数在初始化阶段期间通过像以下(例如)的API调用而仅创建一次：

Create Static WBC(decrypt，ktr，S_decrypt_WBC()，AES256)

函数S_Decrypt_WBC使用设备专用传输密钥ktr作为嵌入AES256-I中的白箱密码模式中的静态密钥。

●(步骤2208，图22)创建DWB构造作为MAC(例如)，其可以根据EMV支付协议和/或根据众所周知的标准ISO 9797-1的方面来进行：

D_MAC_WBC(密钥，矢量，组合，输入，大小)，

其中

○密钥是动态密钥SUK_AU，其是使用传输密钥ktr通过S_Decrypt_WBC对ESUK的调派；

○矢量是可以与SUK_AU密钥组合来导出会话密钥SK_AU的分量，即，矢量是HASH_U＝H1[RAND，H2(WSP_AU_PIN，SALT_U)]；

○组合是得到合成MAC密码的算法，如：combination[密钥，矢量]

例如，组合可以是如在上文的章节中关于安全参数描述的FnH(nKey，H1)

○输入是要被MAC的认证数据的串；

○大小是它的字节长度。

该函数可以通过API调用来创建，像：

Create Dynamic WBC(ktr，S_Decrypt_WBC(ESUK)，D_MAC_WBC()，“ISO9797-1”).

如可以看到的，按照上文阐述的步骤2204，可需要令牌凭证服务器用K_SYS来初始化，以能够接收和记录具有每个设备的传输密钥ktr的密码的所有信封。

本公开的下列章节关于用户在钱包服务器的注册。该阶段的综览在图23中图示。

在用户注册阶段中，用户在管理浏览会话内使用静态用户认证凭证(即(用户_ID，密码))连接到钱包服务器。

用户选择在管理网站上选择功能“注册纯软件认证器”。

该动作向服务器发送注册请求。服务器在轮到它时生成随机认证代码(AC)，其将被发回给用户。服务器更新用户数据库(也称为消费者数据库或“CDB”)中用户记录中的AC值。

在从钱包服务器接收AC之后，用户将利用任何常规安全方法来存储它，以稍后作为对于初始化段的初始用户和设备认证而提供(如在下文关于图25-27描述的)。

这使用户注册阶段终结。

该公开的下一个章节关于在用户设备上安装MPA。图24提供MPA安装阶段的综览。

独立于注册纯软件认证服务，用户可以继续在他的设备上安装MPA(或BE)。

为此，用户可以从App商店(或在BE的情况下是Web商店)选择MPA应用，并且继续它在他/她的用户设备中的下载。为了该公开，假设下载是免费的并且不需要用户呈现AC作为初始用户(和设备)认证的证据。

下载的MPA处于“未初始化”状态，其具有下列标准内容：

□待用于利用令牌凭证服务器对MPA的初始化阶段的初始化URL。

□Cert_Server＝Cert_MCW(KE)--由MCW对钱包服务器的令牌凭证服务器发出的公共加密密钥证书(如关于图15提及的)。

□验证锁定-MPA最初知道的针对弱服务器认证的Cert_Server的锁定值。

□对于到令牌凭证服务器的DWB构造的传输密钥K_TR的初始安全切换的SWB-E K_SYS构造。

□具有系统密钥K_SYS的“未初始化”DWB构造。

该公开的下一个章节关于MPA的初始化(或，尽管未明确提到，BE)。

在初始化阶段，MPA在状态“未初始化”开始处理、连接到初始化URL并且建立安全信道-例如-如在上文关于图15和16描述的，其中用户使用常规(用户_ID,密码)对令牌凭证服务器认证。服务器检索用户数据库/消费者数据库(CDB)中用户的对应记录。

在用户认证成功后，服务器需要MPA/用户呈现关于设备标识符(设备_ID)和设备指纹的初始认证代码(AC)，就是说，为了简单起见，移动设备指纹(MD_Fingerprint)(但在其他实施例中，可能明智的是，这对于浏览器扩展(BE)也是可能的)。为此，MPA调用移动OS用于生成合适的设备_ID和MD_Fingerprint值、将它们连同AC一起封装并且将它们发送到服务器。

图25是图示然后可以由钱包服务器执行的过程的流程图。

钱包服务器可以执行下列处理：

(步骤2502，图25)从CDB检索来自用户记录(如在用户注册阶段期间存储的-参见与图23有关的论述)的见证AC并且将它与接收的AC(如在MPA中由用户提供的)比较。如果两个值相同，则继续进行处理。

(步骤2504)生成SALT_U并且紧挨CDB中的用户_ID将它存储在用户的记录中。

(步骤2506)对于指定设备_ID和MD_Fingerprint在设备数据库(DDB)中创建对于用户设备的条目。

(步骤2508和2510)生成SALT_D并且计算H_2D＝H2(MD_Fingerprint,SALT_D)(还参考上文图17的步骤1702的论述)。

(步骤2512)在DDB中用对应于设备_ID的记录来记录(H2_D,SALT_D)。

(步骤2514)按照上文的图17的步骤1708的论述计算TMK_MD。

(步骤2516)使用TMK_MD用于计算ATC＝0时的SK*_MD，其在一些实施例中可以如在上文的图18的步骤1802的论述中描述的那样进行。

(步骤2518)要求钱包服务器的令牌交易处理以用于生成新的挑战值RAND。

(步骤2520)计算HASH_D＝H1(RAND,H2_D)，其可以根据上文的图18的步骤1806的论述来进行。

(步骤2522)计算SUK*_MD＝SK*_MD FnH HASH_D，其可以根据上文的图18的步骤1808的论述来进行。

(步骤2524)将SALT_U和H2_D传送到MPA/用户设备。

图26是图示然后可以由MPA/用户设备执行的过程的流程图。

在从服务器接收{SALT_U,H2_D}之后，MPA/用户设备可以执行下列处理：

在状态“未初始化”开始处理。

(步骤2602，图26)对于ATC＝0在索引＝1时在DBE中执行写操作来存储{SALT_U,H2_D}。

(步骤2604)弹出安全仿真PIN面板、需要用户选择钱包PIN用于认证并且捕捉它作为WSP_AU_PIN的第一值。

(步骤2606)要求用户确认PIN选择，并且捕捉WSP_AU_PIN的第二值。

(步骤2606，继续；步骤2608)比较对WSP_AU_PIN捕捉的两个值并且如果它们匹配则计算：

H2_U＝H2(WSP_AU_PIN，SALT_U)

(步骤2610)运行DWB构造的初始化，其可以根据在上文的论述图22中以及在图22的论述之前的该公开的章节中提及的技术来进行；可以指出，在一些实施例中，EKTR＝SWB-E[K_SYS](K_TR)可以更精确地写为：

EKTR＝AES256-E(K_SYS](K_TR，SALT_U，H2_D，H2_U)

(步骤2612)将EKTR传送到服务器。

图27是图示然后可以由钱包服务器执行的过程的流程图。

在接收EKTR时，钱包服务器可以执行下列步骤：

(步骤2702，图27)用之前初始化的系统密钥K_SYS打开数字信封EKTR并且得到串S：

S＝AES256-I[K_SYS](EKTR)

(步骤2704)在串S中识别由SALT_U和H2_D表示的已知模式。仅在这两个检索的值等于之前发送的值时才进行。

(步骤2706)检索对应于消费者设备的传输密钥K_TR以及H2_U。

(步骤2708)将关于设备_ID记录的K_TR安全存储在DDB中。

(步骤2710)在CDB中紧挨SALT_U存储H2_U。

(步骤2712)计算ESUK*_MD＝AES256-E[K_TR](SUK*_MD)，其可以采用如在上文关于图18的步骤1810论述的方式发生。

(步骤2714)服务器将ESUK*_MD发送到MPA/用户设备。

在从服务器接收ESUK*_MD之后，MPA/用户设备将在索引＝2并且对于ATC＝ATC_crt(其现在是零)在DBE中写它。该密码将在用户认证协议的首次运行中起到提供密码密钥用于执行强设备认证功能的作用。MPA将“初始化阶段完成OK”消息发送到服务器并且使它的内部状态从“未初始化”变为“初始化”。

在接收成功MPA初始化的确认之后，服务器将验证DDB中对应于设备_ID的记录，并且将验证添加到在CDB中具有用户_ID的用户记录的新项目。它将用状态字段中的值“ACTIVE”来标记两个记录。这完成钱包服务器中用户和他/她的设备的初始化。

如在该公开中描述的用户和设备认证过程可以采用便利、成本有效的方式满足在线支付安全的相关法规要求，同时还提供简单、不复杂的用户体验。另外，本文描述的至少一些过程可以提供非常高的安全性和可靠性程度，而没有与基于硬件的安全特征(例如嵌入式安全元件或SIM卡上支付安全的实现)关联的成本和负担。此外，在许多方面，本文描述的过程可以采用新颖方式利用现有的支付基础设施，其可以加到本文描述的用户/设备认证技术方案的成本有效性方面。

尽管在上文在网购交易的上下文中论述用户和/或设备认证，在一些实施例中，相同或相似用户和/或设备认证协议可以适用于店内购买交易：“在走道上”或对于客户/用户(也在POS终端处出现)在零售店POS终端的参与下。

在本文描述的示例实施例中，双因素认证方法需要“你有什么”(计算设备，其中存储设备专用纯软件认证数据)加上“你知道什么”(PIN或其他秘密信息/密码)。然而，在其他实施例中，代替“你知道什么”认证因素或除其之外，可以使用“你是什么”/生物计量认证因素。例如，用户设备可以包括指纹扫描功能性，并且用户证据数据元素(在基于PIN的用户认证的情况下指示为WSP_AU_PIN)可以包括采用标准格式从用户指纹的扫描结果得到的一个或多个数据元素。也可以或备选地采用其他类型的生物计量度量。

如本文和所附权利要求中使用的，术语“秘密代码”指PIN、密码或其他字符序列并且为设备用户所知(并且一般被设备用户秘密保存)，而无论是否存储在被采用来访问钱包服务器提供的服务的设备中。将注意在本文描述的许多实施例中，在输入PIN之后的认证会话期间的有限时间以外PIN未存储在用户设备中并且一直到它用作到用户设备中的密码过程的输入。

如本文和所附权利要求中使用的，术语“紧接…之前”或“紧跟”指事件序列中事件的相对位置，并且不一定暗指时间上接近。

如本文和所附权利要求中使用的，术语“支付应用”包括下载到计算设备的移动钱包应用、浏览器扩展或网页。

术语“计算设备”包括个人计算机、平板计算机和智能电话。

术语“个人计算机”或“PC”包括膝上型和笔记本计算机。

应理解在本文描述的过程中，当前交易和后续交易在指定用户设备的交易序列中可以彼此紧挨，但在时间上可以相隔数小时或数天(例如，可以相隔超过24小时)。

如本文和所附权利要求中使用的，术语“电子商务”指经由商户的网上商店来购买，和/或“在货架间”购物/支付或其中可以通过互联网或经由移动应用与远程服务器或其他计算机的交互来进行支付的任何其他交易。

如本文和所附权利要求中使用的，术语“计算机”应理解为包含单个计算机或彼此通信的两个或更多个计算机。

如本文和所附权利要求中使用的，术语“处理器”应理解为包含单个处理器或彼此通信的两个或更多个处理器。

如本文和所附权利要求中所使用的，术语“存储器”应理解为包含单个存储器或存储设备或两个或更多个存储器或存储设备。

如本文和所附权利要求中所使用的，术语“服务器”包括对来自其他设备(其代表提交服务请求的客户端)的服务的许多请求作出响应的计算机设备或系统。

本文的流程图及其描述不应被理解为规定执行其中描述的方法步骤的固定顺序。相反，方法步骤可以以任何可行的顺序执行，包括至少一些步骤的同时执行。

如本文和所附权利要求中所使用的，术语“支付卡系统账户”包括信用卡账户、账户持有者可以使用借记卡访问的存款账户、预付卡账户或支付交易可以从其完成的任何其他类型的账户。术语“支付卡系统账户”、“支付卡账户”和“支付账户”在这里可互换使用。术语“支付卡账号”包括标识支付系统账户的号码或由支付卡承载的号码，或用于在处理借记卡和/或信用卡交易的支付系统中路由交易的号码。术语“支付卡”包括信用卡、借记卡、预付卡或其他类型的支付工具，而不管是实际物理卡还是虚拟的。

如本文和所附权利要求中所使用的，术语“支付卡系统”是指用于处理购买交易和相关交易的系统。这样的系统的一个示例是由本公开的受让人万事达卡国际公司运营的系统。在一些实施例中，术语“支付卡系统”可以局限于成员金融机构向个人、企业和/或其他组织发行支付卡账户的系统。

虽然已经结合具体示范性实施例描述了本发明，但是应当理解，在不脱离如所附权利要求中阐述的本发明的精神和范围的情况下，可以对所公开的实施例进行对本领域技术人员显而易见的各种改变、替换和变更。

Claims

1.一种采用双因素认证来执行支付交易的方法，所述方法包括：

利用具有编码在其中的秘密密钥的密码功能参与密码处理，所述密码功能存储在计算设备中，所述秘密密钥充当第一认证因素；以及

在执行所述支付交易时使用第二认证因素。

2.如权利要求1所述的方法，其中，所述第二认证因素是所述计算设备的用户的生物计量特性。

3.如权利要求1所述的方法，其中，所述第二认证因素是所述计算设备的用户已知的秘密代码。

4.如权利要求3所述的方法，其中，所述计算设备从由以下组成的组选择：移动电话、个人计算机和平板计算机。

5.如权利要求4所述的方法，其中，所述秘密密钥在所述计算设备中运行的支付应用的初始化期间被编码在密码功能中。

6.如权利要求5所述的方法，其中，所述秘密密钥由所述支付应用在所述初始化期间随机生成。

7.如权利要求5所述的方法，其中，所述密码处理包括使用所述秘密密钥来对从远程服务器传送到所述计算设备的经加密的一次性密钥解密，作为所述支付交易的一部分。

8.如权利要求1所述的方法，其中，所述计算设备的用户在所述支付交易期间被准许访问分配给所述用户并且在远程钱包服务器中托管的数字钱包。

9.一种使用计算设备执行一系列支付交易的方法，所述一系列支付交易包括第一支付交易和第二支付交易，所述第二支付交易在所述一系列支付交易中紧跟所述第一支付交易，所述支付交易中的每一个包括相应设备认证段和相应用户认证段，所述方法包括：

执行所述第一支付交易的设备认证段；

使用第一会话密码密钥来执行所述第一支付交易的用户认证段；

作为所述第一支付交易的用户认证段的一部分，接收将用于生成第二会话密码密钥的输入；

使用所述第二会话密码密钥作为密码运算的输入值，所述密码运算作为所述第二支付交易的设备认证段的一部分而执行；以及

使用第三会话密码密钥来执行所述第二支付交易的用户认证段；所述第一会话密码密钥、第二会话密码密钥和第三会话密码密钥全部互不相同。

10.如权利要求9所述的方法，其进一步包括：

在一段时间内在所述计算设备中存储将用于生成所述第二会话密码密钥的输入，所述一段时间在所述第一支付交易的完成之后并且在所述第二支付交易开始之前。

11.如权利要求10所述的方法，其进一步包括：

在所述计算设备中接收挑战值，作为所述第一支付交易的用户认证段的一部分；所述挑战值由远程服务器提供给所述计算设备。

12.如权利要求10所述的方法，其进一步包括：

使用所述挑战值作为密码运算的输入值，所述密码运算作为所述第二支付交易的设备认证段的一部分而执行。

13.如权利要求12所述的方法，其进一步包括：

在所述一段时间期间将所述挑战值存储在所述计算设备中。

14.如权利要求9所述的方法，其进一步包括：

对第一一次性密钥解密以获得所述第一会话密码密钥，关于所述第一支付交易将所述第一一次性密钥从远程服务器提供给所述计算设备；

对第二一次性密钥解密以获得所述第二会话密码密钥，将所述第二一次性密钥从所述远程服务器提供给所述计算设备，作为所述第一支付交易的一部分。

15.如权利要求9所述的方法，其中，所述计算设备从以下组成的组选择：移动电话、个人计算机和平板计算机。

16.如权利要求9所述的方法，其中，关于所述第一支付交易和第二支付交易的相应用户认证段将秘密代码输入所述计算设备，所述秘密代码由所述计算设备使用以作为关于所述第一支付交易和第二支付交易的相应用户认证段由所述计算设备执行的相应密码过程的输入值。

17.如权利要求9所述的方法，其中，所述计算设备的用户在所述第一支付交易和第二支付交易期间被准许访问分配给所述用户并且在远程钱包服务器中托管的数字钱包。

18.一种执行当前支付交易的方法，所述方法包括：

将认证请求从计算设备传送到远程服务器，所述认证请求包括：用户识别数据，所述用户识别数据识别所述计算设备的用户；设备识别数据，所述设备识别数据识别所述计算设备；和第一挑战值，所述第一挑战值为所述认证请求而在所述计算设备中随机生成；

参与与所述远程服务器的TLS(传输层安全)握手过程以在所述计算设备与所述远程服务器之间发起隧道通信信道；所述TLS握手过程包括从所述远程服务器接收响应，所述响应包括第二挑战值、数字证书和由所述远程服务器提出的密码处理算法的识别；所述TLS握手过程进一步包括选择与由所述远程服务器提出的密码处理算法匹配的密码处理算法；所述TLS握手过程进一步包括验证从所述远程服务器接收的数字证书；所述TLS握手过程进一步包括访问与所述远程服务器关联的公共加密密钥；所述TLS握手过程进一步包括随机生成秘密值；所述TLS握手过程进一步包括用所述公共加密密钥对所述秘密值加密以生成数字信封；所述TLS握手过程进一步包括将所述数字信封传送到所述远程服务器；所述TLS握手过程进一步包括从所述远程服务器接收服务器真实性证据值；所述TLS握手过程进一步包括基于所述秘密值、所述第一挑战值和所述第二挑战值计算安全信道密钥K；所述TLS握手过程进一步包括经由具有所述安全信道密钥K、所述第一挑战值和所述第二挑战值作为输入的密码过程来验证所述服务器真实性证据值；

使用安全信道密钥K参与与所述远程服务器的设备认证过程段，所述设备认证过程段包括从所述计算设备中存储的加密数据库检索第一哈希值、第一经加密的一次性密钥和第三挑战值，所述第一经加密的一次性密钥在先前的支付交易的用户认证过程段中已被所述计算设备接收，所述当前支付交易在由所述计算设备执行的一系列支付交易中紧接所述先前的支付交易；所述第一经加密的一次性密钥已使用与在所述计算设备中存储的支付应用中编码的密钥相同的传输密钥来加密；所述第三挑战值已由所述计算设备关于先前的支付交易的用户验证段从远程服务器接收；所述第一哈希值已通过将第一哈希函数应用于设备指纹数据和第一salt值来计算；所述设备认证过程段进一步包括使用在所述支付应用中编码的密钥来对经加密的第一一次性密钥解密；所述设备认证过程段进一步包括基于包括第一会话密钥、所述第二挑战值和交易计数器值的输入来生成第一密码；所述第一会话密钥从经解密的第一一次性密钥、所述第一哈希值和所述第三挑战值导出；所述设备认证过程段进一步包括将所述第一密码从所述计算设备传送到所述远程服务器；

在所述设备认证过程段之后，使用所述安全信道密钥K参与所述当前支付交易的用户认证过程段；所述当前支付交易的用户认证段包括从所述远程服务器接收第二经加密的一次性密钥、第三经加密的一次性密钥和第四挑战值；所述当前支付交易的用户认证段进一步包括将所述第二经加密的一次性密钥和所述第四挑战值存储在经加密的数据库中；所述当前支付交易的用户认证段进一步包括从经加密的数据库检索第二salt值；所述当前支付交易的用户认证段进一步包括提示用户输入PIN(个人标识号)；所述当前支付交易的用户认证段进一步包括接收用户输入，其指示所述用户的PIN；所述当前支付交易的用户认证段进一步包括使用在所述支付应用中编码的密钥来对经加密的第三一次性密钥解密；所述当前支付交易的用户认证段进一步包括基于包括第二会话密钥、所述第四挑战值和交易数据的输入来生成第二密码；所述第二会话密钥使用所述用户输入从所述经解密的第三一次性密钥导出；所述当前支付交易的用户认证段进一步包括将所述第二密码从所述计算设备传送到所述远程服务器；以及

经由所述计算设备接收对所述用户的数字钱包的访问。

19.如权利要求18所述的方法，其中，所述用户的数字钱包在所述远程服务器上维持。

20.如权利要求18所述的方法，其中，所述计算设备从由以下组成的组选择：移动电话、个人计算机和平板计算机。

21.一种方法，其包括：

在服务器计算机中关于第一支付交易和第二支付交易执行认证服务，所述第一支付交易和第二支付交易由计算设备请求，所述第二支付交易在所述计算设备所请求的一系列支付交易中紧接所述第一支付交易；

所述认证服务包括：

(i)所述第一支付交易的设备认证过程段，所述服务器计算机在所述第一支付交易的所述设备认证过程段期间接收和验证第一密码；

(ii)所述第一支付交易的用户认证过程段，所述服务器计算机

(a)计算第一一次性密钥和第二一次性密钥；以及(b)将所述第一一次性密钥和第二一次性密钥传送到所述计算设备，作为所述第一支付交易的用户认证过程段的一部分；

(iii)所述第二支付交易的设备认证过程段，所述服务器计算机在所述第二支付交易的所述设备认证过程段期间接收和验证第二密码；所述第二密码的验证包括计算第一会话密钥；所述第一会话密钥与第二会话密钥相同，所述第二会话密钥由所述服务器计算机用于生成在所述第一支付交易的用户认证过程段的用户认证过程段期间计算的第二一次性密钥；以及

(iv)所述第二支付交易的用户认证过程段。

22.如权利要求21所述的方法，其中，所述服务器计算机采用加密形式将所述第一一次性密钥和第二一次性密钥传送到所述计算设备。

23.如权利要求21所述的方法，其中，所述服务器计算机为所述计算设备的用户维持数字钱包。