优选实施方案的具体实施方式

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

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

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

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

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

用于授权新验证器的系统和方法

在一些情况下，允许使用现有客户端装置上注册的验证器启用新验证器可能是有用的。例如，如果用户购买了具有一组新验证器的新装置，则向用户提供使用现有验证器自动注册所有新验证器的方式将是有益的。

下文描述的本发明的实施方案允许用户使用向一个或多个依赖方注册的、现有的/旧的可信客户端装置来授权新客户端装置上的验证器。具体地讲，这些实施方案可用于启用新的或现有的客户端装置上的新验证器，以及在多个客户端装置之间保持注册同步。

图2提供根据本发明的一个实施方案的验证器授权的高级概览。具有旧的/现有验证器(Aold)202的客户端装置(即，具有向一个或多个依赖方250注册的验证器的装置)与用户的新客户端装置200建立连接。建立连接的具体方式与本发明的基本原理无关。在一个实施方案中，连接包括安全/加密连接(例如，经由SSL、TLS等建立)。可使用各种技术，诸如近场通信(NFC)、蓝牙、Wifi直连、使用快速响应(QR)代码以及建立HTTPS连接，或通过标准网络连接(例如，经由WiFi或以太网)。

在一个实施方案中，一旦在具有Aold 202的客户端与具有Anew 200的客户端之间建立连接，便实施安全协议(下文详细描述)以将注册数据从旧的/现有客户端202传送并集成到新客户端200。例如，在一个实施方案中，旧客户端202向新客户端200发送注册数据，该新客户端然后生成一组新的密钥对(例如，每个依赖方一个密钥对)，并将公共密钥连同新客户端200上的验证器类型的指示一起发送回旧客户端202。具有Aold的客户端然后生成已签署授权对象(例如，使用公共密钥、验证器识别数据和用户账户数据)，并将其发送到每个相应的依赖方250。

如图3所示，可分别在新装置200和旧装置202上执行验证器授权应用程序390、391，以建立安全连接、交换授权数据、以及向每个依赖方250上的安全交易服务304核验注册内容。如本文所用，“旧验证器”(Aold)是用户已经向一个或多个依赖方注册的验证器。“新验证器”(Anew)是用户希望使用当前用于旧验证器的所有依赖方注册内容进行启用的验证器。因此，所述实施方案中的验证引擎311先前已经向依赖方注册了一个或多个旧验证装置322至323。一个实施方案的目标是将注册内容从旧验证引擎311传送到新验证引擎310，以向每个依赖方启用新验证器320至321。

如图所示，新客户端200和旧客户端202均分别包括安全存储装置325和326，用以存储每个依赖方的注册数据(例如，在验证期间使用的公共/私有密钥对)。此外，依赖方250包括安全交易数据库325，用以安全地存储客户端装置200至202中的每一者的注册数据(例如，用户账户数据、验证器识别数据、针对每个验证器提供的公共密钥等)。

在一个实施方案中，用户启动新客户端装置200上的验证器授权应用程序390和旧客户端装置202上的验证器授权应用程序390，以建立初始安全连接。验证器授权应用程序390-391可以是专门设计用于执行本文所述授权操作的移动装置应用程序(apps或applications)。在另一个实施方案中，验证器授权应用程序可为响应于用户指示他/她希望执行授权而执行的浏览器插件(例如，经由具有嵌入式Javascript或其他小程序或可执行程序代码的网页)。此外，验证器授权应用程序390至391可为较大应用程序(诸如被设计为管理向依赖方的验证的验证应用程序)内的软件模块。然而，应该指出的是，本发明的基本原理不限于验证器授权应用程序390至391的任何特定具体实施。

在一个实施方案中，为了批准旧装置202上的授权操作，用户由旧装置上的验证引擎311验证(例如，向用户核验装置322至323提供生物计量输入)。相似地，在一个实施方案中，用户可由新客户端装置200上的验证引擎310核验。这两个核验步骤可为验证器授权应用程序390至391提供授权以执行授权过程。

如上所述，在授权过程开始时，验证器授权应用程序390-391建立安全连接(例如，使用蓝牙、WiFi等)。在一个实施方案中，新客户端装置200上的验证器授权应用程序390接收旧客户端装置202向其注册的每个依赖方的一组注册数据。注册数据可包括用户名和与每个依赖方上的用户账户相关联的唯一代码。这种将用户与每个依赖方相关联的唯一代码在本文中有时称为“AppID”。在依赖方提供多种在线服务的一些实施例中，用户在单个依赖方可拥有多个AppID(依赖方为每种服务提供一个AppID)。

在一个实施方案中，新客户端200上的验证器授权应用程序390然后为每个依赖方生成新的公共/私有密钥对(例如，每个用户名+AppID对一个密钥对)。新客户端200上的验证器授权应用程序390向旧客户端202上的验证器授权应用程序391发送密钥对(或仅发送公共密钥)以及识别每个新验证器类型的验证器ID(例如，验证器证实ID或“AAID”)。然后可提示用户确认新验证器的授权。

在一个实施方案中，验证器授权应用程序391生成已签署授权对象，该已签署授权对象包括针对每个依赖方的AAID、公共密钥和AppID的元组上的签名。在一个实施方案中，使用与依赖方相关联的当前验证密钥(例如，与依赖方的旧验证器相关联的私有密钥)来生成签名。然后，验证器授权应用程序391向每个依赖方验证(例如，经由旧验证引擎311和一个或多个旧验证器322-323)，并且包括已签署授权对象作为验证消息之一的扩展。

在接收到已签署验证消息时，安全交易服务304然后可核验签名(例如，使用与用于生成签名的私有密钥对应的公共密钥)。一旦被核验，它可识别用户账户与AppID并将新验证器的新AAID和新公共密钥存储在安全交易数据库325内。用户可随后使用新验证器320至321进行验证，而无需向每个依赖方250重新注册。

尽管在图2至图3中示出为新用户装置，但本发明的基本原理也可在用户在现有客户端装置上安装新验证器的场景中实施。例如，用户可升级验证器或将验证器添加到现有台式计算机、笔记本或其他类型的客户端。在这种情况下，图3中所示的验证器授权应用程序390-391之间的通信可发生在内部(例如，经由客户端上实现的软件模块之间的内部函数调用)。

图4中示出用于授权新验证器的方法的一个实施方案。该方法可在诸如图3所示的系统的环境内实施，但不限于任何特定系统架构。

在401处，用户触发一个或多个新验证器(Anew)的授权并且与旧验证器(Aold)建立安全通信信道。如所提及的，安全通信信道可经由直接连接(例如，经由NFC、蓝牙等)或通过网络(例如，经由以太网或WiFi连接)建立。

在402处，新验证器接收每个依赖方的用户名和用户/依赖方ID代码。

在403处，新验证器为每个用户名/AppID对(例如，为每个唯一的依赖方账户)生成公共/私有密钥对。

在404处，旧验证器接收密钥对和识别每个新验证器的类型的验证器证实ID代码(例如，AAID)。然后可要求用户确认授权操作。

在405处，旧验证器生成已签署授权对象，该已签署授权对象包括在每个依赖方的AAID、公共密钥和AppID的元组上的签名。如所提及的，可使用与依赖方相关联的当前验证密钥(例如，与依赖方的旧验证器相关联的私有密钥)来生成签名。

在406处，旧验证器向每个依赖方验证，并且包括已签署授权对象作为验证消息的扩展。一旦该操作成功完成，用户就可使用新装置和/或新验证器向每个依赖方验证。

图5以图形方式示出了一系列操作，其中利用旧客户端500上的旧验证器502授权新验证器501与多个依赖方R1-Rn一起使用。如所提及的，在接收到与依赖方中的每个依赖方相关的账户数据之后，新验证器501为依赖方R1-Rn中的每个依赖方生成新密钥对，并将新密钥对提供给旧验证器502。旧验证器502然后生成包含与新验证器501相关的数据(例如，AAID)和用于每个验证器的新密钥的安全授权对象。然后旧验证器向依赖方R1-Rn中的每个依赖方执行验证，并且包括验证对象。在核验(例如，其中核验了授权对象上的签名)之后，在每个依赖方R1-Rn处自动注册新验证器501。

在一个实施方案中，每个依赖方R1-Rn可选择是否接受新验证器501。例如，如果AAID指示验证器类型不够可靠或准确，则依赖方可选择拒绝新注册内容。因此，每个依赖方可维护包含用于所有已知验证器(例如，由AAID识别)的数据的验证器数据库(即，元数据)。然后，每个依赖方可响应于从旧验证器接收到授权对象而查询数据库，确定新验证器的特性，并确定这些特性是否可接受。

