FIDO UAF Authenticator Commands v1.0

FIDO UAF Authenticator Commands v1.0

FIDO联盟实施草案 2014年12月08日

本版本 https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-authnr-cmds-v1.0-ps-20141208.html

上一版本 https://fidoalliance.org/specs/fido-uaf-authnr-cmds-v1.0-rd-20141008.pdf

编辑： Davit Baghdasaryan, Nok Nok Labs, Inc. John Kemp, FIDO Alliance

贡献者: Dr. Rolf Lindemann, Nok Nok Labs, Inc. Roni Sasson, Discretix Brad Hill, PayPal, Inc.

本规范的英文版本是唯一的规范版本。也可能有非规范的翻译版本。

Copyright © 2013-2014 FIDO Alliance All Rights Reserved.

摘要

UAF Authenticators可能会采取不同的形式实现。实现方式从在防篡改硬件中运行的安全应用，到在消费者设备上纯软件的解决方案都是可能的。

本文档定义了UAF Authenticators规范性方面，为authenticator实现人员提供安全性和实现指导。

本文档状态

本章节描述了本文档在发布时的状态。可能会有其他文档代替本文档。FIDO联盟发布过的以及最新的技术报告在FIDO Alliance specifications index的https://www.fidoalliance.org/specifications/*都可以找到。

本文档作为建议标准由 FIDO Alliance发布。本文档旨在成为FIDO联盟的建议标准。如果你对本文档有任何意见或建议，请联系我们。我们欢迎任何意见和建议。

本规范某些要素的实现可能需要第三方知识产权的许可，包括但不限于专利权。FIDO Alliance, Inc. 及其成员和其他所有贡献者都没有，且不得举行，负责以任何方式确认或无法确认任何或所有这样的第三方的知识产权。（译者注：大概是防FIDO联盟成员垄断利益的条款）

本FIDO联盟规范为“按原样”提供，无任何，包括任何担保，包括但不限于任何明示或针对特定用途的非侵权，适销性或暗示的保证。

1. 符号解释

类型名，属性名和成员名将写成code。

字符串会被“”包起来，例如“UAF-TLV”。

在公式中使用“|”表示将两个byte数组串联（译者注：注意不是或）

本文档用到的UAF专业术语在 [FIDOGlossary]中定义。

本规范中所有图片，实例，小记（notes）不属于规范。

1.1 关键字

本文中出现的关键字必须，不可以，需要，不应，应该（SHOULD），建议，应该（MAY），可选，遵循RFC2119中的解释。

2 概述

本章节不是规范。

本文档制定了UAF Authenticators应该实现的用于支持UAF协议的底层的功能。文档有如下几个目标： * 定义UAF Authenticator的实现规范 * 定义UAF功能的一系列指令实现，这些指令可以被不同类型的authenticator实现。 * 定义UAFV1TLV断言方案结构，该断言可被FIDO Server解析。

NOTE UAF Protocol支持不同的断言方案。本文档定义的指令和结构都假设authenticator支持UAFV1TLV断言方案。实现了不同断言方案的Authenticator不需要遵循本文档规定的要求。（译者注：目前UAF协议1.2版本只支持这一个断言方案）

整个UAF Protocol的架构和其操作定义在[UAFProtocol]中。下面这个简化的架构图说明了本文档涉及的交互和行为： [img] Fig. 1 UAF Authenticator Commands

3 额外说明

除非另外规定，本文档所有的数据必须以小端格式编码。

所有的TLV结构可以使用“递归-下降”解析，且tag的顺序不是一定的。在某些情况下一个tag可能在同一个结构中出现很多次，此时所有的value都必须保存下来。

除非另外明确提到，否则TLV结构所有的域都是强制要求的。

4 UAF Authenticator

本章节不是规范。

UAF Authenticator是一个满足了[UAFProtocol]中描述的协议要求的认证组件。UAF Authenticators具备的主要功能如下：

1. 【强制】使用authenticator内置的认证装置认证用户。认证技术可以是多样的，从生物识别到简单的在场证明，甚至无用户验证（see Slient Authenticator）。
2. 【强制】执行[UAFProtocol]中定义的加密操作。
3. 【强制】创建可被FIDO Server解析的数据结构。
4. 【强制】向FIDO Server证明自己拥有认证能力。
5. 【可选】向用户显示交易内容。

[img] Fig. 2 FIDO Authenticator逻辑上的子组件

一些UAF Authenticators的代表： * 移动设备内置的指纹传感器 * secure element内置的PIN码验证（译者注：secure element是一个标准硬件平台） * 内置用户在场验证的USB令牌 * 设备内置的声音或脸部识别技术

4.1 Authenticators的种类

本文档一共定义了4中authenticator。这些定义不是规范的（除非另有说明），仅仅为了下文的简化描述。

NOTE 以下是仅考虑这4种authenticator的原理： * 绑定authenticator是典型的嵌入在用户计算设备中并使用宿主存储的设备。从经济角度上使用宿主的存储比使用（自己的）嵌入式存储更有意义。Trusted Execution Environments (TEE), Secure Elements and Trusted Platform Modules (TPM)就是典型的以此理念设计的设备。 * 第一因素漫游设备（First-factor roaming authenticators）必须拥有内部存储来存储key handles。 * 第二因素漫游设备（Second-factor roaming authenticators）可以把key handles存储在相关服务器上，而不用提供内部存储。 * 定义这些约束使得在主要的用例中，规范描述将会更加简洁清晰 尽管如此，厂商（设计authenticator）并不受这些限制影响。例如一个用内部存储来存储key handles的绑定authenticator也是可以的。厂商可以自由的设计和实现这些authenticator，只要设计符合本文档描述的规范要求。

