FIDO U2F令牌的安全性如何

#1 楼

我得到的答案很好，但是我想提供更多的深度，特别是系统为什么存在的原因，这应该进一步解释它的优点。

免责声明：当我现在为Google工作时，在撰写此答案时，我对该项目一无所知。此处报告的所有内容均来自公共资源。这篇文章是我自己的观点，观察和评论，并不代表Google的观点，观点或意图。
值得指出的是，我已经使用并修改了一段时间了。 ，以及从事社会工程和帐户接管工作的人，我对这里所取得的成就印象深刻。

为什么需要一些新的东西
考虑一下：Google已部署两因素身份验证很久以前。这是一家非常关注安全性的公司，而他们的安全性一直是一流的。尽管他们已经在使用最好的技术，但是U2F在传统2要素之上提供的额外安全性是如此重要，以至于值得公司花费时间和金钱来设计，开发，部署和支持他们没有的替代系统。甚至自己也不卖。是的，这是他们走这条路的极具社会意识的举动，但这不仅关乎社区。 Google之所以这样做，是因为他们自己需要U2F本身提供的安全性。许多人信任他们最宝贵的信息，而有些人在危险的政治环境中甚至信任谷歌的生活。 Google需要安全性，才能实现这种信任。
归结为网络钓鱼。网络钓鱼很重要。这是非常普遍且非常有效的。对于针对硬化目标的攻击，网络钓鱼和类似攻击确实是攻击者的最佳选择，他们也知道。更重要的是：
我们的网络钓鱼防护是可笑的。我们有两个因素的身份验证，但实现很少提供防御。诸如SecurID，Google Authenticator，电子邮件，电话和SMS循环之类的常见系统-所有这些系统都无法完全抵御使用时间的网络钓鱼攻击。一次性密码仍然是密码，可以将其公开给攻击者。
这不仅是理论上的。我们已经看到这些攻击实际上是在进行的。实际上，攻击者确实捕获了发送到网络钓鱼站点的第二因素响应，并立即在真实的登录页面上播放它们。这实际上发生在现在。
所以说你是Google。您已经部署了最好的保护措施，您会发现它们还不够。你是做什么？没有其他人可以为您解决这个问题。您必须弄清楚。
解决方案很简单；采用才是真正的问题
创建无法被仿制的第二要素解决方案非常简单。您所要做的只是涉及浏览器。在U2F的情况下，设备会为每个站点创建一个公钥/私钥对，并将站点的身份刻录到该站点用来请求身份验证的“密钥句柄”中。然后，每次尝试进行身份验证之前，浏览器都会验证该站点身份。站点身份甚至可以绑定到特定的TLS公共密钥。而且由于它是一个挑战响应协议，因此也无法重播。而且，如果服务器在数据库泄露中意外泄漏了您的“密钥句柄”，它仍然不会影响您的安全性或泄露您的身份。使用此设备可有效消除网络钓鱼的可能性，这对安全敏感的组织来说意义重大。
加密货币及其应用都不是新的。两者都是很好理解和信任的。技术从来都不是难题，难题是采用。但是，谷歌是少数能够克服通常阻碍此类解决方案发展的障碍的公司之一。由于Google是最受欢迎的浏览器，因此他们可以确保默认情况下兼容。由于他们是最受欢迎的移动操作系统，因此可以确保它也能正常运行。而且由于他们运行着最受欢迎的电子邮件服务，因此他们可以确保该技术具有相关的用例。
比必要的更开放
当然，Google可以利用这一优势在竞争中获得竞争优势。市场，但他们没有。那太酷了。每个人都需要这种级别的保护，包括Yahoo和Microsoft及其竞争的电子邮件产品。很棒的是，它的设计使得即使竞争对手也可以安全地制造自己的产品。这项技术与Google无关，即使硬件完全与使用无关。
该系统在设计时就假设您不会仅将其用于Google。该协议的关键特征是令牌永远不会标识自己。实际上，规范指出，选择这种设计是为了防止创建“超级Cookie”的可能性，该超级Cookie可用于在合谋服务之间跟踪您。
因此，您可以获得单个令牌，不仅可以在Gmail上安全地使用它， ，也可以在支持U2F的任何其他服务上使用。这给了您更多理由放下一笔钱。由于Yubico用PHP，Java和Python发布了服务器软件的参考实现，因此即使在小型商店中，也可以安全地在自己的服务器上启动并运行身份验证。

#2 楼

U2F能够使用使用公钥加密的加密通道来确保只有正确的服务器才能获得一次性令牌。这意味着在网络钓鱼站点上插入它意味着什么也没发生-他们无法进入您的帐户。相反，他们必须依靠XSS和本地恶意软件之类的技术攻击。

