今天我要介绍的是Qubes U2F代理，它是一个安全代理，目的是在web浏览器中使用U2F双因素身份验证设备，以保护浏览器的USB堆栈不被暴露，这就像我已在Qubes中实现的USB键盘和鼠标代理一样。

U2F的介绍

U2F的出现还要从2FA(双因素身份认证)说起，2FA的实施也有其自身局限性。例如，当你的双因素身份认证依赖于通过短信方式发送的一个验证码的话，攻击者则可以通过利用社会工程学骗取用户的电话以获取2FA。目前，最常见的双因素身份认证形式就是2FA，它是由用户手动输入到web应用程序中的数字代码组成。这些代码通常由用户智能手机上的应用程序生成或通过SMS发送。到目前为止，众所周知，这种两步身份验证的形式很容易受到网络钓鱼和中间人攻击，因为请求两步身份验证代码的应用程序本身通常不会由用户进行身份验证。换句话说，用户可能会不小心将代码交给攻击者，因为他们并不总是知道真正请求代码的是谁。幸运的是，还有一个双因素身份认证的替代方案：通用第二要素认证,或称U2F，它正是应用程序开发人员所需一个的开源方案。

U2F(Universal second Factor，通用第二因素认证)是由谷歌和Yubico共同创建的新的认证标准，该标准允许用户安全且即时的使用一个设备去访问多个在线服务，而不需要安装特殊的设备驱动程序或客户端软件。通过使用U2F，用户可以使用一个令牌来认证许多个服务。

U2F要求用户使用一个支持U2F标准的钥匙令牌(如USB类型)设备和浏览器。而钥匙设备的功能是作为一个安全令牌，让用户登录到多个支持U2F的在线服务上，那些服务包括了定制的应用程序，目前Chrome和Firefox都已支持U2F。

Yubico定义U2F为：“一个具有挑战-响应协议的扩展，它提供网络钓鱼和MitM(中间人攻击)保护，特定应用程序的密钥，设备克隆检测和设备认证功能。”该协议的控制旨在对已知的和新的攻击予以防护。它使用的是非对称加密，也称公钥加密算法，其中私钥驻留在Yubikey设备之中。

U2F规范定义了从USB到浏览器API的多层协议，整个堆栈旨在与浏览器中的Web应用程序（最常见的网站）一起使用。在大多数情况下，令牌是USB加密狗。该协议非常简单，允许设备在内部存储非常少的状态（因此令牌可能相当便宜），同时验证几乎无限数量的服务（因此每个人只需要一个令牌，而不是每个应用程序一个令牌）。用户界面通常限于单个LED和按下按钮以确认每个事务，因此设备本身也易于使用。

既然U2F式的双因素身份认证协议依赖于浏览器上客户端级别的验证，那么潜在的攻击就可能来自驻留于浏览器本身的安全漏洞。所以U2F的安全性取决于谷歌、Mozilla等其它公司在其浏览器上应用该协议的良好程度。

U2F的潜在安全问题

在传统的设置中，web浏览器和USB堆栈(U2F令牌与之相连)都在同一个单片操作系统中运行。由于U2F模型假定浏览器是可信的，因此操作系统中的任何浏览器都能够访问存储在U2F令牌上的任何密钥。但问题是用户无法具体知道，哪些浏览器访问了哪些服务的密钥。如果任何浏览器遭到破坏，则应假设所有令牌的密钥都已泄露。 不过，如果此时U2F设备有一个特殊的显示来向用户显示正在进行身份验证的内容，则这个问题可以得到缓解。此外，由于USB堆栈位于同一个单片操作系统中，因此系统容易受到像BadUSB这样的攻击

相比之下，在Qubes操作系统中，可以安全的将浏览器划分到一个qube中，而将USB堆栈划分到另一个qube中，这样它们就可以始终保持独立运行。然后，Qubes U2F代理允许连接到一个qube中的USB堆栈的令牌在一个独立的qube中与浏览器通信。从浏览器的角度来看，我们假设USB堆栈是不可信的，并且浏览器不能被令牌盲目的信任。因此，令牌永远不会位于与浏览器相同的qube中。而Qubes U2F代理只转发实际执行身份验证所需的数据，将所有不必要的数据都删除，因此它不会成为攻击的载体。

Qubes U2F代理分成两大部分：前端和后端。前端与浏览器在同一个qube中运行，并使用uhid提供了一个伪装的类usb HID设备。后端在sys-usb中运行，其行为类似于浏览器。这是使用u2flib_host参考库完成的，Qubes U2F代理所有的代码都是用Python编写的，标准qrexec策略负责将调用定向到适当的域。

