使用安全传输协议建立信任的系统和方法与流程

技术领域

本发明整体涉及数据处理系统的领域。更具体地讲，本发明涉及使用安全传输协议建立信任的系统和方法。

相关领域说明

还已经设计了使用生物计量传感器经由网络提供安全用户验证的系统。在此类系统中，可经由网络发送由验证器生成的得分和/或其他验证数据，以向远程服务器验证用户。例如，专利申请No.2011/0082801(“‘801申请”)描述了一种在网络上进行用户注册和验证的框架，这种框架提供强验证(例如，防御身份窃取和网络钓鱼)、安全交易(例如，防御交易中的“浏览器中的恶意软件”和“中间人”攻击)和客户端验证令牌的登记/管理(例如，指纹读取器、面部识别装置、智能卡、可信平台模块等等)。

本申请的受让人已经开发出对‘801申请中所描述的验证框架的多种改进。这些改进中的一些在以下一组美国专利申请(“共同未决的申请”)中描述，这些美国专利申请都被转让给本受让人：序列号13/730,761，名称为“Query System and Method to Determine Authentication Capabilities”(用于确定验证功能的查询系统和方法)；序列号13/730,776，名称为“System and Method for Efficiently Enrolling,Registering,and Authenticating With Multiple Authentication Devices”(使用多个验证装置有效地进行登记、注册和验证的系统和方法)；序列号13/730,780，名称为“System and Method for Processing Random Challenges Within an Authentication Framework”(用于在验证框架内处理随机质询的系统和方法)；序列号13/730,791，名称为“System and Method for Implementing Privacy Classes Within an Authentication Framework”(用于在验证框架内实施隐私类别的系统和方法)；序列号13/730,795，名称为“System and Method for Implementing Transaction Signaling Within an Authentication Framework”(用于在验证框架内实施交易信令的系统和方法)；以及序列号14/218,504，名称为“Advanced Authentication Techniques and Applications”(高级验证技术和应用)(下文中称为“‘504申请”)。

简而言之，在这些共同未决的申请描述的验证技术中，用户向客户端装置上的验证装置(或验证器)诸如生物计量装置(例如，指纹传感器)登记。当用户向生物计量装置登记时，(例如，通过轻扫手指、拍摄照片、记录语音等)捕捉生物计量参考数据。用户可随后经由网络向一个或多个服务器(例如，配备有安全交易服务的网站或其他依赖方，如共同待决的申请中所述)注册验证装置；并且随后使用在注册过程中交换的数据(例如，预置到验证装置中的密钥)向那些服务器验证。一旦通过验证，用户便获许与网站或其他依赖方执行一个或多个在线交易。在共同未决的申请所描述的框架中，敏感信息(诸如指纹数据和可用于唯一地标识用户的其他数据)可本地保持在用户的验证装置上，以保护用户的隐私。‘504申请描述了多种额外的技术，包括以下技术：设计复合验证器、智能地生成验证保证等级、使用非侵入式用户核验、将验证数据传送到新的验证装置、用客户端风险数据扩充验证数据、自适应地应用验证策略，以及创建信任圈等等。

附图说明

可结合下列附图从以下具体实施方式更好地理解本发明，其中：

图1A至图1B示出了安全验证系统架构的两个不同实施例；

图2是示出了可如何将密钥注册到验证装置中的交易图；

图3示出了显示远程验证的交易图；

图4示出了向依赖方进行的验证可能如何使用依赖方应用程序；

图5示出了用于通过使用安全通信协议建立信任来进行验证的系统的一个实施例；

图6示出了用于通过使用安全通信协议建立信任来进行验证的方法的一个实施例；

图7示出了用于实施本文所述的客户端和/或服务器的示例性数据处理架构；以及

图8示出了用于实施本文所述的客户端和/或服务器的另一个示例性数据处理架构；

具体实施方式

