Geekly articles weekly

谈论PAKE

现在让我们谈谈信息安全。 该出版物致力于启动“加密信息安全”课程，该课程将于5月30日开始。 走吧

PAKE的第一条规则：永远不要谈论PAKE。 PAKE的第二条规则指出，第一条规则是胡说八道，因为PAKE或密码认证密钥交换 （带有密码认证的密钥交换）是最实用的技术之一，几乎从未在任何地方使用。 应该尽可能地实现它，但是要实现起来并不那么简单。




要了解为什么我们在谈论废话，让我们看一个真正的问题。

假设我使用存储用户密码的服务器。 有一种传统的存储方式-哈希每个用户密码并将结果存储在密码数据库中。 关于如何处理哈希过程有很多想法。 今天，最常见的建议是对每个密码使用具有存储硬性的密码哈希函数（例如scrypt或argon2 （具有唯一的salt ）），然后存储哈希结果。 关于使用哪个哈希函数以及它是否可以使用某个秘密值（称为“ pepper” ），存在不同的看法，但是现在我们不再谈论它。

无论您选择哪种方法，所有这些解决方案都有一个致命弱点：
当用户返回进入站点时，他仍然需要将其（开放）密码发送到服务器，以便他进行验证 。

如果您的服务器受到威胁或开发人员犯了一些愚蠢的错误，则这种需求可能导致不愉快的后果。 例如，去年年初，Twitter要求所有用户（还有3.3亿！） 更改密码 -因为事实证明该公司存储了文本（非哈希）密码。

目前，登录问题丝毫没有抵触密码哈希的好处。 但是，您需要找到一种更好的解决方案：永远不要以明文形式将密码发送到服务器的解决方案。 可以帮助我们实现这一目标的密码工具是PAKE，尤其是称为OPAQUE的新协议，我们将在本文结尾处介绍。

什么是PAKE？


Bellovin和Merritt首先提出的PAKE协议是一种特殊的密钥交换协议 。 密钥交换协议（或“密钥协议”）旨在帮助两方（我们称其为客户端和服务器）使用公共密钥密码术就共享密钥达成协议。 最早的密钥交换协议（例如，经典的Diffie-Hellman ）是未经授权的，这使它们容易受到中间人之类的攻击。 PAKE协议的显着特征是客户端使用密码向服务器进行身份验证。 出于明显的原因，假定服务器已经知道了密码或其哈希，这允许进行验证。

如果仅需这些，PAKE协议将很容易构建。 但是使PAKE真正有用的是它还提供了客户端密码保护。 可以制定以下更严格的保证：尝试进入系统（成功或失败）之后，客户端和服务器仅应知道客户端密码是否与服务器期望的值匹配，并且无需其他任何信息。 这是一个相当不错的防守。 实际上，这与零泄漏证明所要求的没什么不同。


PAKE协议的理想表示。 双方的输入都包含一些随机性，此处未显示。 窃听者无需找出共享密钥K，该密钥本身是随机的，并且与密码无关。

当然，PAKE的明显问题是，许多开发人员都不希望一开始就运行“密钥交换”协议！ 他们只想确保用户知道密码。

PAKE的伟大之处在于“仅登录”用例非常易于执行。 假设我有一个标准的PAKE协议，该协议允许客户端和服务器就公用密钥K达成一致。如果他知道正确的密码（并且仅在这种情况下），那么我们所要做的就是简单地检查双方是否都收到了相同的键。 （例如，如果各方使用它来计算某些加密功能并验证结果，则可以这样做。）因此，即使您只想验证密码，PAKE还是有用的。

SRP：PAKE，大约自己忘记了什么时间


与我们今天用来进入服务器的简单方法相比，PAKE概念似乎提供了明显的安全优势。 从1992年以来就知道PAKE的意义上说，这些方法本身就是古老的！ 尽管如此，光从未见过他。 为什么会这样呢？

有几个明显的原因。 最明显的是与Internet的局限性有关：在网页上放置密码表比在浏览器中实现奇特的加密要容易得多。 但是，这种解释还不够。 即使是本机应用程序，也很少为登录操作实现PAKE。 另一种可能的解释与专利有关，尽管其中大多数已经过期。 对我来说，没有PAKE有两个可能的原因：

  • 缺乏流行语言的高质量PAKE实现，使用起来很麻烦；
  • 密码学专家并没有很差地传达其工作的本质和价值，因此大多数人甚至都不知道PAKE的存在。