上图底部带有虚线的vault qube描述了Qubes U2F代理的工作原理，即在隔离的qube中使用软件令牌而不是物理硬件令牌实现Qubes U2F代理，这类似于Split GPG允许我们在不使用物理智能卡的情况下模拟智能卡模型的方式。

U2F的一个非常重要的假设是浏览器验证发送到U2F令牌的每个请求，特别是，发送认证请求的Web应用程序与将通过回复该请求进行认证的应用程序匹配，以便防止如钓鱼网站向你的银行发送一个身份验证请求的站点。但是，借助Chrome中的WebUSB功能，恶意网站可以通过直接连接到令牌而不是使用浏览器的U2F API来绕过此安全措施。

Qubes U2F 代理还会通过实施额外的验证层来防止此类攻击，例如，此验证层允许你强制执行twitter qube中的Web浏览器只能访问与https://twitter.com关联的U2F密钥。这意味着，如果你的Twitter qube中的任何内容被泄露（浏览器甚至操作系统本身），你的令牌上的U2F密钥则无法访问，更不用说用于任何其他网站或服务了，例如你的电子邮件和银行帐户。与单片系统相比，这是另一个重要的安全优势。 （有关详细信息和说明，请参阅下面的高级用法部分。）

为了获得更多保护，你可以将其与Qubes防火墙结合使用，以确保你的银行qube中的浏览器仅访问一个网站，即你银行的官网。通过配置Qubes防火墙以防止你的银行qube访问任何其他网站，这样，你可以降低其他网站破坏浏览器以试图绕过U2F身份验证的风险。

Qubes U2F 代理的安装

Qubes U2F代理工具可以安装在Qubes 3.2和4.0中。但是，其中的高级使用功能仅在4.0中可用。布偶过前提是有一个保存USB堆栈的sys-usb qube，这是大多数Qubes操作系统安装中的默认配置。

在dom0中：

$ sudo qubes-dom0-update qubes-u2f-dom0
$ qvm-service --enable work qubes-u2f-proxy

在Fedora TemplateVMs中：

$ sudo dnf install qubes-u2f

在Debian TemplateVMs中：

$ sudo apt install qubes-u2f

重复qvm-service，启用所有的Qubes U2F代理或在VM设置中执行此操作。与通常的软件更新一样，在安装后关闭模板，然后重新启动sys-usb和所有使用代理的qubes。之后，您可以使用U2F令牌。

高级用法——per-qube密钥访问

如果你使用的是Qubes 4.0，则可以通过限制每个qube对特定密钥的访问来进一步划分你的U2F密钥。这样做，不管你的twitter qube中的任何web浏览器或twitter qube本身是否受到攻击，你的twitter qube以及你的twitter qube中的所有web浏览器只能访问你的U2F令牌上的https://twitter.com上的密钥。如果你的Twitter qube为你的银行网站发出身份验证请求，则会在Qubes策略级别将此请求拒绝。

要启用此功能，请在dom0中创建名为/etc/qubes-rpc/policy/policy.RegisterArgument+u2f.Authenticate的文件，其中包含以下内容：

sys-usb @anyvm allow,target=dom0

接下来，删除/etc/qubes-rpc/policy/u2f.Authenticate的内容，使其成为空白文件，记着不要删除文件本身。如果删除文件本身，下次更新时将重新创建默认文件。最后，按照Web应用程序的说明注册你的令牌并照常使用它。

注意：此注册过程取决于Web应用程序，并不特定于Qubes U2F。

默认模型是允许qube访问所有且仅访问该qube注册的密钥。例如，如果你的银行qube注册了你的银行密钥，并且你的Twitter qube注册了你的Twitter密钥，那么你的银行qube将可以访问你的银行密钥而不是你的Twitter密钥，与此同时，你的Twitter qube将可以访问你的Twitter密钥，而不是你的银行密钥。

TemplateVM和浏览器支持

Qubes版本（3.2,4.0），TemplateVM（Fedora 27,28; Debian 8,9）和浏览器（多个Google Chrome版本，多个Chromium版本，多个Firefox版本）都可以支持U2F，因此我不可能测试每个使用U2F的情况。

请注意，在Quantum之前的Firefox(例如Debian 9中的Firefox 52)中，你必须安装U2F支持插件。在Firefox post-Quantum中，你可能必须在about：config中启用security.webauth.u2f标志，而Chrome和Chromium不需要任何特殊的浏览器扩展程序。

Qubes U2F的未来适用前景

U2F规范不仅考虑到了USB令牌，还考虑到了智能卡（ISO 7816）设备，包括NFC设备（主要用于智能手机）。

从理论上讲，U2F令牌并不局限于web应用程序。在dom0中使用的发行版Fedora具有允许用户使用相同令牌进行身份验证的程序包，U2F代理也可以在dom0中运行。