为什么我不能 MitM Diffie-Hellman 密钥交换?

信息安全 密码学 密钥交换 diffie-hellman 秘密分享 前向保密
2021-08-27 02:21:57

在用简单的英语阅读了“Diffie-Hellman Key Exchange”的选定答案5 次后,我终其一生都无法理解它如何保护我免受中间人攻击。

鉴于以下摘录(来自tylerl 的回答):

  1. 我想出了两个质数gp并告诉你它们是什么。
  2. 然后,您选择一个秘密号码 ( a ),但您不告诉任何人。相反,您计算g a mod p并将结果发送回给我。(我们称它为A ,因为它来自a)。
  3. 我做同样的事情,但我们将调用我的秘密数字b和计算出来的数字B所以我计算g b mod p并将结果发送给你(称为“ B ”)
  4. 现在,你拿着我发给你的号码,用它做同样的操作所以这是B a mod p
  5. 我对你发给我的结果做了同样的操作,所以:A b mod p

以下是 Alpha 控制网络的相同 5 个步骤:

  1. 你试图向我发送gand p,但 Alpha 拦截并学习gandp
  2. 您想出a并尝试将ga mod p( A) 的结果发送给我,但 Alpha 拦截并获悉A
  3. Alpha 提出b并向您发送gb mod p( B)的结果
  4. 你跑 Ba mod p
  5. 阿尔法运行 Ab mod p

在整个过程中,Alpha 伪装成你,并用同样的方法与我创建了一个共享的秘密。

现在,你和阿尔法,阿尔法和我都有一对共享的秘密。

您现在认为与我秘密交谈是安全的,因为当您向我发送使用您的秘密加密的消息时,Alpha 使用您和 Alpha 创建的秘密对其进行解密,使用 Alpha 和我创建的秘密对其进行加密,然后将它们发送给我. 当我回复你时,Alpha 会反过来做同样的事情。

我在这里错过了什么吗?

4个回答

Diffie-Hellman 是一种密钥交换协议,但对身份验证没有任何作用。

有一种高级的、概念性的方式可以看到这一点。在计算机网络和密码学的世界里,你所能看到的,真的,都是通过一些线路发送的零和一。实体只能通过它们可以或不能发送的零和一来区分。因此,用户“Bob”实际上仅由他计算非 Bob 无法计算的事物的能力来定义。由于每个人都可以购买相同的计算机,Bob 只能通过他对某些只有 Bob 知道的价值的了解才能成为 Bob。

在您展示的原始 Diffie-Hellman 交换中,您与某个应该即时生成随机秘密值的实体交谈,并使用它。每个人都可以做这样的随机生成。协议中没有任何地方只有特定的 Bob 可以执行任何操作。因此,该协议无法实现任何类型的身份验证——您不知道您在与谁交谈。没有身份验证,模拟是可行的,这包括同时双重模拟,更广为人知的是中间人最好的情况是,原始 Diffie-Hellman 提供了一个较弱的特性:尽管您不知道自己在与谁交谈,但您仍然知道在整个会话期间您正在与同一个实体交谈。


单一的加密算法不会让你走得太远;任何重要的通信协议都将组装几种算法,以便实现某些明确的安全特性。一个典型的例子是SSL/TLS另一个是SSH在 SSH 中,使用 Diffie-Hellman 密钥交换,但服务器的公共部分(其g b mod p)已签名由服务器。客户端知道它与正确的服务器通信,因为客户端记住(从之前的初始化步骤)服务器的公钥(通常是 RSA 或 DSA 类型);在上面解释的模型中,合法的服务器通过其对与客户端记住的公钥相对应的签名私钥的了解来定义和区别于模仿者。该签名提供身份验证;然后 Diffie-Hellman 生成一个共享密钥,用于加密和保护该连接的所有数据交换(使用一些对称加密和 MAC 算法)。

因此,虽然 Diffie-Hellman 本身并不能满足您的所有需求,但它仍然提供了一个有用的功能,即密钥交换,您不会从数字签名中获得,它提供了加密实际交换数据所需的临时共享密钥.