在本发明的一个实施方案中，验证器可指定更通用的“确认”方法，其中验证器可由相同实体间接控制，但仍然属于不同用户。例如，在图6中，旧验证器601可以集成到由单个所有者/运营商(例如，公司或政府实体)控制的所有者控制系统601中。该示例中的新验证器612可为属于员工计算机611的验证器，并且可由所有者控制系统601使用已知的可信验证器602来触发对新验证器612的授权。在该示例中，新验证器612与旧验证器602之间的交互可如上所述(例如，新验证器生成新密钥对，并且旧验证器向包括所有者或供应商信任锚622的装置621发送授权对象(例如，用于如同图3中的安全交易服务304的安全交易数据库325一样存储验证器注册数据)。

示例性验证系统架构

应该指出的是，本文中使用术语“依赖方”不仅指尝试与之进行用户交易的实体(例如，执行用户交易的网站或在线服务)，也指代表那个实体实施的安全交易服务器(其可执行本文所述的基础验证技术)。安全交易服务器可由依赖方拥有并且/或者在依赖方的控制下，或者可在作为商业安排的一部分向依赖方提供安全交易服务的第三方的控制下。这些区别在下文论述的图7A至图7B中指示，这些附图示出“依赖方”可包括网站731和其他网络服务751，以及用于代表网站和网络服务执行验证技术的安全交易服务器732至733。

具体地讲，图7A至图7B示出包括用于验证用户的客户端侧组件和服务器侧组件的系统架构的两个实施方案。图7A所示的实施方案使用基于浏览器插件的架构来与网站通信，而图7B所示的实施方案不需要浏览器。可在这些系统架构中的任一者上采用本文所述的各种用户确认和授权技术。例如，验证引擎310、311和验证器授权应用程序390、391可被实施为包括接口702的安全交易服务701的一部分。然而，应该指出的是，上文所述的实施方案可使用除了图7A至图7B所示的那些之外的硬件与软件的逻辑布置来实施。

转到图7A，图示实施方案包括配备有用于登记和验证最终用户的一个或多个验证装置710至712的客户端700。如上所述，验证装置710至712可包括生物计量装置，诸如指纹传感器、声音识别硬件/软件(例如，用于识别用户声音的麦克风和相关联软件)、面部识别硬件/软件(例如，用于识别用户面部的相机和相关联软件)、以及光学识别功能(例如，用于扫描用户的视网膜的光学扫描器和相关联软件)；以及非生物计量装置，诸如可信平台模块(TPM)和智能卡。用户可通过提供生物计量数据(例如，在指纹装置上轻扫手指)来登记生物计量装置，安全交易服务701可将这些生物计量数据作为生物计量模板数据(经由接口702)存储在安全存储装置720中。

尽管安全存储装置720被示出为在验证装置710至712的安全周界之外，但在一个实施方案中，每个验证装置710至712可具有其自己的集成安全存储装置。另外，每个验证装置710至712可以加密保护生物计量参考数据记录(例如，使用对称密钥包裹这些数据记录以使得存储装置720安全)。

验证装置710至712通过由安全交易服务701暴露的接口702(例如，应用程序编程接口或API)以通信方式耦接到客户端。安全交易服务701是用于经由网络与一个或多个安全交易服务器732通信以及用于与在web浏览器704的环境内执行的安全交易插件705接口接合的安全应用程序。如图所示，接口702还可提供对客户端700上的安全存储装置720的安全访问，该安全存储装置存储与每个验证装置710至712相关的信息，诸如装置识别代码、用户识别代码、用户登记数据(例如，所扫描的指纹或其他生物计量数据)，以及用于执行本文所述的安全验证技术的密钥。例如，如下文详细论述，唯一密钥可在注册期间被存储到每个验证装置中并且在经由网络(诸如因特网)与服务器730通信时使用。

一旦用户已向客户端700上的验证装置登记，安全交易服务701就可通过网络向安全交易服务器732-733注册验证装置(例如，使用本文所述的注册技术)，并且随后使用在注册过程期间交换的数据(例如，预置到生物计量装置中的加密密钥)向那些服务器验证。验证过程可包括本文所述的任何验证技术(例如，基于显式或非侵入式验证技术在客户端700上生成保证等级并将结果传输到安全交易服务器732至733)。

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

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

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

在图7A至图7B所示的任一个实施方案中，安全交易服务器732至733可生成密钥，这些密钥接着被安全地传输到安全交易服务701并存储到安全存储装置720内的验证装置中。另外，安全交易服务器732至733管理服务器侧上的安全交易数据库740。

典型验证系统

即使经过多年的IT创新，密码仍然是最广泛使用的验证方法。然而，用户和服务提供商均未正确处理密码，从而使这种形式的验证在本质上不安全。另一方面，已经交付了超过10亿个可信平台模块(TPM)和超过1.5亿个安全元件；麦克风和相机集成在大多数智能手机中，并且指纹传感器和可信执行环境(TEE)呈上升趋势。存在比密码或一次性密码(OTP)更好的验证方法。

在2007年，平均用户有25个帐户，使用6.5个密码，并且一天执行8次登录。如今，情况变得更加糟糕。对600万个帐户的分析显示，10000个常见密码可以访问30％的帐户(Burnett，2011年)。即使当查看银行帐户的密码时，也可以发现73％的用户与至少一个非金融网站共享其在线银行密码(Trusteer，Inc.，2010年)，这意味着当非银行网站遭到黑客攻击时，银行帐户受到威胁。

已经做出了一些用于替换密码的建议，包括验证筒仓、多样化验证和值得信任的客户端环境。

验证筒仓：当前替代技术需要其相应的专有服务器技术。因此，当前验证架构由包括验证方法、相关客户端实施方式和相关服务器技术的筒仓组成。

由研究团体提出的创新验证方法未被广泛部署，因为除了客户端实施方式之外，还需要实施和部署完整的服务器软件。验证公司没有争夺更好的用户核验方法，而面临着为了最佳服务器技术的战斗。

多样化验证：用户可以使用独立的PC、平板计算机或智能手机来进行验证。雇主可以控制一些装置，而其他装置可以由用户控制(David A.Willis，Gartner，2013年)。移动装置的增加的采用和BYOD趋势导致更加多样化的验证格局。满足所有需要的一种验证方法似乎是不可及的。

值得信任的客户端环境：客户端侧恶意软件可以捕捉并公开密码或OTP。它可以更改要在显示后确认的交易，或者它可滥用已验证的通信信道以执行非预期动作。验证(即使通过用户名和密码)需要客户端侧处的至少一个值得信任的组件。

如今，基于密码或OTP的验证的替代方法无法缩放。这主要是由于验证构建块的次优组合。为了解决该限制，本发明的一个实施方案识别可能以各种不同方式实施并且仍导致公知且有功能的验证系统的典型构建块-适合于集成在现有平台功能内。

对密码的最近大规模攻击都集中在服务器侧。此类攻击与用户所采取的努力和安全措施无关。在图8所示的攻击分类中，这些攻击被标记为(1)。针对该单一威胁类别引入保护措施很可能会将攻击者注意力转移到进行攻击以窃取和滥用来自用户装置的验证凭据(2-4)，包括通过模仿用户来窃取和滥用数据(2-3)以及滥用已验证会话(4)。项目(5)和(6)包括用户装置的物理失窃和窃取数据(5)和/或滥用装置来模仿用户。然而，攻击很可能将集中在某种类型的可缩放攻击，即具有某个固定成本但可能是大量可出售项目的攻击。可以对单独装置进行物理攻击，但可缩放性较差。

在本发明的一个实施方案中，代替存储具有相对较低熵的散列密码，可以在服务器上存储不对称公共密钥，并且可以在装置中存储相关私有密钥。根据给定公共密钥计算私有密钥是非常耗资源的，因为它需要分解(RSA)或求解离散对数问题(DSA/ECDSA)。至少应当保护私有密钥免受恶意软件攻击。在一个实施方案中，这是使用客户端装置上的可信执行环境(TEE)或安全元件(SE)来完成的。

考虑到大多数客户端装置始终在线，恶意软件不是提取私有密钥，而是可能简单地尝试滥用它。为了进行保护以免受此类攻击，(a)使用密钥的访问应限于有资格的应用程序，并且(b)需要恶意软件无法仿效的某种类型的用户交互。TrustedUI(GlobalPlatform，2013)可以用于实施这种类型的用户交互。应当注意，安全元件通常没有用户界面并且因此不提供这种类型的保护。

当实施如上所述的保护措施时，验证是安全的。然而，攻击者然后可能集中在攻击控制已验证会话的应用程序。现有的PC感染率(APWG，2014年)证明了这些类型的攻击的可行性。当具有带比当前移动应用程序更高的保护的验证器时，该验证器可以用于显示和检索用户对特定交易的确认。在这种情况下，受感染的应用程序可导致(a)将被用户拒绝的显示的恶意交易或(b)在签署后将被修改的已签署交易，这可由服务器检测。这是TrustedUI实施方式的第二用例。

在一个实施方案中，安全元件用于进行保护以免受物理密钥提取。SE的基础芯片硬件通常实施针对物理攻击的最新保护措施。(剑桥大学Sergei Skorobogatov博士，2011年)。另外，在一个实施方案中，可以使用TrustedUI或其他专用用户核验硬件(诸如指纹传感器)来满足对物理用户交互的需要。

如果攻击者获得对装置的物理访问，则攻击者可尝试滥用密钥而不是提取密钥。为了进行保护以免受此类攻击，使用有效的用户核验方法，其具有较低的误接受率、良好的反欺骗方法和反锤击机制(即以有效地限制可能暴力破解尝试的数量)。

考虑到可缩放攻击是主要的，一个实施方案集中于在实施针对可缩放攻击的对策之后的针对物理攻击的对策。

在客户端侧具有对证实的良好保护是有益的，但实际上，远程方(即服务器侧)也有兴趣了解所使用的安全性。因此，本发明的一个实施方案向远程服务器“证实”客户端侧安全特性。为了是有效的，这些证实技术需要至少与客户端侧保护一样强大。

对于实际解决方案，证实的隐私性也是重要的。如直接匿名证实(DAA)的方法是良好的选择。不幸的是，原始DAA方法在标准硬件上实施时太慢。已改善的基于配对的DAA方案快得多。TCG已将其用于TPMv2(Liqun Chen，HP实验室，以及Jiangtao Li，因特尔公司，2013年)。

典型签名由应用程序所控制的待签署对象和使用私有密钥来计算的签名组成。因此，对于核验器而言，待签署对象中的任何数据仅与控制待签署对象的内容的应用程序一样值得信任。

如图9所示，在一个实施方案中，私有密钥905由已证实的验证器902保护，该验证器比应用程序901更值得信任。验证器可以包括交易确认组件909(例如，以允许用户确认本文所述的确认文本)和用户核验组件906(例如，以允许生物计量或其他类型的用户验证)。在一个实施方案中，证实模块903使用私有密钥905以在对象上生成签名908，其包括验证器属性和应用程序数据以生成已签署对象907。如图所示，在一个实施方案中，待签署对象包括验证器的已证实属性和应用程序数据的级联。已签署对象中使用的已证实属性可以包括，例如，(a)由用户确认的交易文本，(b)与最小PIN长度相对的实际个人识别号码(PIN)长度，或(c)验证器实施方式的固件版本。

所示出的实施方式比现有系统更安全，因为向验证器902授予(而不是向应用程序901授予)密钥905的独占控制。在一个实施方案中，由验证器902独占控制的待签署对象具有为由应用程序901控制的数据(在图9中标识为“应用程序数据”)预留的“时隙”。因此，在该实施方案中，不准许应用程序901任意地创建任何形式的待签署对象。每个已签署对象将看起来类似，因此依赖方910的对象核验模块911可以相信已证实属性是由可信验证器902贡献的。在一个实施方案中，对象核验模块911使用公共密钥和与验证器902相关联的元数据912(例如，验证器类型、型号和/或版本)来核验签名908。

在一个实施方案中，限定了一组典型构建块，其可以用于组装诸如图9所示的验证系统。一组特定的构建块包括：

1.用于生成密码密钥并向远程方证实此类密钥的硬件和/或软件。

2.用于生成已证实签名的硬件和/或软件。

3.用于核验用户的硬件和/或软件。

4.用于将密钥绑定到实体(例如，将此类密钥的“使用”访问限制到一组定义的软件应用程序)的硬件和/或软件。

并非所有构建块必须存在。即使仅使用构建块#1，也可以构建验证系统。可以根据需要添加其他构建块。总体安全性和可用性特征取决于所使用的构建块的特定实施方式。

图10示出一个特定实施方案，其包括客户端侧验证器1001、客户端侧平台1002(例如，使用Android OS或Windows OS的移动装置)、远程方1003和元数据6304。验证器1001的一个实施方案生成验证密钥并且支持向远程方1003证实验证密钥。支持各种证实方法，包括上述方法。还参见FIDO基本证实(Rolf Lindemann，Davit Baghdsaryan和Eric Tiffany，2014年)、DAA(Ernie Brickell，英特尔公司；Jan Camenisch，IBM研究所；Liqun Chen，惠普实验室，2004年)、ECDAA(Ernie Brickell，英特尔公司；Jiangtao Li，英特尔实验室)。

远程方有权访问元数据1004，其使用该元数据来核验证实对象。验证器可以被实施为物理上分离的实体(例如，加密SD卡、USB加密令牌等)，但也可以被物理地嵌入到客户端侧平台中(例如，嵌入式安全元件、TPM、TEE中)。

验证器1001可以任选地具有核验用户的能力。然而，本发明的基本原理不限于任何特定的用户核验方法。然而，远程方可以通过调查证实对象和元数据1004来获悉用户核验方法。

本发明的实施方案不依赖于任何特定的有线协议或协议消息编码。唯一要求是，由验证器1001生成的断言(诸如证实对象和已证实的签名对象)需要被远程方1003“理解”。具体的有线格式可取决于特定的平台。

本节旨在给出对于如何可使用这些典型构建块的第一印象。

在当前验证框架(诸如FIDO UAF规范)中，客户端非常“繁重”。通过本文描述的方法，可以轻松地将客户端分为两个部分：(1)应用程序软件开发套件(AppSDK)，其执行所有协议相关任务(这些任务太具体而无法在平台中实施)；以及(2)平台功能，其实施安全相关任务，诸如将密钥绑定到一组软件应用程序。通过这种方法，作为单独实体的客户端(诸如FIDO客户端)消失。

以下是在扩展为支持这些典型构建块的Android平台上实施的FIDO UAF的示例。

证实类型：无需显式设置它。所有Android应用程序将知道它们只能使用Android证实方法(例如，通过FIDO AppSDK)。

AAID：针对每种类别的验证器的唯一标识符(例如，如上所述的“验证器证实ID”)。实质上，使用在创建密钥时指定的用户核验方法，将AAID简化为某一Android密钥库实施方式。密钥库将基于用户核验方法(以及有关其自身的密钥库加密实施方式的静态知识)来查找AAID。

用户名：一个实施方案允许移动应用程序(通过AppSDK)将KeyAlias设置为keyID和用户名(如果存在)的级联。

AppID：使用appID绑定(如果支持)进行寻址。

概括地说，本发明的一个实施方案包括用于向远程方验证客户端侧验证器的系统，该系统包括：

(1)客户端侧验证器，该客户端侧验证器包括(i)用于生成加密密钥对(“验证密钥”)的电路和/或程序代码，以及(ii)用于向远程方证实该密钥生成实体的身份的电路和/或程序代码。

(2)关于验证器的数据，该数据至少包含足够的信息以核验对于远程方可用的证实。该数据在上面被称为“元数据”。

(3)电路和/或程序代码，该电路和/或程序代码使用所生成的验证私有密钥来执行密码操作以向远程方证明对私有验证密钥的持有。

另外，可能已知验证器将验证私有密钥的使用限于仅对明确定义为待签署的对象执行密码签名操作。该明确定义为待签署的对象包含由验证器控制的数据字段，以及清楚标记为包含任意数据(不受验证器控制)的一个或多个数据字段。验证器可以通过以幻数MN开始对象，然后是明确定义的数据结构来指示此类对象。该签名操作在本文中称为“已证实的签署”。可以自由选择该幻数MN，但它必须是固定的并且众所周知。关于如何设置该幻数的一个示例是“ATTESTED_SIGNATURE”。

另外，在一个实施方案中，客户端侧验证器具有使用任意用户核验方法来核验用户的能力，并且其中该用户核验方法的特性是静态的(即，对于任何验证器，它们不会随时间推移而变化)并且在元数据中进行描述。用户核验方法可以是任意复杂的，并且甚至包括多种生物计量和非生物计量形式(例如，PIN或指纹、与PIN/指纹组合的说话者识别、面部识别等)。

此外，在该系统的一个实施方案中，(a)密钥只能用于已证实的签署，并且(b)验证器具有使用用户核验方法来核验用户的能力，其中用户核验方法的特性在由验证器控制的数据字段中(例如，在已证实的签名中)进行描述。应当注意，用户核验方法可以是任意复杂的，并且甚至包括多种生物计量和非生物计量形式(例如，PIN或指纹、与PIN/指纹组合的说话者识别、面部识别等)。

在一个实施方案中，对私有验证密钥905的访问被限于一组指定的应用程序。另外，该组可以限于由平台(例如，操作系统)认为等效的应用程序。例如，操作系统可以将对验证密钥的访问限于使用与触发密钥生成的应用程序相同的分组签署密钥来签名的应用程序。此外，该组应用程序可以包括由应用程序开发者通过被视为等效的应用程序小方面的列表来视为等效的应用程序。

在又一个实施方案中，验证器902支持安全地显示交易文本并且要求用户确认(或拒绝)该特定交易。交易文本可以密码绑定到已证实签名(即，交易文本的密码散列将被包括在由验证器控制的字段中的一个中)。

本发明的一个实施方案在平台(例如，OS或web浏览器)上实施FIDO UAF/U2F堆栈的安全相关任务(其不属于验证器)，以及将其他协议处理任务的实施留给应用程序并从而移除了在平台中实施特定协议的需要(即移除了具有FIDO客户端的需要)。

用于引导用户绑定的系统和方法

如今，任何用户都可登记到新FIDO验证器或具有正在运送/购买的密钥库的装置，包括合法所有者和潜在攻击者两者。一般来讲，一旦用户首次接收到对具有密钥库的装置的物理访问，FIDO验证器和该装置就被绑定到用户(即，用户登记到验证器/装置)。这与在交付之前为用户个性化的智能卡(例如，EMV银行卡和SIM卡)形成对比。该个性化通常包括用户特定的个人识别号码(PIN)。

有时，在运送FIDO验证器(或具有密钥库的装置)之前，用户已被识别/审查。期望利用在商店(或某一其他地方)执行的身份审查，并且在验证器实际到达用户之前将验证器绑定到用户。本发明的实施方案提供了解决该期望的技术。

在一个实施方案中，假设某一可信识别系统已有权访问(a)用户核验参考数据(例如，生物计量模板或PIN)，或者(b)能够从其导出用户核验参考数据的一些数据，或者(c)通过一些其他系统绑定到用户的一些数据。例如，从某个分支机构中核验的带照片ID卡获取的用户面部图像的副本，或者从政府识别数据库或者通过绑定到验证器并由移动网络运营商(MNO)绑定到帐户所有者的SIM卡获取的用户指纹的照片。方法(a)适用于“你所知道的”因素；方法(b)适用于“你是什么人”因素；并且方法(c)适用于“你所拥有的”因素，如下所述。

一个实施方案包括通往验证器的某种形式的安全通信信道，从而允许将用户核验参考数据单次并且初始注入验证器中(即，在某人未登记其他用户核验参考数据的状态下)。安全通信信道可以是安全地与基于SIM卡的验证器交谈的可信服务管理器(TSM)，或者安全地与基于可信执行环境(TEE)的验证器交谈的TSM，或者其可由验证器用于解密此类数据的一些密码或私有密钥来实施。在任何情况下，验证器的一个实施方案可包括预处理引擎，该预处理引擎将初始参考数据转换为验证器所需的形式。需注意，该预处理也可由可信系统完成。

图11示出了一种具体实施的一个实施方案，其中被审查用户U_V最初向第一依赖方1104提供他/她的身份的核验。例如，依赖方1104可以是用户购买新移动装置的实体店。在该过程期间，PIN或其他识别码可由依赖方1104生成(例如，随机生成或由被审查用户U_V选择)。该识别码是本文所述的用于在注册用户时核验用户身份的初始用户核验参考数据(IUVRD)的一种形式。此外，依赖方1114可将与用户和/或客户端装置相关联的识别数据存储在身份数据库1120内。

随后，在1101处，用户核验数据被安全地提供给用户1112。例如，识别码可以通过防篡改或防拆封(例如，密封)信封邮寄给用户。或者，依赖方1114可在用户购买装置的商店处向用户1114提供识别码。在1102处，通过安全通信信道将IUVRD从依赖方1114提供给验证器1110(例如，在商店处和/或使用依赖方1114和验证器1110已知的密钥或密钥对加密)。在一个实施方案中，可将通信加密成验证器模型/实例以防止滥用。在1103处，当首次向依赖方1115注册验证器1110时，提示验证器用户U_A 1111以输入核验数据。在一个实施方案中，验证器1110包括FIDO验证器，并且依赖方1115包括FIDO服务器。如果用户1111输入正确的核验代码，则验证器1110可在与依赖方1115的交易中(例如，在向依赖方注册验证器1110时)将该核验代码包括为用户1111身份的证据。此外，在一个实施方案中，依赖方1115可在身份数据库中执行查找以确认验证器1110和/或验证器用户U_A 1111的身份。

图12示出了另一个实施方案，其中生物计量数据最初在被审查用户U_v 1112与依赖方1114之间的KYC过程期间作为IUVRD被捕获。例如，在1201处，可捕获用户面部的图像，并且可生成面部识别模板，可捕获用户指纹，和/或可执行语音识别。在1202处，通过安全通信信道将IUVRD提供给验证器1110。这可例如在商店处完成和/或可被加密并通过网络传输到验证器1110(例如，使用依赖方1114和验证器1110已知的密钥或密钥对)。在1203处，提示验证器用户U_A 1111诸如通过分析用户面部的图片、收集用户指纹和/或记录用户语音来收集生物计量数据。验证器1110将收集的数据与IUVRD生物计量数据进行比较，并且如果检测到匹配，则在向依赖方1115注册期间提供用户身份的证据。此外，依赖方1115可在初始由依赖方1114填充的身份数据库1120中执行查找，以进一步核验用户1111的身份。

图13示出了另一个实施方案，其中在KYC进程期间或之后，向用户1111提供身份模块1310，该身份模块可包含依赖方1114已知的对称密钥。在一个实施方案中，身份模块1310包括用户身份模块(SIM)卡；然而，本发明的基本原理不限于任何特定形式的身份模块。在1302处，依赖方1114向验证器1110提供质询(例如，随机生成的随机数)。在1303处，验证器通过使用对称密钥在随机数上生成签名来核验身份模块1310的存在。然后该验证器在注册期间向依赖方1115提供该签名。依赖方1115然后可通过将该签名传送到依赖方1114来核验用户1111的身份，依赖方1114可使用对称密钥来核验签名。依赖方1115还可在身份数据库1120中执行查找，如前所述。

所述验证器1110的一个实施方案支持用于FIDO注册的新IUVRD、一次性UVRD和/或一次性身份绑定句柄(OT-IBH)扩展。该扩展包括加密的用户核验数据(或可从中导出用户核验数据的数据，或散列或加密的身份绑定句柄)。

在IUVRD扩展的情况下，如果尚没有用户登记，则验证器1110将使用该数据作为初始用户核验参考数据(IUVRD)并将该用户视为以该数据进行登记。在一个实施方案中，验证器1110如FIDO规范中所指定的那样继续进行(例如，核验用户，生成特定于AppID/依赖方ID的Uauth密钥对，生成注册断言并用证实密钥对其进行签署)。另外，验证器1110的一个实施方案包括扩展，该扩展在已签署注册断言中包含成功指示符以指示数据确实已被验证器使用(并且依赖方1115可假定相关用户登记到该验证器)。该结果指示符可以是简单的布尔值(即，扩展被处理或未被处理)，或者可以是传递给验证器1110的扩展的加密散列值。如果该扩展包括加密到验证器1110但未被发起者验证(例如，PIN的非对称加密)的值，则后者是相关的。如果一些用户已经登记到验证器1110，则该验证器将不处理IUVRD扩展并因此也不将其包括在响应断言中。

在一个实施方案中所使用一次性UVRD扩展的情况下，扩展中包括的用户核验参考数据精确适用于其所属的注册操作。就OT-IBH扩展而言，该扩展包括随机数和可能的附加标识符，后接句柄H与某一随机数和可能的某一附加标识符ID的级联的散列值。更形式化地描述为：OT-IBH＝(Nonce，ID，Hash(H|Nonce|ID))。

图13中示出的实施方案(在本文中有时称为“你所拥有的”具体实施)可利用一次性身份绑定句柄扩展(OT-IBH)。将使用支持对移动网络运营商(MNO)的可扩展认证协议、认证和密钥协定(EAP-AKA，参见RFC4187 https：//tools.ietf.org/html/rfc4187)验证的SIM卡的更具体场景来描述该概念。

在该示例中，依赖方1114可为移动网络运营商，该运营商已审查了账户拥有者并向他们发行SIM(或个性化定制嵌入式SIM；一般来讲，“你所拥有的”令牌)。MNO还(通过移动网络)接收装置标识符(例如，国际移动设备身份，IMEI)并验证SIM(以及因此与之绑定的国际移动用户身份IMSI)。因此，MNO已对绑定到特定移动装置的帐户所有者有了很好的了解。如果验证器绑定到此类移动装置，则可利用该现有身份绑定来进行验证器1110的注册。

FIDO规范小心地避免通过验证器1110暴露任何全局关联句柄。因此，本发明的一个实施方案不是仅仅让验证器添加IMEI或IMSI作为注册断言或签名断言的扩展，而是使用不同的方法。

在OT-IBH方法中，假定存在与用户绑定的一些句柄H(例如，通过IMSI或IMEI或两者)。甚至可支持被密码验证或加密的此类句柄H(例如，H＝MAC(IMEI|IMSI)或H＝Enc(key，IMEI|IMSI))。该句柄H由发出SIM的移动网络运营商拥有。

由于该句柄H不依赖于任何特定依赖方(RP)，因此H可被视为全局关联句柄。出于隐私原因，此类全局关联句柄不应被多个依赖方知道。为了实现这一点，一个实施方案从其导出依赖方特定的句柄：Hd＝Hash(H|Nonce|IDrp)，其中IDrp是依赖方标识符，并且其中随机数和IDrp由H的所有者提供。随机数是一些随机值，并且IDrp是与想要利用由MNO执行的身份绑定的依赖方绑定的一些标识符。

MNO可使用后端服务将导出的句柄Hd发布给一些RP，RP将向该后端服务提供一些用户识别信息IDu(例如，MSISDN)，用户可以直接提供这些用户识别信息，或者RP应用程序可以通过装置上的一些现有本地API检索这些用户识别信息。

图14示出了一个具体实施方案，其中依赖方应用程序1402在1401处将用户识别信息(IDu)传输到依赖方1430。在交易1402处，依赖方1430将识别信息传输到MNO 1431，该MNO在1403处以依赖方特定句柄Hd进行响应。在1404处，依赖方1430向依赖方应用程序1412发送FIDO请求。作为响应，依赖方应用程序1412在1405处向验证器1410发送FIDO注册内容或验证请求，并且在1406处，验证器在1406处与SIM 1413执行核验。如果1406处的核验成功，则1407-1408处的FIDO交易包括Hd。如果核验失败，则Hd将不包括在FIDO响应中。

与使用H作为持有者令牌(bearer token)相比，上述实施方案更安全，因为验证器将H加密绑定到由特定验证器生成的断言。这防止了中间人(MITM)攻击，因此允许H的寿命延长。

该实施方案也更隐私保护，因为验证器1410将不透露H；如果应用程序1412通过其他方式诸如与发布H的实体(例如，MNO)的合同关系或经由对移动装置1411上的应用程序1412可用的一些API(用户对其授予访问权限)接收到对H的访问权限，则验证器将仅允许该应用程序核验H。

可实施以下示例性用例。然而，应该指出的是，本发明的基本原理不限于这些特定用例。

用例1：

在一些分支机构/商店中，用户可由识别系统使用例如电子ID读卡器、指纹扫描器或相机进行审查。识别系统核验ID卡的真实性(ID卡是否正被使用)，然后将所捕获的数据(从用户直接捕获或从某个可信凭据诸如政府发行的ID卡捕获)转换为验证器所需的格式。

识别系统加密IUVRD数据(如上所述)并将其与验证器的客户订单一起存储。订单详情被发送到履行中心，并且验证器被交付给客户。

一旦客户首次使用验证器，其将自动触发该验证器向服务器注册，从而提供订单号(或类似标识符)，允许服务器了解潜在用户。服务器然后将适当的IUVRD扩展添加到FIDO注册请求，并且验证器将处理注册请求，如上文所指定。

用例2：

如果用户在家并且在线订购验证器，则用户可提供他/她的带照片ID卡的扫描件作为身份证明。服务器侧的识别系统核验扫描件的完整性并从其中提取IUVRD。如在用例1中那样进行，其中识别系统核验真实性。

用例3：

类似于用例2，但使用PIN和基于PIN的验证器(例如，基于SIM)或支持PIN和一些其他用户核验方法的验证器。

用例4：

有时，装置和/或绑定到装置的实体(例如，用户拥有的东西诸如SIM卡)已经绑定到用户(例如，移动电话账户拥有者)。这种绑定可能已经由一些通用句柄H表示(例如，一些持有者令牌和/或全局关联句柄，如用户的电话号码或装置IMEI，并且甚至可能是加密的或散列的，如例如一个特定依赖方(例如，MNO)所拥有的MAC(电话#+IMEI)或HMAC(MSN+IMEI)。一个实施方案允许依赖方以保护隐私的方式向验证器询问该验证器是否以某种方式绑定到该句柄H，而不是经由验证器直接向某个依赖方透露此类句柄H。有关细节请参阅OT-IBH部分。

由于上述至少一个实施方案对于未使用的验证器仅一次有效(除非执行重置为出厂默认值)，因此仅允许验证器供应商(不一定是制造商)一开始就有效地对其进行使用。在一个常见的具体实施中，这将是销售绑定到智能电话的验证器的移动网络运营商。“一次性UVRD”实施方案允许验证器制造商随时使用该方法，并且“选择UVM”实施方案允许任何RP或可能限于特定RP使用该方法。

加密细节

多个密码具体实施选项是可能的。在一个实施方案中，在验证器和识别系统之间共享IUVRD/一次性UVRD/OT-IBH的对称加密密钥。在这种情况下，IUVRD/一次性UVRD/OT-IBH将通过验证加密来保护。或者，可在验证器内使用非对称加密/解密密钥结合非对称公共密钥作为信任锚。IUVRD/一次性UVRD/OT-IBH可由识别系统签署，然后使用公共加密/解密密钥加密。在这两种情况下，可以假设密钥是验证器特定的，以便防止对其他验证器的重放攻击。

隐私影响

当RP能够对其自身的Uauth密钥执行身份绑定时，隐私影响最小。IUVRD扩展允许第一RP在拥有验证器特定的加密材料的情况下执行对验证器的身份绑定。

一次性UVRD扩展允许任何RP在拥有验证器特定的加密材料的情况下对验证器执行身份绑定。

OT-IBH具体实施允许通过一些其他现有方式(例如，一些已经对应用程序可用的原生API或通过一些对RP“自有”句柄H的后端API)被提供对句柄H的访问权限的任何RP以加密方式核验验证器是否确实绑定到其上。

在一个实施方案中，遵循以下隐私政策中的一者或多者。私有Uauth密钥在任何时候都不暴露在验证器边界之外。用户登记到验证器的用户核验参考数据在任何时候都不被验证器透露。验证器在任何时候都不透露其注册到的依赖方的号码或名称。验证器在任何时候都不透露任何全局关联句柄。任何RP在任何时候都不可能修改现有密钥的用户核验参考数据。

RP可以查询验证器以确定其是否与某个用户(由扩展程序指定)绑定。然而，用户参与此类查询(通过用户核验)，并且根据验证器模型，也可能知道相关RP的名称。

用于跨验证器共享密钥的系统和方法

动机

当前FIDO规范(UAF、U2F和FIDO2/Web验证)期望验证密钥(例如，Uauth密钥)专用于各个验证器实例。用户可向每个帐户/依赖方注册多个验证器。如果用户丢失任何(除了上次注册的)验证器，则他们可简单地向剩余验证器之一验证，然后注册新的/替换验证器。

实际上，用户有两个痛点。首先，如果用户丢失上次注册的验证器，则依赖方需要将用户推送通过账户恢复程序。账户恢复是很伤脑筋的过程，甚至可能涉及带外检查。账户恢复有时也是有风险的过程，并且不如FIDO验证安全/可信。

除了注册新验证器之外，用户还必须单独地在每个依赖方处撤销注册丢失/被盗的验证器，并在每个依赖方处注册新验证器。注册新验证器或撤销注册旧验证器的过程可能是很伤脑筋的，因为用户通常具有多个账户。

本文所述的本发明的实施方案使用客户端侧生物计量解决方案解决了上述问题。

方法

一种方法是保持每个Uauth密钥专用于一个验证器，并提出用于依赖方的标准化注册/撤销注册API以用于自动添加/移除验证器(如上文相对于某些实施方案所述)。然而，跨依赖方来标准化Web API具有挑战性并且需要时间。因此，不能保证成功。

本发明的一个实施方案扩展了上述具体实施以跨多个验证器共享密钥。

传统FIDO验证器

注册附加的验证器需要每个依赖方进行一次手动操作。该手动操作甚至可包括多个步骤(例如，打开应用程序、点击注册附加验证器、执行用户核验)。这是本领域已知的传统FIDO模型。

经由云服务同步包裹的Uauth密钥

在本发明的一个实施方案中，用户使用相同模型的不同验证器实例(例如，由AAID/AAGUID识别)。根据FIDO规范，此类验证器将具有类似的安全特性，没有任何验证器提供比元数据声明中所声明的更低的安全性。因此，例如，该类别的验证器可以要求可信执行环境(TEE)安全性，并且一些具体实施实际上甚至可以使用安全元件进行密钥保护。更具体地讲，一个验证器可使用TEE被绑定到智能电话以进行密钥保护、匹配器保护和交易确认显示，并且可使用指纹作为用户核验方法。共享该AAID的另一个验证器可被实现为具有集成指纹传感器和电子墨水交易确认显示器并且使用安全元件进行密钥和匹配器保护的智能卡。

另外，这些验证器可允许用户：

a)将验证器持久存储(即，私钥材料以及相关用户名和AppID)的副本以包裹形式存储在云服务上。只有属于同一用户定义组的验证器才能解包这些被包裹的持久数据块。

b)第一验证器定义由对称包裹密钥表征的该组。用户可通过批准第一验证器上的“加入”过程来将另外的验证器添加到该组。

验证器加密细节

在一个实施方案中，验证器支持FIDO功能(例如，其具有FIDO证实密钥并且支持FIDO Uauth密钥的生成)。然而，应该指出的是，本发明的基本原理不限于FIDO具体实施。图15示出了一种示例性实施方案，其中第一客户端装置1518包括加入组Aj的验证器并且第二客户端装置1519包括已加入组Ag的验证器。Aj、Ag中的每个验证器包括物理验证装置1521-1522、用于实施本文所述技术的具有密钥同步逻辑部件1520-1521的验证引擎1511-1512，以及用于存储本文所述各种类型的加密数据的安全存储装置1625-1626。虽然一些细节未示出，但是客户端装置1519可以存储与客户端装置1518相同的所有数据。如图15所示，在一个实施方案中，每个验证器：

a)具有公共云存储访问ID加密密钥(CSEK)1501、1511(例如，作为信任锚)。

b)具有由每个加入程序覆写的随机组ID(例如，UUID)1502、1512，该每个加入程序由验证引擎3710至1511的密钥同步逻辑部件1520至1521实施。