应该可以掩盖您将同一设备用于多种服务的事实，因此控制站点A和站点B的人看不到您使用了同一设备双方。应该是安全的。

这似乎是目前可用的最佳选择，主要是因为正在进行的标准化过程以及对其的广泛支持和发展势头。

根据FIDO规范




在向在线服务注册期间，用户的客户端设备会创建一个新的密钥对。它保留私钥，并在在线服务中注册公钥。客户端设备通过签署挑战来证明拥有服务私钥，从而完成身份验证。客户端的私钥只有在用户在设备上本地解锁后才能使用。本地解锁是通过用户友好且安全的操作来完成的，例如，滑动手指，输入PIN，对着麦克风讲话，插入辅助设备或按下按钮。

#3 楼

我尚未完全探索规范。但是：


U2F与OTP有什么根本的区别？
U2F不使用OTP。它实际上是关于站点身份验证以及将拥有私钥作为因素的。
与OTP系统相比，U2F对网络钓鱼攻击的可行性有何影响？
有时间限制的OTP系统在防止网络钓鱼（窃取凭据）方面非常出色，因为它们很难被窃取。 U2F的确旨在抵抗MiTM攻击。
针对U2F的非交互式攻击（例如蛮力等）如何可行？
蛮力攻击并不是真正的解决之道。您可能想从服务器或客户端上窃取密钥。它如何处理恶意软件等是关键。实现将非常重要。
我可以安全地使用具有多个独立服务的单个U2F令牌吗？
确定-这就是为什么公钥/私钥比共享机密更好的原因。

U2F如何与其他商业产品相提并论？有更好的解决方案吗？
我只能和我们的产品（无论是商业版本还是开源版本）进行交流。主要区别在于，我们将目标站点的ssl证书的哈希存储在身份验证服务器中，并提供由身份验证服务器的私钥加密的OTP。在用户获得OTP之前，软件令牌会通过用户的连接获取目标站点的证书，对其进行哈希处理并进行比较。如果它们匹配，则会显示OTP，然后将其复制到剪贴板，然后将浏览器启动到URL。如果没有，则给出错误。

因此，无需更改服务器或浏览器。密钥存储在与Web服务器不同的服务器上。 OTP是该过程的一部分（尽管可以将其删除/隐藏）。它是开源的。另一方面，U2F确实有发展动力，尽管它是“按需付费”财团。 U2F在某些“安全”硬件产品上可用。我们可以在它们上实现（例如，加密USB驱动器）。 YMMV。

有关WiKID相互身份验证的更多信息，请访问：https：//www.wikidsystems.com/learn-more/technology/mutual_authentication以及此处的操作方法：http：//www.howtoforge .com / prevent_phishing_with_mutual_authentication。

#4 楼

我刚刚阅读了一些规范，因为我想知道设备是否存储了实际的（私有）密钥。我可以尝试回答一些问题。

OTP只是一次性令牌，而U2F基于公钥加密；更具体地说，Yubico Fido U2F密钥似乎使用了椭圆曲线密码。

U2F应该有助于防止网络钓鱼攻击，因为您必须通过手动干预（即按按钮）来确认交易。窃取密钥将需要窃取设备本身，这可能比OTP针更难，具体取决于人们将其存储在何处。当然，这两种方法仍然在一定程度上容易受到MitM攻击；如果攻击者能够以某种方式在您与服务之间进入，干扰正在进行的会话，那么您将无能为力。流量应该经过加密，端点验证，并且没有人可以完全访问您的计算机；显而易见的东西。

我想破解U2F密钥的可行性取决于特定硬件密钥上已实现的公共密钥算法的强度。 Yubico键似乎在P-256 NIST椭圆曲线上使用ECDSA。判断一下自己的位数（以及曲线的来源）是否足够安全和​​可靠...

FIDO的概述文档中提到“廉价的U2F设备”，它们不存储实际的私钥但是将它们加密（包装）存储在“密钥句柄”中，该标识符是将私钥和公钥链接在一起并发送到远程服务的标识符。
因此，如果我对它的理解正确，那么远程服务会同时获取公共密钥（按原样）和私有密钥（在密钥句柄中加密），因此，安全性实际上取决于硬件设备上使用的算法的安全性。远程站点具有您的私钥！从某种意义上讲，这是将用户的会话加密后存储在cookie中的相反过程–此处，远程站点保留密钥，私钥部分被加密，并且理论上只能由硬件设备解密。有趣的是，这种Yubico设备本身就是这样的设备，即密钥会离开设备而不是包含在设备中。

