发送加密数据时如何抵御MITM和重放攻击？
假设我已经与另一台计算机安全地交换了密钥（也许使用 Diffie-Hellman），这是我的暂定解决方案：
数据包号+加密数据+消息认证码（MAC）
数据包编号是从0开始递增的数字。之后是加密数据本身，后面是两者的MAC。 如果有人尝试 MITM 攻击，MAC 应该无法计算。 如果他们尝试重放攻击，接收者会注意到它已经收到了该数据包编号。
我的推理有什么缺陷吗？
Assuming I've securely exchanged keys with another computer (using Diffie-Hellman perhaps), here's my tentative solution:
packet number + encrypted data + message authentication code (MAC)
The packet number is an incrementally-increased number starting at 0. After that is the encrypted data itself, followed by a MAC of them both. If someone attempts a MITM attack, the MAC should fail to compute. If they attempt a replay attack, the recipient will notice it has already received that packet number.
Is there any flaw in my reasoning here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这就是您面临最大危险的地方 - 如果中间人设法控制密钥交换（例如，通过与客户端和自身，并与服务器和自身建立另一个密钥），那么 MITM 就可以解密（并重新加密）所有内容。 一旦建立了安全的密钥交换，您就应该不会受到 MITM 攻击。 但困难的部分是确保密钥交换真正安全。
请参阅实用密码学（或访问Amazon），作者：Ferguson 和 Schneier，了解有关此内容的信息。
This is where you face the biggest danger - if the man-in-the-middle manages to control the key exchange (for example, by establishing one key with the client and itself, and establishing another key with server and itself), then the MITM can decrypt (and re-encrypt) everything. Once you've established the secure key exchange, you should be invulnerable to the MITM attack. But the hard part is ensuring that the key exchange is truly secure.
Consult Practical Cryptography (or at Amazon) by Ferguson and Schneier for information about this.
你描述的不是中间人攻击，而是重放攻击。
通过 MITM 攻击，密钥交换被拦截，并且您说您已经安全地交换了密钥 - 所以这不是问题。
重放攻击很容易缓解，您可以添加一个唯一的消息 ID，然后在接收端检查它的唯一性。 通常，每条消息都有一个到期日期和时间，因此您无需保留不断增长的消息 ID 列表来进行验证。
You're not describing a man in the middle attack, but a replay attack.
With a MITM attack the key exchange is intercepted and you say that you already have exchanged keys securely - so it is not the problem.
Replay attacks are easy enough to mitigate against, you include a unique message ID and then check it for uniqueness on the receiving side. Generally each message has an expiry date and time so you don't need to keep an ever growing list of message IDs to validate.
您防止重放攻击的方法对我来说似乎是合理的。 您本质上是在描述一种名为时间戳的方法。 您的数据包编号是一个“虚拟时间”，收件人用它来验证该消息之前是否未发送过。
Your approach for protecting against replay attacks seems reasonable to me. You are essentially describing a method called timestamping. Your packet number is a "virtual time" that is used by the recipient to verify that the message was not sent before.
一旦密钥被交换，数据就不能被第三方拦截或欺骗。 （除非你的数据包计数器循环。假设来自旧窗口的数据包可以像来自新窗口的数据包一样重放。）这个问题的解决方案是时间戳（正如其他人提到的那样）。不过，同样，如果攻击者能够以某种方式损害系统时间。 （如果他们是中间人，他们可以假设模仿 NTP 服务器并以这种方式修改客户端的系统时间。）
然而，窃听者可以做的是将自己插入两方之间并破坏通道。 这可能会导致发生可以观察到的新密钥交换。 为了使密钥交换真正安全，您必须使用第三方验证或只有两个通信者知道的预共享密钥。
Once the keys have been exchanged then the data cannot be intercepted or spoofed by a third party. (Except when your packet # counter loops. Hypothetically packets from the old window could be replayed as being from the new window.) The solution to this problem is timestamping (as others have mentioned.) Again, though, this can be sabotaged if the attacker is able to compromise in some way the system time. (If they are a man in the middle, they could hypothetically imitate an NTP server and in that way modify a client's system time.)
What an eavesdropper COULD do however is to insert himself between the two parties and disrupt the channel. This would likely cause a new key exchange to occur which could be observed. In order to make key exchange truly secure, you must use 3rd party validation or a pre shared key which only the two communicators know.