c)具有单独的非对称包裹密钥加密密钥(WKEK)1503、1513。其可在首次使用时由验证器3710至1511生成，并且使得在验证器之外无法访问。

d)具有对称的包裹密钥(WK)1504、1514，该包裹密钥可在首次使用时生成并由每个加入程序覆写。

e)在一个具体实施中，密钥同步逻辑部件1520-1521实现以下加入过程。存在可要求验证器Aj加入现有验证器组的API函数。要加入的验证器Aj生成随机数值，向用户请求许可(即，触发在显示器中显示加入过程指示符和随机数值的用户核验)，将其AAID 1505和公共WKEK 1503附加到随机数值，并使用其证实密钥1506对其进行签名。该数据块被称为“加入块”或“信任块”。

f)加入组Ag中的一个验证器接收到由密钥同步逻辑部件1521核验的加入块。这是可能的，因为验证器都知道用于签名核验的可接受公共证实密钥(信任锚)。验证引擎1511在其显示器中显示随机数、AAID 1505和加入请求指示符。如果用户批准该动作(例如，通过正常用户核验)，则密钥同步逻辑部件1521将使用在加入块中接收的公共WKEK 1503加密包裹密钥(WK)1514和组ID 1512。在加入响应块中调用该数据块。

g)Aj解密加入响应块并存储包裹密钥(WK)1514和组ID 1512。

