FIDO UAF Specification Protocol（Considerations节译）

原文链接：http://blog.csdn.net/u014142287/article/details/69487015

4.Considerations

4.1核心协议设计思考

本部分描述一些在协议设计中的重要元素。

4.1.1认证器元数据

假定FIDO服务器能访问到所有支持的认证器列表和相应的元数据。认证器元数据包含这些信息，例如：

（1）所支持的注册和鉴别方案

（2）鉴别因素、安装类型、所支持的内容类型和其他补充信息等等。

为了决定哪些认证器适合一个特定的交易，FIDO服务器根据AAID查找认证器元数据列表并从中提取必要信息。

规范
认证器元数据中的每一条目都必须用唯一的认证器鉴证（AAID）标识符识别。

4.1.2认证器认证

认证器认证是注册期间确认认证器型号及身份有效性的过程。它可以让依赖方加密校验FIDO UAF客户端所报告的认证器与其宣称的一样。
使用认证器鉴证，依赖方"example-ro.com"能够校验以AAID"1234#5678"上报的"example-Authenticator"型号认证器不是运行在FIDO用户设备上的恶意软件，而是真正的型号为"1234#5678"的认证器。

规范

FIDO认证器应该支持下面描述的"基础鉴证"。随着时间的推移，新的鉴证机制可能会加入到协议中。
没有对鉴证密钥提供足够保护的FIDO认证器(非鉴证认证器)必须和经鉴证的认证器一样使用UAuth.priv密钥来正式生成KeyregisterationData对象，此行为必须在认证器元数据中正确声明。

4.1.2.1基础鉴证
基础鉴证分为两种类型：
完整基础鉴证
    基于鉴证私钥在同类认证器中共享。
替代基础鉴证
    仅在语法上看作是基础鉴证。该鉴证对象是自签名的，例如使用UAuth.priv私钥签名，例如包含在鉴证对象中的UAuth.pub公钥所对应的密钥，因此，不提供密码验证的安全特性。但是如果认证器没有签证私钥，这是能够提供的最优方案。

4.1.2.1.1完整基础鉴证

为了遵循[FIDOSecRef]中假定，FIDO服务器必须可以访问一个信任锚以便校验鉴证公钥(例如鉴证证书可信存储)。同样的，在注册过程中认证器必须提供其鉴证签名。鉴别信任锚由FIDO服务器在带外共享(作为元数据的一部分)，根据[UAFMetadataService]，不应当提供该共享过程。
认证器鉴证私钥的保护措施取决于使用的特定的认证器型号。
FIDO服务器必须用KeyRegisterationData对象提供的AAID从可信存储中加载合适的认证器鉴证根证书。
在完整基础鉴证模型中，为了提供非链接性，大量的认证器必须共享相同的鉴证证书和鉴证私钥。认证器只能在批次生产级别或AAID级别被其鉴证证书识别而不是被单独识别。大量的认证器共享相同的鉴证证书提供了更好的隐私性，但是也使得相关的私钥成为更有吸引力的攻击目标。
注释
一个共享同一制造商和基本特征的给定的认证器集合，在使用之前的的鉴证密钥发布不少于100000台设备前，不得发布新的鉴证密钥。

4.1.2.1.2替代基础鉴证
规范
在此鉴证方式中，UAuth.priv私钥用于注册数据对象签名。此行为必须在认证器元数据中正确声明。
注释
没有对鉴证密钥提供足够保护的FIDO认证器(非鉴证认证器)必须使用此鉴证方法。

4.1.3错误处理
注释
当通过消息专用API产生或处理UAF消息时，FIDO服务器必须将遇到的所有错误情况通知作为调用者的依赖方的Web应用服务器。
规范
当通过认证器特定模块(ASM)处理命令时，FIDO认证器必须将遇到的所有错误情况通知FIDO UAF客户端。