下文描述用于实施高级验证技术及相关联应用的设备、方法和机器可读介质的实施例。在整个描述中，出于解释的目的，本文陈述了许多特定细节以便透彻理解本发明。然而，本领域的技术人员将容易明白，可在没有这些特定细节中的一些的情况下实践本发明。在其他情况下，为免模糊本发明的基本原理，已熟知的结构和装置未示出或以框图形式示出。

下文论述的本发明的实施例涉及具有用户核实功能(诸如生物计量形式或PIN输入)的验证装置。这些装置在本文中有时称为“令牌”、“验证装置”或“验证器”。尽管某些实施例注重于面部识别硬件/软件(例如，用于识别用户面部并且跟踪用户的眼球运动的相机和相关联软件)，但有些实施例可利用额外的生物计量装置，包括(例如)指纹传感器、声音识别硬件/软件(例如，用于识别用户声音的麦克风和相关联软件)以及光学识别能力(例如，用于扫描用户视网膜的光学扫描器和相关联软件)。用户验证功能还可包括非生物计量形式，如PIN输入。验证器可使用装置，如可信平台模块(TPM)、智能卡和安全元件，来进行密码操作与密钥存储。

在移动式生物计量的具体实施中，生物计量装置可远程于依赖方。如本文所用，术语“远程”意味着生物计量传感器不是其以通信方式耦接到的计算机的安全边界的一部分(例如，生物计量传感器未嵌入到与依赖方计算机相同的物理外壳中)。举例来说，生物计量装置可经由网络(例如，因特网、无线网络链路等)或经由外围输入(诸如USB端口)耦接到依赖方。在这些条件下，依赖方可能无法知道装置是否为得到依赖方授权的装置(例如，提供可接受等级的验证强度和完整性保护的装置)以及/或者黑客是否已经危及或甚至已经替换了生物计量装置。生物计量装置的置信度取决于装置的特定实施。

本文中使用的术语“本地”指的是用户正亲自在特定位置处(诸如在自动取款机(ATM)或销售点(POS)零售结账处)进行交易的事实。然而，如下文所论述，用于验证用户的验证技术可能涉及非位置组件，诸如经由网络与远程服务器和/或其他数据处理装置的通信。此外，尽管本文中描述了特定实施例(诸如ATM和零售点)，但应该指出的是，可在由最终用户在其内本地发起交易的任何系统的环境中实施本发明的基本原理。

本文中有时使用术语“依赖方”来不仅指尝试与之进行用户交易的实体(例如，执行用户交易的网站或在线服务)，也指安全交易服务器(有时称为代表那个实体实施的，该实体可执行本文所述的基础验证技术)。安全交易服务器可由依赖方拥有并且/或者在依赖方的控制下，或者可在作为商业安排的一部分向依赖方提供安全交易服务的第三方的控制下。

本文中使用的术语“服务器”指的是在一个硬件平台上(或跨多个硬件平台)执行的软件，其经由网络从客户端接收请求，然后作为响应来执行一个或多个操作，并且将响应传输到客户端，该响应通常包括操作的结果。服务器对客户端请求做出响应，从而向客户端提供或帮助向客户端提供网络“服务”。值得注意的是，服务器不限于单个计算机(例如，用于执行服务器软件的单个硬件装置)，而是实际上可散布在多个硬件平台上，有可能位于多个地理位置处。

示例性系统架构和交易

图1A和图1B示出了包括用于注册验证装置和验证用户的客户端侧组件和服务器侧组件的系统架构的两个实施例。图1A所示的实施例使用基于web浏览器插件的架构来与网站通信，而图1B所示的实施例不需要web浏览器。本文所述的各种技术诸如向验证装置登记用户、向安全服务器注册验证装置和核验用户可在这些系统构架中的任一者上实施。因此，虽然图1A所示的架构用于展示下述若干实施例的操作，但相同的基本原理可在图1B所示的系统上容易地实施(例如，通过删除浏览器插件105，该浏览器插件充当用于在服务器130与客户端上的安全交易服务101之间通信的中介)。