我了解经济和易于使用的动机–存储了很多在这类设备中，芯片上的密钥对会更昂贵-但我不确定我是否喜欢这种方法。

因此，请回到您有关将令牌与多个独立服务一起使用的问题：由于密钥对保存在服务本身上，因此该设备可以生成任意数量的对。登录时，设备将解开私钥并检查签名。该消息包含源，因此密钥应仅适用于该特定服务。

出于高度安全的目的，最好使用以某种方式存储（或生成）私钥的设备根本无法检索它们，也永远不会离开设备。我对这些设备的电子方面一无所知，但我假设，假设设备使用的芯片与现代智能卡使用的芯片相同，那么这将需要相当复杂的攻击者窃取然后破解物理硬件来获取密钥。 ，sims和其他形式的硬件加密。

来源：


概述：“ 7。允许廉价的U2F设备”
实现注意事项： “ U2F令牌可能不存储私钥材料，而是可能导出包装的私钥作为密钥句柄的一部分。”
还要检查FIDO“原始消息格式”文档。

#5 楼

U2F令牌使用公钥密码术实现质询响应算法。它提供了两个功能：注册新来源和计算对挑战的响应。

因此，它不实现一次性密码（OTP）生成。

注册新密码Origin

（起源字符串标识远程系统，例如远程服务器的主机名。）

注册新起源时，令牌将起源字符串作为输入，返回


新生成的公钥（KA），
证明书（即证明公钥和使用证明私钥在KA上的签名），
使用新创建的私钥的密钥句柄（H）和
签名（在原点，KA和H上）

。证明密钥对在同一供应商生产的一组设备之间共享，并且通常由著名的CA签名。密钥句柄是标识KA的字符串。所有这些项目都被发送到原点。

签署挑战

在签署挑战（即生成响应）时，令牌将获取原始字符串，挑战数据（包含会话）


如果输入的原点与原点不匹配，则返回错误。
如果输入的是原点，则返回错误。未知，则返回错误。
否则，将对质询数据和内部事务计数器的值进行签名计算（使用密钥句柄引用的私钥），并将其与计数器一起返回值。

可能的令牌实现




有效的U2F令牌实现具有可能较大的可写关联数组，其中密钥句柄映射到私钥和来源信息。该数组一定不能离开该标记，因此应加以保护以防止将其读出。

U2F规范不允许将私钥重用于不同的来源。因此，还需要一个大数组。

或者，也可以使用没有任何读写存储器的U2F令牌实现：令牌将令牌对称地加密，而不是将私钥和源存储在令牌内带有内部钥匙（K0）。然后将结果作为键句柄返回。在理智的硬件设计中，K0不能离开令牌。换句话说，私钥和原始字符串是从外部存储的，它们被分配到原始位置，因为它们被用作密钥句柄-这很好，只要不能破坏加密即可。

基本上，大多数可用的U2F令牌都实现了第二种方法，因此生产起来相对便宜（在亚马逊上起价约为5欧元：搜索“ FIDO U2F”）。 Yubikey U2F就是这种实现方式的一个例子。

攻击

在通常情况下，强行攻击是不可行的。一种这样的攻击是当您知道公钥时尝试强行使用特定于源的私钥。


假设正在使用便宜的U2F令牌，则也可以尝试强行使用当您知道特定于原点的键句柄时，选择内部键（K0）。仅当令牌供应商犯了设计错误时，这才可行。例如，当供应商使用相同的内部密钥运送每个令牌并且密钥以某种方式泄漏时。
或者，如果内部密钥K0为：每个令牌都不同，但是K0最终无法重新初始化-用户，由卖方保留并与另一方（自愿或非自愿）共享-然后，该方可以毫不费力地强制使用一个密钥句柄（该密钥句柄来自该卖方产生的令牌）。
另一种风险将是是在令牌内部使用的弱对称加密算法实现，因此，可以使暴力破解密钥句柄H中的加密数据变得更加容易。

由于U2F令牌验证了来源并将特定于会话的数据用作挑战，因此某些网络钓鱼和中间人被击败。

#6 楼

我认为，令牌用户无法通过按令牌上的按钮来查看他/她实际上同意的行为是非常糟糕的。否则，在不受信任的公共PC上具有受感染OS的用户可以不经意地将恶意程序放到自己的银行帐户中，而无需登录Facebook。

但是，U2F协议包含有关当前操作（URI）的信息，AppID和可选的TLS通道ID）。我认为，在开始使用这些设备之前，请先等待带有小液晶屏的U2F令牌的出现，该小屏幕将显示这些信息（至少是AppID），然后在发现事实并非如此的情况下允许采取不同意见如您所愿。