4.1.4断言方案
UAF协议被设计用于兼容各种各样的现存认证器(可信平台模块，指纹传感器，安全元件等)以及将来为FIDO设计的认证器。因此，可扩展性是协议设计的核心功能。
有两个特别的方面需要小心可扩展性：
加密密钥准备（KeyRegistrationData）
加密鉴别和签名（SignedData）
KeyRegisterationData和SignedData方案的结合成为断言方案。
UAF协议允许插入新的断言方案。
注册断言定义了加密密钥是如何以及以各种形式在认证器和FIDO服务器之间交换的。
鉴别断言定义了认证器是如何以及何种形式产生加密签名的。
4.1.5认证器中的用户名
FIDO UAF支持认证器作为第一鉴别因子(例如更换用户名和密码)。在这种情况下，认证器在内部存储用户名（在特定依赖方唯一标识一个账号）。
4.1.6TLS通信保护
注释
为保护FIDO UAF客户端与FIDO服务器之间的数据通信，FIDO UAF客户端(或用户代理)和依赖方对所有协议元素都必须使用受保护的TLS通道。
1、TLS连接的服务器端必须在依赖方
2、TLS连接的客户端必须在FIDO UAF客户端或者用户代理/应用。
3、TLS客户端和服务端应该使用TLS v1.2或更高版本，如果TLS v1.2或更高版本不可用，应该仅适用于TLS v1.1。"匿名"和"未命名"TLS假密套件是不允许的，必须拒绝；TLS中应避免不安全的加密算法。
建议：
1.根据"证书路径验证"，TLS客户端负责验证和确认服务器证书链。应该检查证书撤销状态(例如使用在线证书状态协议或基于证书吊销列表的有效性确认)以及TLS服务器身份。
2.TLS客户端的可信证书根存储被正确维护，至少要求根存储中的CA每年通过Web Trust或欧洲电信标准化协会的SSL CA审计。

4.2实施注意事项
4.2.1服务器挑战值和随机数
注释
ServerChallengec需要合适的随机数以确保有效。用于产生服务器挑战值的(伪)随机数应该成功地通过[Coron99]中规定的随机性测试并且应该遵循[SP800-90b]给出的指导。
4.3安全注意事项
没有"一刀切"的鉴别方法。FIDO的目标是将用户校验方法与鉴别协议和鉴别服务器进行解耦合，并且支持范围广泛的用户校验方法和保障级别。FIDO认证器应该能够利用现有计算机硬件的能力，例如移动设备或者智能卡。
电子化的用户鉴别，其整体保障级别非常依赖于相关用户设备的安全性和完整性用于鉴别用户的鉴别方法。
当使用FIDO时，用户应可自由地使用任何可用的设备和各种各样的鉴别方法。依赖方需要关于设备和鉴别方法自身安全相关部分的可靠消息，以便来决定在特定的业务环境下，是否接受电子化鉴别的整体风险。FIDO元数据用于提供这样的信息。
为FIDO服务器提供设备和鉴别方法自身安全相关部分的可靠信息，对于UAF协议而言是很重要的。
整体安全性由最弱的环节决定。在FIDO中，为了支持可扩展的安全，作为基础的UAF协议需要提供非常高的概念安全级别，以至于协议不是最弱的环节。

依赖方定义可接受的安全级别。FIDO联盟遇见了将有不同供应商提供多种多样的FIDO UAF客户端、FIDO认证器和FIDO服务器。依赖方可以选择提供适当安全级别的FIDO服务器。依赖方可以选择提供适当安全级别的FIDO服务器。他们也有能力接受满足给定业务环境的安全需求的FIDO认证器，通过增加适当的隐式鉴别措施来补偿安全级别缺陷，并且拒绝不满足他们要求的认证器。FIDO不要求FIDO认证器具有非常高的保障级别，而是提供了认证器和用户校验方法进行竞争的基础。