首先转到图1A，所示实施例包括配备有一个或多个用于登记和核验最终用户的验证装置110至112(这些验证装置在本领域中有时称为验证“令牌”或“验证器”)的客户端100。如上所述，验证装置110至112可包括生物计量装置，诸如指纹传感器、声音识别硬件/软件(例如，用于识别用户声音的麦克风和相关联软件)、面部识别硬件/软件(例如，用于识别用户面部的相机和相关联软件)和光学识别功能(例如，用于扫描用户视网膜的光学扫描器和相关联软件)，并且支持非生物计量形式(诸如PIN核验)。验证装置可使用可信平台模块(TPM)、智能卡或安全元件用于密码操作以及密钥存储。

验证装置110至112通过由安全交易服务101暴露的接口102(例如，应用程序编程接口或API)以通信方式耦接到客户端。安全交易服务101是用于经由网络与一个或多个安全交易服务器132至133通信以及用于与在web浏览器104的环境内执行的安全交易插件105介接的安全应用程序。如图所示，接口102还可提供对客户端100上的安全存储装置120的安全访问，该安全存储装置存储与每个验证装置110至112相关的信息，诸如装置识别代码、用户识别代码、受验证装置保护的用户登记数据(例如，所扫描的指纹或其他生物计量数据)，以及用于执行本文所述安全验证技术的由验证装置包封的密钥。例如，如下文详细论述，唯一密钥可被存储到每个验证装置中并且在经由网络(诸如因特网)与服务器130通信时使用。

如下文论述，安全交易插件105支持某些类型的网络交易，诸如与网站131或其他服务器的HTTP或HTTPS交易。在一个实施例中，响应于由安全企业或Web目的地130内的网络服务器131(下文中有时简称为“服务器130”)插入到网页HTML代码中的特定HTML标签来启动安全交易插件。响应于检测到此类标签，安全交易插件105可将交易转发到安全交易服务101以进行处理。另外，对于某些类型的交易(例如，安全密钥交换)，安全交易服务101可开启与当地交易服务器132(即，与网站位于同一地点)或异地交易服务器133的直接通信信道。

安全交易服务器132至133耦接到安全交易数据库120，安全交易数据库120用于存储用户数据、验证装置数据、密钥以及支持下文所述的安全验证交易所需要的其他安全信息。然而，应该指出的是，本发明的基本原理不需要分离图1A所示的安全企业或web目的地130内的逻辑组件。例如，网站131和安全交易服务器132至133可在单个物理服务器或分开的多个物理服务器内实施。此外，网站131和交易服务器132至133可在用于执行下文所述的功能的一个或多个服务器上所执行的集成软件模块内实施。

如上所述，本发明的基本原理不限于图1A所示的基于浏览器的架构。图1B示出替代性具体实施，其中独立应用程序154利用由安全交易服务101提供的功能来经由网络验证用户。在一个实施例中，应用程序154被设计为建立与一个或多个网络服务151的通信会话，这些网络服务依赖于安全交易服务器132至133来执行下文详细描述的用户/客户端验证技术。

在图1A和图1B所示的任一个实施例中，安全交易服务器132至133可生成密钥，这些密钥接着被安全地传输到安全交易服务101并存储到安全存储装置120内的验证装置中。另外，安全交易服务器132至133管理服务器端上的安全交易数据库120。

与远程注册验证装置并向依赖方进行验证相关的某些基本原理将结合图2至图5进行描述，然后详细介绍使用安全通信协议建立信任的本发明实施例。

图2示出了用于在客户端(例如，图1A至图1B中的客户端100上的装置110-112)上注册验证装置的一系列交易。为了简单起见，安全交易服务101和接口102被组合在一起作为验证客户端201，包括安全交易服务器132至133的安全企业或Web目的地130被表示为依赖方202。