h)一个实施方案支持API函数以从验证器Aj检索同步拉取请求(给定从云服务1550检索的随机数值)。验证器Aj上的密钥同步逻辑部件1520返回服务器提供的随机数、组ID 1502以及由CSEK 1501加密的内部持久存储的散列值(例如，同步拉取请求)的级联。该功能由外部模块(例如，ASM、验证器配置应用程序)触发。一旦云服务1550接收到同步拉取请求，安全交易服务4004解密该块并将状态散列值与连同最新数据块一起接收的散列值进行比较。如果结果不同，则其返回同步拉取响应，即由WKEK 1503加密的最新包裹数据块，否则其返回“无更改”代码。

i)支持API函数以处理同步拉取响应。密钥同步逻辑部件1520使用其私有WKEK1503解密该块，然后使用对称包裹密钥(WK)1504解包数据。如果这两个操作都成功，验证引擎3710相应地更新其内部持久存储。需注意，该更新程序支持合并各种元件(即，在该验证器上生成的尚未同步到云1550的密钥)。

j)支持另一个API函数以触发在验证器中生成同步推送请求。该API函数触发密钥同步逻辑部件1520返回随机数、组ID 1502、与已包裹持久存储级联的内部持久存储的散列值，所有这些都用CSEK 1501加密(即，使得云服务1550可以读取随机数、组ID 1502和散列值，但其无法解包包含私钥材料的持久存储)。需注意，验证器首先需要与云端1550执行同步拉取，以便在生成同步推送请求之前合并更改。