"鉴别"对比"交易确认"。现有云服务通常基于鉴别。用户启动一个假定为可信的应用(例如用户代理)到云服务进行鉴别，目的是为了在应用和云服务之间建立一个经鉴别的通道。在鉴别后，应用能够使用鉴别通道来对云服务执行任意操作。服务提供者把所有这些操作都归属于该用户。本质上，用户提前鉴别由应用执行的所有操作，直到服务连接或鉴别过期。这是很方便的方法，因为用户不会为鉴别所需的手工操作分心。然而，在某些情况下，了解用户在鉴别前确实看过或者接受了特定的内容对于依赖方而言是重要的。该方法通常用于需要不可抵赖性时。该场景导致的需求被称之为所见即所签（What You See Is What You Sign简称WYSIWYS）。
UAF支持两种方法：称为"鉴别"和"交易确认"。技术上的区别是，"鉴别"时用户要确认一个随机挑战值，而在"交易确认"时，用户还要确认一个人类可读的内容，例如合同。从安全角度来看，在"鉴别"情况下，应用需要是可信的，隐为一旦经过鉴别的通道确立，应用就可以执行任意操作。在"交易确认"的情况下，只有实现了所见即所签的交易确认显示组件需要时可信的，而不是整个应用。
显示鉴证安全组件。对依赖方来说，为了判断一次鉴别的相关风险，了解用户环境的某些的细节是很重要的。一般网络浏览器会发送一个"用户代理"字符串给网络服务器。但是任意应用都可以发送任意字符串例如"用户代理"给依赖方，所以此方法不提供强安全性。FIDO UAF是基于加密鉴证概念的。据此概念，带验证的组件拥有加密的秘密并且凭此加密来鉴别其身份。在FIDO UAF中，此加密秘密被称为"认证器鉴证密钥"。依赖方可以访问校验此鉴证所需的参考数据。
为了使依赖方能够恰当地判断与一次鉴别相关的风险，所有执行重要安全功能的徐建都需要被鉴证。
在FIDO UAF中，重要安全功能在FIDO认证器中实现。安全功能有：
1.保护鉴证密钥
2.生成和保护鉴别密钥，通常每个依赖方和依赖方的用户账户有一个。
3.校验用户
4.提供WYSIWYS功能("交易确认显示"组件)
某些FIDO认证器可能运行与FIDO用户设备上的软件中实现这些功能，其他的可能在"硬件"（例如运行于与FIDO用户设备隔离的硬件上的软件）中实现这些功能。某些FIDO认证器可能甚至被正式评估并且被某些国家或国际的方案所认可。每个FIDO认证器型号都有一个鉴证标识符(AAID)，作为相关的安全特征的唯一识别方式。依赖方可以获得这些FIDO认证器的安全属性以及校验该验证所需的参考数据。
由其他校验者泄露的可恢复性。现有鉴别方案的重要问题之一是薄弱的服务器端实现，影响了典型用户到其他依赖方鉴别的安全。将不同依赖方的安全解耦合适FIDO UAF协议的目标。

将用户校验方法与鉴别协议解耦合。为了将用户校验方法与鉴别协议解耦合，FIDO UAF是基于一个可扩展的加密鉴别算法的集合。加密秘密将在认证器完成用户校验后解锁。随后，该秘密用于认证器到依赖方的鉴别。根据现有的加密硬件和计算设备能力来选择加密算法集合。该集合可被扩展以便支持新的加密硬件。
隐私保护。世界的不同地区有不同的隐私条例。FIDO UAF协议应该在所有地区被接受，因此必须支持最高等级的数据保护。因此，FIDO UAF不需要把生物特征数据传输给依赖方，也不需要再依赖方存储生物识别参考数据[ISOBiometrics]。此外，用于不同依赖方的加密秘密不允许这些依赖方将操作和相同的实体进行链接。UAF支持此概念，称为不可链接性。因此，UAF协议不需要可信第三方参与每一笔交易。
依赖方可以使用发现接口[UAFAppAPIAndTransport]在FIDO用户设备上交互式地发现所有可用的FIDO认证器的AAID。AAID的组合添加到客户端为依赖方所提供的熵中。基于这些信息，依赖方可以在互联网上辨识客户端（参考"浏览器唯一性"Eff.org和https://wiki.mozilla.org/Fingerprinting）。为了最小化FIDO添加的熵，用户可以启用或禁用个别认证器，即使这些认证器已经嵌入到设备中。
4.3.1FIDO认证器安全
参考[UAFAuthnrCommands]。
4.3.2加密算法
为了保证小设备的密钥长度足够小，并且私钥操作足够快，建议实施者优先考虑椭圆曲线数字签名算法(ECDSA)与SHA-256或SHA-512的结合。然而，RSA算法也是支持的。一般支持的加密算法列表可参考[UAFRegistry]"鉴别算法和密钥格式"。
椭圆曲线数字签名算法的一个特性是对每个签名的产生，都需要生成一个新的随机值。为了安全性的有效，这个值必须使用加密安全进程随机切均匀地从一个模数集合中选择。在此过程中哪怕有轻微偏差，也可能转化为对签名方案攻击。
注释
如果在所有可能的环境条件下都不能提供这样的随机值，就要使用确定性版本的椭圆曲线数字签名算法。
4.3.3FIDO 客户端信任模型