在注册验证器(例如，指纹验证器、语音验证器等)期间，在验证客户端201和依赖方202之间共享与验证器相关联的密钥。回顾图1A至图1B，密钥存储在客户端100的安全存储装置120和由安全交易服务器132至133使用的安全交易数据库120内。在一个实施例中，密钥是由安全交易服务器132至133中的一个生成的对称密钥。然而，在下文论述的另一个实施例中，使用了不对称密钥。在该实施例中，可以由安全交易服务器132至133生成公共/私有密钥对。公共密钥然后可由安全交易服务器132至133存储，并且相关私有密钥可存储在客户端上的安全存储装置120中。在一个另选的实施例中，密钥可在客户端100上生成(例如，由验证装置或验证装置接口而不是安全交易服务器132至133生成)。本发明的基本原理不限于任何特定类型的密钥或生成密钥的方式。

在一个实施例中采用一种安全密钥预置协议以通过安全通信信道与客户端共享密钥。密钥预置协议的一个示例是动态对称密钥预置协议(DSKPP)(例如，参见请求注释(RFC)6063)。然而，本发明的基本原理不限于任何特定密钥预置协议。在一个特定实施例中，客户端生成公共/私有密钥对并向服务器发送公共密钥，可以利用证实密钥证实它们。

转到图2所示的具体细节，要启动注册流程，依赖方202生成随机生成的质询(例如，密码随机数)，验证客户端201必须在装置注册期间呈现此质询。该随机质询可在有限时间段内有效。作为响应，验证客户端201发起与依赖方202的带外安全连接(例如，带外交易)，并使用密钥预置协议(例如，上文提到的DSKPP协议)与依赖方202通信。为了发起安全连接，验证客户端201可以向依赖方202返回随机质询(可能带有在随机质询上生成的签名)。此外，验证客户端201可以传输用户的身份(例如，用户ID或其他代码)和待注册的验证装置的身份(例如，使用唯一地识别所注册的验证装置的类型的验证证实ID(AAID))。

该依赖方利用用户名或ID代码(例如，在用户账户数据库中)定位用户，(例如，使用签名或简单地比较随机质询与发送过的质询)证实随机质询，证实验证装置的验证代码(如果发送了验证代码(例如，AAID))，并在安全交易数据库(例如，图1A至图1B中的数据库120)中为用户和验证装置创建新条目。在一个实施例中，依赖方维护其接受验证的验证装置的数据库。它可以通过AAID(或其他验证装置代码)查询此数据库，以确定所注册的验证装置是否是验证可接受的。如果是，那么它将继续进行注册过程。

在一个实施例中，依赖方202为注册的每个验证装置生成验证密钥。它向安全数据库写入密钥，并利用密钥预置协议向验证客户端201发回密钥。一旦完成，验证装置与依赖方202便在使用对称密钥的情况下共享相同密钥，或者在使用不对称密钥的情况下共享不同密钥。例如，如果使用不对称密钥，那么依赖方202可以存储公共密钥并向验证客户端201提供私有密钥。在从依赖方202接收私有密钥时，验证客户端201向验证装置中预置密钥(在与验证装置相关联的安全存储装置之内存储密钥)。然后它可以在验证用户期间使用该密钥(如下所述)。在一个另选的实施例中，密钥由验证客户端201生成并使用密钥预置协议向依赖方202提供密钥。在任一种情况下，一旦完成预置，验证客户端201和依赖方202均具有密钥，且验证客户端201通知依赖方已完成。

图3示出用于向注册的验证装置验证用户的一系列交易。一旦完成装置注册(如图2中所述)，依赖方201将接受由客户端上的本地验证装置生成的验证响应(有时称为“令牌”)作为有效的验证响应。

转向图3中所示的具体细节，响应于用户发起与依赖方202的需要验证的交易(例如，发起从依赖方网站进行支付，访问私有用户账户数据等)，依赖方202生成包括随机质询(例如，密码随机数)的验证请求。在一个实施例中，随机质询具有与其关联的时间限制(例如，它在指定的一段时间内是有效的)。依赖方还可以标识要由验证客户端201用于验证的验证器。如上文所提及，依赖方可以注册客户端上可用的每个验证装置，并且存储每个注册的验证器的公共密钥。因此，它可以使用验证器的公共密钥或可以使用验证器ID(例如，AAID)来标识要使用的验证器。或者，它可以为客户端提供验证选项的列表，用户可以从该列表进行选择。