Tom 很好地解释了为什么 Diffie-Hellman 不能安全地对抗中间人。现在这回答了 OP 的原始问题,但可能会给一些读者留下(合理的)后续问题:为什么我们不只使用公钥(非对称)加密来确保我们消息的机密性,并完全放弃 DH?有一些理由不这样做:

  • 有些算法只支持签名,但不支持加密消息(例如 ECDSA)
  • 对称加密和解密比非对称地快很多
  • 可能最重要的是我们要确保前向保密毕竟,您的通信伙伴之一的私钥在某些时候被泄露并非不可能。现在,如果您只依赖非对称加密,那么您发送给该合作伙伴的所有消息都可能在事后被攻击者解密。相反,如果我们使用 Diffie-Hellman - 准确地说是短暂的 Diffie-Hellman,我们会为每个通信会话生成一个新的 DH 密钥对并在之后将其丢弃(= 不要存储它),这意味着无法解密稍后我们的消息。

在 DH 密钥交换之后,双方都知道他们计算的密钥是什么。如果没有中间人渗透到连接中,则双方将拥有相同的密钥。如果连接被破坏,它们将拥有不同的密钥。如果有一种方法可以让一方询问另一方正在使用什么密钥,那么中间人只有在能够以与合法方相同的方式做出回应的情况下才能保持不被发现。虽然通常使用数字签名来回答问题,但为了使模拟变得困难,也可以通过语音通信等方式提出/回答问题。如果语音应用程序向参与者显示当前的加密密钥并且参与者任意选择范围和流行的电影明星(例如玛丽莲梦露),并要求对方以他们最好的玛丽莲梦露的声音读出第十五到二十五位数字,一个真正的参与者,如果他面前有数字,就可以快速流畅地阅读,并且在没有中间人攻击的情况下,这些数字将与第一方看到的数字相匹配。中间人攻击者可以毫无问题地检测到问题,并且——给定时间——可能能够伪造合法通信者的语音文件,该文件错误地模仿玛丽莲梦露说出适当的数字,但会很难像真正的那样快速地做到这一点。

简而言之,如果每个参与者都知道其他参与者能够比攻击者更有效地处理某个数字,那么 DH 本身就可以抵御 MITM 攻击。然而,其他协议通常与 DH 结合使用,因为它对于自动化身份验证过程很有用,并且大多数不依赖加密的身份验证形式(如语音、短语等)都需要人工验证。此外,实体通常需要征求陌生人的交流。如果想与 Acme Bank 代表交谈,中间人冒名顶替者可以建立一个假的“Acme Bank”办公室并接听我的电话,然后让其他人在假客厅里将我所说的一切转述给真实的人Acme Bank,没有人会更聪明。

DH 通常不能抵抗中间人攻击。

如果 Alice 和 Bob (A<->B) 可以建立一个共享秘密。然后弗兰克可以与爱丽丝(A<->F)建立一个共享秘密,同时弗兰克可以与鲍勃(F<->B)建立第二个(不同的)共享秘密。然后弗兰克可以解密 A-> F 消息并重新加密并发送给鲍勃 F-> B,反之亦然。

*因此,您需要某种方式来确保消息实际上来自 Alice(由 Alice 签名)。使用先前共享的秘密(通过其他渠道传递)或使用证书颁发机构(代理信任)。或者其他一些方法。

如果你只是稍微信任一个 CA,那么 Alice 可以与 Bob 设置一个 DH 共享密钥,用来自 CA 的证书对消息进行签名。Bob 检查消息是否由 CA 签名。Frank 无法伪造这些消息,因为它们没有所需的证书。

现在爱丽丝和鲍勃有一个共享的秘密。弗兰克无法假装进入中间。然而,CA 没有参与创建共享密钥(仅签署沿途发送的部分),因此 CA 也不能扮演坏角色。即使弗兰克用 5 美元的扳手威胁他们。

*稍微简单,但这是一般的想法。