• First-factor Bound Authenticator
  • 这类authenticator拥有内部匹配器。匹配器可以认证一个已经登记了的用户。如果有多个用户登记——匹配器依然可以认证该用户。
  • authenticator和使用这个authenticator设备会有一个逻辑上的绑定（绑定通过KeyHandleAsscessToken来描述）。这个authenticator无法被多个设备绑定，只能绑定一个。
  • 这类authenticator不会存储key handles到自己的内部存储。它们会把key handle返回给ASM，然后存到ASM本地数据库。
  • 这类authenticator也可以工作在send factor。
  • 例子：
    • 笔记本，手机或平板的指纹识别传感器
    • 内嵌在移动设备的secure element
    • 设备内置的声音识别认证
• Second-factor (2ndF) Bound Authenticator
  • 这类authenticator和first-factor bound authenticator类似，除了它可以以second-factor的身份进行multi-factor认证。
  • 例子：
    • 使用内置电容触摸来认证用户在场的USB令牌
    • 运行在手机上的信任的执行环境中的“Trustlet”应用，利用安全键盘来验证用户在场。（译者注：Trustlet后文有提到）
• First-factor (1stF) Roaming Authenticator
  • 这类authenticator不会与其他设备绑定。用户可以在任意数量的设备上使用。
  • 这类authenticator被假定为拥有内部匹配器。匹配器可以认证一个已经登记了的用户。如果有多个用户登记——匹配器依然可以认证该用户。
  • 这类authenticato被假定为在自己的内部安全存储中存储key handles，不会暴露到外面。
  • 这些authenticator也可以作为second factor工作。
  • 例子：
    • 内置指纹识别传感器的基于BLE的硬件
    • PIN码保护的USB令牌
    • 一个以roaming authenticator身份工作的first-facor bound authenticator，其为另一台设备做认证。
• Second-factor Roaming Authenticator
  • 这类authenticator不会与其他设备绑定。用户可以在任意数量的设备上使用。、
  • 这类authenticator可能拥有内部匹配器。匹配器可以认证一个已经登记了的用户。如果有多个用户登记——匹配器依然可以认证该用户。
  • 这类authenticator被假定为不会在自己的内部存储中存储key handles。它们会把key handles上传到FIDO Server，等到认证操作的时候再由FIDO Server传回来。
  • 这类authenticator只能作为second factor。
  • 例子：
    • 内置电容触摸用于验证用户在场的USB加密器
    • 一个运行在手机上的信任的执行环境中的“Trustlet”应用，利用安全键盘来验证用户在场。

译者注： 下文有提到：支持用户名是first-和second- factor authenticator之间的关键区别。first-可以区分不同key handles分别属于哪个用户（key handle有对应的username），second-没有username这个概念，所有key handle对它来说都是一样的。 我的理解： First-factor可以理解为只有本人才知道的信息。比如PIN，指纹等。该设备可以直接登录。 Second-factor可以理解为本人持有的东西，比如预写好密钥或证书的便携式设备，你对这个设备的持有被看做是本人。如内置证书的USB令牌。该设备不可以直接登录，需要先通过其他途径进行登录，再使用该设备进行认证，签名。第二因素设备更像u2f设备。 仅供参考。如有误烦请提出。

整篇文章中会有针对这几类型的authenticator指定的特殊条件。

规范 在某些部署中，ASM和bound authenticator的组合可以作为一个roaming authenticator使用（例如当一个移动设备上的ASM和一个内嵌的authenticator的组合作为另一台设备的roaming authenticator）。当这种情况发生时，这个authenticator必须遵循这个bound authenticator所绑定的系统的要求，并且遵循其连接的在另一系统中，作为roaming authenticator的要求。 （译者注：1.2版本在此段新增了：为了符合authenticator的要求，authenticator必须至少实现一个[ UAFRegistry]中的认证类型，和[UAFRegistry]中的一个认证算法和一个密钥对格式。） NOTE 书上所述，bound authenticator不存储key handles，而roaming authenticator存储key handles（译者注：这里在1.2版本中，roaming authenticators to store them被改为roaming authenticators do store them，猜测是笔误。这里按照1.2的版本翻译）。上面的例子中ASM会存储bound authenticator的key handles，以满足上面的假设。

5. Tags

该章节是规范的。

本文档中UAF Authenticators使用“Tag-Length-Value”（TLV）格式来与外界通讯。所有的请求和回复都必须是TLV格式的。

command和已存在的预定义TLV tags可以通过附加其他（自定义或预定义的）TLV tags来进行扩展。

参考[UAFRegistry]来了解更多有关TAG tags的信息。

TLV格式数据为下面这样的简单结构：

译者注：Length in bytes应该是Length in Data，即第三个成员Data的长度

所有长度的单位是bytes。如UINT32[4]为16个长度。

虽然tag被分配了2个byte，但为了适配某些硬件平台的限制，只可以使用前14个bits（到0x3FFF）。

数组在TLV中是隐藏的。一些数据结构的描述表明该结构允许多个值，在这种情况中，如果tag出现多于1次，则所有的值都是有意义的，它们应该被当做是一个数组。

为了方便解码TLV结构的信息，所有的复合tag——即必须递归下降解析的值（译者注，value是也是一个TLV结构数据）——其第13 bit（0x1000）是1。