用户设备上的FIDO环境包含下面4个实体：
1.用户代理(一个原生app或浏览器)
2.FIDO客户端（可以被多个用户代理使用的共享服务）
3.认证器规范模型（ASMs）
4.认证器

支持移动操作系统的安全和隐私原则需要应用程序的某些行为。 FIDO必须尽可能坚持这些原则。这意味着这些组件中的每一个都必须与其他组件实施特定的信任关系，以避免流氓组件破坏解决方案完整性的风险。
手机的一个特殊要求是不得允许源自不同厂商的应用直接查看或编辑对方的数据(例如FIDO UAF凭证)。
鉴于FIDO UAF客户端旨在提供共享服务，孤立应用程序数据的原理已应用于FIDO UAF客户端，而不是单个应用程序。这意味着如果设备上存在两个或多个FIDO UAF客户端，则每个FIDO UAF客户端都无法访问由另一个FIDO UAF客户端创建的身份验证密钥。然而，给定的FIDO UAF客户端可以向多个用户代理提供服务，使得相同的认证密钥可以对相同依赖方的不同facet进行认证，即使一个facet是第三方浏览器。

此专属访问限制通过KHAccessToken执行。当FIDO UAF客户端与ASM通信时，ASM将读取FIDO UAF Client caller1的身份，并将该客户端ID包含在发送给认证这的KHAccessToken中。对认证者的后续调用必须在KHAccessToken中包含相同的客户端ID。每个验证密钥也绑定到创建它的ASM，通过ASMToken(ASM的随机唯一ID)也包含在KHAccessToken中。
最后，FIDO UAF客户端将认可的用户代理由依赖方本身决定。作为注册和认证协议的一部分，FIDO UAF客户端从RP请求可信应用程序列表。这样可以防止依赖方为明确授权的用户代理使用FIDO凭据。

以这种方式，在合规FIDO安装中，UAF凭证只能通过依赖方明确信任的应用程序和通过执行原始注册同一客户端和ASM来访问。

应该注意的是，该规范允许将FIDO UAF客户端直接构建到用户代理中。然而，这样的实现将限制支持依赖方应用的多个方面的能力，除非他们还暴露UAF客户端API以供其他用户代理消费。

4.3.3.1 使用密钥句柄访问令牌隔离
认证器可能在专用硬件中实现，因此可能不能校验调用软件的实体(例如ASM)
KHAccessToken允许限制访问有FIDO认证器生成的给指定ASM的密钥。这是基于"首次使用时信任(Trust On First Use 简称TOFU)"的概念。
FIDO认证器能够将UAuth.Key与调用者(例如ASM)提供的密钥进行绑定。该密钥称之为KHAccessToken。
此技术允许确保注册密钥只有最初注册的调用者能够访问。移动平台上的恶意应用不能通过绕过相关的ASM来访问密钥(假定此ASM最初注册了这些密钥)。
KHAccessToken通常是特定于AppID、PersonalID、ASMToken和CallerID的。
注释
在某些平台上，为了与FIDO认证器通信，ASM可能还另外需要特定的许可。某些平台不提供在应用间可靠地强制访问控制的方法。

4.3.4TLS绑定
多种通道绑定方法已经被提出
UAF依赖TLS服务器鉴别来将鉴别密钥与AppID进行绑定。存在以下威胁：
1.攻击者可能通过使用与依赖方相同的AppID而欺骗性地获取TLS服务器证书，而且他们也许能篡改DNS系统。
2.攻击者也许能窃取依赖方的TLS服务器私钥和证书，而且他们也许能篡改DNS系统。
存在以下功能需求：
（1）UAF交易可能跨越多个TLS会话。
（2）数据中心可能使用SSL集中器。
（3）数据中心可能为使用不同TLS证书的TLS终端实施均在均衡。因此，[RFC5929]中定义的"tls-server-end-point"可能是不合适的。
（4）很遗憾，在一个特定的但又但又相当常见的环境下，TLS服务器证书的哈希限制了通道绑定的实用性。如果客户端咋一个可信的代理后面操作，可信代理充当TLS中间人，客户端将会看到一个不同于服务器正在使用的证书。对于想要检查所有进出流量的高安全态势的公司和军事网络来说，这其实是相当常见的。如果FIDO服务器只得到哈希值，就没有办法将其和攻击区别开。从性能的角度来看，如果发送整个证书是可接受的，那么服务器可检查并判断其是否为来自非标准发布者的有效名称的证书，或不同姓名的证书（几乎确定表明为一个转发攻击）。