特性

使用上述方法，可以通过单个操作容易地将新验证器添加到该组中。加入过程可独立于云服务执行。然而，一个缺点是，如果用户失去其上次注册的验证器，则需要执行完整的账户恢复，这对用户来说是很繁琐的。

经由云服务同步密码保护的Uauth密钥

本发明的一个实施方案类似于上述方法，其中一个区别在于对称包裹密钥(WK)可源自用户提供的密码。具体地讲，对上述步骤(d)补充了用从密码导出的WK(例如，经由专用API函数)覆写当前WK的能力。在一个实施方案中，始终在验证器的安全显示器上输入密码。

此外，在一个实施方案中，上述步骤(h)按照以下段落的粗体部分所指出那样修改。具体地讲，密钥同步逻辑部件1520将返回服务器提供的随机数、组ID 1502、WKEK 1503，以及首先由证实密钥1506签署然后由CSEK 1501加密的内部持久存储的散列值(同步拉取请求)的级联。该功能由外部模块(例如，ASM、验证器配置应用程序)触发。一旦被云服务接收，它就解密该块，核验证实签名，并将状态散列值与连同最新的数据块一起接收的散列值进行比较。该方法(与对WKEK的加密相结合)允许云服务将对已包裹存储块的访问限制为具有正确模型的验证器(例如，防止其他验证器/攻击者对密码的蛮力攻击)。如果结果不同，则其返回同步拉取响应，即由WKEK 1503加密的最新包裹数据块，否则其返回“无更改”代码。

