对FIDO、UAF和U2F的MITM攻击

Question

在讨论MITM攻击的U2F(通用第二因子)概述第6节中--接近本节的末尾，它的内容如下：

It is still possible to MITM a user's authentication to a site if the MITM is 

a. able to get a server cert for the actual origin name issued by a valid CA, and 
b. ChannelIDs are NOT supported by the browser. 

But this is quite a high bar. 

我不相信这是这么高的标准。我们已经看到了不止几个攻击者能够获得伪造但可信的CA签名证书.的例子。而且，TLS ChannelID还没有被大多数浏览器和服务器广泛采用(事实上，RFC提案草案于2013年到期)。此外，即使两个端点都支持TLS ChannelID，活动的MITM攻击者也可以通过在ClientHello消息期间通过降级攻击的方式阻止TLS ChannelID的使用。

我赞赏FIDO为减少我们对密码的依赖，以及使身份验证更加安全和减少用户的麻烦而做出的飞跃。但是，它似乎对防止MITM攻击几乎没有什么作用，因为攻击者能够拿到伪造但可信的证书，我们必须继续把我们的全部信念和信任放在CA上，因为CA有让我们失望的历史。当然，即使是最安全的身份验证协议，如果连接可能被活动的MITM攻击者破坏，也是毫无用处的。

其他基于密钥的身份验证协议(如SSH)通过将内置的公钥钉入该协议来防止MITM攻击。例如，使用SSH，客户端存储它们连接到的服务器的公钥。在建立连接之后，在密钥交换期间和试图进行任何客户端身份验证之前，客户端通过检查服务器正在使用的公钥是否与该服务器的文件中的公钥相同，并通过某些需要私钥的加密操作，确保服务器拥有与公钥关联的私钥。

当然，HPKP (没有FIDO)可以用于将站点的SSL/TLS证书插入到浏览器中，但是它有它的自己的一组问题。

我很好奇为什么FIDO和U2F的架构师没有更进一步，在协议中嵌入一种公钥钉扎方法(可能使用与SSL/TLS连接使用的不同的密钥)，这样客户端就可以确保在尝试身份验证( la SSH )之前连接到合法服务器。有人愿意假设吗？

Answer 1

我和你一样认为U2F是一份好工作，即使这是一份半做的工作。注:我是一家小公司(FIDO联盟成员)的安全架构师，拥有自己的U2F认证产品。

关于即将到期的TLS ChannelID支持，人们认为它最终将演变为令牌绑定支持(更新的规范，相同的目标)。https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/是的，在服务器端实现TlS通道ID并不容易(BoringSSL库可以帮助)，是的，它只在客户端得到TlS的支持，是的，它可以被降级。但是，好的是，如果您考虑在您自己的服务器/服务上使用U2F，它仍然可以完成，并且可以强制执行。确实，在许多全局服务(gmail、facebook.)上，TLS通道ID保护被完全停用。

对于关键定位的争论以及服务器认证部分为什么依赖好/坏的旧SSL服务器证书，最初的决策可能是技术困难和“政治”定位的混合结果。U2F (和UAF)已经攻击客户端已经建立的证书颁发机构.注意:这些是匿名客户端密钥对，但相关的认证/生产证书可以由FIDO联盟私钥(成为自己的证书颁发机构.)签名。

处理相互认证也需要更大的内存..。我不在乎，但对于一些解决方案提供商来说，这可能是个问题。

无论最初的真正原因是什么，它都没有完成，据我所知，这种特性在未来的U2F发行版中没有计划.也没有计划WebAuthN ( U2F/UAF的继承者)。

但这并不意味着U2F不能适应于支持增强的相互认证功能.我正在和其他几个傻瓜合作:欢迎来到我们的疯狂:)