4.3.5会话管理
FIDO不定义任何特定的会话管理方法。然而一些FIDO功能依赖于由依赖方网页应用实现的强会话管理。
FIDO注册
在通过传统的凭证完成对现有用户的鉴别之后，网页应用可能会触发FIDO注册。于是会话就被用于维护鉴别状态直到FIDO注册完成。
FIDO鉴别
FIDO鉴别成功后，会话用于在用户代理或移动应用执行操作期间维持鉴别状态。
应该遵循最优的做法来实现强会话管理。

4.3.6角色
FIDO通过使用依赖方特定密钥支持不同依赖方的账户的非链接性
有时用户在一个特定依赖方有多个账户，并且甚至想要维持这些账户间的非链接性。
目前，这是很困难的，需要某些严格的措施。
FIDO不想增加更多的复杂性来维护用一个依赖方的多账户间的非链接性。
在漫游认证器的情况下，建议对不同的角色(例如"商务"、"私人")使用不同的认证器。这样做是合理的，因为漫游认证器通常很小且不会过于昂贵。在绑定认证器的情况下，就有所不同了。FIDO建议此情况下采用"角色"的概念。认证器的所有相关数据都与一个角色例如"商务"、"私人")相关联。认证器的某些管理接口可以允许维护和切换角色。
规范
认证器必须只能"知道"或"识别"与那一时刻活动的角色相关的数据(例如鉴别密钥、用户名、密钥标识符等)。

根据此概念，用户可以切换到"私人"角色并注册新的账户。当切换回"商务"角色时，账户就不能被认证器识别了，直到用户再次切换到"私人"角色。
为了支持角色特征，FIDO认证器特定模块API支持使用角色标识符(PersonalID)来识别认证器所使用的角色。角色的管理及与用户的通信超出了FIDO的范围。
4.3.7服务器数据和密钥句柄
包含在UAF请求中的serverData字段(参考 Operation Header结构)的数据被发送给FIDO UAF客户端，并会作为相关UAF响应消息的一部分返回给FIDO服务器。
注释
FIDO服务器不应该假定对这种数据的任何隐式的完整性保护，也没有任何隐式的会话绑定。FIDO服务器必须明确地将serverData与活跃会话进行绑定。
注释
在某些情景中，理想的情况是保护可以存储在任意的地方的敏感数据(例如在serverDat或keyHandle中)。在这种情况下，这些敏感数据的机密性和完整性必须加以保护。这可以通过使用合适的加密算法来完成，例如使用适当加密模式的AES，例如CBC或CTR。这种加密模式需要被正确的使用。例如，对于CBC，每次加密采用新的随机初始化向量是必须的。为了获取块的长度的整数值，数据可能需要先进行填补。可以通过在密文中添加MAC(消息鉴别码)或者数字签名来完成完整性保护，使用与加密不同的密钥，例如使用HMAC。或者也可以使用诸如AES-GCM和AES-CCM这样的鉴别加密方案。这样的方案在一个算法中使用一个密钥提供了完整性和机密性保护。
在保护serverData时，MAC或数字签名计算应该包含某些与相关消息绑定的数据，例如在已鉴别的serverDat中重新包含挑战值。

4.3.8通过UAF应用API或元数据提取认证器信息进行比对
一些认证器属性(例如用户校验方法、密钥保护、交易确认显示等)可从元数据[UAFAuthnrMetadata]或通过FIDO UAF应用API获得。这些包含在元数据中的属性是由可信源授权并提供的。当有疑问时，应该基于将从元数据提取的属性和通过FIDO UAF应用API提取的数据进行比对而决定。
然而，通过FIDO UAF应用API提取的属性提供了一个预期来自于任主任哪个区的良好"暗示"。这样的"暗示"很好地适合于促进和优化用户体验。