除了上文突出显示的差异之外，(a-j)中的其余操作如先前所述执行。

特性

利用上述方法，很容易通过单个操作将新验证器添加到该组。如果用户丢失上次的验证器，则他可以通过提供其密码来恢复。通过使用相应的经验证的WKEK对已包裹存储块加密来防止对密码的蛮力攻击。然而，一个缺点是云服务提供商仍具有对已包裹存储块的访问权限，因此可能蛮力破解密码。

云端中的回退加入验证器

在一个实施方案中，为了解决上述限制问题，由云服务1550所使用的特殊验证模块1540来保护已包裹数据和CSEK 1501私钥。该验证模块是具有以下特征的独特类型的验证器：

1.该验证器在一个硬件盒中支持多个用户，类似于由支持多个OS帐户的平板电脑使用的绑定UAF验证器。

2.该验证器仅支持经由另一个验证器进行的远程用户核验，该验证器恰好具有在第一次登记时使用的模型。

3.该验证器不允许用户实际使用任何Uauth密钥进行验证，只支持批准其他验证器加入该组。

因此，该云验证器模块1540可以像任何其他验证器那样加入到该组。

验证器加密细节

本发明的一个实施方案类似于先前的方法，但利用用于向云服务登记并使用基于云端的加入验证器的附加技术。这些新技术以粗体突出显示。

在该实施方案中，每个验证器：

a)具有公共云存储访问ID加密密钥(CSEK)1501、1511(例如，作为信任锚)。

b)具有由每个加入程序覆写的随机组ID(例如，UUID)1502、1512，该每个加入程序由验证引擎3710至1511的密钥同步逻辑部件1520至1521实施。

c)具有单独的非对称包裹密钥加密密钥(WKEK)1503、1513。其可在首次使用时由验证器3710至1511生成，并且使得在验证器之外无法访问。

d)具有对称的包裹密钥(WK)1504、1514，该包裹密钥可在首次使用时生成并由每个加入程序覆写。

e)可“登记”到云服务1550以便创建新分区。该过程的一个实施方案可包括FIDO注册：

1.用户获取一个验证器Aj并将其注册到云服务1550。用户还提供他的电子邮件地址以识别他的分区。