尽管我说过现在不使用PAKE，但规则仍然有例外。

Tom Wu（不要与Tim Wu混淆）在1998年开发了一个很棒的协议，称为“ SRP”（“安全远程密码”的缩写）。 实际上，它只是一个三阶段的PAKE，具有一些其他功能，这些功能在最初的作品中并未实现。 据我所知，SRP的不同之处在于它是世界上最常见的PAKE协议。 我将给出此陈述的两个证明：

  1. SRP被标准化为TLS密码套件，并在诸如OpenSSL之类的库中实现，尽管似乎没有人特别使用它。
  2. 苹果在其iCloud Key Vault中广泛使用SRP

第二个事实本身可能使SRP成为世界上使用最广泛的加密协议之一，Apple为其加盖的设备数量如此之多。 没有什么好笑的。

业界已经接受了SRP的事实当然是件好事，但另一方面，事实并非如此。 主要是因为尽管任何PAKE认可都很酷，但仅SRP并不是最佳的PAKE实施。 我原本打算进入有关SRP讨论的丛林，但是该演讲已经开始进行了，我偏离了关于一个非常好的协议的故事，我们将在下面讨论。 如果您仍然对SRP的讨论感兴趣，我将其带到这里 。

除了这些不必要的细节，让我写一些关于SRP的简短摘要：

  1. SRP做一些正确的事情。 首先，与早期版本的PAKE不同，您不需要在服务器上存储原始密码（或等效地，可以由攻击者使用的散列代替密码）。 相反，服务器存储“验证程序”，它是密码哈希的单向功能 。 这意味着密码数据库泄漏不允许攻击者仅在他不进行进一步昂贵的字典攻击时立即替换该用户。 （此技术名称为“不对称” PAKE。）
  2. 有更好的消息，当前版本的SRP（v4 v6a）尚未被黑客入侵！
  3. 但是，（不要被开发人员所冒犯）SRP协议的体系结构完全疯狂，并且其早期版本遭到了多次黑客入侵-这就是为什么我们现在拥有版本6a。 另外，原始研究文章中的“安全证明”实际上并未证明任何东西 。
  4. SRP当前基于整数（最终）算法，并且由于各种原因（请参见上文第3节），其SRP体系结构显然无法转换为椭圆曲线 。 这需要更多的带宽和计算能力，因此SRP无法利用我们在诸如Curve25519的附加组件中开发的许多性能改进。
  5. SRP容易受到预先计算的攻击，因为它会将用户的注意力传递给可以发起SRP会话的任何攻击者。 这意味着在服务器受到威胁之前，我可以向服务器索要费用，并建立一个潜在的密码哈希字典。
  6. 尽管存在所有这些缺点，SRP还是非常简单，并且还附带有工作代码。 此外，OpenSSL的工作代码甚至与TLS集成在一起，因此相对易于实现。

在所有这些方面中，后者几乎可以肯定是SRP相对于其他PAKE协议所取得的（相对）高度商业成功的原因。 他不是完美的，而是真实的。 这就是我想传达给密码安全专家的内容。

不透明：PAKE新一代


几个月前，当我开始考虑PAKE时，我不禁注意到大多数现有实现都表现不佳。 他们要么遇到问题，例如在SRP中出现问题，要么要求用户将密码（或有效密码）存储在服务器上，或者向攻击者显示“盐”，从而有机会在计算之前进行攻击。

然后，去年年初，Jarecki，Kravczyk和Xu向世界展示了一种称为OPAQUE的新协议。 它具有许多重要的优点：

  1. 即使存在Diffie-Hellman问题和离散对数问题，也可以实现它。 这意味着，与SRP不同，它可以使用有效的椭圆曲线轻松实例化。
  2. 更好的是：OPAQUE不会向攻击者透露盐分。 他通过使用“健忘的PRF”将盐和密码结合在一起来解决此问题，从而使客户端不会收到盐，而服务器也不会收到密码。
  3. OPAQUE可与任何密码哈希功能一起使用。 由于所有散列工作都是在客户端上执行的，因此OPAQUE实际上可以减轻服务器的负担，例如，释放联机服务以使用大量的安全设置，例如，使用大量RAM配置scrypt 。
  4. 在消息计数和指数方面，OPAQUE与SRP并没有太大区别。 但是，由于可以使用更有效的参数来实现它，因此它的工作效率可能会更高。
  5. 与SRP不同，OPAQUE具有合理的安全证据（非常强大的模型）。