4.3.9策略校验
FIDO UAF响应消息没有把相关FIDO UAF请求消息中收到的全部参数都包含仅待签名对象中。因此任何中间人攻击都能修改这些记录。
如果被修改的值是不可被接受的，FIDO服务器会检测到这些变化。
例如，中间人攻击也许用一个指定为最弱的可能FIDO认证器的策略来替换一个通用策略。如果这个最弱的可能的FIDO认证器策略来替换一个通用策略。如果这个最弱的可能的FIDO认证器与最初的策略不匹配，FIDO服务器会检测到这个变化。

4.3.10重放攻击保护
对于重放攻击保护，FIDO UAF协议指定两种不同的方法
1.安全传输层协议(TLS)
2.服务器挑战值
如果实施无误，TLS协议自身能防护重放攻击。
另外，每个协议消息在ServerChallenge字段包含一些随机字节。FIDO服务器应该只接受包含有效ServerChallenge值得传入FIDO UAF消息。这是通过校验由客户端发送的ServerChallenge值是否之前是由FIDO服务器产生的来完成的。
应当说明的是，某些(尽管不可能)情形下，FIDO服务器生成的随机数可能不是唯一的，这种情况下，同样的ServerChallenge可能出现不止一次，这就使得重放攻击更难检测。

4.3.11防止克隆认证器
FIDO UAF依赖于带有特定于型号(通过AAID识别)的安全特色的认证器管理并保护的UAuth.Key。当仅有一个带有特定UAuth.Key实例的认证器存在时，安全性更好。FIDO UAF指定了一些保护措施来防止认证器克隆。
首先，如果UAuth私钥处于适当的保护措施下，由于这样的密钥不易于提取所以很难被克隆。
其次，UAF指定了签名计数器(参考鉴别响应处理规则和UAFAuthnrCommands)，该计数器随着每次签名操作递增。如果使用了克隆的认证器，以后使用原来的认证器其所含签名计数器的值小于或等于之前的(恶意)操作。FIDO服务器可以检测这样的事件。

4.3.12反欺诈标志
存在攻击者为欺诈而滥用FIDO认证器的可能性，更具体低说他们可能：
1.为某个账号将认证器注册到依赖方
2.进行欺骗
3.注销认证器
4.为另一个账号将认证器注册到依赖方
5.进行欺骗
6.注销认证器
7.以此类推...
注释
认证器可能支持注册计数器(RegCounter)。RegCounter每次注册后增加，因此在这样的欺诈场景中会变得非常高。

4.4互操作性思考
FIDO支持网页应用、移动应用和本地计算机应用，这些应用被称为支持FIDO功能的应用。

网页应用通常由网页应用服务器和相关的网页应用程序组成。网页应用程序代码(例如HTML和JavaScript)通常用户代理在客户端呈现和执行。网页应用程序代码通过一套JavaScriptAPI与用户代理对话，例如HTML DOM。FIDO DOM API在[UAFAppAPIAndTransport]中定义。网页应用程序和依赖方网页应用服务器之间的协议通常是专有的。
移动应用担任用户代理和网页应用程序(客户端)的角色。移动应用和依赖方网页应用服务器之间的协议通常是专用的。
本地计算机应用担任用户代理和网页应用程序(客户端)的角色。这些应用通常是独立于任意依赖方网页应用服务器的。
建议支持FIDO的应用按照本文档中规定的格式使用FIDO消息
建议支持FIDO的应用使用[UAFAppAPIAndTransport]中定义的UAF HTTP绑定。
注释
KeyRegistrationData和SignedData对象[UAFAuthnrCommands]是由FIDO认证器生成和签名的，必须由FIDO服务器校验。如果在传输期间该值被修改，则验证失败。
ASM API[UAFASM]在桌面计算机和移动设备上指定了标准化的API来访问认证器特定模块(ASM)。
[UAFAuthnrCommands]文档没有规定特东的协议或API，它列出了需要从FIDO认证器来回传递的最小数据集合特定的消息格式。