2.基于云端的加入验证器1540为注册的验证器Aj创建“分区”。该分区由相关的Uauth公共密钥识别。每个“分区”具有其自己的一组持久数据(包括密钥材料)。

f)可以“登记”到云服务的现有分区(恢复加入)：

1.用户为现有分区输入他/她的电子邮件地址。

2.用户获取一个验证器Aj并将其注册到云服务。

3.注意，该验证器尚未被批准。用户能够触发的唯一动作是将该验证器用作Aj(并且将基于云端的加入验证器1540用作Ag)的加入过程。在一个实施方案中，只有当该验证器的AAID1505与最初创建该分区的验证器的AAID(例如，AAID1515)相同时，该过程才会成功。

g)支持以下加入过程：

1.存在可要求验证器加入现有验证器组的API函数。要加入的验证器(Aj)将生成随机数值，向用户请求许可(即，触发在显示器中显示加入过程指示符和随机数值的用户核验)，将其AAID和公共WKEK附加到随机数值，并使用其证实密钥对其进行签署。该数据块被称为“加入块”或“信任块”。

2.该功能也由基于云端的加入验证器1540支持。

a.用户首先要求基于云端的加入验证器1540加入该组(由首先“登记”到云服务的验证器Aj进行初始化)。

b.在这种情况下，基于云端的加入验证器担任Aj的角色，并且用户的初始验证器担任Ag的角色。

c.Ag向云服务进行验证并调用Aj.join API函数。云服务1550在调用API函数时将Ag的AAID1515传递到Aj。Aj以加入块进行响应(参见上文)。

d.Ag执行下文的步骤h并将加入响应块发送到Aj。

e.Aj将组ID1502和WK1504存储在相关“分区”中。

h)加入组中的一个验证器Ag接收到加入块，并且密钥同步逻辑部件1521对其进行核验。这是很容易实现的，因为验证器都知道用于签名核验的可接受公共证实密钥(信任锚)。Ag在其显示器中显示随机数、AAID1515和加入请求指示符。如果用户批准该动作(通过正常用户核验)，则验证器将使用在加入块中接收的公共WKEK 1513加密包裹密钥(WK)1514和组ID 1512。在加入响应块中调用该数据块。

i)Aj将解密加入响应块并存储包裹密钥(WK)1504和组ID 1502。

j)一个实施方案支持API函数以从验证器Aj检索同步拉取请求(给定从云服务1550检索的随机数值)。具体地讲，密钥同步逻辑部件1520将返回服务器提供的随机数、组ID 1502、WKEK 1503，以及首先由证实密钥1506签署然后由CSEK 1501加密的内部持久存储的散列值(同步拉取请求)的级联。该功能由外部模块(例如，ASM、验证器配置应用程序)触发。一旦被云服务接收，它就解密该块，核验证实签名，并将状态散列值与连同最新的数据块一起接收的散列值进行比较。该方法(与对WKEK的加密相结合)允许云服务将对已包裹存储块的访问限制为具有正确模型的验证器(例如，防止其他验证器/攻击者对密码的蛮力攻击)。如果结果不同，则其返回同步拉取响应，即由WKEK 1503加密的最新包裹数据块，否则其返回“无更改”代码。

k)支持API函数以处理同步拉取响应。密钥同步逻辑部件1520使用其私有WKEK1503解密该块，然后使用对称包裹密钥(WK)1504解包数据。如果这两个操作都成功，验证引擎3710相应地更新其内部持久存储。需注意，该更新程序支持合并各种元件(即，在该验证器上生成的尚未同步到云1550的密钥)。

l)支持另一个API函数以触发在验证器中生成同步推送请求。该API函数触发密钥同步逻辑部件1520返回随机数、组ID 1502、与已包裹持久存储级联的内部持久存储的散列值，所有这些都用CSEK 1501加密(即，使得云服务1550可以读取随机数、组ID 1502和散列值，但其无法解包包含私钥材料的持久存储)。需注意，验证器首先需要与云端1550执行同步拉取，以便在生成同步推送请求之前合并更改。

特性

利用这种方法，通过单个操作将新验证器添加到该组中是相对容易的。如果用户丢失上次的验证器，则他可以通过提供其密码来恢复。通过使用相应的经验证的WKEK对已包裹存储块加密来防止对密码的蛮力攻击。云服务提供商将不得不破坏基于云端的加入验证器以便蛮力破解密码。因此，基于云端的加入验证器应使用基于安全元件的安全性。证实声明反映了其安全性。

遗憾的是，用户无法撤销其恢复组中的各个验证器成员。

云端中的回退加入验证器和验证器中的自动密钥删除策略。

该方法对先前的方法补充如下。除非验证器持久存储重新同步到云存储，否则每个验证器(除了基于云端的加入验证器之外)将删除其持久私有密钥存储(WK、WKEK、Uauth密钥等)，在可配置时间段之后的证实私有密钥除外。因此，验证器需要可靠的内部时钟/打点器。

用户拥有经由云存储从组中移除各个验证器的能力。如果验证器已被移除，则其不能再同步。

验证器加密细节

该方法补充了如下的先前方法(其中关键特征以粗体突出显示)。验证器支持另一API函数以从验证器检索同步拉取请求(给定从云服务检索的随机数值)。验证器将返回同步拉取响应，即服务器提供的随机数、组ID 1502、WKEK 1503，以及首先由证实密钥签署然后由CSEK 1501加密的内部持久存储的散列值(同步拉取请求)的级联。该功能由外部模块(例如，ASM、验证器配置应用程序)触发。一旦被云服务1550接收，它就解密该块，核验证实签名，并将状态散列值与连同最新的数据块一起接收的散列值进行比较。其返回同步拉取响应，即由WKEK 1503加密的最新已包裹数据块。在一个具体实施中，如果散列值不匹配，则云服务1550使失配计数器递增。非常高的计数器值指示风险增加。

在一个实施方案中，验证器支持API函数以处理同步拉取响应。验证器使用其私有WKEK解密该块，然后使用对称包裹密钥WK解包数据。在这两个操作均成功的情况下，验证器相应地更新其内部持久存储并重置其内部需要云同步打点器。

特性

利用这种方法，很容易通过单个操作将新验证器添加到该组。如果用户丢失上次的验证器，则他可以通过提供其密码来恢复。通过使用相应的经验证的WKEK对已包裹存储块加密来防止对密码的蛮力攻击。

云服务提供商将不得不破坏基于云端的加入验证器以便蛮力破解密码。因此，基于云端的加入验证器应使用基于安全元件的安全性。证实声明反映了其安全性。

此外，在该具体实施方案中，用户可通过将各个验证器成员从恢复组中移除来将它们从该组中“撤销”。

敏感数据迁移卡

本发明的一个实施方案使用专用芯片卡(ICC)而非使用云服务，该专用芯片卡在图16中示出为具有安全存储1626的数据迁移卡(DMC)，用于存储所有Uauth密钥以及甚至存储在客户端装置1518中的所有其他敏感数据的受保护备份。为了“备份”敏感数据，用户经由DMC 1601的安全存储接口1610连接到包含绑定验证器Aj的客户端装置1518(或直接连接到验证器)。用户向验证器Aj确认要将数据备份到DMC 1601。该步骤擦除DMC上的所有现有数据。

根据设置，安全存储接口1610可记住验证器模型(AAID、AAGUID)或具有类似安全特性的模型(例如，受TEE保护的密钥+匹配器等)，并且将仅将数据恢复到相同的模型或具有类似安全特性的模型。

在一个实施方案中，验证器Aj将仅将密钥备份到具有可接受安全特性(例如，具有在验证器中配置的模型)的DMC 1601。DMC 1601将仅将密钥恢复到具有可接受安全特性(例如，具有与原始验证器相同的模型)的验证器中。可使用验证器/DMC证实来实施安全机制。

在一个实施方案中，第二验证器可充当DMC(例如，经由NFC+BLE)。例如，在图15中，存储在客户端装置1518的安全存储1525中的所有密钥可以安全地迁移到客户端装置1519的安全存储1526中。

DMC加密细节

在一个实施方案中，DMC类似于传统(外部)验证器。因此，DMC和支持它的每个验证器可执行上述用于加入和管理加入块或信任块的相同密钥同步技术。

例如，在一个实施方案中，验证器可被“登记”到DMC。这可通过FIDO注册来实现，其中用户获取一个验证器并将其注册到DMC。用户还提供标识符(例如，他的电子邮件地址)以识别其在DMC中的分区(仅在DMC支持多个分区的情况下需要)。此外，DMC可为已注册验证器创建“分区”(在其支持多个分区的情况下，否则使用其唯一的预先配置的分区)。该分区由相关的Uauth公共密钥识别。每个“分区”具有其自己的一组持久数据(包括密钥材料)。

