FIDO UAF 结构概述 v1.1
FIDO UAF 结构概述
版本 v1.1
FIDO UAF协议中文文档。
现在FIDO UAF有关的文章还比较少，这主要是文档翻译和UAF系统概要介绍。
FIDO官网
感谢原文作者：
Salah Machani, RSA, the Security Division of EMC
Rob Philpott, RSA, the Security Division of EMC
Sampath Srinivas, Google, Inc.
John Kemp, FIDO Alliance
Jeff Hodges, PayPal, Inc.
摘要
FIDO UAF强大的认证框架使得网络服务提供端能够透明的利用用户终端上已有的安全功能来完成用户身份的认证工作，并在这个过程中避免认证过程中和多认证凭证关联所带来的问题。
FIDO UAF参考架构描述了它的组件、协议及构成其强认证生态系统的接口。
1. 介绍
本文档介绍了FIDO通用认证框架（UAF）的参考架构。本文会方便技术架构师来深入理解FIDO UAF强大的身份认证解决方案和它的相关工业标准。
FIDO UAF将按如下顺序介绍：
FIDO UAF 协议
FIDO UAF 应用程序API和传输绑定（Transport Binding）
FIDO UAF 认证器命令
FIDO UAF 认证器特定模块（Authenticator-Specific Module，ASM）API
FIDO UAF 预定义值注册表
FIDO UAF APDU(Application Protocol Data Unit，应用协议数据单元)
附录文档提供和UAF架构相关的重要信息：
FIDO AppID和Facets规范
FIDO 元数据语句
FIDO 元数据服务
FIDO 预定值注册表
FIDO ECDAA算法
FIDO 安全参考
FIDO 词汇表
以上文档在FIDO联盟网站获取。
1.1 背景
FIDO联盟旨在通过以下方式来改善线上强认证生态：
制定开放、可扩展的、可互操作的线上用户身份认证技术规范，取消对传统密码等的依赖；
制定确保这套标准再全球推广的行业计划方案；
向相关机构提交已成熟化的技术规范以推动标准化制定。
FIDO的核心驱动思想是：
易用性
隐私和安全
标准化
主要工作是使得网络服务提供端能够透明的利用用户终端上已有的安全功能来完成用户身份的认证工作，并在这个过程中避免认证过程中和多认证凭证关联所带来的问题。
FIDO中包含两个关键协议来满足用户使用网络服务的时两种基本模式。两个协议共享了大量的基础内容，不过各自针对不用的使用场景有了不同的发展变化。
Universal Authentication Framework (UAF) 协议
UAF协议允许网络服务端提供无密码和多因子安全的服务。用户通过本地认证机制（例如指纹，人脸识别，声纹，PIN码等）将用户注册到在线服务端。UAF协议允许服务选择哪些安全因子来进行用户认证。一旦注册，当用户需求服务时只需进行身份验证，用户只需重复本地身份验证操作就能完认证过程。当在该设备进行身份验证后，用户将不再需要输入密码。 UAF还可以提供多因子认证的操作，例如指纹+ PIN码等。
本文将着重介绍UAF相关内容。
Universal 2nd Factor (U2F) 协议
U2F协议允许在线服务通过要求用户提供第二个安全因子构成的强认证来增强其现有密码架构的安全性。用户和以前一样通过用户名密码登陆，而后服务端可以在它选择的任何时间点要求用户进行第二安全因子验证。强认证方式可以简单的如4位PIN码，而不会影响其之前原有结构的安全性。在验证期间，还可以通过U盾、点击NFC等方式完成。用户可以在任何支持此协议的在线服务中使用他的FIDO U2F设备。
1.2 FIDO UAF 文件（名词对照）
了解以下名词有助于更好的理解FIDO UAF。
FIDO UAF 概述：本文档，介绍FIDO UAF 框架、协议和规范。
FIDO技术术语：定义FIDO 联盟规范和文件中使用的技术术语和短语。
UAF
UAF协议规范：所有UAF协议消息的消息格式和处理规则。
UAF应用程序API和传输绑定规范：规范客户端应用程序使用FIDO的API和互操作性的配置文件。
UAF认证器命令：UAF认证机构应实现的最基本功能，用以支持UAF协议。
UAF认证器特定模块API：由ASM向FIDO客户端提供的特定于认证器的模块API。
UAF预定义值注册表：定义UAF协议保留的所有字符串和常量。
UAF APDU：将FIDO UAF认证器命令映射到应用协议数据单元（APDU）。
FIDO AppID和Facet规范：用户凭证的范围以及支持应用程序隔离的可信计算基础。可以对哪些应用程序和Web来源可以使用哪些密钥进行访问控制决定。
FIDO元数据语句：FIDO认证过程中用于交互和策略描述的因子、特征、功能等的信息。
FIDO元数据服务：依赖方访问最新元数据语句的基线方法。
FIDO ECDAA算法：定义FIDO认证器的直接匿名证明算法。
FIDO预定义值注册表：定义FIDO协议保留的与多个FIDO相关的所有字符串和常量协议族。
FIDO安全参考：根据与FIDO相关的安全威胁的详细分析，提供对FIDO安全性的分析基于其目标，假设和固有安全措施的协议。
参考架构文档的“介绍”的其余部分主要讲了有关UAF的关键驱动因素，目标和原则。
在后续章节中，本文档会继续介绍以下内容：
对架构定义的组件，协议和API进行更深入的介绍。
一个的FIDO UAF实例和实现它们所需的协议消息流。
FIDO协议与其他相关行业标准的关系。
1.3 FIDO UAF目标
为了解决当下在强认证领域所面临的问题，需要有一个运作良好的生态系统，一个全面、开放、多元化的架构，包括：
多样化的用户设备，无论是个人的、企业发布的还是企业BYOD，多样化的设备运行环境，如家里、办公室、开放场所等。
认证器
依赖方应用程序及其部署环境
满足最终用户和依赖方的需求
非常重视基于浏览器或传统应用的终端用户体验
此解决方案架构必须具有以下特点：
FIDO UAF认证器的发现，认证和配置
通过FIDO UFA认证器实现跨平台的强身份认证协议
统一的跨平台的认证器API
依赖方简单的整合机制
FIDO联盟旨在打造一个开放、 多供应商、跨平台的参考架构，其具有以下目标：
支持多因子强认证：通过两个或更多个安全因子对终端用户的身份认证来使服务提供方避免未经授权的访问。
基于但不限于已有的设备功能：使用设备内置的认证器或功能（如指纹、相机、声纹、嵌入式TPM硬件）来进行用户身份认证，也可以使用一些额外的辅助认证器。
认证机制的可选择性：使服务提供端和用户选择最合适的认证机制来尽量减少特定用户场景下的风险。
简化新认证功能的集成：使组织可以简便的扩展所使用的强认证手段以解决新场景、新挑战并和新的认证器功能所匹配。
保持可扩展性：设计可扩展的协议和API方便以后使用
尽可能利用现有的标准，并使其变得更开放、更具有可扩展性：一个开放、标准化的规范套件会带来一个良性循环的生态系统，并降低部署强认证时遇到的风险、复杂度和成本。现有标准主要有下面的问题，缺乏统一的身份验证器配置和认证，缺少统一的跨平台的用于身份认证API，用户认证过程中更灵活强大的的认证挑战-响应协议。
完善现有的登录模式和认证联合方式：现有的工业解决方案（如OpenID、OAuth、SAML等）已经在减少对密码验证方式和传统认证联合方式的依赖了，但是它们并没有直接解决用户和服务提供端初始的强认证交互过程所面临的问题。
对最终用户隐私的保护：向用户提供控制服务提供方对设备等信息的传播的能力，同时减少服务端潜在的信息传播能力。
统一的最终用户的体验：在所有的平台和类似的身份认证器上创建简单、统一的用户体验。
2 FIDO UAF 高阶架构分析
FIDO UAF架构旨在满足FIDO目标并产生所需的生态系统优势。 它通过使用标准化协议和API填补现状的空白来实现这一点。
下图给出了参考架构及其组件和用户、服务提供端的关系。
2.1 FIDO UAF 客户端
它实现了FIDO UAF 协议中客户端的部分，主要负责：
通过FIDO UAF认证器抽象层的认证器API来完成和特定FIDO UAF认证器的交互；
使用用户设备上（如手机app、浏览器等）特定的代理接口来完成和FIDO UAF 服务端的交互。举个例子：FIDO可能会采用浏览器现有的插件，在app上可能会使用FIDO特定的SDK。随后，用户代理负责将FIDO UAF 传送到服务提供方的FIDO UAF 服务器上。
FIDO UAF 架构确保FIDO客户端软件可以实现跨系统跨平台的能力。尽管每个特定的FIDO客户端是平台相关的，但是组件间的交互会确保平台到平台的一致性的用户体验。
2.2 FIDO UAF服务器
它实现了FIDO UAF协议中服务端的部分，主要负责：
服务端利用FIDO UAF协议通过设备用户代理向FIDO UAF客户端传递信息。
根据已配置的认证器元数据验证FIDO UAF认证器的可靠性，确保只有可信赖的认证器注册使用。
管理用户接入的FIDO UAF认证器的认证联合。
评估用户认证和交易确认响应以确定其有效性。
FIDO UAF服务器一般又服务端作为内部服务器进行部署，或者又第三方外包服务商提供。
2.3 FIOD UAF协议
FIDO UAF协议用于在用户设备和依赖方之间传递信息。这些信息主要包括：
认证器注册：FIOD UAF注册协议使依赖方能够：
发现用户系统或设备上可用的FIDO UAF身份验证器，并把认证器的相关属性传递到服务依赖端，使得后续的安全策略得以确定和执行。
利用FIDO UAF认证机构提供的认证元数据来对认证器的真实性和可靠性进行验证。具体来说，是通过认证器元数据中发布的认证公钥完成验证。
注册认证者，并将其与依赖方的用户帐户相关联。一旦认证者证明了验证方，依赖方可以提供独特的安全标识符，该标识符是依赖方和FIDO UAF身份验证器所特有的。该标示符可以通过{RP,Authentication}这样的对耳朵形式应用在后续的交互过程中，并且这个标示符对其他设备是不可知的。
用户认证：认证过程使用基于加密的挑战-响应认证协议，并且让用户选用认证过程中将要使用的具体认证器。
确保安全的传输过程：如果用户端认证器包含这样的功能，依赖方就只需向用户显示一个安全消息进行确认。消息内容由依赖方决定。这个确认可以用于各种情况，如金融交易、用户合同确定、医疗手续的确认。
认证器注销：用户不再需要服务时，反注册是一个基本的需求。服务提供方在验证认证器合法性后删除本地用户相关认证数据，随后向用户确认注销，用户删除UFA凭证完成注销。
2.4 FIDO UAF认证器抽象层
它为FIDO客户端提供统一的API，可以为FIDO支持的操作提供基于认证器的加密服务。它向下提供了一个底层的认证器插件API，以便部署多厂商FIDO UAF认证器和对应的驱动。
2.5 FIDO UAF认证器
FIDO UAF身份验证器是连接到或安装在FIDO用户设备中的安全实体，可以创建与依赖方相关的key等。密钥用于参与FIDO UAF强认证过程中。如，随后的FIDO UAF身份验证器可以使用密钥材料提供对加密挑战的响应，从而完成依赖方进行认证器的身份验证。
为了达到简单集成可信认证功能的目标，一个FIOD UAF认证器需要提供它特有的认证类型（如：生物特征），功能（如支持的加密算法）和设备来源等。这为依赖方验证用户认证器身份的可靠性提供了支持。
2.6 FIDO UAF认证器元数据验证
在FIDO UAF认证的过程中，认证是由认证器向依赖方提出的需求，认证器通过生成密钥或信息报告来证明认证设备的真实性。然后有UAF协议携带包含签名的信息给UAF服务端进行验证。首先由认证器使用其私钥进行签名，然后在服务端通过认证元数据中的公钥进行证书验签。元数据采用数据外放的方式和FIDO UAF服务器进行共享。
3 FIDO UAF使用场景和协议消息流
3.1 FIDO UAF认证器采集和用户注册
用户将会有多种途径获取FIDO UAF认证器：比如购买了具有嵌入式FIDO UAF认证功能的新系统，后买了具有嵌入式FIDO UAF身份认证器的设备，或又其他机构（eg.银行）分发得到身份认证器。
获取了认证期之后，用户需要向认证器进行特定的注册（此注册过程不再FIDO UAF协议范围内）。如，认证器设备是基于指纹的，用户需要向认证器注册其指纹。在注册完成后，认证器就可以在支持FIDO UAF的服务提供端进行下一步的用户注册。
3.2 认证器注册
如下给出的FIDO UAF架构，当用户开始进行认证器初始化并和服务端发起交互时，依赖方可以把信息透传到FIDO服务器中。在初始化阶段，服务端将提示用户检测到的认证器，并给出用户注册相关的选项。
3.3 认证
注册后，FIDO UAF身份认证器将在随后用户和服务端进行身份认证时使用。如果FIDO身份认证器不存在时，服务端将采用各种预备策略。这些策略可能包括允许常规登陆或者因权限减少而不允许登陆等。
用户所使用的FIDO UAF认证器有多种类型。 一些认证器可以采样生物特征数据，如脸部图像，指纹或语音检测。 一些通过PIN或本地认证者特定密码条目， 还有一些可能只是一个硬件承载认证器。 这里，只要遵守FIDO隐私原则，FIDO客户端就可以与外部服务进行交互 。
3.4 加强认证（Step-up Authentication）
强认证是传统的网站登陆验证场景下的补充策略。通常网站会允许未经验证或者经普通验证方式认证的用户浏览信息。但是当用户希望有更高价值的交互时，如进入会员专区等，服务端会要求用户进一步认证来提高安全级别。
FIDO UAF将帮助实现这种需求，有FIDO服务的网站将能识别用户端系统可用的FIDO UAF认证器，并从中选择合适的认证器来完成身份的认证。即，根据用户对交互的安全要求，服务端将根据客户端能提供的认证方式和网站风险分析引擎来动态的制定认证交互标准。
3.5 交易确认（安全交易）
提供FIDO服务的依赖方结合有FIDO认证器的客户端可以提供多样化的服务。例如之前的网站登录认证和加强认证等。另一个更高级的使用场景就是安全交易的处理。
考虑如下场景，依赖方希望最终用户确认交易（例如财务操作，特权操作等）的情况，以便可以检测到在其到达终端设备显示和返回的路由期间任何篡改交易消息。FIDO架构具有提供此功能的“安全事务”概念。如果FIDO UAF身份验证器具有事务确认显示功能，则FIDO UAF架构可确保系统支持“你看到的就是你要的”（WYSIWYS）。很多场景需要这种功能- 主要涉及交易授权（汇款，执行上下文特定的特权操作，电子邮件/地址的确认等）。
3.6 认证注销
在某些情况下，依赖方可能需要删除FIDO中与特定用户帐户相关联的UAF凭据认证。 例如，用户的帐户被取消或删除，用户的FIDO认证器丢失或被盗等。在这种情况下，RP可以请求FIDO认证器删除绑定到用户帐户的认证密钥。
3.7 对新FIDO UAF的可扩展性
随着技术的发展，各种新的认证器将会出现。只要它们是基于FIDO结构的。则添加对它的支持，只需要依赖方在认证器描述元数据中添加对应条目，和认证证书即可。用户就可以通过新型认证器和依赖方进行交互。
4 隐私保护
用户隐私是FIDO在设计之初就予以考虑的，并在又UAF提供了支持。一些核心的隐私保护设计如下：
UAF没有一个全局可见的唯一标识符（实现不可链接性，即对同一角色或身份的关联）如果出现UAF设备丢失的情况，捡到设备的人也无法准确的将其指向某个服务方，并发现其他关联账户。此外，如果有多名用户共享某个UAF设备，且都进行过认证注册过程，依赖方将不能通过UAF协议来单独识别两个账户在共享设备。
UAF协议基于账户、设备、服务端生成唯一的非对称加密密钥对。不同服务端的加密密钥不能让他们相互产生任何关联，即UAF具有不可链接性。
UAF协议需要极少量的用户个人数据，最多需要提供一个用户在依赖方的username，这个信息指挥用在FIDO的作用过程中，如注册、认证、验权等。这个数据信息只存在在用户端环境中，且只有在必要的时候会做本地永久化处理。
在UAF中，用户验证（用户生物特征校验等）在本地执行。UAF不向依赖方传递任何生物特征数据，更不会要求依赖方对它进行存储。
用户会明确自己使用的某特定厂商的UAF设备。只有在用户同意的情况下，才会在注册期间生产唯一的加密密钥并将其绑定到依赖方。
UAF认证器只能通过生产批次或制造商和设备型号的认证证书来识别。它们不能被单独标识。UAF规范要求厂商要以相同的认证证书和私钥来制造一批100,000个或更多的UAF认证器，以确保不可链接性。
5 和其他技术的关系
OpenID, SAML, OAuth
FIDO协议（UAF和U2F）完善了身份联合管理(FIM)框架，如OpenId、SAML；也完善了web授权协议，如OAuth。
FIM依赖方可以利用身份提供者（IdP）的初始身份验证事件。然而，OpenID和SAML在IdP上没有定义用于直接用户身份验证的特定机制。（就是OpenId和SAML只解决了第二公里的问题——通过鉴别后身份凭证的分享，没有解决第一公里——对最终用户的直接鉴别的问题）
当IdP与启用FIDO的认证服务集成时，它可以配合服务端进行强身份认证。下图说明了这种关系。基于FIDO的认证机制首先被触发，随后FIM协议把这个身份认证用于随后的身份凭证分享。