响应于接收到验证请求，可以为用户呈现请求验证的图形用户界面(GUI)(例如，形式为验证应用/应用的网页或GUI)。用户然后进行验证(例如，在指纹读取器上轻扫手指等)。作为响应，验证客户端201生成验证响应，该验证响应包含随机质询上的签名，带有与验证器相关联的私有密钥。它还可以包括其他相关数据，例如，验证响应中的用户ID代码。

在接收验证响应时，依赖方可以证实随机质询上的签名(例如，使用与验证器相关联的公共密钥)并确认用户的身份。一旦完成验证，用户便获许进入与依赖方的安全交易，如图所示。

可以使用安全通信协议，例如传输层安全(TLS)或安全套接字层(SSL)在依赖方201和验证客户端202之间建立用于图2至图3所示的任何或所有交易的安全连接。

使用安全传输协议建立信任的系统和方法

如上文所提及，在使用远程验证的某些具体实施中，诸如TLS或SSL的安全通信协议可以用于在依赖方与验证客户端之间安全地交换数据。简而言之，TLS和SSL是在通常不安全的通信信道(例如，因特网)上提供安全通信的密码协议。这些协议使用实施非对称密码的X.509证书来交换对称密钥。然后在通信会话期间使用此对称密钥来加密双方之间的数据信道。尽管此详细描述的其余部分将集中于TLS的使用，但是可以使用诸如SSL的其他密码协议来实施本发明的基本原理。

在一个实施例中，TLS用于保护依赖方与验证客户端之间的通信信道并验证发送者的身份。也就是说，通过使用X.509证书所支持的非对称密码，一方(例如，验证客户端)能够验证对方(例如，依赖方)的身份，或反之亦然。对方的身份可以体现在代码或名称中，该代码或名称例如识别依赖方(例如，“RPNAME”)或识别验证客户端、或该客户端上用于与依赖方建立通信信道的特定应用程序(例如，“AppID”)。当验证客户端与依赖方之间存在直接信道时(如上文提供的示例中)，由于通常通过因特网发送数据并且TLS总是可用的，使用TLS可很好地满足此用途。

然而，在诸如iOS^TM、Android^TM和近场通信(NFC)交易的某些计算装置平台上，此TLS假设不成立。如图4大致所示，在这些平台上，预期第三方代码(例如，依赖方应用程序410)管理依赖方402与验证客户端401之间的所有通信。因此，依赖方应用程序410基本上类似于依赖方402与验证客户端401之间的中间人。此外，验证客户端401没有关于依赖方应用程序410所建立的TLS连接的有效性的信息。它必须仅依赖第三方代码来做出此决定，并使用IPC机制来转交验证请求(如图所示)。这些IPC机制可以访问发送应用程序的识别代码(例如，“集束ID”)，但是使用集束ID核验发送者/接收者的身份(例如，RPNAME、AppID)的真实性主要依赖于操作系统、以及对分发依赖方应用程序的应用程序商店所实施的审查过程的关注。

在使用NFC时，情况甚至更糟，因为没有诸如伴随传输机制的集束ID的识别代码。NFC由一般的多用途互联网邮件扩展(MIME)处理程序处理。验证客户端401必须假定声称的任何识别代码(例如，RPNAME)是正确的，并且验证请求来自有效源。

更具体地讲，在iOS装置上，使用多重验证客户端的AppDelegate代码中的openURL()调用的sourceApplication参数来确定正在与验证客户端401通信的应用程序410：-(BOOL)application:(UIApplication*)application openURL:(NSURL*)url sourceApplication:(NSString*)sourceApplication annotation:(id)annotation

在此示例中，sourceApplication包含调用应用程序的集束ID。集束ID是调用应用程序的plist清单中的唯一字符串，其识别Apple^TM数据库中的应用程序。建议以相反表示法使用公司的基础URL(例如，com.paypal.app)来部分构建集束ID。这样，假定Apple审查此字符串以确保应用程序不试图欺骗其他应用程序。