第14 bit（0x2000）为1的tag表示这是致命的，接受者必须终端处理整个信息，如果无法处理这个tag。（译者注：目前全部TAG第14 bit都为1）

由于UAF Authenticator可能处在极为有限的处理环境，发送command时ASM必须遵循规范中定义的结构顺序。（译者注：写死了顺序，可以让解析程序更加简单，authenticator性能更容易满足解析需要）

ASM和Server被假定有充足的资源以任何的顺序解析tags，所以authenticator发送过来的数据结构可能是任何顺序的。（译者注：也是为了方便authenticator）

5.1 Command Tags

Table 4.1.1：UAF Authenticator Command TLV tags (0x3400 – 0x34FF, 0x3600-0x36FF)

5.2 只在Authenticator Command中使用的Tag

Table 4.2.1: Non-Command Tags (0x2800 – 0x28FF, 0x3800 – 0x38FF)

5.3 UAF Protocol中用到的Tag

Table 4.3.1: Tags used in the UAF Protocol (0x2E00 – 0x2EFF, 0x3E00 – 0x3EFF). Normatively defined in [[UAFRegistry(#bib-UAFRegistry)]]

5.4 状态码（Status Code）

Table 4.4.1: UAF Authenticator Status Codes(0x00 – 0xFF)

6. Structures

本章节是规范的。

6.1 RawKeyHandle

RawKeyHandle是一个由authenticator生成和解析的结构。authenticator应该定义不同的RawKeyHandle，RawKeyHandle内部结构应仅与指定的authenticator实现相关。 一个典型的first-factor bound atuenticator的RawKeyHandle有如下的结构：

Table 5.1: RawKeyHandle Structure

first factor authenticator必须存储Username在RawKeyHandle中（译者注：1.2版本被修改为：first factor authenticator必须自己存储用户名且必须将key和用户名关联在一起。这可以通过存储用户名到RawKeyHandle来实现。），second factor authenticator不可以存储用户名。

支持用户名是first-和second- factor authenticator之间的关键区别。

在离开authenticator边界时（译者注：即authenticator要完成自己的操作，把数据返回到上层的时候），RawKeyHandle必须加密，因为其存放着敏感信息。如用户的私钥（UAuth.priv）。

6.1.1 由FIDO Server解析的结构

本章节定义的结构由UAF Authenticator创建，被FIDO Server解析。

如果authenticator实现了”UAFV1TLV”断言方案，则必须生成这些结构。

NOTE “UAFV1TLV”断言方案假设authenticator拥有TAG_UAFV1_KRD 和TAG_UAFV1_SIGNED_DATA内部所有数据的独占控制权。

嵌套关系结构必须保留，但在一个复合tag中的tag的顺序不必遵循规范。FIDO Servers必须准备好处理任何顺序的tag。

6.1.1.1 TAG_UAFV1_REG_ASSERTION

下面的TLV结构由authenticator在处理Register command的时候生成。然后原封不动地发送到FIDO Server，并被server解析。该结构内嵌了TAG_UAFV1_KRD，该tag含有新生成的公钥和其他数据。

如果authenticator想要在TAG_UAFV1_KRD上附加自定义数据（然后用认证密钥签名）——这些数据必须包含在TAG_EXTENSION_DATA 中，而TAG_EXTENSION_DATA包含在TAG_UAFV1_KRD的TAG_EXTENSION 中。

如果authenticator想要发送额外的数据给FIDO Server而不签名——这些数据必须必须包含在TAG_EXTENSION_DATA 中，而TAG_EXTENSION_DATA包含在TAG_UAFV1_REG_ASSERTION 的TAG_EXTENSION 中。

当前本文档只指定了TAG_ATTESTATION_BASIC_FULL，TAG_ATTESTATION_BASIC_SURROGATE和TAG_ATTESTATION_ECDAA这三个认证类型。以防万一authenticator需要对TAG_UAFV1_KRD 执行“其他某种认证“，其必须使用TLV tag和内容定义”其他某种认证“（定义在[UAFRegistry]）。

6.1.1.2 TAG_UAFV1_AUTH_ASSERTION

下面的TLV结构由authenticator在处理Sign command的时候生成。然后原封不动地发送到FIDO Server，并被server解析。该结构内嵌了TAG_UAFV1_SIGNED_DATA。

如果authenticator想要在TAG_UAFV1_SIGNED_DATA 上附加自定义数据（然后用认证密钥签名）——这些数据必须作为额外的tag包含在TAG_UAFV1_SIGNED_DATA。

如果authenticator想要发送额外的数据给FIDO Server而不签名——这些数据必须必须包含在TAG_UAFV1_AUTH_ASSERTION中，但不包含在TAG_UAFV1_SIGNED_DATA中。

6.1.2 UserVerificationToken

本规范没有指定究竟应该如何在authenticator中进行用户验证。验证被认为是一个authenticator，一个厂商，一个明确的操作。

本文档提供了“vendor_specific_UserVerify“命令（验证用户使用的authenticator内置技术）如何安全地绑定到UAF Register和Sign Command的一个例子。绑定通过一个叫UserVerificationToken的概念完成。这个绑定使得”vendor_specific_UserVerify”和”UAF Register/Sign”互相独立（解耦）。

UserVerificationToken的定义如下： * ASM调用“vendor_specific_UserVerify”命令。authenticator验证用户并返回UserVerificationToken。 * ASM调用 UAF.Register/Sign命令并传入参数UserVerificationToken。authenticator验证UserVerificationToken的合法性，如果合法则执行FIDO操作。

UserVerificationToken这个概念不是规范的。authenticator可能以完全不同的方式实现这个绑定功能。例如一个authenticator厂商可能决定直接追加UAF Register请求到他们的”vendor_specific_UserVerify”命令，并当作一个单命令处理。（？？没理解）

如果UserVerificationToken绑定机制实现了，则应该满足下面其中一个标准，或实现一个机制来提供更简单或更好的安全性： * UserVerificationToken必须允许仅执行一个单UAF Register或UAF Sign操作。 * UserVerificationToken必须和时间绑定，并允许在规定时间内执行多次UAF操作。

6.2 Commands

该章节不是规范的。

规范 可以和不同厂商的ASM交互的UAF Authenticators必须实现本章节的command接口。例如： * 核心功能由一个厂商生产的bound authenticator，但需要和另一个厂商开发的ASM交互 * Roaming Authenticators 规范 和自定义ASM紧密耦合的UAF Authenticators可以实现不同的command接口。

所有的UAF Authenticators command和responses在语义上是相似的——它们都表现为TLV编码块。每个command前面的2bytes是command code。接收完一个command后，authenticator必须解析第一个TLV tag并了解是发过来的是哪个command。

6.2.1 GetInfo Command

6.2.1.1 Command描述

该command返回内部authenticator的信息。可能会返回0或更多的authenticator。每个authenticator被赋值一个不同的authenticatorIndex，用于其他命令时引用该authenticator。 （译者注：一个UAF Authenticators可能包含多个internal authenticator。）

6.2.1.2 Command结构

6.2.1.3 Command Response

6.2.1.4 Status Codes

• UAF_CMD_STATUS_OK
• UAF_CMD_STATUS_ERR_UNKNOWN

6.2.2 Register Command

该command生成UAF registration断言。该断言可用于向FIDO Server注册authenticator。

6.2.2.1 Command结构

6.2.2.2 Command Response

6.2.2.3 Status Codes

• UAF_CMD_STATUS_OK
• UAF_CMD_STATUS_ACCESS_DENIED
• UAF_CMD_STATUS_USER_CANCELLED
• UAF_CMD_STATUS_ATTESTATION_NOT_SUPPORTED
• UAF_CMD_STATUS_ERR_UNKNOWN

6.2.2.4 指令介绍

authenticator必须遵循以下步骤（浏览下面的command结构的表格）（？？上面）

1. 如果authenticator有交易确认展示界面可以展示AppID，则需要保证（ASM）提供了Command.TAG_APPID，并在用户确认的时候进行展示。使用TAG_APPID更新Command.KHAccessToken：
   • 把Command.KHAccessToken和Command.TAG_APPID混合，结果赋值给Command.KHAccessToken。举个混合例子（使用加密哈希）：
     • 例：Command.KHAccessToken=hash(Command.KHAccessToken | Command.TAG_APPID)

   NOTE 这个方法允许我们避免在RawKeyHandle分开存储AppID。

2. 如果用户已经使用此authenticator进行了登记（通过生物识别验证，PIN验证或者类似的机制）—— 验证该用户。如果验证已经在之前的command完成了 —— 保证Command.TAG_USERVERIFY_TOKEN合法。
   1. 如果验证失败 —— 返回UAF_CMD_STATUS_ACCESS_DENIED
3. 如果用户还没有使用该authenticator进行登记，则引导用户执行登记流程。（如指纹录入）
   1. 如果登记失败 —— 返回UAF_CMD_STATUS_ACCESS_DENIED
   2. 如果用户明确的取消了该操作 —— 返回UAF_CMD_STATUS_USER_CANCELLED
4. 确认支持Command.TAG_ATTESTATION_TYPE。如果不支持该type —— 返回UAF_CMD_STATUS_ATTESTATION_NOT_SUPPORTED
5. 生成一个新的密钥对（UAuth.pub/UAuth.priv）
6. 创建RawKeyHandle
   1. 添加UAuth.priv
   2. 添加Command.KHAccessToken
   3. 如果是first-factor authenticator，添加Command.Username
7. 用Wrap.sym密钥打包RawKeyHandle
8. 创建TAG_UAFV1_KRD结构
   1. 如果是second-factor roaming authenticator – 把key handle作为TAG_KEYID的值。否则生成一个随机KeyID作为TAG_KEYID的值。
   2. 拷贝其它所有要求的数据域（参考 TAG_UAFV1_REG_ASSERTION）
9. 根据提供的Command.AttestationType认证TAG_UAFV1_KRD。
10. 创建TAG_AUTHENTICATOR_ASSERTION
    1. 创建 TAG_UAFV1_REG_ASSERTION
       1. 拷贝其它所有要求的数据域（参考 TAG_UAFV1_REG_ASSERTION）
       2. 如果这是first-factor authenticator —— 内部存储KeyID和key handle
       3. 如果是second-factor roaming authenticator —— 通过TAG_KEYHANDLE返回key handle
    2. 将整个TAG_UAFV1_REG_ASSERTION的TLV结构当作TAG_AUTHENTICATOR_ASSERTION的值
11. 返回TAG_UAFV1_REGISTER_CMD_RESPONSE
    1. 设置状态为UAF_CMD_STATUS_OK
    2. 添加TAG_AUTHENTICATOR_ASSERTION
    3. 如果需要外部存储key handle，添加TAG_KEY_HANDLE

规范 authenticator不可以在验证用户（或登记用户（用户第一次使用authenticator））前处理Register command。 authenticator必须在每次调用Register command时都必须生成唯一的UAuth密钥对。 authenticator应该存储key handle在内部安全存储中，或加密传送给ASM。 对于silent authenticators，key handle不可以存储在FIDO Server，否则会使用户可能被跟踪但又没有为用户提供从本地设备上清除key handle的能力。 如果KeyID不是key handle（如second-factor roaming authenticator）——则其必须是一个唯一的无规律的byte数组且最大长度为32。其必须是同样AAID的设备中唯一的。 NOTE 如果KeyID是随机生成的（而不是根据key handle计算出来的（比如hash））——则其应该存储KeyID到RawKeyHandle里面，使得authenticator在处理Sign command的时候可以根据RawKeyHandle获取到keyID。 如果authenticator不支持SignCount或RegCounter，则必须在TAG_UAFV1_KRD中设置它们为0。authenticator恢复出厂设置时，RegCount和SignCount必须设置为0。

6.2.3 Sign Command

这个command会生成UAF断言。断言稍后将会发送到之前进行注册的FIDO Server并被验证。

6.2.3.1 Command结构

6.2.3.2 Command Response

6.2.3.3 Status Codes

• UAF_CMD_STATUS_OK
• UAF_CMD_STATUS_ACCESS_DENIED
• UAF_CMD_STATUS_USER_NOT_ENROLLED
• UAF_CMD_STATUS_USER_CANCELLED
• UAF_CMD_STATUS_CANNOT_RENDER_TRANSACTION_CONTENT
• UAF_CMD_STATUS_ERR_UNKNOWN

6.2.3.4 Command描述

NOTE First-factor authenticator应该将该命令实现分为两个阶段： 1. 第一阶段：验证KHAccessToken后，authenticator发现存在多个key handles。该阶段中，authenticator必须返回所有key handles的username+key handles组合给ASM。 2. 第二阶段：用户选择了一个username后，ASM再次调用Sign Command，此时command中只有一个key handle，authenticator根据此key handle返回UAF断言。 如果second-factor authenticator收到多与一个合法的key handle，则必须选择第一个，并忽略其他。 该命令实现分为两个阶段，可以保证一次command调用只会生成一个断言。

authenticator必须遵循以下步骤：

1. 如果authenticator有交易确认展示界面可以展示AppID，则需要保证（ASM）提供了Command.TAG_APPID，并在用户确认的时候进行展示。使用TAG_APPID更新Command.KHAccessToken：
   • 把Command.KHAccessToken和Command.TAG_APPID混合，结果赋值给Command.KHAccessToken。举个混合例子（使用加密哈希）：
     • 例：Command.KHAccessToken=hash(Command.KHAccessToken | Command.TAG_APPID)

   NOTE 这个方法允许我们避免在RawKeyHandle分开存储AppID。

2. 如果用户已经在此authenticator登记过（如生物识别录入，PIN初始化等），则验证该用户。如果在之前的command中已经验证过，则保证Command.TAG_USERVERIFY_TOKEN合法。（译者注：可以做成：如果Command.TAG_USERVERIFY_TOKEN存在，则验证是否合法。如果不合法或者过期，则重新进行验证）
   1. 如果认证失败——返回UAF_COD_STATUS_ACCESS_DENIED
   2. 如果用户取消了操作——返回UAF_COMD_STATUS_USER_CANCELLED
3. 如果用户还没在此authenticator登记过，则返回UAF_CMD_STATUS_USER_NOT_ENROLLED
4. 使用Wrap.sym解包所有Command.TAG_KEYHANDLE提供的key handles。
   1. 如果是first-factor roaming authenticator：
      1. 如果提供了Command.TAG_KEYHANDLE，则该列表位KeyIDs。使用这些KeyIDs去找到内部存储中的key handles。
      2. 如果没有提供Command.TAG_KEYHANDLE，解包内部存储的所有key handles >译者注： >虽然文档其他地方只是说存储在authenticator外部的key handles都要加密，但这个步骤中表明内部存储的key handles也要用Wrap.sym加密
5. 根据Command.KHAcessToken过滤RawKeyHandles（RawKeyHandle.KHAccessToken == Command.KHAccessToken）
6. 如果过滤后RawKeyHandles数量为0，则返回UAF_CMD_STATUS_ACCESS_DENIED
7. 如果过滤后RawKeyHandles数量 > 1
   1. 如果是second-factor authenticator，则选择第一个RawKeyHandle然后调到步骤8。
   2. 拷贝所有{Command.KeyHandle, RawKeyHandle.username}到TAG_USERNAME_AND_KEYHANDLE tag。
      • 如果是first-factor roaming authenticator，则返回的TAG_USERNAME_AND_KEYHANDLES必须按照key handle注册日期排序（最后注册的key handle必须排在最后） （译者注：1.2版本新增了提示如下） > NOTE > 如果发现多个拥有同样username的key handles，first-factor roaming authenticator应该只保留最近注册的，并删除其余key handles。这样可以避免authenticator持有无用的（旧的）私钥，这些私钥可能会在删除新生成的key handles时重新变成可用的。
   3. 拷贝TAG_USERNAME_AND_KEYHANDLE到TAG_UAFV1_SIGN_CMD_RESPONSE并返回
8. 如果RawKeyHandles数量为1
   1. 创建TAG_UAFV1_SIGNED_DATA并设置TAG_UAFV1_SIGNED_DATA.AuthenticationMode = 0x01
   2. 如果TransactionContent非空
      • 如果这是一个slient authenticator，则返回UAF_CMD_STATUS_ACCESS_DENIED
      • 如果这个authenticator不支持交易
      • 确认（在先前的GetInfo Command中TransactionConfirmationDisplay设置为0），则返回UAF_CMD_STATUS_ACCESS_DENIED
      • 如果authenticator拥有内置的交易显示确认模块，则显示Command.TransactionContent和Command.TAG_APPID（可选）并等待用户确认：
        • 如果用户取消了交易，返回UAF_CMD)STATUS_USER_CANCELLED
        • 如果交易内容无法显示，则返回UAF_CMD_STATUS_CANNOT_RENDER_TRANSACTION_CONTENT
      • 计算TranscationContent的hash值
        • TAG_UAFV1_SIGNED_DATA.TAG_TRANSACTION_CONTENT_HASH = hash(Command.TransactionContent)
        • 设置TAG_UAFV1_SIGNED_DATA.AuthenticationMode = 0x02
   3. 创建TAG_UAFV1_AUTH_ASSERTION
      1. 填充TAG_UAFV1_SIGNED_DATA 剩余的数据域
         • SignCounter增加1并放入TAG_UAFV1_SIGNED_DATA
         • 复制所有强制要求的数据域（参考TAG_UAFV1_AUTH_ASSERTION
         • 如果 TAG_UAFV1_SIGNED_DATA.AuthenticationMode == 0x01 —— 设置TAG_UAFV1_SIGNED_DATA.TAG_TRANSACTION_CONTENT_HASH.Length = 0
         • 使用UAuth.priv签名TAG_UAFV1_SIGNED_DATA
   4. 把整个TAG_UAFV1_AUTH_ASSERTION作为TAG_AUTHENTICATOR_ASSERTION的值放入
   5. 拷贝TAG_AUTHENTICATOR_ASSERTION到TAG_UAFV1_SIGN_CMD_RESPONSE并返回结果

   规范 Authenticator不可以不先验证用户而去处理Sign command Authenticator不可以不先验证用户而展示username Bound authenticators不可以不先验证KHAccessToken而先去处理Sign command UAuth.priv密钥在解析为明文的时候，必须留存在Authenticator的安全区域。UAuth.priv保护边界声明在[UAFAuthnrMetadata]的Metadata.keyProtection中。 如果Authenticator的Metadata表示其支持“交易确认显示”（Transaction Confirmation display）——则其必须显示提供的交易信息并在TAG_UAFV1_SIGNED_DATA加入交易信息的哈希值 Silent Authenticators不可以工作在first-factor模式，以遵循[FIDOSecRef]中的假设 如果Authenticator不支持SignCounter，则在TAG_UAFV1_SIGNED_DAT中必须设置SignCounter为0。当Authenticator恢复出厂设置时SignCounter必须设置为0，以遵循[FIDOSecRef]中的假设 一些Authenticators可能支持“交易确认显示”功能，但不是在Authenticator内，而是在ASM的边界中。典型例子是基于软件的“交易确认显示”。当处理提供了交易的Sign command的时候，这些Authenticators应该假设他们的确有一个内置的“交易确认显示”，并讲交易信息的哈希值包括在最后的断言中，但并不显示东西给用户。不仅如此，这些Authenticator的Metadata文件必须明确显示交易确认显示”的类型。典型例子是“交易确认显示”的flag为TRANSACTION_CONFIRMATION_DISPLAY_ANY或TRANSACTION_CONFIRMATION_DISPLAY_PRIVILEGED_SOFTWARE。查看[UAFRegistry]了解“交易确认显示”的flag类型。

6.2.4 Deregister Command

该command删除Authenticator上已注册的UAF凭据。

6.2.4.1 Command Structure

6.2.4.2 Command Response

6.2.4.3 Status Codes

• UAF_CMD_STATUS_OK
• UAF_CMD_STATUS_ACCESS_DENIED
• UAF_CMD_STATUS_CMD_NOT_SUPPORTED
• UAF_CMD_STATUS_ERR_UNKNOWN

6.2.4.4 Command描述

Authenticator必须遵循以下步骤：

1. 如果authenticator有交易确认展示界面可以展示AppID，则需要保证（ASM）提供了Command.TAG_APPID，并在用户确认的时候进行展示。使用TAG_APPID更新Command.KHAccessToken：
   • 把Command.KHAccessToken和Command.TAG_APPID混合，结果赋值给Command.KHAccessToken。举个混合例子（使用加密哈希）：
     • 例：Command.KHAccessToken=hash(Command.KHAccessToken | Command.TAG_APPID)

   NOTE 这个方法允许我们避免在RawKeyHandle分开存储AppID。

2. 如果该authenticator没有自行存储key handles，则返回UAF_CMD_STATUS_CMD_NOT_SUPPORTED
3. 寻找匹配Command.KeyID的KeyHandle
4. 使用Wrap.sym解包KeyHandle
5. 保证RawKeyHandle.KHAccessToken == Command.KHAccessToken * 如果不相等则抛出UAF_CMD_STATUS_ACCESS_DENIED
6. 删除该KeyHandle
7. 返回UAF_CMD_STATUS_OK

（译者注：1.2新增了没提供KEYID的情况： * 如果TAG_KEYID长度为0，则 * 如果提供了TAG_APPID，则 * 对于每个匹配TAG_APPID的KeyHandle： 1. 如果RawKeyHandle.KHAccessToken == Command.KHAccessToken，则删除该KeyHandle，否则标记发生了错误（译者注：意思是还是要先删掉所有可以删的KeyHandle） * 如果触发了错误，则返回UAF_CMD_STATUS_ACCESS_DENIED

）

规范 Bound authenticators不可以不验证KHAccessToken而先处理Deregister command。

6.2.5 OpenSettings Command

该command告诉Authenticator开启其内置的UI设置界面（如修改密码，记录新指纹等）。

如果不支持该功能，Authenticator必须返回UAF_CMD_STATUS_CMD_NOT_SUPPOERTED。

6.2.5.1 Command Structure

6.2.5.2 Command Response

6.2.5.3 Status Codes

• UAF_CMD_STATUS_OK
• UAF_CMD_STATUS_CMD_NOT_SUPPORTED
• UAF_CMD_STATUS_ERR_UNKNOWN

7. KeyIDs与key handles

该章节不是规范。

该文档根据其在处理command时的特性和行为差异一共定义了4种Authenticator。其中一个主要的差别是它们存储和处理key handles的差异。该章节试图描述所有Authenticator在处理相关command的时候的行为。

7.1 first-factor Bound Authenticator

Register Command：

Authenticator不存储key handles。KeyHandles由ASM存储并提供。

KeyID为随机生成的32位随机数（或简单的就做成KeyHandle的hash值）

Sign Command：

当用户seesion不存在的时候（没有cookies，是一个刚清理的机器）。Server不会返回KeyID（因为Server不知道返回哪个KeyID）。这种情况下，ASM选择所有的key handles然后发给Authenticator。

在按步骤进行authentication的时候（此时有用户session），Server会提供相应的KeyID。ASM选择KeyID对应的key handles然后发给Authenticator。

Deregister Command：

因为Authenticator不存储任何key handles，所以Authenticator没什么需要删除的。

ASM找到KeyID对应的KeyHandle然后删除。

7.2 2ndF Bound Authenticator

Register Command：

Authenticator不存储key handles。KeyHandles由ASM存储并提供。

KeyID为随机生成的32位随机数（或简单的就做成KeyHandle的hash值）

Sign Command：

没有KeyID的时候Authenticator无法操作，即Authenticator无法在无用户seesion的环境中操作（没有cookies，是一个刚清理的机器）。

在按步骤进行authentication的时候（此时有用户session），Server会提供相应的KeyID。ASM选择KeyID对应的key handles然后发给Authenticator。

Deregister Command：

因为Authenticator不存储任何key handles，所以Authenticator没什么需要删除的。

ASM找到KeyID对应的KeyHandle然后删除。

7.3 first-factor Roaming Authenticator

Register Command：

Authenticator存储key handles到自己的内部存储空间。ASM不会发给Authenticator。

KeyID为随机生成的32位随机数（或简单的就做成KeyHandle的hash值）

Sign Command：

当用户seesion不存在的时候（没有cookies，是一个刚清理的机器）。Server不会返回KeyID（因为Server不知道返回哪个KeyID）。这种情况下，Authenticator选择匹配该AppID的所有key handles

在按步骤进行authentication的时候（此时有用户session），Server会提供相应的KeyID。Authenticator选择KeyID对应的key handles然后发给Authenticator。

Deregister Command：

Authenticator找到KeyID对应的KeyHandle然后删除。

7.4 2ndF Roaming Authenticator

Register Command：

Authenticator和ASM都不存储key handles。KeyHandles（将取代KeyID）将发送给Server，由Server存储到用户记录中。从Server的角度来说，KeyHandles被当作KeyID。实际上KeyID就是KeyHandles。

Sign Command：

没有KeyID的时候Authenticator无法操作，即Authenticator无法在无用户seesion的环境中操作（没有cookies，是一个刚清理的机器）。

在按步骤进行authentication的时候（此时有用户session），Server会提供相应的KeyID（实际上是KeyHandle）。Authenticator找到正确的key handles然后使用它（？？直接提供了还需要找吗？）

Deregister Command：

因为Authenticator和ASM不存储任何key handles，所以client端没什么需要删除的。

8. Command的访问控制

该章节是规范。

FIDO Authenticators可能会实现不同的机制去管理command访问控制。

下面的表格总结了各个command访问控制要求。

所有的UAF Authenticators必须满足下面的访问控制要求。

Authenticator厂商可能会提供额外的安全机制。

下面表格用到的词汇： NoAuth – 不需要访问控制 UserVerify – 明确的用户验证 KHAccessToken – 调用者必须持有KHAccessToken KeyHandleList – 调用者必须持有KeyHandleList KeyID – 调用者必须持有KeyID

表格 1:Command访问控制

9. 与其它标准的关系

*该章节不是规范。＊

与UAF authenticator有关的当前存在的标准说明文档有[TPM]，[TEE]和[SecureElement]。

实施这些标准的硬件模块可以通过它们的扩展机制来纳入UAF功能，如通过加载安全应用（trustlets，applets等）。不支持这样的扩展机制模块无法在UAF框架内得到充分的利用。

9.1 TEE

为了让TEE支持UAF，可设计一个的特殊Trustlet（在TEE内部运行的可信赖应用），实现本文档中指定的UAF Authenticator功能，并实现一些用户认证技术（生物特征识别，密码或其它东西）

需要额外创建一个知道如何调用Trustlet的ASM。

9.2 Secure Elements

为了让SE支持UAF，可设计一个的特殊Applets（在SE内部运行的可信赖应用），实现本文档中指定的UAF Authenticator功能，并实现一些用户认证技术（生物特征识别，密码或其它东西）

需要额外创建一个知道如何调用Applets的ASM。

9.3 TPM

TPM通常内置有认证模块支持，但支持的TPM认证模块和UAF基本认证模块不兼容。UAF的未来改进计划可能会包括兼容认证。

TPM通畅还有一个内置的PIN认证功能，这个功能可以被UAF利用。为了让这个TPM模块支持UAF，厂商需要写一个如下的ASM： * 通过调用TPM API转换UAF数据为TPM数据 * 使用TPM API创建断言（TLV） * 向FIDO UAF Client报告自己是一个合法的UAF authenticator

为TPM设计的一个特殊的断言方案也必须是被FIDO联盟创建和发布的(see [UAFAuthnrMetadata]）。当FIDO Server接收到这个断言方案的断言，则将这个数据当作是TPM生成的数据并解析和验证。

9.4 不可靠的传输

本文档描述的命令结构是基于可靠传输的假设上的，并且不支持应用层检测或修正例如乱序，重复，丢失和信息被修改这些问题。如果ASM和Authenticator之间的传输层不可靠，则可能需要一个UAF规范之外的机制来发现和修正传输错误。

A. 安全指南

本章节不是规范。

B. 图片列表

Fig. 1 UAF Authenticator Commands

Fig. 2 FIDO Authenticator Logical Sub-Components

C. 参考

C.1 规范参考

[Coron99] J. Coron and D. Naccache An accurate evaluation of Maurer’s universal test. LNCS 1556, February 1999, URL: http://www.jscoron.fr/publications/universal.pdf [FIDOGlossary] R. Lindemann, D. Baghdasaryan, B. Hill, J. Hodges, FIDO Technical Glossary. FIDO Alliance Proposed Standard. URLs: HTML: fido-glossary-v1.0-ps-20141208.html PDF: fido-glossary-v1.0-ps-20141208.pdf [ITU-X690-2008] X.690: Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), (T-REC-X.690-200811). International Telecommunications Union, November 2008 URL: http://www.itu.int/rec/T-REC-X.690-200811-I/en [SP800-90b] Elaine Baker and John Kelsey, NIST Special Publication 800-90b: Recommendation for the Entropy Sources Used for Random Bit Generation. National Institute of Standards and Technology, August 2012, URL: http://csrc.nist.gov/publications/drafts/800-90/draft-sp800-90b.pdf [UAFAuthnrMetadata] B. Hill, D. Baghdasaryan, J. Kemp, FIDO UAF Authenticator Metadata Statements v1.0. FIDO Alliance Proposed Standard. URLs: HTML: fido-uaf-authnr-metadata-v1.0-ps-20141208.html PDF: fido-uaf-authnr-metadata-v1.0-ps-20141208.pdf [UAFProtocol] R. Lindemann, D. Baghdasaryan, E. Tiffany, D. Balfanz, B. Hill, J. Hodges, FIDO UAF Protocol Specification v1.0. FIDO Alliance Proposed Standard. URLs: HTML: fido-uaf-protocol-v1.0-ps-20141208.html PDF: fido-uaf-protocol-v1.0-ps-20141208.pdf [UAFRegistry] R. Lindemann, D. Baghdasaryan, B. Hill, FIDO UAF Registry of Predefined Values. FIDO Alliance Proposed Standard. URLs: HTML: fido-uaf-reg-v1.0-ps-20141208.html PDF: fido-uaf-reg-v1.0-ps-20141208.pdf

C.2 非规范参考

[CLICKJACKING] D. Lin-Shung Huang, C. Jackson, A. Moshchuk, H. Wang, S. Schlechter Clickjacking: Attacks and Defenses. USENIX, July 2012, URL: https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final39.pdf [CommonCriteria] CommonCriteria Publications. CCRA Members, Work in progress, accessed March 2014. URL: http://www.commoncriteriaportal.org/cc/ [FIDOSecRef] R. Lindemann, D. Baghdasaryan, B. Hill, FIDO Security Reference. FIDO Alliance Proposed Standard. URLs: HTML: fido-security-ref-v1.0-ps-20141208.html PDF: fido-security-ref-v1.0-ps-20141208.pdf [FIPS140-2] FIPS PUB 140-2: Security Requirements for Cryptographic Modules. National Institute of Standards and Technology, May 2001, URL: http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf [NSTCBiometrics] NSTC Subcommittee on Biometrics, Biometrics Glossary. National Science and Technology Council. 14 September 2006, URL: http://biometrics.gov/Documents/Glossary.pdf [RFC2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119 [RFC4086] D. Eastlake 3rd, J. Schiller, S. Crocker Randomness Requirements for Security (RFC 4086), IETF, June 2005, URL: http://www.ietf.org/rfc/rfc4086.txt [SP800-38F] M. Dworkin, NIST Special Publication 800-38F: Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping. National Institute of Standards and Technology, December 2012, URL: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf [SP800-57] Recommendation for Key Management – Part 1: General (Revision 3). SP800-57. July 2012. U.S. Department of Commerce/National Institute of Standards and Technology. URL: http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf [SecureElement] GlobalPlatform Card Specifications GlobalPlatform. Accessed March 2014. URL: https://www.globalplatform.org/specifications.asp [TEE] GlobalPlatform Trusted Execution Environment Specifications GlobalPlatform. Accessed March 2014. URL: https://www.globalplatform.org/specifications.asp [TEESecureDisplay] GlobalPlatform Trusted User Interface API Specifications GlobalPlatform. Accessed March 2014. URL: https://www.globalplatform.org/specifications.asp [TPM] TPM Main Specification Trusted Computing Group. Accessed March 2014. URL: http://www.trustedcomputinggroup.org/resources/tpm_main_specification