Qubes U2F代理是一个利用Web浏览器使用U2F双因素身份验证设备的安全代理，有它在浏览器将不会被暴露给完整的USB堆栈。 [出自:jiwo.org]

什么是U2F？

U2F是“Universal second Factor”的缩写，它是一个使用硬件设备(U2F令牌)作为“second factors”进行身份验证的框架，即你所拥有的内容与你所知道的内容(如密码)相反。这种额外的控制在密码被盗的情况下提供了良好的保护(例如通过网络钓鱼或键盘记录)。虽然密码破解对用户来说可能不是很明显，但对于恶意破解人来说则增加了一个环节：必须获得无法复制的物理设备。尽管如此，还是需要注意U2F无法全方位保证面临威胁时主机系统的安全性。(例如在对手控制下感染恶意软件的操作系统)。

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

目前，最常见的两步身份验证形式是由用户手动输入到web应用程序中的数字代码组成。这些代码通常由用户智能手机上的应用程序生成或通过SMS发送。到目前为止，众所周知，这种两步身份验证的形式很容易受到网络钓鱼和中间人攻击，因为请求两步身份验证代码的应用程序本身通常不会由用户进行身份验证。(换句话说，用户可能会不小心将代码交给攻击者，因为他们并不总是知道真正请求代码的是谁。)相比之下，在U2F模型中，浏览器确保令牌接收关于请求身份验证的web应用程序的有效信息，这样令牌就知道它正在验证哪个应用程序。尽管如此，即使使用U2F，一些攻击仍然是可能实现的。

特点

在传统的设置中，web浏览器和USB堆栈(U2F令牌与之相连)都在同一个单片操作系统中运行。由于U2F模型假定浏览器是可信的，因此操作系统中的任何浏览器都能够访问存储在U2F令牌上的任何密钥。用户无法知道哪个浏览器为哪个服务访问了哪个密钥。如果有任意一个浏览器受到攻击，令牌的所有密钥都可能受到攻击。(但是，如果U2F设备有一个特殊的显示器向用户显示正在进行身份验证的内容，则可以减轻此问题。)此外，由于USB堆栈在同一个单片操作系统中，系统很容易受到类似BadUSB的攻击。

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

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

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

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

Qubes U2F 代理还通过实施额外的验证层来防止此类攻击。例如，此验证层允许您强制执行twitterqube中的Web浏览器只能访问与之关联的U2F密钥https://twitter.com。这意味着如果用户twitterqube中的任何内容遭到破坏，它仍然无法访问用户的令牌上的U2F密钥以用于任何其他网站或服务，比如电子邮件和银行帐户。这是相对于单片系统的另一个显著的安全优势。为了获得更多保护，还可以将U2F代理与Qubes防火墙结合使用，通过配置Qubes防火墙以防止银行qube访问任何其他网站，以降低其他网站在尝试绕过U2F身份验证时破坏浏览器的风险。