对于Android装置，首先从系统Binder调用getCallingUid()，以返回分配给依赖方进程的Linux uid，该依赖方进程将当前交易发送到正在处理的多重验证进程，例如：

int callerUId＝Binder.getCallingUid()；；

然后，应用程序从系统PackageManager检索与用户ID相关联的包。使用依赖方的基础URL作为组成部分但以相反表示法为包命名(例如，“com.fido.android.sample.app.paypal”)。例如：

String packageNames[]＝mPackageManager.getPackagesForUid(callerUId)；；

在使用NFC时，不存在可以映射到对方标识符(例如，RPNAME或AppID)的可信任信息片段。在Android上使用NFC时，请求通过多用途互联网邮件扩展(MIME)处理程序到达，并且不可识别调用者。因此，包含在请求中的任何标识符可以是有效的，也可以不是有效的。

本发明的一个实施例通过使用可信证书签名验证请求和源标识符来解决这些限制问题。可针对移动装置的根证书存储进行验证的来自web服务器的SSL X.509证书是在一个实施例中采用的一个选项。然而，依赖方的验证服务器可能没有访问该密钥的权限。专门为验证服务器生成新X.509证书是另一个选项，但这意味着管理又一个X.509证书的附加开销。

为了避免这些问题，图5所示的本发明的一个实施例使用来自分散式公共密钥基础设施(PKI)的自签名证书来签名来自依赖方502的验证服务器520的验证请求和对应的源标识符(例如，“RPNAME”标识符)。具体地讲，在一个实施例中，自签名证书包括私有密钥522、以及存储在验证服务器520上的公共密钥文件525中的一个或多个公共密钥。不同于X.509证书，这些自签名证书不能被它们自身信任，因为没有将它们连接到根可信证书的链。

在一个实施例中，为了建立信任，通过使用可信证书526(例如，用于打开TLS连接的现有X.509可信证书)建立的安全通信信道，将存储在web服务器上的公共密钥文件525中的公共密钥传输到客户端装置500(例如，移动智能电话)上的验证客户端530。使用TLS可确保从正确的所有者获得公共密钥文件525中的易受攻击的自签名公共密钥，因为可以针对根证书存储(如果使用X.509或其他已知标准)核验用于通过因特网从web服务器传输这些密钥的可信证书/密钥526。然后，文件526中的那些自签名公共密钥可以被隐含地信任，并且用于核验包括源标识符(例如，RPNAME)的验证请求523。

验证服务器520可能以与上文参考图3描述的相同方式和相同情况生成验证请求523。例如，验证服务器520可以生成随机质询并且识别待使用的客户端侧验证器(例如，使用针对验证器注册的公共密钥)。随机质询和验证器ID信息可以封装在验证请求523中。

另外，在一个实施例中，使用分散式PKI的私有密钥522来签名验证请求523。如所提及的，在一个实施例中，私有密钥522对应于文件525中的公共密钥。例如，可以使用公共密钥中的一个来证实私有密钥522所生成的任何签名。

再次，为了建立信任，通过使用可信证书521(例如，用于打开TLS连接的现有X.509可信证书)建立的安全通信信道，将使用验证服务器520上的私有密钥522签名的验证请求523传输到客户端装置500上的依赖方应用程序510。在一个实施例中，可信证书521与可信证书526相同，后者用于与验证客户端530建立TLS信道。然后，使用TLS信道将私有密钥签名的验证请求523连同源标识符(例如，用于识别依赖方的RPNAME)一起传输到依赖方应用程序510。

在一个实施例中，依赖方应用程序510提取底层私有密钥签名的验证请求(即，拆解TLS数据)，并且将该验证请求提供给客户端装置500上的验证客户端530。依赖方应用程序510可以使用已知的进程间通信(IPC)机制与验证客户端530通信。然而，本发明的基本原理不限于用于在客户端装置500上交换信息的任何特定通信机制。

