Universal 2nd Factor (U2F) 概述（6）-认证过程中的中间人攻击保护

如果一个中间人设法在用户设备与网站之间认证过程中以中介的方式进行攻击，U2F设备协议在大多数场景下是可以直接检测并防止的。

当用户在某一个网站正常的注册了U2F设备，中间人设法在另外一个不同的网站进行身份认证时，用户的U2F设备是不可能有响应的，因为这个中间人使用的网站名称是不可能匹配到KeyHandle字段的。U2F设备也可以用于检测更复杂的其他中间人攻击的场景，如下：

作为U2F调用签名“sign”函数返回的一个数据，浏览器会返回关于源网站的相关数据对象（即“ClientData”），ClinetData包括：

a.源网站的随机挑战值；
b.浏览器中看到的源主机名，用于创建javascript调用；
c.（非必须的）如果对TLS的ChannelID扩展被使用，则连接ChannelID的公钥；

浏览器将ClientData进行HASH运算后发送给U2F设备。另外，这个ClientData的HASH值，如前所述，浏览器将源网站和KeyHandle的HASH值处理作为U2F设备的额外输入。

当U2F设备收到ClientData的HASH值，源网站和KeyHandle的HASH值后，如果确定为这个源网站生成过KeyHandle，U2F设备或会进行ClientData的HASH值签名并且发送。这个签名数据将会被作为另外一个U2F调用签名“sign”函数的返回数据。

网站会将U2F调用签名“sign”函数的两个返回数据，ClientData的HASH值和签名数据一并返回到源网站依赖方，当依赖方接受到数据后，第一步就是检查签名数据和用户的公钥签名是否匹配。依赖方可以经一部检查ClientData是有中间人攻击：

1）如果ClientData中的源网站名称是错误的表明：
a.有中间人攻击；
b.尽管是一个复杂的中间人攻击，在注册获得了U2F设备生成的KeyHandle，以匹配中间人攻击自己的源网站名称，而中间人攻击现在正在尝试进行身份验证。如前所述，只有在身份验证时，而不是在注册时，中间人攻击将会失败，因为U2F设备将拒绝签名，因为源网站和KeyHandle不匹配。

2）如果ClientData中一个ChannelID或origin使用了SSL连接的ChannelID：
a.如果ClientData中的ChannelID和源网站使用的ChannelID不匹配，那么证明有中间人攻击；
b.尽管是一个复杂的中间人攻击，它拥有一个真实有效的源SSL证书，因此与“源网站名称”的观点是不可区分的。

有可能在用户认证过程中受中间人攻击的可能性：
a.获得实际源网站名称的服务器证书，并且该证书是有效CA发布的。
b.浏览器不支持ChannelID。

但是这个难度是相当高的。

U2F设备不保护的中间人攻击案例如下：
在一个线上服务或网站中，它接受简单的密码，但允许用户自行注册并逐步升级到U2F。在用户与真实站点之间存在不同源网站时，中间人可以将U2F设备注册到自身，而不将此注册传递给真实站点源网站，这仍然会使用户只需要一个密码。然后，对于身份验证，中间人可以接受U2F设备，并对真实的源网站进行身份验证。

假定用户在URL中没有注意到错误的(不同的)来源，用户就会认为他们是通过强大的身份验证登录到实际的源，因此非常安全，但实际上他们被中间人攻击了。

防止钓鱼网站

假如，某钓鱼网站在你注册的时候，获取到了你的Key Handle和公钥。当做认证的时候，浏览器获取的网址（application identity）和你注册的时候网址是不一样的。这样，将Key Handle ，app_id信息传入U2F设备中，U2F设备也不会实施签名操作，因为它发现自身存储的Key Handle对应的app_id和传入的app_id不一致。