验证器还可被“登记”到DMC的现有分区(恢复加入)。用户输入其针对现有分区的标识符(例如电子邮件地址)，并向DMC注册一个验证器。需注意，该验证器尚未被批准。用户能够触发的唯一动作是将该验证器用作Aj(并且DMC是作为Ag的加入验证器)的加入过程。只有当该验证器的AAID与最初创建该分区的验证器的AAID相同时，该过程才会成功。

此外，在一个实施方案中，存在可要求验证器加入现有验证器组的API函数。该功能也由DMC加入验证器支持。用户首先要求DMC加入验证器加入该组(由首先“登记”到云服务的验证器进行初始化)。在这种情况下，DMC加入验证器担任Aj的角色，并且用户的初始验证器担任Ag的角色。Ag向DMC进行验证并调用Aj.join API函数。DMC在调用API函数时将Ag的AAID传递到Aj。Aj以加入块进行响应(参见上文)。Ag执行下文的步骤h并将加入响应块发送到Aj。Aj然后将组ID和WK存储在相关的“分区”中。

示例性数据处理装置

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

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

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

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

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

用于验证器认可的系统和方法

在一些情况下，尤其是涉及电子支付的那些情况下，多个商家的应用程序需要验证来自用户的支付凭据。如令，类似主账号(PAN)或令牌化PAN的简单持有者令牌用于该目的。这种方法提供了非常有限的安全性，因为此类信息可能被恶意行为者网络钓鱼和使用。

另选地，有时使用逐步验证方案(例如，三域安全或3DS)。此类方案基本上实施“解耦”模型，该模型要求发行者通过带外通道触发逐步验证。如今，经由SMS的一次性密码主要用于这种逐步验证，从而导致购物车放弃率高(例如，据估计为15％)。

类似FIDO的现代验证概念提供显著更高的安全性，并且由3DS v2支持以用于用户到商家的验证。遗憾的是，FIDO验证的设计方式是验证凭据特定于应用程序的，从而导致每个商家需要单独的验证器注册步骤，这增加了不期望的摩擦。

本发明的一个实施方案使用诸如FIDO的高度安全验证技术，但允许无缝认可与支付卡或账户相关的商家特定验证凭据而不是与商家相关的验证凭据。在这种情况下，隐私不是问题，因为根据定义，支付提供商将获悉特定商家从用户接收到付款。因此，该实施方案避免了对每个应用程序的验证器注册的需要，同时仍然允许验证器通过嵌入式AppSDK在商家应用程序中实施。

本文所述的本发明的实施方案可任选地利用2018年10月2日公布的美国专利号10,091，195(′195专利)和2016年9月公布的美国专利号9,413,533(′533专利)中所述的技术。

该以验证器为中心的具体实施的一个实施方案扩展了具有各种新功能的FIDO验证器，这些新功能包括在绑定到同一平台的验证器之间安全(初始)共享用户核验参考数据。此外，一个实施方案允许绑定到同一平台的验证器之间的用户核验参考数据同步。

将参照图19所示的架构描述一个实施方案，该架构包括客户端装置1930，该客户端装置具有用于安全地存储验证数据(例如，密钥)的安全密钥库1925、与验证器实例1911相关联的旧应用程序1901、与验证器实例1912相关联的第一新应用程序1902以及与验证器实例1913相关联的第三新应用程序。

在这些实施方案中使用的应用程序可属于不同的商家，但仍然支持相同的支付方案。为了减少用户的摩擦，应用程序希望在向方案后端1940验证时将该用户的验证凭据无缝地认可到支付方案。

在一个实施方案中，用户最初安装旧应用程序1901，该旧应用程序检查是否已经安装了支持相同“方案”并具有已注册验证器的其他应用程序。如果不是，则在一个实施方案中，用户输入其用户标识符(例如，用户名、或电子邮件地址、或甚至可能被令牌化的PAN)，并且还输入持有者令牌诸如密码或一次性密码(例如，通过SMS接收的密码)。然后用户由后端服务1940进行验证，该后端服务向应用程序1901发出会话令牌。

在一个实施方案中，应用程序1901触发其验证器实例1911的注册(例如，通过AppSDK)。该操作可包括要求用户提供用户核验参考数据(例如，PIN)以及生成验证密钥(FIDO凭证)。

现在参见图20，在一个实施方案中，旧应用程序1901上的同步处理器1921和新应用程序1902中的同步处理器1922实施本文所述的技术。具体地讲，当用户安装新应用程序1902时，应用程序1902检查是否已安装了支持相同“方案”并且具有已注册验证器1911的其他应用程序1901。如果是，则新应用程序1902的同步处理器1922向旧应用程序1901发送认可请求1926以“认可”该应用程序的验证器实例1912。本文所述的同步处理器可在电路、在电路上执行的程序代码或它们的任何组合中实现。

该认可请求1926可包括公共验证密钥和由新应用程序1902的验证器实例1912生成的证实对象。认可请求可包括用于访问私有验证密钥的初始用户核验参考数据的公共加密密钥。

在一个实施方案中，旧应用程序1901的验证器实例1911在接收到来自同步处理器1921的请求时，对照可信FacetID列表核验请求的来源(例如，使用与该请求相关联的调用者识别数据)。该列表可能已由旧应用程序1911从后端服务器1940检索，或者其可能已作为具有一些版本指示的已签署对象由新应用程序1902提供，以便防止重播过时的FacetID列表版本的攻击。

如果认可请求得到肯定地核验，则旧应用程序1901的验证器实例1911生成认可响应1927。该响应1927可以是从“方案”后端服务1940检索的会话令牌，或者它可以是验证器1911在不具有对任何后端服务器的访问权限的情况下创建的已签署认可对象，但包括公共验证密钥和如上所述的证实对象的可能部分或全部。另外参见图2至图6和相关联的文本。还可包括用于获得对相关私有验证密钥的用户访问权限的初始用户核验参考数据。可使用包括在上述认可请求中的公共加密密钥来加密该数据。

在一个实施方案中，认可响应1927返回至调用新应用程序1902的同步处理器1922，该同步处理器将认可响应1927传递给验证器实例1912。验证器实例1912检索响应1927中包括的用户核验参考数据，使用密钥库1925对其解密并更新其自己的状态，以在使用私有验证密钥之前要求该新的用户核验参考数据。

一旦到后端服务1940的网络连接可用，新应用程序1902的同步处理器1922就将认可响应1927传输至后端服务1940，并直接地或在证明其拥有与上文所述由验证器实例1912生成的验证密钥中的一个或多个相关的私有密钥之后检索验证会话。

在一个实施方案中，使用相对于图21所述的下文一系列操作来同步用户核验参考数据。在该实施方案中，应用程序的验证器实例1912接收到来自用户的更改核验参考数据的请求。同步处理器1922向安装在支持相同“方案”的相同装置1930上的每个其他应用程序1901、1903发送同步请求2126A-B。

其他应用程序1901、1903中的每一者分别包括同步处理器1921、1923，这些同步处理器传输同步响应2127A-B以及指示对接收更新感兴趣的消息。这些响应2127A-B可以包括要更新的用户核验参考数据的加密密钥，并且还可以包括其他应用程序1901、1903已知的已签署FacetID列表的最新版本。

应用程序的验证器实例1912对照可信FacetID列表核验该消息的来源(例如，使用调用者标识)。该列表可能已由应用程序1902刚刚从服务器检索，或者其可能已作为具有一些版本指示的已签署对象由其他应用程序1901、1903之一提供，以便防止重播过时的FacetID列表版本的攻击。

在2128A-B处，同步处理器1922将更新的用户核验参考数据提供给其他同步处理器1921、1923，从而使参考数据可用于其他验证器实例1911、1913。在一个实施方案中，可以使用在同步响应2127A-B中接收的公共加密密钥来加密经更新的用户核验参考数据。

一个实施方案使用基于支持客户端PIN的FIDO验证器的以ASM为中心的方法，该支持客户端PIN的FIDO验证器如2018年2月27日的客户端到验证器协议(CTAP)实施草案中所述(参见例如https：//fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html#authenticatorClientPIN)。这可包括例如输入ASM(或平台)中并通过API发送到验证器的PIN。该实施方案使用嵌入应用程序中的ASM来收集PIN并将其与安装在同一装置上的其他合适的应用程序共享。

以ASM为中心的方法可以使用与上述那些相同或类似的技术来实现。不同之处在于记住并共享PIN的不是验证器，而是ASM。因此，只要有可能实现与客户端PIN特定的API的ASM接口接合，就可使用支持客户端PIN的任何FIDO验证器。

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

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

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

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