在接收私有密钥签名的验证请求523时，验证客户端530使用来自公共密钥文件的公共密钥来验证签名。如果签名是有效的，则其接着如上所述生成验证响应。例如，响应于用户的成功验证，其可以使用验证器的私有密钥来生成包括在验证请求523中的随机质询上的签名，并且将所得的验证响应传输到验证服务器520(例如，直接传输或经由依赖方应用程序510传输)。一旦验证服务器520使用对应的公共验证器密钥核验该签名，向依赖方502验证用户并且允许用户完成期望的交易。

使用本文所述的技术，验证请求523和源标识符(例如，RPNAME)由集中式SSL X.509密钥以加密方式核验，同时仍保持分散式PKI提供的灵活性和极小的管理开销。通过利用包含那些证书的文件位于某个确定的web服务器上的事实，隐含地信任自签证书的有效性具有一定风险。任何能够在web服务器上修改此文件的人都可以更改公共密钥。然而，只要像能够管理X.509证书一样谨慎地保护对文件的访问，通过任一解决方案授予的信任都应当是类似的。

图6中示出根据本发明的一个实施例的方法。该方法可使用图5所示的架构来实施，但不限于任何具体架构。

在601处，在代表依赖方的验证服务器处生成第一验证相关通信。在一个实施例中，第一验证相关通信包括上文所提及的验证请求523(例如，包含随机质询、验证器ID等)。

在602处，使用来自分散式公共密钥基础设施(PKI)的自签名证书的第一密钥来签名第一验证相关通信。在一个实施例中，第一密钥包括上文所论述的私有密钥522。

在603处，使用现有可信通信基础设施，与客户端装置上的依赖方应用程序建立第一安全信道。在一个实施例中，使用现有可信通信基础设施包括使用可信X.509证书与依赖方建立安全传输层安全(TLS)信道。

在604处，通过第一安全通信信道将第一验证相关通信传输到依赖方应用程序。如所提及的，在一个实施例中，与通信一同提供的源标识符(例如，RPNAME)。

在605处，使用现有可信通信基础设施，与客户端装置上的验证客户端建立第二安全通信信道。如所提及的，在一个实施例中，使用现有可信通信基础设施包括使用可信X.509证书与依赖方建立安全TLS信道。

在606处，通过第二安全通信信道将来自分散式PKI的自签名证书的第二密钥传输到验证客户端。在一个实施例中，第二密钥包括与来自分散式PKI的自签名证书相关联的公共密钥。还可以经由公共密钥文件526(如上文所论述)提供一个或多个附加密钥。

在607处，从依赖方应用程序向验证客户端提供具有签名的第一验证相关通信。在一个实施例中，这是遵循客户端装置上的现有进程间通信(IPC)机制来执行的。

在608处，验证客户端使用第二密钥验证通过第一密钥生成的签名。如果验证成功，则验证客户端响应于第一验证相关通信而生成第二验证相关通信。例如，如上文所论述，如果第一验证相关通信包含验证请求，则第二验证相关通信可包含验证响应。为了生成响应，验证客户端可以首先要求用户在客户端装置上执行验证(例如，轻扫手指、记录语音、输入代码等)。如果验证成功，则验证客户端可以传输成功验证的指示以及其他可核验的信息(例如，随验证请求一起提供的随机质询)。一旦验证服务器接收到第二验证相关通信，可以向依赖方验证用户，并且允许用户进入与依赖方的交易。

示例性数据处理装置

图11是示出可在本发明的一些实施例中使用的示例性客户端和服务器的框图。应当理解，尽管图11示出计算机系统的各种组件，但其并非意图表示互连组件的任何特定架构或方式，因为此类细节与本发明并不密切相关。应当理解，具有更少组件或更多组件的其他计算机系统也可与本发明一起使用。