甚至还有OPAQUE的Internet草案建议，您可以在此处阅读。 不幸的是，目前我对代码实现的质量一无所知，除了已经有几种潜在的实现。 我希望这个问题能尽快解决。
下面列出了完整的OPAQUE协议。 在本节的其余部分，我将讨论其工作原理。

问题1：保守盐的秘密。 如上所述，PAKE的早期版本的主要问题是需要将盐从服务器传输到客户端（仍然未经身份验证）。 这使攻击者可以在计算之前进行攻击，从而可以根据接收到的数据生成字典。

这里的问题是盐通常会与密码一起传递给哈希函数（例如scrypt）。 凭直觉，有人需要计算此函数。 如果它是服务器，则服务器应该看到一个密码，该密码会杀死所有含义。 如果这是客户，那么他需要盐。

从理论上讲，您可以通过使用安全的两方计算协议（2PC）计算密码哈希函数来解决此问题。 实际上，这种解决方案几乎肯定是无效的，主要是因为密码哈希函数非常复杂且耗时。 这将极大地增加任何2PC系统的复杂性。

OPAQUE对此进行了如下处理。 它在客户端留下密码哈希，但不显示盐。 取而代之的是，它使用一种称为“健忘PRF”的特殊双向协议来计算另一种盐（我们称其为salt2），以便客户端可以在哈希函数中使用salt2，但无法访问原始的salt。

它的工作原理如下：
服务器存储“盐”，并且客户端具有密码。salt2 = PRF（盐，密码），这是使用客户端将永远不会识别盐并且服务器将知道密码的协议在客户端和服务器之间计算的。 客户端收到salt2K = PasswordHash（salt2，密码）-所有这些都在客户端上考虑。

健忘的PRF的实际实现可以使用几个组元素和指数来完成。 更好的是，如果客户端输入了错误的密码，则协议会收到一个虚拟值“ salt2”，该值不表示盐的实际值。

问题2：证明客户端收到了正确的密钥K。当然，目前客户端已收到密钥K，但是服务器不知道它是什么。 服务器也不知道这是否是正确的密钥。

OPAQUE解决方案基于Gentry，Mackenzie和Ramzan的旧思想。 用户首次登录服务器时，服务器会为安全协议协议（例如HMQV）生成可靠的公钥和私钥，并在K下将接收到的私钥与服务器的公钥一起加密。 生成的经过身份验证的密码（和公共密钥）存储在密码数据库中。

C =加密（K，客户端密钥|服务器的公共密钥）


完整版的OPAQUE协议，摘自本文 。

当客户端希望使用OPAQUE协议进行身份验证时，服务器将向其发送存储的C代码。 如果客户在第一阶段输入了正确的密码，则他可以得到K并解密该密码。 否则，它是无用的。 现在，他可以使用有线秘密密钥运行带有身份验证密钥的标准协议协议，以完成握手。 （服务器通过对照客户端的公钥副本检查客户端的输入来检查客户端的输入，客户端也是如此。）

现在，让我们把它们放在一起。 所有这些步骤都可以组合成一个协议，该协议具有与SRP相同的步骤数。 如果您不注意验证步骤，则它看起来像上面的协议。 原则上，此想法仅包含两个消息：一个来自客户端，第二个发送回服务器。

OPAQUE工作的最后一个方面是，它具有良好的安全性证据，告诉我们，如果我们在随机oracle模型中采用一个或多个离散对数，则可以将生成的协议视为安全的，这是一个标准假设，这显然是，发生在我们使用的设置中。

结论


因此，简而言之，我们拥有可靠的技术，可以使使用密码的过程变得更加容易，并且还可以使我们更有效地处理密码-在客户端具有大量的哈希参数和大量的工作量。 为什么没有到处使用它？ 也许在未来几年内一切都会改变。 时间会证明一切。

根据既定传统，我们正在等待您的评论，并邀请您参观开放日 ，该日将由我们的密码分析家Elena Kirshanova老师于5月27日举行。

Source: https://habr.com/ru/post/zh-CN453334/

More articles:


All Articles