如图7所示，计算机系统700，其为一种形式的数据处理系统，包括总线750，该总线与处理系统720、电源725、存储器730和非易失性存储器740(例如，硬盘驱动器、快闪存储器、相变存储器(PCM)等)耦接。总线750可通过如本领域中熟知的各种桥接器、控制器和/或适配器来彼此连接。处理系统720可从存储器730和/或非易失性存储器740检索指令，并执行这些指令以执行如上所述的操作。总线750将以上组件互连在一起，并且还将那些组件互连到可选底座760、显示控制器与显示装置770、输入/输出装置780(例如，NIC(网络接口卡)、光标控件(例如，鼠标、触摸屏、触摸板等)、键盘等)和可选无线收发器790(例如，蓝牙、WiFi、红外等)。

图8是示出可在本发明的一些实施例中使用的示例性数据处理系统的框图。例如，数据处理系统800可为手持式计算机、个人数字助理(PDA)、移动电话、便携式游戏系统、便携式媒体播放器、平板计算机或手持式计算装置(其可包括移动电话、媒体播放器和/或游戏系统)。又如，数据处理系统800可为网络计算机或在另一个装置内的嵌入式处理装置。

根据本发明的一个实施例，数据处理系统800的示例性架构可用于上文所述的移动装置。数据处理系统800包括处理系统820，其可包括一个或多个微处理器和/或集成电路上的系统。处理系统820与存储器810、电源825(其包括一个或多个电池)、音频输入/输出840、显示控制器与显示装置860、可选输入/输出850、输入装置870和无线收发器830耦接。应当理解，在本发明的某些实施例中，图8中未示出的其他组件也可为数据处理系统800的一部分，并且在本发明的某些实施例中，可使用比图8所示更少的组件。另外，应当理解，图8中未示出的一个或多个总线可用于使如本领域中熟知的各种组件互连。

存储器810可存储数据和/或程序以供数据处理系统800执行。音频输入/输出840可包括麦克风和/或扬声器以(例如)播放音乐，以及/或者通过扬声器和麦克风提供电话功能。显示控制器与显示装置860可包括图形用户界面(GUI)。无线(例如，RF)收发器830(例如，WiFi收发器、红外收发器、蓝牙收发器、无线蜂窝电话收发器等)可用于与其他数据处理系统通信。所述一个或多个输入装置870允许用户向系统提供输入。这些输入装置可为小键盘、键盘、触控面板、多点触控面板等。可选的其他输入/输出850可为底座的连接器。

本发明的实施例可包括如上文陈述的各种步骤。这些步骤可体现为致使通用处理器或专用处理器执行某些步骤的机器可执行指令。或者，这些步骤可由包含用于执行这些步骤的硬连线逻辑的特定硬件组件执行，或由编程的计算机组件和定制硬件组件的任何组合执行。

本发明的元件还可被提供为用于存储机器可执行程序代码的机器可读介质。机器可读介质可包括但不限于软盘、光盘、CD-ROM和磁光盘、ROM、RAM、EPROM、EEPROM、磁卡或光卡、或者适合于存储电子程序代码的其他类型的介质/机器可读介质。

在整个前述描述中，出于解释的目的，陈述了许多特定细节以便透彻理解本发明。然而，本领域的技术人员将容易明白，可在没有这些特定细节中的一些的情况下实践本发明。例如，本领域的技术人员将容易明白，本文所述的功能模块和方法可被实施为软件、硬件或其任何组合。此外，虽然本文在移动计算环境的情形内描述本发明的一些实施例，但本发明的基本原理不限于移动计算具体实施。在一些实施例中，可使用几乎任何类型的客户端或对等数据处理装置，包括(例如)台式计算机或工作站计算机。因此，应依据所附权利要求书确定本发明的范围和精神。

本发明的实施例可包括如上文陈述的各种步骤。这些步骤可体现为致使通用处理器或专用处理器执行某些步骤的机器可执行指令。或者，这些步骤可由包含用于执行这些步骤的硬连线逻辑的特定硬件组件执行，或由编程的计算机组件和定制硬件组件的任何组合执行。